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

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
сотрудников достигает минимума.

Управление программными проектами: процессы, инструменты, методики

Существуют разные представления о том, как ведётся творческая работа. Для многих людей творец – это личность (поэт, художник, изобретатель), которая создаёт своё творение в момент озарения. Управлять озарением? О, нет! Это невозможно!

Тем не менее, задача управления творчеством во все времена была актуальна. Инвесторам, менеджерам, государству хотелось бы иметь предсказуемость на счёт того, когда будет выпущен разрабатываемый творческий продукт (будь это книга, самолёт, компьютерная программа или кинофильм).

Творческая работа может вестись как индивидуально (одним творцом – учёным, художником, композитором или поэтом), так и коллективно (когда над созданием произведения работают коллективы людей разных специальностей). В данной статье мне бы хотелось сконцентрироваться на вопросах управления творческими коллективами на примере распределённого коллектива программистов, художников и дизайнеров из трёх стран, который выпускает приложение, продаваемое во всём мире. Каждый год продаётся более 10 миллионов экземпляров. Годовая выручка – 1 миллиард долларов.

Предположим, мы захотели открыть ресторан. По каким критериям Клиент будет оценивать его? Конечно, это кухня, дизайн и обслуживание. Обычно, наибольшее количество «глюков» происходит в процессе обслуживания, т.е. там, где велик человеческий фактор. Красивенькая молоденькая официантка вроде бы привлекает Клиентов. Но у неё испортилось настроение, и вместо доброжелательного отношения, она начинает хамить. В результате, вместо привлечения происходит отваживание Клиентов. В индустрии разработки ПО такое просто недопустимо. Необходимо, чтобы специалисты разных специальностей взаимодействовали друг с другом, а барьеры в коммуникациях и всякие субъективные вещи сводились бы к нулю. Поэтому при работе в большой интернациональной команде неформальные связи между людьми заменяются формализованными бизнес-процессами, а вместо субъективных оценок (хороший, прикольный, клёвый) используются метрики и показатели качества.

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

Параметры управления

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

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

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

1. Сроки.
2. Объём (количество полезных функций).
3. Объём работы.
4. Полезность (ценность для Потребителя).
5. Техническая и технологическая сложность.
6. Внешнее качество (с точки зрения Потребителя).
7. Внутреннее качество (с точки зрения специалиста, инженера, конструктора).
8. Риски.
9. Психологическое состояние команды.

Процессы управления

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

1. Управление задачами.
2. Управление сроками.
3. Управление качеством.
4. Управление рисками.

Управление задачами

Назначение

Оценка объёма работы и распределение задач между сотрудниками.

Система контроля задач

Цели

1. Оценить и зафиксировать объём работы.

Примечание. Сотрудники не должны выдумывать себе занятия, а заниматься задачами из заранее утверждённого списка.

Пример. На одной работе у меня был начальник, который на вопрос «К какому сроку нужно выполнить эту задачу?» — всегда давал одинаковый ответ: «Вчера». Позднее, став начальником, я убедился в том, что с программистами происходит зеркальная ситуация. Спросишь кого-нибудь: «Когда ты закончишь эту работу?» — и получаешь ответ: «Завтра к обеду. В худшем случае – к вечеру». Но проходит день, другой, а задача всё ещё не сделана. Чтобы как можно реже попадать в подобные ситуации и нужен инструмент, который подсказывает регулярно оставшийся объём работы.

2. Распределить задачи между работниками. Убедиться, что у каждого работника имеется задача, и ни один из них не простаивает.

