Руководство программным проектом презентация

1


Руководство программным проектом

2


Схема разработки программ

3


Управление проектом охватывает инфраструктуру (организационные моменты); инфраструктуру (организационные моменты); управляющий процесс (права и ответственности участников); управляющий процесс (права и ответственности участников); процесс разработки (методы, инструменты, языки, документация и поддержка); процесс разработки (методы, инструменты, языки, документация и поддержка); расписание (моменты времени, к которым должны быть представлены вы­полненные фрагменты работы) расписание (моменты времени, к которым должны быть представлены вы­полненные фрагменты работы)

4


Руководитель проекта может управлять следующими факторами Общая стоимость проекта Общая стоимость проекта Возможности продукта Возможности продукта Качество продукта Качество продукта Длительность проекта Длительность проекта Один из способов визуализировать значения данных четырех переменных состоит в использовании лепестковых диаграмм

5


Пример использовании лепестковых диаграмм

6


Типичная схема процесса управления проектом 1. Понять содержание проекта, область применения и временные рамки. 2. Определиться с процессом разработки (методы, инструменты, языки, документация и поддержка) 3. Выделить организационную структуру (привлечение отделов организации). 4. Определить управляющий процесс (ответственность участников).

7


Типичная схема процесса управления проектом 5. Разработать расписание проекта (моменты сдачи частей работы). 6. Разработать план подбора кадров. 7. Начать управление рисками. 8.Определить, какие документы необходимо выработать. 9. Начать сам процесс.

8


Рекомендуемое правило распределения затрат проекта : на анализ и проектирование приходится 40% затрат (из них на планирование и системный анализ 5%); на анализ и проектирование приходится 40% затрат (из них на планирование и системный анализ 5%); на кодирование 20%; на кодирование 20%; на тестирование и отладку 40%. на тестирование и отладку 40%.

9


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

10


Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки прямо измеряют программный продукт и процесс его разработки основываются на LOC-оценках (Lines Of Code) основываются на LOC-оценках (Lines Of Code) LOC-оценка это количество строк в программном продукте LOC-оценка это количество строк в программном продукте

11


Исходные данные для расчета LOC-метрик Проект Затраты чел.- мес Стоимость, тыс. $ KLOC, тыс. LOC Прогр. док- ты, страниц Ошибки Люди ааа , bbb , сс ,

12


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

13


Достоинства размерно-ориентированных метрик: 1) широко распространены; 2) просты и легко вычисляются. Недостатки размерно-ориентированных метрик: 1) зависимы от языка программирования; 2) требуют исходных данных, которые трудно получить на начальной стадии проекта; 3) не приспособлены к непроцедурным языкам программирования.

14


Конструктивная модель стоимости СОСОМО 81 Е=а b x(KLOC) b b [чел-мес]; D = c b x (E) a b [мес], где Е затраты в человеко-месяцах, D время разработки, KLOC количество строк в программном продукте. Коэффициенты аb, bb, сb, db берутся из таблицы

15


Коэффициенты для базовой подмодели СОСОМО 81 Тип проектааbаbb сbсb dbdb Распространен ный 2,41,052,50,38 Полунезависим ый 3,01,122,50,35 Встроенный 3,61,202,50,32

16


УПРАВЛЕНИЕ ПЕРСОНАЛОМ ПРОЕКТА

17


Варианты организации персонала 1. Управление взаимодействием

18


2. Варианты структуры ответственности Иерархическая структура управления Иерархическая структура управления

19


горизонтальная структура управления горизонтальная структура управления

20


коллегиальная структура управления коллегиальная структура управления

21


ВЫЯВЛЕНИЕ И УМЕНЬШЕНИЕ РИСКОВ

22


Типы рисков Риски, которых можно избежать (устранимые) Риски, которых невозможно избежать избежать

23


Управление риском состоит из нескольких действий: Идентификация Идентификация Планирование устранения Планирование устранения Выбор приоритетов Выбор приоритетов Устранение или уменьшение. Устранение или уменьшение.

24


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

25


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

26

27


