Методика оценки трудоемкости и стоимости разработки и сопровождения прикладного программного обеспечения при создании информационных систем (Методика CETIN)

Методика оценки трудоемкости и стоимости разработки и сопровождения прикладного программного обеспечения при создании информационных систем (Методика CETIN) Методика основана на измерении функционального размера информационной системы на основе функциональных требований пользователей к разрабатываемой информационной системе. Функциональный размер информационной системы измеряется пятью функциональными единицами измерения. Название методики CETIN представляет собой аббревиатуру, образованную из обозначений функциональных единиц измерения: C - Case, E – Entity, T – Tool, I – Interaction, N – Node. В настоящем документе приводятся алгоритмы определения функционального размера информационной системы, расчета трудоемкости и стоимости разработки и сопровождения прикладного программного обеспечения. Методика учитывает также требования качества и технические требования к информационной системе. Принципы оценки трудоемкости и стоимости разработки и сопровождения ППО Методика оценки трудоемкости и стоимости разработки и сопровождения ППО основана на следующих принципах: 1. Принцип поддержки жизненного цикла. Данный принцип означает, что Методика должна основываться на процессах жизненного цикла ИС; 2. Принцип измерения функционального размера. Данный принцип означает, что Методика должна базироваться на методе измерения функционального размера функциональных требований пользователя; 3. Принцип универсальности (нелокальности). Данный принцип означает, что Методика должна быть применима для оценки стоимости разработки и сопровождения любого ППО. 4. Принцип улучшающейся оценки. Данный принцип означает, что точность оценки трудоемкости и стоимости разработки ППО должна повышаться с увеличением степени детализации функциональных требований к ИС. 5. Принцип учета технологии производства программного обеспечения. Методика базируется на процессах разработки ППО – методологии RUP, которая обеспечивает реализацию процессов разработки и сопровождения ИС согласно жизненного цикла определенного в. Жизненный цикл разработки ППО согласно методологии RUP состоит из 6 основных, 3 вспомогательных процессов. Методика базируется на измерении трудоемкости шести основных процессов, при этом трудоемкость вспомогательных процессов косвенно учитывается в нормативных коэффициентах трудоемкости. Порядок оценки трудоемкости разработки прикладного программного обеспечения Порядок оценки трудоемкости разработки ППО представлен следующими этапами: 1 этап. Оценка функционального размера разрабатываемой ИС На данном этапе делается оценка функционального размера ИС на основании модели информационной системы и функциональных требований пользователей. Функциональный размер ИС представляет собой набор из пяти элементов, каждый элемент которого измеряется в соответствующей функциональной единице измерения. 2 этап. Оценка базовой трудоемкости разработки ППО На данном этапе оценивается базовая трудоемкость каждого основного процесса разработки ППО в человеко-месяцах. Базовая трудоемкость каждого процесса определяется на основе нормативных коэффициентов трудоемкости. 3 этап. Определение значений поправочных коэффициентов 2 Исходя из характеристик создаваемой информационной системы и требований к ее функционированию, требований качества и технических требований определяются значения поправочных коэффициентов к трудоемкости. 4 этап. Расчет трудоемкости с учетом поправочных коэффициентов На основании поправочных коэффициентов к трудоемкости разработки ППО делается расчет трудоемкости разработки ППО с учетом поправочных коэффициентов. 5 этап. Оценка срока разработки ППО На данном этапе оценивается средний срок разработки ППО. 6 этап. Корректировка трудоемкости разработки ППО при уменьшении срока разработки На данном этапе производится корректировка трудоемкости разработки ППО в случае уменьшения среднего срока разработки на основе коэффициента эластичности трудоемкости. 7 этап. Оценка стоимости разработки ППО На данном этапе, на основании расcчитанной трудоемкости разработки ППО определяется стоимость разработки ППО. 1. Оценка функционального размера ИС Оценка функционального размера ИС производится на основании модели информационной системы и функциональных требований пользователей. Функциональный размер ИС задается набором из пяти элементов, каждый элемент которого представляет собой соответствующую функциональную единицу измерения. В следующей таблице приведены наименования и обозначения функциональных единиц измерения, используемых в настоящей методике. Таблица 1 - функциональные единицы измерения Наименование функциональных единиц измерения Количество вариантов использования Количество типов объектов Количество свойств типов объектов Количество взаимодействий между типами объектов Количество типов узлов Обозначение функциональных единиц измерения C (case) E (entity) T (tool) I (interaction) N (node) Функциональный размер обозначается - SIZE={C, E, T, I ,N} Примечание: Функциональный размер информационной системы, записанный в виде SIZE={12, 26, 134, 102, 4} означает, что модель информационной системы имеет следующие значения функциональных единиц измерения: ● 12 вариантов использования; ● 26 типов объектов; ● 134 свойств типов объектов; ● 102 взаимоотношения между типами объектов; ● 4 типа узла информационной системы. Функциональный размер информационной системы определяется путем подсчета значений функциональных единиц измерения для модели информационной системы. Входными документами для оценки функционального размера ИС могут служить: Видение информационной системы, Концепция информационной системы, Техническое задание на разработку информационной системы и другие. 3 Для оценки функционального размера рекомендуется использовать модель информационной системы, реализованной на языке моделирования UML. Для применения настоящей методики желательно изначально иметь следующие диаграммы: диаграмма вариантов использования (Use case diagram, диаграмма прецедентов), диаграмма классов (Class diagram), диаграмма коммуникаций (Communication diagram) и диаграмма развертывания (Deployment diagram). Если необходимые диаграммы построены, то расчет выполняется следующим образом: Шаг 1. Количество вариантов использования (С) определяется из диаграммы вариантов использования модели информационной системы. Шаг 2. Количество типов объектов (E) оценивается подсчетом количества неодинаковых классов, изображенных на диаграммах классов; Шаг 3. Количество свойств типов объектов (T) оценивается подсчетом количества свойств классов, изображенных на диаграммах классов; Шаг 4. Количество взаимодействий между типами объектов (I) оценивается подсчетом количества связей (отношений) между классами на диаграмме коммуникаций; Шаг 5. Количество типов узлов (N) оценивается подсчетом количества типов узлов на диаграмме развертывания. При отсутствии модели информационной системы на языке UML оценщику рекомендуется самостоятельно построить модель разрабатываемой информационной системы. Для оценки функционального размера пользователь должен знать основные функциональные возможности будущей информационной системы и уметь измерить эти возможности в функциональных единицах измерения. Оценка функционального размера информационной системы состоит из следующих шагов: ● Оценка количества вариантов использования информационной системы; ● Оценка количества типов объектов предметной области; ● Оценка количества свойств типов объектов; ● Оценка количества взаимодействий между типами объектов; ● Оценка количества типов узлов; ● Оценка функционального размера. В разделах 3.1-3.5 настоящего документа приведены методы определения значений функциональных единиц измерений в случае отсутствия UML-диаграмм модели разрабатываемой информационной системы. Оценка количества вариантов использования информационной системы Целью данного шага является оценка окружения информационной системы (выявление акторов) и определение количества вариантов использования. Каждый из акторов отождествляется с чем-то или с кем-то, взаимодействующим с системой. Актор способен выполнять различные функции: ● только снабжать информацией систему; ● только получать информацию из системы; ● снабжать информацией и получать информацию из системы. Множество акторов обычно обнаруживается в результате анализа требований или в ходе обсуждения проблемы с заинтересованными лицами и экспертами в предметной области. Помощь в выявлении акторов окажут ответы на вопросы, приведенные в следующей таблице, которую рекомендуется заполнить. Таблица 2 - рекомендуемые вопросы для выявления акторов Вопросы Ответы Кто именно заинтересован в выполнении определенного требования? В каком подразделении организации должна использоваться система? Кто получит преимущества от внедрения системы в эксплуатацию? Кто будет поставлять системе те или иные данные, обращаться к ним 4 и нести ответственность за их обновление и удаление? Кому предстоит выполнять обязанности администратора системы? Будет ли система использоваться совместно с какими-либо существующими унаследованными системами? В результате ответов на вопросы таблицы можно выделить основных акторов. Процедура выявления акторов системы носит итеративный характер – первый вариант списка редко бывает окончательным. Новые акторы могут появляться в любой фазе разработки ИС. Чем полнее и правильнее определен перечень акторов, тем точнее можно оценить трудоемкость разработки. Далее производится выявление вариантов использования информационной системы акторами. Основная задача модели Вариантов использования - представлять собой единое средство, позволяющее заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение системы. Каждый актор использует информационную систему для получения конкретных результатов, для удовлетворения своих потребностей. Для каждого актора составляется перечень вариантов использования системы. Помощь в выявлении вариантов использования (функциональных возможностей ИС) окажут ответы на вопросы, приведенные в следующей таблице, которую рекомендуется заполнить. Таблица 3 - рекомендуемые вопросы для выявления вариантов использования Вопросы Ответы Какие задачи решает каждый актор? Способен ли тот или иной актор создавать, сохранять, изменять, удалять или считывать фрагменты данных в контексте системы? Какие варианты использования гарантируют выполнение указанных выше функций обработки данных? Какие варианты использования связаны с поддержкой и администрированием системы? Какие специфические функциональные требования предъявляет каждый актор к информационной системе? В результате определяется перечень вариантов использования информационной системы для каждого актора, который оформляется в виде таблицы 4. № 1 Наименование актора Актор 1 2 Актор 2 3 Актор 3 Таблица 4 - перечень акторов и вариантов использования Наименование варианта использования Вариант использования 1 Вариант использования 2 Вариант использования 2 Вариант использования 4 Вариант использования 1 Вариант использования 3 Один вариант использования может быть использован несколькими акторами, поэтому необходимо составить перечень различных (не одинаковых) вариантов использования на основании записей таблицы 4, который заносится в таблицу 5. Таблица 5 – перечень вариантов использования № 1. 2. 3. 4. Наименование варианта использования Вариант использования 1 Вариант использования 2 Вариант использования 3 Вариант использования 4 5 На основании записей вышеприведенной таблицы можно оценить значение функциональной единицы измерения: ● Количество вариантов использования (С) – количество записей таблицы 5. следующей Оценка количества типов объектов предметной области На данном шаге выявляются все типы объектов предметной области (бизнес объекты), участвующие в вариантах использования. При выполнении каждого варианта использования информационная система оперирует объектами предметной области и реализует поведение этих объектов при достижении результатов варианта использования. Таблицу 4 при этом можно дополнить новым столбцом (последний столбец следующей таблицы 6): Таблица 6 - перечень типов объектов предметной области № Актор 1. Актор 1 1.1. 1.2. 1.3. 1.4 1.5 1.6 1.7 2. Актор 2 2.1. 2.2. 2.3. 2.4 2.5 2.6 3. Актор 3 3.1. 3.2. 3.3. 3.4 3.5 3.6 3.7 Вариант использования Типы объектов предметной области Вариант использования 1 Тип объекта 1 Тип объекта 2 Тип объекта 3 Вариант использования 2 Тип объекта 4 Тип объекта 5 Тип объекта 2 Вариант использования 2 Тип объекта 4 Тип объекта 5 Тип объекта 2 Вариант использования 4 Тип объекта 2 Тип объекта 5 Вариант использования 1 Тип объекта 1 Тип объекта 2 Тип объекта 3 Вариант использования 3 Тип объекта 1 Тип объекта 4 Тип объекта 6 После заполнения таблицы необходимо выявить различные (неодинаковые) типы объектов предметной области. На основании записей вышеприведенной таблицы можно оценить значение следующей функциональной единицы измерения: ● Количество типов объектов (E) – количество различных (неодинаковых) типов объектов, полученных из столбца «типы объектов предметной области» Оценка количества свойств типов объектов Для оценки размера функциональной единицы «Количество свойств типов объектов» достаточно посчитать количество свойств классов на диаграммах классов. Если диаграмма классов не построена, тогда оценщик определяет для каждого типа объекта количество его свойств и заносить результат в следующую таблицу 7. 6 Таблица 7 - количество свойств типов объектов № Акторы Варианты использования Типы объектов предметной области Количество свойств (атрибутов), которые не являются ссылкой На основании записей таблицы можно сделать оценку следующей функциональной единицы измерения: ● Количество свойств типов объектов (T) – сумма значений столбца «Атрибуты, которые не являются ссылкой», для различных (не одинаковых) типов объектов. Оценка количества взаимодействий между типами объектов Оценка количества взаимодействий между типами объектов осуществляется на основе подсчета количества взаимодействий (связей) между классами на диаграмме коммуникаций, либо с помощью заполнения следующей бинарной таблицы 8. Тип (1) Тип (2) Тип (3) … Тип (n-1) Тип (n) Тип (1) 1 Тип (2) 1 1 1 1 Тип (3) 1 1 1 Таблица 8 - Взаимодействия между типами объектов … Тип (n-1) Тип (n) … 1 … 1 1 … 1 1 … 1 … … Каждая ячейка таблицы равна либо 0, либо 1. Если тип объектов строки взаимодействует с типом объектов столбца таблицы, то в ячейку на пересечении соответствующей строки и столбца записывается значение 1, в противном случае – 0. На основании записей в таблице 8 производится оценка следующей функциональной единицы измерения: ● Количество взаимодействий между типами объектов (I) – сумма значений всех ячеек таблицы 8. Оценка количества типов узлов Оценка количества типов узлов определяется на основании диаграммы развертывания информационной системы. Количество типов узлов подсчитывается как общее число типов узлов на диаграмме развертывания. Если UML-диаграмма развертывания не построена, то количество типов узлов можно оценить по количеству типов процессоров и устройств, используемых при функционировании информационной системы. Примерами процессоров и устройств могут служить рабочие станции, серверы, брандмауэры, принтеры, сканеры и другие. Оценка функциональной единицы измерения производится следующим образом: ● Количество типов узлов (N) – количество типов процессоров и устройств, используемых при функционировании системы. Определение функционального размера После выполнения всех шагов оценки функциональных единиц измерения, приведенных в разделах 3.1-3.5 настоящей методики, заполняется следующая таблица 9. Таблица 9 - функциональный размер 7 количество вариантов использования SIZE С количество количество количество взаимодействий типов свойств типов между типами объектов объектов объектов E T I количество узлов N 2. Расчет базовой трудоемкости разработки ППО Базовая трудоемкость разработки ППО определяется на основе оценки трудоемкости каждого процесса разработки ППО. В следующей таблице 10 приведен перечень основных процессов разработки ППО согласно методологии RUP. Таблица 10 - основные процессы разработки ППО Номер Наименование процесса процесса (j) 1 Бизнес моделирование 2 Управление требованиями 3 Проектирование 4 Реализация 5 Тестирование 6 Развертывание Базовая трудоемкость каждого процесса разработки рассчитывается как сумма произведений единиц измерения функционального размера и значений нормативных коэффициентов трудоемкости соответственно. Базовая трудоемкость Sj процесса разработки с номером j рассчитывается по следующей формуле: Sj=1/165·[C*Sj(C)+E*Sj(E)+T*Sj(T)+I*Sj(I)+N*Sj(N)], (1) где Sj - трудоемкость процесса разработки с номером j в [человеко-месяц] j - номер процесса разработки - нормативные коэффициенты трудоемкости реализации одного варианта Sj(C) использования в процессе разработки с номером j=1,2,…,6, {[человекочас]/[вариант]} Sj(E) - нормативный коэффициент трудоемкости реализации одного типа объектов в процессе разработки с номером j=1,2,...,6. {[человеко-час]/[тип объектов]} Sj(T) - нормативный коэффициент трудоемкости реализации одного свойства типа объекта в процессе разработки с номером j=1,2,...,6. {[человеко-час]/[свойство типа объектов]} Sj(I) - нормативный коэффициент трудоемкости реализации одного взаимодействия между типами объектов в процессе разработки с номером j=1,2,...,6. {[человекочас]/[взаимодействие между типами объектов]} Sj(N) - нормативный коэффициент трудоемкости реализации одного типа узла в процессе разработки с номером j=1,2,...,6. {[человеко-час]/[узел]} функциональный размер информационной системы, определенный в разделе 3.6, в функциональных единицах измерения - количество человеко-часов в одном человеко-месяце. SIZE={C,E,T,I,N} 165 Значения нормативных коэффициентов трудоемкости приведены в таблице А1 раздела А.1 приложения А. По столбцам таблицы А1 расположены функциональные единицы измерения, по строкам - процессы 8 разработки. В каждой ячейке таблицы находится значение соответствующего нормативного коэффициента трудоемкости. 3. Определение поправочных коэффициентов к трудоемкости Метод оценки трудоемкости, приведенный в разделе 4, определяет трудоемкость реализации функциональных требований пользователя, которые не включают в себя технические требования к системе и требования качества пользователя. Влияние этих требований в настоящей методике учитываются через поправочные коэффициенты. Поправочные коэффициенты к трудоемкости процессов разработки определяются как произведения частных поправочных коэффициентов, рассчитываемых по формулам, приведенным в таблице 12. Перечень частных поправочных коэффициентов определен в соответствии с [2] и приведен в таблице А2 раздела А.2 приложения А. Все частные поправочные коэффициенты являются безразмерными величинами и сгруппированы в три группы в зависимости от типов влияющих факторов:  внутренние факторы,  факторы среды;  факторы данных. Каждая группа состоит из соответствующих факторов, влияющих на трудоемкость разработки, а каждый фактор из возможных значений фактора. Первая колонка содержит обозначение соответствующего частного поправочного коэффициента. Каждый частный поправочный коэффициент увеличивает или уменьшает трудоемкость реализации функционального размера программных средств с учетом технических требований к системе и качественных требований пользователя. Для определения значения общих поправочных коэффициентов необходимо сначала определить значения всех 20 частных поправочных коэффициентов. Границы значений частных поправочных коэффициентов приведены в таблице А2 приложения 1 к настоящей методике. Алгоритм определения значения частного поправочного коэффициента одинаков для всех коэффициентов. Для каждого из 20 факторов определяется наиболее подходящее значение для разрабатываемой информационной системы путем выбора значения из соответствующего интервала (раздел А.2. приложения А). Если при расчете возникают затруднения по поводу выбора значения частного поправочного коэффициента, то рекомендуется использовать среднее значение из указанного интервала. Значения поправочных коэффициентов для соответствующих процессов разработки из таблицы 10 определяются как произведения значений частных поправочных коэффициентов по формулам, приведенным в следующей таблице. Номер Обозначение процесса поправочного коэффициента 1 КП1 Таблица 11 - определение поправочных коэффициентов Формула для определения поправочного коэффициента К11·К16·К17 2 КП2 К1·К2·К4·К5·К6·К7· К8·К9·К16·К17·К18 3 КП3 К1·К2·К4·К5·К6·К7·К8·К9·К11·К12·К13·К14·К15·К16·К17·К18 4 КП4 К1·К2· К4·К5·К6·К7·К8·К9·К10·К12·К13·К14·К15·К16·К17·К18 5 КП5 К1·К2·К4·К5·К6·К7·К8·К9·К10·К11·К12·К13·К14·К15·К16·К17· К18 6 КП6 К1·К2·К11· К16· К18 9 4. Расчет трудоемкости с учетом поправочных коэффициентов На основании поправочных коэффициентов к трудоемкости разработки ППО делается расчет трудоемкости разработки ППО с учетом поправочных коэффициентов по следующей формуле: S=КП1*S1+КП2*S2+КП3*S3+КП4*S4+КП5*S5+КП6*S6, (2) где S Sj КПj Скорректированная трудоемкость процесса разработки ППО в человеко-месяцах Базовая трудоемкость процесса разработки с номером j в человеко-месяцах Поправочный коэффициент к трудоемкости процесса разработки с номером j 5. Оценка срока разработки информационной системы Для оценки срока разработки информационной системы необходимо воспользоваться следующей таблицей, в которой приведена зависимость между сроком разработки и трудоемкостью разработки ППО. Данная зависимость рассчитана на основе математической модели зависимости срока разработки при командной работе [6]. № 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. Срок разработки ППО 1 месяц 2 месяца 3 месяца 4 месяца 5 месяцев 6 месяцев 7 месяцев 8 месяцев 9 месяцев 10 месяцев 11 месяцев 12 месяцев 13 месяцев 14 месяцев 15 месяцев 16 месяцев 17 месяцев 18 месяцев 19 месяцев 20 месяцев 21 месяц 22 месяца 23 месяца 24 месяца 25 месяцев 26 месяцев Таблица 12 - зависимость срока разработки от трудоемкости Трудоемкость (человеко-месяц) 5 – 30 10 – 80 17 – 140 26 – 210 37 – 280 50 – 340 65 – 400 80 – 450 100 – 500 120 – 550 140 – 610 160 – 670 180 – 720 200 – 770 230 – 820 260 – 870 290 – 930 330 – 990 370 – 1040 420 – 1090 470 – 1150 530 – 1200 600 – 1250 670 – 1300 750 – 1350 830 – 1400 10 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 27 месяцев 28 месяцев 29 месяцев 30 месяцев 31 месяц 32 месяца 33 месяца 34 месяца 35 месяцев 36 месяцев 37 месяцев За каждый последующий месяц 900 – 1450 970 – 1500 1150 – 1550 1230 – 1600 1310 – 1660 1390 – 1720 1470 – 1780 1520 – 1840 1570 – 1900 1620 – 1960 1680 – 2020 Добавляется 40 чел-мес. Для определения срока разработки по данной таблице определяется минимальное и максимальное количество месяцев разработки и определяется среднее арифметическое между этими значениями. Примечание: Например, если трудоемкость составляет 140 человеко-месяцев, то по таблице минимальный срок разработки равен 3 месяцам, а максимальный срок разработки равен 11 месяцам, тогда средний срок разработки равен 7 месяцам (7=(3+11)/2). Если трудоемкость S=1000 чел.-мес., то средний срок разработки равен (19+28)/2=23,5 месяца. 6. Корректировка трудоемкости разработки ППО при уменьшении срока разработки Срок разработки ППО может быть уменьшен до минимального срока разработки определенного в разделе 7. При этом посчитанная трудоемкость разработки увеличивается пропорционально коэффициенту эластичности трудоемкости из раздела А.3 приложения А. Если срок разработки уменьшается на Х%, то трудоемкость разработки увеличивается на L*X%, где L - коэффициент эластичности трудоемкости. Примечание. Например если трудоемкость составляет 140 человеко-месяцев, то минимальный срок разработки равен 3 месяцам, а средний срок разработки равен 7 месяцам. Если средний срок разработки уменьшается до 5 месяцев (на 28,5%), то трудоемкость разработки увеличивается на 28,5*L%. 7. Оценка стоимости разработки ППО Стоимость разработки ППО рассчитывается как произведение трудоемкости разработки ППО, определенной в разделе 6 или 8 на тарифную ставку человеко- месяца утвержденную уполномоченным органом на планируемый период из раздела 3 приложения 1. 8. Порядок оценки трудоемкости и стоимости процесса сопровождения прикладного программного обеспечения Процесс сопровождения прикладного программного обеспечения заключается в управлении модификацией, миграцией и выводом из действия компонентов ППО в соответствии с запросами заказчиков по причине выявленных проблем или потребности в усовершенствовании или адаптации. Содержание процесса сопровождения ППО соответствует содержанию процессов разработки ППО. В процессе сопровождения ППО разрабатывается стратегия поддержки для управления 11 модификацией, миграцией и выводом из действия компонентов ППОв соответствии со стратегией выпуска, определяется влияние организационных, операционных и коммуникационных аспектов на действующую систему, спецификации, проектная документация и стратегии тестирования. Модифицированные компоненты ППО разрабатываются вместе с тестами, подтверждающими, что требования к ППО продолжают удовлетворяться, обновления ППО передаются в среду заказчика, по требованию программные средства и системы выводятся из употребления контролируемым образом, сводящим к минимуму воздействие на заказчика. Оценка функционального размера сопровождения ППО определяется как сумма функциональных размеров модификаций по всем процессам разработки ИС. Функциональный размер модификации ППО определяется по следующей формуле: где SIZE=SIZEADD+SIZEDEL+SIZEMOD (3) SIZE- функциональный размер модификации ППО; SIZEADD- функциональный размер добавленных функциональных требований пользователя; SIZEDEL- функциональный размер удаленных функциональных требований пользователя;; SIZEMOD- функциональный размер измененных функциональных требований пользователя;. Оценки трудоемкости и стоимости сопровождения ППО определяются на базе функционального размера модификации также как трудоемкость и стоимость процессов разработки программных средств.