Примечание: По данным министра экономического развития России (21.05.2012 – 24.06.2013) Андрея Белоусова производительность труда в нашей стране в 2-3 раз ниже, чем в развитых странах в зависимости от методики подсчёта (http://www.forbes.ru/kompanii/245905-v-kakikh-otraslyakh-rabotayut-samye-neeffektivnye-rossiiskie-kompanii).

Пример. Если вы когда-нибудь наблюдали, как происходит починка аварии на теплотрассе, то наверняка замечали, что копает яму один рабочий, а вокруг него 10 человек стоят и смотрят, как он работает.

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

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

3. Найти зависимости между различными задачами.

Примечание (Василина Абу-Навас, бизнес-консультант, объединение «Практик»): Задача обязательно должна быть согласована с задачами других сотрудников, всего проекта или его части. Потому что, продолжая пример с рабочим, может оказаться так, что рабочий выкопал яму, получил деньги, все 10 «начальников» отчитались, а на другой день пришёл приказ яму срочно закопать, потому что именно по этой дороге поедет, например, президент. Об этом знали давно, просто «забыли» предупредить. А те, кто «копал», как обычно не уточнили параметры своей задачи… Или рабочий вырыл яму, а надо было оказывается рыть чуть шире или чуть глубже… Т.е. задача, может, и актуальна, но, при этом, не согласована или не точна.

4. Определить, какие задачи заблокированы по тем или иным причинам.

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

Описание

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

Таблица 1. Список задач для мобильной навигационной системы GPS

Название	Статус	Ответственный	Область	Остаточная трудоемкость (часы)
Добавить экран поиска перекрёстков	Новая	Иванов И.И.	Поиск адреса	24
Добавить парикмахерские в базу данных для карты России	Выполняется	Петров П.П.	Поиск мест	8
Добавить новые стили оформления карты	Завершена	Сидоров С.С.	Карта	0
Разобраться, почему не строится маршрут через кольцевую дорогу в Санкт-Петербурге	Заблокирована	Дмитриев Д.Д.	Построение маршрута	12

Параметры

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

Примеры:

• Добавить экран поиска перекрёстков. (Примечание: Проверяемый критерий – экран. Он либо есть, либо его нет.)
• Разобраться, почему не строится маршрут через кольцевую дорогу в Санкт-Петербурге. (Примечание: Проверяемый критерий – построение маршрута через кольцевую дорогу.)

Название задачи может включать в себя и название области программы (подсистемы), к которой относится задача. Это помогает при беглом взгляде на задачу понять, какому специалисту её следует поручить.

Примеры:

• База данных – Поиск мест – Добавить парикмахерские в базу данных для России. (Примечание: Задача относится сразу к двум областям: с технической точки зрения – к базе данных, потому что в неё надо внести изменения; с пользовательской точки зрения – к поиску мест, потому что в этом разделе навигационной системы можно проверить вносимое изменение.)
• Интерфейс – Карты – Добавить новые стили оформления карт. (Примечание: Эту задачу тоже можно отнести сразу к двум разделам навигационной системы: к интерфейсу пользователя, где можно выбирать стиль оформления карт, и к подсистеме визуализации карты.)

Подсистему можно указывать не только в названии задачи, но и в отдельной графе. Это позволит «подбить статистику» и оценить объём работы, относящийся к той или иной части программы.

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

Для визуального представления статистики лучше всего подходит круговая диаграмма:

Рисунок 1. Объём работы над мобильной навигационной системой GPS

Статус задачи позволяет определить, какие задачи уже выполнены, какие – выполняются, и над какими задачами работа ещё не начиналась. Рекомендуется завести специальный статус, который сигнализирует о том, что задача заблокирована. Если работник устанавливает такой статус, то это означает, что выполнение задачи невозможно по тем или иным причинам.

Пример. Задача «Заменить иконки» не может быть выполнена, если художник не успел эти иконки нарисовать.

Остаточная трудоёмкость содержит актуальную оценку задачи – сколько времени ещё осталось до завершении задачи. Она даётся исполнителем в конце каждого рабочего дня. Таким образом, задача регулярно переоценивается. Это позволяет следить за прогрессом и вовремя предпринять определённые меры, если команда не поспевает к заданному сроку.

Использование

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

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

ПО

Для управления задачами можно использовать готовые бесплатные или недорогие системы контроля задач:

• Электронные таблицы Excel или Google Docs
• Redmine – http://www.redmine.org
• Jira – https://www.atlassian.com/software/jira
• BugZilla — http://www.bugzilla.org
• DropTask – http://www.droptask.com
• Hansoft – http://www.hansoft.com

Сложная, «навороченная» и дорогая система управления проектом может быть заменена симбиозом Redmine и Excel.

Управление сроками

Назначение

Оценка и контроль сроков реализации проекта.

Диаграмма сгорания задач

Цели

Позволяет:

1. Оценить текущий остаточный объём работы.

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

2. Определить величину отставания от плана.

3. Оценить прогресс каждого сотрудника и всей команды.

Примечание. В этом случае будет семейство диаграмм.

Диаграмма

Рисунок 2. Прогресс работы сотрудника (реальный и прогнозируемый)

Описание

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

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

Таблица 2. Прогресс работы сотрудников

Ф.И.О.	31.08.14	01.09.14	02.09.14	03.09.14	04.09.14	05.09.14
Иванов И.И.	Реально	38	32	28	20	14	8
План	38	30	22	14	6	0
Петров П.П.	Реально	40	32	26	18	11	0
План	40	32	24	16	8	0

Примечание (Антон Яковлев, программист): Описан подход, очевидно, удобный в случае использования Excel. С другими системами подход может быть другой – Hansoft такие диаграммы может генерировать самостоятельно.

Параметры

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

Использование

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

В конце каждого рабочего дня данные – объём оставшейся работы в часах – заносятся в таблицу. Данные берутся из графы «Остаточная трудоёмкость» таблицы задач.

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

Управление качеством

Назначение

Обеспечение надлежащего качества продукта.

Пример. В 2013 году в России количество разводов составило 54,5% от числа зарегистрированных браков (http://womanadvice.ru/statistika-razvodov-v-rossii). Такое количество «браков» в индустрии разработки ПО просто недопустимо. Не смотря на то, что государство является заинтересованной стороной, в том, чтобы количество разводов уменьшалось, причины столь печальной статистики государством не собираются и не анализируются. А вот при разработке ПО это делается.

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

Пример. В одном из проектов было найдено 30 тысяч (!) дефектов. Из них 15% так и не было исправлено. Не смотря на то, что это некритические или очень редко встречающиеся ошибки, тем не менее, можно сказать, что приложение было выпущено с 4 500 ошибками.

Прогноз количества дефектов

Цели

1. Оценить сложность проекта.
2. Оценить ресурсы, необходимые на доводку качества.

Описание

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

Таблица 3. Прогноз количества дефектов для мобильной навигационной системы GPS

Область	2013 год (реальность)	2014 год (прогноз)
Пользовательский интерфейс	243	250
Построение маршрута	113	100
Поиск адреса	53	50
Поиск мест	17	20
Карта	194	200
Навигация	89	100
Аудио	67	50
Итого	776	770

Параметры

В графе «Область» перечисляются подсистемы программы. Они могут быть получены путём логического деления по разным основаниям. Иногда программа делится на части с точки зрения пользователя (как в приведённой таблице). В других случаях используются технические критерии.

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

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

Использование

При старте проекта отдел контроля качества создаёт прогноз по багам. Во внимание принимаются исторические данные, прогнозируемый объём работы, сложность требований к новой версии приложения, а также опытность самой команды.

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

Например:

• Пользовательский интерфейс
• База данных
• Аудио
• Алгоритмы

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

Например:

• Рисование карты
• Построение маршрута
• Навигация
• Поиск адреса

Разные модели прогноза дополняют и проверяют друг друга.

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

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

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

План поиска дефектов

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

Цели

1. Распределить ресурсы, ответственные за контроль качества, во времени.
2. Получить механизм контроля за работой инженеров по качеству.

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

Описание

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

Таблица 4. Понедельный план поиска дефектов для мобильной навигационной системы GPS

Область	01.09.14	08.09.14	15.09.14	22.09.14
Пользовательский интерфейс	5	5	10	12
Построение маршрута	3	3	5	7
Поиск адреса	5	5	5	8
Поиск мест	0	1	2	3
Карта	3	5	7	8
Навигация	8	10	10	12
Аудио	0	1	2	3
Итого	24	30	41	53

Параметры

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

Диаграмма

На основании плана строится график поиска дефектов, который представляет собой S-образную кривую.

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

На графике также откладываются ключевые даты проекта: альфа-версия, бета-версия и финальная версия.

Рисунок 3. Графическое представление плана поиска дефектов за всё время работы над проектом

Использование

Визуально, на кривой можно выделить три этапа.

Первый этап начинается с момента старта проекта и заканчивается выпуском альфа-версии. В это время кривая растёт не так интенсивно, потому что до альфа-версии приоритет отдаётся разработке программы, а не поиску дефектов. Ещё не все требования реализованы, а то, что сделано, может быть реализовано не в полном объёме.

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

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

К моменту альфа-версии отделом тестирования должно быть найдено 30% всех дефектов. К бета-версии должно быть найдено 98% всех дефектов.

Управление рисками

Назначение

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

Примечание: В системной инженерии существует методология «анализ видов и последствий отказов» (англ. – Failure Modes and Effects Analysis, https://ru.wikipedia.org/wiki/FMEA). Согласно стандарту министерства обороны США эта процедура проводит анализ потенциальных ошибок системы, определяет результаты их влияния как на систему в целом, так и на различные подсистемы, производит классификацию ошибок относительно их критичности.

Управление рисками похоже на анализ видов и последствий отказов: выявляются риски, оценивается их негативное влияние на проект, находятся решения для нейтрализации негативных последствий.

Реестр рисков

Цели

1. Описать выявленные риски.

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

Примечание (Василина Абу-Навас, бизнес-консультант, объединение «Практик»): Тут даже больше: нужно описывать решение сразу (по-возможности, следует находить идеальные решения). Т.е. выявить риск мало – надо сразу думать о том, как его предотвратить. Иначе риски так и остаются «граблями».

Пример (Василина Абу-Навас, бизнес-консультант, объединение «Практик»): Перед нашим Клиентом стояла задача – разморозить оборотные средства в размере 25 млн. рублей за 1 месяц. Казалось, мы учли все риски, кроме налогов, потому что финансовый директор был в отпуске, и зная, что эта задача будет решаться, ничего не сказал. Сделали отличный план по размораживанию средств и реализовали его. В результате, налетели на налог на прибыль. Если бы данный риск был учтён, то можно было бы вырученные средства потратить для приобретения недвижимости, и, тем самым, избежать уплаты налога.

2. Оценить важность каждого риска и вероятность его срабатывания.

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

Пример. Одна компания, разрабатывающая GPS-навигатор, решила сменить поставщика карт. Причина смены проста – стоимость лицензии в 2 раза ниже, а формат описания карт – тот же. Тем не менее, цена перехода на карты нового поставщика обошлась компании в 2 – 3 человека-года. Именно столько усилий было затрачено на решение возникших технических проблем.

3. Предложить план действия на случай того, если риск сработает.

Пример. При создании одной игры для маленьких девочек был серьёзный риск не уложиться в отведённые сроки. Было несколько причин у этого риска: новая команда, незнакомая платформа, для которой велась разработка, отсутствие отлаженной технологической инфраструктуры. Чтобы снизить риск, было принято решение организовать игру в виде последовательности мини-игр. Каждая такая игра была достаточно простой, не слишком сильно насыщенной графикой и другими персонажами. Кроме того, игрок был лишён свободы передвижения, т.е. мог двигаться только в заранее определённых направлениях. Это настолько упростило процесс разработки, что одна мини-игра в финальном качестве создавалась за 5 человеко-дней (имеется в виду работа инженера без учёта работы художника).

4. Распределить риски между ответственными за их устранение.

Описание

Все выявленные риски заносят в специальную таблицу, как в примере ниже.

Таблица 5. Таблица рисков для мобильной навигационной системы GPS

Риск	Важность	Вероятность	Вес	Что делать?	Ответственный	Состояние
Если программисты не получат новые карты от поставщика до 15 октября, то они не будут включены в релиз	Средняя	Низкая	2	Связаться с поставщиком по телефону и послать напоминание по email	Сергеев А.Д.	Нужно напомнить ещё пару раз
Если отдел маркетинга не предоставит отзывы покупателей до 1-го сентября, то команда не сможет учесть их в очередном релизе	Высокая	Высокая	9	Запросить отдел маркетинга	Владимиров К.П.	Получены, находятся на сервере в папке ‘Отзывы’

Параметры

Каждый риск записывается по формуле:

Если не <будет сделано что-то> до <определённой даты>, то <произойдёт нечто негативное>.

Каждый риск следует оценить с точки зрения его важности, т.е. негативных последствий для проекта при его срабатывании. Обычно ограничиваются шкалой из трёх оценок: низкая, средняя и высокая.

Также следует оценить вероятность срабатывания риска. Для оценки тоже можно ограничиться тремя значениями: низкая, средняя и высокая.

Вес риска рассчитывается автоматически, исходя из его важности и вероятности. Для этого оценочные значения преобразуются в числовые следующим образом: значение «низкая» становится равной 1, «средняя» — 2, а «высокая» — 3. Вес рассчитывается, как произведение двух оценок. Например, если важность риска высокая и вероятность его срабатывания тоже высокая, то риск получает вес равный 9.

Использование

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

Заключение

1. Проекты по разработке программного обеспечения бывают как индивидуальными, так и коллективными.
2. Коллективные программные проекты требуют координации усилий многих людей. Нередко эти люди обладают разными специальностями, находятся в разных странах и на разных континентах и разговаривают на разных языках.
3. Крупные корпорации имеют опыт по управлению достаточно большими (100 – 200 человек), интернациональными и распределёнными творческими коллективами. Этот опыт можно переосмыслить и использовать.
4. Процесс управления реальным проектом основан на контроле целой группы параметров. Это только в школе учат мыслить функцией от одной переменной.
5. Для контроля параметров управления рекомендуется использовать процессы управления, среди которых есть: управление задачами, управление сроками, управление качеством, управление рисками и т.д.
6. Каждый из процессов управления сводится к одному или нескольким инструментам и методикам их применения. Среди инструментов есть такие: система контроля задач, диаграмма сгорания задач, прогноз количества дефектов, план поиска дефектов, реестр рисков.

Автор благодарит Василину Абу-Навас (Объединение «Практик»), И.Л. Викентьева (Система «ТРИЗ-ШАНС»), Эдуарда Галиаскарова и Антона Яковлева за помощь в подготовке статьи.

Содержание

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. Раннее время начала решения задачи Tⁱⁿ_min (при условии, что все предыдущие задачи решены в кратчайшее время).

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

1. Раннее время конца решения задачи T^out_min

T^out_min = Tⁱⁿ_min + T_реш

1. Позднее время конца решения задачи T^out_max

T^out_max = Tⁱⁿ_max + T_реш.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

f₁,f₂, …,f_n.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Е = a_b x (KLOC^b_b [чел-мес];

D = c_b x (E)^d_b[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.