Файл: 1 разработка сценария внедрения.pdf

53 4. Что указывается в характеристиках объекта автоматиза- ции?
5. Что необходимо определить в требованиях к информаци- онному обеспечению?

6. Что необходимо определить в требованиях к техниче- скому обеспечению?
7. Что необходимо определить в требованиях к программ- ному обеспечению?

8. Что содержат общие требования к проектируемой систе- ме?
9. Специальные технические требования, предъявляемые к системе.
10. Календарный план выполнения работ.

54 3 РАЗРАБОТКА ГРАФИКА РАЗРАБОТКИ И ВНЕДРЕНИЯ
ИНФОРМАЦИОННОЙ СИСТЕМЫ
3.1 ЦЕЛЬ РАБОТЫ
Цель работы – изучение методологии управления проекта- ми, получение навыков по применению данных методологий для разработки графика разработки и внедрения проекта.
3.2 ТЕОРЕТИЧЕСКИЕ ПОЛОЖЕНИЯ
Проблемы управления программными проектами впервые проявились в 60-х – начале 70-х годов. Руководители программ- ных проектов выполняют такую же работу, что и руководители технических проектов. Вместе с тем процесс разработки про- граммного обеспечения (ПО) существенно отличается от процес- сов реализации технических проектов, что порождает определен- ные сложности в управлении программными проектами. Ниже приведѐн краткий список этих отличий.
1. Программный продукт нематериален. Менеджер техни- ческого проекта видит результаты выполнения своего проекта.
Если реализация проекта отстает от графика, это также видно во- очию. В противоположность этому программное обеспечение нематериально. Его нельзя увидеть или потрогать. Менеджер программного проекта не видит процесс «роста» разрабатывае- мого ПО. Он может полагаться только на документацию, которая фиксирует процесс разработки программного продукта.
2. Не существует стандартных процессов разработки ПО.
На сегодняшний день не существует четкой зависимости между процессом создания ПО и типом создаваемого программного продукта. Другие технические дисциплины имеют длительную историю, процессы разработки технических изделий многократно опробованы и проверены. Процессы создания большинства тех- нических систем хорошо изучены. Изучением же процессов соз- дания ПО специалисты занимаются только несколько последних лет. Поэтому пока нельзя точно предсказать, на каком этапе про-

55 цесса разработки ПО могут возникнуть проблемы, угрожающие всему программному проекту.
3. Большие программные проекты – это часто «одноразо- вые» проекты. Большие программные проекты, как правило, зна- чительно отличаются от проектов, реализованных ранее. Поэто- му, чтобы уменьшить неопределенность в планировании проекта, руководители проектов должны обладать очень большим практи- ческим опытом. Но постоянные технологические изменения в компьютерной технике и коммуникационном оборудовании обесценивают предыдущий опыт. Знания и навыки, накопленные опытом, могут не востребоваться в новом проекте.
Перечисленное выше может привести к тому, что реализа- ция проекта выйдет из временного графика или превысит бюд- жетные ассигнования. Программные системы зачастую оказыва- ются новинками как в «идеологическом», так и в техническом плане. Технические проекты, которые являются инновационными
(например, новая транспортная система), также часто нарушают временные графики работ. Поэтому, предвидя возможные про- блемы в реализации программного проекта, следует всегда пом- нить, что многим из них свойственно выходить за рамки времен- ных и бюджетных ограничений.
3.2.1 Планирование проекта
Эффективное управление программным проектом напрямую зависит от правильного планирования работ, необходимых для его выполнения. План помогает менеджеру предвидеть пробле- мы, которые могут возникнуть на каких-либо этапах создания
ПО, и разработать превентивные меры для их предупреждения или решения. План, разработанный на начальном этапе проекта, рассматривается всеми его участниками как руководящий доку- мент, выполнение которого должно привести к успешному за- вершению проекта. Этот первоначальный план должен макси- мально подробно описывать все этапы реализации проекта.
Кроме разработки плана проекта, на менеджера ложится обязанность разработки других видов планов. Эти виды планов кратко описаны в таблице 3.1.

