Вендров А.М. Проектирование программного обеспечения экономических информационных систем

Подождите немного. Документ загружается.

Жизненный цикл программного обеспечения 51

эксплуатация или сопровождение). Данный процесс может

включать анализ, оценку

тестирование.

Верификация может проводиться с различными степенями

независимости. Степень независимости может варьироваться от

выполнения верификации самим исполнителем или другим спе-

циалистом данной организации до ее выполнения специалистом

другой организации

различными вариациями. Если процесс ве-

рификации осуществляется организацией, не зависящей от пос-

тавщика, разработчика, оператора или службы сопровождения,

то он называется

процессом независимой

верификации.

Процесс верификации включает следующие действия:

1) подготовительную работу;

2) верификацию.

процессе верификации проверяются следующие условия:

• непротиворечивость требований к системе и степень учета

потребностей пользователей;

• возможности поставщика выполнить заданные требования;

• соответствие выбранных процессов ЖЦ ПО условиям дого-

вора;

• адекватность стандартов, процедур и среды разработки про-

цессам ЖЦ ПО;

• соответствие проектных спецификаций ПО заданным тре-

бованиям;

• корректность описания в проектных спецификациях вход-

ных и выходных данных, последовательности событий,

интерфейсов, логики и т.д.;

• соответствие кода проектным спецификациям и требовани-

ям;

• тестируемость

корректность кода,

его

соответствие приня-

тым стандартам кодирования;

• корректность интеграции компонентов ПО в систему;

• адекватность, полнота и непротиворечивость документа-

ции.

Процесс аттестации (validation

process) предусматривает

определение полноты соответствия заданных требований и соз-

данной системы или программного продукта их конкретному

функциональному назначению. Под

аттестацией

обычно пони-

мается подтверждение и оценка достоверности проведенного

тестирования ПО. Аттестация должна гарантировать полное со-

ответствие ПО спецификациям, требованиям и документации, а

52 Глава 1

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

пользователем. Аттестацию рекомендуется выполнять путем тес-

тирования во

всех

возможных ситуациях

использовать при этом

независимых специалистов. Аттестация может проводиться на

начальных стадиях

ЖЦ

ПО или как

часть

работы по приемке ПО.

Аттестация, так же как и верификация, может осуществлять-

ся с различными степенями независимости. Если процесс аттес-

тации выполняется организацией, не зависящей от поставщика,

разработчика, оператора или службы сопровождения, то он на-

зывается

процессом независимой

аттестации.

Процесс аттестации включает следующие действия:

1) подготовительную работу;

2) аттестацию.

Процесс совместной оценки Qoint review process)

предназначен

для оценки состояния работ по проекту и ПО, создаваемому при

выполнении данных работ (действий). Он сосредоточен в основ-

ном на контроле планирования и управления ресурсами, персо-

налом, аппаратурой и инструментальными средствами проекта.

Оценка применяется как на уровне управления проектом, так

и на уровне технической реализации проекта и проводится в те-

чение всего срока действия

договора.

Данный процесс может вы-

полняться двумя любыми сторонами, участвующими

договоре,

при этом одна сторона проверяет

другую.

Процесс совместной оценки включает следующие действия:

1) подготовительную работу;

2) оценку управления проектом;

3) техническую оценку.

Процесс аудита (audit process)

представляет собой определе-

ние соответствия требованиям, планам и условиям договора. Ау-

дит может выполняться двумя любыми сторонами, участвующи-

ми

договоре, когда одна сторона проверяет

другую.

Аудит

- это ревизия (проверка), проводимая компетентным

органом (лицом) в целях обеспечения независимой оценки сте-

пени соответствия ПО или процессов установленным требовани-

ям.

Аудит служит для установления соответствия реальных работ

и отчетов требованиям, планам и контракту. Аудиторы (ревизо-

ры)

не

должны иметь прямой зависимости от разработчиков ПО.

Они определяют состояние работ, использование ресурсов, соот-

ветствие документации спецификациям и стандартам, коррект-

ность тестирования.

Жизненный цикл программного обеспечения 53

Процесс аудита включает следующие действия:

подготовительную работу;

аудит.

Процесс

разрешения проблем (problem

resolution

process)

предус-

матривает анализ и решение проблем (включая обнаруженные

несоответствия), независимо от их происхождения или источни-

ка, которые обнаружены в ходе разработки, эксплуатации, соп-

ровождения или других процессов. Каждая обнаруженная проб-

лема должна быть идентифицирована, описана, проанализиро-

вана и разрешена.