Метод расчета приоритета рисков Риск 1, наложение изображений, связан с манипулированием изображениями в Java Риск 1, наложение изображений, связан с манипулированием изображениями в Java Риск 2, недостаточные навыки программирования на Java, отражает тот факт, что 40 % команды не имеют достаточного опыта программирования на Java Риск 2, недостаточные навыки программирования на Java, отражает тот факт, что 40 % команды не имеют достаточного опыта программирования на Java

28

1.

Руководство программным
проектом

2.

Цели
• Процесс руководства проектом
• Планирование проектных задач
• Размерно-ориентированные метрики
• Функционально-ориентированные метрики
• Конструктивная модель стоимости
2

3.

Процесс руководства проектом
3

4.

Процесс руководства проектом
Руководство программным проектом — первый слой
процесса конструирования ПО. Термин «слой»
подчеркивает, что руководство определяет сущность
процесса разработки от его начала до конца.

5.

Процесс руководства проектом
Для проведения успешного проекта нужно понять
• объем предстоящих работ,
• возможный риск,
• требуемые ресурсы,
• предстоящие задачи,
• прокладываемые вехи,
• необходимые усилия (стоимость),
• план работ, которому желательно следовать.
Руководство программным проектом обеспечивает такое
понимание. Оно начинается перед технической работой,
продолжается по мере развития ПО от идеи к реальности и
достигает наивысшего уровня к концу работ
5

6.

Начало проекта
Перед планированием проекта следует:
• установить цели и проблемную область
проекта;
• обсудить альтернативные решения;
• выявить технические и управленческие
ограничения.
6

7.

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

8.

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

9.

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

10.

Трассировка и контроль
• Каждая задача, помеченная в плане, отслеживается
руководителем проекта.
• При отставании в решении задачи применяются утилиты
повторного планирования. С помощью утилит
определяется влияние этого отставания на
промежуточную веху и общее время конструирования.
Под вехой понимается временная метка, к которой
привязано подведение промежуточных итогов.
В результате повторного планирования:
• могут быть перераспределены ресурсы;
• могут быть реорганизованы задачи;
• могут быть пересмотрены выходные обязательства.
10

11.

Планирование проектных задач
Основной задачей при планировании является определение
WBS — Work Breakdown Structure (структуры распределения
работ). Она составляется с помощью утилиты планирования
проекта. Типовая WBS приведена на рис.
11

12.

Системный анализ проводится
с целью:
1)
выяснения потребностей заказчика;
2)
оценки выполнимости системы;
3)
выполнения экономического и
технического анализа;
4)
распределения функций по элементам
компьютерной системы (аппаратуре,
программам, людям, базам данных и т. д.);
5)
определения стоимости и ограничений
планирования;
6)
создания системной спецификации.
12

13.

Вехи
• Вехи — процедуры контроля промежуточных результатов.
Очень важно, чтобы вехи были расставлены через
регулярные интервалы (вдоль всего процесса разработки
ПО). Это даст руководителю возможность регулярно
получать информацию о текущем положении дел. Вехи
распространяются и на документацию как на один из
результатов успешного решения задачи.
• Параллельность действий повышает требования к
планированию. Так как параллельные задачи
выполняются асинхронно, планировщик должен
определить межзадачные зависимости. Это гарантирует
«непрерывность движения к объединению». Кроме того,
руководитель проекта должен знать задачи, лежащие на
критическом пути. Для того чтобы весь проект был
выполнен в срок, необходимо выполнять в срок все
13
критические задачи.

14.

Затраты времени
Рекомендуемое правило распределения затрат
проекта — 40-20-40:
• на анализ и проектирование приходится 40%
затрат (из них на планирование и системный
анализ — 5%);
• на кодирование — 20%;
• на тестирование и отладку — 40%.
14

15.

Метрики
Программного проекта
15

16.

Размерно-ориентированные
метрики (1)
• Размерно-ориентированные метрики прямо измеряют
программный продукт и процесс его разработки.
Основываются размерно-ориентированные метрики на LOCоценках (Lines Of Code). LOC-оценка — это количество строк в
программном продукте.
• Исходные данные для расчета этих метрик сводятся в
таблицу (данные за последние несколько лет).
16

