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

Стр 1 из 6Следующая ⇒

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

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

Принцип руководства иллюстрирует рис. 2.1.

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

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

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

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

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

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

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

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

В результате измерения определяется

мера — количественная характеристика какого-либо свойства объекта.

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

В программной инженерии понятия мера и метрика очень часто рассматривают как синонимы.

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

При планировании программного проекта надо оценить

§ людские ресурсы (в человеко-месяцах),

§ продолжительность (в календарных датах),

§ стоимость (в тысячах долларов).

Обычно исходят из прошлого опыта.

Анализ риска

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

В результате принимается решение — выполнять проект или нет.

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

§ Определяется набор проектных задач.

§ Устанавливаются связи между задачами,

§ оценивается сложность каждой задачи.

§ Определяются людские и другие ресурсы.

§ Создается сетевой график задач, проводится его временная разметка.

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

Каждая задача, помеченная в плане, отслеживается руководителем проекта.

При отставании в решении задачи применяются утилиты повторного планирования.

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

q М.б. перераспределены ресурсы;

q М.б. реорганизованы задачи;

q М.б. пересмотрены выходные обязательства.

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

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

Она составляется с помощью утилиты планирования проекта. Типовая WBS приведена на рис. 2.2.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.

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

.

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

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

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

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

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

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

Для третьего подхода

где УД_СТОИМОСТЬ_ан_i — метрика стоимости одной строки аналога, взятая из метрического базиса. Пример применения данного процесса оценки -ниже.

ПРИМЕЧАНИЕ

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

От оценки затрат легко перейти к стоимости проекта. Переход выполняют по формуле:

СТОИМОСТЬ = ЗАТРАТЫ х РАБ_ КОЭФ,

где среднее значение рабочего коэффициента составляет $15 000 за человеко-месяц.

После определения затрат и стоимости можно оценить длительность разработки. Модель СОСОМО II содержит уравнение для оценки календарного времени TDEV, требуемого для выполнения проекта. Для моделей всех уровней справедливо:

Длительность (TDEV) = [3, 0 х (ЗАТРАТЫ)^{(0, 33+0, 2(}^B^{-1, 01))}] х SCEDPercentage/100 [мес],

где

-В — ранее рассчитанный показатель степени;

-SCEDPercentage — процент увеличения (уменьшения) номинального графика.

Если нужно определить номинальный график, то принимается SCEDPercentage =100 и правый сомножитель в уравнении обращается в единицу. Следует отметить, что СОСОМО II ограничивает диапазон уплотнения/растягивания графика ( от 75 до 160% ). Причина проста — если планируемый график существенно отличается от номинального, это означает внесение в проект высокого риска.

пример. Положим, что затраты на проект равны 20 человеко-месяцев. Примем, что все масштабные факторы номинальны (имеют значения 3), поэтому, в соответствии с табл. 2.20, показатель степени 5=1, 16. Отсюда следует, что номинальная длительность проекта равна

TDEV = 3, Ox (20)^{0, 36} = 8, 8 мес.

(3, 0x (20) ^{0, 33+0, 2(}^B^{-1, 01)=, 33+0, 2(1.17-1, 01)})

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

Очень часто увеличение количества разработчиков приводит к возрастанию затрат. причина:

q увеличивается время на взаимодействие и обучение сотрудников, согласование совместных решений;

q возрастает время на определение интерфейсов между частями программной системы.

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

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

Предварительная оценка программного проекта

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

Предположим, что поступил заказ от концерна «СУПЕРАВТО». Необходимо создать ПО для рабочей станции дизайнера автомобиля (РДА). Заказчик определил проблемную область проекта в своей спецификации:

q ПО РДА должно формировать 2- и 3-мерные изображения для дизайнера;

q дизайнер должен вести диалог с РДА и управлять им с помощью стандартизованного графического пользовательского интерфейса;

q геометрические данные и прикладные данные должны содержаться в базе данных РДА;

q модули проектного анализа рабочей станции должны формировать данные для широкого класса дисплеев SVGA;

q ПО РДА должно управлять и вести диалог со следующими периферийными устройствами: мышь, дигитайзер (графический планшет для ручного ввода), плоттер (графопостроитель), сканер, струйный и лазерный принтеры.

