Тема 1 Введение в экономику ПИ Лекция 2

Тема 1. Введение в экономику ПИ Лекция 2. Обзор методов оценки разработки ПП

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

Классификация методов оценки стоимости ПО К неалгоритмическим методам относятся: 3 Price-to-win Оценка по Паркинсону Экспертная оценка Оценка по аналогии

Классификация моделей оценки стоимости ПО Модели разделяют по типу используемых функций на линейные мультипликативные степенные по использованию исторических данных на эмпирические аналитические Наиболее часто реализуемыми и хорошо документированными моделями являются модель COCOMO (степенная, эмпирическая) и метод Function Points (? И ? , FP), а также модель Путнэма (степенная и аналитическая, SLIM) 4

Обзор неалгоритмических методов: Метод Price -to-win Метод основывается на принципе "клиент всегда прав" Суть метода состоит в том, что независимо от предполагаемых реальных затрат на разработку проекта, оценка стоимости ПО корректируется в соответствии с пожеланиями заказчика Price-to-win фактически является политикой проведения переговоров с клиентом, поэтому часто применяется компаниями, не имеющими средств для качественной оценки проектов Применение метода может иметь для разработчика следующие негативные последствия: 5 нехватка ресурсов для выполнения проекта невыполнение сроков сдачи проекта и как результат – потеря контракта или банкротство

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

Обзор неалгоритмических методов: Экспертная оценка (1) Методы экспертной оценки предназначены для оценки проектов с опорой на знания и опыт экспертов Суть методов Достоинства 7 Оценка проекта в целом или его отдельных частей экспертами На выходе должны быть трудозатраты Универсальная методика Можно оценивать практически любые системы

Обзор неалгоритмических методов: Экспертная оценка (2) Ограничения применимости Зависимость от наличия и квалификации экспертов Экспертная оценка – достаточно трудоемкая процедура Наличие "человеческого фактора": 8 «Все не так" (например, мало данных или много данных) Усталость Риск "игнорирования" рисков У каждого эксперта свой уровень ответственности

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

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

Обзор неалгоритмических методов: Оценка по аналогии (2) Ограничения применимости: Необходимо наличие исторических данных и их обработка Слабо применима для новых проектов, новых бизнесобластей При смене технологических платформ или команды требуется "перекалибровка" Рекомендации от LUXOFT: 11 Необходимо результаты перепроверять, пока не будет создан хороший массив статистических данных