17.

Размерно-ориентированные
метрики (2)
• На основе таблицы вычисляются размерноориентированные метрики производительности и
качества (для каждого проекта):
17

18.

Размерно-ориентированные
метрики (3)
Общими особенностями гибких методологий3являются:
• Ориентированность на людей – как разработчиков, так и
заказчиков (согласие участвовать в разработке). Считается,
что умение собрать в проектной команде «правильных»
людей определяет успех или неудачу проекта в значительно
большей степени, чем любые процессы или технологии.
• Использование устных обсуждений вместо формальных
спецификаций везде, где это возможно.
• Итеративная разработка с возможно более короткой (в
разумных пределах) продолжительностью итерации, при
этом в результате каждой итерации выпускается
полноценная работающая версия продукта.
• Ожидание изменений – в гибком процессе проектная команда
не пытается зафиксировать требования в начале проекта и
затем следовать жестко определенному плану. Изменения 18

19.

Размерно-ориентированные
метрики (4)
Достоинства размерно-ориентированных метрик:
• 1) широко распространены;
• 2) просты и легко вычисляются.
Недостатки размерно-ориентированных метрик:
• 1) зависимы от языка программирования;
• 2) требуют исходных данных, которые трудно получить
на начальной стадии проекта;
• 3) не приспособлены к непроцедурным языкам
программирования.
19

20.

Функциональноориентированные метрики (1)
• Функционально-ориентированные метрики косвенно измеряют
программный продукт и процесс его разработки. Вместо
подсчета LOC-оценки при этом рассматривается не размер, а
функциональность или полезность продукта.
• Используется 5 информационных характеристик.
1. Количество внешних вводов. Подсчитываются все вводы
пользователя, по которым поступают разные прикладные
данные. Вводы должны быть отделены от запросов, которые
подсчитываются отдельно.
2. Количество внешних выводов. Подсчитываются все выводы,
по которым к пользователю поступают результаты, вычисленные
программным приложением. В этом контексте выводы означают
отчеты, экраны, распечатки, сообщения об ошибках.
Индивидуальные единицы данных внутри отчета отдельно не
подсчитываются.
20

21.

Функциональноориентированные метрики (2)
• Количество внешних запросов. Под запросом понимается
диалоговый ввод, который приводит к немедленному
программному ответу в форме диалогового вывода. При
этом диалоговый ввод в приложении не сохраняется, а
диалоговый вывод не требует выполнения вычислений.
Подсчитываются все запросы — каждый учитывается
отдельно.
• 4. Количество внутренних логических файлов.
Подсчитываются все логические файлы (то есть
логические группы данных, которые могут быть частью
базы данных или отдельным файлом).
• 5. Количество внешних интерфейсных файлов.
Подсчитываются все логические файлы из других
приложений, на которые ссылается данное приложение.
21

22.

Функциональноориентированные метрики (3)
• После сбора всей необходимой информации приступают к
расчету метрики — количества функциональных
указателей FP (Function Points). Автором этой метрики
является А. Албрехт (1979) [7].
• Исходные данные для расчета сводятся в табл.
22

23.

Функциональноориентированные метрики (4)
• В таблицу заносится количественное значение
характеристики каждого вида (по всем уровням сложности).
Места подстановки значений отмечены прямоугольниками
(прямоугольник играет роль метки-заполнителя).
Количественные значения характеристик умножаются на
числовые оценки сложности. Полученные в каждой строке
значения суммируются, давая полное значение для данной
характеристики. Эти полные значения затем суммируются по
вертикали, формируя общее количество.
• Количество функциональных указателей вычисляется по
формуле
где Fi — коэффициенты регулировки сложности.
23

24.

Функциональноориентированные метрики (5)
Каждый коэффициент может принимать следующие
значения: 0 — нет влияния, 1 — случайное, 2 — небольшое,
3 — среднее, 4 — важное, 5 — основное.
Значения выбираются эмпирически в результате ответа на
14 вопросов, которые характеризуют системные параметры
приложения:
24

