Итерационная модель ЖЦ. Спиральная модель

Лекция №4

Тема: «Жизненный цикл Автоматизированных систем»

План:

Модели ЖЦ АИС

Каскадная модель ЖЦ

Итерационная модель ЖЦ. Спиральная модель

Модели жизненного цикла АИС

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

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

Модель ЖЦ АИС отражает состояние системы с момента осознания необходимости создания данной АИС до полной ее утилизации.

Выбор модели жизненного цикла зависит от специ­фики, масштаба, сложности проекта и набора условий, в кото­рых АИС создается и функционирует.

Модель ЖЦ АИС вклю­чает:

• стадии;

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

• ключевые события или точки завершения работ и приня­тия решений.

В соответствии с известными моделями ЖЦ ПО определяют модели ЖЦ АИС — каскадную, итерационную, спиральную.

Ниже подробно рассмотрена каждая из них.

Каскадная модель ЖЦ

Каскадная модель описывает классический подход к разра­ботке систем в любых предметных областях; широко использо­валась в 1970—80-х гг.

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

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

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

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

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

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

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

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

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

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

Ниже приведены основные достоинства:

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

2) последовательное выполнение этапов работ позволяет планировать сроки завершения и соответствующие затраты.

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

Тем не менее модель имеет ряд недостатков, ограничиваю­щих ее применение:

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

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

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

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

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

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

Задержка в получении результатов проявляется в том, что при последовательном подходе к разработке согласование ре­зультатов с заинтересованными сторонами производится только после завершения очередного этапа работ. В результате может оказаться, что разрабатываемая АИС не соответствует требова­ниям, и такие несоответствия могут возникать на любом этапе разработки; кроме того, ошибки могут непреднамеренно вно­ситься и проектировщиками-аналитиками, и программистами, так как они не обязаны хорошо разбираться в тех предметных областях, для которых разрабатывается АИС.

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

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

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

Вообще, работа может быть возвращена с любого этапа на любой преды­дущий, поэтому в реальности каскадная схема разработки выгля­дит так, как показано на рис. 1.7 116—18).

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

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

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

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

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

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

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

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

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

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

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

Таким образом, сложные проекты, разрабатываемые по кас­кадной схеме, имеют повышенный уровень риска. Этот вывод подтверждается практикой: по сведениям консалтинговой ком­пании The Standish Group в США более 31 % проектов корпора­тивных информационных систем (1Т-проектов) заканчивается неудачей; почти 53 % IT-проектов завершается с перерасходом бюджета (в среднем на 189%, т. е. почти в 2 раза); и толь­ко 16,2 % проектов укладывается и в срок, и в бюджет (13).

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

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

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

Итерационная модель ЖЦ. Спиральная модель

Построение итерационной модели заключается в серии корот­ких циклов (шагов) по планированию, реализации, изучению, действию.

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

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

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

• время жизни каждого этапа растягивается на весь период разработки;

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

• запутанность архитектуры;

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

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

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

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

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

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

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

Преимущества итерационного подхода:

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

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

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

На рис. 1.9 приведено сравнение зависимостей рис­ков от времени разработки для каскадного и итерационного подходов (8, 16—18];

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

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

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

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

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

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

Планиро­вание работ обычно проводится на основе статистических дан­ных, полученных в предыдущих проектах, и личного опыта раз­работчиков. В основе спиральной модели жизненного цикла ле­жит применение прототипной — Rapid Application Development, RAD-технологии.

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

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

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