Процесс разрешения проблем включает следующие действия:

1) подготовительную работу;

2) разрешение проблем.

1.2.3.

ОРГАНИЗАЦИОННЫЕ ПРОЦЕССЫ

ЖИЗНЕННОГО ЦИКЛА ПО

Процесс

управления (managementprocess)

состоит

из

действий и

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

щей своими процессами. Данная сторона (менеджер) отвечает за

управление выпуском продукта, управление проектом

задачами

соответствующих процессов, таких, как приобретение, поставка,

разработка, эксплуатация, сопровождение

др.

Процесс управления включает следующие действия:

1) инициирование и определение области управления;

2) планирование;

3) выполнение и контроль;

4) проверку и оценку;

5) завершение.

При

инициировании

менеджер должен убедиться, что необхо-

димые для управления ресурсы (персонал, оборудование и техно-

логия) имеются в его распоряжении

достаточном количестве.

Планирование

подразумевает выполнение, как минимум, сле-

дующих задач:

• составление графиков выполнения работ;

• оценку затрат;

• вьщеление требуемых ресурсов;

• распределение ответственности;

• оценку

рисков,

связанных с конкретными задачами;

• создание инфраструктуры управления.

54 Глава 1

Процесс создания инфраструктуры

(infrastructure process) охва-

тывает выбор и поддержку (сопровождение) технологии, стан-

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

ных и профаммных средств, используемых для разработки,

эксплуатации или сопровождения ПО. Инфраструктура должна

модифицироваться и сопровождаться в соответствии с измене-

ниями требований к соответствующим процессам. Инфраструк-

тура, в свою очередь, является одним из объектов управления

конфигурацией.

Процесс создания инфраструктуры включает следующие

действия:

1) подготовительную работу;

2) создание инфраструктуры;

3) сопровождение инфраструктуры.

Процесс усовершенствования (improvement process)

предусмат-

ривает оценку, измерение, контроль и усовершенствование про-

цессов ЖЦ ПО. Данный процесс включает следующие действия:

1) создание процесса;

2) оценку процесса;

3) усовершенствование процесса.

Усовершенствование процессов ЖЦ ПО направлено на повы-

шение производительности труда всех участвующих в них специ-

алистов за счет совершенствования используемой технологии,

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

ния персонала. Усовершенствование основано на анализе досто-

инств и недостатков каждого процесса. Такому анализу в боль-

шой степени способствует накопление в организации историчес-

кой, технической, экономической и иной информации по реали-

зованным проектам.

Процесс обучения

(training process) охватывает первоначальное

обучение и последующее постоянное повышение квалификации

персонала. Приобретение, поставка, разработка, эксплуатация и

сопровождение ПО в значительной степени зависят от уровня

знаний и квалификации персонала. Например, разработчики ПО

должны пройти необходимое обучение методам и средствам прог-

раммной инженерии. Содержание процесса обучения определя-

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

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

работаны и представлены методические материалы, необходимые

для обучения пользователей в соответствии с учебным планом.

Жизненный цикл программного обеспечения 55

Процесс обучения включает следующие действия:

1) подготовительную работу;

2) разработку учебных материалов;

3) реализацию плана обучения.

1.2.4.

ВЗАИМОСВЯЗЬ МЕЖДУ ПРОЦЕССАМИ ЖЦ ПО

Процессы ЖЦ ПО, регламентируемые стандартом ISO/IEC

12207,

могут использоваться различными организациями в конк-

ретных проектах самым различным образом. Тем не менее, стан-

дарт предлагает некоторый базовый набор взаимосвязей между

процессами с различных точек зрения (или в различных аспек-

тах),

который показан на

рис.

1.2. Такими аспектами являются:

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

2) аспект управления;

3) аспект эксплуатации;

4) инженерный аспект;

5) аспект поддержки.

В договорном аспекте

заказчик и поставщик вступают в дого-

ворные отношения

реализуют соответственно процессы приоб-

ретения и поставки. В

аспекте управления

заказчик, поставщик,

разработчик, оператор, служба сопровождения и другие участву-

ющие в ЖЦ ПО стороны управляют выполнением своих процес-

сов.

В аспекте эксплуатации

оператор, эксплуатирующий систе-

му, предоставляет необходимые услуги пользователям. В

инже-

нерном аспекте

разработчик или служба сопровождения решают

соответствующие технические задачи, разрабатывая или моди-

фицируя программные продукты. В

аспекте поддержки

службы,

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

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

рамках ас-

пекта поддержки можно вьщелить аспект управления качеством