25.

Определение системных
параметров приложения
25

26.

Определение системных
параметров приложения (прод.)
После вычисления FP на его основе формируются метрики
производительности, качества и т. д.:
26

27.

Функциональноориентированные метрики (6)
• Область применения метода функциональных указателей
— коммерческие информационные системы. Для
продуктов с высокой алгоритмической сложностью
используются метрики указателей свойств (Features
Points). Они применимы к системному и инженерному ПО,
ПО реального времени и встроенному ПО.
• Достоинства функционально-ориентированных метрик:
• 1. Не зависят от языка программирования.
• 2. Легко вычисляются на любой стадии проекта.
• Недостаток функционально-ориентированных метрик:
результаты основаны на субъективных данных,
используются не прямые, а косвенные измерения. FPоценки легко пересчитать в LOC-оценки.
27

28.

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

29.

Выполнение оценки проекта на
основе LOC- и FP-метрик
Цель этой деятельности — сформировать предварительные
оценки, которые позволят:
• предъявить заказчику корректные требования по стоимости и
затратам на разработку программного продукта;
• составить план программного проекта.
При выполнении оценки возможны два варианта использования
LOC- и FP-данных:
• в качестве оценочных переменных, определяющих размер
каждого элемента продукта;
• в качестве метрик, собранных за прошлые проекты и
входящих в метрический базис фирмы.
29

30.

Шаги процесса оценки (1)
•Шаг 1. Область назначения проектируемого продукта
разбивается на ряд функций, каждую из которых можно
оценить индивидуально: f1, f2,…,fn.
•Шаг 2. Для каждой функции fi, планировщик формирует
лучшую LOCлучшi (FРлучшi), худшую LOCхудшi (FРхудшi) и
вероятную оценку LOCвероятнi (FРвероятнi). Используются
опытные данные (из метрического базиса) или интуиция.
Диапазон значения оценок соответствует степени
предусмотренной неопределенности.
•Шаг 3. Для каждой функции в соответствии с распределением вычисляется ожидаемое значение LOC(или FP-) оценки:
•LOCожi =(LOCлучшi + LOCхудшi +4x LOCвероятнi )/ 6.
30

31.

Шаги процесса оценки (2)
•Шаг 4. Определяется значение LOC- или FPпроизводительности разработки функции.
•Используется один из трех подходов:
•1)для всех функций принимается одна и та же метрика средней
производительности ПРОИЗВср, взятая из метрического базиса;
•2)для i-й функции на основе метрики средней
производительности вычисляется настраиваемая величина
производительности: ПРОИЗВi =ПРОИЗВсрх(LOCср /LOCожi),
где LOCcp — средняя LOC-оценка, взятая из метрического
базиса (соответствует средней производительности);
3) для i-й функции настраиваемая величина
производительности вычисляется по аналогу, взятому из
метрического базиса: ПРОИЗВi =ПРОИЗВанiх(LOCанi /LOCожi).
•Первый подход обеспечивает минимальную точность), а третий
31
подход — максимальную точность.

32.

Шаги процесса оценки (3)
Шаг 5. Вычисляется общая оценка затрат на проект: для первого
подхода
• для второго и третьего подходов
Шаг 6. Вычисляется общая оценка стоимости проекта: для
первого и второго подходов
где УД_СТОИМОСТЬср — метрика средней стоимости одной
строки, взятая из метрического базиса.
• для третьего подхода
где УД_СТОИМОСТЬанi — метрика стоимости одной строки
аналога, взятая из метрического базиса.
32

33.

Конструктивная модель стоимости
• В данной модели для вывода формул использовался
статистический подход — учитывались реальные результаты
огромного количества проектов. Автор оригинальной модели
— Барри Боэм (1981) —дал ей название СОСОМО 81
(Constructive Cost Model) и ввел в ее состав три разные по
сложности статистические подмодели.
Иерархию подмоделей Боэма (версии 1981 года) образуют:
• базисная СОСОМО — статическая модель, вычисляет затраты
разработки и ее стоимость как функцию размера программы;
• промежуточная СОСОМО — дополнительно учитывает
атрибуты стоимости, включающие основные оценки продукта,
аппаратуры, персонала и проектной среды;
• усовершенствованная СОСОМО — объединяет все
характеристики промежуточной модели, дополнительно
учитывает влияние всех атрибутов стоимости на каждый этап
процесса разработки ПО (анализ, проектирование и т.д.) 33

