Тема 21. Общие этапы по разработке ПО

План лекции

1. Инициация проекта

2. Планирование проекта

3. Реализация проекта

4. Завершение проекта

 

Инициация проекта

Каждая ИС имеет собственный жизненный цикл, в который проект разработки очередного релиза входит как одна из стадий Аналогично, каждый проект разработки ПО имеет свой собственный жизненный цикл, состоящий из четырех фаз (таблица 21.1).

Таблица 21.1. Жизненный цикл и основные продукты проекта по созданию ИС

Этап	Артефакт
Инициация	- концепция;
Планирование	- требования к системе; - план управления;
Реализация	- рабочее описание - отчет о состоянии - документы проекта - исходные коды;
Завершение	- протоколы и приемо-сдаточные испытания; - итоговый отчет; - архив проекта.

 

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

Согласно терминологии PMBOK, вместо понятия «концепция» используется понятие «Устав проекта» – это документ, выпущенный инициатором или спонсором проекта, который формально узаконивает существование проекта и предоставляет менеджеру проекта полномочия использовать организационные ресурсы в операциях проекта. Концепция проекта разрабатывается на основе анализа потребностей бизнеса. Цель данного документа – подтверждение и согласование единого видения целей, задач и результатов всеми участниками проекта. Концепция проекта используется для принятия решений в ходе всего проекта, а также на фазе приемки – для подтверждения результата. Как правило, концепция проекта содержит следующие разделы:

1) название проекта;

2) цели проекта;

3) результаты проекта;

4) допущения и ограничения;

5) ключевые участники и заинтересованные стороны;

6) ресурсы проекта;

7) сроки;

8) риски;

9) критерии приемки;

10) обоснование целесообразности проекта.

Цели проекта. Цели проекта должны отвечать на вопрос «зачем» данный проект нужен. Цели проекта должны описывать бизнес потребности и задачи, которые решаются в результате исполнения проекта.

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

- изменения в компании. Например, автоматизация ряда бизнес-процессов для повышения эффективности основной производственной деятельности;

- реализация стратегических планов. Например, завоевание значительной доли растущего рынка за счет вывода на него нового продукта;

- выполнение контрактов. Например, разработка программного обеспечения по заказу.

Разрешение специфических проблем. Например, доработка программного продукта в целях приведения его в соответствие с изменениями в законодательстве.

Результаты проекта. Результаты проекта отвечают на вопрос, что должно быть получено после его завершения. Результаты проекта должны определять:

- какие конкретно преимущества получит заказчик в результате проекта;

- что именно будет произведено по окончании проекта (т.е. какие продукт или услуга);

- краткое описание продукта или услуги.

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

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

В частности они могут содержать:

- специфические нормативные требования. Например, обязательная сертификация продукта, услуги на соответствие определенным стандартам;

- специфические технические требования. Например, разработка под заданную программно-аппаратную платформу;

- специфические требования к защите информации.

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

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

К ключевым участникам, как правило, относятся:

- спонсор проекта – лицо или группа лиц, предоставляющая финансовые ресурсы для проекта в любом виде;

- заказчик проекта – лицо или организация, которые будут использовать продукт, услугу или результат проекта. Заказчик и спонсор проекта не всегда совпадают;

- пользователи результатов проекта;

- куратор проекта – представитель исполнителя, уполномоченный принимать решение о выделении ресурсов и изменениях в проекте;

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

- - соисполнители проекта – субподрядчики и поставщики.

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

- людские ресурсы и требования к квалификации персонала;

- оборудование, услуги, расходные материалы, лицензии на ПО, критические компьютерные ресурсы;

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

Специфика программного проекта заключается в том, что людские ресурсы вносят основной вклад в его стоимость. Все остальные затраты, как правило, незначительны, по сравнению с этим расходами. Необходимо помнить, что помимо непосредственно программирования в проекте разработки ПО есть много других процессов (анализ и уточнение требований, проектирование, документирование, тестирование и пр.), которые требуют ресурсы соответствующей квалификации, а само программирование составляет лишь четверть всех затрат. На фазе инициации хорошей считается оценка трудозатрат с точностью от -50% до +100%.

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

Современный проект разработки ПО должен реализовываться с применением инкрементального процесса. В этом случае контрольные точки должны соответствовать выпуску каждой промежуточной версии ПО, в которой будет реализована и протестирована определенная часть конечной функциональности программного продукта. В зависимости от сложности и масштаба проекта продолжительность одной итерации может составлять от 2 до 8 недель.

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

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

Обоснование целесообразности проекта. Этот раздел концепции должен содержать краткое технико-экономическое обоснование проекта:

- для кого предназначены результаты проекта (конечные пользователи);

- описание текущей ситуации «AS-IS» и перечень существующих у заказчика проблем бизнеса;

- описание будущей модели «TO-BE», с помощью которой показывается, каким образом результаты проекта решают данные проблемы;

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

 

Планирование проекта

Уточнение содержания и состава работ. Согласно теории систем, наиболее эффективным способом решения сложной задачи является анализ и декомпозиция задачи на более простые подзадачи, которые, в свою очередь, могут быть разделены на функции и так далее. При этом деление осуществляется с соблюдением иерархии. Таким образом, формируется некоторая иерархическая структура или дерево, в корне которого находится проект, а на листьях элементарные задачи или работы, которые надо выполнить, чтобы завершить проект в условиях заданных ограничений. Согласно терминологии PMBOK, иерархическая структура работ (ИСР, Work /Breakdown Structure, WBS) – ориентированная на результат иерархическая декомпозиция работ, выполняемых командой проекта для достижения целей проекта и необходимых результатов. С ее помощью структурируется и определяется все содержание проекта. Каждый следующий уровень иерархии отражает более детальное определение элементов проекта.

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

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

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

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

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

