Стандарт iso iec 12207 определяет. Техническая документация. Проведение приемочных испытаний

Стандарт ISO/IEC 12207-95 определяет стратегию и общий порядок в создании и эксплуатации ПО, он охватывает ЖЦ ПО от концептуализации идей до завершения ЖЦ (жизненного цикла).

Особенности стандарта

Стандарт не предписывает конкретную модель ЖЦ или метод разработки ПО; Он определяет, что стороны-участники использования стандарта ответственны=

1. за выбор модели ЖЦ для проекта ПО,
2. за адаптацию процессов и задач стандарта к этой модели,
3. за выбор и применение методов разработки ПО,
4. за выполнение действий и задач, подходящих для проекта ПО;

Стандарт ISO/IEC 12207-95 равносильно ориентирован на организацию действий каждой из двух сторон: поставщик (разработчик) и покупатель (пользователь); может быть в равной степени применен, когда обе стороны - из одной организации.

Определения стандарта

Система - это объединение одного или более процессов, аппаратных средств, программного обеспечения, оборудования и людей для обеспечения возможности удовлетворения определенных потребностей или целей.

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

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

Стандарт определяет общую структуру жизненного цикла ПО в виде 3-х ступенчатой модели, состоящей из:

1. · процессов,
2. · видов деятельности,
3. · задач

Стандарт не определяет метрики , по которым можно было бы отслеживать ход работ и их результативность. Самыми крупными элементами являются процессы жизненного цикла ПО . Всего выделено 18 процессов, которые объединены в 3 группы:

1. -основные процессы;
2. -поддерживающие процессы;
3. -организационные процессы;
4. -процесс адаптации.

Основные процессы ЖЦ

1) Процесс приобретения - его задача - определить действия предприятия-покупателя, которое приобретает автоматизированную систему, программный продукт или сервис ПО:

1. · инициация приобретения;
2. · подготовка запроса предложений;
3. · подготовка контракта;
4. · анализ поставщиков;
5. · получение ПО.

2) Процесс передачи (поставки) определяет действия предприятия-поставщика, которое снабжает покупателя системой, программным продуктом или сервисом ПО.

3) Процесс разработки - его задача - определить действия предприятия-разработчика, которое создает программный продукт.
Включает следующие работы:

1. · развертывание процесса разработки;
2. · анализ системных требований;
3. · проектирование (программно-аппаратной) системы в целом;
4. · анализ требований к ПО;
5. · проектирование архитектуры ПО;
6. · детальное проектирование;
7. · кодирование;
8. · отладочное тестирование;
9. · интеграцию ПО;
10. · квалификационное тестирование ПО;
11. · системную интеграцию;
12. · квалификационное тестирование системы;
13. · развертывание (установку или инсталляцию) ПО.

4) Процесс эксплуатации определяет действия предприятия-оператора, которое обеспечивает обслуживание системы в процессе ее функционирования в интересах пользователей. Включает такие работы, как:

1. · консультирование пользователей;
2. · получение обратной связи и др.

5) Процесс поддержки ПО определяет действия персонала сопровождения, который обеспечивает:

1. · инсталляцию и удаление программного изделия на вычислительной системе;
2. · анализ возникающих проблем;
3. · внесение изменений;
4. · экспертизу и передачу измененного ПО;
5. · перенос ПО с одной платформы на другую;
6. · изъятие ПО из эксплуатации.

В России в настоящее время используется стандарт ГОСТ Р ИСО/МЭК 12207-2010 Процессы жизненного цикла программных средств(ISO/IEC 12207:2008 System and software engineering - Software life cycle processes)

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

Общая структура – см. самостоятельно!

Особенности:

Стандарт ISO состоит из очень крупных обобщенных процессов: "приобретение", "поставка", "разработка" и т. п. Грубо говоря, один такой процесс сравним со всеми процессами CDM вместе взятыми.Каждый процесс разделен на набор действий, каждое действие - на набор задач. Очень важное отличие ISO: каждый процесс, действие или задача инициируется и выполняется другим процессом по мере необходимости, причем нет заранее определенных последовательностей (естественно, при сохранении логики связей по исходным сведениям задач и т. п.).

- «Динамический» характер стандарта определяется способом определения последовательности выполнения процессов и задач, при котором один процесс при необходимости вызывает другой или его часть. Такой характер позволяет реализовывать любую модель ЖЦ.

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

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

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