56
Таблица 1 – Виды планов
План
Описание
План качества
Описывает стандарты и мероприятия по поддержке качества разрабатываемого ПО
План аттестации
Описывает способы, ресурсы и перечень работ, необ- ходимых для аттестации программной системы
План управления конфигурацией
Описывает структуру и процессы управления конфи- гурацией
План сопровож- дения ПО
Предлагает план мероприятий, требующихся для со- провождения ПО в процессе его эксплуатации, а так- же расчет стоимости сопровождения и необходимые для этого ресурсы
План по управлению персоналом
Описывает мероприятия, направленные на повыше- ние квалификации членов команды разработчиков
В примере 1 показан процесс планирования создания ПО в виде псевдокода. Здесь сделан акцент на том, что планирование – это итерационный процесс. Поскольку в процессе выполнения проекта постоянно поступает новая информация, план должен регулярно пересматриваться. Важными факторами, которые должны учитываться при разработке плана, являются финансо- вые и деловые обязательства организации. Если они изменяются, эти изменения также должны найти отражение в плане работ.
Пример 1. Процесс планирования проекта.
Определение проектных ограничений
Первоначальная оценка параметров проекта
Определение этапов выполнения проекта и контрольных отметок
While loop (Пока проект не завершится или не будет оста- новлен)
Составление графика работ
Начало выполнения работ
Ожидание окончания очередного этапа работ
Отслеживание хода выполнения работ
Пересмотр оценок параметров проекта
Изменение графика работ
Пересмотр проектных ограничений

57
If (возникла проблема) then
Пересмотр технических или организационных параметров проекта
End if
End loop
Процесс планирования начинается с определения проектных ограничений (временные ограничения, возможности наличного персонала, бюджетные ограничения и т. д.). Эти ограничения должны определяться параллельно с оцениванием проектных па- раметров, таких как структура и размер проекта, а также распреде- лением функций среди исполнителей. Затем определяются этапы разработки и то, какие результаты (документация, прототипы, под- системы или версии программного продукта) должны быть полу- чены по окончании этих этапов. Далее начинается циклическая часть планирования. Сначала разрабатывается график работ по вы- полнению проекта или дается разрешение на продолжение исполь- зования ранее созданного графика. После этого (обычно через 2–3 недели) проводится контроль выполнения работ и отмечаются рас- хождения между реальным и плановым ходом работ.
Далее, по мере поступления новой информации о ходе вы- полнения проекта, возможен пересмотр первоначальных оценок параметров проекта. Это, в свою очередь, может привести к из- менению графика работ. Если в результате этих изменений нару- шаются сроки завершения проекта, должны быть пересмотрены
(и согласованы с заказчиком ПО) проектные ограничения.
Конечно, большинство менеджеров проектов не думают, что реализация их проектов пройдет гладко, без всяких проблем. Жела- тельно описать возможные проблемы еще до того, как они проявят себя в ходе выполнения проекта. Поэтому лучше составлять «пес- симистические» графики работ, чем «оптимистические». Но, ко- нечно, невозможно построить план, учитывающий все, в том числе случайные, проблемы и задержки выполнения проекта, поэтому и возникает необходимость периодического пересмотра проектных ограничений и этапов создания программного продукта.

58
3.2.2 План проекта
План проекта должен четко показать ресурсы, необходимые для реализации проекта, разделение работ на этапы и временной график выполнения этих этапов. В некоторых организациях план проекта составляется как единый документ, содержащий все ви- ды планов, описанных выше. В других случаях план проекта опи- сывает только технологический процесс создания ПО. В таком плане обязательно присутствуют ссылки на планы других видов, но они разрабатываются отдельно от плана проекта.
План, представленный ниже, принадлежит именно к по- следнему типу планов. Детализация планов проектов очень раз- нится в зависимости от типа разрабатываемого программного продукта и организации-разработчика. Но в любом случае боль- шинство планов содержат следующие разделы.
1. Введение. Краткое описание целей проекта и проектных ограничений (бюджетных, временных и т. д.), которые важны для управления проектом.
2. Организация выполнения проекта. Описание способа подбора команды разработчиков и распределение обязанностей между членами команды.
3. Анализ рисков. Описание возможных проектных рисков, вероятности их проявления и стратегий, направленных на их уменьшение. Тема управления рисками рассмотрена ниже.
4. Аппаратные и программные ресурсы, необходимые для реализации проекта. Перечень аппаратных средств и программ- ного обеспечения, необходимого для разработки программного продукта. Если аппаратные средства требуется закупать, приво- дится их стоимость совместно с графиком закупки и поставки.
5. Разбиение работ на этапы. Процесс реализации проекта разбивается на отдельные процессы, определяются этапы выпол- нения проекта, приводится описание результатов («выходов») каждого этапа и контрольные отметки. Эта тема представлена ниже.
6. График работ в этом графике отображаются зависимости между отдельными процессами (этапами) разработки ПО, оценки времени их выполнения и распределение членов команды разра- ботчиков по отдельным этапам.