Обзор алгоритмических моделей: модель СОСОМО Суть модели: Модель основывается на расчёте трудоемкости и стоимости разработки как функции от размера программы Размер выражается в оценочных тысячах строк кода (KLOC - kilo lines of code) COCOMO применим к трем классам проектов разработки ПО: Органический (Organic mode) – маленькие команды с хорошим опытом работы и не жесткими требованиями к разработке Полу разделённый вид (Intermediate/Semi-detached mode) – средние по размеру команды со смешанным опытом разработки и со смешанными требованиями (как жесткими, так и нет). Встроенный вид (Intered/Embedded mode) – разрабатываются с учетом множества жестких ограничений (по аппаратному, программному, операционному обеспечению и т. д. 12

Обзор алгоритмических моделей: Классификация метода FP Группа методов функциональных точек FP : Function Points (FP) Fast Function Points (FFP) Early Function Points (EFP) 13

Обзор алгоритмических моделей: Function Points (FP) - 1 Метод предназначен для оценки проектов на базе понятия "функциональная точка" Суть метода: Выявление всех информационных объектов и всех операций по обмену данными между системой и актёрами (пользователями, другими системами) и оценка их сложности Корректировка результатов – учет нефункциональных требований Использование результата (в FP) в калькуляторе СОСОМО (Constructive Cost Model – Barry W. Boehm) – пересчет в трудозатраты с разбиением по фазам и процессам проекта или пересчёт в размер кода, а затем в трудозатраты Достоинства: 14 Высокая точность Хорошо подходит для стандартных ИС

Обзор алгоритмических моделей: Function Points (FP) - 2 Ограничение применимости: Высокая трудоемкость и большая продолжительность процесса оценки Необходимо детальное понимание того, как работает система (требуются детальные требования, а в идеале и архитектурные решения) Коэффициенты пересчета FP в SLOCs зависит от языка программирования и использования "ускорителей" программистского труда - нужно измерять или покупать Точность зависит от опыта аналитика и корректности пересчета Use Case Points в человека-часы Калькулятор СОСОМО – инструмент, крайне чувствительный к квалификации оценщика Рекомендации от LUXOFT: 15 Используйте, когда нужна точная оценка, есть достаточный объем входной информации и время на подготовку оценки

Обзор алгоритмических моделей: Early Function Points (EFP) - 1 Это разновидность FP и отличается от него тем, что допускает применение в условиях отсутствия детальных данных Суть метода: Выявление всех информационных объектов и всех операций по обмену данными между системой и актёрами Корректировка результатов – учет нефункциональных требований Пересчет в размер кода, а затем в трудозатраты Достоинства: 16 Точность уровня FP для детально определенных частей системы Сохранение работоспособности (путем повышения уровня абстракции) для поверхностно определенных частей системы Хорошо подходит для стандартных ИС

Обзор алгоритмических моделей: Early Function Points (EFP) - 2 Ограничение применимости: Оценка на высоких уровнях абстракции выполняется фактически экспертным путем Коэффициенты пересчета FP в SLOCs зависит от языка программирования и использования "ускорителей" программистского труда- нужно измерять или покупать Невозможность применения результата в калькуляторе СОСОМО Рекомендации от LUXOFT: 17 Используйте, когда система описана требованиями разного уровня детальности, но с преобладанием детальных описаний

Обзор алгоритмических моделей: Fast Function Points (FFP) - 1 Это разновидность FP и отличается от него тем, что допускает применение в условиях отсутствия детальных требований Суть метода: Выявление всех информационных объектов и всех операций по обмену данными между системой и актёрами без оценки их сложности, т. к. используется средняя оценка Далее по аналогии с FP Достоинства: 18 Нормальная работоспособность для недостаточно детально определенных частей системы Хорошо подходит для стандартных ИС Возможность применения результата в калькуляторе СОСОМО

Обзор алгоритмических моделей: Fast Function Points (FFP) - 2 Ограничение применимости: Отсутствует возможность оценки сложности даже для детально определенных частей системы Коэффициенты пересчета FP в SLOCs зависит от языка программирования и использования "ускорителей" программистского труда- нужно измерять или покупать Невозможность применения результата в калькуляторе СОСОМО Рекомендации от LUXOFT: 19 Используйте, когда система описана требованиями близкого и недостаточного уровня детальности для применения FP Используйте, когда нужна очень точная оценка и есть достаточный объем входной информации и время на подготовку оценки

Обзор алгоритмических моделей: Use Case Points (UCP) - 1 Метод предназначен для оценки проектов, в которых требования определяются с помощью сценариев (прецедентов) использования Суть метода: Выявление актёров и сценариев использования, их "взвешивание" (оценка сложности) На выходе – трудозатраты Достоинства: 20 Быстро и просто! Хорошо подходит для стандартных ИС (много пользовательского интерфейса, мало сложных алгоритмов) Легко подстраивается под производительность команды или среднюю производительность по компании

Обзор алгоритмических моделей: Use Case Points (UCP) - 2 Ограничение применимости: Для проведения оценки нужен аналитик Требуется выделение "стандартных" (относительно простых) сценариев использования Оценка сложности выполняется экспертным путем Точность зависит от опыта аналитика и корректности пересчета Use Case Points в человека-часы Не все системы можно оценивать по UCP (например, сложные алгоритмы невозможно) Рекомендации от LUXOFT: 21 Подстраивайте оценку под производительность команды Применяйте сценарии использования в повседневной практике

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