34.

Конструктивная модель
стоимости
• Подмодели СОСОМО 81 могут применяться к трем типам
программных проектов. По терминологии Боэма, их
образуют:
• распространенный тип — небольшие программные
проекты, над которыми работает небольшая группа
разработчиков с хорошим стажем работы,
устанавливаются мягкие требования к проекту;
• полунезависимый тип — средний по размеру проект,
выполняется группой разработчиков с разным опытом,
устанавливаются как мягкие, так и жесткие требования к
проекту;
• встроенный тип — программный проект
разрабатывается в условиях жестких аппаратных,
программных и вычислительных ограничений.
34

35.

Уравнения базовой подмодели
Уравнения базовой подмодели имеют вид
• Е=аbx(KLOC) [чел-мес];
• D = cbx (E) [мес],
где Е — затраты в человеко-месяцах, D — время
разработки, KLOC — количество строк в программном
продукте.
Коэффициенты аb, bb, сb, db берутся из табл.
35

36.

Модель СОСОМО II
• В 1995 году Боэм ввел более совершенную модель
СОСОМО II, ориентированную на применение в
программной инженерии XXI века.
В состав СОСОМО II входят:
• модель композиции приложения;
• модель раннего этапа проектирования;
• модель этапа пост-архитектуры.
Для описания моделей СОСОМО II требуется информация о
размере программного продукта. Возможно использование
LOC-оценок, объектных указателей, функциональных
указателей.
36

37.

Модель композиции
приложения
Модель композиции используется на ранней стадии
конструирования ПО, когда:
• рассматривается макетирование пользовательских
интерфейсов;
• обсуждается взаимодействие ПО и компьютерной системы;
• оценивается производительность;
• определяется степень зрелости технологии.
Модель композиции приложения ориентирована на применение
объектных указателей.
Объектный указатель — средство косвенного измерения ПО, для
его расчета определяется количество экранов (как элементов
пользовательского интерфейса), отчетов и компонентов,
требуемых для построения приложения..
37

38.

Модель композиции
приложения (2)
• Проектные затраты оцениваются по формуле
ЗАТРАТЫ = NOP /PROD [чел.-мес],
где PROD — производительность разработки, выраженная в
терминах объектных указателей;
NOP — количество новых объектных указателей:
NOP = (Объектные указатели) х [(100 — %REUSE) /100],
%REUSE — процент повторного использования
программных компонентов.
38

39.

Модель раннего этапа
проектирования
• Модель раннего этапа проектирования используется в период,
когда стабилизируются требования и определяется базисная
программная архитектура.
• Основное уравнение этой модели имеет следующий вид:
где:
• масштабный коэффициент А = 2,5;
• показатель В отражает нелинейную зависимость затрат от
размера проекта (размер системы РАЗМЕР выражается в
тысячах LOC);
• множитель поправки Мe зависит от 7 формирователей затрат,
характеризующих продукт, процесс и персонал;
• слагаемое 3ATPATЫauto отражает затраты на автоматически
генерируемый программный код.
39

40.

Модель этапа постархитектуры
• Модель этапа постархитектуры используется в период, когда
уже сформирована архитектура и выполняется дальнейшая
разработка программного продукта.
• Основное уравнение постархитектурной модели является
развитием уравнения предыдущей модели и имеет следующий
вид:
ЗАТРАТЫ = А х К~req х РАЗМЕРB х Мр +3ATPATЫauto [чел.-мес], где
• коэффициент К~req учитывает возможные изменения в
требованиях;
• показатель В отражает нелинейную зависимость затрат от
размера проекта (размер выражается в KLOC), вычисляется
так же, как и в предыдущей модели;
• в размере проекта различают две составляющие — новый код
и повторно используемый код;
• множитель поправки Мр зависит от 17 факторов затрат,
характеризующих продукт, аппаратуру, персонал и проект. 40