59 7. Механизмы мониторинга и контроля за ходом выполне- ния проекта. Описываются предоставляемые менеджером отчеты о ходе выполнения работ, сроки их предоставления, а также ме- ханизмы мониторинга всего проекта.
План должен регулярно пересматриваться в процессе реали- зации проекта. Одни части плана, например, график работ, изме- няются часто, другие более стабильны. Для внесения изменений в план требуется специальная организация документопотока, по- зволяющая отслеживать эти изменения.
3.2.3 Контрольные отметки этапов работ
Менеджеру для организации процесса создания ПО и управления им необходима информация. Поскольку само про- граммное обеспечение неосязаемо, эта управленческая информа- ция может быть получена только в виде документов, отобра- жающих выполнение очередного этапа разработки программного продукта. Без этой информации нельзя судить о степени готовно- сти создаваемого продукта, невозможно оценить произведенные затраты или изменить график работ.
При планировании процесса определяются контрольные от- метки – вехи, отмечающие окончание определенного этапа работ.
Для каждой контрольной отметки создается отчет, который пре- доставляется руководству проекта. Эти отчеты не должны быть большими объемными документами; они должны подводить краткие итоги окончания отдельного логически завершенного этапа проекта. Этапом не может быть, например, «Написание
80% кода программ», поскольку невозможно проверить заверше- ние такого «этапа»; кроме того, подобная информация практиче- ски бесполезна для управления, поскольку здесь не отображается связь этого «этапа» с другими этапами создания ПО.
Обычно по завершении основных больших этапов, таких как разработка спецификации, проектирование и т. п., заказчику ПО предоставляются результаты их выполнения, так называемые контрольные проектные элементы. Это может быть документа- ция, прототип программного продукта, законченные подсистемы
ПО и т. д. Контрольные проектные элементы, предоставляемые заказчику ПО, могут совпадать с контрольными отметками (точ-

60 нее, с результатами выполнения какого-либо этапа). Но обратное утверждение неверно. Контрольные отметки – это внутренние проектные результаты, которые используются для контроля за ходом выполнения проекта, и они, как правило, не предоставля- ются заказчику ПО.
Для определения контрольных отметок весь процесс созда- ния ПО должен быть разбит на отдельные этапы с указанным
«выходом» (результатом) каждого этапа. Например, на рисун- ке 3.1 показаны этапы разработки спецификации требований в случае, когда для ее проверки используется прототип системы, а также представлены выходные результаты (контрольные отмет- ки) каждого этапа. Здесь контрольными проектными элементами являются требования и спецификация требований.
Рисунок 3.1 – Этапы процесса разработки спецификации
3.2.4 График работ
Составление графика – одна из самых ответственных работ, выполняемых менеджером проекта. Здесь менеджер оценивает длительность проекта, определяет ресурсы, необходимые для реализации отдельных этапов работ, и представляет их (этапы) в виде согласованной последовательности. Если данный проект подобен ранее реализованному, то график работ последнего про- екта можно взять за основу для данного проекта. Но затем следу- ет учесть, что на отдельных этапах нового проекта могут исполь- зоваться методы и подходы, отличные от использованных ранее.
Если проект является инновационным, первоначальные оцен- ки длительности и требуемых ресурсов наверняка будут слишком оптимистичными, даже если менеджер попытается предусмотреть все возможные неожиданности. С этой точки зрения проекты соз- дания ПО не отличаются от больших инновационных технических проектов. Новые аэропорты, мосты и даже новые автомобили, как правило, появляются позже первоначально объявленных сроков их

