1. Процесс приобретения. Определяет действия предприятия-покупателя, которое приобретает АС, программный продукт или сервис ПС.
2. Процесс поставки. Определяет действия предприятия-поставщика, которое снабжает покупателя системой, программным продуктом или сервисом ПС.
3. Процесс разработки. Определяет действия предприятия-разработчика, которое разрабатывает принцип построения программного изделия и программный продукт.
4. Процесс эксплуатации. Определяет действия предприятия-оператора, которое обеспечивает обслуживание системы (а не только ПС) в процессе ее функционирования в интересах пользователей. В отличие от действий, которые определяются разработчиком в инструкциях по эксплуатации (эта деятельность разработчика предусмотрена во всех трех рассматриваемых стандартах), определяются действия оператора по консультированию пользователей, получению обратной связи и др., которые он планирует сам и берет на себя соответствующие обязанности.
5. Процесс сопровождения. Определяет действия персонала сопровождения, который обеспечивает сопровождение программного продукта, что представляет собой управление модификациями программного продукта, поддержку его текущего состояния и функциональной пригодности, включает в себя инсталляцию и удаление программного изделия на вычислительной системе.
Вспомогательные процессы: документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, решение проблем.
Организационные процессы: управление, создание инфраструктуры, усовершенствование, обучение.
Каких-либо этапов, фаз, стадий не предусмотрено, что дает описываемую ниже степень адаптивности. Динамический характер стандарта зависит от способа определения последовательности выполнения процессов и задач, при котором один процесс при необходимости вызывает другой или его часть.
Примеры
Процесс приобретения в части анализа и фиксации требований к системе или ПC может вызывать исполнение соответствующих задач процесса разработки. В процессе поставки поставщик должен управлять субподрядчиками согласно процессу приобретения и выполнять верификацию и аттестацию по соответствующим процессам. Сопровождение может требовать развития системы и ПC, что выполняется по процессу разработки.
Такой характер позволяет реализовать любую модель ЖЦ.
При выполнении анализа требований к ПC предусмотрено 11 классов характеристик качества, которые используются позже при гарантировании качества и оформляются в виде требований к ПС:
1. Функциональные и возможные спецификации, включая исполнение, физические характеристики и условия среды эксплуатации, при которых единица программного обеспечения должна быть выполнена.
2. Внешние связи (интерфейсы) с единицей программного обеспечения.
3. Требования к квалификации.
4. Спецификации надежности, включая спецификации, связанные с методами функционирования и сопровождения, воздействием окружающей среды и вероятностью травмирования персонала.
5. Спецификации защищенности.
6. Человеческие факторы, спецификаций по инженерной психологии (эргономике), включая факторы связанные с ручным управлением, взаимодействием человека и оборудования, ограничениями персонала и областей, нуждающихся в концентрированном человеческом внимании, которые являются чувствительными к ошибкам человека и обучения.
7. Определение данных и требований базы данных.
8. Установочные и приемочные требования поставляемого программного продукта в местах функционирования и сопровождения (эксплуатации).
9. Документация пользователя.
10. Работа пользователя и требования выполнения.
11. Требования сервиса пользователя.
Итак, ISO 12207 имеет набор процессов, действий и задач, охватывающий наиболее широкий спектр возможных ситуаций при максимальной адаптируемости. Он показывает пример того, как должен строиться хорошо организованный стандарт, содержащий минимум ограничений (принцип «нет одинаковых проектов»). При этом детальные определения процессов, форм документов и т.п. целесообразно выносить в различные функциональные стандарты, ведомственные нормативные документы или фирменные методики.
