ISO 12207:1995 - процессы ЖЦ ПО

ISO 12207:1995 – ISO Standard for Software life cycle processes [см. 13, 18].

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО. Под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует. Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

По определению, ISO12207 - базовый стандарт процессов ЖЦ ПО, ориентированный на различные (любые) виды ПО и типы проектов АС, куда ПО входит как часть. Стандарт определяет стратегию и общий порядок в создании и эксплуатации ПО, он охватывает ЖЦ ПО от концептуализации идей до завершения ЖЦ.

Очень важное замечание стандарта: процессы, используемые во время ЖЦ ПО, должны быть совместимы с процессами, используемыми во время ЖЦ АС. (Отсюда понятна целесообразность совместного использования стандартов на АС и на ПО.)

В отличие от Oracle CDM стандарт ISO12207 равносильно ориентирован на организацию действий каждой из двух сторон: поставщик (разработчик) и покупатель (пользователь); может быть в равной степени применен, когда обе стороны - из одной организации.

В стандарте рассматриваются следующие этапы:

· Анализ.

· Проектирование.

· Реализация.

· Внедрение.

· Сопровождение.

Стандарт регламентирует архитектуру, процессы, разделы и подразделы ЖЦ ПС, а также перечень базовых работ и детализирует содержание каждой из них. Архитектура ЖЦ ПС в стандарте строится на трех крупных компонентах:

· основы жизненного цикла ПС и определяющие работы;

· процессы, поддерживающие жизненный цикл ПС;

· организация и управление жизненным циклом ПС.

В стандарте расшифровано свыше 220 работ и комментариев к ним. Стандарт состоит из 7 разделов и 4 приложений.

Стандарт принципиально не содержит конкретные методы действий, тем более - заготовки решений или документации. Он описывает архитектуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить услуги и задачи, включенные в процессы, не предназначен для предписывания имени, формата или точного содержимого получаемой документации. Решения такого типа принимаются использующим стандарт.

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

· рассматривается область применения системы для определения требований системы;

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

· квалификация требований системы должна быть документирована.

Далее, при выполнении анализа требований к ПО предусмотрено 11 классов характеристик качества, которые используются позже при гарантировании качества. При этом разработчик должен установить и документировать как требования к программному обеспечению:

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

б) внешние связи (интерфейсы) с единицей программного обеспечения;

в) требования квалификации;

г) спецификации надежности, включая спецификации, связанные с методами функционирования и сопровождения, воздействия окружающей среды и вероятностью травмы персонала;

д) спецификации защищенности, включая спецификации, связанные с компрометированием точности информации;

е) человеческие факторы спецификаций по инженерной психологии (эргономике), включая связанные с ручным управлением, взаимодействием человека и оборудования, ограничениями на персонал и областями, нуждающимися в концентрированном человеческом внимании, которые являются чувствительными к ошибкам человека и обучению;

ж) определение данных и требований базы данных;

з) установочные и приемочные требования поставляемого программного продукта в местах функционирования и сопровождения (эксплуатации);

и) документация пользователя;

к) работа пользователя и требования выполнения;

л) требования сервиса пользователя.

Стандарт не предписывает конкретную модель ЖЦ или метод разработки ПО, но определяет, что стороны-участники использования стандарта ответственны за выбор модели ЖЦ для проекта ПО, за адаптацию процессов и задач стандарта к этой модели, за выбор и применение методов разработки ПО, за выполнение действий и задач, подходящих для проекта ПО.

Вводные разделы (1-4)

· В первом разделе сформулированы цели стандарта, области его применения, подчеркнуты его гибкость и ограничения при использовании.

· Во втором приведены нормативные ссылки на некоторые общие стандарты, поддерживающие разработку и качество ПС и их компонентов, а также терминологию.

· В третьем даны основные термины.

· Общая структура пятого-седьмого разделов и их краткое содержание изложены в четвертом разделе.

