Сравнение методов оценки создания ПО

20.02.12

Функциональные - Управление проектом (PMO, EPM)

Методы оценки размера проектов (микрооценка и макрооценка)

Скачать файл

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование По подписке [?] Купить один файл
СРАВНЕНИЕ МЕТОДОВ ОЦЕНКИ ПРОЕКТОВ ПО СОЗДАНИЮ ПО
.docx 26,23Kb
9
9 Скачать (1 SM) Купить за 1 850 руб.

СРАВНЕНИЕ МЕТОДОВ ОЦЕНКИ ПРОЕКТОВ

МЕТОДЫ ОЦЕНКИ РАЗМЕРА ПРОЕКТОВ

Методы оценки размера проектов разделяются на две основные группы: микрооценка и макрооценка.

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

Методы макрооценки, основанные на функциональных требованиях и/или продукте.

Методы макрооценки:

  • IFPUG FPA
  • COCOMO II
  • модели оценки трудоемкости разработки программных систем, утвержденные Госкомтруда в 1986 году

ОСНОВНЫЕ МОДЕЛИ ДЛЯ ОПРЕДЕЛЕНИЯ ОБЪЕМОВ РАБОТ ПРИ РАЗРАБОТКЕ ИНФОРМАЦИОННЫХ СИСТЕМ

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

...слабо развиты наши методы оценок. В сущности, они отражают молчаливое и совершенно неверное предположение, что все будет идти хорошо.
Фредерик Брукс

Вероятно, одним из наиболее известных моделей данного рода является конструктивная модель стоимости (Constructive Cost Model - COCOMO), разработанная в конце 70х годов Барри Боэмом (Barry Boehm). Построенная на основе анализа ряда проектов, выполненных в основном в интересах Министерства Обороны США, она устанавливает соответствие между размером системы в тысячах условных строк кода и "классом" проекта, с одной стороны, и трудоемкостью разработки системы, с другой стороны.

Базовый тип модели COCOMO учитывает только класс проекта - естественный, полуинтегрированный, "встроенных систем". Естественные проекты - относительно маленькие и разрабатываются командами, знакомыми с прикладной областью. Полуинтегрированные проекты - системы среднего размера и сложности, разрабатываемые группами разработчиков с различным опытом. Проекты "встроенных систем" выполняются при значительных аппаратных, программных и организационных ограничениях.

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

Существенным недостатком данной модели является ее основанность на тысячах условных строк кода, как метрике размера программного комплекса. Видимо, одной из первых попыток отойти от данной метрики размера ПО была разработка Аланом Альбрехтом (Alan Albrecht) в середине 70-х годов метода функциональных точек с целью разработки механизма предсказания усилий, сопряженных с разработкой программных систем. Метод был впервые опубликован в 1979 году. В 1984 году Альбрехт усовершенствовал свой метод и с 1986 года, в котором была сформирована Международная Ассоциация Пользователей Функциональных Точек (International Function Point User Group - IFPUG), было опубликовано несколько ревизий метода.

Со временем модель СОСОМО оказалась устаревшей в значительной своей части. Поэтому на ее основе была разработана модель СОСОМО II, опубликованная в 1999 году. Она усовершенствует оригинальную модель в следующих основных направлениях:

  • использование входных данных, доступных на ранних этапах жизненного цикла системы для оценки ее сложности (в частности, использование функциональных точек);
  • новые - циклические и обобщенные - модели процессов разработки;
  • подходы, основанные на повторном использовании, включая интеграцию коммерческих продуктов, реинжиниринг, генерацию приложений;
  • объектно-ориентированные подходы, поддерживаемые распеделенным ПО промежуточного слоя;
  • влияние зрелости процессов разработки.

В течение восьмидесятых годов в СССР также на основе COCOMO были разработаны собственные модели оценки трудоемкости разработки программных систем, утвержденные Госкомтруда в 1986 году. В них по-своему была решена задача оценки функционального размера программной системы и получения количества тысяч условных машинных команд.

ПАРАМЕТРЫ ДЛЯ СРАВНЕНИЯ ОСНОВНЫХ МОДЕЛЕЙ ДЛЯ ОПРЕДЕЛЕНИЯ ОБЪЕМОВ РАБОТ ПРИ РАЗРАБОТКЕ ИНФОРМАЦИОННЫХ СИСТЕМ

Перечислим те параметры, по которым можно сравнить описанные выше модели.

Тип модели

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

Доступность репозиториев

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

Время применения

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

Независимая оценка трудоемкости и времени

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

