1. Как оценить проект, чтобы не
было мучительно больно... потом
(… и что делать, если это «потом» все-таки наступило…)
Luxoft’ 2008-2010 Д. Башакин
Copyright © 2008-2009 by Luxoft, Inc. All rights reserved. Version 1.2.1

2. О тренере
 Дмитрий Башакин (DBashakin@Luxoft.com)
 Luxoft, группа компаний IBS – ведущий эксперт по управлению
проектами Учебного Центра
 В ИТ-индустрии с 1986, 12 лет опыта в управлении проектами и
проектными программами (управление производством,
управление бизнесом, управление персоналом), 6 лет опыта
тренерской деятельности, с 2008 года – штатный эксперт УЦ
Luxoft
 Каталог курсов Учебного Центра, расписание, контакты
и прочая информация:
 http://www.luxoft-training.ru
2

3. Правила
 График семинара
 Вопросы – по окончании слайда или раздела, но можно и
сразу!
 Обсуждения – приветствуются! Но: или общие, или за
пределами аудитории 
 Мобильные телефоны – вибро-режим, разговоры за
пределами аудитории
 Обратная связь – форма оценки
3

4. Наша цель
 Обсудить основные критерии выбора и применения
различных методик оценки проектов по разработке ПО
 Обсудить основные трудности оценок и способы их
преодоления
 Обсудить пути выхода из кризиса «А с оценкой мы все-
таки "пролетели"…»
 Подробнее – на курсе Учебного Центра:
 PM-005 «Оценка проекта: размер и трудозатраты» – 20 часов
 Ближайшее чтение – 25.06-01.07.2010, Москва
 Вне рамок семинара: детальное обсуждение конкретных
методик оценки
4

5. Вступление.
Об Учебном Центре Luxoft

6. Учебный Центр Luxoft
 Что такое Учебный Центр Luxoft?
Мы - часть компании Luxoft, лидера в области разработки ПО на заказ
Наша миссия - повышать эффективность IT-команд в компаниях-
клиентах
 Кого и чему мы учим?
Наша ниша – программная инженерия. Все дисциплины для создателей
ПО
 Кто у нас преподает?
Лучшие эксперты компании Luxoft и индустрии Software Engineering
 Как с нами работать?
Очное и On-line Обучение. Корпоративные тренинги
 Почему мы – лучшие в своей области?
3 причины учиться в УЦ Luxoft: Результат, Экспертиза, Гибкость

7. Мероприятия УЦ Luxoft
Очные мероприятия:
 Открытые Тренинги и Классы в Школах www.Luxoft-Training.ru
 Конференции с отраслевой тематикой www.Soft-Labs.ru
 Семинары
 Партнерские мероприятия
Online мероприятия:
 Online Тренинги и Классы в Школах
 Вебинары

8. Школы и Классы в Школах
 Школа Менеджера проекта (52 курса)
 Класс руководителя группы разработки; Класс менеджера проекта
 Школа Аналитика (36 курсов)
 Класс системного аналитика; Класс бизнес аналитика
 Школа Проектировщика (9 курсов)
 Класс проектировщика
 Школа Разработчика (28 курсов)
 Класс .Net разработчика; Класс Java-разработчика
 Школа Тестировщика (76 курсов)
 Класс Тест-менеджера; Класс Тест-дизайнера; Класс тестировщика; Инженеров по
автоматизированному тестированию
Каталог: www.luxoft-training.ru
Расписание: www.luxoft-training.ru, раздел Расписание и цены
Запись на обучение: для люксофтовцев, для внешних
слушателей

9. Расписание – менеджерский блок
 Школа Менеджера проекта
 Очный Класс руководителя группы разработки:
05.04.2010-07.05.2010, 52 ч.
 Очный Класс менеджера проектов:
 Основы управления проектами: 11.05-27.05.2010, 44 ч.
 Экспертный уровень управления проектами: 15.06-
01.07.2010, 40 ч.
 Онлайн Класс руководителя группы разработки:
08.02-15.02.2010, 20 ч. и 01.03-05.03.2010, 20 ч.

10. Чему мы учим?
• Управление проектом • Rational Unified Process
• Анализ требований • Agile, SCRUM
• Проектирование • ISO 2000, CMMI
• Тестирование • PMP
• Конфигурационное • UML, IDEF0
управление
• Управление
изменениями
IT-команда
• J2EE
• Планирование и
контроль • MS .NET
• Деловое общение • Oracle
• Управление людьми • BEA, IBM
• Построение команды • Rational, Mercury
• Презентации • XML, WebServices