Раздел 5

Основные этапы подготовки, эксплуатации и сопровождения ПС изложены в пятом разделе:

· Приобретение или подготовка к созданию ПС (подраздел 5.1) включает 23 вида работ и начинается с инициализации проекта, анализа концепции и рынка аналогичных продуктов, выработки требований и состава поддерживающих документов, создания предварительного плана действий. Далее анализируются предложения возможных исполнителей и подготавливается проект контракта. Организуется отслеживание проекта, его приемка и завершение.

· В подразделе 5.2. детализируются 23 процесса организации последующей подготовки к поставке ПС. Оцениваются отзывы фирм о проекте, заключается контракт, планируется ЖЦ, организуются поддержка разработки отчетами и обеспечение развития, а также процессы сдачи и завершения проекта.

· Основные 55 работ по созданию сложного комплекса программ представлены в подразделе 5.3. Подготовка проекта начинается с определения состава сопровождающих документов, выбора средств конфигурационного управления и обеспечения качества, а также выбора методов и средств технологического обеспечения всей ИС. Анализируются и формализуются функциональные, коммерческие, пользовательские, системные требования и критерии качества ПС: защищенность, интерфейсы с внешней средой, сопровождаемость и т. д. На этой базе проектируется архитектура всей ИС, выделяются и анализируются требования к программным средствам. При формировании характеристик качества ПС рекомендуется руководствоваться стандартом ISO 9126 и предложенной в нем номенклатурой показателей. Все эти работы отражаются в документах, на каждый компонент проекта отслеживается их взаимодействие и связи с внешней средой в ИС:

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

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

· Затем ПС необходимо подвергнуть квалификационному (аттестационному) тестированию по всем разделам требований, при широком варьировании тестов и значений критериев, а также протестировать адекватность программам и полноту технической и пользовательской документации.

· Проверенный таким образом комплекс программ интегрируется с вычислительными средствами ИС, средствами визуализации и телекоммуникации.

· После объединения всех средств ИС система подвергается квалификационному тестированию и испытаниям на всю совокупность требований к системе, а также производится оформление и проверка полного комплекта документации. При этом рекомендуется использовать методы и средства поддержки ЖЦ ПС, изложенные в шестом разделе.

· Далее следует создать план установки программного продукта в соответствии с контрактом и производить инсталляции, результаты которых документируются. Должна быть обеспечена поддержка разработчиком поставки ПС.

· Подраздел 5.4 состоит из 9 работ и посвящен поддержке эксплуатации. Подготовленный оператор должен освоить все процедуры применения ИС, в том числе тестирования ПС на соответствие критериям оперативного использования, указанным в документации. Поддержка пользователей подразумевает оказание помощи и консультационных услуг при обнаружении дефектов или ошибок при применении ПС в составе информационной системы. Эти работы взаимодействуют с описанными в подразделе 5.5, обеспечивающими сопровождение ПС (24 работы). Предполагается, что сопровождение может выполняться другими специалистами, не теми, кто создавал ПС на предыдущих этапах. Они анализируют сообщения об ошибках и предложения о модификации ПС, селектируют их на соответствие требованиям контракта и оценивают целесообразность проведения изменений. Подготовленные изменения тестируют и проверяют по критериям, определенным в документации. При подтверждении необходимости изменений в программах производится корректировка документации. Далее планируется распространение внесенных изменений или новой версии пользователям, которым была поставлена предшествующая версия. Рекомендуется учитывать возможность одновременного использования клиентами версий ПС с разным составом проведенных модификаций. Некоторые версии с определенной совокупностью изменений планируются для ликвидации.

Раздел 6

В разделе 6 представлено около 70 технологических работ, поддерживающих ЖЦ ПС:

· Процессы документирования ПС (6.1) охватывают планирование и регламентирование документирования, рекомендации по стандартизации, проектированию и разработке, а также по производству, конфигурационному управлению и сопровождению комплекта документации на ПС.

