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

1.1. МОДЕЛИ И СТАДИИ ЖЦ ПО

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

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

Модель ЖЦ любого конкретного ПО ЭИС определяет характер процесса его создания, который представляет собой совокупность упорядоченных во времени, взаимосвязанных и объединенных в стадии работ, выполнение которых необходимо и достаточно для создания ПО, соответствующего заданным требованиям. Под ста­дией создания ПО понимается часть процесса создания ПО, огра­ниченная некоторыми временными рамками и заканчивающаяся выпуском конкретного продукта (моделей ПО, программных ком­понентов, документации), определяемого заданными для данной стадии требованиями. Стадии создания ПО выделяются по сообра­жениям рационального планирования и организации работ, закан­чивающихся заданными результатами. В состав жизненного цикла ПО обычно включаются следующие стадии:

1. Формирование требований к ПО.

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

3. Реализация.

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

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

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

7. Снятие с эксплуатации.

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

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

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

• построение моделей деятельности организации, предусматриваю­щее обработку материалов обследования и построение двух ви­дов моделей:

• модели "AS-IS" ("как есть"), отражающей существующее на мо­мент обследования положение дел в организации и позволяю­щей понять, каким образом функционирует данная организация, а также выявить узкие места и сформулировать предложения по улучшению ситуации;

• модели "ТО-ВЕ" ("как должно быть"), отражающей представле­ние о новых технологиях работы организации.

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

Переход от модели "AS-IS" к модели "ТО-ВЕ" может выполняться двумя способами:

1) совершенствованием существующих технологий на основе оценки их эффективности;

2) радикальным изменением технологий и перепроектировани­ем бизнес-процессов (реинжиниринг бизнес-процессов).

Построенные модели имеют самостоятельное практическое зна­чение. Например, модель "AS-IS" позволяет выявлять узкие места в существующих технологиях и предлагать рекомендации по решению проблем независимо от того, предполагается на данном этапе даль­нейшая разработка ЭИС или нет. Кроме того, модель облегчает обу­чение сотрудников конкретным направлениям деятельности органи­зации за счет использования наглядных диаграмм (известно, что "одна картинка стоит тысячи слов").

Стадия проектирования. Она, как правило, включает следующие этапы:

• разработка системного проекта. На этом этапе дается ответ на воп­рос: "Что должна делать будущая система?", а именно: определя­ются архитектура системы, ее функции, внешние условия функ­ционирования, интерфейсы и распределение функций между пользователями и системой, требования к программным и инфор­мационным компонентам, состав исполнителей и сроки разработки. Основу системного проекта составляют модели проектируемой ЭИС, которые строятся на основе модели "ТО-ВЕ". Документаль­ным результатом этапа является техническое задание;

• разработка технического проекта. На этом этапе на основе сис­темного проекта осуществляется собственно проектирование си­стемы, включающее проектирование архитектуры системы и де­тальное проектирование. Таким образом, дается ответ на вопрос: "Как построить систему, чтобы она удовлетворяла предъявлен­ным к ней требованиям?". Модели проектируемой ЭИС при этом уточняются и детализируются до необходимого уровня. Содержание последующих стадий совпадает в основном с соот­ветствующими процессами ЖЦ ПО.

На каждой стадии могут выполняться несколько процессов, оп­ределенных в стандарте ISO/I ЕС 12207, и, наоборот, один и тот же процесс может выполняться на различных стадиях. Взаимосвязь между стадиями и процессами (включая отдельные действия) пока­зана в табл. 1.1 (каждая стадия обозначена первой буквой своего наименования: Ф - формирование требований к ПО; П - проекти­рование; Р — реализация; Т — тестирование; В — ввод в действие; Э — эксплуатация и сопровождение; С — снятие с эксплуатации).

Таблица 1.1 Взаимосвязи между стадиями и процессами ЖЦ ПО

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

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

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

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

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

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

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

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

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

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

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

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

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