Степень обязательности: после решения организации о применении ISO12207 в качестве условия торговых отношений является ее ответственность за указание минимального набора требуемых процессов и задач, которые составляют согласованность с этим стандартом.

МОДЕЛЬ SEI SW-CMM

Методология CMM разрабатывалась и развивалась в США как средство, позволяющее выбирать лучших производителей ПО для выполнения госзаказов.

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

СММ – стандарт де-факто.

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

Для оценки степени готовности предприятия разрабатывать качественный программный продукт СММ вводит ключевое понятие зрелость организации (Maturity ).

СММ определяет 5 уровней технологической зрелости компании:

1. Уровень 1 , начальный - организации, разрабатывающие ПО, но не имеющие осознанного процесса разработки, не производящие планирования и оценок своих возможностей;

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

3. Уровень 3 , определенный - в таких организациях имеется принятый, полностью документированный, соответствующий реальному положению дел и доступный персоналу процесс разработки и сопровождения ПО. Этот процесс должен включать как управленческие, так и технические подпроцессы, а также обучение сотрудников работе с ним;

4. Уровень 4 , управляемый - в этих организациях, помимо установленного и описанного процесса, используются измеримые показатели качества продуктов и результативности процессов, которые позволяют достаточно точно предсказывать объем ресурсов (времени, денег, персонала), необходимый для разработки продукта с определенным качеством);

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

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

1) Позволяет реализовать любую модель ЖЦ - это возможно, т.к. стандарт предлагает способ определения последовательности выполнения процессов и задач, при котором один процесс может вызывать другой процесс или его части.

2) Обеспечивает максимальную степень адаптивности – множество процессов и задач сконструировано так, что возможна их адаптация в соответствии с конкретными проектами ИС. Адаптация сводится к исключению процессов, видов деятельности и задач, которые не применяются в конкретном проекте.

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

4) Стандарт содержит предельно мало описаний, касающихся проектирования БД - это оправдано, т.к. разные ИС и разные программные комплексы могут не только использовать специфические типы БД, но и вообще не использовать БД.

5) Ценность стандарта в том, что он содержит наборы задач, характеристик качества, критериев оценки и т.д. , дающие всесторонний охват проектных решений.

6) Хотя стандарт не предписывает использовать конкретную модель ЖЦ или метод разработки, он определяет, что стороны участники проекта несут ответственность за следующие моменты:

выбор модели ЖЦ для разрабатываемого проекта;

адаптация процессов и задач стандарта к выбранной модели;

выбор и применение методов разработки ПО;

выполнение действий и задач, подходящих для данного проекта ПО.

Стандарты комплекса гост 34.

Задумывался как всеобъемлющий комплекс взаимоувязанных межотраслевых документов.

Объекты стандартизации : автоматизированные системы различных видов и все виды их компонентов.

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

Согласно ГОСТу разработка автоматизированной системы разбивается на следующие этапы и стадии:

1 этап формирования требований к АС :

Стадия а: обследование объекта и обоснование необходимости разработки автоматизированной системы;

Стадия б: формирование требований заказчика к автоматизированной системе;

Стадия в: разработка отчета о проделанной работе и подготовка заявки на разработку технического задания.

2 этап разработки концепции :

а: изучение объекта;

б: проведение необходимых НИР;

в: разработка вариантов концепции АС, удовлетворяющей требованиям заказчика;

г: разработка отчета о проделанной работе.

3 этап разработки и утверждения технического задания на создание АС .

4 этап разработки эскизного проекта АС :

а: разработка предварительных проектных решений по всей системе в целом и по её отдельным компонентам;

б: разработка документации.

5 этап разработки технического проекта :

а: разработка проектных решений по всей системе и по её частям;

б: разработка документации на автоматизированную систему и подсистемы, входящие в её состав;

в: разработка и оформление документации на поставку изделий для комплектования АС или разработка и оформление технических требований на разработку этих изделий.

6 этап разработки технической документации :

а: разработка рабочей документации на систему её части;

б: разработка или адаптация ПО.

7 этап ввода разработанной системы в действие :

а: подготовка объекта автоматизации к внедрению АС;

б: подготовка персонала;

в: комплектации АС программными и техническими средствами;

г: монтажные работы;

д: пуско-наладочные работы;

е: предварительные испытания;