11. Soft-labs
 PM-labs: Конференция для менеджеров проектов
 Arch-labs: Конференция для системных архитекторов и
проектировщиков
 Req-Labs: Конференция для системный и бизнес аналитиков
 Test-labs: Конференция для инженеров по тестированию (тест-
менеджеров, тест-дизайнеров, тестировщиков и автоматизаторов
тестирования).
 Dev-labs: Конференция для разработчиков ПО
 Training-Labs: Конференция, посвященная обучению в сфере
Software Engineering. Тренинговый марафон, в котором ведущие
Учебные Центры индустрии, а также независимые тренеры
представляют свои авторские курсы и проводят мастер-классы
Подробнее о конференциях: www.Soft-labs.ru

12. Ближайшие конференции Soft Labs в
Москве
 Training Labs 2010
Москва, 17 апреля
Тренинговый марафон. Обучение в области разработки ПО
www.training-labs.ru
 PM Labs 2010
Москва, 28 сентября
Конференция для менеджеров ИТ проектов
www.pm-labs.ru

13. Семинары/вебинары
Партнерские мероприятия
 Семинары / вебинары – очное / online бесплатное двухчасовое
мероприятие, на котором эксперты Software Engineering (штатные
эксперты УЦ, эксперты производственного подразделения Luxoft,
внешние эксперты) делятся опытом реализации производственных
задач в проектах
 Партнерские мероприятия:
 Семинары/Конференции совместно с Microsoft
 Семинары с Oracle
 Встречи .Net community, UML2.ru community
 и т.п.
Расписание и регистрация на мероприятия:
http://www.luxoft-training.ru, раздел Мероприятия

14. Контакты
Учебный Центр Luxoft: www.Luxoft-Training.ru
E-mail: education@luxoft.com
Филиалы:
- Москва, Санкт-Петербург, Омск
- Киев, Одесса, Днепропетровск
Конференции Soft-labs: www.Soft-Labs.ru
География конференций: Москва, Омск, Киев

15. Часть 1.
Как правильно оценить проект

16. Разработка ПО –
хаос неизбежен?
Chaos Report (Standish Group) – анализ результатов исполнения
~ 70 000 ИТ-проектов, отражение положения дел в ИТ-отрасли
 Succeeded –
выполнены в срок
и в пределах
выделенного
бюджета
 Challenged –
превысили бюджет
и/или сроки
 Failed –
прекратились
ввиду
невозможности
довести проект до
конца
16
Источник: Trends in IT Value – 2008, Copyright © 2008 by The Standish Group International, Inc. All rights reserved.

17. Кто виноват?
Нет, не так: что делать?
 Итак, каждый пятый проект неуспешен, а каждый
второй – исполняется с существенными проблемами
Почему?
 Одна из существенных причин – неправильная оценка проектов
 Оценка – основа планирования, неправильная оценка
делает невозможным качественное планирование, а ведь
«если вы провалите планирование, вы запланируете провал »
17

18. Цели проведения оценки
 Подготовка технико-коммерческих предложений
 Оценка проекта в целом
 Планирование
 Оценка отдельных задач в иерархической структуре работ (WBS)
 Управление изменениями
 Оценка запросов на изменения
 Управление рисками
 Оценка альтернатив
 Переоценка при передаче проекта другой команде
 Оценка несделанной части работ
(Пример: подготовка ТКП –> старт полномасштабного проекта)
 Ваши дополнения? 18

19. В чем измеряются проекты?
 С точки зрения Руководителя проекта?
 В аналогичных проектах
 С точки зрения Аналитика?
 В сценариях (прецедентах) использования (use cases)
 С точки зрения Архитектора?
 В строках кода
 С точки зрения Заказчика?
 В килобаксах  и ключевых контрольных событиях (вехах)
 Почему это важно?
19

20. В чем измеряются проекты –
почему это важно?
 Получать оценку вы будете в понятных оценщику
единицах
 И не требуйте от него преобразования во что-то другое!
 Выдавать оценку Заказчику (потребителю) нужно в
понятных ему единицах
 Преобразовывать одно в другое – вам 
20