Для преодоления перечисленных проблем в середине 80-х гг. была предложена спиральная модель ЖЦ (рис. 1.5). Ее принципиальной особенностью является следующее: прикладное ПО создает­ся не сразу, как в случае каскадного подхода, а по частям с использо­ванием метода прототипирования. Под прототипом понимается действующий программный компонент, реализующий отдельные функции и внешние интерфейсы разрабатываемого ПО. Создание прототипов осуществляется в несколько итераций, или витков спи­рали. Каждая итерация соответствует созданию фрагмента или вер­сии ПО, на ней уточняются цели и характеристики проекта, оце­нивается качество полученных результатов и планируются работы следующей итерации. На каждой итерации производится тщатель­ная оценка риска превышения сроков и стоимости проекта, чтобы определить необходимость выполнения еще одной итерации, сте­пень полноты и точности понимания требований к системе, а так­же целесообразность прекращения проекта. Спиральная модель из­бавляет пользователей и разработчиков ПО от необходимости пол­ного и точного формулирования требований к системе на началь­ной стадии, поскольку они уточняются на каждой итерации. Таким образом, углубляются и последовательно конкретизируются детали проекта, и в результате выбирается обоснованный вариант, который доводится до реализации.

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

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

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

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

1.2. ПОДХОД RAD

Одним из возможных подходов к разработке прикладного ПО в рамках спиральной модели ЖЦ является получивший широкое распространение способ так называемой быстрой разработки приложений, или RAD (Rapid Application Development). Подход RAD предусматривает наличие трех составляющих:

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

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

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

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

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

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

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

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

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

На стадии анализа и планирования требований пользователи осу­ществляют следующие действия:

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

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

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

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

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

стадий;

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

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

ЭИС;

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

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

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

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

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

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

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

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

форма);

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

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

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

внутри приложения);

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

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

Результатом данной стадии должны быть:

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

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

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

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

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

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

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

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

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

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

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

• производится физическое проектирование базы данных;

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

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

• завершается разработка документации проекта. Результатом стадии является готовая система, удовлетворяющая

всем согласованным требованиям.

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

• разрабатывается совершенно новая система;

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

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

Следует, однако, отметить, что подход RAD, как и любой другой, не может претендовать на универсальность. Он хорош в первую оче­редь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Если же разрабатывается крупномасштабная система (например, масштаба отрасли), которая не является закон­ченным продуктом, а представляет собой комплекс программных компонентов, адаптируемых к программно-аппаратным платформам, системам управления базами данных (СУБД), средствам телекомму­никации, организационно-экономическим особенностям объектов внедрения и интегрируемых с существующими разработками, то на первый план выступают такие показатели проекта, как управляемость и качество, которые могут войти в противоречие с простотой и ско­ростью разработки. Для таких проектов необходимы высокий уро­вень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки.

Подход RAD не применим для построения сложных расчетных программ, операционных систем или программ управления сложны­ми объектами в реальном масштабе времени, т.е. программ, содер­жащих большой объем (сотни тысяч строк) уникального кода.

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

• менее 1 тыс. функциональных точек — один человек;

• от 1 до 4 тыс. функциональных точек — одна команда разработ­чиков;

• более 4 тыс. функциональных точек — одна команда разработчи­ков на 4 тыс. функциональных точек.

Итак, перечислим основные принципы подхода RAD:

• разработка приложений итерациями;

• необязательность полного завершения работ на каждой стадии ЖЦ ПО;

• обязательность вовлечения пользователей в процесс разработки ЭИС;

• целесообразность применения CASE-средств, обеспечивающих целостность проекта и генерацию кода приложений;

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

готовой системы;

• использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности пользователей;

• тестирование и развитие проекта, осуществляемые одновремен­но с разработкой;

• ведение разработки немногочисленной хорошо управляемой ко­мандой профессионалов;

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