- определить источники запросов на изменение;

- установить порядок анализа, оценки и утверждения/отклонения изменения содержания;

- определить порядок документирования изменений содержания;

- определить порядок информирования об изменении содержания.

Первая задача, которую необходимо решить при анализе запроса на изменения – выявить объекты изменений: требования, архитектура, структуры данных, исходные коды, сценарии тестирования, пользовательская документация, проч. Затем требуется спроектировать и детально описать изменения во всех выявленных объектах. И наконец, следует оценить затраты на внесение изменений, тестирование изменений и регрессионное тестирование продукта и их влияние на сроки проекта.

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

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

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

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

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

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

- объективную проверку соответствия программных продуктов и технологических операций применяемым стандартам, процедурам и требованиям;

- определение отклонений по качеству, выявление их причин, применение мер по их устранению, а также контроль исполнения принятых мер и их эффективности;

- представление высшему руководству независимой информации о несоответствиях, не устраняемых на уровне проекта.

Помимо перечисленных разделов план проекта должен включать еще:

- план управления рисками;

- оценку трудоемкости и сроков работ.

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

Для проекта следует определить критический путь проекта (Critical path) – самую длинную цепочку работ в проекте. Увеличение длительности любой работы в этой цепочки приводит к увеличению длительности всего проекта. В проекте всегда существует хотя бы один критический путь, но их может быть несколько. Критический путь может меняться во время исполнения проекта. При исполнении проекта руководитель должен обращать внимание на исполнение задач на критическом пути в первую очередь и следить за появлением других критических путей. Практическая рекомендация: на критическом пути должны стоять работы с нежесткими связями, которые всегда можно перепланировать, если возникает угроза срыва сроков.

 

Реализация проекта

Рабочее планирование. Для управления проектом требуется осуществлять стратегическое и оперативное планирование. Базовое расписание, составленное на этапе планирования проекта, служит ориентиром для мониторинга состояния дел на макро- уровне. Для оперативного управления проектом используется рабочий план.

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

Элементарная работа, как правило, представляет собой отдельное функциональное требование к программному продукту или запрос на изменение, над которым последовательно работают: бизнес-аналитик, проектировщик, разработчик, тестировщик и документалист. Трудоемкость элементарной работы каждого из исполнителей должна быть от 4 до 20 чел.-час. Если трудоемкость задачи не укладывается в эти пределы, следует провести декомпозицию работы. Для рабочего планирования целесообразно использовать систему управления задачами или багтрекинга, поскольку она позволяет задавать последовательность переходов задачи от исполнителя к исполнителю, управлять приоритетами работ и адекватно отслеживать их статус: анализ, проектирование, кодирование, тестирование, документирование. Работа должна считаться законченной только тогда, когда реализация требования протестирована и документирована.

Рекомендуется проводить еженедельные собрания по статусу проекта всей команды или, если проект достаточно большой, то ключевых его частников: руководителей подпроектов и лидеров команд. Хорошее время для этого утро понедельника, поскольку участники проекта, особенно студенты, которые совмещают учебу и работу, часто работают в выходные, потому что им так удобнее. Обсуждаются, как правило, всего три вопроса:

- угрозы и проблемы;

- анализ результатов за неделю;

- уточнение приоритетов задач на новую неделю.

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

- допустимые отклонения – предполагается, что никаких управляющих воздействий не требуется;

- критичные отклонения – требуется тщательный анализ причин отклонения и при необходимости применение корректирующих действий;

- недопустимые отклонения – требуется срочный анализ причин отклонения и обязательное применение корректирующих действий.

Измерения необходимо производить регулярно. Цель – выявить причины наступивших или возможных критичных и недопустимых отклонений. Результатом анализа должны стать планирование корректирующих действий по компенсации недопустимых отклонений, их реализация и мониторинг результативности применения этих корректирующих действий. Измерения по проекту необходимо выполнять регулярно, не реже одного раза в 1-2 недели. Все измерения необходимо сохранять в репозитарии проекта. Измерения, накопленные в ходе проекте, являются наиболее достоверной основой при детальной оценке и планировании работ на следующих итерациях проекта. Поскольку главная задача менеджера удержать проект в пределах «железного» треугольника, то, в первую очередь, необходимо анализировать отклонения проекта по срокам и затратам. В управлении программным продуктом целесообразно применять следующие измеримые показатели:

- показатель прогресса проекта – это доля реализованных и проверенных высокоуровневых требований к проекту, например, отношение числа завершенных сценариев использования продукта к их общему числу;

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

- текущий размер проекта – количество строк исходного кода, добавленных, измененных и удаленных в ходе выполнения проекта разработки ПО. Чем больше объем исходного кода, тем больше времени потребуется на внесение изменений и исправление ошибок;

- средняя производительность – отношение текущего размера проекта к фактическим затратам по проекту;

- качество программного продукта – это группа количественных показателей, таких как, дефектность продукта, доля неустраненных дефектов, средние затраты на сопровождение, документированность кода.

 

Завершение проекта

Главная цель этой фазы – проверить и передать заказчику результат проекта. Для этого необходимо выполнить приемо-сдаточные работы в соответствии с процедурой приемки. Результаты проекта должны быть переданы во внедрение или сопровождение, или должным образом законсервированы для дальнейшего использования. Не должно оставаться «зависших» работ по проекту.

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

1) Итоги проекта:

- достижение целей проекта;

- дополнительные полезные результаты;

- фактические сроки;

- фактические расходы;

- обоснование отклонения от целей;

- отклонения результатов от требований;

2) Уроки проекта:

- проблемы проекта и способы их решения;

- материалы программные компоненты для последующего использования;

- предложения по изменению технологий или стандартов компании.

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