Вопрос 15
Организационные процессы жизненного цикла АС.
v Процесс управления
· Инициирование и определение области управления
· Планирование
· Выполнение и контроль
· Проверка и оценка
· Завершение
· Инициирование и определение области управления. Руководитель должен убедиться, что необходимо для управления ресурсы имеются в его распоряжении в достаточном количстве.
· Планирование. Составление графиков выполнения работ, оценка затрат, выделение требуемых ресурсов, распределение ответственности, оценка рисков, создание инфраструктуры управления
v Процесс создания инфраструктуры
Охватывает выбор и поддержку технологию стандартов инструментальных средств, выбор и установку аппаратных и программных средств, используемых для разработки, эксплуатации и сопровождения
· Подготовительная работа
· Создание инфраструктуры
· Сопровождение инфраструктуры
v Процесс усовершенствования
Предусматривает оценку, измерение, контроль и усовершенствование ЖЦ АС.
· Создание процесса
· Оценка процесса
· Усовершенствование процесса
v Процесс обучения
Охватывает первоначальное обучение и последующие постоянное повышение квалификации персонала содержания процесса обучения определяется требованиями к проекту, должно учитывать необходимые ресурсы и технические средства обучения. Должны быть разработаны и представлены методические материалы, необходимые для обучения пользователей в соответствии с учебным планом.
· Подготовительная работа
· Разработка учебных материалов
· Реализация плана обучения
Данная модель предполагает строго последовательное (во времени) и однократное выполнение всех фаз проекта с жестким (детальным) предварительным планированием в контексте предопределенных или однажды и целиком определенных требований к программной системе.
Рисунок 2. Каскадная модель жизненного цикла.
На рисунке изображены типичные фазы каскадной модели жизненного цикла и соответствующие активы проекта, являющиеся для одних фаз выходами, а для других - входами. Марри Кантор [Кантор, 2002, с.145-146] отмечает ряд важных аспектов, характерных для водопадной модели: “Водопадная схема включает несколько важных операций, применимых ко всем проектам:
· составление плана действий по разработке системы;
· планирование работ, связанных с каждым действием;
· применение операции отслеживания хода выполнения действий с контрольными этапами.
В связи с тем, что упомянутые задачи являются неотъемлемым элементом всех хорошо управляемых процессов, практически не существует причин, препятствующих утверждению полнофункциональных, классических методов руководства проектом, таких как анализ критического пути и промежуточные контрольные этапы. Я часто встречался с программными менеджерами, которые ломали себе голову над тем, почему же столь эффективный набор методик на практике оборачивается неудачей...”
Будучи активно используема (де факто и, например, в свое время, как часть соответствующего отраслевого стандарта в США), эта модель продемонстрировала свою “проблемность” в подавляющем большинстве ИТ-проектов, за исключением, может быть, отдельных проектов обновления программных систем для критически-важных программно-аппаратных комплексов (например, авионики или медицинского оборудования). Практика показывает, что в реальном мире, особенно в мире бизнес-систем, каскадная модель не должна применяться. Специфика таких систем (если можно говорить о “специфике” для подавляющего большинства создаваемых систем) - требования характеризуются высокой динамикой корректировки и уточнения, невозможностью четкого и однозначного определения требований до начала работ по реализации (особенно, для новых систем) и быстрой изменчивостью в процессе эксплуатации системы.
Фредерик Брукс во втором издании своего классического труда “Мифический человеко-месяц” так описывает главную беду каскадной модели [Брукс, 1995, с.245]:
“Основное заблуждение каскадной модели состоит в предположениях, что проект проходит через весь процесс один раз, архитектура хороша и проста в использовании, проект осуществления разумен, а ошибки в реализации устраняются по мере тестирования. Иными словами, каскадная модель исходит из того, что все ошибки будут сосредоточены в реализации, а потому их устранение происходит равномерно во время тестирования компонентов и системы.”
В каскадной модели переход от одной фазы проекта к другой предполагает полную корректность результата (выхода) предыдущей фазы. Однако, например, неточность какого-либо требования или некорректная его интерпретация, в результате, приводит к тому, что приходится “откатываться” к ранней фазе проекта и требуемая переработка не просто выбивает проектную команду из графика, но приводит часто к качественному росту затрат и, не исключено, к прекращению проекта в той форме, в которой он изначально задумывался. Кроме того, эта модель не способна гарантировать необходимую скорость отклика и внесение соответствующих изменений в ответ на быстро меняющиеся потребности пользователей, для которых программная система является одним из инструментов исполнения бизнес-функций. И таких примеров проблем, порождаемых самой природой модели, можно привести достаточно много. Достаточно для чего? Для отказа от каскадной модели жизненного цикла.