4970

11

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

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

1.1.Приобретение готовых ИС.

1.2.Поставка программного продукта или услуги.

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

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

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

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

2.1.Документирование процесса разработки.

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

2.3.Обеспечение качества программных средств.

3.Организационные процессы жизненного цикла.

3.1.Управление проектом создания информационной системы.

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

3.3.Усовершенствование (оценка, измерение, контроль и усовершенствование процессов).

3.4.Обучение (первоначальное обучение и последующее постоянное повы-

шение квалификации персонала).

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

13

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

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

1.3. Спиральная модель жизненного цикла ИС

Спиральная модель была разработана в середине 1980-х годов. Она основана на классическом цикле Дёминга PDCA (англ. plan−do−check−act − планирование, выполнение, контроль, исполнение). При использовании этой модели жизненного цикла информационная система создаётся за несколько многократноповторяющихся не рекурсивных процессов (итераций). На каждой итерации создаётся фрагмент (прототип) информационной системы, который уточняется и дорабатывается на следующей итерации (витке спирали). Таким образом, начиная с прообраза (прототипа) некоторых основных функций и(или) внешних интерфейсов системы, каждый новый шаг итерации привносит и реализует на новом витке новые возможности проекта. На каждом шаге итерации оценивается качество полученных результатов (в виде артефактов) и планируются работы для следующей итерации.

На каждой итерации оцениваются:

14

1)риск превышения сроков и стоимости проекта;

2)необходимость выполнения ещё одной итерации;

3)степень полноты и точности понимания требований к системе;

4)целесообразность завершения работы над проектом.

Один из примеров реализации спиральной модели — RAD (англ. Rapid Application Development, метод быстрой разработки приложений).

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

Спиральная модель требует применения объектно-ориентированной технологии анализа и программирования. При осуществлении проектов применяется модульное и компонентное программирование, реализуется событийноориентированный интерфейс.

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

1.4. Итерационная модель жизненного цикла ИС

Итерационный подход представляет собой сочетание каскадной и спиральной моделей. Итерационная модель реализована в современной технологии RUP (от англ. Rational Unified Process — унифицированный процесс разработки программного обеспечения), созданной компанией Rational Software. Процессом называется упорядоченное неким образом множество шагов, направленных на достижение некоторой цели. В контексте проектирования программного обеспечения целью является поставка программного продукта, удовлетворяющего требованиям, в заданные сроки и в пределах заранее составленной сметы. Организация процесса RUP позволяет ему быть адаптируемым для самых разных про-

16

1)документирование требований (включая детальное описание для большинства прецедентов использования);

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

3)уточнение экономического обоснования и более точная оценка сроков и стоимости разработки;

4)снижение основных рисков.

Итерация «Построение» включает в себя следующие этапы:

1)реализация большей части функциональности продукта;

2)завершение первого внешнего релиза системы. Итерация «Внедрение» включает в себя следующие этапы:

5)создание финальной версии продукта;

6)передача от разработчика к заказчику (бета-тестирование, обучение пользователей, определение качества продукта);

7)повторение внедрения (в случае несоответствия качества ожиданиям пользователей);

8)завершение полного цикла разработки.

Технология RUP на сегодняшний день является наиболее прогрессивной, так

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

Применение UML в RUP-процессах позволяет фиксировать окончание работ на очередной стадии в виде различных по назначению моделей. Более того, язык UML принят в качестве стандарта для графических примитивов в автоматизированных CASE-средствах от одноимённой компании Rational Software (IBM Rational Software Modeler и IBM Rational Software Architect), предназначенных для ускоренной разработки программных продуктов. Типичное распределение трудоёмкости по стадиям технологии RUP приведено рисунке 1.

Описанные в этом разделе различные процессы разработки программных систем не являются единственными в своём роде. Мы привели наиболее показательные примеры с целью пояснить различия между процедурным и объектноориентированными подходами к разработке программных продуктов. Более подробно объектно-ориентированные технологии будут рассмотрены в следующей главе настоящего пособия. Иллюстрация жизненного цикла программного продукта, включающего в себя итерационный цикл разработки, применение автоматизированных средств CASE и RAD, а также роли исполнителей этапов работ приведена на рисунке 1.

19

1.5. Парадигмы программирования

Эволюция программного обеспечения обусловлена следующими проблемами: усложнением моделей предметной области; требованиями к организации групповой разработки программных продуктов; адаптация к быстрой смене поколений вычислительной техники, к уровням и развитию телекоммуникаций; требованиями к обеспечению взаимодействия систем в гетерогенных средах; мобильностью и интероперабельностью программного кода и т.д. Эволюция программного обеспечения находит своё отражение в становлении и развитии технологий (парадигм) программирования. Парадигмой программирования следует считать весь комплекс средств, которыми обладают разработчики программных продуктов, как-то: методы и средства проектирования программных систем; языки программирования; среды разработки исходного кода; средства автоматизации процессов разработки прототипов интерфейсов пользователей и классов в виде CASE-систем (Computer Aided Software Engineering); средства ускоренной разработки приложений (RAD-системы); средства экстремального программирования (в минимально сжатые сроки с привлечением большой группы разработчиков); средства реализации языков программирования четвёртого уровня и т.д.

Рассмотрим в качестве примера две парадигмы:

1)структурное проектирование и программирование (см. рисунок 3);

2)объектно-ориентированное проектирование и программирование.

1.5.1. Структурное проектирование

Структурное проектирование включает в себя:

1)нисходящее каскадное проектирование ("сверху вниз");

2)модульное программирование;

3)структурное программирование.

Нисходящее проектирование – разработка иерархической схемы, которая отражает состав и взаимоподчинённость всех функций, обнаруженных в ходе функционального анализа предметной области. Такой схемой является функциональная структура алгоритма (ФСА) приложения. Функциональная структура алгоритма строится посредством функциональной декомпозиции, т.е. выявления главной цели, подцелей и задач. Одна задача соответствует одной функции. Функциональная структура алгоритма является основой для построения алгоритма приложения. Пример функциональной структуры алгоритма приведён на рисунке 4.

20

Примечание: показательными примерами применения процедурной парадигмы при разработке тиражируемых прикладных программных продуктов для автоматизации бухгалтерского учета в 1990 – 1995гг. являлись системы с жёстким (не зависящим от действий пользователя) интерфейсом типа «меню».

1.5.2. Структурное программирование

Структурное программирование − технология разработки программного обеспечения, в основе которой лежит представление программы в виде иерархической структуры базовых конструкций (блоков). Технология предложена в 70-х годах XX века Э. Дейкстрой, разработана и дополнена Н. Виртом.

Базовые элементы структурного программирования:

1)последовательное исполнение — однократное выполнение операций в том порядке, в котором они записаны в тексте программы;

2)ветвление — однократное выполнение одной из двух или более операций,

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

3)цикл — многократное исполнение одной и той же операции до тех пор, пока выполняется некоторое заданное условие (условие продолжения цикла);

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

5)переход к выполнению таких инструкций из основной программы осуществляется посредством вызова подпрограммы (процедуры или функции);

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

Вразрабатываемой процедурной программе базовые элементы могут быть вложены друг в друга произвольным образом, при этом возможны условные и безусловные переходы на определённые (посредством меток) строки программного кода, но никаких других средств управления последовательностью выполнения операций в такой программе не предусматривается. Данная технология предусматривает каскадный процесс разработки программ (см. «каскадный жизненный цикл») методом «сверху вниз».