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

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

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

1) формирование требований к ПО;

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

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

4) тестирование;

5) ввод в действие;

6) эксплуатация и сопровождение;

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

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

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

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

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

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

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

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

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

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

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

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

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

2) разработку технического проекта. На этом этапе на основе сис­темного проекта осуществляется собственно проектирование си­стемы, включающее проектирование архитектуры системы и де­тальное проектирование. Таким образом, дается ответ на вопрос: «Как построить систему, чтобы она удовлетворяла предъявлен­ным к ней требованиям?». Модели проектируемой ЭИС при этом уточняются и детализируются до необходимого уровня;

3) содержание последующих стадий совпадает в основном с соот­ветствующими процессами ЖЦ ПО.

На каждом этапе могут выполняться несколько процессов, оп­ределенных в стандарте 1SO/IEC 12207, и, наоборот, один и тот же процесс может выполняться на различных этапах.

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

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

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

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

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

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

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

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

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

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

1) пользователи не в состоянии сразу изложить все свои требования и не могут предвидеть, как они изменятся в ходе разработки;

2) за время разработки могут про­изойти изменения во внешней среде, которые повлияют на требо­вания к системе.

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

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

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

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

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

программного обеспечения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· описывают информационные потребности.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· запрос (пара «вопрос – ответ»);

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

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

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

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

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

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

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

· построенные прототипы экранных форм, отчетов, диалогов.

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

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

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

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

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

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

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

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

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

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

· завершается разработка документации проекта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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