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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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