26.Понятие жизненного цикла ис и основные модели

жизненного цикла ИС.

Период времени, который начин-ся с момента принятия реш-я о необход-ти создания программного продукта и заканч-ся в момент его полного изъятия из эксплуатации. Этот цикл — процесс построения и развития ПО.

К наст. врем. наиб-е распр-е получили следующие две основные модели ЖЦ: каскадная модель (70-85 г.г.); спиральная модель (86-90 г.г.).

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

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

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

В результате реальный процесс создания ПО принимал следующий вид:

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

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

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