Лаврищева Е.М., Петрухин В.А. Методы и средства инженерии программного обеспечения
Подождите немного. Документ загружается.
231
взялся за реализацию программного проекта, как правило, то ему необходимо
учитывать такие особенности программного продукта:
– этот продукт не материален, его нельзя увидеть в процессе конструирования (как
это имеет место, например, при строительстве здания) и повлиять на его реализацию
более оперативно;
– стандарты ЖЦ прямо не ориентированы на нужный вид продукта, как это имеет
место в технических дисциплинах (автомобильной, авиационной и др.), их необходимо
адаптировать к виду и типу проекта и разработать методики их выполнения
исполнителями;
– программные продукты создают длительное время на компьютерной технике,
которая быстро устаревает в виду постоянного обновления архитектуры.
– элементной базы и языков программирования.
Эта концепция
обеспечивает концентрацию внимания менеджера на критических
роботах. Однако, основным преимуществом метода критического пути есть
возможность управления сроками выполнение задач, которые не лежат на критическом
пути. Этот метод разрешает рассчитать возможные календарные графики выполнения
комплекса работ на основе описанной логической структуры сети и оценок времени
выполнения выполнение каждой работы [1–4].
Накопленный опыт в
создании технических проектов был систематизирован (в
институте управления проектами в США) и разработано ядро знаний – РMBOK
(Project Management Body of Knowledge [2]. В нем малыми проектами считаются
проекты, содержащие 100 работ и 15 исполнителей, средними – 500 работ и 50
исполнителей и большими – 1000 работ и 100 исполнителей.
В ядре РМВОК определены основные аспекты разработки проектов:
– методы управления, планирования и контроля работ;
– эффективная организация проектной группы (команды);
– инструментарий менеджера проекта (например, система Project Management фирмы
Microsoft ).
10.1.1. Методы управления программным проектом
Сложилось несколько методов, эффективно применяемых в практике реализации
программных проектов. Рассмотрим их.
10.1.1.1. Метод критического пути СРМ
Оснополагающим моментом создания этого метода является исследование
возможности эффективного использования вычислительной машины Univac на фирме
“Dupon” при планировании и создании планов-графиков больших комплексов работ
по модернизации заводов этой фирмы. В результате был создан рациональный и
простой метод (Уолкера – Келли) управления проектом с использованием ЭВМ,
который был назван CPM (Critical Path Method ) методом критического пути.
Критический путь - наиболее длинный полный путь в сети; работы, которые лежат на
этом пути, также называются критическими. Именно продолжительность критического
пути определяет наименьшую общую продолжительность работ из проекта в целом.
Время выполнения всего проекта в целому может быть сокращен за счет сокращения
времени выполнения задач, которые лежат на критическом пути. Соответственно,
любая задержка выполнения задач критического пути приводит к увеличению времени
232
выполнения проекта. Эта концепция обеспечивает концентрацию внимания менеджера
на критических роботах. Однако, основным преимуществом метода критического пути
есть возможность управления сроками выполнение задач, которые не лежат на
критическом пути. Этот метод разрешает рассчитать возможные календарные графики
выполнения комплекса работ на основе описанной логической структуры сети и оценок
времени выполнения выполнение каждой работы [1–6].
Метод основан на графическом представлении задач (работ) и видов действий на
проекте и заданием ориентировочного времени их выполнения. Это представление
задается в виде графа (рис 10.1), в вершинах которого располагаются работы и время
выполнения каждой работы под вершинами либо на дугах графа. Граф целесообразно
строить тогда, когда работы и время их выполнения являются заданными
(определенными).
А 1нед. F
3нед. 3 нед.
начало 2 нед. конец
работ работ
A2
4 нед. 2 нед.
Рис.10.1. Граф задания сроков выполнения работ
Критический путь в графе указывает максимальную продолжительность работ на
графе (от начальной работы до последней). При выполнении проекта выбираются и
выполняются работы, которые не влияют на время выполнения других (независимых)
работ
проекта или на их продолжительность. Работы на критическом пути могут
сокращаться за счет изменения времени выполнения.
Представление в таком виде работ называется сетевая диаграммой и служит для
графическое отображение работ проекта, их взаимосвязей, последовательностей и
времени выполнения. В графе вершины отображают работы, а линии взаимные связи
между работами. Этот граф является наиболее распространенным представлением сети
на сегодняшний день.
10.1.1.2. Метод анализа и оценки PERT
Параллельно с разработкой CPM, в военно-морских силах США был создан (фирма
"Буз, Аллен & Гамильтон") метод анализа и оценки программ PERT (Program
Evaluation and Review Technique) для реализации проекта разработки ракетной системы
"Polaris", объединяющей около 3800 подрядчиков с числом операций более 60 тыс. [6].
Применение метода PERT позволяло
точно знать руководству данной программы, что
нужно делать в каждый момент времени и какой исполнитель это делает, а также
определять вероятность своевременного завершения отдельных операций. Руководство
программой создания ракетной системы оказалось настолько успешным, что проект
удалось завершить на два года раньше запланированного срока.
А3
А6
A1
А4
А5
233
Метод PERT представляется сетевыми диаграммами с вершинами-событиями, а
работа – в виде линии между двумя событиями, отображающими начало и конец
данной работы. В целом расхождения между этими двумя методами сетевого
представления графа работ являются незначительными. Однако этот метод, в отличие
от CMP, учитывает возникающие неопределенности во времени выполнения каждой
операции.
Представление более
сложных связей между работами для задания узлов графа в виде
вершина-событие является более сложным и потому этот метод реже используется на
практике.
В этом методе возможное время выполнения операций оценивается с помощью трех
оценок:
– оптимистичной (О),
– пессимистической (P),
– вероятностной (B).
А далее вычисляется по формуле: (О+4В+П)/6, c указанием
его на сетевом графике.
Для уменьшения провалов проектов используются и другие аналитические методы и
усовершенствованные языки разработки систем. Как показывает опыт, "продвинутые"
технологии решают вопросы успешного создания проекта с учетом факторов, которые
уменьшают его провал [3]:
1. Проект начинать с правильного шага.
2. Поддержка темпа работы.
3. Обеспечение прогресса и правильных решений.
4. Посмертный анализ завершенного проекта.
1). Проект начинать с правильного шага. К правильному шагу относится
формирование команды разработчиков из хороших специалистов, в том числе не
более 20% звезд, наиболее приспособленных для хорошей работы над проектом
(много звезд - создание конфликтов). В команду входят надежные разработчики с
совместимыми характерами и рабочими привычками. Звезды решают сложные
вопросы, разрабатывают более ответственные алгоритмы и проводят техническое
обучение остальных членов команды. Для уточнения всех особенностей проекта
разработчики садятся за стол переговоров с заказчиком и составляют взаимно
приемлемый документ.
Следующий шаг - это создание среды для эффективной работы и уменьшения
вероятности возникновения конфликтов. Продуктивной среда для работы команды
являются: белые стены мест встреч для формальных и неформальных переговоров,
личные рабочие места и современные лицензионные компьютерные средства.
2). Поддержка темпа работы состоит в:
– уменьшении текучести кадров;
– контроле качества выполняемых работ;
– управлении процессом разработки, а не людьми.
Текучесть кадров – проблема программной индустрии, так как перемещение или
уход отдельного специалиста, вынуждает других членов группы к трудоемкой работе,
234
связанной с изучением незаконченных и не полностью документированных программ.
Большой промежуток времени между уходом специалиста и нахождением замены
может привести к краху отдельных частей проекта.
Контроль качества необходимое условие создания качественного проекта. Им
занимаются с самого начала разработки проекта, устанавливая процедуры проверки
качества, а также используя разработчиков, которые могут создавать
высококачественный продукт.
Управление процессом разработки. Исполнители должны пользоваться свободой для
прихода на работу в нефиксированное время и в нестрогой одежде. Требуется
управлять разработкой, подвергая критике результаты труда, а не режим работы.
3. Поддержка прогресса и правильных решений. Программа отличается от других
продуктов тем, что ее нельзя пощупать. Разработка программы начинается с
концептуальной модели, а результаты ее применения влияют на получение продукта.
Для поддержки прогресса, как правило, выбирается технологии с необходимым
экономическим и технологическим анализом, который отвечает требованиям рынка и
важности компании.
4. Посмертный анализ. Это изучение своих ошибок при реализации предыдущего
проекта, чтобы не повторить их в новом проекте. Так как каждая команда и фирма
имеет свои особенности, которые влияют на процесс разработки, то при анализе
можно выделить закономерности , которые влияют на получение результатов.
10.1.2. Планирование проекта
Планирование представляет собой процесс распределения и назначения ресурсов
(материальных и людских) с учетом стоимости и времени выполнения проекта.
Планирования являются необходимой предпосылкой выполнения любой, даже самой
простой задачи. Неадекватное планирование может привести к срыву проекта или к
получению в среде проекта неадекватных результатов.
Планирование и перепланирование представляет собой наиболее емкостную во
времени часть управления проектом, в особенности на ранних стадиях проекта. В
прошлом, проекты в области программных систем не имели планов и оценок их
следования и выполнения. Современные методики предлагают средства для
исправления этой ситуации, предоставляя в распоряжение менеджеров инструменты и
методы, которые разрешают работать в направлении достижения реальных и
достижимых оценок работ и планов.
Планирование в том или ином виде выполняется в течение всего срока реализации
проекта. В начале ЖЦ проекта обычно разрабатывается неофициальный
первоначальный план - грубое представление о том, что потребуется выполнить в
случае реализации проекта. Решение о выборе проекта в значительной мере базируется
на оценках этого первоначального плана. Формальное и детальное планирование
проекта начинается после принятия решения о его реализации.
Планирование заключается в составлении следующих планов:
– работ со сроками их выполнения по методу критического пути СРМ или PERT;
– достижения требуемого качества методами проверки промежуточных результатов
процессов ЖЦ;
235
– управление рисками,
– аттестации результатов проектирования и деятельности исполнителей проекта,
– управление конфигурацией и др.
Составляется график работ по следующей схеме (рис.10.2):
Определение Связь Оценка Распределение Определение
этапов между ресурсов персонала графика
этапами для этапа по этапам
Требования График
к проекту
Рис.10.2. Шаги составления графика работ на проекте
При планировании по методу PERT событие или дата в плане является некоторой
вехой осуществления отдельных работ проекта. Веха используется для отображения
(отметки) состояния завершения тех или иных работ. В контексте проекта менеджеры
используют вехи для того, чтобы обозначить важные промежуточные результаты,
которые должны быть достигнуты в процессе реализации проекта. Последовательность
вех, определенных менеджером, часто называется планом по вехам или по событиям.
Определение плана достижения соответствующих вех образуют календарный план на
основе вех.
На этапе планирования могут использоваться также сетевая разбивка работ (СРР) и
диаграммы Ганта [7].
СРР представляет собой иерархическая структура последовательной декомпозиции
задач проекта на подзадачи. На нижнем уровне располагаются работы, которые
являются детализированным элементами деятельности, они отображаются в сетевой
модели СРР, как в иерархической структуре и помогают провести:
– структуризацию работ на основные компоненты и подкомпоненты,
– определить направления деятельности для достижения комплекса целей,
– распределить ответственных за выполнение отдельных работ на проектеа,
– получить отчетность и обобщение информации по проекту.
План содержит описание цикла разработки ПС по фазам, состояниям проекта и
представлением каждой из них в терминах отдельных задач или деятельностей. В плане
отражаются связи между процессами и определяется интервал времени для
выполнения каждой деятельности, а также время ее начала и завершения. В план работ
включается также описание разных видов демонстраций заказчику: функций,
подсистем, надежности, защиты и др. К документам плана относятся: комплект
руководства пользователя для выполнения заданного набора операций, коммуникации
системы с другими подсистемами и др.
Диаграмма Ганта - горизонтальная линейная диаграмма, на которой задачи проекта
представляются сроками в виде отрезков времени и имеют даты начала и окончания,
возможно с задержками и другими временными параметрами.
236
План в виде графа СРР имеет фазы, шаги и деятельности, а также начало и
конечную деятельность на процессе (рис.10.3).
Фаза 1 Шаг 1 Деятельность 1.1
шаг 2 деятельность 1.2
. .
. .
Проект Фаза 2 Шаг 1 Деятельность 2.1
шаг 2 деятельность 3.2
. .
. . .
.
Фаза n Шаг 1
шаг2
Рис 10.3. Пошаговый граф плана проекта
Каждая фаза описывается с помощью параметров:
– начальная точка выполнения процесса,
– продолжительность,
– срок,
– результат (конечная точка).
При построении сетевого графика работ создается граф (рис.10.4), в котором
указываются:
начальная точка – событие или набор событий, которые произошли до начала
выполнения данной фазы процесса, и для которой описывается набор условий начала
процесса;
продолжительность – интервал времени, за которое процесс должен успешно
завершить свое выполнение;
срок – дата, до которой процесс полностью или частично завершает свое выполнение;
конечная точка процесса – контрольная точка, в которой заказчик проверяет качество
полученных результатов процесса.
Дуге, выходящей из начальной вершины и входящей в заключительную вершину,
соответствует временная пометка 0. С помощью этих меток задается время выполнения
процесса.
В графе могут присутствовать циклические пути. По графу проводят анализ
критических путей, т.е. определяют данные о продолжительности каждого процесса.
План проекта проводится в терминах этапов: планирование, проектирование,
кодирование, тестирование и сопровождение. Для первых двух методов планирование
затрагивает: определение спецификаций, бюджета и расписания, а также развития
плана проекта в целом.
В графе могут присутствовать циклические пути. По графу проводят анализ
критических путей, т.е. определяют данные о продолжительности каждого процесса.
План проекта проводится в терминах этапов: планирование, проектирование,
кодирование, тестирование и сопровождение. Для первых двух
методов планирование
237
затрагивает: определение спецификаций, бюджета и расписания, а также развития
плана проекта в целом.
9
1.2 1.1
13
1.3
12
11 2.1 11
2.2 3.1
10 15
2.3 3.2
5
2.4 0
0
Рис.10.4. Граф работ и сроков (на дугах) для проекта
В настоящее время значительная часть современных средств проектирования нацелена
на визуализацию структуры проекта и процессов деятельности, которые на иконке
могут быть выделены цветом или иконкой, это позволяет увидеть, какие виды
деятельности должны выполняться параллельно, и какие находятся на критическом
пути (наприер в системе Project Management).
10.1.3. Организационные аспекты управления в проекте
Распределение работ по ролям. Наиболее часто определение ролей исполнителей
проекта соответствует этапам разработки. В графе могут присутствовать циклические
пути. По графу проводят анализ критических путей, т.е. определяют данные о
продолжительности каждого процесса. План проекта проводится в терминах этапов:
планирование, проектирование, кодирование, тестирование и сопровождение. Для
первых двух методов планирование затрагивает: определение спецификаций,
бюджета и расписания, а также развития плана проекта в целом.
Состав и количество сотрудников, входящих в группу проекта, зависит от масштаба
работ и опыта сотрудников. Сотрудники должны быть настолько
квалифицированными, что могут выявить ошибки и неточности в проекте на самых
ранних стадиях ведения разработки. Разделение труда сотрудников по этапам имеет
свои определенные преимущества, но требует специальной техники общения между
группами сотрудников для эффективной работы (проверки, просмотры, откаты назад,
сквозной контроль).
238
Специалисты, которые наиболее подходят к выполнению каждой из перечисленных
ролей, различаются между собой:
– способностью выполнять работу;
– интересом к работе;
– опытом работы с подобным проектом, инструментами, языками, технологиями и
ОС;
– способностью к обучению;
– коммуникабельностью с другими сотрудниками;
– способностью разделить ответственность с другими;
– профессионализмом и знанием методов управления.
Менеджер проекта должен знать способности того или иного сотрудника выполнить
определенную работу по проектированию или по тестированию системы в целом.
Работающие в одной группе должны разделять одни и те же взгляды по проведению
порученной им работы и пользоваться одним стилем программирования. Разделение
большого участка работы на меньшие части должно соответствовать фрагментам
работы, определению ролей и ответственности каждого сотрудника в проекте.
Стиль работы. Разным людям свойственны разные стили выполнения работы и
коммуникации с другими сотрудниками [3]. Отличаются сотрудники тем, что одни
сначала взвешивают все детали и собирают всю информацию, а потом принимают
решения по всем вопросам. Другие разбивают работу на фрагменты и принимают
решение постепенно для каждого фрагмента. Некоторые сотрудники предпочитают
формировать рабочее решение путем высказывания своего мнения другим
сотрудниками и принимать окончательное решение сообща (стиль экстраверта),
другие предпочитают и интересоваться мнением других по тому или другому вопросу,
а потом самостоятельно принимать решение (интроверты). Некоторые сотрудники
полагаются на свою интуиции и профессиональный опыт при принятии решения
(интуитивисты), другие – руководствуются только рациональными и логическими
доводами (рационалисты). В реальной рабочей среде более часто встречаются
смешанные типы сотрудников.
Рациональный экстраверт считается хорошим руководителем. Он стремится обсудить
проблему, но не позволяет влиять на принятие окончательного решения. Стиль его
работы – спрашивать у своих подчиненных
то, что касается главной линии ведения
проекта (их не интересуют подробности, частности, детали документации и т. д.).
Рациональный интроверт избегает эмоциональных обсуждений, ему необходимо время,
чтобы обдумать все возможные пути решения проблемы и просчитать все шаги. Он
тщательно взвешивают все «за и против», собирая все факты. Его репутация хорошего
работника для
него очень важна, он считает, что работа должна занимать большую
часть времени и требует этого от других. Он аккуратен и точен.
Интуитивный экстроверт часто принимает решение на эмоциональной почве.
Стремится больше рассказать о себе и своих планах, чем выслушать других. Часто
базируется на предыдущем опыте работы, по натуре он испытатель. Ему важно, чтобы
другие признали его идеи. Ему удобнее работать в коллективе, где устоялись хорошо
организованные связи между сотрудниками.
Интуитивный интроверт - это творец, он начинает творить, только после того, как
собрал подходящую для себя информацию. Уинстон Черчель принадлежал к этому
типу. Перед тем, как принять решение, он слушал и читал по этому вопросу все
239
материалы. И часто принимал решение, базируясь на своих впечатлениях об
услышаном, был хорошим слушателем, собирал полную информацию для принятия
правильного решения, принимая во внимание не столько факты и объекты
исследования, сколько связи и отношения между ними.
При работе над проектом необходимо учитывать стиль работы не только своего
подчиненного, но и заказчика. Если заказчик интроверт, то ему нужно предоставлять
больше информации и времени на обдумывание для принятия решения, В случае
экстроверта необходимо больше общаться с ним, позволять высказывать свои
требования и идеи. Интуитивисту необходимо подкидывать больше новых идей,
поощрять творчество и, если он рационален, то надо для него проводить больше
демонстраций, базирующихся на фактах и схемах.
Организация проекта. Для хорошей организации ведения проекта подбирается
подходящая структура проекта на основании следующих данных:
– рабочие стили членов группы;
– число людей в группе;
– стиль работы с заказчиками и разработчиками.
Один из популярных стилей ведения проекта впервые использовался в IBM (рис.10.5).
В нем главным ответственным за проектирование системы и ведение разработки
является руководитель группы программистов. Ему непосредственно подчиняются
программисты, которые имеют право последнего слова при принятии решений –
главные программисты. Главный программист руководит своей подгруппой
программистов и непосредственно посвящен в детали проекта и разработки
программы.
Главный
программист
Ассистент
главного
программиста
Программисты Библиотекарь Администратор Группа тестовиков
Подчиненный
программист
Рис.10.5. Структура организации группы главного программиста
240
Ассистент главного программиста дублирует, замещает главного программиста, когда
это необходимо. Библиотекарь – ответственный за всю документацию проекта:
компилирование и тестирование всех модулей библиотеки. Введение этой должности
позволяет сконцентрироваться программистам на их непосредственной работе, а не на
поиске ошибок и создании необходимых материалов.
В группу входит администратор и группа тестировщиков. Старшие программисты и
младшие непосредственно подчиняются старшим. Хотя структура такой рабочей
группы иерархическая, каждый член группы может общаться непосредственно с
главным программистом или с другими сотрудниками. Главный программист должен
сам просматривать части основного проекта и программ.
Альтернативная структура ведения проекта описана Вейнбергом (Weinberg) [3], так
называемое обезличенное программирование, при котором все несут одинаковую
ответственность за качество продукта. В проекте не концентрируются на персоналиях,
критике подвергается программный продукт, а не члены группы. Такая структура
подходит для маленьких групп программистов.
Ответственность за моделирование работ в проекте. В [3] в рамках военного
ведомства разработана общая структура команды для создания интегрированного
продукта (Integrated Product Development Team). Модель ответственности команды
приведена на рис.10.6.
ТРЕБУЕМЫЕ РЕЗУЛЬТАТЫ
Ответственность за
- планирование
- выполнение плана
- конечный результат
Команда Заказчик
Воздействие на проект:
- инспекция элементов /сборка
- содействие
- руководство
- пополнение
Рис. 10.6 Модель ответственности лиц в интегрированном проекте
Модульное программирование системы осуществлялось с помощью компилятора Ада
при моделировании этапов: проектирования, анализа и построения программного
обеспечения, а также при управлении конфигурацией, тестировании, объединении
элементов проекта через интерфейс или при переходе от основных фреймов к рабочим
станциям. Менеджер проекта управляет распределением обязанностей и устанавливает
сроки для выполнения трех одинаковых по размеру задач проекта.