Вовлеченные стороны. Должно быть определено или указано, какие стороны вовлечены в проект (например, заказчик, поставщик, разработчик, субподрядчик, посредник по верификации и посредник по аттестации, персонал сопровождения) и численность соответствующего персонала. Должны быть рассмотрены все требования, относящиеся к организационным интерфейсам между двумя сторонами, например, интерфейс заказчика с разработчиком и поставщика с посредниками по верификации или аттестации. Большой проект, включающий много (десятки или сотни) лиц, требует значительного административного надзора и контроля. Для большого проекта важны такие средства, как внутренние и независимые оценки, анализы, аудиторские проверки и инспекции, а также сбор важнейших данных по проекту. Для малых проектов такой контроль может быть излишним.
Работа жизненного цикла системы. Должно быть определено, какая из работ жизненного цикла существующей системы уместна и применима, например, подготовка проекта заказчиком, разработка поставщиком и сопровождение. Ниже приведены некоторые сценарии:
a. заказчик готовит или определяет требования к системе, изучает выполнимость и прототипность требований и проекта. Может быть выполнено программирование для прототипов, результаты которого могут использоваться или не использоваться в дальнейшем при разработке программных продуктов по договору. Могут быть разработаны требования к системе и предварительные требования к программным средствам. В этих случаях может быть использован процесс разработки (см. 5.3 настоящего стандарта) скорее как руководство, чем как требование; может не потребоваться строгое отношение к квалификации и оценке и могут не потребоваться совместные анализы и аудиторские проверки;
b. разработчик создает программный продукт в соответствии с договором. В этом случае все требования к процессу разработки (см. 5.3 настоящего стандарта) следует учитывать при адаптации;
c. персонал сопровождения модифицирует программные продукты. Учитывается процесс сопровождения (см. 5.5 настоящего стандарта). Части процесса разработки (см. 5.3) могут быть использованы в качестве мини-процессов.
Характеристики системного уровня. Должно быть определено, какие из характеристик системного уровня уместны и применимы, например, количество подсистем и объектов конфигурации. Если система содержит много подсистем или объектов конфигурации, то процесс разработки (см. 5.3 настоящего стандарта) следует тщательно адаптировать к каждой подсистеме и объекту конфигурации. Следует учесть все требования к итерфейсу и сборке.
Характеристики программного уровня. Должно быть определено, какие из характеристик программного уровня уместны и применимы, например, количество программных объектов, типы, объемы и критичность программных продуктов, а также технические риски. Если программный продукт включает много программных объектов, компонентов и модулей, то следует тщательно адаптировать процесс разработки (см. 5.3) к каждому программному объекту. Следует учесть все требования к интерфейсу и сборке.
Должно быть определено, какие из типов программных продуктов присутствуют в проекте, так как для различных типов программных продуктов требуются различные решения по адаптации. Ниже приведены некоторые примеры:
a. Новая разработка. Должны быть учтены все требования, особенно к процессу разработки (см. 5.3);
b. Использование готового программного продукта. Весь процесс разработки (см. 5.3) может быть излишним. Должны быть оценены функциональные характеристики, документация, патентная чистота, используемость, права собственности, гарантийные и лицензионные права, а также возможность дальнейшей поддержки, относящиеся к программному продукту;
c. Модификация готового программного продукта. Документация может отсутствовать. В зависимости от критичности и ожидаемых дальнейших изменений в процессе сопровождения (см. 5.5 настоящего стандарта) должен быть реализован процесс разработки (см. 5.3). Должны быть оценены функциональные характеристики, документация, патентная чистота, используемость, права собственности, гарантийные и лицензионные права, а также возможность дальнейшей поддержки, относящиеся к программному продукту;
d. Программный или программно-аппаратный продукт, встроенный или подключенный к системе. Так как такой программный продукт является частью большой системы, то следует учитывать работы процесса разработки (см. 5.3), связанные с системой. Из работ, связанных с системой, необходимо выбрать только те, которые описаны глаголами «выполнять» или «поддерживать». Если программный или программно-аппаратный продукт, скорее всего, не будет в дальнейшем изменяться, то следует тщательно проверить необходимую степень его документируемости;
e. Отдельно поставляемый программный продукт. Так как такой программный продукт не является частью системы, то не требуется рассматривать работы процесса разработки (см. 5.3), связанные с системой. Следует тщательно проверить потребность в документации, особенно для сопровождения [1];
f. Непоставляемый программный продукт. Так как данные объекты не заказываются, не поставляются или не разрабатываются, то не следует учитывать положения настоящего стандарта, за исключением 5.3.1.5 процесса разработки по 5.3. Однако если заказчик желает приобрести часть такого программного продукта для дальнейших эксплуатации и сопровождения, то данный программный продукт следует рассматривать в перечислениях b) или с) настоящего пункта.
Другие соображения.
Система в значительной степени зависима от правильной эксплуатации и своевременного окончания создания программного продукта, поэтому должен быть усилен административный контроль во время тестирования, анализов, аудиторских проверок, верификаций, аттестации и т. д. Напротив, усиленный административный контроль за некритичными или малыми программными продуктами может привести к неэффективным затратам.
Разработка программного продукта может иметь технические риски. Если используется несовершенная технология программирования, то разрабатываемый программный продукт будет несовершенным или сложным, а если к программному продукту предъявляются требования по безопасности, защите или другие критические требования, то может потребоваться точное установление технических требований к нему, тщательное его проектирование, тестирование и оценка. Могут оказаться важными независимая верификация и аттестация.
ПРИЛОЖЕНИЕ С (справочное)
Руководство по процессам и организациям
В настоящем приложении с целью лучшего понимания текста стандарта обсуждаются процессы, организации и их взаимоотношения по ключевым вопросам.
C.1 Процессы с ключевых точек зрения
Настоящий стандарт содержит процессы, применяемые на протяжении жизненного цикла программных средств. Однако данные процессы могут быть использованы разными способами различными организациями и сторонами с разных точек зрения и с различными целями. В данном разделе процессы и их взаимосвязи рассматриваются с ключевых точек зрения. Краткий обзор процессов приведен в 4.1.1 настоящего стандарта.
На рисунке С.1 изображены процессы жизненного цикла программных средств и их взаимосвязи при различных подходах к использованию настоящего стандарта. Основными представленными подходами являются: договор, управление, эксплуатация, технология и поддержка. С точки зрения договора стороны заказчика и поставщика ведут переговоры и вступают в договорные отношения, используя при этом, соответственно, процесс заказа и процесс поставки. С точки зрения управления заказчик, поставщик, разработчик, оператор, персонал сопровождения или другие стороны управляют соответствующим процессом. С точки зрения эксплуатации оператор представляет пользователям услуги по эксплуатации программных средств. С точки зрения технологии разработчик или персонал сопровождения выполняет соответствующие технологические задачи при создании или модернизации программных продуктов. С точки зрения поддержки стороны (такие, как управление конфигурацией, обеспечение качества) предоставляют услуги по поддержке другим сторонам при выполнении специфических, уникальных задач. Также показаны (см. нижнее окно на рисунке C.I) организационные процессы; они применяются организацией на уровне объединения, чтобы установить и реализовать подчиненную структуру соответствующего процесса(ов) жизненного цикла и персонала и постоянно улучшать ее.