ОЦЕНКА СЛОЖНОСТИ В ПРОЕКТАХ ПО РАЗРАБОТКЕ ПРОГРАММНЫХ СРЕДСТВ

Максимова Наталья Владимировна

Преподаватель информатики и Информационных технологий

Государственное бюджетное профессиональное

образовательное  учреждение Московской области

«Дмитровский техникум»

Структурное подразделение №3 «Дубна»

Дубна, 2021

Оглавление

Введение. 3

Модель СОСОМО.. 6

Модель СОСОМО II 8

Методика Agile СОСОМО II. 10

Модификация методик СОСОМО II и Agile СОСОМО II 11

Заключение. 13

Список литературы.. 14

Введение

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

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

Существующие модели хорошо применимы к так называемым информационным системам, т.е. системам, основные функции которых связаны с накоплением и хранением больших объемов данных, предоставлением доступа и интерактивной обработкой запросов к ним. На рис. 1 представлены некоторые из этих моделей в их историческом развитии.

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

·         Плохое управление проектом

·         «Плывущие»  требования

·         Неправильная оценка проекта

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

«Плывущие»  требования

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

·         Постепенное понимание заказчиком того, что же ему на самом деле нужно

·         Изменение бизнеса заказчика за время реализации проекта

Понятны и негативные следствия плывущих требований:

·         Разногласия между заказчиком и поставщиком

·         Превышения сроков

·         Работа, сделанная впустую.

·         Превышение бюджетов и финансовые потери

Неправильная оценка проекта

О неправильной оценке проекта, как важном источнике проблем проекта (причем таких, с которыми никакими средствами и подходами к управлению проектами не справиться!), почему-то очень мало вспоминают. Наверное, просто неприятно вспоминать. Основные причины неправильной оценки проекта:

·         Отсутствие опыта или методики оценки проекта

·         Непредвиденные проблемы в используемых средствах и компонентах

·         Непонимание ключевых технических проблем проекта

Контрактная сторона вопроса

Естественно, все вышеописанные проблемы в первую очередь упираются в деньги. А раз в деньги, то, значит, и в контракты, по которым эти деньги выплачиваются (или, не приведи господь, не выплачиваются). Значит, важно составить контракт так, чтобы обе стороны выигрывали. При этом, на наш взгляд, вопрос упирается в единицу измерения контракта.

Наиболее популярные единицы измерения – время и проект.

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

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

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

·         непрерывно зависит от сложности проекта и позволяет изменять оценку размера проекта с изменением требований;

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

·         давала бы независимые оценки времени выполнения проекта и его трудоемкости;

·         позволяет распределить риски по-честному.

Модель СОСОМО

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

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

Рис. 1 — Основные модели оценки трудозатрат на разработку ПО

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

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

Зависимость затрат труда в человеко-месяцах (Eff) от численного, выраженного в тысячах исходных команд (KLOC) размера программного изделия, и скорректированная рядом поправочных коэффициентов, представляется следующим образом:

,

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

Коэффициенты  — отражают изменение трудоемкости непосредственной разработки строки текста программы за весь цикл создания программного продукта при воздействии ij-фактора.

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

Модель СОСОМО II

Самым популярным методом является метод СОСОМО II (Constructive Cost Model II, СОСОМО II), использующий большое количество данных из реализованных ранее проектов.

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

На самых ранних этапах, когда известны только общие требования, а проектирование еще не начиналось, используется модель состава приложения (Application Composition Model). В ее рамках трудоемкость проекта оценивается в человеко-месяцах по формуле

где  представляет собой оценку размера в терминах экранов, форм, отчетов, компонентов и модулей будущей системы (каждый такой элемент оценивается с коэффициентом от 1 до 10 в зависимости от своей сложности); коэффициент А учитывает возможное переиспользование части компонентов и производительность разработки, зависящую от опытности команды и используемых инструментов:

.

На следующих этапах, когда требования в основном известны и начинается разработка архитектуры ПО, используется модель этапа предварительного проектирования (Early Design Model) и следующие формулы:

·         для трудоемкости (в человеко-месяцах):

где коэффициент А считается равным 2,45; Size — оценка размера ПО, выраженная в тысячах строк кода; С — произведение семи коэффициентов затрат, каждый из которых лежит в интервале от 1 до 6; В — фактор процесса разработки, который вычисляется по формуле

где коэффициенты  означают предсказуемость проекта для данной организации и принимают значения от 0 до 5;

