Понятие жизненного цикла ИС. Понятие модели жизненного цикла ИС. Типы моделей ЖЦ ИС. Особенности, преимущества, недостатки.

Понятие жизненного цикла (ЖЦ) ИС является одним из базовых в программной инженерии. Жизненный цикл ИС определяется как период времени, который начинается с момента принятия решения о необходимости создания ИС и заканчивается в момент его полного изъятия из эксплуатации. Основным нормативным документом, регламентирующим состав процессов жизненного цикла, является международный стандарт ISO/IEC 12207: “Information Technology – Software Life Cycle Processes”. ISO – International Organization for Standardization – Международная организация по стандартизации, IEC – International Electrotechnical Commission – Международная комиссия по электротехнике. Данный стандарт определяет структуру жизненного цикла, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ИС.

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

Рис. 2.1. Жизненный цикл информационной системы

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

· каскадная (до 70-х годов);

· итерационная (70-80-е годы);

· спиральная (80-90-е годы).

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

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

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

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

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

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

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

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

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

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

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

В середине 80-х гг. была предложена спиральная модель жизненного цикла, представленная на рис.2.2.

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

Рис. 2.2. Спиральная модель жизненного цикла информационной системы

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

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

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

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

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

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

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

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

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

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

БИЛЕТ №____4____