Файл: Учебник Рекомендовано Федеральным государственным учреждением.pdf

На втором этапе разрабатывают проектные решения, удовлет­
воряющие всем требованиями, сформулированным в техническом задании. Результатом данного этапа является комплект проектной документации, содержащей все необходимые данные для реали­
зации проекта.
Третий этап — реализация проекта. Здесь осуществляется раз­
работка программного обеспечения (кодирование) в соответствии с проектными решениями, полученными на предыдущем этапе.
Методы, используемые для реализации, не имеют принципиаль­
ного значения. Результатом выполнения данного этапа является готовый программный продукт.
На четвертом этапе проводится проверка (тестирования) по­
лученного программного обеспечения на предмет соответствия требованиям, заявленным в техническом задании. Опытная экс­
плуатация позволяет выявить различного рода скрытые недостат­
ки, проявляющиеся в реальных условиях работы информационной системы.
Последний этап — сдача готового проекта, ввод его в действие.
Главная задача этого этапа — документально подтвердить, что все требования заказчика выполнены в полной мере.
Этапы работ в рамках каскадной модели часто также называ­
ют частями «проектного цикла» системы. Такое название воз­
никло потому, что этапы состоят из многих итерационных про­
цедур уточнения требований к системе и вариантов проектных решений. Жизненный цикл самой системы существенно сложнее и длиннее. Он может включать в себя произвольное число циклов уточнения, изменения и дополнения уже принятых и реализо­
ванных проектных решений. В этих циклах происходят развитие информационной системы и модернизация отдельных ее компо­
нентов.
Достоинства каскадной модели.
Каскадная модель имеет ряд положительных сторон, благодаря которым она хорошо зареко­
мендовала себя при выполнении различного рода инженерных разработок и получила широкое распространение. Рассмотрим ее основные достоинства.
1. На каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласован­
ности. На заключительных этапах также разрабатывается пользо­
вательская документация, охватывающая все предусмотренные стандартами виды обеспечения информационной системы (орга­
низационное, методическое, информационное, программное, аппаратное).
2. Выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения и соответствующие затраты.
77

Каскадная модель изначально разрабатывалась для решения различного рода инженерных задач и не потеряла своего значения для прикладной области до настоящего времени. Кроме того, каскадный подход хорошо зарекомендовал себя при разработке определенных информационных систем. Имеются в виду системы, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем чтобы предоставить разработчикам свободу выбора реализации, наилучшей с техни­
ческой точки зрения. К таким информационным системам, в частности, относятся сложные расчетные системы, системы ре­
ального времени.
Тем не менее, несмотря на все свои достоинства, каскадная модель имеет ряд недостатков, ограничивающих ее применение при разработке информационных систем. Причем эти недостатки делают ее либо полностью неприменимой, либо приводят к уве­
личению сроков разработки и стоимости проекта. В настоящее время многие неудачи программных проектов объясняются имен­
но последовательным процессом разработки.
Недостатки каскадной модели.
Перечень недостатков ка­
скадной модели при ее использовании для разработки информа­
ционных систем достаточно обширен. Вначале просто перечислим их, а затем рассмотрим основные из них более подробно:
— существенная задержка в получении результатов;
— ошибки и недоработки на любом из этапов проявляются, как правило, на последующих этапах работ, что приводит к необхо­
димости возврата назад;
— сложность параллельного ведения работ по проекту;
— чрезмерная информационная перенасыщенность каждого из этапов;
— сложность управления проектом;
— высокий уровень риска и ненадежность инвестиций.
Задержка в получении результатов обычно считается главным недостатком каскадной схемы. Данный недостаток проявляется в основном в том, что вследствие последовательного подхода к раз­
работке согласование результатов с заинтересованными сторона­
ми производится только после завершения очередного этапа работ.
Может оказаться, что разрабатываемая информационная система не соответствует требованиям пользователей, причем такие несо­
ответствия могут возникать на любом этапе разработки — иска­
жения могут непреднамеренно вноситься и проектировщиками- аналитиками, и программистами, так как они могут недостаточно хорошо разбираться в тех предметных областях, для которых раз­
рабатывают информационную систему.
Кроме того, используемые при разработке информационной системы модели автоматизируемого объекта, отвечающие крите­
78

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

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

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

