Первая редакция ISO 12207 была подготовлена в 1995 г. объединенным техническим комитетом ISO/IEC JTC1 «Информационные технологии, подкомитет SC7, проектирование программного обеспечения».

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

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

примечание

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

Общая структура

В стандарте ISO 12207 не предусмотрено каких-либо этапов (фаз или стадий) жизненного цикла информационной системы. Данный стандарт определяет лишь ряд процессов, причем по сравнению с Oracle CDM стандарт ISO 12207 состоит из гораздо более крупных обобщенных процессов: приобретение, поставка, разработка и т. п. Несколько утрируя, можно сказать, что один процесс ISO 12207 сопоставим со всеми процессами Oracle CDM вместе взятыми.

Согласно ISO 12207, каждый процесс подразделяется на ряд действий, а каждое действие — на ряд задач.

Очень важной особенностью ISO 12207 по сравнению с CDM является то, что каждый процесс, действие или задача инициируются и выполняются другим процессом по мере необходимости, причем нет заранее определенных последовательностей (естественно, при сохранении логики связей по исходным сведениям задач и т. п.).

Основные и вспомогательные процессы жизненного цикла.

В стандарте ISO 12207 описаны пять основных процессов жизненного цикла программного обеспечения:

·  процесс приобретения определяет действия предприятия-покупателя, которое приобретает информационную систему, программный продукт или службу программного обеспечения;

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

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

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

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

Кроме основных, стандарт 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 классов характеристик качества, которые используются позже при обеспечении качества.

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

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

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

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

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

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

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

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

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

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

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

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

примечание

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

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

·  выбор модели жизненного цикла для разрабатываемого проекта;

·  адаптацию процессов и задач стандарта к этой модели;

·  выбор и применение методов разработки программного обеспечения;

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

Стандарты комплекса ГОСТ 34

ГОСТ 34 задумывался в конце 80-х годов как всеобъемлющий комплекс взаимосвязанных межотраслевых документов. Объектами стандартизации являются автоматизированные системы различных видов и все виды их компонентов, а не только программное обеспечение и базы данных.

Комплекс рассчитан на взаимодействие заказчика и разработчика. Аналогично ISO 12207, в нем предусмотрено, что заказчик может разрабатывать автоматизированную систему для себя сам (например, создав для этого специализированное подразделение). Однако формулировки ГОСТ 34 не ориентированы на столь явное и в известном смысле симметричное отражение действий обеих сторон, как это сделано в ISO 12207. Поскольку ГОСТ 34 в основном уделяет внимание содержанию проектных документов, распределение действий между сторонами обычно производится исходя из этого содержания.

Общая структура

Из всех существующих групп документов будем основываться только на группе 0 "Общие положения" и группе 6 «Создание, функционирование и развитие автоматизированной системы». Наиболее популярными можно считать стандарты ГОСТ 34.601-90 (стадии создания автоматизированной системы), ГОСТ 34.602-89 (техническое задание на создание автоматизированной системы) и методические указания РД 50-34.698-90 (требования к содержанию документов). Стандарты предусматривают стадии и этапы выполнения работ по созданию автоматизированной системы, но не предусматривают сквозных процессов в явном виде.

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

·  Этап формирования требований к автоматизированной системе. Состоит из следующих стадий:

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

o  формирование требований заказчика к автоматизированной системе;

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

·  Разработка концепции:

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

o  проведение необходимых научно-исследовательских работ;

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

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

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

·  Разработка эскизного проекта автоматизированной системы:

o  разработка предварительных проектных решений по всей системе в целом и по ее отдельным составляющим;

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

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

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

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

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

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

·  Разработка технической документации:

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

o  разработка и/или адаптация программного обеспечения.

·  Ввод разработанной системы в действие:

o  подготовка объекта автоматизации;

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

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

o  монтажные работы;

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

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

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

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

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

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

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

В ГОСТ 34 приводится описание содержания документов, разрабатываемых на каждом из этапов.

Особенности

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

·  Основной целью разработки комплекса нормативных документов ГОСТ 34 было разрешение противоречий, возникающих при интеграции систем вследствие несогласованности нормативно-технической документации. Комплекс стандартов ГОСТ 34 более близок к схемам конкретных методик, чем к стандартам типа ISO 12207.

·  Степень адаптивности стандарта ГОСТ 34 определяется следующими возможностями:

o  возможностью отказаться от этапа эскизного проектирования и объединять

o  этапы разработки технического проекта и рабочей документации;

o  возможностью отказываться от некоторых стадий разработки, а также объединять большинство документов и их разделов;

o  возможностью вводить дополнительные документы, разделы документов и работы;

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

o  Стадии и этапы, выполняемые организациями — участниками работ по созданию автоматизированной системы, устанавливаются в договорах и техничес­ком задании, что близко к подходу ISO 12207.

·  Несмотря на достаточно большую гибкость формирования жизненного цикла, предопределенные документами ГОСТ 34 этапы и стадии разработки на практике ориентируют разработчиков на каскадную схему жизненного цикла.

·  Документы ГОСТ 34 определяют единую терминологию и вполне разумно классифицируют работы по созданию автоматизированной системы и документы, разрабатываемые в результате этих работ. Благодаря ГОСТ 34 упрощается интеграция разных систем и повышается качество систем, полученных в результате интеграции.

·  Обеспечение качества согласно ГОСТ 34 определяется в техническом задании на автоматизированную систему и производится на любых последующих этапах и с любой степенью независимости экспертизы. В последовательности этапов разработки эти экспертизы располагаются несколько позже, чем в ISO 12207.

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

·  Ключевым документом взаимодействия сторон является техническое задание (ТЗ) на создание автоматизированной системы. ТЗ является основным исходным документом для создания автоматизированной системы нее приемки, оно определяет важнейшие точки взаимодействия заказчика и разработчика.

Примечание

Техническое Задание Разрабатывается Организацией-Разработчиком (По Гост 34.602-89); Но Формально Техническое Задание Выдает Разработчику Заказчик (По Рд ).

Согласно ГОСТ 34, автоматизированная система состоит из программно-технических, программно-методических комплексов и отдельных компонентов организационного, технического, программного и информационного обеспечения. Документы комплекса ГОСТ 34 определяют автоматизированную систему следующим образом:

    «организационно-техническая система, обеспечивающая выработку решений на основе автоматизации информационных процессов в различных сферах деятельности (управление, проектирование, производство и т. д.) или их сочетаниях» - РД ; «система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций» - ГОСТ 34.003-90.

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

Выводы

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

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

·  ГОСТ 34 достаточно полно и фундаментально определяет.

ü  систему как объект создания или развития;

ü  аналитические и при необходимости исследовательские работы, направленные на разработку обоснованной концепции автоматизированной системы;

ü  виды обеспечения системы, которые, в общем, согласуются с требованиями ISO 12207 к системе и программному обеспечению.

Материалы ГОСТ 34 почти так же, как и ISO 12207, а может быть, еще более четко определяют, что автоматизированная система — это в первую очередь люди, которые выполняют свои функции с помощью информационных техно­логий.

·  ГОСТ 34 благодаря своей комплексной ориентации на систему и обеспечению единой терминологии позволяет избежать ситуаций, в которых разработчики разных профессий (например, финансовые аналитики и проектировщики баз данных) «говорят на разных языках», от чего в итоге страдают цельность и глубина проработки проекта.

·  ГОСТ-34 и CDM в первую очередь ориентированы на действия по созданию и поддержке систем ISO 12207 — на приобретение и эксплуатацию систем (при этом разработка является процессом, логически вытекающим из приобретения).

Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6