21. Методики оценки
 Экспертная оценка
 Оценки с помощью моделей:
 Оценка по аналогии
 Use Case Points (UCP)
 Function Points (FP)
 Fast Function Points (FFP)
 Early Functional Points (EFP)
 Какими из здесь перечисленных и не
перечисленных методик оценки приходилось
пользоваться лично Вам?
21

22. Экспертная оценка (1)
 Методика предназначена для оценки проектов с опорой
на знания и опыт экспертов
 Суть методики:
 Оценка проекта в целом или его отдельных частей экспертами
 На выходе – все, что угодно (но мы возьмем – скорее всего
трудозатраты)
 Плюсы:
 Универсальная методика
 Можно оценивать практически любые системы
 Какие ограничения присущи этой методике?
 Как обходить эти ограничения?
22

23. Экспертная оценка (2)
 Ограничения применимости:
 Зависимость от наличия и квалификации экспертов
 Может быть довольно трудоемкой
 «Человеческий фактор»:
 «все не так» (мало данных – плохо, много данных – тоже плохо)
 усталость
 риск «игнорирования» рисков
 уровень ответственности – у каждого свой
23

24. Экспертная оценка (2)
 Рекомендации:
 Не пытайтесь оценить проект целиком – делайте декомпозицию:
 По сущностям
 Функциональность: количество экранов, отчетов, фидов
(файлов экспорта или импорта) и т.п.
 Данные: количество обрабатываемых сущностей и количество /
сложность связей между ними
 По объектам поставки (система, документация, обучающие
материалы и т.д.) и функциональным блокам
 Перепроверяйте!
 Делайте несколько оценок, анализируйте и усредняйте
 Проверяйте и корректируйте результаты оценки с
помощью метрик
 Используйте PERT (возможно, с подстройкой коэффициентов)
24

25. Оценка по аналогии (1)
 Методика предусматривает оценку проекта на
основании исторических данных. По сути –
автоматизированная версия экспертной методики
 Суть методики:
 Оценка проекта на основании его «измерения» в формах, отчетах,
подсистемах, сущностях и т.п.
 На выходе – как решим, но скорее всего трудозатраты
 Плюсы:
 Устраняет недостатки экспертной методики
 Очень хорошо подходит для развития существующего бизнеса
 При накоплении исторической информации растет точность и
достоверность оценки
25

26. Оценка по аналогии (2)
 Ограничения применимости:
 Необходимо наличие исторических данных и их обработка
 Слабо применима для новых проектов, новых бизнес-областей
 При смене технологических платформ или команды требуется
«перекалибровка»
 Рекомендации:
 Перепроверяйте! (пока не накопите хороший массив статистики)
26

27. Use Case Points (UCP) (1)
 Методика предназначена для оценки проектов, для
которых применяется определение требований с
помощью сценариев (или прецедентов) использования
(Use Cases)
 Суть методики:
 Выявление акторов (actors) и сценариев (прецедентов)
использования, их «взвешивание» (оценка сложности)
 На выходе – трудозатраты
 Плюсы:
 Быстро и просто!
 Хорошо подходит для стандартных информационных систем (много
пользовательского интерфейса, мало сложных алгоритмов)
 Легко подстраивается под производительность команды или
среднюю производительность по компании
27

28. Use Case Points (UCP) (2)
 Ограничения применимости:
 Для проведения оценки нужен аналитик
 Требуется выделение «стандартных» (относительно простых)
сценариев использования
 Оценка сложности выполняется экспертным путем
 Точность зависит от опыта аналитика и корректности
коэффициента пересчета Use Case Points в человеко-часы
 Не все системы можно оценивать по UCP (сложные алгоритмы и
т.п.)
 Рекомендации:
 Подстраивайте под производительность команды
 Если вы разрабатываете системы, описанными с помощью
сценариев использования – используйте в повседневной практике!
28

29. Function Points (FP) (1)
 Методика предназначена для оценки проектов на базе
понятия «функциональная точка»
 Суть методики:
 Выявление всех информационных объектов и всех операций по
обмену данными между системой и акторами (пользователями,
другими системами) и оценка их сложности
 Корректировка результатов – учет нефункциональных требований
 Использование результата (в FP) в калькуляторе COCOMO
(Constructive Cost Model – Barry W. Boehm) (пересчет в
трудозатраты с разбиением по фазам проекта и процессам) или
пересчет в размер кода и далее – в трудозатраты
 Плюсы:
 Высокая точность
 Хорошо подходит для стандартных информационных систем
