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

Жизненный цикл

Наименование процессов идействий

Подготовительная работа

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

Техническая оценка

Аудит

Подготовительная работа

Аудит

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

Подготовительная работа

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

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

Управление

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

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

Выполнение и контроль

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

Завершение

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

Подготовительная работа

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

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

41

Продолжение

Стадия Ф П Р т в э с

• •

•

••

42						Глава 1
					Продолжение
Наименование процессов и действий				Стадия
				т	в	э	с
	Ф	П	Р
Усовершенствование
Создание процесса	•	•
Оценка процесса
Усовершенствование процесса		•	•	•	•	•
Обучение
Подготовительная работа	•	•	•				•
Разработка учебных материалов	•	•	•				•
Реализация плана обучения

К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ ПО: каскадная модель (1970 — 1985 гг.) и спиральная модель (1986 - 1990 гг.).

В однородных ЭИС 70-х и 80-х гг. прикладное ПО представляло собой единое целое. Для разработки такого типа ПО применялся каскадный подход (другое название —водопад (waterfall)) (рис. 1.3). Принципиальной особенностью каскадного подхода является следующее: переход на следующую стадию осуществляется только после того, как будет полностью завершена работа на текущей стадии, и возвратов на пройденные стадии не предусматривается. Каждая стадия заканчивается получением некоторых результатов, которые служат в качестве исходных данных для следующей стадии. Требования к разрабатываемому ПО, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Критерием качества разработки при таком подходе является.;Твчность выполнения спецификаций технического задания.

Жизненный цикл	43
Формирование	h
требований
к ПО

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

Реализация

Тестирование 1

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

Эксплуатация и сопровождение

Рис. 1.3. Каскадная схема разработки ПО

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

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

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

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

Каскадный подход хорошо зарекомендовал себя при построении ЭИС, для которых в самом начале разработки можно достаточно

44 Гла

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

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

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

Основным недостатком каскадного подхода являются существенное запаздывание с получением результатов и, как следствие, достаточно высокий риск создания системы, не удовлетворяю.щей изменившимся потребностям пользователей. Практика показывает, что на начальной стадии проекта полностью и точно сформулировать все требования к будущей системе не удается. Это объясняется двумя причинами: 1) пользователи не в состоянии сразу изложить все свои требования и не могут предвидеть, как они изменятся в ходе разработки; 2) за время разработки могут произойти изменения во внешней среде, которые повлияют на требования к системе. В рамках каскадного подхода требования к ЭИС фиксируются в виде технического задания на все время ее создания, а согласование получаемых результатов с пользователями производится только в точках, планируемых после завершения каждой стадии (при этом возможна корректировка результатов по замечаниям пользователей, если они не затрагивают требования, изложенные в техническом задании). Таким образом, пользователи могут внести существенные замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длитель-

Жизненный цикл

45

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

требований

к ПО

Проектиро

вание

Реализация

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

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

Эксплуатация и сопровождение

Рис. 1.4. Реальный процесс разработки ПО

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

Для преодоления перечисленных проблем в середине 80-х гг. была предложена спиральная модель ЖЦ (рис. 1.5). Ее принципи-

46

Глава 1

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

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

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

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

Жизненный цикл

47

Определениецелей,

альтернатив и ограничений

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

следующей

итерации

Идентификация

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

Принципы

функционирования

Кодирование и тестирование

Кодирование и тестирование

Разработка

продукта

на очередной итерации

Рис. 1.5. Спиральная модель жизненного цикла программного обеспечения

48

Глава 1

1.2.2. ПОДХОД RAD

Одним из возможных подходов к разработке прикладного ПО в рамках спиральной модели ЖЦ является получивший широкое распространение способ так называемой быстрой разработки приложе-

ний, или RAD (Rapid Application Development). Подход RAD предусмат-

ривает наличие трех составляющих:

•небольших групп разработчиков (от 3 до 7 человек), выполняющих работы по проектированию отдельных подсистем ПО. Это обусловлено требованием максимальной управляемости коллектива;

•короткого, но тщательно проработанного производственного графика (до 3 месяцев);

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

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

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

Жизненный цикл ПО в соответствии с подходом RAD включает четыре стадии:

1)анализ и планирование требований;

2)проектирование;

3)реализация;

4)внедрение.

На стадии анализа и планирования требований пользователи осу-

ществляют следующие действия:

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

•выделяют наиболее приоритетные функции, требующие проработки в первую очередь;

•описывают информационные потребности. Формулирование требований к системе осуществляется в основном силами пользователей под руководством специалистов-разработчиков.

Кроме того, на данной стадии решаются следующие задачи:

Жизненный цикл

49

•ограничивается масштаб проекта;

•устанавливаются временные рамки для каждой из последующих стадий;

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

•список расставленных по приоритету функций будущего ПО ЭИС;

•предварительные моделиПО.

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

•более детально рассматриваются процессы системы;

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

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

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

После детального определения состава процессов оценивается количество так называемых функциональных точек (function point) разрабатываемой системы ипринимается решение о разделенииЭИС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время (до 3 месяцев). Под функциональной точкой понимается любой из следующих элементов разрабатываемой системы:

•входной элемент приложения (входной документ или экранная форма);

•выходной элемент приложения (отчет, документ, экраннаяформа);

•запрос (пара "вопрос/ответ");

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

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

50

Глава 1

Далее проект распределяется между различными командами разработчиков. (Опыт разработки крупных ЭИС показывает, что для повышения эффективности работ необходимо разбить проект на отдельные слабо связанные по данным и функциям подсистемы. Реализация подсистем должна выполняться отдельными группами специалистов. При этом необходимо обеспечить координацию ведения общего проекта и исключить дублирование результатов работ каждой проектной группы, которое может возникнуть в силу наличия общих данных и функций.) В случае использования CASEсредств это означает деление функциональной модели системы (диаграммы потоков данных для структурного подхода (см. главу 2) или диаграммы вариантов использования для объектно-ориентированно- го подхода (см. главу 3)). Результатом данной стадии должны быть:

•общая информационная модель системы;

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

•точно определенные интерфейсы между автономно разрабатываемыми подсистемами;

•построенные прототипы экранных форм, отчетов, диалогов. Все модели и прототипы должны быть получены с применением

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

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

На стадии реализации выполняется непосредственно сама быстрая разработка приложения:

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

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