Прежде всего

-детализировать проблемную область.

-выделить базовые функции ПО

-очертить количественные границы.

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

Будем считать, что эта работа проделана и что идентифицированы следующие основные функции ПО:

1. Средства управления пользовательским интерфейсом СУПИ.

2. Анализ двухмерной графики А2Г.

3. Анализ трехмерной графики А3Г.

4. Управление базой данных УБД.

5. Средства компьютерной дисплейной графики КДГ.

6. Управление периферией УП.

7. Модули проектного анализа МПА.

Теперь нужно оценить каждую из функций количественно, с помощью LOC-оценки.

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

LOC_ож_i =(LOC_лучш_i +LOC_худш_i +4 х LOC_{вероятн}_i)/6,

результаты расчетов заносим в табл. 2.22.

Таблица 2.22. Начальная таблица оценки проекта

Функция	Лучш. [LOC]	Вероят. [LOC]	Худш. [LOC]	Ожид. [LOC]	Уд. стоимость [$/LОС]	Стоимость[$]	Произв. [LOC/ [чел-мес]	Затраты [чел-мес]
СУПИ
А2Г
АЗГ
УБД
КДГ
УП
МПА
Итого

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

Видно, что наибольшую удельную стоимость имеет строка функции управления периферией (требуются специфические и конкретные знания по разнообразным периферийным устройствам), наименьшую удельную стоимость — строка функции управления пользовательским интерфейсом (применяются широко известные решения).

Таблица 2.23. Данные из метрического базиса фирмы

Функция	LOC_ан_i	УД_СТОИМОСТЬ_ан_i[$ / LOC]	ПРОИЗВ_ан_i[LOC/чел-мес]
СУПИ
А_Г
УБД
КДГ
УП
МПА

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

СТОИМОСТЬ_i = LOC_ож_i х УД_СТОИМОСТЬ_ан_i.

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

ПРОИЗВ _i =ПРОИЗВ_ан_i х (LOC_ан_i / LOC_ож_i).

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

ЗАТРАТЫ _i = (LOC_ож_i /ПРОИЗВ _i)[чел.-мес].

Теперь мы имеем все необходимые данные для завершения расчетов. Заполним до конца таблицу оценки нашего проекта (табл. 2.24).

Таблица 2.24. Конечная таблица оценки проекта

Функция	Лучш.	Вероят.	Худш.	Ожид. [LOC]	Уд. стоимость [S/LOC]	Стоимость [$]	Произв. [LOC/ чел.-мес]	Затраты [чел-мес]
СУПИ								7, 4
А2Г								21, 9
A3Г								35, 0
УБД								13, 9
КДГ								24, 7
УП								15, 2
МПА								28, 0
Итого

Учитывая важность полученных результатов, проверим расчеты с помощью FP-указателей.

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

Таблица 2.25. Оценка информационных характеристик проекта

Характеристика	Лучш.	Вероят	Худш.	Ожид.	Сложность	Количество
Вводы					х 4
Выводы					х 5
Запросы					х 4
Логические файлы					х 10
Интерфейсные файлы					х 7
Общее количество

Таблица 2.26. Оценка системных параметров проекта

Коэффициент регулировки сложности	Оценка
F₁	Передачи данных
F₂	Распределенная обработка данных
F₃	Производительность
F₄	Распространенность используемой конфигурации
F₅	Скорость транзакций
F₆	Оперативный ввод данных
F₇	Эффективность работы конечного пользователя
F₈	Оперативное обновление
F₉	Сложность обработки
F₁₀	Повторная используемость
F₁₁	Легкость инсталляции
F₁₂	Легкость эксплуатации
F₁₃	Разнообразные условия размещения
F₁₄	Простота изменений

Таким образом, получаем:

FР = Общее количество х (0, 65+ 0, 01 х ) = 318 x 1, 17 = 372.

Используя значение производительности, взятое в метрическом базисе фирмы,

Производительность = 2, 55 [FP / чел.-мес],

вычисляем значения затрат и стоимости:

Затраты = FP / Производительность = 145, 9 [чел.-мес],

Стоимость = Затраты х $4500 = $656500.

Итак, результаты проверки показали хорошую достоверность результатов.

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

Примем, что все масштабные факторы и факторы затрат имеют номинальные значения. В силу этого показатель степени В = 1, 16, а множитель поправки М_p= 1. Кроме того, будем считать, что автоматическая генерация кода и повторное использование компонентов не предусматриваются. Следовательно, мы вправе применить формулу

ЗАТРАТЫ = A х РАЗМЕР^B[чел.-мес]

и получаем:

ЗАТРАТЫ = 2, 5(33, 3)^{1, 16} =145, 87 [чел.-мес].

Соответственно, номинальная длительность проекта равна

Длительность = [3, 0 х (ЗАТРАТЫ)^{(0, 33+0, 2(}^B^-^{1, 01))}]=3(145, 87)^{0, 36} = 18[мес].

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

Сценарий понижения зарплаты

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

EM_ACAP=EM_PCAP=1 .

Следствием такого решения является возрастание множителя поправки М_р= 1, 507, а также затрат и стоимости:

ЗАТРАТЫ = З6х 1, 507 = 54 [чел.-мес],

СТОИМОСТЬ = ЗАТРАТЫ х$5000 = $270 000,

Проигрыш_ в_стоимости = $36 000.

Сценарий наращивания памяти

Положим, что разработчик предложил нарастить память —

купить за $1000 чип ОЗУ емкостью 96 Кбайт (вместо 64 Кбайт).

Это меняет ограничение памяти (используется не 70%, а 47%), после чего фактор STOR снижается до номинального:

EM_STOR=1-> М_р =1, 026,

ЗАТРАТЫ = 36x1, 026 = 37 [чел.-мес],

СТОИМОСТЬ = ЗАТРАТЫ х $6000 = $222000,

Выигрыш_ в_стоимости = $ 12 000.

Выводы.

1. Факторы затрат оказывают существенное влияние на выходные параметры программного проекта.

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

3. Модель СОСОМО II обеспечивает перевод качественного обоснования решения менеджера на количественные рельсы, тем самым повышая объективность принимаемого решения.

Контрольные вопросы

1. Что такое мера?

2. Что такое метрика?

3. Что такое выполнение оценки программного проекта?

4. Что такое анализ риска?

5. Что такое трассировка и контроль?

6. Охарактеризуйте содержание Work Breakdown Structure.

7. Охарактеризуйте рекомендуемое правило распределения затрат проекта.

8. Какие размерно-ориентированные метрики вы знаете?

9. Для чего используют размерно-ориентированные метрики?

10. Определите достоинства и недостатки размерно-ориентированных метрик.

11. Что такое функциональный указатель?

12. От каких информационных характеристик зависит функциональный указатель?

13. Как вычисляется количество функциональных указателей?

14. Что такое коэффициенты регулировки сложности в метрике количества функциональных указателей?

15. Определите достоинства и недостатки функционально-ориентированных метрик.

16. Можно ли перейти от FP-оценок к LOC-оценкам?

17. Охарактеризуйте шаги оценки проекта на основе LOC- и FP-метрик. Чем отличается наиболее точный подход от наименее точного?

18. Что такое конструктивная модель стоимости? Для чего она применяется?

19. Чем отличается версия СОСОМО 81 от версии СОСОМО II?

20. В чем состоит назначение модели композиции? На каких оценках она базируется?

21. В чем состоит назначение модели раннего этапа проектирования?

22. Охарактеризуйте основное уравнение модели раннего этапа проектирования.

23. Охарактеризуйте масштабные факторы модели СОСОМО II.

24. Как оцениваются масштабные факторы?

25. В чем состоит назначение модели этапа пост-архитектуры СОСОМО II?

26. Чем отличается основное уравнение модели этапа пост-архитектуры от аналогичного уравнения модели раннего этапа проектирования?

27. Что такое факторы затрат модели этапа пост-архитектуры и как они вычисляются?

28. Как определяется длительность разработки в модели СОСОМО II?

29. Что такое анализ чувствительности программного проекта?

30. Как применить модель СОСОМО II к анализу чувствительности?

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

12 3 4 5 6 Следующая ⇒