41.

Стоимость проекта
• От оценки затрат легко перейти к стоимости проекта. Переход
выполняют по формуле:
СТОИМОСТЬ = ЗАТРАТЫ х РАБ_ КОЭФ,
где среднее значение рабочего коэффициента составляет
$15000 за человеко-месяц.
• После определения затрат и стоимости можно оценить
длительность разработки.
• Модель СОСОМО II содержит уравнение для оценки
календарного времени TDEV, требуемого для выполнения
проекта. Для моделей всех уровней справедливо:
41

42.

Оценка календарного времени
• Длительность (TDEV) = [3,0 х (ЗАТРАТЫ)(0,33+0,2(B-1,01))] х
SCEDPercentage/100 [мес],
где
• В — ранее рассчитанный показатель степени;
• SCEDPercentage — процент увеличения (уменьшения)
номинального графика.
• Если нужно определить номинальный график, то
принимается SCEDPercentage =100 и правый сомножитель
в уравнении обращается в единицу. Следует отметить, что
СОСОМО II ограничивает диапазон
уплотнения/растягивания графика (от 75 до 160%). Причина
проста — если планируемый график существенно
отличается от номинального, это означает внесение в
проект высокого риска.
42

43.

Модель СОСОМО II
• Модель СОСОМО II явно утверждает, что длительность
проекта является функцией требуемых затрат, прямой
зависимости от количества сотрудников нет. Другими
словами, она устраняет миф нерадивых менеджеров в том,
что добавление людей поможет ликвидировать отставание в
проекте.
• СОСОМО II предостерегает от определения потребного
количества сотрудников путем деления затрат на
длительность проекта. Такой упрощенный подход часто
приводит к срыву работ. Реальная картина имеет другой
характер. Количество людей, требуемых на этапе
планирования и формирования требований, достаточно
мало. На этапах проектирования и кодирования потребность
в увеличении команды возрастает, после окончания
кодирования и тестирования численность необходимых
43
сотрудников достигает минимума.

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

Презентация Руководство программным проектом онлайн

Слайды презентации

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

Презентация: Руководство программным проектом

Содержание

1. Введение

2. Руководство программным проектом

3. Планирование проектных задач

4. Конструктивная модель стоимости

5. Заключение

6. Список литературы

Введение

Руководство программным проектом — первый слой процесса конструирования ПО. Термин «слой» подчеркивает, что руководство определяет сущность процесса разработки от его начала до конца. Принцип руководства иллюстрирует рис. 2.1.

Рис. 2.1. Руководство в процессе конструирования ПО

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

Для проведения успешного проекта нужно понять объем предстоящих работ, возможный риск, требуемые ресурсы, предстоящие задачи, прокладываемые вехи, необходимые усилия (стоимость), план работ, которому желательно следовать. Руководство программным проектом обеспечивает такое понимание. Оно начинается перед технической работой, продолжается по мере развития ПО от идеи к реальности и достигает наивысшего уровня к концу работ [32], [64], [69].

2. Руководство программным проектом

Начало проекта

Перед планированием проекта следует:

· установить цели и проблемную область проекта;

· обсудить альтернативные решения;

· выявить технические и управленческие ограничения.

Измерения, меры и метрики

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

В IEEE Standard Glossary of Software Engineering Terms метрика определена как мера степени обладания свойством, имеющая числовое значение. В программной инженерии понятия мера и метрика очень часто рассматривают как синонимы.

Процесс оценки

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

Анализ риска

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

Планирование

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

Трассировка и контроль

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

В результате повторного планирования:

· могут быть перераспределены ресурсы;

· могут быть реорганизованы задачи;

· могут быть пересмотрены выходные обязательства.

3. Планирование проектных задач

Основной задачей при планировании является определение WBS — Work Breakdown Structure (структуры распределения работ). Она составляется с помощью утилиты планирования проекта. Типовая WBS приведена на рис. 2.2.

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

