CC BY
74
Заключение
В работе показано, что метод сингулярно-спектрального анализа может использоваться в обработке электрических сигналов человеческого мозга, в частности он позволяет более качественно очистить ряд от шумовых компонент по сравнению с традиционными методами. Преимущество метода «Гусеница» заключается в том, что он лишен «субъективизма» по сравнению с другими методами. То есть все действия с временными рядами, в частности с электроэнцефалограммами, производятся по базису, который основан на природных особенностях временного ряда.
Дальнейшие исследования будут основаны на применении метода сингулярно-спектрального анализа в выявлении клинически значимой информации в электроэнцефалограммах.
Список литературы:
1. Голяндина Н.Э. Метод «Гусеница»-SSA: анализ временных рядов: учеб. пособие. - СПб., 2004. - 76 с.
2. Рангайян Р.М. Анализ биомедицинских сигналов. Практический подход / Р.М. Рангайян. - М.: ФИЗМАТЛИТ, 2007. - 440 с.
3. Зенков Л.Р. Клиническая электроэнцефалография / Л.Р. Зенков. - М.: Медпресс-форм, 2004. - 368 с.
ОЦЕНКА РАЗМЕРА СОЗДАВАЕМОГО ПРОГРАММНОГО СРЕДСТВА С ИСПОЛЬЗОВАНИЕМ ФУНКЦИОНАЛЬНЫХ ТОЧЕК
© Тютюнников Н.Н.*
Центральный научно-исследовательский институт экономики, информатики и систем управления, г. Москва
В статье рассмотрены вопросы оценки затрат на выполнение программных проектов с использованием модели COCOMO II. Для ее применения на ранних стадиях проектирования использован метод не-приведенных функциональных точек для получения оценки размера исходного кода создаваемого программного средства.
Ключевые слова программное средство, модель COCOMO II, оценка затрат, размер исходного кода, метод функциональных точек.
Для бюджетного и календарного планирования выполнения программных проектов актуальным является получение оценок затрат на создание тре-
* Ведущий научный сотрудник Центра информационных ресурсов, кандидат технических наук, старший научный сотрудник.
буемых программных средств. Для решения данной задачи используются различные методы, одним из которых является модель COCOMO II [1]. Она позволяет оценить трудозатраты и время на создание программного средства, как на ранней стадии его проектирования, так и на стадии его разработки.
Проведение расчетов с использованием модели COCOMO требует величины оценки прогнозируемого размера исходного кода, который будет достигнут по окончании создания программного средства. На стадии разработки размер программного средства можно с достаточно высокой точностью оценить по результатам его проектирования путем подсчета и аппроксимации размеров исходного кода моделей, макетов и прототипов программного средства. Однако на ранней стадии проектирования при отсутствии предыдущих версий программного средства или программного задела в автоматизируемой предметной области получить такую оценку достаточно сложно.
На помощь приходят методы, основанные на анализе требований технического задания и принимаемых проектных решениях. Одними из таких методов являются методы функциональных точек. Проведение расчетов с использованием функциональных точек и их применение в качестве единиц измерения основывается на том, что размер компонентов программного обеспечения можно оценивать в терминах количества и сложности функций, реализованных в данном программном коде [2].
Различные методы функциональных точек установлены международными стандартами. Стандарт ISO/IEC TR 14143-5:2004 [3] описывает изменение функционального размера программного обеспечения путем определения функциональных доменов (областей). Другой стандарт ISO/IEC 20926:2009 [4] описывает метод измерения функционального размера IFPUG 2009 при разработке программного обеспечения и систем. Третий стандарт ISO/IEC 20968:2002 [5] устанавливает порядок подсчета функциональных точек методом Mk II при разработке программного обеспечения.
В [6] отмечено, что имея систему измерений функциональности компонентов, можно рассчитывать и сравнивать месячную индивидуальную производительность определенного специалиста или целой рабочей группы путем деления функциональности созданного программного компонента на количество месяцев, потраченное на его разработку. Однако при коллективном производстве сложных программных продуктов индивидуальные характеристики специалистов нивелируются, многие из них не участвуют в непосредственном программировании (аналитики-спецификаторы, тести-ровщики, документаторы), в результате чего расчет функциональности и ее применение в экономике производства сложных программных продуктов теряет смысл. В таких проектах целесообразнее пользовать для учета размера компонентов и комплексов программ традиционной величиной числа строк исходного кода (SLoC, Source Lines of Code).
Однако в случае отсутствия статистических данных по разработке программных проектов определенной тематики для получения размера исход-
ного кода можно воспользоваться одним из методов подсчета функциональных точек.
Достоинство использования этого подхода состоит в том, что сведения о функциях разрабатываемого программного продукта обычно известны на ранних стадиях жизненного цикла программного проекта. Подход позволяет с высокой степенью достоверности оценить размер исходного кода программ при отсутствии их прототипа макета или модели.
В модели COCOMO II оценка размера исходного кода программы осуществляется путем подсчета неприведенных функциональных точек (UFP, Unadjusted Function Points). Подход оценивания затрат с использованием UFP основан на объеме функционала в программном проекте и ряде отдельных факторов проекта (метод измерения функционального размера IFPUG). Применение функциональных точек для использования в модели COCOMO II состоит в следующем.
Измерение функциональных точек программного проекта для количественной оценки функциональности обработки информации связано с основными внешними данными, управлением вводом-выводом или типами файлов. В качестве исходных данных для проведения расчетов используются 5 типов пользовательских функций (User Function Types), которые считаются в функциональных точках, как представлено в табл. 1. (Примечание: авторы модели COCOMO II при проведении подсчетов, фактически, не делают разницы между пользовательской функцией и функциональной точкой).
Таблица 1
Типы пользовательских функций
Функциональные точки (FP) Описание пользовательских функций
Внешние входы (External Input, EI) Считается каждое уникальное исходного данное или тип пользовательского управляющего воздействия, которые (1) вводятся через внешний интерфейс программного обеспечения измеряемой системы и (2) добавляют или изменяют данные во внутреннем логическом файле.
Внешние выходы (External Output, EO) Считается каждое уникальное выходного данное или тип выходного управляющего воздействия, которые выводятся на внешний интерфейс программного обеспечения измеряемой системы
Внутренние логические файлы (Internal Logical File, ILF) Внутренним логическим файлом считается каждая крупная группа данных пользователя или управляющей информации в программном обеспечении системы. Включаются все логические файлы (например, каждая логическая группа данных), который создается, используется или ведется программным обеспечением системы.
Внешние интерфейсные файлы (External Interface File, EIF) Внешними интерфейсными файлами внутри каждой системы считаются файлы, переданные или совместно используемые программным обеспечением системы.
Внешние запросы (External Inquiry (Queries), EQ) Внешними запросами считаются все уникальные комбинации ввода-вывода, при которых ввод вызывает или порождает немедленный вывод.
Каждая функция описанного типа затем классифицируется по уровню сложности. Для каждого уровня сложности установлены соответствующие весовые коэффициенты, которые применяются для определения количества неприведенных функциональных точек.
В модели COCOMO II процедура определения количества неприведенных функциональных точек состоит из следующих шагов, которые обычно проводятся на этапе раннего проектирования или после архитектурного моделирования:
1. Определение числа функций каждого из пяти типов (NF). Число функций должно быть подсчитано ведущим техническим специалистом на основе информации, содержащейся в требованиях к программному обеспечению и в технической документации. Подсчет осуществляется методом IFPUG.
2. Определение уровней сложности (R). Для каждого подсчитанного числа функций оценивается соответствующий уровень сложности (по следующей шкале: низкий (L, low), средний (A, average), высокий (H, high)) в зависимости от количества содержащихся элементов данных и числа соответствующих файлов, как представлено в табл. 2.
Таблица 2
Порядок подсчета весового коэффициента функциональной точки
Для внутренних логических файлов (ILF) и внешних интерфейсных файлов (EIF)
Число элементов записи Число элементов данных
1-19 20-50 51+
1 low low average
2-5 low average high
6+ average high high
Для внешних выходов (EO) и внешних запросов (EQ)
Число типов файлов Число элементов данных
1-5 6-19 20+
0 или 1 low low average
2—3 low average high
4+ average high high
Для внешних входов (EI)
Число типов файлов Количество элементов данных
1-4 5-15 16+
0 или 1 low low average
2-3 low average high
4+ average high high
3. Учет весового коэффициента (СРК). Весовые коэффициенты для числа функций разных типов для каждого уровня сложности определяются в соответствии с табл. 3 (весовые коэффициенты отражают относительные усилия, необходимые для реализации соответствующих функций).
Таблица 3
Значения весовых коэффициентов для неприведенных функциональных точек
Функциональная точка low average high
Внешние входы (Е1) 3 4 6
Внешние выходы (ЕО) 4 5 7
Внутренние логические файлы (1ЬБ) 7 10 15
Внешние интерфейсные файлы (Е№) 5 7 10
Внешние запросы (Ер) 3 4 6
4. Подсчет неприведенных функциональных точек (UPF). Количество неприведенных функциональных точек подсчитывается путем сложения количества всех функций с учетом весовых коэффициентов по следующей формуле:
UFP = YZ Nf ■ CR (1)
F R
где F - тип пользовательской функции (функциональной точки), принимающий значения EI, EO, ILF, EIF, EQ;
R - определенный уровень сложности, принимающий значения L, A, H.
5. Преобразование неприведенных функциональных точек в строки исходного кода (SLoC). Количество неприведенных функциональных точек преобразуется в число строк исходного кода в реализации конкретного языка (Ada, C, C++, Pascal и др.) с использованием перекодировочной таблицы по формуле:
SLoC = UFP ■ L (2)
где L - коэффициент преобразования для заданного языка программирования.
Коэффициенты преобразования для некоторых языков программирования представлены в табл. 4.
Таблица 4
Коэффициенты преобразования количества неприведенных функциональных точек в число строк исходного кода для некоторых языков программирования
Язык программирования SLoC / UFP
C++ 55
Java 53
Применим описанную процедуру определения количества неприведенных функциональных точек для каждого комплекса и компонента макета программных средств терминологического фонда, объемы которых измерены в [7]. Подсчет функциональных точек осуществлялся только для про-
граммных модулей, написанных на языке С++(0). В данной статье для удобства представления результаты подсчета сведены для диалоговых и консольных средств. В табл. 5 подсчитанному количеству функциональных точек назначены весовые коэффициенты, а также осуществлен подсчет не-приведенных функциональных точек и их перевод в строки исходного кода. Для сравнения в таблице также приведены размеры (в тысячах строк исходного кода, KSLoC) разработанного макета соответствующих средств терминологического фонда.
Таблица 5
Назначение весовых коэффициентов, подсчет неприведенных функциональных точек и перевод их в количество строк исходного кода
Тип FP Шкала Вес Диалоговые средства Консольные средства Всего БР Всего ИБР
EI Ь 3 12 32 44 132
А 4 31 17 48 192
Н 6 0 5 5 30
EO Ь 4 10 22 32 128
А 5 1 2 3 15
Н 7 4 4 8 56
1ЬБ Ь 7 1 9 10 70
А 10 2 8 10 100
Н 15 12 36 48 720
EIF Ь 5 4 23 27 135
А 7 6 4 10 70
Н 10 0 0 0 0
Ед Ь 3 0 13 13 39
А 4 4 4 8 32
Н 6 7 34 41 246
ИБР 560 1405 1965
ЕЗЬоС (С++) 30,8 77,2 108,0
ЕЗЬоС (Макет) 24,6 8,1 32,7
Расхожение 1,25 9,53 3,30
Как видно из таблицы, превышение количества строк исходного кода, полученного путем подсчета неприведенных функциональных точек, по сравнению с величинами, подсчитанными по результатам макетирования, для диалоговых средств составляет 30,8 против 24,6 KSLoC, а для консольных средств - 77,2 против 8,1 KSLoC.
Таким образом, по результатам расчетов можно сделать вывод о том, что прогнозируемый размер исходного кода, полученный с использованием данного подхода, практически совпал с размером исходного кода, полученного в результате макетирования, только для диалоговых программ (разница составила 25 %). Однако, рассчитанные размеры для консольных программ расходятся с реальными примерно в 10 раз.
Список литературы:
1. Software Cost Estimation with Cocomo II / by Barry W. Boehm ... [et al.]. -N.J.: Prentice-Hall, 2000. - 544 p.
2. Липаев В.В. Оценивание количества информации в сложных заказных программных продуктах // Программная инженерия. - 2012. - № 1. - С. 2-9.
3. ISO/IEC TR 14143-5:2004. Information technology. Software measurement. Functional size measurement. Part 5: Determination of functional domains for use with functional size measurement. (Информационные технологии. Оценка программного обеспечения. Измерение функционального размера. Ч. 5. Определение функциональных доменов, используемых для измерения функционального размера). - Switzerland: ISO/IEC, 2004. - 34 p.
4. ISO/IEC 20926:2009. Software and systems engineering. Software measurement. IFPUG functional size measurement method 2009. (Разработка программного обеспечения и систем. Измерения в программном обеспечении. Метод измерения функционального размера IFPUG 2009). - Switzerland: ISO/IEC, 2009. - 32 p.
5. ISO/IEC 20968:2002. Software engineering. Mk II Function Point Analysis. Counting Practices Manual. (Разработка программного обеспечения. Анализ функциональных точек Mk II. Руководство по практике подсчета). -Switzerland: ISO/IEC, 2002. - 98 p.
6. Липаев В.В. Экономика производства программных продуктов. - М.: СИНТЕГ, 2011. - 352 с.
7. Тютюнников Н.Н. Оценка затрат на создание программных средств терминологического фонда по типовым нормам времени на программирование задач для ЭВМ // Экономика и управление в XXI веке: тенденции развития. - Новосибирск, 2013. - № 8. - С. 24-29.
АНАЛИЗ МЕТОДОВ ПРЕДВАРИТЕЛЬНОЙ ОБРАБОТКИ ИЗОБРАЖЕНИЯ В РАМКАХ ЗАДАЧИ РАСПОЗНАВАНИЯ ГРЯЗНЫХ И/ИЛИ ЗАШУМЛЕННЫХ НОМЕРНЫХ ЗНАКОВ АВТОТРАНСПОРТА
© Убоженко Н.В.*
Московский государственный университет леса, г. Мытищи
В данной статье проводится обзор существующих методов предварительной обработки изображения применительно к задаче распознавания символов грязных и зашумленных номерных знаков автотранспорта, производится анализ различных операций улучшения качества
* Магистрант кафедры Вычислительной техники.
