1. Реализация процесса

Эта деятельность состоит следующих задач:

5.3.1.1. Если не оговорено в контракте, разработчик должен определить или выбрать модель жизненного цикла программного обеспечения, соответствующую возможностям, величине и сложности проекта. Действия и задачи Процесса Разработки должны быть выбраны и отображены на модель жизненного цикла.

ПРИМЕЧАНИЕ. Эти действия и задачи могут накладываться или взаимодействовать и могут быть выполнены взаимосвязано или рекурсивно.

5.3.1.2. Разработчик должен:

а) документировать выходные данные согласно Процессу Документирования (6.1);

б) разместить выходные данные при Процессе Управления Конфигурацией (6.2) и выполнить контроль изменений согласно этому пункту;

в) документировать и решать проблемы и несоответствия, найденные в программных продуктах и задачах согласно Процессу Разрешения Проблем (6.8);

г) выполнить вспомогательные процессы (п.6), как определено в контракте.

5.3.1.3. Разработчик должен выбирать, настраивать и использовать стандарты, методы, инструментарии, языки программирования (если не конкретно не оговорено в контракте), которые задокументированы, соответствуют и установлены организацией для выполнения действий Процесса Разработки и вспомогательных процессов (п.6).

5.3.1.4. Разработчик должен разработать планы проведения действий процесса разработки. Планы должны включать стандарты, методы, инструментальные средства, действия и обязательства, связанные с разработкой и квалификацией всех требований, включая надежность и защищенность. Если необходимо, могут быть разработаны индивидуальные планы. Эти планы должны быть задокументированы и выполнены.

5.3.1.5. Непоставляемые изделия могут быть использованы в разработке программного изделия. Однако должно быть гарантировано, что функционирование и сопровождение поставляемых программных продуктов, после их поставки покупателю не зависят от таких изделий, иначе эти изделия должны быть рассмотрены как поставляемые.

2. Анализ системных требований

Эта деятельность состоит из следующих задач, которые разработчик должен выполнить или поддержать, как требуется по условиям контракта:

5.3.2.1. Рассматривается область применения системы для определения требований системы. Спецификация требований системы должна описывать: функции и возможности системы, бизнес, организационные требования и требования пользователя, безопасность, защищенность, человеческие факторы, эргономику, связи, операции и требования сопровождения; проектные ограничения и квалификационные требования. Квалификация требований системы должна быть документирована.

5.3.2.2. Требования системы должны быть определены при помощи рассмотрения критериев перечисленных ниже. Результаты оценок должны быть документированы:

а) трассируемость к потребностям приобретения;

б) согласованность с нуждами приобретения;

в) контролируемость;

г) выполнимость архитектуры системы;

д) возможность функционирования и сопровождения.

3. Проектирование архитектуры системы

Эти действия состоят из следующих задач, которые разработчик должен выполнить или поддержать, как требуется контрактом:

5.3.3.1. Должна быть установлена архитектура верхнего уровня системы. Архитектура должна идентифицировать единицы аппаратных средств, программного обеспечения и ручного управления. Должно быть гарантировано, что все требования системы распределены среди единиц. Единицы конфигурации аппаратных средств и программного обеспечения и ручные действия должны быть впоследствии идентифицированы от этих единиц (изделий). Архитектура системы и требования системы, распределенные к единицам должны быть документированы.

5.3.3.2. Архитектура системы и требования для единиц должны быть оценены, рассматривая критерии, опубликованные ниже. Результаты оценок должны быть документированы:

а) трассируемость к требованиям системы;

б) согласованность с требованиями системы;

в) соответствие стандартов проектирования и используемых методов;

г) выполнимость единиц программного обеспечения, выполняющих распределенные требования;

д) возможность функционирования и сопровождения.