-
процесс приобретения определяет
действия предприятия-покупателя, которое
приобретает информационную систему,
программный продукт или службу программного
обеспечения;
-
процесс поставки определяет действия
предприятия-поставщика, которое снабжает
покупателя системой, программным продуктом
или службой программного обеспечения;
-
процесс разработки определяет действия
предприятия-разработчика, которое разрабатывает
принцип построения программного изделия
и программный продукт;
-
процесс функционирования определяет
действия предприятия-оператора, которое
обеспечивает обслуживание системы в
целом (а не только программного обеспечения)
в процессе ее функционирования в интересах
пользователей. В отличие от действий,
которые определяются разработчиком в
.инструкциях по эксплуатации (эта деятельность
разработчика предусмотрена во всех трех
рассматриваемых стандартах), определяются
действия оператора по консультированию
пользователей, получению обратной связи
и др., которые он планирует сам и берет
на себя соответствующие обязанности;
-
процесс сопровождения определяет
действия персонала, обеспечивающего
сопровождение программного продукта,
то есть управление модификациями программного
продукта, поддержку его текущего состояния
и функциональной пригодности; сюда же
относятся установка программного изделия
на вычислительной системе и его удаление.
Кроме основных, стандарт ISO 12207 оговаривает
8 вспомогательных процессов, которые
являются неотъемлемой частью всего жизненного
цикла программного изделия и обеспечивают
должное качество проекта программного
обеспечения.
К вспомогательным процессам относятся:
-
процесс решения проблем;
-
процесс документирования;
-
процесс управления конфигурацией;
-
процесс обеспечения качества;
-
процесс верификации;
-
процесс аттестации;
-
процесс совместной оценки;
-
процесс аудита.
В стандарте ISO 12207 также определяются
четыре организационных процесса:
-
процесс управления;
-
процесс создания инфраструктуры;
-
процесс усовершенствования;
-
процесс обучения.
примечание
Под процессом усовершенствования в
стандарте ISO 12207 понимается не усовершенствование
информационной системы или программного
обеспечения, а улучшение самих процессов
приобретения, разработки, обеспечения
качества и т. д., реально осуществляемых
в организации.
И наконец, в стандарте ISO 12207 определен
один особый процесс, называемый процессом
адаптации, который определяет основные
действия, необходимые для адаптации этого
стандарта к условиям конкретного проекта.
^ Особенности стандарта ISO 12207
Все сказанное выше позволяет сформулировать
следующие особенности стандарта ISO 12207.
-
Стандарт ISO 12207 имеет динамический характер,
обусловленный способом определения последовательности
выполнения процессов и задач, при котором
один процесс при необходимости вызывает
другой или его часть. Такой характер позволяет
реализовать любую модель жизненного
цикла.
примечание
Согласно стандарту ISO 12207, модель жизненного
цикла — это структура, содержащая процессы,
действия и задачи, которые осуществляются
в ходе разработки, функционирования и
сопровождения программного продукта
в течение всей жизни систеы, от определения
требований до завершения ее использования.
-
Стандарт ISO 12207 обеспечивает максимальную
степень адаптивности. Множество процессов
и задач сконструировано так, что возможна
их адаптация в соответствии с конкретными
проектами информационных систем. Эта
адаптация сводится к исключению процессов,
видов деятельности и задач, неприменимых
в конкретном проекте.
примечание
Согласно ISO 12207, добавление уникальных
или специфических процессов, действий
и задач должно быть оговорено в контракте
между сторонами. Причем «контракт» понимается
в самом широком смысле — от юридически
оформленного документа до неформального
соглашения. Это соглашение может быть
определено даже единственной стороной
— как задача, поставленная самому себе.
-
Стандарт принципиально не содержит описания
конкретных методов действий, а тем более
— заготовок решений или документации.
Он лишь описывает архитектуру процессов
жизненного цикла программного обеспечения,
но не конкретизирует в деталях, как реализовывать
или выполнять услуги и задачи, включённые
в процессы. Данный стандарт не предписывает
имена, форматы или точное содержание
получаемой документации. Решения такого
типа принимаются сторонами, использующими
стандарт.
-
Обеспечение качества разными процессами
выполняется с разной предусмотренной
степенью организационной независимости
контролирующей деятельности вплоть до
обязательных требований к полной независимости
проверяющею персонала от какой-либо прямой
ответственности за проверяемые объекты.
В отличие от CDM контроль этого вида предусмотрен
на самых ранних шагах разработки, начиная
с анализа системных требований посредством
их проверок на соответствие потребностям
приобретения.
-
Степень обязательности рассматриваемого
стандарта следующая: после решения организации
о применении ISO 12207 в качестве условия
торговых отношений является ее ответственность
за указание минимального набора требуемых
процессов и задач, которые обеспечивают
согласованность с этим стандартом.
-
Стандарт содержит предельно мало описаний,
направленных на проектирование базы
данных. Это можно считать оправданным,
так как разные системы и разные прикладные
комплексы программного обеспечения могут
не только использовать весьма специфические
типы баз данных, но и вообще не использовать
базу данных.
Ценность стандарта ISO 12207 в том, что он
содержит наборы задач, характеристик
качества, критериев оценки и т. п., дающие
всесторонний охват проектных ситуаций.
Например, при выполнении анализа требований
к системе предусматривается, что:
-
рассматривается область применения системы
для определения требований, предъявляемых
к системе;
-
спецификация требований системы должна
описывать функции и возможности системы,
области применения системы, организационные
требования и требования пользователя,
безопасность, защищенность, человеческие
факторы, эргономику, связи, операции и
требования сопровождения; проектные
ограничения и квалификационные требования,
Далее, при выполнении анализа требований
к программному обеспечению предусмотрено
11 классов характеристик качества, которые
используются позже при обеспечении качества.
При этом разработчик должен установить
и документировать в виде требований к
программному обеспечению следующие спецификации
и характеристики:
-
функциональные и возможные спецификации,
включая исполнение, физические характеристики
и условия среды эксплуатации, при которых
единица программного обеспечения должна
быть выполнена;
-
внешние связи (интерфейсы) с единицей
программного обеспечения;
-
требования квалификации;
-
спецификации надежности, включая спецификации,
связанные с методами функционирования
и сопровождения, воздействия окружающей
среды и вероятностью травмы персонала;
-
спецификации защищенности, включая спецификации,
связанные с компрометацией точности
информации;
-
человеческие факторы спецификаций по
инженерной психологии (эргономике), включая
связанные с ручным управлением, взаимодействием
человека и оборудования, ограничениями
на персонал и областями, нуждающимися
в концентрированном человеческом внимании,
которые являются чувствительными к ошибкам
человека и обучению;
-
определение данных и требований к базе
данных;
-
установочные и приемочные требования
поставляемого программного продукта
в местах функционирования и сопровождения
(эксплуатации);
-
документацию пользователя;
-
работа пользователя и требования выполнения;
-
требования сервиса пользователя.
примечание
Согласно стандарту IS012207, требование
квалификации — это набор критериев или
условий (квалификационные требования),
которые должны быть удовлетворены для
того, чтобы квалифицировать программный
продукт как подчиняющийся (удовлетворяющий
условиям) его спецификациям и готовый
для использования в целевой окружающей
среде.
Хотя стандарт не предписывает конкретной
модели жизненного цикла или метода разработки,
он определяет, что стороны-участники
при использовании стандарта ответственны
за следующее:
-
выбор модели жизненного цикла для разрабатываемого
проекта;
-
адаптацию процессов и задач стандарта
к этой модели;
-
выбор и применение методов разработки
программного обеспечения;
-
выполнение действий и задач, подходящих
для проекта программного обеспечения.