Модели жизненного цикла информационной системы

 

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

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

Сегодня в практике создания ИС применяются следующие модели жизненного цикла: 1) каскадная модель, иногда также называемая моделью «водопад» (waterfall); 2) спиральная модель.

Каскадная модель разработки ИС

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

В этой модели можно выделить следующие этапы разработки, практически не зависящие от предметной области (рис. 13, а, б; табл. 7):

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

• проектирование и разработка ИС;

• тестирование и опытная эксплуатация ИС;

• сдача готового программного продукта.

 

 

Рис. 13. Каскадная модель разработки ИС:

а – теоретическая; б – практическая

 

 

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

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

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

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

Таблица 7

 

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

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

достоинства модели

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

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

1. Существенная задержка в получении результатов. 2. Ошибки и недоработки на любом из этапов выявляются, как правило, на последующих этапах работ, что приводит к необходимости возврата на предыдущие стадии. 3. Сложность распараллеливания работ по проекту. 4. Чрезмерная информационная насыщенность каждого из этапов. 5. Сложность управления проектом. 6. Высокий уровень риска и ненадежность инвестиций.

 

 

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

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

Причины подобной ситуации состоят в следующем:

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

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

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

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

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

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

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

Чем сложнее проект ИС, тем более запутаны взаимосвязи между его частями и тем дольше каждый из этапов разработки. Реальная оценка итогов возможна лишь на этапе тестирования, по завершении всех предыдущих этапов (анализа, проектирования и разработки ИС), требующих много времени и средств. Возврат на предыдущие стадии проекта ИС обусловлен не только ошибками, но и изменениями в предметной области или требованиях заказчика, а также априорной вероятностью того, что разработка проекта «зациклится» еще до сдачи проекта в эксплуатацию. При этом расходы на проект резко возрастают, а сроки сдачи готового продукта отсрочиваются во времени. Разработка сложных проектов ИС с использованием каскадной модели характеризуется повышенным уровнем риска, что подтверждено практикой: в США более 31 % проектов ИС (IТ-проектов) заканчивается провалом, 53 % – почти двойным перерасходом бюджета (в среднем на 189%) и лишь 16,2 % проектов реализуется в заданные сроки и укладывается в бюджетные объемы финансирования.