Системный анализ проводится с целью:

1. выяснения потребностей заказчика;

2. оценки выполнимости системы;

3. выполнения экономического и технического анализа;

4. распределения функций по элементам компьютерной системы (аппаратуре, программам, людям, базам данных и т. д.);

5. определения стоимости и ограничений планирования;

6. создания системной спецификации.

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

Анализ требований дает возможность:

1. определить функции и характеристики Программного продукта;

2. обозначить интерфейс продукта с другими системными элементами;

3. определить проектные ограничения программного продукта;

4. построить модели: процесса, данных, режимов функционирования продукта;

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

Рис. 2.2. Типовая структура распределения проектных работ

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

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

Ромбиками на рис. 2.2 обозначены вехи — процедуры контроля промежуточных результатов. Очень важно, чтобы вехи были расставлены через регулярные интервалы (вдоль всего процесса разработки ПО). Это даст руководителю возможность регулярно получать информацию о текущем положении дел. Вехи распространяются и на документацию как на один из результатов успешного решения задачи.

Параллельность действий повышает требования к планированию. Так как параллельные задачи выполняются асинхронно, планировщик должен определить межзадачные зависимости. Это гарантирует «непрерывность движения к объединению». Кроме того, руководитель проекта должен знать задачи, лежащие на критическом пути. Для того чтобы весь проект был выполнен в срок, необходимо выполнять в срок все критические задачи.

Основной рычаг в планирующих методах — вычисление границ времени выполнения задачи.

Обычно используют следующие оценки:

1. Раннее время начала решения задачи Tinmin (при условии, что все предыдущие задачи решены в кратчайшее время).

2. Позднее время начала решения задачи Tinmax (еще не вызывает общую задержку проекта).

3. Раннее время конца решения задачи Toutmin

Toutmin = Tinmin + Tреш

4. Позднее время конца решения задачи Toutmax

Toutmax = Tinmax + Tреш.

5. Общий резерв — количество избытков и потерь планирования задач во времени, не приводящих к увеличению длительности критического пути Tк.п.

Все эти значения позволяют руководителю (планировщику) количественно оценить успех в планировании, выполнении задач.

Рекомендуемое правило распределения затрат проекта — 40-20-40:

· на анализ и проектирование приходится 40% затрат (из них на планирование и системный анализ — 5%);

· на кодирование — 20%;

· на тестирование и отладку — 40%.

Выполнение в ходе руководства проектом

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

Выполнение оценки проекта на основе LOC- и FP-метрик

Цель этой деятельности — сформировать предварительные оценки, которые позволят:

· предъявить заказчику корректные требования по стоимости и затратам на разработку программного продукта;

· составить план программного проекта.

При выполнении оценки возможны два варианта использования LOC- и FP-данных:

· в качестве оценочных переменных, определяющих размер каждого элемента продукта;

· в качестве метрик, собранных за прошлые проекты и входящих в метрический базис фирмы.

Обсудим шаги процесса оценки.

· Шаг 1. Область назначения проектируемого продукта разбивается на ряд функций, каждую из которых можно оценить индивидуально:

f1 ,f2, …,fn.

· Шаг 2. Для каждой функции f1 планировщик формирует лучшую LОСлучшi (FРлучшi ), худшую LOСХУДШi (FРХУДШi ) и вероятную оценку LOСвероятнi (FРвероятнi ). Используются опытные данные (из метрического базиса) или интуиция. Диапазон значения оценок соответствует степени предусмотренной неопределенности.

· Шаг 3. Для каждой функции fi в соответствии с β-распределением вычисляется ожидаемое значение LOC- (или FP-) оценки:

LOCожi = LOCлучшi + LOCхудшi + 4 x LOCвероятнi ) / 6.

· Шаг 4. Определяется значение LOC- или FP-производительности разработки функции.

Используется один из трех подходов:

1. для всех функций принимается одна и та же метрика средней производительности ПРОИЗВср, взятая из метрического базиса;

