Организационные процессы[1]:
1. Процесс управления;
2. Процесс создания инфраструктуры;
3. Процесс усовершенствования;
4. Процесс обучения.
Процесс управления состоит из действий и задач, которые могут выполняться любой стороной, управляющей своими процессами. Стороны отвечают за управление выпуском продукта, проектом и задачами соответствующих процессов, таких, как приобретение, поставка, разработка и другие. Большую роль играет планирование. Оно подразумевает выполнение таких задач, как составление графиков выполнения работ, оценку затрат, выделение требуемых ресурсов, распределение ответственности и другие.
Процесс создания инфраструктуры охватывает выбор и поддержку технологии, стандартов и инструментов, выбор и установку программных и аппаратных средств, используемых для разработки ПО. Инфраструктура должна постоянно модифицироваться в соответствии с изменениями требований к соответствующим процессам.
Процесс усовершенствования предусматривает оценку, измерение, контроль и усовершенствование процессов жизненного цикла программного обеспечения. Усовершенствование процессов направлено на повышение производительности труда за счет совершенствования используемых технологий, методов управления, используемых инструментов и обучения персонала. Усовершенствование должно быть основано на анализе плюсов и минусов каждого из процессов. В связи с необходимостью постоянного анализа, происходит накопление различной информации о всех этапах жизненного цикла и этапах разработки.
Процесс обучения включает в себя изначальное обучение персонала и его последующее постоянное повышение квалификации. Конечный и промежуточные результаты очень сильно зависят от уровня знаний и квалификации персонала.
Взаимосвязь между процессами жизненного цикла программного обеспечения
Различные организации, компании могут по разному использовать процессы жизненного цикла. Однако, предполагается базовый вариант взаимосвязей между различными процессами в разных аспектах[1].
В договорном аспекте: заказчик и поставщик вступают в договорные отношения и реализуют соответственно процессы приобретения и поставки.
В аспекте управления: стороны участвующие в жизненном цикле программного обеспечения управляют своим процессом.
В аспекте эксплуатации: оператор предоставляет необходимые услуги пользователям.
В инженерном аспекте: разработчик или служба сопровождения решают соответствующие технические задачи, разрабатывая или модифицируя программные продукты.
В аспекте поддержки: службы, которые реализуют вспомогательные процессы, предоставляют услуги всем остальным участникам работ, по мере их необходимости.
Организационные процессы выполняются на корпоративном уровне или на уровне всей организации в целом, создавая базу для реализации и постоянного совершенствования остальных процессов жизненного цикла.
Одна и та же организация может выполнять различные роли: поставщика, разработчика и другие, и наоборот, одна и та же роль может выполняться несколькими организациями.
Модели жизненного цикла программного обеспечения
Исторически в ходе развития теории проектирования программного обеспечения и по мере его усложнения утвердились четыре основные модели ЖЦ:
1. Каскадная модель;
2. Итерационная модель;
3. Спиральная модель;
4. Компонентно-ориентированная модель.
Каскадная модель
Первой по времени появления и самой распространенной явилась каскадная модель (рис. 2). Каскадная стратегия представляет собой однократный проход этапов разработки. Она характеризуется следующими основными особенностями[3][4]:
1. Последовательным выполнением входящих в ее состав этапов;
2. Окончанием каждого предыдущего этапа до начала последующего;
3. Отсутствием временного перекрытия этапов (последующий этап не начнется, пока не завершится предыдущий);
4. Отсутствием (или определенным ограничением) возврата к предыдущим этапам;
5. Наличием результата только в конце разработки.
Рисунок 2 - Каскадная модель жизненного цикла ПО
Плюсами данной модели являются:
1. Стабильность требований в течение всего жизненного цикла разработки;
2. Простота применения стратегии, необходимость только одного прохода этапов разработки;
3. Простота планирования, контроля и управления проектом;
4. Доступность для понимания заказчиками.
К недостаткам каскадной стратегии следует отнести:
1. Сложность четкого формулирования требований в начале жизненного цикла ПС и невозможность их динамического изменения на протяжении ЖЦ;
2. Последовательность линейной структуры процесса разработки
3. При возвращении к предыдущим шагам для решения возникших проблем происходит увеличение затрат и нарушение графика работ;
4. Непригодность промежуточного продукта для использования;
5. Недостаточное участие пользователя в разработке системы или ПС – только в самом начале (при разработке требований) и в конце (во время приемочных испытаний), что приводит к невозможности предварительной оценки пользователем качества ПС или системы.
Излишняя жесткость каскадного подхода мешала оперативно вносить изменения в проект при обнаружении ошибок или изменений условий функционирования на последних этапах проектирования. Для устранения недостатков каскадного проектирования в 70-х годах был предложен итерационная или поэтапная модель с промежуточным контролем[5].