ж: опытная эксплуатация;

з: приемочные испытания.

8 этап сопровождения :

а: выполнение работ в соответствие с гарантийными обязательствами;

б: послегарантийное обслуживание.

Жизненный цикл программного обеспечения (ПО) - период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации . Этот цикл - процесс построения и развития ПО.

Стандарты жизненного цикла ПО

· ГОСТ 34.601-90

· ISO/IEC 12207:1995 (российский аналог - ГОСТ Р ИСО/МЭК 12207-99)

Стандарт ГОСТ 34.601-90

Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы:

Формирование требований к АС

1. Обследование объекта и обоснование необходимости создания АС

2. Формирование требований пользователя к АС

3. Оформление отчета о выполнении работ и заявки на разработку АС

Разработка концепции АС

1. Изучение объекта

2. Проведение необходимых научно-исследовательских работ

3. Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователей

4. Оформление отчета о проделанной работе

Техническое задание

1. Разработка и утверждение технического задания на создание АС

Эскизный проект

1. Разработка предварительных проектных решений по системе и ее частям

Технический проект

1. Разработка проектных решений по системе и ее частям

2. Разработка документации на АС и ее части

3. Разработка и оформление документации на поставку комплектующих изделий

4. Разработка заданий на проектирование в смежных частях проекта

Рабочая документация

1. Разработка рабочей документации на АС и ее части

2. Разработка и адаптация программ

Ввод в действие

1. Подготовка объекта автоматизации

2. Подготовка персонала

3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)

4. Строительно-монтажные работы

5. Пусконаладочные работы

6. Проведение предварительных испытаний

7. Проведение опытной эксплуатации

Проведение приемочных испытаний

8. Сопровождение АС.

1. Выполнение работ в соответствии с гарантийными обязательствами

2. Послегарантийное обслуживание

Эскизный, технический проекты и рабочая документация - это последовательное построение все более точных проектных решений. Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в «Технорабочий проект», параллельно выполнять различные этапы и работы, включать дополнительные.

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

Стандарт ГОСТ Р ИСО/МЭК 12207 (ISO/IEC 12207)

Федеральным агентством по техническому регулированию и метрологии РФ 01.03.2012 г. взамен ГОСТ Р ИСО/МЭК 12207-99 принят стандарт ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств», идентичный международному стандарту ISO/IEC 12207:2008 «System and software engineering - Software life cycle processes».

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

Базовая линия (baseline) по ГОСТ Р ИСО/МЭК 12207-2010

или, которые были официально рассмотрены и с тем, чтобы впоследствии служить основой для дальнейшего, и которые могут быть изменены только посредством официальных и контролируемых изменения [из п. 4.6 ГОСТ Р ИСО/МЭК 12207-2010]

Валидация (validation) по ГОСТ Р ИСО/МЭК 12207-2010

Подтверждение (на основе представления объективных свидетельств) того, что, предназначенные для конкретного или применения, выполнены. Примечание - Валидация в контексте представляет собой совокупность действий, гарантирующих и обеспечивающих уверенность в том, что способна реализовать свое предназначение, текущие и перспективные [из п. 4.54 ГОСТ Р ИСО/МЭК 12207-2010]

Верификация (verification) по ГОСТ Р ИСО/МЭК 12207-2010

Подтверждение (на основе представления объективных свидетельств) того, что заданные полностью выполнены. Примечание - Верификация в контексте представляет собой совокупность действий по сравнению полученного результата жизненного цикла с требуемыми характеристиками для этого результата. Результатами жизненного цикла могут являться (но не ограничиваться ими) заданные требования, описание и непосредственно [из п. 4.55 ГОСТ Р ИСО/МЭК 12207-2010]

Гарантия качества (quality assurance) по ГОСТ Р ИСО/МЭК 12207-2010

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

1. Существуют как внутренние, так и внешние гарантии качества:
   1. внутренняя гарантия качества: в пределах гарантия качества обеспечивает уверенность;
   2. внешняя гарантия качества: в контрактных ситуациях гарантия качества обеспечивает уверенность или другим.
2. Некоторые действия по и гарантии качества взаимосвязаны.
3. До тех пор, пока требования к качеству полностью не удовлетворяют потребностям, гарантия качества не может обеспечить необходимой уверенности.

[из п. 4.34 ГОСТ Р ИСО/МЭК 12207-2010]