2. для i-й функции на основе метрики средней производительности вычисляется настраиваемая величина производительности:

ПРОИЗВi = ПРОИЗВср х (LOСср / LOСожi ),

где LOCcp — средняя LOC-оценка, взятая из метрического базиса (соответствует средней производительности);

4. Конструктивная модель стоимости

В данной модели для вывода формул использовался статистический подход — учитывались реальные результаты огромного количества проектов. Автор оригинальной модели — Барри Боэм (1981) — дал ей название СОСОМО 81 (Constructive Cost Model) и ввел в ее состав три разные по сложности статистические подмодели [1].

Иерархию подмоделей Боэма (версии 1981 года) образуют:

· базисная СОСОМО — статическая модель, вычисляет затраты разработки и ее стоимость как функцию размера программы;

· промежуточная СОСОМО — дополнительно учитывает атрибуты стоимости, включающие основные оценки продукта, аппаратуры, персонала и проектной среды;

· усовершенствованная СОСОМО — объединяет все характеристики промежуточной модели, дополнительно учитывает влияние всех атрибутов стоимости на каждый этап процесса разработки ПО (анализ, проектирование, кодирование, тестирование и т. д.).

Подмодели СОСОМО 81 могут применяться к трем типам программных проектов. По терминологии Боэма, их образуют:

· распространенный тип — небольшие программные проекты, над которыми работает небольшая группа разработчиков с хорошим стажем работы, устанавливаются мягкие требования к проекту;

· полунезависимый тип — средний по размеру проект, выполняется группой разработчиков с разным опытом, устанавливаются как мягкие, так и жесткие требования к проекту;

· встроенный тип — программный проект разрабатывается в условиях жестких аппаратных, программных и вычислительных ограничений.

Уравнения базовой подмодели имеют вид

Е = ab x (KLOCbb [чел-мес];

D = cb x (E)db [Mec],

где Е- затраты в человеко-месяцах, D — время разработки, KLOC — количество строк в программном продукте.

Заключение

СОСОМО II — авторитетная и многоплановая модель, позволяющая решать самые разнообразные задачи управления программным проектом.

Рассмотрим возможности этой модели в задачах анализа чувствительности — чувствительности программного проекта к изменению условий разработки.

Будем считать, что корпорация «СверхМобильныеСвязи» заказала разработку ПО для встроенной космической системы обработки сообщений. Ожидаемый размер ПО — 10 KLOC, используется серийный микропроцессор. Примем, что масштабные факторы имеют номинальные значения (показатель степени В = 1,16) и что автоматическая генерация кода не предусматривается. К проведению разработки привлекаются главный аналитик и главный программист высокой квалификации, поэтому средняя зарплата в команде составит $ 6000 в месяц. Команда имеет годовой опыт работы с этой проблемной областью и полгода работает с нужной аппаратной платформой.

В терминах СОСОМО II проблемную область (область применения продукта) классифицируют как «операции с приборами» со следующим описанием: встроенная система для высокоскоростного мультиприоритетного обслуживания удаленных линий связи, обеспечивающая возможности диагностики.

Оценку пост-архитектурных факторов затрат для проекта сведем в табл. 2.27.

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

Список литературы

1. Боэм Б. У. Инженерное проектирование программного обеспечения. М.: Радио и связь, 1985. 511 с.

2. Липаев В. В. Отладка сложных программ: Методы, средства, технология. М.: Энергоатомиздат, 1993. 384 с.

3. Майерс Г. Искусство тестирования программ. М.: Финансы и статистика, 1982. 176с.

4. Орлов С. А. Принципы объектно-ориентированного и параллельного программирования на языке Ada 95. Рига: TSI, 2001. 327 с.

5. Чеппел Д. Технологии ActiveX и OLE. M.: Русская редакция, 1997. 320 с.

6. Abreu, F. В., Esteves, R., Goulao, M. The Design of Eiffel Programs: Quantitative Evaluation Using the MOOD metrics. Proceedings of the TOOLS’96. Santa Barbara, California 20 pp. July 1996.

Соседние файлы в папке Лекции

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #