Структурное проектирование программных средств.
Гибкость модификации и расширяемость комплексов программ при их развитии обеспечивается рядом принципов и правил структурного построения ПС и их компонент, а также взаимодействия между ними. Эти правила направлены на стандартизацию и унификацию структуры и взаимодействия компонент разного ранга и назначения в пределах проблемной области (рис.2). Некоторая часть принципов и правил имеет достаточно общий характер и может применяться практически всегда. Другая часть отражает проблемную и машинную ориентированность класса ПС и подлежит отработке при проектировании для эффективного применения в соответствующей области.
Основные принципы и правила структурирования ПС и БД можно объединить в группы, которые отражают:
Ш стандартизированную структуру ПС или БД определенного класса;
Ш унифицированные правила структурного построения прикладных программных компонент и модулей;
Ш стандартизированную структуру базы данных, обрабатываемых программами;
Ш унифицированные правила структурного построения информационных модулей, заполняющих базу данных;
Ш унифицированные правила структурного построения и организации межмодульного интерфейса прикладных программ;
Ø унифицированные правила внешнего интерфейса и взаимодействия компонент прикладных ПС и БД с внешней средой, с операционной системой и другими типовыми средствами организации вычислительного процесса и контроля.
Сущность структурного подхода к разработке ПО заключается в декомпозиции (разбиении) программ на функции. Все наиболее распространенные методологии структурного подхода базируются на ряде общих принципов. В качестве двух базовых принципов используются следующие:
1) принцип "разделяй и властвуй" - принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения;
2) принцип иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.
Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, поскольку игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к провалу всего проекта). Основными из этих принципов являются следующие:
3) принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечения от несущественных;
4) принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы;
5) принцип непротиворечивости - заключается в обоснованности и согласованности элементов;
6) принцип структурирования данных - заключается в том, что данные должны быть структурированы и иерархически организованы.
Методология структурного анализа и структурного проектирования ПС предполагает использование одного из стилей проектирования:
Ш нисходящего (Top-of-Design);
Ш восходящего (Bottom-of-Design).
При нисходящем проектировании («сверху–вниз») программа разбивается на функциональные подпрограммы, которые в свою очередь делятся на функции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до операторов конкретного языка программирования. При этом программа сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. Четкая реализация нисходящего проектирования приводит к спиральной модели разработки ПО, на каждом витке спирали блоки предыдущего уровня детализируются, используются обратные связи (альтернативой является так называемая каскадная модель, относящаяся к поочередной реализации частей системы).
При восходящем проектировании программы («снизу-вверх»), которое направлено от отдельных задач ко всей системе, целостность программы теряется, возникают проблемы при информационной стыковке отдельных компонентов.
Верхний уровень проектирования ПО часто называют концептуальным проектированием. Концептуальное проектирование выполняют в процессе предпроектных исследований, формулировки ТЗ, разработки эскизного проекта и прототипирования (согласно ГОСТ 34.601-90, эти стадии называют формированием требований к ИС, разработкой концепции ИС и эскизным проектом).
При концептуальном проектировании применяют ряд спецификаций среди которых центральное место занимают модели преобразования, хранения и передачи информации. Модели, полученные в процессе обследования предприятия, являются моделями его функционирования. В процессе разработки ИС модели, как правило, претерпевают существенные изменения (переход от «As Is» (как есть) к «То Be» (как должно быть) и в окончательном виде модель «То Be» рассматривают в качестве модели проектируемой АС.
Различают функциональные, информационные, поведенческие и структурные модели. Функциональная модель системы описывает совокупность выполняемых системой функций. Информационные модели отражают структуры данных — их состав и взаимосвязи. Поведенческие модели описывают информационные процессы (динамику функционирования), в них фигурируют такие категории, как состояние системы, событие, переход из одного состояния в другое, условия перехода, последовательность событий, осуществляется привязка ко времени. Структурные модели характеризуют морфологию системы (ее построение) — состав подсистем, их взаимосвязи.
Для описания функциональных моделей наибольшее распространение получили функциональные спецификации в виде диаграмм. Практически все способы функциональных спецификаций имеют следующие общие черты:
Ш модель имеет иерархическую структуру, представляемую в виде диаграмм нескольких уровней;
Ш элементарной частью диаграммы каждого уровня является конструкция вход-функция-выход;
Ш необходимая дополнительная информация содержится в файлах поясняющего текста.
В большинстве случаев функциональные диаграммы являются диаграммами потоков данных (DFD — Data Flow Diagram). В DFD блоки (прямоугольники) соответствуют функциям, дуги — входным и выходным потокам данных. Поясняющий текст представлен в виде «словарей данных», в которых указаны компонентный состав потоков данных, число повторений циклов и т. п. Для описания структуры информационных потоков можно использовать нотацию Бэкуса-Наура.
Одна из нотаций для DFD предложена Е. Иорданом. В ней описывают процессы (функции), потоки данных, хранилища и внешние сущности, их условные обозначения показаны на рис. 3.2.
Разработка DFD начинается с построения диаграммы верхнего уровня, отражающей связи программной системы, представленной в виде единого процесса, с внешней средой. Декомпозиция процесса проводится до уровня, на котором фигурируют элементарные процессы, которые могут быть представлены одностраничными описаниями алгоритмов (миниспецификациями) на терминальном языке программирования.
Для описания информационных моделей наибольшее распространение получили диаграммы сущность-связь (ERD — Entity-Relation Diagrams), в которых предусмотрены средства для описания сущностей, атрибутов и отношений. Спецификации хранилищ данных в CASE, как правило, даются с помощью диаграмм сущность-связь. Стандартной методикой построения таких диаграмм является IDEF1X.
Поведенческие модели описывают процессы обработки информации. В инструментальных CASE-системах их представляют в виде граф-схем, диаграмм перехода состояний, таблиц решений, псевдокодов (языков спецификаций), процедурных языков программирования, в том числе языков четвертого поколения.
3.3. Приобретение и поставка готовых программных компонент в процессе проектирования
Особенности использования готовых программных и информационных компонент. Как уже отмечалось, многие проекты базируются на покупных, готовых программных и информационных компонентах, возможный состав которых необходимо определить в процессе проектирования. При этом следует учитывать и планировать сложные регламентированные процессы выбора и приобретения разработчиками таких компонент или ПС в целом, а также процессы их поставки. Особенно высокие требования к качеству, защите, унификации интерфейсов и оформлению документации целесообразно предъявлять к тем компонентам, которые в перспективе будут использоваться многократно в различных проектах, различными специалистами и на той же или иной платформах.
С точки зрения обеспечения повторного использования готовых программных компонент в современных ПС наиболее существенными представляются две задачи:
1) структурирование программ и данных проекта ПС на стадиях анализа и системного проектирования, предполагающее последовательную декомпозицию заданных функций и соответственно архитектуры системы, что позволяет выделить компоненты, которые могут быть применены повторно как готовые, и описание их взаимодействия с другими компонентами;
2) сборка или интеграция готовых компонент и комплексное тестирование и испытания ПС в целом.
Эффективность поиска, выбора и выделения готовых программных компонент или ПС в целом при системном проектировании для использования в новом проекте зависит прежде всего от их объема и от кратности возможного применения. При проектировании ПС небольшого объема (порядка тысячи строк исходного текста) поиск, подбор и адаптация готовых компонент для их применения в новом ПС чаще всего оказываются не рентабельными, проще написать новые программы. Таким образом, существует некоторый диапазон объемов программ и информации баз данных («докритическая масса»), для которых нецелесообразно применять ранее созданные программы и массивы данных. В зависимости от объема и назначения компонент можно выделить три варианта их использования:
1) готовые комплексы программных и информационных компонент и операционной среды в целом, решающие все функциональные задачи определенной информационной системы и полностью сохраняющие свою архитектуру в новом проекте;
2) достаточно автономные, крупные прикладные ПС и базы данных, решающие дополнительные функциональные задачи во взаимодействии с имеющимися «унаследованными» операционными и прикладными средствами;
3) отдельные модули или небольшие функциональные группы прикладных программ и информационных массивов данных для расширения и совершенствования функций ранее реализованных функциональных задач.
Приведенные варианты применения готовых компонент значительно различаются возможностью выбора технологии, стандартов и инструментария для последующего проектирования. В первом случае они почти полностью определяются степенью совместимости аппаратных платформ и потенциальной мобильностью применяемых компонент. При использовании небольших компонент, имеющаяся среда, куда встраиваются готовые программы и данные определяет необходимость использования технологии и инструментария, которые применялись при их создании. Методологически наиболее сложным случаем является применение и встраивание дополнительных функциональных приложений в иную аппаратную и операционную платформу и в программную среду, которая уже содержит часть прикладного комплекса программ и массивов данных информационной системы.
Проектирование на базе повторно применяемых, готовых компонент становится особенно рентабельным для сложных ПС, содержащих сотни или тысячи модулей, и с большими объемами обрабатываемой информации. Кратность применения компонент также значительно влияет на эффективность их использования. На первый взгляд, повторное использование исходных текстов программных компонент на однотипных реализующих ЭВМ на любых языках программирования представляется тривиальным. Однако для обеспечения эффективного применения готовых программ необходимо при их первичной разработке поставщиками подготовить возможность их последующего многократного использования в различном операционном и внешнем окружении. Для этого должна быть унифицирована технология разработки модулей и групп программ, унифицированы структуры межмодульных связей и технология комплексирования, стандартизирована система идентификации и специфицирования программ и переменных, а также дисциплина испытаний и документирования компонент и комплекса программ в целом. Программные компоненты должны быть подготовлены для отчуждения от их первичных разработчиков и от комплекса ПС, в составе которых они первично отлаживались, испытывались и применялись. Таким образом, возникает необходимость проведения поставщиками компонент ряда предварительных общесистемных и организационных работ, а также некоторых дополнительных затрат на обеспечение возможности переноса программ и данных в различную внешнюю среду.
Затраты и ресурсы для обеспечения возможности применения готовых компонент требуются в той или иной степени на двух фазах:
1) при создании потенциально переносимых ПС и БД, когда свойства эффективной мобильности предусматриваются и реализуются при их разработке и определяются возможные платформы и области повторного использования таких программ и данных;
2) при непосредственной реализации с соответствующими затратами процессов переноса ПС и БД, в различной степени подготовленных для повторного использования на той же или иной платформах.
При анализе первой фазы следует учитывать, что к настоящему времени накоплен огромный объем прикладных программ и информации в базах данных, при создании которых не учитывалась возможность их последующего переноса на иные платформы - так называемые "унаследованные" системы. Более того, из-за ограниченных ресурсов вычислительных средств при реализации крупных функциональных задач программы и данные в таких системах обычно в максимальной степени адаптировались при разработке к особенностям и параметрам ЭВМ для эффективного использования их ресурсов.
При выборе готовых программных и информационных компонент для обеспечения модернизации и развития проекта комплекса программ следует учитывать наличие заложенных в них элементов унификации:
1) унифицированные протоколы и интерфейсы взаимодействия приложений между собой, со средой ИС, с пользователями, с внешней средой, к которым относятся, прежде всего, интерфейсы прикладного программирования;
2) языки программирования и инструментальные средства, поддерживающие создание готовых переносимых приложений - использованные CASE-технологии;
3) языки баз данных и системы управления базами данных;
4) форматы данных, форматы электронных сообщений. Значительная часть этих задач решается путем применения соответствующих стандартов информационных технологий, действующих как международные или национальные нормативные документы, или открытых спецификаций, отражающих сложившиеся промышленные стандарты "де-факто".
Для проверки соответствия создаваемого ПС применяемым стандартам, требуется иметь тесты соответствия в составе целевой или CASE-системы, поддерживающей создание приложений. Функционирование программного обеспечения среды на выбранных для ИС платформах обычно гарантируется поставщиками готовых компонент, о чем должно быть явно сказано в документации поставщика.
В общем случае невозможна разработка прикладных ПС и БД на базе готовых компонент, эффективно переносимых на любые ЭВМ, в различные операционные системы и для любой внешней среды. При переносе свойства ИС практически всегда изменяются, что следует учитывать при анализе целесообразности переноса, а также могут быть необходимы дополнительная отладка, испытания и сертификация получаемых ПС и БД в новой среде. Следует также учитывать, что любое непосредственное использование готовых компонент связано с некоторыми затратами, которые чаще всего требуются для:
1) системного анализа рентабельности их применения и переноса на иную или ту же платформу и для технико-экономического обоснования этого процесса;
2) интеграции с операционной и внешней средой новой аппаратной платформы или в существующей среде;
3) испытаний и минимально необходимой проверки функционирования ПС и БД в новом окружении или на новой платформе;
4) сертификации ПС и БД перенесенных на новую платформу и функционирующих в иной операционной и внешней среде;
5) корректировки или дополнения пользовательской и технологической документации.
Так как при создании мобильных ПС и БД трудно предусмотреть все возможные особенности различных платформ и внешней среды, для которых декларируется мобильность конкретных компонент, эти особенности и возможное расширение окружающих прикладных программ и данных могут преподносить неприятные «сюрпризы» нестыковки, для ликвидации которых потребуются дополнительные ресурсы.
Технология создания и применения мобильных прикладных программ и информации баз данных с использованием готовых компонент быстро совершенствуется и в ближайшие годы станет доминирующей при создании сложных информационных систем. Исследования открытых систем, разработка технологических инструментальных комплексов и их активное применение позволят повысить качество и конкурентоспособность готовых программных средств и баз данных и резко сократить трудоемкость, стоимость и длительность их создания.
В процессе системного проектирования комплексов программ на базе готовых программных компонент процессы их поставки и приобретения составляют значительную часть работ. Системный анализ должен подготовить и обеспечить выбор таких компонент или ПС в целом с необходимыми характеристиками и качеством. Он должен проводиться в тесном взаимодействии разработчиков и заказчика для оперативного решения задач, обеспечивающих создание ПС с нужными функциями и необходимого качества.
В стандарте ISO 12207 процессы поставки и приобретения готовых компонент и программных средств в целом, а также организационного взаимодействия их поставщиков и потребителей (разделы 5.1 и 5.2) рассматриваются как начальные, предшествующие процессам разработки, которым посвящен раздел 5.3 стандарта. В них внимание акцентируется на организации экономического и технического взаимодействия покупателя и продавца готового программного продукта или сервиса в течение всего жизненного цикла ПС. Раздел поставки (5.2) содержит основные требования заказчика к организации Работ поставщика в течение всего жизненного цикла ПС и его компонент, которые детализируются и реализуются всеми последующими разделами стандарта. При проектировании целесообразно учитывать основные требования и рекомендации разделов 5.1 и 5.2 стандарта ISO 12207 (цифры в скобках соответствуют ссылкам на другие разделы этого стандарта), изложение которых с небольшими сокращениями представлено ниже с сохранением основного текста и нумерации подразделов стандарта.
5.1. Процесс приобретения
Процесс приобретения содержит действия и задачи покупателя. Процесс начинается с определения нужных для приобретения компонент, программного продукта или сервиса программного обеспечения. Далее следуют подготовка и оформление заявки на приобретение, выбор поставщика и управление процессом приобретения, принятие компоненты, программного продукта или сервиса программного обеспечения.
5.1.1. Инициирование
5.1.1.1. Покупатель начинает процесс приобретения, описывая концепцию или потребность приобретения, разработки или расширения системы, программного продукта или обслуживания программного обеспечения.
5.1.1.2. Покупатель определяет и анализирует требования системы. Требования системы должны включать коммерческую деятельность, организацию и требования надежности, безопасности, защиты информации и другие критические требования вместе с проектированием, тестированием и соответствующими стандартами и процедурами.
5.1.1.3. Если покупатель приглашает поставщика, чтобы выполнить анализ требований системы, покупатель утверждает проанализированные требования.
5.1.1.4. Покупатель может выполнить определение и анализ требований программного обеспечения сам или может приглашать поставщика для выполнения этой задачи.
5.1.1.5. Процесс разработки (5.3) используется для выполнения задач в 5.1.1.2 и 5.1.1.4.
5.1.1.6. Покупатель рассматривает варианты приобретения, начиная с анализа соответствующих критериев и до включения риска, стоимости затрат и выгоды от каждого варианта. Варианты включают:
а) покупку готового программного продукта, который удовлетворяет все требования;
б) разработку программного продукта и приобретение сервиса программного обеспечения внутрисистемно;
в) разработку программного продукта и приобретение сервиса программного обеспечения через контракт;
г) комбинацию а, б, в;
д) модернизацию существующего программного продукта или обслуживания.
5.1.1.7. При покупке готового программного изделия покупатель должен получить гарантии, что удовлетворены следующие условия:
а) удовлетворены требования для программного продукта;
б) в распоряжении есть документация;
в) удовлетворены права собственности, употребления, лицензирования и гарантии;
г) удовлетворена будущая поддержка программного продукта.
5.1.1.8. Покупатель должен подготовить, документировать и выполнить план приобретения, который включает в себя:
а) требования к системе;
б) запланированная занятость системы;
в) тип используемого контракта;
г) обязательства вспомогательных организаций;
д) поддержка используемой концепции;
е) учтенные риски и методы управления ими. 5.1.1.9. Покупатель должен определить и документировать принятые стратегии и критерии.
5.1.2. Заявка на подготовку предложения
5.1.2.1. Покупатель должен задокументировать требования на приобретение (например, заявка на приобретение), содержание которых зависит от вариантов, указанных в 5.1.1.6. Документация на приобретение должна включать:
а) требования к системе;
б) область действия;
в) инструкции для участников торгов;
г) список программных продуктов;
д) сроки и условия приобретения;
е) контроль над субподрядным договором;
ж) технические ограничения.
5.1.2.2. Покупатель должен определить процессы, действия и задачи этого стандарта, которые являются подходящими для конкретного проекта, и должен соответственно их применять. В первую очередь покупатель должен определить применяемые вспомогательные процессы и использующие их организации, включая обязательства, так, чтобы поставщики могли в их предложениях определить подход к каждому из специфических вспомогательных процессов. Покупатель определяет возможности реализации тех задач, которые отражаются в контракте.
5.1.2.3. Документация приобретения должна определять промежуточные отчеты контракта, в которых будет рассмотрен и проверен прогресс поставщика как часть текущего контроля приобретения.
5.1.2.4. Требования приобретения должны быть предоставлены организации, выбранной для выполнения деятельности по приобретению.
5.1.3. Подготовка контракта и модернизация
5.1.3.1. Покупатель должен установить процедуры для выбора поставщика, включая критерии оценки предложений и соответствия требованиям.
5.1.3.2. Покупатель должен выбрать поставщика, исходя из оценки предложений поставщиков, их возможностей и других рассмотренных факторов.
5.1.3.3. Покупатель может включать другие стороны, включая потенциальных поставщиков до сдачи подряда на поставку товара с применением этого стандарта для проекта. Покупатель принимает окончательное решение относительно адаптации. Покупатель может включать или ссылаться в контракте на адаптированный данный Международный стандарт.
5.1.3.4. Покупатель затем готовит и обсуждает условия контракта с поставщиком, которому адресует требования приобретения, включая стоимость и план (перечень) программного продукта или сервиса, который должен быть поставлен. Контракт адресует права собственности, употребления, лицензирования и гарантии, связанные с имеющимися в наличии программными продуктами многократного использования.
5.1.3.5. Если контракт уже заключен, то покупатель контролирует изменения через переговоры с поставщиком, как часть механизма контроля изменений. Изменения в контракте должны быть исследованы для воздействия на проектные планы, затраты, выгоды, качество.
ПРИМЕЧАНИЕ. Покупатель должен определить какой из терминов "контракт" или "соглашение" используется для применения этого Международного стандарта.
5.1.4. Мониторинг поставщика
5.1.4.1. Покупатель контролирует деятельность поставщика согласно Процессу Совместной Оценки (6.6) и Процессу Проверки (6.7). Покупатель должен дополнить текущий контроль Процессом Верификации (6.4) и Процессом Аттестации (6.5) как это определено в контракте.
5.1.4.2. Покупатель должен сотрудничать с поставщиком для обеспечения всей необходимой информацией своевременно и решения всех нерешенных вопросов.
5.7.5. Принятие и завершение
5.1.5.1. Покупатель должен готовиться к принятию программных средств на основе определенной приемной стратегии и критериев, которые включают подготовку контрольных тестовых примеров, данных, процедур и среды эксплуатации. Должна быть определена степень возможных затруднений (в том числе денежных) поставщика.
5.1.5.2. Покупатель проводит приемную оценку и приемочные испытания поставляемого программного продукта или сервиса и принимает их от поставщика, когда удовлетворены все условия приемки. Процедура приемки должна подчиняться условиям 5.1.1.9.
5.1.5.3. После принятия, покупатель должен взять ответственность за управление конфигурацией поставляемого программного продукта (см.6.2).
ПРИМЕЧАНИЕ. Покупатель может устанавливать программный продукт или выполнять сервис программного обеспечения согласно инструкциям, определенным поставщиком.
5.2. Процесс поставки
Процесс поставки содержит действия и задачи поставщика. Процесс может быть начат решением о подготовке предложения
для ответа на требование (запрос) о приобретении или подписанием и заключением контракта с покупателем для обеспечения системы, программного продукта или сервиса. , Процесс продолжается определением процедур и ресурсов, необходимых для управления и гарантии качества проекта, включая разработку проектных планов и выполнение планов посредством поставки компонент, программного продукта или сервиса покупателю.
5.2,1. Инициирование
5.2.1.1. Поставщик должен провести обзор требований в запросе о приобретении, принимая во внимание организационную политику и другие правила.
.2.1.2. Поставщик должен принять решение о предлагаемой цене (на аукционе, торгах) или принять контракт.
5.2.2. Подготовка ответа
5.2.2.1. Поставщик должен определить и подготовить предложение в ответ на запрос о приобретении, включая рекомендуемые положения этого Международного стандарта.
5.2.3. Контракт
5.2.3.1. Поставщик ведет переговоры и заключает контракт с покупателем на обеспечение программным продуктом или сервисом.
5.2.3.2. Поставщик может требовать дополнения к контракту в части механизма управления изменениями.
5.2.4. Планирование
5.2.4.1. Поставщик должен провести оценку требований приобретения, чтобы определить структуру для управления и гарантирования выполнения проекта и для гарантии качества поставляемого программного продукта или сервиса.
5.2.4.2. Если не предусмотрено в контракте, поставщик определяет или выбирает модель жизненного цикла программного обеспечения, соответствующую области применения, величине (важности) и сложности проекта. Процессы, действия и задачи этого Международного стандарта должны быть выбраны и отображены на модели жизненного цикла.
5.2.4.3. Поставщик должен установить требования для планов управления и гарантии проекта и гарантирования качества поставляемого программного продукта или сервиса. Требования для планов должны включать потребности ресурсов и возможные ограничения пользователя.
5.2.4.4. Если требования планирования установлены, поставщик должен рассмотреть примеры разработки программного продукта или предоставления сервиса, противопоставив им анализ рисков, связанных с каждым примером. Примеры включают:
а) разработка программного продукта или предоставление сервиса, используя внутренние ресурсы;
б) разработка программного продукта или предоставление сервиса, заключая субподрядный договор;
в) получение готовых программных продуктов от внутренних или внешних источников;
г) комбинация а, б, в.
5.2.4.5. Поставщик должен разработать и документировать планы руководства проектом, основанные на требованиях планирования и примерах, выбранных в 5.2.4.4. Пункты, которые должны быть рассмотрены в плане, включают, но не ограничиваются, следующими:
а) проектирование организационной структуры, полномочий, ответственности (обязательств) каждой организационной единицы, включая внешние организации;
б) проектирование окружения (для разработки, функционирования или сопровождения), включая испытательное окружение, оборудование, библиотеку, средства, стандарты, процедуры и инструментарий;
в) структура прерывания процессов жизненного цикла и действий, включая программные продукты, сервис и не поставляемые единицы, должна быть выполнена вместе с запасами, персоналом, физическими ресурсами, размером программного обеспечения и планами, связанными с задачами;
г) управление качественными характеристиками программного продукта или сервиса. Могут быть разработаны отдельные планы для качества;
д) управление безопасностью, защитой и другими критическими требованиями программных продуктов или сервиса. Могут быть разработаны отдельные планы по безопасности и
защите;
е) управление субподрядчиком, включая выбор субподрядчика и решение финансовых затруднений между субподрядчиком и покупателем, если они есть;
ж) оценка качества (см.6.3);
з) верификация (см.6.4) и аттестация (см.6.5); включение варианта связи с помощью интерфейса с проверкой и аттестационным агентом, если это определено;
и) возможные затруднения покупателя: решаются при помощи таких средств как совместные оценки (см.6.6), проверки (см.6.7), неофициальные встречи, сообщения, модификация и изменение; реализация, утверждение, принятие и доступ к оборудованию (доступность);
к) затруднения пользователя: решаются при помощи таких средств, как выполнение регулирующих требований, демонстрации прототипов и оценки;
л) управление риском, т. е. управление областями проекта, которые включают технический потенциал, стоимость и планирование рисков;
м) политика безопасности: включает правила обязательного доступа к информации на каждом проектном уровне организации;
н) утверждение: обеспечивается такими средствами, как правила, требуемые для удостоверения (свидетельства), гарантии, необходимые права собственности, лицензионные права;
о) средства для планирования, трекинга и сообщений;
п) обучение персонала (см.7.4).
http://www. *****/2008/11/18/metody-proektirovanie-slozhnykh-programmnykh. html