Учет факторов размера системы

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

Непрерывная зависимость от сложности проекта

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

Учет функциональной сложности

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

Учет нефункциональных требований к системе

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

Поддержка различных жизненных циклов и разбиения по стадиям жизненного цикла

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

Учет степени новизны

Модель может позволять учитывать степень новизны системы - абсолютной либо для конкретных разработчиков.

Учет использования в разработке типовых элементов

Модель может позволять учитывать использование в разработке типовых элементов.

Учет реинжиниринга или конверсии

Модель может позволять учитывать использование в разработке реинжиниринга или конверсии ранее существовавших приложений.

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

Модель может позволять учитывать использование в разработке готовых коммерческих продуктов.

Учет жесткости требований

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

Учет качества управления проектом, организационных факторов, инфраструктурных факторов, персонала

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

Учет зависимости трудоемкости от средств разработки

Желательно, чтобы модель отражала зависимость трудоемкости от средств разработки.

Учет влияния графика на трудоемкость

Желательно, чтобы модель отражала возрастание трудоемкости разработки в более сжатые сроки

СРАВНЕНИЕ МОДЕЛЕЙ ДЛЯ ОПРЕДЕЛЕНИЯ ОБЪЕМОВ РАБОТ ПРИ РАЗРАБОТКЕ ИНФОРМАЦИОННЫХ СИСТЕМ

В соответствии с вышеизложенным, главными факторами при выборе модели должны являться:

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

Данные факторы для анализируемых нами моделей сведены в табл. 1 -2.

Таблица 1 Основные параметры качества для анализируемых моделей[ 21]

Параметр

Методика Госкомтруда

COCOMO 2.0

FPA IFPUG 4.1

Тип модели

Закрытая

Закрытая

Открытая

Доступность репозиториев

Не приложимо

Не приложимо

Да, множество репозиториев

Время применения

На протяжении всего жизненного цикла

На протяжении всего жизненного цикла после определения требований

На протяжении всего жизненного цикла после определения требований

Учет факторов размера системы

Да

Да

На основе репозитория

Непрерывная зависимость от сложности проекта

Нет

Да

Да

 

Таблица 2 Учет требований к системе в моделях

Параметр

Методика Госкомтруда

COCOMO 2.0

FPA IFPUG 4.1

Учет функциональной сложности

Неадекватный

Да, на основе неcкорректированного количества функциональных точек IFPUG

Да, на основе cкорректированного количества функциональных точек IFPUG

Учет нефункциональных требований к системе

защита информации, распараллеливание вычислений

Надежность, объем обрабатываемых данных, повторная используемость, требования к документированию, изменчивость платформы, ограничения на производительность, ограничения на хранимые данные

Распределенная обработка, Производительность, Загруженность конфигурации, Частота транзакций, повторная используемость, Множество инсталляций, Упрощение внесения изменений

 

Проанализируем подробнее модели на основе этих факторов.

Время применения и учет факторов размера системы

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

Тип модели и доступность репозиториев

Методика Госкомтруда и COCOMO 2.0 являются закрытыми, а FPA IFPUG 4.1 – открытой. 

Учет функциональной сложности

Функциональная сложность в моделях COCOMO 2.0 и FPA IFPUG 4.1 оценивается на основе подсчета функциональных точек. Таким образом, в этом смысле эти две модели аналогичны.

В нижеприведенной табл. 3 сведено сравнение методик по остальным параметрам:

 

Таблица 3 Сравнение методик

Параметр

Методика Госкомтруда

COCOMO 2.0

FPA IFPUG 4.1

Независимая оценка трудоемкости и времени

Нет

Да

Да, на основе данных репозиториев

Поддержка различных жизненных циклов

Да

Да

Да

Поддержка разбиения по стадиям жизненного цикла

Да

Да

В зависимости от репозитория

Учет степени новизны

Платформа, средства

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

 

Нет

Учет использования в разработке типовых элементов

Да

Да

Да

Учет реинжиниринга или конверсии

Нет

Да

Да

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

Нет

Да

Нет

Учет жесткости требований

Нет

Да

Нет

Учет факторов, связанных с командой

Нет

Да

Нет, но может являться свойством репозитория

Учет зависимости трудоемкости от средств разработки

Детальный

Интегрированный

Интегрированный

Учет влияния графика на трудоемкость

Нет

Да

Нет

 

IFPUG FPA наиболее предпочтительно применять на стороне заказчика, а СОСОМО II - на стороне разработчика, так как для заказчика разница в конкретных условиях разработки не важна, а для разработчика - важна.

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