29

30. Function Points (FP) (2)
 Ограничения применимости:
 Высокая трудоемкость применения методики и большая
продолжительность процесса оценки
 Необходимо детальное понимание того, как работает система
(детальные требования, в идеале – еще и архитектурные решения)
 Коэффициент пересчета FP в SLOCs зависит от языка
программирования и использования «ускорителей»
программистского труда (кодогенераторов и т.п.) – нужно измерять
или покупать
 Калькулятор COCOMO – инструмент, крайне чувствительный к
квалификации оценщика
 Рекомендации:
 Используйте, когда нужна очень точная оценка и есть достаточный
объем входной информации и время на подготовку оценки
30

31. Early Function Points (EFP) (1)
 Разновидность методики Function Points, допускающая
применение в условиях отсутствия детальных
требований
 Суть методики:
 Выявление всех информационных объектов и всех операций по
обмену данными между системой и акторами
 Корректировка результатов – учет нефункциональных требований
 Пересчет в размер кода и далее – в трудозатраты
 Плюсы:
 Точность уровня методики Function Points для детально
определенных частей системы
 Сохранение работоспособности (путем повышение уровня
абстракции) для поверхностно определенных частей системы
 Хорошо подходит для стандартных информационных систем 31

32. Early Function Points (EFP) (2)
 Ограничения применимости:
 Оценка на высоких уровнях абстракции выполняется фактически
экспертным путем
 Коэффициент пересчета FP в SLOCs зависит от языка
программирования и использования «ускорителей»
программистского труда (кодогенераторов и т.п.) – нужно измерять
или покупать
 Невозможность применения результата в калькуляторе COCOMO
 Рекомендации:
 Используйте, когда система описана требованиями разного уровня
детальности, но с преобладанием детальных описаний
32

33. Fast Function Points (FFP) (1)
 Разновидность методики Function Points, допускающая
применение в условиях отсутствия детальных
требований
 Суть методики:
 Выявление всех информационных объектов и всех операций по
обмену данными между системой и акторами (пользователями,
другими системами) без оценки их сложности (= средняя)
 Далее – полная аналогия с Function Points
 Плюсы:
 Нормальная работоспособность для недостаточно детально
определенных частей системы
 Возможность применения результата в калькуляторе COCOMO
 Хорошо подходит для стандартных информационных систем
33

34. Fast Function Points (FFP) (2)
 Ограничения применимости:
 Отсутствует возможность оценки сложности даже для детально
определенных частей системы
 Коэффициент пересчета FP в SLOCs зависит от языка
программирования и использования «ускорителей»
программистского труда (кодогенераторов и т.п.) – нужно измерять
или покупать
 Рекомендации:
 Используйте, когда система описана требованиями близкого и
недостаточного для применения Function Points уровня детальности
 Используйте, когда нужна очень точная оценка и есть достаточный
объем входной информации и время на подготовку оценки
34

35. Метрики (1)
 Расширенный вариант цитаты: «Планирование без измерения
невозможно, а если вы провалите планирование, вы
запланируете провал »
 Мини-опрос:
 Какими метриками Вам приходилось пользоваться в процессе
оценки и в целом в разработке программного обеспечения?
 Для чего?
35

36. Метрики (2)
1. «Эффективность разработки»
 Определение:
 [Общие трудозатраты, чел.-часы] / [размер продукта, KSLOC]
 Применение:
 Оценка трудозатрат на исполнение проекта в целом, если
известен размер кода и наоборот
2. «Производительность кодирования»
 Определение:
 [Размер кода, SLOC] / [трудозатраты на кодирование, чел.-часы]
 Применение:
 Оценка трудозатрат на кодирование, если известен размер кода
и наоборот
36

37. Метрики (3)
3. «Распределение трудозатрат по процессам»
 Определение: Распределение общих проектных трудозатрат
между рабочими процессами:
 Анализ требований, Проектирование, Кодирование,
Тестирование, Документирование, Конфигурационное
управление, Управление проектом
 Применение:
 Получение разбивки проектных трудозатрат на отдельные
процессы (большинство методик дают на выходе полные
проектные трудозатраты)
 Получение общих проектных трудозатрат на основе известных
затрат на один процесс (чаще всего это процессы кодирования
и/или тестирования)
37

38. Проверка оценки
 Сравниваем результаты, полученные по разным
