36
Рисунок 4 Различные модели процесса разработки ПО и их
классификация
1.5.1. ГОСТы
ГОСТ 19 «Единая система программной документации» (ГОСТ
19.102-77. «ЕСПД. Стадии разработки») [2] и ГОСТ 34 «Стандарты на
разработку и сопровождение автоматизированных систем» (ГОСТ 34.601-90
«Автоматизированные системы стадии создания») [3] ориентированы на
последовательный подход к разработке ПО. В соответствии с этими
стандартами проект разработки ПО реализуется по этапам, в рамках каждого
их которых предполагается выполнение заранее четко определенных задач, а
в завершении предполагается выпуск объемных четкого формализованных
документов.
Обычно такая методология используется для разработки ПО по
госзаказам.
1.5.2. SW-CMM
Методология SW-CMM, Capability Maturity Model for Software была
разработана в середине 80-х годов XX века в Институте программной
инженерии, входящий в состав Университета Карнеги-Меллона, заказчиком
37
разработки методологии выступило Министерство обороны США. Данная
методология представляет собой образцовую модель организации разработки
ПО и предполагает 5 уровней зрелости процесса разработки ПО:
1. Начальный – хаотический процесс разработки, определенность в
лишь некоторых процессах, успех проекта зачастую зависит от конкретных
исполнителей.
2. Повторяемый – отлажено управление основными ограничениями
проекта (затратами, сроками, функциональностью), отлажена часть
процессов для возможности повторения успехов предыдущих проектов.
3. Определенный – в компании внедрена единая система управления
проектами.
4. Управляемый – собираются детальные количественные данные по
функционированию процессов разработки и качеству конечного продукта.
Анализируется значение и динамика этих данных.
5. Оптимизируемый – постоянное улучшение процессов основывается
на количественных данных по процессам и на пробном внедрении новых
идей и технологий.
Документация с полным описанием SW-CMM занимает около 500
страниц и определяет набор из 312 требований, которым должна
соответствовать организация, если она планирует аттестоваться по этому
стандарту на 5-ый уровень зрелости [18].
1.5.3. RUP
«Унифицированный процесс (Rational Unified Process, RUP) был
разработан Филиппом Крачтеном (Philippe Kruchten), Иваром Якобсоном
(Ivar Jacobson) и другими сотрудниками компании «Rational Software» в
качестве дополнения к языку моделирования UML. Модель RUP описывает
абстрактный общий процесс, на основе которого организация или проектная
команда должна создать конкретный специализированный процесс,
ориентированный на ее потребности» [12].
38
В основе RUP лежит итеративная модель разработки. В завершении
каждой итерации должны быть достигнуты запланированные на данную
итерацию цели, в том числе должна быть получена промежуточная, но
функциональная версия конечного продукта. Такой подход позволяет
оперативно реагировать на изменяющиеся внешние условия и адаптировать
ход проекта.
1.5.4. MSF
«Microsoft Solutions Framework (MSF) – это гибкая и достаточно
легковесная модель, построенная на основе итеративной разработки» [13].
Данная модель уделяет особое внимание к созданию эффективной
проектной команды, предлагая нестандартные и оригинальные подходы к
организационной структуре, распределению ответственности и принципам
взаимодействия внутри команды.
1.5.5. PSP/TSP
Одна из последних разработок Университета Карнеги-Меллон – это
модель «Индивидуальный процесс разработки» (Personal Software Process /
Team Software Process. Personal Software Process). Данная модель
ориентирована на самостоятельную работу разработчика, помогая ему
понимать и совершенствовать собственную производительность
Team Software Process делает ставку на самоуправляемые команды
численностью 3-20 разработчиков. Команды должны:
установить собственные цели;
составить свой процесс и планы;
отслеживать работу;
поддерживать мотивацию и максимальную производительность.
Последовательное применение модели PSP/TSP позволяет сделать
нормой в организации пятый уровень CMM.
1.5.6. Agile
Agile относится к классу гибких методик разработки и представляет
собой серию подходов (итераций), характеризуется динамическим
39
формированием требование в ходе адаптации к изменяющимся условиям
проекта и их реализацией в результате постоянного взаимодействия внутри
проектных групп.
1.5.7. Достоинства и недостатки моделей процесса
Тяжелые и легкие модели производственного процесса имеют свои
достоинства и свои недостатки, представленные в таблице 2.
Таблица 2
Плюсы и минусы тяжелых и легких моделей процессов
разработки ПО
Вес
модели
Плюсы
Минусы
Тяжелые
Процессы рассчитаны на среднюю
квалификацию исполнителей.
Большая специализация
исполнителей. Ниже требования к
стабильности команды.
Отсутствуют ограничения по
объему и сложности выполняемых
проектов.
Требуют существенной
управленческой надстройки.
Более длительные стадии
анализа и проектирования.
Более формализованные
коммуникации.
Легкие
Меньше непроизводительных
расходов, связанных с
управлением проектом, рисками,
изменениями, конфигурациями.
Упрощенные стадии анализа и
проектирования, основной упор на
разработку функциональности,
совмещение ролей. Неформальные
коммуникации.
Эффективность сильно
зависит от индивидуальных
способностей, требуют более
квалифицированной,
универсальной и стабильной
команды.
Объем и сложность
выполняемых проектов
ограничены.
Не существует единственного правильного процесса разработки ПО, в
каждом новом проекте процесс должен определяться каждый раз заново, в
зависимости от проекта, продукта и персонала, в соответствие с «Законом 4-х
П»: Процесс в проекте должен определяться в зависимости от проекта,
продукта и персонала.
1.6. Определения и концепции проекта
Классическое управление проектами выделяет два вида организации
человеческой деятельности: операционная и проектная.
Об операционной деятельности идет речь в случаях, когда внешние
условия стабильны и известны, выполняемые операции проделывались не
один раз и неизменны. При операционной деятельности эффективность
40
достигается за счет узкой специализации сотрудника и повышения его
компетенции.
В случае, если разрабатывается новый продукт, требования к
которому постоянно меняются и внешние условия не постоянны, а также
если операции выполняются в первый раз и необходим поиск новых
возможностей – применяется проектный подход.
Термин «проект» в различных источниках рассматривается с
различных позиций.
Наиболее общее определение проекта можно обозначить так: проект –
это совокупность распределенных во времени задач, направленных на
достижение поставленной цели в рамках заранее определенного бюджета и
заранее определенными ресурсами.
Из этого определения можно вывести ряд свойств, присущих всем
проектам:
1. У проекта всегда должна быть четкая и измеримая цель. Достижение
цели значит успешное окончание проекта.
2. Проект всегда имеет четкое начало – это начало выполнения первой
задачи по достижению поставленной цели.
3. Проект всегда имеет четкое время завершения – это окончание
выполнения последней задачи по достижению поставленной цели.
4. В проекте всегда есть команда проекта, которая выполняет задачи по
достижению поставленной цели. Обязательно должен быть выделен
руководитель проекта. Также могут привлекаться третьи лица для
выполнения некоторых задач.
5. Для выполнения проекта всегда используются материальные
ресурсы. Их состав и количество определяется в зависимости от специфики
проекта, но обязательно должно быть определено перед началом работ по
проекту.
6. Проект всегда должен иметь бюджет. Бюджет проекта складывается
из стоимости ресурсов, используемых в проекте (как материальных, так и
41
человеческих) и прочих расходов, необходимых для достижения цели
проекта.
7. Проект всегда имеет 3 ограничения – бюджет, сроки, ресурсы.
Грамотное управление проектом заключается в грамотном управлении этими
ограничениями в рамках достижения поставленной цели проекта.
Жизненный цикл проекта – это период времени между его началом и
завершением. Он делится на четыре фазы, представленных на рисунке 5:
Рисунок 5. Жизненный цикл проекта
Результат проекта – это ценность (продукция или полезный эффект),
которая создается в процессе выполнения проекта. Критерием успешности
проекта является то насколько его результат соответствует изначально
42
запланированным срокам, бюджету, ресурсам и насколько была достигнута
запланированная изначально цель.
1.7. Методика управления проектами
При внедрении (автоматизации) практически любой ИТ-системы
невозможно обойтись без управления проектом внедрения. Как известно,
любая система управления функционирует только при наличии методологии.
Методология управления проектами предназначена для формализации и
стандартизации подходов к управлению проектами.
Управление проектами – это область управления, охватывающая те
сферы деятельности компании, в которых создание продукта или услуги
реализуется как уникальный комплекс взаимосвязанных целенаправленных
мероприятий при определенных требованиях, касающихся сроков, бюджета и
характеристик ожидаемого результата. Исходя из определения Института
проектного управления, управление проектами означает применение знаний,
навыков, инструментов и методов управления к проектной деятельности для
удовлетворения предъявляемых к проекту требований.
Общепринятые методики управления проектами, стандарты и
ключевые термины содержатся в Руководстве по управлению проектами
«Project Management Body of Knowledge» (PMBOK), которое, по существу,
является сводом профессиональных знаний по управлению проектами.
Под управлением проектом понимается деятельность, направленная
на эффективное достижение целей проекта в установленные строки, в рамках
утвержденного бюджета, с заданным качеством.
«Управление проектами – это приложение знаний, навыков,
инструментов и методов к операциям проекта для удовлетворения
требований, предъявляемых к проекту. Управление проектами выполняется с
помощью применения и интеграции процессов управления проектами:
инициации, планирования, исполнения, мониторинга и управления,
завершения.» [14].
43
1.7.1. Состав управления проектами
В управление проектом входит:
Определение требований
Установка четких и достижимых целей
Уравновешивание противоречащих требований по качеству,
содержанию времени и стоимости
Коррекция характеристик, планов и подхода в соответствии с
мнением и ожиданиями различных участников проекта.
Итак, управление проектом состоит в планировании, организации и
управлении задачами и ресурсами для достижения цели проекта и контроле
стратегии реализации проекта.
Управление проектами – это область менеджмента, охватывающая те
сферы производственной деятельности, в которых создание продукта или
услуги реализуется как уникальный комплекс взаимосвязанных
целенаправленных мероприятий при определенных требованиях к срокам,
бюджету и характеристикам ожидаемого результата.
1.7.2. Субъекты и объекты управления
Субъектами управления в системе управления проектами (СУП)
являются активные участники проекта, взаимодействующие при выработке и
принятии управленческих решений. К ним относятся:
управленческий аппарат заказчика проекта;
управленческий аппарат исполнителя (или исполнителей) проекта;
команды проектов (группы управления, рабочие группы).
К объектам управления относятся:
портфель проектов – совокупность проектов, находящихся в
компетенции одного центра ответственности;
программа – группа взаимосвязанных проектов и различных
мероприятий, объединенных общей целью и условиями их выполнения.
Управление проектами, объединенными в рамках одной программы, обычно
44
требует координации. Программы обычно включают в себя элемент
непрерывной деятельности;
проект – комплекс взаимосвязанных мероприятий, предназначенных
для достижения поставленных целей с установленными требованиями к
качеству результата в течение заданного времени и при установленном
бюджете;
стадии жизненного цикла программ и проектов – набор логически
взаимосвязанных работ проекта, в процессе завершения которых достигается
один из основных результатов проекта. Жизненные циклы проектов в
различных областях деятельности могут существенно различаться.
1.7.3. Процессы и фазы управления проектом
Процессы управления проектом осуществляются на всех стадиях
жизненного цикла проекта и могут быть классифицированы по двум
следующим основаниям - по области применения (области знаний) и по
целевому результату (фазы управления).
К областям знаний в проекте относится управление содержанием и
границами проекта, управление проектом по временным и стоимостным
параметрам, управление качеством, отклонениями и другие.
Жизненный цикл и основные продукты программного проекта
приведены на рисунке 6.
Под фазой процесса управления понимается совокупность
мероприятий (процессов), обеспечивающих достижение одного из
следующих результатов:
санкционирование начала проекта или очередной стадии его
жизненного цикла – инициализация;
определение наилучшего способа действий для достижения целей
стадии жизненного цикла проекта с учетом складывающейся обстановки –
планирование;
реализация плана стадии жизненного цикла проекта (от выдачи
задания до получения результата) – выполнение;
45
выявление фактов отклонения фактического выполнения стадии
жизненного цикла проекта от запланированного и принятие корректирующих
действий – контроль;
завершение и закрытие проекта или стадии жизненного цикла
проекта – завершение.
Рисунок 6 Жизненный цикл и основные продукты программного
проекта
1.8. Планирование проекта
Наиболее эффективными инструментами решения сложной задачи
являются анализ и декомпозиция на более простые подзадачи, которые в
свою очередь могут быть декомпозированы на более мелкие подзадачи и т.д.
На выходе получается некое подобие дерева, в основе которого находится
проект, а на ветвях – простые задачи, которые необходимо выполнить для
завершения проекта при заданных ограничениях.