• для времени (в месяцах):

 (2)

где коэффициент  считается равным 3,67; Eff — оценка трудоемкости без учета плотности графика;  — требуемое сжатие времени выполнения проекта;

• для стоимости проекта:

,

где  — среднемесячная заработная плата программиста.

После того как разработана архитектура ПО, оценки должны выполняться с использованием постархитектурной модели (Post-Architecture Model). Формулы для оценки времени остаются без изменения, а формула для трудоемкости претерпивает небольшие изменения (количество коэффициентов затрат увеличится с 7 до 17).

Методика Agile СОСОМО II

Приводится краткая характеристика одной из последних разработок в данной области — методики Agile СОСОМО II. Многие, кто впервые сталкивался с ней, предполагали, что это специально разработанная методика СОСОМО, учитывающая специфику Agile-проектов (о проектах этого типа в данной статье речь не идет). Суть методики проста и заключается в следующем:

•            задается трудоемкость предыдущего завершенного проекта в какой-либо метрике либо просто как конечная стоимость проекта;

•            задается характеристика СОСОМО предыдущего завершенного проекта;

•            предполагаются характеристики СОСОМО нового проекта;

•            вычисляются трудоемкость и стоимость нового проекта как отклонения от значений предыдущего.

Эта методика удивительна по простоте своего применения, многие эксперты сходятся во мнении, что она адекватно работает для небольших и Agile-проектов, коих в настоящее время много и которые часто не подвергаются никаким оценкам именно из-за своих небольших размеров.

Модификация методик СОСОМО II и Agile СОСОМО II

Следует отметить, что в рассмотренных моделях существенным является параметр Size, приблизительную оценку которого необходимо получить уже на этапе раннего проектирования и позднее уточнять ее. Значение этого параметра в таких моделях измеряется в тысячах строках кода (KLOC). Однако эффективней оценку проводить в функциональных точках (FP), а потом с помощью имеющихся таблиц соответствия переводить FP в KLOC.

Для небольших и средних проектов проведение подобной оценки размера Size может стать невыгодным вследствие существенных временных и денежных затрат. Для их сокращения имеет смысл проводить оценку не с «нуля», а основываясь на данных об уже реализованных предыдущих системах.

Нетрудно заметить, что из формулы (2) для уже завершенного проекта можно получить оценку трудоемкости Effx

.

Затем подставляем полученную Eff в формулу (1) и выражаем из нее Size:

.

Благодаря этой формуле мы можем получить оценку 81гех выполненного проекта в единицах измерения, используемых в модели СОСОМОII. Для оценки параметра  предлагается использовать коэффициент К изменения размеров проекта:

,

где  и        — экспертная оценка размеров проекта по 10-балльной шкале. Важным является проведение оценки  и  одним и тем же экспертом для обеспечения сопоставимости значений. В случае, если известны компонентные составы проектов 1 и 2, логичным является экспертное оценивание каждой компоненты и выведение средней оценки по проекту.

Таким образом, коэффициент К показывает, во сколько раз разрабатываемый проект больше или меньше уже реализованного, причем вне зависимости от метрики размера проекта. Поэтому мы можем использовать этот коэффициент в следующей формуле, полученной из формул (1) и (3):

.

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

.

Заключение

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

Задача выбора адекватной модели оценки затрат на менее сложные и объемные программные системы получила решение в виде выбора методики Agile СОСОМО, основанной на методике СОСОМО II, с внесением некоторых изменений в алгоритм. Данный выбор был обусловлен во многом тем, что методика Agile СОСОМО основывается на данных о предыдущем законченном проекте, что позволяет достаточно легко получить оценку будущего проекта.

Список литературы

1.      Жоголев Е.А. Лекции по технологии программирования: учеб. пособие / Е.А. Жоголев. - М.: Издательский отдел факультета ВМиК МГУ, 2001. - 151 с.

2.      Михайловский Н.Э. Сравнение методов оценки стоимости проектов по разработке информационных систем / Н.Э. Михайловский // Корпоративные системы. - 2003. - № 6. -С. 35-40.

3.      Липаев В.В. Технико-экономическое обоснование проектов сложных программных средств / В.В. Липаев. - М.: СИНТЕГ, 2004. - 284 с.

4.      Sharman G. Agile COCOMOII [Электронный ресурс] / G. Sharman. - CSE Annual Research Review - 2003. - March 17-21.

Скачано с www.znanio.ru