Your SlideShare is downloading. ×
Как оценить проект, чтобы не было мучительно больно...потом
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Как оценить проект, чтобы не было мучительно больно...потом

4,123
views

Published on

Published in: Business

0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,123
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
118
Comments
0
Likes
4
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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

×