CC BY
59
12. Mckinley P., Sadjadi S.M., Kasten E., Cheng B. Composing Adaptive Software // IEEE Computer Society. - Vol. 37. - № 7, July, 2004. - P.27-30.
13. Гурьянов В.И. Многоагентная модель среды поддержки программного продукта для систем со слоистой архитектурой // Управление большими системами. - Вып. - 22. - М.: ИПУ РАН, 2008.
14. Башмаков А.И., Старых В.А. Подход к формированию и описанию структуры профиля стандартов и спецификаций информационно-образовательных сред // Вестник компьютерных и информационных технологий. - 2007. - № 11.
15. Башмаков А.И., Старых В.А. Профиль стандартов и спецификаций информационно-образовательных сред как основа для обеспечения их взаимодействия // Вестник компьютерных и информационных технологий. - 2007. - № 8.
16. Barritt C. Creating a Reusable Learning Objects Strategy: Leveraging Information and Learning in a Knowledge Economy, 2004, Wiley.
17. Gray J., Helland P., O'Neil P., Shasha D. The Dangers of Replication and a Solution. SIGMOD. - June 1996. - 4. "eXtremeDB High Availability Addendum", McObject, Issaquah, WA, 2003.
18. McGraw H. Row-Level Security with Virtual Private Database - 2005. Osborne.
ОЦЕНКА СТОИМОСТИ ПРОЕКТОВ: ПРОГРАММНЫЙ ИНСТРУМЕНТАРИЙ
М.А. Глазова, асп. Тел.: (916)58-181-24; E-mail: mglazova@gmail.com
В.П. Грибанов, к.э.н., доц. Тел.:(495) 442-80-98; E-mail: VGribanov@mesi.ru Кафедра Математического обеспечения и администрирования информационных систем Московский государственный университет экономики, статистики и информатики
http://www.mesi.ru
In article the history of development of the software market at the price of projects is described, and also merits and demerits of software products, problems of branch are described.
С момента появления первых проектов, задействовавших в себе определенную
группу людей, выделяющих лидера - менеджера проекта - для управления с целью достижения поставленной цели, заинтересованные лица всегда хотели знать две важные величины: за какое время удастся закончить проект, и сколько ресурсов уйдет на него.
Первоначально производимые оценки стоимости и сроков проекта были очень неточны. Поскольку создаваемое приложение ограничивалось некоторой сферой деятельности, то достаточно несложно было найти в ней специалистов, которые, основываясь на своем опыте, могли сказать, с большей или меньшей степенью уверенности, сколько
времени может занять выполнение той или иной работы. В случае отсутствия специалистов менеджеры поступали иначе - за основу брались данные по успешно завершенным проектам, совпадающим по составу работ. Разумеется, это работало до тех пор, пока не требовалась оценка инновационного проекта - того, что никто никогда не делал. По этим проектам ошибки были колоссальными и порой приводили к драматическим последствиям. Например, проект ФБР Virtual Case File был свернут, когда при вложениях в него 170 миллионов долларов было реализовано только 1/10 из запланированных возможностей. Проект строительства скоростного шоссе в Бостоне был оценен в 2,6 миллиарда долларов, но в конечном счете затраты на него оказались более 15 миллиардов - то есть ошибка оценки была более 400% [1].
Проходило время, эксперты накапливали больше сведений по проектам, находили общие тенденции, и оценки становились все более и более точными. Риск ошибки оста-
вался достаточно большим - границы правил, определяемых экспертами, определялись на новых проектах.
Появились первые модели оценки стоимости - математические алгоритмы, позволяющие оценить стоимость продукта или проекта. Их появление стало значимой вехой в области оценки стоимости программных проектов: во-первых, это привело к еще большему увеличению точности оценок, и, во-вторых, их использование позволяло менеджерам средней квалификации выполнять достаточно точные оценки в тех областях, где раньше прогноз затрат доверялся исключительно экспертам.
Было только вопросом времени, когда появятся программы, построенные на основе модели. Это случилось в начале 1970-х, когда появились компьютеры, способные производить расчеты такого уровня, который требовали алгоритмы оценки стоимости за приемлемое время. Родоначальниками рынка программ по оценке стоимости считаются исследователи крупных компаний и корпораций, занимавшихся компьютерными разработками в то время: IBM, RCA, TRW и военно-воздушные силы США. Первым коммерческим программным продуктом по оценке стоимости стала система PRICE-S, разработанная Ф. Фрэйменом и его коллегами, сотрудниками компании RCA.
В 1973 году А. Альбрехт и его коллеги из компании IBM разработали новую метрику оценки программного обеспечения -функциональные точки - которая стала основой для многих современных систем оценки стоимости (в настоящее время эту метрику поддерживают более 30 программных продуктов по оценке стоимости, разработанных в США).
В 1979 году на американском рынке появился второй коммерческий продукт по оценке стоимости. Им стал SLIM (software lifecycle management - управление жизненным циклом программного обеспечения), разработанный Л. Путнамом, сотрудником компании Quantitiative Software Management. Первоначальное исследование, которое легло в основу этого программного продукта, было сделано Путнамом, когда он служил полковником в военно-воздушных силах США.
В 1981 году доктор Б. Боэм из корпорации TRW опубликовал книгу «Экономика разработки программного обеспечения», которая содержала алгоритмы модели, которая стала в дальнейшем одной из наиболее часто
используемых - COCOMO (constructive cost model - конструктивная модель оценки стоимости). С того момента, как алгоритмы COCOMO были опубликованы, прошло много времени, но и сейчас COCOMO остается единственной моделью оценки стоимости, алгоритмы которой полностью раскрыты и не являются коммерческой тайной.
Доктор Б. Боэм и его коллеги также создали новую версию COCOMO, получившую название COCOMO II, алгоритмы которой также были описаны в новой книге, опубликованной в 2000 году. COCOMO II расширила возможности старой модели, и теперь с ее помощью можно оценивать приложения, созданные с помощью современных методов разработки.
Продолжая исследования в области оценки стоимости, в 1983 доктор Г. Рубин выпустил на рынок продукт под названием ESTIMACS. Он был построен на основе внутренней методологии оценки стоимости компании IBM в области проектов по разработке информационных систем и поддерживал раннюю версию метрик оценки с помощью функциональных точек (в 1984 году методология функциональных точек была переработана).
В 1985 году на рынке появился программный продукт исследователя К. Джонса [2], получивший название SPQR/20 (software productivity, quality and reliability - продуктивность, качество и надежность программного обеспечения). Это была первая система оценки стоимости, полностью построенная для подсчета с помощью функциональных точек. В 1989 году система SPQR/20 эволюционировала в более мощный инструмент, получивший название Checkpoint, который включал в себя метрики программного обеспечения, поддержку IFPUG и оценку программного обеспечения начиная с детализации на уровне задачи.
В 1997 году была создана система по оценке стоимости KnowledgePlan. Этот продукт стал windows-приложением, поддерживающим двунаправленное взаимодействие с Microsoft Project и с рядом других программ для управления проектами. Также этот инструмент поддерживал оценку на различных
уровнях проекта - от макроуровня до уровня задачи.
Постепенно компьютеризированная оценка стоимости начала становиться все более популярной, и появилось большое количество программных пакетов, как коммерческих, так и созданных внутри компаний - разработчиков программного обеспечения для внутренних нужд. В итоге, к середине 1990-х годов количество коммерческих продуктов по оценке стоимости программных проектов приблизилось к 50 в США и 25 в Европе.
Программные продукты во многих аспектах различались друг от друга, их возможности варьировались от параметрических пакетов до детализированных программ оценки.
Современные программные продукты по оценке стоимости [3] могут выполнять многие функции, присущие системам управления проектами. Однако если сравнивать эти две группы систем, то можно найти достаточно много отличий, которые не позволяют рассматривать эти системы как относящиеся к одной области программных продуктов. Работы по слиянию этих двух направлений ведутся, но в полной мере они не завершены.
Программные продукты по управлению проектами автоматизируют некоторые работы, которые выполняет менеджер проекта, -они выполняют анализ критического пути, расход ресурсов, строят диаграммы Ганта. Программы управления проектами изначально не создаются только для сферы программного обеспечения. Они используются для сложных задач построения графика, состоящего из нескольких сотен или даже тысяч работ, со сложными взаимодействиями, но в разных сферах - будь то военная, строительная или же сфера разработки программного обеспечения.
Программы по управлению проектами не содержат специальных модулей по оценке программного обеспечения, как системы оценки стоимости. Например, программа управления проектами не сможет определить различие в стоимости двух проектов, один из которых использует в качестве базового языка разработки Visual Basic, а другой - C. В данном случае верно использовать программу по оценке стоимости.
Поскольку программы по оценке стоимости появились гораздо позже систем управления проектами, разработчики в большинстве случаев не стали добавлять в
них инструменты характерные для систем управления проектами (анализ критического пути, диаграммы Ганта), а вместо этого добавили механизм экспорта данных в системы управления проектами. Будучи более просто реализуемым средством, это стало нормой, лишая, таким образом, системы оценки стоимости наличия полной информации по проектам в реальном времени.
Второй характеристикой, сделавшей системы оценки стоимости по сути лишь дорогим дополнением к системам управления проектами, вместо того, чтобы стать полноценным программным комплексом, стало в большинстве случаев отсутствие системы разграничения доступов, позволяющей ограничивать просмотр конфиденциальной информации по проектам, разрешать и запрещать отдельным пользователям операции по оценке.
В целом, спектр задач, которые призвана решать современная система оценки стоимости, весьма широк, и с развитием информационных технологий только продолжает расширяться. Авторами были проанализированы наиболее известные из существующих систем подобного класса, и на основе этого был составлен список их основных функциональностей.
1. Поддержка разных моделей жизненного цикла. Жизненный цикл проекта - это последовательная реализация его стадий, направленная на получение конечной цели -готового программного продукта. Организации - разработчики программного обеспечения не похожи друг на друга, они используют разные технологии разработки, этапы создания их программ могут сильно отличаться друг от друга. Это обусловлено спецификой процессов, количеством сотрудников, временем и ресурсами, выделенными на проект. Все это должно учитываться в модели стоимости. Чем больше разных моделей жизненного цикла она поддерживает - тем она более универсальна.
2. Поддержка различных языков программирования и гибкость оценки размера кода. Важной составляющей практически любой модели оценки стоимости является оценка размера создаваемого программного продукта. Варианты оценки могут быть самыми различными - от количества компонентов до подсчета строк кода. Необходим некоторый универсальный механизм, который позволял бы свести оцененные объемы к некоторому среднему значению, которое было бы сопоставимо для проектов, в основе
которых лежит разработка программных средств, написанных на разных языках программирования. Применимость модели и соответствующего программного продукта по оценке стоимости во многом зависит от того, поддерживаются ли современные языки программирования, насколько много их поддерживается, возможна ли поддержка повторного использования уже существующего кода и, наконец, насколько гибок механизм перевода.
3. Возможность построения функциональной модели системы. Ряд систем оценки
стоимости обладает возможностью графического отображения функциональной модели системы. Произведя описание компонентов и их взаимосвязи, пользователь может получить визуальное отображение всей системы в целом, что упрощает ее понимание, позволяет прослеживать связи между компонентами. На рис. 1 (fpw_скриншотjpg) представлен пример подобного графического отображения в системе БР'. Также, на основе этого описания система может проводить расчет предполагаемого размера программного кода.
ф Г|Я8Вп Рой *5Вё<сЕ [Рн^чЫНоп | Еп1и|кн1 йорюгйг^ 5Я ЙЙ \ 2, fu.ictior.af №<|и1г*тм|Ь | Им» II ЙрЫ1.-..,'[аТ^
■ □в: »ЁЫЕ § Я Л ай «I» V № <® с» о, [йрЕтГв 3
Рвч-.и 1С<1 Пцклог
£
н
1
1
; —Наук-лди Битума I >
■ II
I 1.дЬе'1 Сокмг Не, . §¡11
{ 1 * \
ни Анимсш
ГШ ___
ЕгЛлпмкп1РтС9«1 й ...... Мм1е -МОМРГ
СЬяпд*
>Й,3
^ сет Р^де { 5'■ 15 У гтк к алрв (о ■ 1)
№
> - ирАЫС
:> ЕГО 2.6 -КвауЙИлсывЮот,
> №а«п Ьг ¡оГг.-.йге ЬиИ - вф^вВйя сотсййше * икг С0ФПЧ*11У ■
Рис.1. Пример графического
4. Простота использования. Дружественность интерфейса в последнее время стала одной из ключевых характеристик большинства систем. Даже для таких сложных и многофункциональных систем, как программы по оценке стоимости должен существовать некоторый упрощенный механизм оценки, который мог бы использовать начинающий менеджер и любой другой сотрудник, не знакомый с областью оценки стоимости, чтобы быстро получить нужный ре-
отображения в системе FPW
зультат. Насколько быстро можно оценить проект, изменить те или иные параметры проекта и увидеть новые результаты оценки? От этого зависит, насколько система оценки будет удобной и простой в использовании.
5. Возможность проработки сценариев «что если». Выполнив основной прогноз оценки стоимости по проекту, менеджер может задаться вопросом - а что случится, если по проекту сократят сроки разработки,
финансирование, или же уйдет наиболее опытный разработчик? Насколько сильно изменится стоимость проекта, и что он может сделать, изменить какие параметры, чтобы сбалансировать все эти изменения? Это позволяет сделать сценарий «что если». В системе оценки стоимости менеджер может задать, насколько сильно изменится один или несколько параметров проекта, и система рассчитает, какова будет стоимость и длительность проекта в этом случае. Соответственно, меняя другие параметры, менеджер может привести стоимость проекта к первоначальному значению, тем самым вернув проект в состояние равновесия. На рис. 2 (SLIM_скриншотjpg) и 3 (pjcost_ скрин-шотjpg) - см. цв. вставку - представлен пример проведения анализа «что если» в средах SLIM и PJCost соответственно.
6. Наличие репозитория, хранения истории по проектам. Приступая к новому проекту, важно понять, что от него можно ожидать. Это позволяет избежать ряда сложностей и подводных камней. Если система оценки стоимости хранит всю историю по проектам организации, то это может в значительной степени упростить жизнь менеджеру проекта. Работа над подобного рода проектом уже могла вестись в прошлом, и тогда опыт оценок, расчетов, предсказывания изменений может помочь, научить, позволить сократить затраты, увидеть что-то, что просмотрел менеджер того проекта. Ряд систем позволяет провести сравнительный анализ по выбранным проектам, упрощая поиск тех ключевых точек, по которым пошли расхождения в настоящем и в прошлом проектах. Кроме того, историческая информация может послужить для осуществления еще одной, очень важной цели - проведения калибровки модели оценки.
7. Возможность калибровки. Любая система оценки стоимости поставляется с некоторыми усредненными для отрасли оценками. Поскольку технологии работы предприятия могут не совпадать с технологиями тех предприятий, на основе которых подсчитывались коэффициенты, используемые в модели, программа может выдавать недостаточно точные оценки. Этого можно избежать, если, накопив достаточное количество исторических данных по конкретному предприятию, провести калибровку. Калибровка - это механизм подстройки модели под нужды конкретного предприятия, направленный на повышение точности оценок. Чем больше данных используется в качестве
базы для калибровки, тем лучше будут настройки, и тем точнее будут оценки программы для данного предприятия.
8. Возможность добавления новых факторов моделей, глобальной перенастройки модели. Порой калибровки может быть недостаточно для того, чтобы сделать оценки более точными. Модель может не учитывать какого-то важного фактора влияния на стоимость, который является ключевым для данного предприятия. Например, при разработке системы безопасности фактором, повышающим стоимость проекта, может являться необходимость разработки специальных механизмов шифрования, сертификации системы по стандартам безопасности. Стандартное программное средство по оценке стоимости может такой фактор не учитывать, но давать возможность добавления любого нового фактора с последующей перенастройкой системы, то есть изменением значений других факторов вследствие добавления нового.
9. Возможность экспорта/импорта, связи с внешними системами. Если для управления проектами используется одна система, а для оценки стоимости другая, то чтобы оценить стоимость проекта, надо предварительно занести данные по проекту в систему оценки, и, наоборот, чтобы в системе управления проектами была данная по оценке стоимость, ее нужно каким-то образом добавить из внешней системы оценки. Перенос данных путем набора приводит к неизбежным ошибкам, и механизм экспорта/импорта позволяет свести количество ошибок к минимуму. Соответственно, чем большее количество форматов данных для выгрузки/загрузки система поддерживает, тем более универсальной она является. Более совершенным путем связи является связь систем управления оценки стоимости и управления проектами в режиме реального времени. Это более сложно реализуемый и потому редко встречающийся механизм, но зато он полностью исключает ошибки переноса данных.
10. Наличие гибкой системы отчетности. Современный продукт по оценке стоимости должен иметь возможность вывода результатов разной степени детализации и группировки, для предоставления отчетов руководителям разного уровня иерархии, удобного просмотра необходимой результатной информации в графической и текстовой форме. На рис. 4 (cost_скриншот.jpg) и 5 (caliber_скриншотjpg) - см. цв. вставку -
приведены экранные формы, отражающие результаты расчетов в системах Cost Xpert и Borland CaliberRM соответственно.
11. Наличие механизма поддержки принятия решений. Достаточно редко встречаемой характеристикой, сложной для реализации и не всегда используемой менеджерами проектов вследствие недоверия, является механизм поддержки принятия решений. Система оценки может проанализировать сложившуюся по проекту ситуацию и предложить решения по уменьшению оценки стоимости, длительности проекта путем изменения тех или иных параметров проекта. Механизм удобен для начинающих менеджеров проекта, но специалисты в области оценки стоимости предпочитают не полагаться на решения, предложенные системой, самостоятельно находя оптимальный вариант.
12. Возможность совместной работы. Является существенной, особенно для крупных предприятий, с большим количеством участников проектов. Позволяет изменять данные, просматривать изменения по одному проекту одновременно всем пользователям системы.
13. Разограничение доступов. На крупных предприятиях, с большим количеством проектов, может возникнуть необходимость, например, дать менеджеру доступ только к группе проектов, на редактирование, аналитику - ко всем проектам, но только на просмотр. Это может требоваться из-за высокой важности, конфиденциальности проектов и, соответственно, недопустимости просмотра этой информации всеми сотрудниками предприятия. Эта характеристика сложно реализуема и поэтому присутствует в очень небольшом количестве систем оценки стоимости.
14. Возможность коммуникаций внутри системы. Эта функциональность, нехарактерная для систем оценки стоимости, стала появляться в них относительно недавно, но стала популярной по причине удобства работы. Она позволяет взаимодействовать с другими участниками системы, не используя никаких дополнительных средств коммуникации, через встроенные внутри системы механизмы.
В табл. 1 (Программные продук-ты_сравн_1.jpg - Программные продук-ты_сравн_2.jpg) приведен сравнительный анализ наиболее известных программных продуктов по оценке стоимости программ-
ных проектов - SLIM Tools [4], KnowledgePlan [5], FPW [5], Cost XPert [6], Borland CaliberRM [7], а также разработанной автором системы PJCost, с оценкой наличия/отсутствия рассмотренных характеристик. Каждая из данных систем обладает рядом уникальных возможностей. Так, в FPW можно построить функциональную модель системы, SLIM имеет модуль поддержки принятия решений, PJCost содержит гибкий механизм калибровки и перенастройки системы, продвинутую систему разграничения доступов. В общем же, механизм оценки в системах подобного класса сходен - пользователь отвечает на ряд вопросов касательно характеристик проекта, и на выходе ему выдаются предполагаемая стоимость и длительность проекта.
Если производить выбор, какая из систем будет наиболее функциональной, то наибольшее количество баллов набрала разработанная автором система PJCost. Из всех рассмотренных характеристик у нее отсутствует только две - модули поддержки принятия решений и построения функциональной модели. Построенная на базе Oracle 9.2 она позволяет быстро производить сложные вычисления по оценке стоимости, работать большому количеству пользователей одновременно, имеет систему разграничения доступов. Система имеет полностью русский интерфейс и систему помощи и является одной из первых систем оценки стоимости программных проектов, разработанных в России.
Система оценки стоимости программного проекта PJCost включает в себя следующие подсистемы:
1. Подсистема справочников. Одержит все основные термины, списки, используемые при оценке. Это позволило поддержать мультиязычность системы -хранить в таблицах как термины на русском, так и на других, поддерживаемых системой языках, и подставлять термины на языке текущего пользователя системы.
2. Подсистема настройки. Одержит таблицы, в которых хранятся данные по настройкам формул, рейтинговых шкал, используемых для подсчета стоимости проекта на основе модели оценки. Есть возможность применения разных настроек для различных групп проектов, дополнения настроек и отката, как к предыдущей версии настроек, так и к первоначальным настройкам системы.
Наименование характеристики SLIM Tools Knou led gePlan FFW Cost XPert Borland CahberRU PJCo5t
ГТпдтрр'дтга pare* i и и нкгу I1,' 0Д5Я5И ЖЕЗНеШГСГ с цикла - Имеющей шаблоны для разных жизненных 32 стандарта Е м одели жизненног с - у. рш- сосомоп
По д держка раз личных языков программирования + - + +
В озм ажно сть построения ävhkhhohs льной м одели системы - + - -
Простота нспольз ев акия сыстрой оценки мастеров для рабОТЫ +Возможность визуального построения процессов, дляновичкаи профессионала - [сколе ¿5 минут на первичную опенку) - H аличие г.: астеров -г быстрая опенка на основе предустановленных параметров
Наличие воз:,! ожко ста проработки сценариев «что если» - возможность просмотра в динамике + + + + +
Наличие репозигория. возможности хранения ЕСТСрИИ -Возможность переноса данных из ЕСТОрИИНа Текущую опенку. ю.з еется база знании -Есть база знаний - + "ВОЗМОЖНОСТЬ о завершенных проектах и дальнейшего ее использования + возможность сравнительного анализ а проектов. хранение полное истории изм енения пс проектам и опенкам
Возможности экспорта импорта -MS Offir- html -^-MS Project внешними системами через ODBC —.html, лги! - форматы - MS Project. Primavera + -г непс средств енно е в заим одействие о систем ой управления проектами. MS Project Excel
Наименование ха р а ктер ист и ки SLIM Tools KnowledgePlan mv Cost XPert Borland CaliberRM PJCost
Н аличие м еханвзм а поддержки приня тия решений — предлагает в арианты решения проблемы
Гибкость оценки размера кода ■tip 4= +
Возможность калибровки + + + - -возможность применения настроек калибровке к группе проектов, отката настроек, приостановки действия настроек, возврата к предустановленным значениям. Три разных режима калЕбровкЕ пс выб ору пользователя
Возможность добавления новых ф акторов н одели, глоб альной перенастройки системы - + - легкое дсбявление новых факторов. в озможно сть анализ а изменении, которые принесет добавление ф актора
Наличие гибкой системы отчетности - + - - + +
Возможне сть совместной работы + - + +
Разграничение доступов - -{-возможность аДЬГИННСТрырОЕ ЕИЮЕ настройка-разграничения доступов по проектам и по операциям
Возможность коммуникаций внутри системы + - через модуль коммуникационной системы управления предпркя ткем
мы хранения и анализа. Функции подсистемы оценки стоимости позволяют производить моделирование оценок, анализ «что если». Есть возможность сравнить несколько проектов для выявления их различий, для лучшего понимания менеджером ситуации, что, возможно, пошло не так, и как это можно исправить, или же просто использовать сравнения в качестве обучающего материала.
3. Подсистема хранения и анализа. Содержит таблицы, в которых хранятся данные по оценкам проектов. С помощью этих данных можно производить сравнительный анализ проектов, выявлять расхождения в оценках и находить их причины.
4. Подсистема оценки стоимости. Включает в себя серверные пакеты, функции и процедуры которых осуществляют оценку стоимости на основе значений из подсисте-
5. Подсистема разграничения доступов. Содержит настройки доступности операций пользователей системы по тем или иным проектам. Она поддерживает создание проектных ролей - контейнеров, содержащих набор операций, доступных для выполнения пользователю в данной системе. В дальнейшем эти проектные роли могут использоваться в проектах, с назначениями их конкретным пользователям, таким образом, давая широкие возможности по разграничению доступов внутри системы.
6. Подсистема калибровки. Включает в себя серверные пакеты, предназначенные для калибровки факторов модели с целью увеличения точности оценки. Функции подсистемы калибровки подразделяются на два вида:
• анализ расхождений между фактическими и моделируемыми значениями. Поскольку система оценки стоимости была разработана авторами с возможностью интеграции с системой управления проектами, то менеджер с течением времени может получить точные фактические результаты стоимости программного проекта. Эта информация может быть полезна для системы оценки стоимости в целях увеличения точности оценки, потому как те значения, которые
указаны в модели СОСОМО II, являющейся ядром системы, ориентированы все-таки на общую модель проекта, без учета специфики технологий предприятия. Анализируя расхождения фактических и моделируемых значений, можно понять, в каких константах есть расхождения и что следует скорректировать для увеличения точности оценки.
• подстройка в соответствии с расхождениями. Эти функции позволяют на основе полученного анализа расхождений произвести подстройку характеристик модели СО-СОМО II под нужды конкретного предприятия. Таким образом, можно существенно повысить точность производимых системой оценок.
Результаты работы были апробированы и успешно используются в реальных условиях среды разработки программного обеспечения, в ЗАО «Системы автоматизированного управления», основным видом деятельности которого является разработка профессионального программного обеспечения, в качестве инструментария для прогнозирования стоимости проектов, для анализа изменения стоимости и длительности в результате возможных изменений параметров проекта.
Действие Перечня в редакции апреля 2008 г. прекращается 1 сентября 2009 г.
В связи с прекращением действия Перечня в редакции апреля 2008 г., научным периодическим изданиям, входящим на настоящий момент в Перечень, необходимо представить комплект документов в установленном порядке для перерегистрации и включения в новую редакцию Перечня.
Источник Высшая аттестационная комиссия Министерства образования и науки Российской Федерации (http://vak.ed.gov.ru/ru/news/allnews/index.php?id4=1145)
Литература
1. Макконнелл С. Сколько стоит программный проект. - М.: «Русская Редакция», Спб.: Питер,
2007.
2. Capers Jones. How estimation tools work. - Software Productivity research LLC, 2005. http://www.compaid.com/caiinternet/ezine/capers-estimation.pdf
3. Gina Kingston, Martin Burke. iMAPS: A Review of Software Sizing for cost estimation. - Department of Defense. Defense Science and technology organization, Australia. DSTO Electronics and Surveillance Laboratory, 1996.
4. http://www.qsm.com/
5. http://www.spr.com/
6. http://www.costxpert.com
7. http://www.borland.com/us/products/caliber/index.html