· Конфигурационное управление (6.2) включает план реализации версий как часть общего плана управления проектом, рекомендации по конфигурационной идентификации, контролю, учету, отчетности и развитию конфигурации.

· Обеспечение гарантий качества (6.3) включает использование планирования, методологии, процедур и стандартов качества в соответствии с контрактом и учетом доступных ресурсов. Рекомендуется обеспечивать качество конечного продукта в соответствии с документацией путем планирования и выполнения специальных работ в процессе всего ЖЦ ПС, а также на основе положений стандарта ISO 9001 (для сравнения см. п. 2.4.4).

· Верификация ПС (6.4) включает организацию, планирование и техническое обеспечение. Представлена структура контракта на верификацию, содержание процесса, состав требований, проектирование процесса верификации, обобщение и документирование результатов.

· Валидация (6.5) - удостоверение правильности (аттестация) - должна гарантировать полное соответствие спецификациям, требованиям и документации на ПС и возможность его безопасного и надежного применения пользователем. Рекомендуется ее выполнение независимыми специалистами путем тестирования во всех возможных ситуациях исходных данных. По существу, этот процесс аналогичен сертификации, которая в стандарте не упоминается.

· Управление проектом (6.6) подразумевает в основном подготовку и обеспечение планирования и управления ресурсами, персоналом, аппаратурой, программными средствами и инструментарием. Общий контроль проекта должен учитывать состояние доступных ресурсов и возможность изменения плана проектирования, а также систематические технические отчеты.

· Процессы ревизии - аудит (6.7) - служат для установления соответствия реальных работ и отчетов требованиям, планам и контракту. Ревизоры должны быть независимыми от проектировщиков ПС, они определяют состояние работ, использование ресурсов, соответствие документации спецификациям и стандартам, корректность тестирования.

· В процессе устранения дефектов и ошибок (6.8) решаются проблемы обеспечения последующего применения ПС и их функционирования. Каждый дефект или ошибка должны быть определены, идентифицированы, описаны, проанализированы и исправлены в процессе сопровождения в соответствии с контрактом.

Раздел 7

Раздел 7 посвящен процессам организации ЖЦ ПС (25 работ):

· Процессы управления (7.1) включают основные работы по управлению проектом, производством и средствами для обеспечения прикладных процессов по созданию, эксплуатации, сопровождению ПС и поддерживающим процессам. Они охватывают подготовку концепции управления, планирование, реализацию планов и контроль, отчетность и развитие проекта, а также его завершение.

· Процессы образования инфраструктуры (7.2) включают выбор и установление аппаратных и программных средств, технологии, стандартов и способов обслуживания, используемых для разработки, сопровождения и обеспечения эксплуатации ПС. Инфраструктура должна модифицироваться и сопровождаться в соответствии с изменениями требований к проекту и подлежит конфигурационному управлению.

· Совершенствование ЖЦ ПС (7.3) подразумевает установление, оценку, измерение, контроль и корректировку процессов ЖЦ. Оно должно учитывать требования пользователей и развитие определенной технологии.

· Процессы обучения (7.4) определяются требованиями к проекту, должны учитывать необходимые ресурсы, управление и технические средства. Необходимо разработать и представить пользователю материалы, облегчающие обучение по соответствующему плану.

Приложения

В приложении А (нормативное) изложены основы преобразования и обобщения базовой структуры этого международного стандарта для конкретного проекта. Следует подчеркнуть необходимость реализации двух важнейших вариантов адаптации положений и рекомендаций стандарта: на особенности создания потенциально мобильных ПС и на особенности ПС с использованием мобильных компонентов.

Приложение В (информационное) содержит руководство по процессам адаптации и преобразования ЖЦ ПС для конкретного проекта, а также рекомендации по возможным изменениям ряда работ из разделов 5 и 6 стандарта в зависимости от характеристик объекта.