61 сдачи или поступления на рынок, чему причиной являются неожи- данно возникшие проблемы и трудности. Именно поэтому графики работ необходимо постоянно обновлять по мере поступления но- вой информации о ходе выполнения проекта.
В процессе составления графика (рисунок 3.2) весь массив работ, необходимых для реализации проекта, разбивается на от- дельные этапы и оценивается время, требующееся для выполне- ния каждого этапа. Обычно многие этапы выполняются парал- лельно. График работ должен предусматривать это и распреде- лять производственные ресурсы между ними наиболее оптималь- ным образом. Нехватка ресурсов для выполнения какого-либо критического этапа – частая причина задержки выполнения всего проекта.
Рисунок 3.2 – Процесс составления графика работ
Длительность этапов обычно должна быть не меньше недели.
Если она будет меньше, то окажется ниже точности временных оценок этапов, что может привести к частому пересмотру графика работ. Также целесообразно (в аспекте управления проектом) уста- новить максимальную длительность этапов, не превышающую
8 или 10 недель. Если есть этапы, имеющие большую длитель- ность, их следует разбить на этапы меньшей длительности.
При расчете длительности этапов менеджер должен учиты- вать, что выполнение любого этапа не обойдется без больших или маленьких проблем и задержек. Разработчики могут допус- кать ошибки или задерживать свою работу, техника может выйти из строя либо аппаратные или программные средства поддержки процесса разработки могут поступить с опозданием. Если проект инновационный и технически сложный, это становится дополни- тельным фактором появления непредвиденных проблем и увели- чения длительности реализации проекта по сравнению с первона- чальными оценками.

62
Кроме временных затрат, менеджер должен рассчитать дру- гие ресурсы, необходимые для успешного выполнения каждого этапа. Особый вид ресурсов – это команда разработчиков, при- влеченная к выполнению проекта. Другими видами ресурсов мо- гут быть необходимое свободное дисковое пространство на сер- вере, время использования какого-либо специального оборудова- ния и бюджетные средства на командировочные расходы персо- нала, работающего над проектом.
Существует хорошее эмпирическое правило: оценивать временные затраты так, как будто ничего непредвиденного и
«плохого» не может случиться, затем увеличить эти оценки для учета возможных проблем. Возможные, но трудно прогнозируе- мые проблемы существенно зависят от типа и параметров проек- та, а также от квалификации и опыта членов команды разработ- чиков. К исходным расчетным оценкам рекомендуется добавлять
30% на возможные проблемы и затем еще 20%, чтобы быть гото- вым к тому, что невозможно предвидеть.
График работ по проекту обычно представляется в виде на- бора диаграмм и графиков, показывающих разбиение проектных работ на этапы, зависимости между этапами и распределение разработчиков по этапам.
Временные и сетевые диаграммы полезны для представле- ния графика работ. Временная диаграмма показывает время на- чала и окончания каждого этапа и его длительность. Сетевая диа- грамма отображает зависимости между различными этапами про- екта. Эти диаграммы можно создать автоматически с помощью программных средств поддержки управления на основе инфор- мации, заложенной в базе данных проекта.
Рассмотрим этапы некоего проекта, представленные в таб- лице 3.2, из которой, в частности, видно, что этап Т3 зависит от этапа Т1. Это значит, что этап Т1 должен завершиться прежде, чем начнется этап Т3. Например, на этапе Т1 проводится компо- нентный анализ создаваемого программного продукта, а на этапе
Т3 – проектирование системы.
На основе приведенных значений длительности этапов и за- висимости между ними строится сетевой график последователь- ности этапов (рисунок 3.3). На этом графике видно, какие работы могут выполняться параллельно, а какие должны выполняться

63 последовательно друг за другом. Этапы обозначены прямоуголь- никами. Контрольные отметки и контрольные проектные элемен- ты показаны в виде овалов и обозначены (как и в таблице 3.2) бу- квой М с соответствующим номером. Даты на данной диаграмме соответствуют началу выполнения этапов. Сетевую диаграмму следует читать слева направо и сверху вниз.
Рисунок 3.3 – Сетевая диаграмма этапов
Таблица 3.2 – Этапы проекта
Этап
Длительность (дни)
Зависимость
Т1 8
Т2 15
Т3 15
Т1 (М1)
Т4 10
Т5 10
Т2, Т4 (М2)
Т6 5
Т1, Т2 (М3)
Т7 20
Т1 (М1)
Т8 25
Т4 (М5)
Т9 15
Т3, Т6 (М4)
Т10 15
Т5, Т7 (М7)
Т11 7
Т9 (М6)
Т12 10
Т11 (М8)