методикам
 Не сошлось? Ищем ошибку у себя, а не в методике!
 Используем метрики
 Соотношение затрат на тестирование и на разработку – проверяем
с помощью метрики «Распределение трудозатрат по процессам»
 Подключаем здравый смысл
38

39. Поправки «на ветер»
 Сработанность команды
 Интеграция с другими системами
 Специальные виды тестирования
 Нагрузочное, производительности, удобства использования, …
 Миграция данных из «старых» систем
 Не забыть, что придется делать хотя бы один раз (возможно –
многократно; возможно – в обе стороны)
 Многоплатформенность
 Разные операционные системы, браузеры, устройства (КПК,
коммуникаторы, смартфоны), …
 Необходимость / сложность обучения пользователей
 Ваши предложения? 39

40. Допущения в оценке
 Допущение – «условие, необходимое для успешного
выполнения проекта»
 Каждое неясное место должно быть закрыто
допущением!
 Допущение – то, что делает оценку реальной
 Не бывает оценок без допущений
 Допущения превращаются в проектные риски
40

41. Где еще можно «подстелить
соломку»?
 «Рваная» загрузка ресурсов в плане-графике – источник
риска перерасхода бюджета
 Понимать, какие фазы оценивались!
 Внедрение, опытная эксплуатация, поддержка – вне оценки по UCP
и FP/FFP/EFP
 «Водопад» для большинства проектов не работает!
 Итерации + активное вовлечение Заказчика
 Учесть риски и допущения и связать с ними буферы в
плане-графике
41

42. Требования неясны, а fixed
price проект делать нужно
 Проекты с фиксированной ценой – ночной (а иногда и
дневной) кошмар менеджеров проектов
 Идеально – оценка по Function Points, но где взять
детальные требования? А что, если они «на салфетках»?
 Выходы:
 Разбиваем проект на относительно короткие итерации и «продаем»
их по отдельности
 Даже если «пролетим» с оценкой, потеряем существенно
меньше
 Оценив и выполнив несколько первых итераций, гораздо лучше
сможем оценивать даже такие «плохие» требования
 Заодно снимаем ключевые риски – правильным выбором
содержания (scope) первых итераций
 Даем грубую оценку и разбиваем проект на 2 части: уточнение и
детализация требований + разработка; с переоценкой между ними
42

43. Часть 2. Как выходить из кризиса
«А с оценкой мы все-таки
"пролетели"…»

44. Что имеем?
Проект недооценен. Мы рискуем не выполнить
обязательства перед Заказчиком:
 На срок
 На бюджет
 Мини-опрос:
 Что хуже?
 И главное – что делать?
44

45. Первые мысли
 Повысить интенсивность труда
 «В сутках 24 часа, а не 8. В крайнем случае – 16…»
 Добавить ресурсов, лучше всего – дешевых
 «У нас же есть филиал в Урюпинске!…»
 Сэкономить время и деньги
 «С тестированием неплохо справится и сам Заказчик…»
 Расслабиться и «засунуть голову в песок»
 «А вдруг повезет? Бывают же форс-мажоры и у Заказчика…»
 «В крайнем случае расскажем всем, что "в жизни все бывает"…»
45

46. Интенсификация
 Плюсы:
 Легко позволяет наверстать несколько дней отставания от графика
 Чем больше команда, тем больше выигрыш
 При умелом использовании способствует сплоченности команды
 Минусы:
 Не надейтесь наверстать месяц отставания
 При длительном или частом применении приносит больше вреда,
чем пользы:
 Разрушается мотивация
 Люди устают, делают больше ошибок, в итоге – с какого-то
момента начинаем тратить больше, чем приобретать
 Нарастают нервозность и негатив, нарушается внутри-
проектная коммуникация, растет риск разрушения команды
 Перерасход бюджета легко выходит из-под контроля
46

47. Добавление ресурсов
 Плюсы:
 В условия низкой связанности задач позволяет разработать
значительное количество дополнительного функционала
 Минусы:
 Теряется время на передачу знаний
 Значительно (непропорционально результату) повышает стоимость
проекта
 Очень рискованно использовать для задач, находящихся на
критическом пути
 Демотивирует команду («они, значит, умнее нас?»)
 «Разбалансирует» команду, отбрасывает ее на этап
«Столкновение» (“Storming”) и тем самым значительно снижает ее
производительность (помним жизненный цикл команды!)
47

