CC BY
139
А. И. Терехов, А. А. Терехов // Вестник РФФИ. 2006. № 4. С. 23-37.
3. Каплан, Р. С. Сбалансированная система показателей / Р. С. Каплан, Д. П. Нортон. М. : Олимп-Бизнес, 2004. 320 с.
4. March, G. Hopeful future for a nano-Europe / G. March // Materials Today. 2003. № 7-8. P. 40-45.
5. Кэнтон, Дж. Социальное значение нанотехноло-гии: прогноз на будущее / Дж. Кэнтон // Нанотехноло-гии в ближайшем десятилетии. Прогноз направления исследований / под ред. М. К. Роко, Р. С. Уильямса и П. Аливисатоса. М. : Мир, 2002. C. 239-243.
6. Гудилин, Е. А. Сказка со счастливым концом [Электронный ресурс] / Е. А. Гудилин. Электрон. дан. Режим доступа: http://www.nanometer.ru. Загл. с экрана.
7. Демина, Н. Академическая нанорусистика [Электронный ресурс] / Н. Демина. Электрон. дан. Режим доступа: // http://www.polit.ru/science. Загл. с экрана.
8. Rifkin, D. The end of work: The Decline of Global Labor Force and the Down of the Post-Market
Era / D. Rifkin. New-York: G. P. Putman's Sons, 1996. 350 p.
9. Нанотехнологии восстанавливают нервные клетки [Электронный ресурс]. Электрон. дан. Режим доступа: http://polit.ru/science. Загл. с экрана.
10. Norman, R. S. Sabo-Attwood Targeted Photothermal Lysis of the Pathogenic Bacteria, Pseudomonas aeruginosa, with Gold Nanorods / R. S. Norman [et al.] // Nano Letters. ASAP Article 10.1021/nl0727056 S1530-6984(07)02705-1. 07.12.2007.
11. Наночастицы могут повреждать ДНК [Электронный ресурс]. Электрон. дан. Режим доступа: http://polit.ru/science.27.04.2007. Загл. с экрана.
12. Obe^rster, G. Toxicology of nanoparticles: A historical perspective / G. Obe^rster, V. Stone, K. Donaldson // Nanotoxicology. 2007 (March). Vol. Issue 1. P. 2-25.
13. Проведена оценка опасности наноразмерных аэрочастиц [Электронный ресурс]. Электрон. дан. Режим доступа: http://polit.ru/science. Загл. с экрана.
14. Наночастицы могут негативно влиять на рост растений [Электронный ресурс]. Электрон. дан. Режим доступа: http://polit.ru/science. Загл. с экрана.
G. G. Krushenko, S. N. Reshetnikova, K K Tsau
SOME ECONOMICAL, SOCIAL, EDUCATIONAL AND ECOLOGICAL ASPECTS
OF NANOTECHNOLOGIES USE
Some possible consequences of nanotechnologies use in different fields are described.
УДК 004.412.3
Ю. Ю. Якунин
ОЦЕНКА ТРУДОЕМКОСТИ РАЗРАБОТКИ ПРОГРАММНОЙ СИСТЕМЫ
Описаны методика и математическая модель оценки трудоемкости программного проекта на базе метрик, основанных на функциональных точках.
Организации, занимающиеся разработкой программных систем, особенно для коммерческой реализации, в том или ином виде используют методику оценки программного проекта. Проблема состоит в том, что в России в настоящее время действуют устаревшие модели по оценке, утвержденные Госкомтруда в 1986 г. В этой ситуации фирмы вынуждены использовать методики иностранного происхождения. Особенно остро стоит вопрос в организациях, которые получили или собираются получить сертификат по стандарту ГОСТ Р ИСО 9000-2001.
Использование иностранных методик сопровожда -ется рядом проблем:
1) методики и модели созданы без учета специфики разработки программных систем в Росси;
2) параметры моделей оцениваются по статистическим данным о выполненных проектах в зарубежных странах. Сами статистические данные как правило закрыты, а потому не вызывают доверия;
3) математические модели не представлены в полном объеме, что не позволяет оценить достоверность этих моделей и самостоятельно выполнить оценку их параметров.
Все методики оценки делятся на две группы: микрооценка и макрооценка. Методы микрооценки основаны на точном знании процесса. Такова, например, Oracle AIM и оценки трудоемкости для него. Во всех случаях, когда для построения модели оценки необходимо видение разбивки работ и оценка каждой индивидуальной работы, метод относится к группе микрооценки. Методы макрооценки основаны на функциональных требованиях. Таковы методы функциональных точек (FP) типа СОСОМО.
В статье Н. Михайловского [1] проведен сравнительный анализ методик оценки стоимости проектов по разработке программных систем. Из рассмотренных методик две имеют закрытые модели оценки, а из двух методик с открытыми моделями, у одной не доступны статистические данные, на основе которых вы-
полнялись расчеты оценки параметров модели. Последняя методика (ГРРив БРА) основана на статистических данных зарубежных стран.
Возникает потребность в открытых российских разработках такого рода методик. Открытые модели следующие:
1) производить оценку и настраивать модели на основе собственного опыта организаций;
2) использовать свои обозначения и понятия функциональных блоков, что наиболее актуально в постоянно меняющихся технологиях разработки.
В описываемой модели и методе оценки трудоемкости программной разработки учтены наиболее существенные факторы. С развитием метода будут учитываться и другие факторы, влияющие на стоимость программного проекта.
Концепция метода. Оценка программного проекта является исходными данными и отправной точкой для планирования. Для составления плана проекта необходимо знать три основных показателя: длительность (продолжительность) разработки, требуемые усилия (трудозатраты), количество специалистов (штат разработчиков). Эти показатели позволяют определить стоимость разработки проекта.
Основным показателем, который требуется оценить, является трудоемкость. Остальные показатели можно считать в той или иной степени производными. Для оценки трудоемкости требуется набор статистических данных о предыдущих проектах. Такими данными могут являться: трудоемкость функционального блока, подсистемы и проекта в целом; длительность проекта и каждого этапа в отдельности; количество ошибок на один функциональный блок или строку программного кода; используемые технологии разработки и организации процесса разработки; размер команды разработчиков и их квалификация.
Рассматриваемый в данной статье метод относится к группе макрооценок и основан на использовании подхода функциональных точек. Данный метод предполагает выполнение следующих шагов:
1) на основе предварительного анализа требований должны быть определены основные функциональные подсистемы (блоки) будущего программного продукта;
2) для каждого типа функционального блока определяется количество типов элементов и производится оценка сложности каждого типа элемента относительно друг друга (в том случае, если прежде такая оценка не производилась);
3) для каждого функционального блока определяется количество элементов каждого типа;
4) выполняется вычисление оценки трудозатрат для каждого функционального блока разрабатываемой системы;
5) в результате суммирования данных по всем блокам получаем оценки трудозатрат и стоимости разработки всей системы.
Исходные данные для оценки. В зависимости от подхода в организации к описанию и формализации
требований к программной системе можно выделить несколько типов элементов, из которых эти требования состоят. В любом случае требования к системе делятся на функциональные и нефункциональные. От функциональных требований трудоемкость разработки системы зависит в большей степени, хотя некоторые нефункциональные требования могут очень сильно влиять на стоимость разработки. В предлагаемом методе пока учитываются только функциональные требования. В общем случае для любых подходов функциональные требованиях к системе на самом высоком уровне могут быть описаны как требования к подсистемам. Каждая подсистема может состоять из набора функций (по ГОСТ 34.602-89) или набора вариантов использования (по IEEE 830). И те и другие имеют детальное описание или спецификацию.
Для того, чтобы отвязаться от разных стандартов и подходов к описанию требований введем понятие «функциональный блок». Под функциональным блоком будем понимать набор однотипных функций, направленных на решение одной задачи. Задача может быть нацелена как на результат пользователя, так и на программный результат. Объем функционального блока может быть любым, но предпочтительно, чтобы все функциональные блоки были одного уровня абстракции, хотя это не обязательно. Например, для уровня подсистем можно считать следующие функциональные блоки: «подсистема авторизации», «подсистема формирования отчетов», «подсистема ведения справочных данных» и т. п. Это крупные функциональные блоки, для более точной оценки рекомендуется использовать функциональные блоки, например, уровня вариантов использования.
Так как рассматриваемый метод основан на подходе макрооценки, то исходными данными для него является статистика о предыдущих выполненных проектах. Статистические данные по каждому выполненному проекту должны содержать информацию по всем функциональным блокам следующего содержания:
T-k
j - количество элементов по типам сложности,
где i - номер функционального блока, j - номер типа сложности, k - номер выполненного проекта;
Tk - трудозатраты, использованные на разработку i-го функционального блока в k-м проекте.
Очевидно, что от проекта к проекту объем (или содержание) однотипного функционального блока может различаться. Обычно руководителю проекта известны трудозатраты, использованные на разработку функционального блока в целом (Tk), а не отдельных
его частей. Но для оценки трудоемкости такого же функционального блока в новом (оцениваемом) проекте нужно знать трудозатраты на каждый элемент этого функционального блока в предыдущих проектах. Для решения этой проблемы вводится понятие сложности элементов функциональных блоков и оценка сложности (Si j ). В качестве примера приведем возможные типы элементов функционального блока и оценки их сложности (см. таблицу).
Типы элементов функционального блока
Тип элемента Оценка сложности (%) Описание
Простой объект 3,85 Количество простых и составных полей менее 15
Средний объект 7,69 Количество простых и составных полей более 15, но менее 50
Сложный объект 11,54 Количество простых и составных полей более 50
Простая транзакция 3,85 Выборка данных посредствам SQL-запроса или хранимой процедуры
Средняя транзакция 7,69 Выполнение нескольких SQL-запросов и/или хранимых процедур
Сложная транзакция 19,23 Реализация математического алгоритма
Простая таблица 7,69 Таблица, состоящая из простых полей, для создания которой используется один несложный SQL-запрос
Средняя таблица 15,38 Таблица, состоящая как из простых полей, так и из опциональных и/или списочных. Для создания таблицы используется один или несколько простых SQL-запросов
Сложная таблица 23,08 Таблица, состоящая из простых полей и/или опциональных и списочных полей. Для фильтрации данных используются дополнительные поля на форме. Для загрузки данных используются один или несколько сложных SQL-запросов (хранимые процедуры)
Примечание. Под объектом здесь понимается совокупность простых и составных полей, образующих некоторую сущность, которая представляется в системе как единое целое на отдельной форме, закладке, в разделе и т. п. Над объектом могут совершаться стандартные операции сохранения, изменения и удаления. Под транзакцией понимается набор действий пользователя и/или системы, выполняющихся по событию на форме и приводящих к определенному ощутимому результату. Например, транзакцией можно назвать реализацию некоторого математического алгоритма или выборку данных для отчета. Под таблицей понимается таблица с набором простых и составных полей, позволяющая выполнять стандартные действия над записями (сортировка, фильтрация по столбцам, настройка таблицы).
В приведенном примере оценка сложности выполнена в процентах, общая сумма всех оценок составляет 100 %. Для использования оценки сложности в модели удобно работать с приведенной оценкой. Тогда должно выполняться следующее условие:
^Сту,у = 1, для V/ . (1)
}
Значения оценки сложности элементов функционального блока могут быть получены двумя способами:
1) при наличии достаточного количества статистических данных о выполненных проектах оценку сложности можно будет рассчитать, например, через оценку матожидания;
2) при отсутствии достаточного количества статистических данных оценка может задаваться экспертом, например, менеджером проекта.
Как было отмечено выше, О/ у нам необходима
для получения трудозатрат в разрезе типов элементов, так как обычно известна информация только о стоимости всего функционального блока. Для каждого
исходного проекта рассчитывается Тку - трудозатраты, использованные на разработку элементов у-го типа в к-м проекте для /-го функционального блока.
Примечание. Исходные проекты - это выполненные проекты, чьи статистические данные будут использоваться для оценки стоимости нового проекта.
Эти трудозатраты рассчитываются путем весового распределения трудозатрат всего функционального блока по типам его элементов:
тк = О
т,у = ^
ЕЛ
/,у тк
Оценка функциональных блоков. Очевидно, что для оценки стоимости проекта нужно использовать статистические данные из нескольких проектов. Тогда возникает вопрос, насколько достоверны данные из того или иного проекта и насколько корректно использовать эти данные с равной степенью доверия. Конечно, можно было исключить проекты с меньшей степенью достоверности. Но тогда, как оценить эту степень достоверности? Кроме того, любые статистические данные, на сколько они были бы недостоверны, несут в себе ценную информацию. Например, нужно оценить редкий функциональный блок, а в тех проектах, которым мы доверяем, такого рода блок не разрабатывался, вот тогда мы вынуждены взять информацию из менее достоверных проектов.
Чтобы можно было учитывать в методе степень доверия к исходным данным выполненных проектов, введем понятие значимости (веса) каждого проекта
(рк). Модель оценки значимости проектов в данной статье не рассматривается. Скажем только, что этот вес может задаваться экспертом (менеджером проекта). Понятно, что для рк должно выполняться следующее условие:
ок
ХРк = 1, для V/ .
к
(3)
к
• Е
В некоторых выполненных проектах могут отсутствовать данные по количеству разработанных элементов у-го типа, т. е. Ек,у = 0 . Тогда, для того чтобы
не потерять вес на этих типах элементов, нужно его перераспределить по остальным проектам пропорционально их весам: для Vк , если Еку = 0, то
пК
РК для "К . (4)
1 -ЬК
Теперь рассчитаем трудозатраты на каждый элемент каждого типа для нового проекта:
- К
Ти = X РК , где ЕК,- Ф 0 для V/, -. (5)
Для оценки трудоемкости аналогичного функционального блока в новом проекте нужно знать количество элементов --го типа /-го функционального блока
(Ео ц). Эти данные могут быть получены в результате
выполнения детального анализа требования. После этого можно рассчитать значение трудозатрат, необходимых для разработки /-го функционального блока:
Т°Ц =Х Т0- • Еоц. (6)
]
Трудозатраты всего проекта могут быть получены путем суммирования трудозатрат всех функциональных блоков.
Пример оценки системы. В данном примере будут оценены трудозатраты на разработку подсистемы ведения справочных данных (/ = 1):
1. Определяем типы сложности элементов или сами элементы подсистемы ведения справочных данных, если они не были определены ранее и не хранятся в базе данных о выполненных проектах. Для подсистемы ведения справочных данных выделим три типа элементов:
- = 1: простые справочники - все поля имеют простые типы данных (целое, строка и т. п.);
- = 2: составные справочники - справочник состоит из любого количества простых полей и любого количества полей, которые принимают значения других справочников;
- = 3: сложные справочники - для любой записи этого справочника существует определенный набор записей из другого справочника.
2. Оцениваем сложность каждого элемента подсистемы (стг- - ):
Ст11 = 0,1; Ст1 2 = 0,3; Ст1 \ = 0,6 .
3. Получаем данные из других проектов о количестве элементов (ЕК-) в оцениваемой подсистеме и
трудозатратах (Тк), использованных на разработку этих подсистем. Предположим, что у нас есть данные по двум проектам (К = 2 ):
Е'111 = 5; е12 = 5 ; Е^3 = 2 ; = 150 [чел.-ч];
Е2! = 20 ; Е22 = 10; Е23 = 10 ; Т12 = 350 [ чел.-ч].
4. Рассчитываем трудозатраты на разработку каждого типа элементов для обоих проектов на основе
количества этих элементов (ЕК-) и оценки сложности
(стг- - ) в соответствии с формулой (2):
Т^ = 23,44 ; Т112 = 70,31; Т^ = 56,25 ;
Т1221 = 63,64 ; Т1222 = 95,46 ; Т^ = 191,00.
5. Определим важность каждого проекта путем распределения весов (рК):
Р1 = 0,3; р2 = 0,7 .
6. Рассчитываем среднюю стоимость одного элемента каждого типа в соответствии с формулой (5):
Т^ = 3,62 ; Т°2 = 10,90 ; Т°3 = 21,80.
7. Выполним оценку количества элементов каждого типа (Е,оц) в создаваемой подсистеме. Предположу
жим, в создаваемой подсистеме будет следующее количество элементов:
Е°ц = 15 ; Е2 = 10 ; Е°ц = 5 .
8. Рассчитаем оценку трудозатрат подсистемы в соответствии с формулой (7):
Т1оц = 272,3.
Рассмотренная методика оценки программного проекта разрабатывалась с учетом требований малых и средних организаций, которые развиваются в жесткой конкурентной борьбе и чья основная деятельности связана с производством программных продуктов. Развитие малых организаций, разрабатывающих программные системы в России, осложняется еще и тем, что большая часть программного обеспечения является пиратской. Хотя последние тенденции в политике нашего государства и навязывают приобретение лицензионного программного обеспечения, но сложившийся менталитет руководителей еще не позволяет делать серьезные вложения в лицензионные системы или их разработку. Такая ситуация ставит под вопрос рентабельность фирм-разработчиков, вынуждая их уходить в оффшор.
В этой ситуации разработчикам тяжело формализовать и автоматизировать свои собственные рабочие процессы, тем более путем приобретения технологий и программного обеспечения сторонних фирм. Как правило, такие приобретения требуют серьезных финансовых вложений. Предложенная методика формализует один из небольших, но важных этапов технологии разработки и не требует финансовых вложений в ее автоматизацию.
При разработке методики оценки учитывались такие требования, как легкость использования оценки; возможность использования статистики предыдущих проектов, которая не велась в соответствии со специальными требованиями для оценки; возможность учета нефункциональных требований; гибкость методики, т. е. она не должна быть привязана к каким-то определенным единицам (функциональным блокам), и др.
Разработанная методика в представленном виде удовлетворяет большей части предъявляемых требований и кроме всего прочего позволяет выполнять оценку на разных этапах разработки программного обеспечения. Например, в самом начале жизненного
цикла программной системы требуется грубая (предварительная) оценка, которая может иметь точность до ±200 % [2], а в конце этапа анализа требований оценка требуется более точная, поскольку на ее основе рассчитывается бюджет проекта и сумма контракта. В предложенной методике уровень точности оценки зависит от детализации функциональных блоков, которые могут иметь статус от элементарных блоков системы до компонент и подсистем, что существенно упрощает использование методики.
В развитии предложенной методики планируются следующие исследования:
1) получение параметров модели (оценки сложности (стг- - ) и значимости (весов) проектов (рК)), на
основе статистических данных исходных проектов;
2) разработка методов оценки степени достоверности данных исходных проектов;
3) идентификация и классификация функциональных блоков программных систем;
4) идентификация параметров, влияющих на стоимость программного проекта и на их основе уточнение модели и методики.
Библиографический список
1. Михайловский, Н. Сравнение методов оценки стоимости проектов по разработке информационных систем [Электронный ресурс] / Н. Михайловский. Электрон. дан. Режим доступа: http://www.pmproiy.ru/content/rus/79/797-article.asp. Загл. с экрана.
2. Макконнелл, С. Остаться в живых. Руководство для менеджера программных проектов / С. Маккон-нелл. СПб. : Питер, 2006. 240 с. (Библиотека программиста).
Yu. Yu. Yakunin
ESTIMATION OF LABOUR PRODUCTIVITY OF DEVELOPMENT OF PROGRAM SYSTEM
The technique and mathematical model of an estimation of labour productivity of the program project on the basis of the metrics based on functional points are described.
УДК 621.314
А. В. Калинин, С. В. Ченцов АЛГОРИТМ ВОССТАНОВЛЕНИЯ ПРОПУСКОВ НА ПОЛЕ «ПЛОХИХ» ДАННЫХ
Предложена модификация алгоритма ZЕT восстановления данных на основе анализа многомерности данных. Приведены результаты сравнительного анализа восстановления данных модифицированным алгоритмом ZЕT.
Ключевые слова: восстановление пропусков, многомерные данные 2БТ алгоритм.
Для современной науки характерно непрерывное возрастание сложности изучаемых объектов. Одним из характерных свойств «сложных объектов» является то, что для описания используются переменные различной физической природы. Например, при изучении причин миграции населения социолог вынужден учитывать большое число факторов, отражающих экономические, географические, природно-климатические, культурно-бытовые условия и т. д. Часто при работе на «сложных объектах» приходится сталкиваться с ситуацией, когда отсутствуют те или данные. Причины этого различны: ошибки, допущенные при сборе сведений; невозможность в силу каких-либо причин заполнить значения и т. д. При этом для анализа данных требуется непрерывный набор значений. Пропущенные значения могут серьезно повлиять на результаты анализа. Поэтому возникает задача наиболее точного заполнения пропусков.
Алгоритмов решения данной задачи весьма много - от самых простых до весьма сложных математических подходов [1-3]. Следует отметить, что при формировании модели «сложного объекта», как пра-
вило, возникают трудности, что объясняется существенным недостатком знаний о его внутренних функциональных взаимосвязях.
В настоящее время широкое распространение получили локальные алгоритмы заполнения пропуска на основе использования зависимостей, определенных на части данных в некоторой окрестности пропуска в отличие от других, основанных на предположении, что зависимость заданного (например, линейного) типа реализована на всех данных, поэтому и в определении зависимости участвуют все строки и столбцы исходного поля данных.
Многолетний опыт использования локальных алгоритмов показал их высокую эффективность по сравнению с другими известными алгоритмами заполнения пробелов, редактирования таблиц и прогнозирования характеристик динамических (меняющихся во времени или пространстве) объектов [1]. Вместе с тем, по мере накопления опыта решения реальных задач возникает необходимость модификации существующих локальных алгоритмов и разработки новых. В процессе исследований изучается влияние различ-
