grischenko-proj-management / lectures / lecture-03-conspect

1

Менеджмент проектов программного обеспечения Лекция №3: «Оценка трудоемкости проектов программного обеспечения»

1.Зачем оценивать время выполнения задач

1.Нет точных и простых методов оценки трудоемкости программных систем

2.Методы оценки трудоемкости задач

1.Виды методов:

1.Микрооценка

1.Основываются на анализе запланированных задач

2.Oracle AIM

2.Макрооценка

1.Основываются на анализе функциональных требований

2.COCOMO (COnstructive COst Model ), COCOMO II

1.Объем проекта оценивается в количестве строк кода

3.Функциональные точки

1.Объем проекта оценивается в количестве функциональных точек

2.Микрооценка небольших проектов

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

2.Проанализируйте требования клиента, насколько они детальны? Если не хватает детализации - значит нужно выяснить у клиента эти моменты.

3.Попробуйте оценить каждую из подзадач по срокам.

4.Добавьте к срокам, определенным Вами в п.3 +25-30% от времени. Как бы это не звучало странно - мы всегда оценивает сроки слишком оптимистично и как правило ошибаемся. Буфер в 25-30% должен Вам помочь в решении этой проблемы.

5.Ответьте на вопрос: будете ли Вы тратить какое-то количество времени на общение с клиентом? Если да - то заложите это время тоже в бюджет. Вы не должны делать это за бесплатно.

6.Сложите количество часов, полученных в результате пунктов 1-5, и сделайте оценку проекту, исходя из оплаты за час Вашей работы.

3.Модель COCOMO

1.Разработана в конце 70-х Барри Боэмом. Впервые обнародована в 1981 г. Базируется на 63-х разноплановых проектах.

2.Разработана для методики «Водопад»

2

3.Устанавливает взаимосвязь между размером системы (в тысячах строк кода), «классом проекта» и трудоемкостью разработки

4.Трудоемкость зависит от многих факторов

5.Наибольшее влияние на величину программного продукта оказывает объем программного кода

6.Формы оценки трудоемкости

1.Базовый уровень

1.Базовый уровень рассчитывает трудоемкость и стоимость разработки как функцию от размера программы. Размер выражается в оценочных тысячах строк кода (KLOC - kilo lines of code).

2.Средний уровень

3.Детальный уровень

7.Классы проектов:

1.естественные (органические)

1.относительно небольшие проекты, разрабатываемые командой, знакомой с предметной областью и не жесткими требованиями к разработке

2.полуинтегрированные (полуразделенные)

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

3.встроенные системы

1.выполняются при значительных аппаратных, программных и организационных ограничениях

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

1.Трудоемкость = ab ( KLOK )bb [человеко-месяцев]

3

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

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

1.Характеристики продукта

1.Требуемая надежность ПО

2.Размер БД приложения

3.Сложность продукта

2.Характеристики аппаратного обеспечения

1.Ограничения быстродействия при выполнении программы

2.Ограничения памяти

3.Неустойчивость окружения виртуальной машины

4.Требуемое время восстановления

3.Характеристики персонала

1.Аналитические способности

2.Способности к разработке ПО

3.Опыт разработки

4.Опыт использования виртуальных машин

5.Опыт разработки на языках программирования

4.Характеристики проекта

1.Использование инструментария разработки ПО

2.Применение методов разработки ПО

3.Требования соблюдения графика разработки

6.Каждому из этих 15 факторов ставится в соответствие рейтинг по шестибальной шкале, начиная от «очень низкий» и до «экстра высокого» (по значению или важности фактора). Далее значения рейтинга заменяются множителями трудоемкости из стандартной таблицы. Обычно он принимает значения в диапазоне от 0.9 до

7.Формула модели COCOMO для среднего уровня принимает вид

4

E=ai(KLoC)(bi).РФТ

где Е — трудоемкость в человекомесяцах, KloC — оценочный объем продукта в тысячах строк кода, РФТ (регулирующий фактор трудоемкости), рассчитанный как произведение значений из таблицы

8.Расчет времени разработки для среднего уровня COCOMO совпадает с расчетом для Базового уровня.

8.Детальный уровень

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

4.Основной недостаток измерения объема в строках кода:

1.Они ничего не дают

1.Предположим, что два коллектива разработчиков решают одну и ту же задачу с применением разных технологических средств. Первый коллектив специализируется в низкоуровневом программировании с использованием языка ассемблера целевой платформы, второй – работает на языке C. На первых проектных этапах в силу высокой квалификации обе группы идут плечо к плечу, затратив по одному месяцу на изучение требований к ПО и по два месяца на высокоуровневое проектирование. Этап кодирования, безусловно, намного более трудоемкий при применении низкоуровневого языка ассемблера, отнимает у первого коллектива девять месяцев, у второго – два. Соответственно, по той же причине этап тестирования обходится первому коллективу в четыре месяца, второму – в два. Завершающие этапы – подготовка комплекта сопроводительной документации и отработка системы поддержки ПО у обеих команд почти одинаковы – первый коллектив затрачивает на решение этих задач три месяца, второй – два. Результирующий программный продукт первой команды содержит 30 тыс. строк кода, второй – 5 тыс. И наконец, затраты первой команды

5

составляют 150 тыс. у. е., второй – 90 тыс. А вот теперь начнется парадоксальное – если оценивать эти два проекта на основе «строк кода», то получится, что цена строки кода при программировании на ассемблере – 5 у. е. (150 000 у. е./30 000 строк), почти в три раза меньше, чем строки кода на C, которая равна 18 у. е. (90000 у.е./5000 строк). А производительность труда программистов-«ассемблерщиков», измеренная в выданных на-гора строках в месяц, выше в три раза (!), чем у их работающих на сравнительно высокоуровневом языке коллег – 30 тыс. строк за 19 месяцев против 5 тыс. за 10 месяцев, т. е. 1579 строк в месяц против 500.

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

1.Мицель А., Шелковников К., Истомин Н. Методы оценки трудоемкости проектов по созданию программных систем

2.Методы оценки проекта разработки ПО. http://habrahabr.ru/blogs/pm/24872/

3.COCOMO — Википедия. http://ru.wikipedia.org/wiki/COCOMO

4.На старт! Внимание! И? http://itc.ua/articles/na_start_vnimanie_i_21814/

5.С. Архипенков. Обзор метода функциональных точек. http://citforum.ru/SE/project/arkhipenkov_lectures/12.shtml

6.Десять смертных грехов в оценке трудоёмкости разработки программного обеспечения. http://habrahabr.ru/blogs/pm/75903/