48. Если ресурсы еще и дешевые
 (Дополнительные) плюсы:
 (Потенциально) позволяет снизить перерасход бюджета
 (Дополнительные) минусы:
 Передать проект в Урюпинск полностью все равно не успеем, а
поддержка распределенной команды – вещь дорогая
48

49. Сэкономить на качестве…
Расслабиться…
Без комментариев!
49

50. Действуем конструктивно! (1)
Внутренние резервы:
 Мозговой штурм – вместе с командой!
 «Срываем низко висящие плоды»:
 На перфекционизм нет времени!
 Устраняем барьеры для эффективной работы
 Возможно, пришло время нарушить некоторые правила 
 Преподаем команде уроки эффективного управления временем
 Определяем балласт в команде (деморализаторы, болтуны,
халтурщики и т.п.) – отделяем (возможно, временно)
50

51. Действуем конструктивно! (2)
Внутренние резервы (окончание):
 Привлекаем экспертов, вырабатываем альтернативы:
 Оптимизируем решение (более простые и проверенные
технические решения, …)
 Повышаем эффективность работы (тулы, …)
 Определяем альтернативы разработке своими силами (покупные
компоненты, субподряд)
 Заручаемся поддержкой своего руководства:
 Оно много чем может помочь: советом, ресурсами, прямой
коммуникацией с Заказчиком и демонстрацией личного внимания к
проекту
 Возможно, потом – когда основные проблемы будут решены – вам и
достанется за допущенные промахи, но в этот момент вы будете
уже не в худшей позиции
51

52. Действуем конструктивно! (3)
Внешние резервы:
 Заказчик не меньше вас заинтересован в успехе
проекта!
 Вовлекаем ключевых заинтересованных лиц
 Презентуем альтернативы
 Более простые, проверенные и знакомые технические решения т.п.
 Изменяем объем работ
 Принцип Парето: 20% функционала системы удовлетворяют 80%
потребностей пользователей, остальные 80% функционала можно
сделать позже
 Цель проекта – удовлетворение потребностей Заказчика и
пользователей, а не формальная реализация требований!
52

53. Действуем конструктивно! (4)
Менеджер не должен быть «бутылочным горлышком»:
 Делегируйте!
 Помогите людям раскрыть свой потенциал!
«Никогда не говорите людям, как им действовать. Просто скажите,
что нужно сделать, и они удивят вас своей изобретательностью!»
(George S. Patton (1885–1945))
53

54. Полезные ссылки (1)
 Общее:
 «IT Measurement: Practical Advice from the Experts» by International
Function Point Users Group (Addison-Wesley Professional, April 27, 2002,
800 pages) (www.amazon.com, www.ozon.ru)
 «Сравнение методов оценки стоимости проектов по разработке
информационных систем» – Н.Михайловский
(http://www.pmprofy.ru/content/rus/79/797-article.asp)
 COCOMO:
 COCOMO II –
http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html
54

55. Полезные ссылки (2)
 Use Case Points:
 «Project Estimation With Use Case Points» by Roy K. Clemmons
(http://www.stsc.hill.af.mil/crosstalk/2006/02/0602Clemmons.pdf)
 «How to Prepare Quotation Using Use Case Points» by Shivprasad
koirala
(http://www.codeproject.com/KB/architecture/usecasepoints.aspx)
 Function Points:
 IFPUG: International Function Point Users Group – www.ifpug.org
 «Оценка трудоемкости разработки программного обеспечения
методом Function Point с использованием модели COCOMO II» –
Д.Либерман (http://www.talgar.ru/Articles/article.asp?ID=1145)
55

56. Полезные ссылки (3)
 Fast Function Points:
 FAST Function Points by David Seaver (presentation)
(http://sunset.usc.edu/Activities/oct24-27-
00/Presentations/Seaver_FAST%20Function%20Points.pdf)
 Early Function Points:
 Early and Extended Function Point: a new method for Function Points
estimation by Roberto Meli (http://www.dpo.it/resources/papers/1997-
ifpug-exfp-en.pdf)
 Методика Function Points для предварительной оценки трудозатрат
по проекту (http://www.pmprofy.ru/content/rus/20/203-article.asp)
 Early Function Point Counting by Netherlands Software Metrics Users
Association (http://www.nesma.org/english/earlyfpa.htm)
56

57. Вопросы?
57