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

Процесс функционирования и сопровождения

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

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

● корректирующее (действия по обслуживанию) — выявление дефектов и ошибок, обнаруженных при работе;

● адаптивное — изменение ПО в ответ на изменения в вычислениях или в бизнес-среде;

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

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

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

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

Рассмотрим, почему специфические особенности жизненного цикла должны быть приспособлены к организационной культуре и почему они отличаются от проекта к проекту:

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

● Деловой опыт и знания (это намного более неприятно, чем предыдущий момент, потому что деловой опыт и знания легко не приобретаются).

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

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

● Внутренние деловые изменения (изменения в управлении, условиях работы, финансовое здоровье предприятия и т. д.).

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

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

● «водопад с обратной связью»;

● итеративный пошаговый.

1 Жизненный цикл «водопад с обратной связью»

Модель водопада — традиционный жизненный цикл, реализованный и популяризируемый в 1970-х годах. Об этой модели было сказано, что она успешно использовалась во многих больших проектах прошлого. Большинство этих проектов было связано с пакетными (то есть не диалоговыми) системами, реализованными на языке КОБОЛ. Сегодня жизненный цикл «водопад» используется менее часто.

Жизненный цикл «водопад с обратной связью» может быть представлен так, как изображено на рис. 1.3. Это линейная последовательность стадий, из которых предыдущая стадия должна быть закончена прежде, чем может начаться следующая.

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

Такой возврат может (хотя это бывает редко) продолжаться до начальной стадии — анализа требований.

Рисунок 1.3. Жизненный цикл «водопад с обратной связью»

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

Преимущества водопада с обратной связью:

1 Предписывает дисциплинированный подход к разработке ПО. Определяет ясные вехи в стадиях ЖЦ, облегчая, таким образом, руководство проектом.

2 Производит полную документацию для системы.

3 Требует завершения проектной документации перед переходом на следующие стадии.

4 Требует тщательного планирования проекта.

Недостатки водопада с обратной связью:

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

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

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

4 Документация может давать ложное представление относительно прогресса в проектировании. Имеется риск бюрократизировать работу.

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

6 Планирование проекта проводится на ранних этапах ЖЦ, когда имеется ограниченное понимание проекта. Риск неверной оценки требуемых ресурсов.

Дата добавления: 2014-01-05