CC BY
23
УДК: 338.2:004.413 ГРНТИ: 20.15.13
ГРАНИЦЫ ПРИМЕНИМОСТИ МЕТОДА OBJECT POINTS ДЛЯ ОПРЕДЕЛЕНИЯ ТРУДОЁМКОСТИ ПРОГРАММНОГО ПРОЕКТА
А. С. Халуимов, Н. В. Соколов
Сибирский федеральный университет
Россия, 660074 г. Красноярск, ул. Академика Киренского 26/1 Н Халуимов Александр Сергеевич - mail4wowac@yandex.ru
В статье исследуется метод расчёта трудоёмкости программных проектов под названием Object points, представляющий собой разновидность метода Function Points, но применяющийся для ПО, написанным с использованием парадигмы объектно-ориентированного программирования (ООП) или полностью основанном на ней. Так же, как и для программного обеспечения в принципе, проблема оценки стоимости объектно-ориентированных программных продуктов остаётся актуальной и при том достаточно сложной задачей, в связи с чем специалисты должны иметь в своём распоряжении наиболее совершенные методики. Рассматриваются особенности объектно-ориентированных (ОО) программных продуктов, недостатки применения к ним стандартных метрик, особенности метода Object points в сравнении с ними, а также подробное описание его использования.
Ключевые слова: программное обеспечение, ООП, оценки стоимости, оценочные метрики, Object points.
APPLICABILITY RANGE OF OBJECT POINTS METHOD FOR ESTIMATING SOFTWARE COST A. S. Khaluimov, N. V. Sokolov
Siberian Federal University
26/1 Akademik Kirensky St., 660074 Krasnoyarsk, Russia El Khaluimov Alexander - mail4wowac@yandex.ru
The article reviews the method of estimating the complexity of software projects called Object Points, which is a kind of the Function Points method, but applied to software written with using of the object-oriented programming (OOP) paradigm or completely based on it. Just as for any software, the problem of estimating the cost of object-oriented software products remains relevant and rather complex task, so specialists must have the most advanced techniques at their disposal. This research considers the features of object-oriented (OO) software products, the disadvantages of applying standard metrics to them, special qualities of the Object Points method in comparison with them, as well as its detailed description.
Keywords: software, OOP, cost estimates, estimation metrics, Object points.
Несмотря на эффективность традиционно применяемых оценочных метрик, вроде метода функциональных точек [1] (FP), практика показывает, что со временем анализ, выполняемый при помощи них, становится всё менее точен. Прежде всего, это связано с процессом внедрения Объектно-Ориентированных (ОО) технологий, который приобрёл повсеместный масштаб - достаточно сказать, что большинство ныне применяемых языков программирования (ЯП), вроде C++/C#, Java и других, предполагают реализацию именно ОО парадигмы. Это очевидным образом изменяет результаты анализа стоимости программных продуктов (ПП), поскольку ООП предполагает, как минимум, уменьшение кол-ва кода в приложении, за счёт построения архитектуры таким образом, чтобы при необходимости внесения изменений это было возможно сделать с минимальными усилиями. Кроме того, пропадает необходимость писать каждое действие в программе наиболее подробно, поскольку современные методы программирования предоставляют готовые решения, выполняющие эти команды при помощи, например, одной строки кода.
Для того, чтобы учесть данные особенности ОО программных продуктов в оценочных расчётах, необходимо рассмотреть не только функциональную сторону такого ПО, но и информацию об объектах, их отношениях в данном ПО [2]. Если главными расчётными факторами в традиционных метриках являются входные/выходные данные приложения, а также процедуры, связанные с ними, то Object Points
исследует прежде всего объекты и их характеристики.
Для проведения такого исследования в методе Object Points существует три расчётных измерения [3] - функциональность ПО (это - единственное измерение в традиционных метриках), объекты и их отношения, а также повторные использования объектов при помощи концепции наследования.
Два последних расчетных измерения являют собой ключевое отличие от традиционных метрик, позволяющее нам определить параметры, которые будут учитываться при расчете затрат на разработку программного проекта. Пре-диктивные точки объектов [4] (Predictive Object Points) - основной предмет рассматриваемого нами метода. Параметры, включенные в Predictive Object Points - это метрики, отражающие важнейшие аспекты Объектно-ориентированного проектирования, такие как разработанные для приложения классы, поведение этих классов и последствия их работы для разрабатываемой системы в целом.
Метрики, включенные в Predictive Object Points:
- количество классов высшего уровня (TLC);
- среднее количество взвешенных методов на класс (WMC);
- средняя глубина дерева наследования (DIT);
- среднее количество прямых наследников базового класса (NOC).
Количество классов высшего уровня (TLC) - учитывает количество классов на диаграмме, от которых наследуют-
Economics I Juvenis scientia 2018 № S
9
ся остальные классы, находящиеся на более низких уровнях. Иными словами, эта метрика отвечает за количество корневых элементов на диаграмме классов. Этот параметр позволяет анализировать систему с высшего уровня, чтобы создать базу для исследования вглубь дерева наследования [5].
Среднее количество взвешенных методов на класс (WMC) - среднее количество методов, оцененных по сложности в зависимости от типа метода, последствий его работы и количества «услуг», предоставляемых методом для проектируемой системы. Этот параметр принято считать ключевым в Predictive Object Points, поскольку он отвечает одновременно и за функциональность, и за связи между объектами в системе [6].
Средняя глубина дерева наследования (DIT) - оценка глубины дерева наследования, то есть, расстояния от корневого класса (класса высшего уровня) до последнего наследника [7].
Среднее количество прямых наследников базового класса (NOC) - оценка количества наследников у класса, но уже без прохода в глубину, то есть в расчет входят только прямые потомки, унаследованные строго от базового класса [8].
Далее, согласно приведённым выше определениям, выполняется сбор нужной информации о ПО. Прежде всего необходимо произвести определение «веса» каждого из используемых методов. Для этого, все методы условно подразделяются (согласно классификации Гради Буча [9]) на пять типов:
1. конструкторы - методы, инициализирующие объекты;
2. деструкторы - методы, уничтожающие объекты;
3. модификаторы - методы, изменяющие состояние объектов;
4. селекторы - методы, предоставляющие доступ к данным объектов, но не изменяющие их [10];
5. итераторы - методы, предоставляющие доступ к объектам в коллекции и имеющие возможность навигации по ним [11].
Помимо этого, для каждого метода необходимо собрать информацию об их «важности» в системе (то есть о количестве запросов, которые метод должен обработать) и количестве параметров. Таким образом, при помощи этих данных, мы может определить сложность для каждого метода, согласно ниже приведённой таблице 1 [12]:
Таблица 1
Расчёт сложности методов
Кол-во обрабатываемых запросов Количество параметров
0 - 1 2 - 6 7 или более
0 - 1 Низкая Низкая Средняя
2 - 3 Средняя Средняя Средняя
4 или более Средняя Высокая Высокая
Теперь, с помощью таблицы 1 и заранее известной классификации методов, не составит труда определить веса для каждого из них, согласно таблице 2.
С этими данными можно приступать к конечным расчётам. Используя информацию из таблицы 2 можно рассчитать Среднее количество взвешенных методов на класс (WMC), и вместе с количеством Классов высшего уровня (TLC), средним значением количества прямых наследников базового класса (NOC) и средней глубиной дерева наследования (DIT) соединить эти величины в одном уравнении:
OPiWMCJLC, NOC,DIT) = WMC X f(TLC,NOC'DIT) x f2(NOC,DIT)
7,8
где:
f - размер всей системы
f2 - достигнутый при помощи повторного использования эффект.
Таблица 2
Расчёт весов методов
Тип метода Сложность метода Вес
Конструкторы/деструкторы Низкая 1
Средняя 4
Высокая 7
Низкая 1
Селекторы Средняя 5
Высокая 10
Низкая 12
Модификаторы Средняя 16
Высокая 20
Низкая 3
Итераторы Средняя 9
Высокая 15
Таким образом, мы можем сделать вывод, что вышеописанным методом можно довольно точно подойти к расчету затрат на разработку программного обеспечения, разрабатываемого с точки зрения парадигмы объектно-ориентированного программирования [13]. Это является несомненным плюсом для больших проектов, нацеленных на долговременное использование, поскольку при таком подходе возможно еще и обеспечение долгосрочной поддержки выпускаемого продукта. Однако стоит заметить, что в нынешней ситуации, когда даже в разработке больших систем предпочитают использовать функциональные языки программирования в связке с объектно-ориентированными [14], такой подход к расчету затрат не может в полной мере описать разрабатываемый проект. Это можно заметить из вышеописанной классификации методов Гради Буча. По этой причине следует проводить расчеты затрат, опираясь и на другие разработанные методики.
ЛИТЕРАТУРА
1. Никулина Д.М., Яковлева В.А., Михалев А.С. Применение информационных систем в управлении персоналом // Новая наука: теоретический и практический взгляд. Стерлитамак: АМИ, 2016. №12(3) С.133-136.
2. Попова Е.И., Михалев А.С. Системный анализ как этап инженерной деятельности современного программиста // Интеллектуальный и научный потенциал XXI века: сборник статей Международной научно - практической конференции (20 декабря 2016 г., г. Казань). В 6 ч. Ч.4 Уфа: Аэтерна, 2016. С. 179-182.
3. Максимов Д.Б., Трацевская А.П., Михалев А.С. Современный инструментарий программной инженерии // Новая наука: опыт, традиции, инновации. Стерлитамак: АМИ, 2016. №12(3). С.149-151.
4. Евдокимов И.В., Михалев А.С., Чучунева А.С., Павлушкина Л.В. Применение систем отслеживания ошибок в дистанционном обучении по ИТ-направлениям подготовки // Дистанционное и виртуальное обучение. 2018. №1. С. 132-137.
5. Михалев А.С., Иванова Я.С., Конюхова А.Н. Актуальные проблемы документирования исходных кодов разрабатываемого ИТ продукта и пути их решения // Экономика и бизнес: теория и практика. 2017. № 11. С. 137-139
6. Кокташев В.В., Макеев В.В., Михалев А.С. Применение системы управления инцидентами для разработки программного обеспечения в образовании // Современные информационные технологии. 2017. № 26(26). С. 139-143.
7. Евдокимов И.В., Михалев А.С., Ковалев В.В. ТРИЗ-инструментарий программной инженерии// Теоретические, методологические и прикладные вопросы науки и образования: материалы международной научно-практической конференции. Самара, 2018. C. 8-16
8. Евдокимов И.В., Михалев А.С., Тимофеев Н.А., Батурин Ю.А. Прогнозирование эффективности использования виртуальных технологий в инженерной среде при обучении студентов // Проблемы социально-экономического развития Сибири. 2017. № 3(29). С. 129-135.
9. Буч Г. и др. Объектно-ориентированный анализ и проектирование с примерами приложений на С++. СПб : Невский диалект, 1998. С. 560.
10. Евдокимов И.В., Михалев А.С., Кицкалов А.Е., Яшевский Д.Е. Особенности применения метода Use-Case Points в экономике программной инженерии с открытым исходным кодом // Проблемы социально-экономического развития Сибири. 2017. № 4(30). С.36-42.
11. Евдокимов И.В., Коваленко М.А., Мелех Д.А. Управление разработкой и внедрением учётной информационной системы // Научное обозрение. Экономические науки. 2017. № 4. С. 34-39.
12. Minkiewicz A. Measuring object oriented software with predictive object points //PRICE Systems, LLC. 1997.
13. Евдокимов И.В., Алалван А Р Д , Тимофеев Н.А., Нехоношин С.Р. Интернет вещей в контексте экономики программной инженерии и управления стоимостью проекта // Интернет журнал «НАУКОВЕДЕНИЕ» Том , № (201) http://naukovedenie ru PDF 56 VN 17 pdf.
14. Евдокимов И.В., Ященков К.Г., Телков А.Ю., Татауров В.А. Экспертные методы оценки трудоёмкости разработки программных проектов // Экономика и менеджмент систем управления. 2017. Т. 24. № 2.2. С. 272-276.
Поступила в редакцию 13.05.2018