ПО,

включающий пять процессов: обеспечение качества, вери-

фикация, аттестация, совместная оценка и аудит. Организацион-

ные процессы, показанные в нижней части

рис.

1.2, выполняют-

ся на корпоративном уровне или на уровне всей организации в

целом, создавая базу для реализации и постоянного совершен-

ствования остальных процессов ЖЦ ПО.

Процессы

реализующие их организации (или стороны) свя-

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

Глава 1

^Договор.

Приоб-

..J

ретение *^ ^

Пос-

тавка

^w^*^

Управление

Эксплуатация

Солро>

вождение

Разра-

ботка

Вспомогательные процессы

Документирование

Управление конфигурацией

Разрешение проблем

Обеспечение качества

Верификация Аттестация

Совместная оценка Аудит

Договорный

аспект /Заказчик

Постав-

щик

Аспект у^ ^ч.

управления^ \

!• Ы Менеджер 1

Аспект

эксплуатации^

шератор

Пользо-

ватель

Инженерный^

аспект^

Разработчик

Служба

«усопровождения/

Аспект

поддержки

Исполнитель^

|^>>( вспомогательных;

процессов

Организационные процессы

Создание инфраструктуры

Усовершенствование

Обучение

Рис.

1.2. Связи между процессами жизненного цикла ПО

Жизненный цикл программного обеспечения 57

структура и статус организаций никак не регламентируются. Од-

на и та же организация может выполнять различные роли: пос-

тавщика, разработчика и другие, и наоборот, одна и та же роль

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

Взаимосвязи между процессами, описанные в стандарте, но-

сят статический характер. Более важные динамические связи

между процессами и реализующими их сторонами устанавлива-

ются в реальных проектах. Соотношение процессов ЖЦ ПО и

стадий ЖЦ, характеризующих временной аспект ЖЦ системы,

рассматривается в рамках модели ЖЦ ПО.

Значение данного стандарта трудно переоценить, поскольку

он формирует подход к выбору

оценке всех современных

техно-

логий и процессов создания и сопровождения ПО. Безусловно,

на выбор конкретной технологии в проекте влияет целый ряд

факторов, но принципы реализации и состав процессов ЖЦ ПО

остаются стабильными. Большинство технологий, поставляемых

ведущими производителями (IBM, Oracle, Microsoft и др.), соот-

ветствуют требованиям этого стандарта. Анализ различных тех-

нологий показывает, что общие принципы описания процессов

ЖЦ ПО в стандарте ISO 12207 прошли практическую апробацию

и стали общепризнанными.

1.3.

МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА ПО

Под моделью жизненного цикла ПО

понимается структура, оп-

ределяющая последовательность выполнения и взаимосвязи

процессов, действий и задач на протяжении ЖЦ. Модель ЖЦ за-

висит от специфики, масштаба и сложности проекта и специфи-

ки условий, в которых система создается и функционирует.

Стандарт ГОСТ Р ИСО/МЭК 12207-99 не предлагает конк-

ретную модель ЖЦ ПО. Его положения являются общими для

любых моделей ЖЦ, методов

технологий создания ПО. Он опи-

сывает структуру процессов ЖЦ ПО, не конкретизируя

деталях,

как реализовать или выполнить действия и задачи, включенные в

эти процессы.

Модель ЖЦ ПО включает

себя:

стадии;

2) результаты выполнения работ на каждой стадии;

3) ключевые события

—

точки завершения работ и принятия

решений.

Глава 1

Модель ЖЦ любого

конкретного

ПО

определяет

характер

про-

цесса его

создания^

который представляет собой совокупность упо-

рядоченных

во

времени, взаимосвязанных

объединенных

ста-

дии

работ,

выполнение которых необходимо

достаточно

для

соз-

дания ПО, соответствующего заданным требованиям. Под

стади-

ей

понимается часть процесса создания ПО, ограниченная опре-

деленными временными рамками и заканчивающаяся выпуском

конкретного продукта (моделей, профаммных компонентов, до-

кументации), определяемого заданными для данной стадии тре-

бованиями. Стадии процесса создания ПО вьщеляются по сооб-

ражениям рационального планирования и организации работ, за-

канчивающихся заданными результатами. Конкретный состав

стадий ЖЦ ПО определяется используемой технологией создания

ПО и соответствующими технологическими стандартами. Табл.

1.1 характеризует подходы к составу и наименованию стадий, ис-

пользуемые в некоторых технологиях

стандартах.

Таблица 1.1

Различные подходы

составу

