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

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

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

     К настоящему времени наибольшее распространение получили две основные модели жизненного цикла:

     1. Классический жизненный цикл - каскадная модель, иногда также называемая моделью водопада

     2. Спиральная модель 
 

Классический  жизненный цикл

     Одной из старейших последовательностей  шагов разработки программного обеспечения (ПО) является классический жизненный цикл  (Автор Уинстон Ройс, 1970).

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

      Рисунок - Классический жизненный цикл разработки ПО 
 

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

Рассмотрим  каскадную модель немного подробнее

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

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

     Основные  этапы разработки по каскадной модели 

     За  десятилетия существования каскадной  модели разбиение работ на стадии и названия этих стадий менялись. Кроме  того, наиболее разумные методики и  стандарты избегали жесткого и однозначного приписывания определенных работ к конкретным этапам. Тем не менее, все же можно выделить ряд устойчивых этапов разработки, практически не зависящих от предметной области:

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

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

     3) разработка;

     4) тестирование и опытная эксплуатация;

     5) сдача готового продукта. 
 

     Основные  достоинства каскадной  модели 

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

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

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

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

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

     Недостатки  каскадной модели 

     Перечень  недостатков каскадной модели при  ее использовании для разработки информационных систем достаточно обширен. Вначале просто перечислим их, а  затем рассмотрим основные из них  более подробно:

     1) существенная задержка в получении результатов;

     2) ошибки и недоработки на любом из этапов проявляются, как правило, на последующих этапах работ, что приводит к необходимости возврата назад;

     3) сложность параллельного ведения работ по проекту;

     4) чрезмерная информационная перенасыщенность каждого из этапов;

     5) сложность управления проектом;

     6) высокий уровень риска и ненадежность инвестиций.  

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

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

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

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

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

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

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

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

     Преимущества  спиральной модели 

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

     Рассмотрим  преимущества итерационного подхода  более подробно.

     Итерационная  разработка существенно упрощает внесение изменений в проект при изменении  требований заказчика.

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

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

       

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

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

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

     Недостатки  спиральной модели 

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

С каждой итерацией по спирали (продвижением от центра к периферии) строятся все  более полные версии ПО. 
 
 
 

     Итерационная  модель

     Макетирование (прототипирование)

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