Возврат на предыдущие стадии может быть связан не только с ошибками, но и с изменениями, произошедшими в предметной области или в требованиях заказчика за время разработки. Причем возврат проекта на доработку вследствие этих причин не гаран­
тирует, что предметная область снова не изменится к тому момен­
ту, когда будет готова следующая версия проекта. Фактически это означает, что существует вероятность того, что процесс разработ­
ки «зациклится», и система никогда не дойдет до сдачи в экс­
плуатацию. Расходы на проект будут постоянно расти, а сроки сдачи готового продукта постоянно откладываться.
Поэтому можно утверждать, что сложные проекты, разрабаты­
ваемые по каскадной схеме, имеют повышенный уровень риска.
Помимо рассмотренных существует еще один серьезный недо­
статок, присущий каскадной модели разработки, на который также следует обратить внимание. Этот недостаток связан с кон­
фликтом (не всегда явным) между разработчиками, участвующи­
ми в выполнении проекта. Конфликт обусловлен тем, что возврат части проекта на предыдущую стадию обычно сопровождается поиском причин и виновных. А так как однозначно персонифи­
цировать ответственного за ошибки можно далеко не всегда, по­
пытки поиска виноватых могут сильно усложнить отношения в коллективе. Как следствие, в рабочей группе часто ценится не тот руководитель, который имеет высокую квалификацию и больший опыт, а тот, кто умеет «отстоять» своих подчиненных, обеспечить им более удобные условия работы и т. п. В результате появляется опасность снижения и квалификации, и творческого потенциала всей команды. Соответственно, техническое руководство проек­
том начинает в большей степени подменяться организационным руководством, все более детальной проработкой должностных инструкций и все более формальным их исполнением.
Каскадный подход хорошо зарекомендовал себя при построе­
нии относительно простых информационных систем, когда в самом начале разработки можно достаточно точно и полно сфор­
мулировать все требования к системе.
3.3.2. Спиральная модель жизненного цикла
Спиральная модель ЖЦ была предложена для преодоления перечисленных проблем каскадной модели. На этапах анализа и проектирования реализуемость технических решений и степень удовлетворения потребностей заказчика проверяется путем соз­
дания прототипов. Каждый виток спирали соответствует созданию работоспособного фрагмента или версии системы. Это позволяет уточнить требования, цели и характеристики проекта, определить
82

качество разработки, спланировать работы следующего витка спира/ти. Таким образом, углубляются и последовательно конкре­
тизируются детали проекта, и в результате выбирается обоснован­
ный вариант, который удовлетворяет действительным требовани­
ям заказчика и доводится до реализации.
Спиральная модель (рис. 3.3) в отличие от каскадной предпо­
лагает итерационный процесс разработки информационной си­
стемы. При этом возрастает значение начальных этапов жизнен­
ного цикла, таких как анализ и проектирование. На этих этапах проверяется и обосновывается реализуемость технических реше­
ний путем создания прототипов. Каждая итерация представляет собой законченный цикл разработки, приводящий к выпуску внутренней или внешней версии изделия (или подмножества ко­
нечного продукта), которое совершенствуется от итерации к ите­
рации, чтобы стать законченной системой. На каждом витке спирали уточняются цели и характеристики проекта, определяет­
ся его качество, планируются работы на следующем витке. На каждой итерации углубляются и последовательно конкретизиру­
ются детали проекта, в результате чего выбирается обоснованный вариант, который доводится до окончательной реализации.
Использование спиральной модели позволяет перейти на сле­
дующий этап выполнения проекта, не дожидаясь полного завер­
шения текущего — недоделанную работу можно будет выполнить на следующей итерации. Главная задача каждой итерации — как можно быстрее создать работоспособный продукт, который можно показать пользователям системы. Таким образом, существенно упрощается процесс внесения уточнений и дополнений в проект.
Достоинства спиральной модели.
Спиральный подход к раз­
работке программного обеспечения позволяет преодолеть боль-
Рис. 3.3. Спиральная модель жизненного цикла ИС
83

шинство недостатков каскадной модели и, кроме того, обеспечи­
вает ряд дополнительных возможностей, делая процесс разработ­
ки более гибким. Рассмотрим преимущества итерационного подхода более подробно.
1. Итерационная разработка существенно упрощает внесение изменений в проект при изменении требований заказчика.
2. При использовании спиральной модели отдельные элементы информационной системы интегрируются в единое целое посте­
пенно. При итерационном подходе интеграция производится фактически непрерывно. Поскольку интеграция начинается с меньшего количества элементов, то возникает гораздо меньше проблем при ее проведении (по некоторым оценкам, при исполь­
зовании каскадной модели разработки интеграция занимает до
40 % всех затрат в конце проекта).
3. Уменьшение уровня рисков. Данное преимущество является следствием предыдущего, так как риски обнаруживаются именно во время интеграции. Поэтому уровень рисков максимален в на­
чале разработки проекта. По мере продвижения разработки ожи­
даемый уровень рисков снижается. Данное утверждение справед­
ливо при любой модели разработки, однако при использовании спиральной модели снижение уровня рисков происходит с наи­
большей скоростью. Это связано с тем, что при итерационном подходе интеграция выполняется уже на первой итерации, и на начальных итерациях выявляются многие аспекты проекта, такие как пригодность используемых инструментальных средств и про­
граммного обеспечения, квалификация разработчиков и т.п. На рис. 3.4 приведены в сравнении графики зависимости уровня рисков от времени разработки для каскадного и итерационного подходов.
4. Итерационная разработка обеспечивает большую гибкость в управлении проектом, давая возможность внесения тактических изменений в разрабатываемое изделие. Например, можно сокра­
тить сроки разработки за счет снижения функциональности си­
стемы или использовать в качестве составных частей системы
Рис. 3.4. Зависимость рисков от времени разработки
84