наименованию стадий

ГОСТ 34

Формирование

требований к

АС.

Разработка кон-

цепции АС.

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

ние

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

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

ект

Рабочая докумен-

тация

Ввод

действие.

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

АС

Барри

У.

Боэм^

Анализ осущест-

вимости системы.

Планирование и

анализ требова-

ний к ПО

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

изделия.

Детальное проек-

тирование

Кодирование

Внедрение.

Функционирова-

ние (эксплуата-

ция) и сопровож-

дение

Oracle CDM

Стратегия.

Анализ

Проектирова-

ние

Реализация

Внедрение.

Эксплуатация

и сопровожде-

ние

Rational Unified

Process

Начальная ста-

дия (Inception)

Разработка

(Elaboration)

Конструирова-

ние

(Construction) 1

Ввод в

действие

(Transition)

^ Боэм Б. У. Инженерное проектирование программного обеспечения:

Пер.

с англ.

—

М.: Радио и связь, 1985.

Жизненный цикл программного обеспечения 59

Как видно из

табл.

1.1,

наименования стадий в различных

подходах

во

многом схожи и не отражают их внутреннее содержа-

ние,

которое полностью определяется используемой моделью

жцпо.

На каждой стадии могут выполняться несколько процессов,

определенных

стандарте ГОСТ Р ИСО/МЭК 12207-99,

наобо-

рот, один

тот

же

процесс может выполняться на различных ста-

диях. Соотношение между процессами и стадиями также опреде-

ляется используемой моделью ЖЦ ПО.

мировой практике не существует международного стандар-

та, регламентирующего различные модели ЖЦ, однако существу-

ет ряд различных подходов к их классификации. Наибольшее

распространение в этих классификациях получили две модели

ЖЦ: каскадная и итерационная.

Крайним случаем модели ЖЦ можно считать так называемую

модель «черного ящика» (black box), или «code and

fix»

(кодиро-

вание и исправление), что фактически означает отсутствие ка-

кой-либо модели (рис. 1.3). В этом случае выделить какие-либо

рациональные стадии в процессе разработки ПО не представля-

ется возможным, поскольку отсутствует планирование и органи-

зации работ.

Спецификации

системы

Разработка

ПО

^ Программный

продукт

Рис.

1.3. Модель «черного ящика»

Профаммистский фольклор, тем не менее, вьщеляет в такой

модели следующие стадии:

• начало проекта;

• безудержный энтузиазм;

• разочарование;

• хаос;

• поиски виновных;

• наказание невиновных;

• награждение непричастных;

• определение требований к системе.

60 Глава 1

1.3.1.

КАСКАДНАЯ МОДЕЛЬ ЖЦ

1970

г.

эксперт

области ПО Уинстон Ройс опубликовал по-

лучившую широкую известность статью, в которой он излагал

свое мнение о методике, которая позднее получила название

«модель водопада» (waterfall model), или «каскадная модель» (рис.

1.4). Эта модель была разработана с учетом ограничений «тяже-

лых» процессов, налагавшихся на разработчиков государствен-

ными контрактами того времени. Многие ошибочно полагают,

что

своей статье Ройс выступил

защиту однопроходной после-

довательной схемы. На самом же деле он рекомендовал подход,

несколько отличный от

того,

который в конечном итоге вылился

в концепцию «водопада» с ее строгой последовательностью ста-

дий анализа требований, проектирования и разработки. Впосле-

дствии эта модель была регламентирована множеством норма-

тивных документов, в частности, широко известным стандартом

Министерства обороны США Dod-STD-2167A и российскими

стандартами серии ГОСТ

34.

Принципиальными свойствами так

называемой «чистой» каскадной модели являются следующие:

• фиксация требований к системе до ее сдачи заказчику;

• переход на очередную стадию проекта только после того,

как будет полностью завершена работа на текущей стадии,

без возвратов на пройденные стадии.

Каждая стадия заканчивается получением некоторых резуль-

татов, которые служат в качестве исходных данных для следую-

щей стадии. Требования к разрабатываемому ПО, определенные

на стадии формирования требований, строго документируются в

виде

технического задания

фиксируются на

все

время разработ-

ки проекта. Каждая стадия завершается выпуском полного комп-

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

могла быть продолжена другой командой разработчиков.

Преимущества применения каскадной модели заключаются в

следующем:

• на каждой стадии формируется законченный набор проект-

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

ласованности;

• выполняемые в логичной последовательности стадии работ

позволяют планировать сроки завершения всех работ и со-

ответствующие затраты.