Методы и средства разработки, написания и сопровождения программ за два последних десятилетия потерпели коренные качественные изменения и сегодня характеризуются:

  • преимущественным применением объектно-ориентированного программирования;
  • привлечением новейших средств разработки и написания программ - Java, SQL, С# и т.д.
  • активным использованием WEB-технологий.

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

 

См. также

Управление проектом (PMO, EPM) Пользователь Платформа 1С v8.3 Россия Управленческий учет Платные (руб)

Продукт "1С:Предприятие 8. ERP+PM Управление проектной организацией 2" разработан на основе типовой конфигурации "ERP Управление предприятием 2" с сохранением базового функционала и использует все преимущества технологической платформы "1С:Предприятие" версии 8.3, обеспечивающей масштабируемость, открытость, простоту администрирования и конфигурирования. Продукт предназначен для поддержки управленческой деятельности научно-исследовательских и проектно-изыскательских институтов, инжиниринговых компаний, конструкторских бюро, управляющих и инвестиционных компаний, а также других проектно-ориентированных предприятий и организаций.

32000 руб.

17.02.2016    35019    7    0    

5

Управление проектом (PMO, EPM) Работа с интерфейсом Рабочее место ServiceDesk, HelpDesk Пользователь Руководитель проекта Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 Россия Абонемент ($m)

Представляю вашему вниманию свою версию доски Канбан. Решение создано на управляемых формах в виде расширения. Я делал его максимально автономным, чтобы была возможность использования практически в любой конфигурации. Единственный объект, требующий сопряжения с основной конфигурацией – это справочник Пользователи. Эту разработку можно использовать как для отслеживания прогресса выполнения проектов, так и для учета текущих задач и времени их выполнения.

1 стартмани

28.08.2024    1464    13    umah    4    

7

Управление проектом (PMO, EPM) Руководитель проекта Платформа 1С v8.3 ИТ-компания Управленческий учет Абонемент ($m)

Полная трансформация в работе ваших команд. Цель публикации: Создание единого инструмента коммуникаций и ведения проекта по разработки ПО. Задачи, которые решает данная программа: Избавиться от большого и не интегрированного количества инструментов: excel, jira, wrike, redmine и т.д. Вся команда работает в одном окне. Кому полезна: Руководителям проектов по разработке ПО, Владельцам продуктов, Скрам мастерам, Участникам команды разработки.

1 стартмани

01.07.2024    1419    6    user1930767    2    

7

Управление проектом (PMO, EPM) Россия Бесплатно (free)

Что интересного писали про управление проектами за прошедшую неделю? Мы прочитали все публикации с Хабра, VC, Инфостарта (и не только) и выбрали самые крутые и полезные. Читайте аннотации, сохраняйте и применяйте!

21.05.2024    925    Birby    1    

4

Документооборот и делопроизводство (СЭД) Управление проектом (PMO, EPM) Платформа 1С v8.3 1С:Документооборот Россия Абонемент ($m)

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

5 стартмани

10.07.2023    5752    60    Mattakushi    18    

9

Управление проектом (PMO, EPM) Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Подсистема "Служба поддержки Redmine". Сделана на расширении. Позволяет отправлять заявку из 1С в сервис-деск Redmine. Использует Rest-API Redmine. Поддерживает полноценный редактор Markdown для оформления заявки.

1 стартмани

06.05.2023    3660    13    henr1ck    1    

12

Управление проектом (PMO, EPM) Бизнес-анализ Платформа 1С v8.3 1С:Управление торговлей 11 Оптовая торговля, дистрибуция, логистика Россия Управленческий учет Бесплатно (free)

Успешен ли бизнес, где его слабые места, а где — возможности для роста? Корректно отвечать на эти вопросы, опираясь на данные управленческой отчётности. О том, как мы внедрили «1С:УТ» и настроили качественный управленческий учёт, — в нашем кейсе.

26.04.2023    1736    ystetsenko    0    

0
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
0. alsoumars 1 20.02.12 20:11 Сейчас в теме
Методы оценки размера проектов (микрооценка и макрооценка)


Перейти к публикации

1. Сергей Осипенко 20.02.12 20:11 Сейчас в теме
...оценки трудоемкости разработки программных систем, утвержденные Госкомтруда

феерично
2. leha.mos 25.02.12 23:40 Сейчас в теме
Где это можно применить? Для чего вся эта информация!? Хотелось бы хотя-бы один пример использования на практике.
Оставьте свое сообщение