ИТ-индустриия и разработка ПО

Оглавление Введение Глава 1. Роль ИТ-индустрии в мире и необходимость измерения ПО

1.1 Роль ИТ-индустрии в мире и в международных отношениях

1.2 Работы и исследования, положенные в основу измерения программного обеспечения

1.3 Зачем нужны модели и методы оценки затрат на разработку программного обеспечения Глава 2. Методы оценки трудозатрат на разработку ПО

2.1 Метод суждения эксперта

2.2 Метод оценки по аналогии

2.3 Нисходящий и восходящий методы

2.4 Алгоритмические методы Глава 3. Модели оценки затрат на разработку ПО

3.1 Модель Путнэма жизненного цикла программного обеспечения — SLIM

3.2 Checkpoint

3.3 PRICE-S

3.4 SELECT Estimator

3.5 Модель COCOMO II

3.6 Принципы, которыми нужно пользоваться при оценке трудозатрат проекта Заключение Использованные источники

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

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

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

После 20 лет исследований, возникло множество методов расчета затрат по разработке программного обеспечения таких как: алгоритмические методы (algorithmic methods), оценка по аналогии (estimating by analogy), методу суждения эксперта (expert judgment method), метод цены, чтобы выиграть метод (price to win method), нисходящий метод (top-down method) и метод основания наверх (bottom-up method). Ни один метод не является лучше или хуже чем другой, однако понимание их преимуществ и недостатков очень важно, когда вы хотите оценить затраты в ваши проектах.

Глава 1. Роль ИТ-индустрии в мире и необходимость измерения ПО

1.1 Роль ИТ-индустрии в мире и в международных отношениях Анализ собранных компанией IDC данных об экономической роли ИТ-индустрии позволяет выявить величину его влияния на экономику. С ростом этого сектора связаны прямые преимущества для работников, государства и экономики во всем мире.

ИТ-индустрия является двигателем глобального экономического роста и предоставляет ряд ключевых преимуществ:

Сегодня ИТ-индустрия непосредственно обеспечивает работой 9 млн. высокооплачиваемых квалифицированных сотрудников в более чем 4 тыс. компаний во всем мире. Кроме того, этот сектор экономики создает занятость еще для 21 млн. ИТ-специалистов в самых разных сферах деятельности — от консалтинга до грузовых автоперевозок. Число рабочих мест в ИТ-индустрии в целом за период с 1996 по 2002 год выросло на 40%, а в отрасли программного обеспечения — на 76%.

ИТ-индустрия приносит в бюджеты своих стран свыше 700 млрд долл. налоговых поступлений в год. Эти налоговые доходы от деятельности, связанной с информационными технологиями, выросли за 1996—2002 годы на 37% и помогают финансировать жизненно важные государственные службы и предоставлять государственные льготы, в том числе обеспечивают общественную безопасность, работу школ и транспортной системы. Таким образом, можно сделать вывод, что рост ИТ-индустрии выгоден для государства и общества в целом.

Вклад ИТ-индустрии в мировую экономику составляет почти 1 трлн. долл. в год, в том числе 330 млрд долл. поступают от отрасли производства компьютерного оборудования, 180 млрд долл. — от отрасли «тиражного» программного обеспечения и еще 420 млрд долл. — от отрасли ИТ-услуг.

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

ИТ-отрасль — исключительно разнообразный сектор экономики, и его можно логически разделить на 3 горизонтальных сегмента: оборудование, программное обеспечение и услуги:

оборудование: по оценке IDC, расходы на ИТ-оборудование во всем мире в 2001 году превысили 381 млрд долл. и в течение следующих четырех лет будут возрастать в среднем на 4,3% ежегодно и в 2005 году составят 450 млрд долл.;

программное обеспечение: по оценке IDC, расходы только на коробочное ПО во всем мире в 2001 году достигли 192 млрд долл. и в течение следующих четырех лет будут возрастать в среднем на 15% ежегодно и в 2005 году составят 335 млрд долл.;

услуги: по оценке IDC, расходы на ИТ-услуги в мире в 2001 году превысили 426 млрд долл. и в течение следующих четырех лет будут возрастать в среднем на 11,1% в год и в 2005 году составят 650 млрд долл.

Отрасль программного обеспечения способствует росту ИТ-индустрии в целом:

Отрасль программного обеспечения и связанная с нею отрасль ИТ-услуг представляют собой два основных двигателя роста ИТ-индустрии и превосходят по вкладу отрасль компьютерного оборудования. В 2001 году программное обеспечение и ИТ-услуги составляли более 60% расходов в ИТ-индустрии (см. рис. 1). Кроме того, они отличаются и более высокими темпами роста. Так, в 1996—2001 годах расходы на программное обеспечение увеличивались в 6 раз быстрее, чем расходы на компьютерное оборудование (см. рис. 2). Ускорение темпов роста индустрии программного обеспечения в сочетании с воздействием на повышение значимости отрасли ИТ-услуг позволили ей стать основной движущей силой развития информационных технологий, и в свою очередь привело к расширению предоставляемых ими преимуществ.

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

Информационные технологии делают бизнес более конкурентоспособным:

Ведущие компании и правительства разных стран мира поставили перед собой задачу внедрения решений, расширяющих возможности бизнеса, повышающих конкурентоспособность и увеличивающих прибыль. Эти решения повышают качество обслуживания, позволяют сократить расходы, повысить эффективность и устранить риск. Часть этой задачи — избавиться от неэффективных и неточных бизнес-процессов. Хотя многие предприятия уже выполнили эту задачу, оптимизировав бизнес-процессы на основе новых информационных технологий, экономический спад последних лет показал, что предприятия слишком тянули с новыми вложениями в ИТ.

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

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

Отчет «Destination Wireless», недавно составленный для корпорации Intel организацией Economist Intelligence Unit, основан на опросе более 600 сотрудников компаний из десяти стран Европы и Ближнего Востока. Он показывает растущее влияние глобализации и беспроводных технологий на рабочие методики и культуру офисной работы. Уход от традиционной культуры офисной работы с восьмичасовым рабочим днем стал возможным благодаря использованию интернет и мобильных технологий, позволяющих служащим рассматривать работу как дело, которое нужно сделать, а не как место, куда нужно ходить. По данным отчета, сотрудники работают за пределами офиса больше времени, и их рабочий день становится более длинным, а также более фрагментированным в связи с необходимостью работы в виртуальных группах, в которые входят сотрудники из разных стран и часовых поясов.

Служащие успешно адаптировались к изменениям, что подтверждают следующие результаты:

большинство (68%) считает, что работа вне офиса более продуктивна (19%) или настолько же продуктивна (49%), что и работа в офисе;

около трех четвертей опрошенных (73%) считают, что удаленная работа так же удобна, как и работа в офисе;

более трех четвертей опрошенных считают, что мобильная работа дает их компании преимущество перед конкурентами (83%) и позволяет им лучше обслуживать клиентов (88%);

87% указывают возможность продуктивной работы за пределами офиса, как важнейшее преимущество.

Мобильные и Интернет технологии способствуют интернационализации и глобализации бизнеса, давая возможность вести и контролировать бизнес из любой точки мира, а также значительно облегчают международное сотрудничество между компаниями.

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

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

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

Например, ЕС планирует к 2005 году обеспечить широкополосным доступом в интернет все школы и университеты Европы, создать виртуальные университеты и общеевропейские сети и платформы на базе высокопроизводительных компьютерных инфраструктур.

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

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

Ежегодно корпорация Intel вкладывает более 100 миллионов долларов в образовательные программы, с 1968 года она вложила в поддержку образования более 1 миллиарда долларов, оказывая помощь образовательным учреждениям и проводя специальные программы более чем в 50 странах на семи континентах.

Другим средством повышения компьютерной грамотности населения являются программы распространения домашних компьютеров Home Computing Initiatives (HCI), все чаще проводящиеся в различных компаниях Европы. Эти программы основаны на налоговых вычетах и гибкой системе кредитования, позволяя людям улучшить свои навыки работы на компьютере. Программы HCI способствуют повышению гибкости и продуктивности работающих специалистов и расширению сферы их навыков. Такие схемы также помогают привлекать и удерживать в компании мотивированных опытных сотрудников, сокращать операционные расходы и экономить на налогах.

Использование современных технологий в образовании, а также проведение программ HCI играет очень важную роль в переходе к обществу, основанному на знаниях, где технологии играют самую важную роль. По оценкам конфедерации промышленников Великобритании (CBI), через пять лет 85% новых рабочих мест будут требовать технических знаний и навыков в области информационных технологий. Дигби Джонс (Digby Jones), генеральный директор CBI, заметил: «Основная цель всех организаций, которые хотят адаптироваться в экономике завтрашнего дня, должна заключаться в том, чтобы информационные технологии вошли в гены работников завтрашнего дня».

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

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

В секторе здравоохранения также начинается активное внедрение беспроводных технологий, которые позволят улучшить качество ухода за пациентами и сократить расходы. Например, в детской больнице «Шнейдер» в Израиле врачи могут быстрее получать информацию, необходимую для принятия решений, используя ноутбуки с беспроводным доступом, обеспечивающие мгновенный доступ к историям болезни и всем медицинским данным пациентов в реальном времени и позволяющие быстрее производить диагностику и назначать лечение.

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

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

Источники информации:

1."Экономическая роль индустрии информационных технологий", статья с www.msdn.ru

2."Microsoft и развитие национальной экономики", статья с www.msdn.ru

3. «Информационные и телекоммуникационные технологии: преобразования в Европе», Наука и техника, 2004 г.

1.2 Работы и исследования, положенные в основу измерения программного обеспечения Основные работы по мерам и измерения программного обеспечения были написаны в шестидесятых и главным образом в семидесятых годах в США. На основе этих работ были, собственно разработаны основные методы и модели оценки в восьмидесятые и девяностые годы.

Причины для создания и развития мер программного обеспечения основаны на знании, того что структура программы и модульность являются важными условиями для развития надежного программного обеспечения. Большинство специалистов по программному обеспечению соглашаются, что высокая надежность обеспечена, если программный продукт правильно разбит на модули, а структура модуля остается простой. Парнас (Parnas, 1975) предложил, что модули должны быть организованы, таким образом, чтобы модуль не имел никакого знания внутренней структуры других модулей, Майерс (Myers, 1975) описал понятие силы модуля, а Йордан (Yourdon, 1975), свою очередь, четко описал понятие модульности и модульной организации программы в 1975. Эти факторы существенно повлияли на стоимость разработки и качество программного обеспечения.

Самая ранняя мера измерения программного обеспечения, которая обсуждается и используется до сих пор — LOC-мера. В 1974 Вольфертон (Wolverton) сделал одну из самых ранних попыток формально измерить производительность программиста, используя линии программного кода (LOC — lines of code). Он предложил использовать понятие человек-месяц, для того чтобы определить, продуктивность, то есть, сколько должен проработать один человек над созданием конкретного программного продукта и использовать LOCмеру, для определения числа строк, кода программы, которое должен набрать один программист. Основанием для LOC-меры послужило, то что длина программы является хорошим показателям характеристик программы типа надежности и легкости поддержки. Несмотря на это, или возможно даже из-за, простоты этой метрики, она была подвергнута серьезной критике. Актуальность линий кода, при оценки продуктивности используются для оценок производительности, как описано Валстоном (Walston) и Феликсом (Felix) во время предложения и представления контракта по программному обеспечению. В шестидесятых годах число линий исходного кода (SLOC-Source lines of code), считалось как число карт с 80 колонками. В 1983 Базили (Basili) и Гаченс (Hutchens) предложили, чтобы LOC-метрика стала основной метрикой, по отношению ко всем другим метрикам оценки. LOC-метрика была описана более чем в десяти тысячах статей.

В начале шестидесятых появляются первые модели оценки — Delphi и модель Нельсона SDC.

В 1975 году Коленс (Kolence) предложил ввести понятие «физика программного обеспечения», а в 1977 Халстед (Halstead) ввел понятие «наука о программном обеспечении» (software science). Основная идея была в том, чтобы применить научные методы к свойствам и структурам компьютерных программ. Теория Коленса соединяет такие традиционные меры измерения в науке как время оборота, доступность системы и время ожидания с традиционными мерами измерения в менеджменте как продуктивность, цена за единицу услуги, бюджет.

Одни из самых знаменитых измерений которые активно обсуждаются до сих пор и которые были предложены в середине семидесятых — это измерения Мак Кейб (McCabe, 1976) и Холстеда (Halstead, 1977). Мак Кейб вывел меру сложности программного обеспечения (software complexity measure) из теории графов, пользуясь определением циклического числа (cyclomatic number). Мак Кейб представил циклическое число как минимальное число путей в графе потока управления (flowgraph). Он обоснавал, что минимальное число путей определяет сложность программы (циклическую сложность (cyclomatic complexity)):

«Общая стратегия — измерить сложность программы подсчетом числа линейно независимых путей v (G), контролируя размер программы путем установления верхнего предела для v (G) и использовать циклическую сложность, как основу для проверяющей методологии.»

Модель измерений Халстеда основана на исходном коде программ. Халстед показал, что время затрачиваемое программой может быть выражено как функция от числа операндов и операторов. Модель Халстеда используется такими организациями как IBM, General Electrics и General Motors Corporation. Наиболее используемые меры Халстеда сегодня ;

мера длины, объема и сложности.

В 1979 Албрехт (Albrecht) предложил метод показателя функциональности (function point method), с целью разработки механизма предсказания усилий, сопряженных с разработкой программных систем. Метод был впервые опубликован в 1979 году. В 1984 году Альбрехт усовершенствовал свой метод и с 1986 года, в котором была сформирована Международная Ассоциация Пользователей показателей функциональностей (International Function Point User Group — IFPUG), было опубликовано несколько ревизий метода.

Чарльз Саймон (Charles Symon) разработал другой, аналогичный, но несколько более логичный и использующий более современную терминологию, метод показателя функциональности Mark II. В отличие от FPA IFPUG, MK II FPA использует единое понятие транзакции, имеющей вход, обработку и выход. MK II FPA принят в качестве национального стандарта Великобритании.

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

1.3 Зачем нужны модели и методы оценки затрат на разработку программного обеспечения?

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

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

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

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

Глава 2. Методы оценки трудозатрат на разработку ПО программный обеспечение информационный

2.1 Метод суждения эксперта (expert judgment method)

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

В общем говоря, техника группового консенсуса — Delphi — техника — наиболее подходящая. Преимущества и недостатки Delphi дополняют сильные и слабые стороны алгоритмических методов.

Этапы оценки этого метода:

1.Координатор представляет каждого эксперта со спецификацией и формой оценки.

2.Координатор назначает встречу группы, во время которой эксперты обсуждают возможные оценки с координатором и c друг другом.

3.Эксперты заполняют формы, анонимно

4.Координатор готовит и распределяет резюме оценок.

5.Координатор назначает встречу группы, особенное внимание будет уделено точкам зрения тех экспертов, оценки которых кардинально расходятся.

6.Эксперты заполняют формы по новой, анонимно, и шаги 4, 5 и 6 повторяются несколько раз.

Delphi — техника оказалась довольно успешной, комбинируя групповое обсуждение проблемы с анонимным суждением каждого эксперта.

Преимущества:

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

2. Эксперты могут грамотно оценить различные факторы влияния на проект такие как применение новых технологий, программных архитектур и языков.

Недостатки:

Этот метод не может быть измерен Сложно документировать факторы, используемые экспертами и экспертными группами.

Эксперт может быть предвзятым, слишком оптимистичным или наоборот пессимистичным, даже не смотря на групповое обсуждение проблемы

Метод суждения эксперта обычно должен дополняться другими методами оценки такими как алгоритмические методы.

Использованные источники при анализе:

1. Parametric cost estimation handbook — www.rspa.com/reflib/estimation.htm

2. A review of studies on expert estimation of software development effort, M. Jorgensen

2.2 Метод оценки по аналогии (estimating by analogy)

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

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

Этапы оценки этого метода:

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

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

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

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

Использованные источники при анализе:

1.Parametric cost estimation handbook — www.rspa.com/reflib/estimation.htm

2. «Effort Estimation Using Analogy» Martin Shepperd, Chris Schofield Barbara, Kitchenham;

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

Преимущества этого метода:

Этот метод фокусируется на системном уровне активностей таких как: интеграция, документация, управление конфигурациями, многие из которых игнорируются другими методами оценки. В нисходящем методе затратам на функции системного уровня придается значение.

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

Недостатки этого метода:

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

Этот метод не предоставляет детальной основы о суждениях, решениях или оценках.

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

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

Преимущества:

Этот метод позволяет группе разработчиков ПО проводить оценку наиболее традиционным образом и оценивать компоненты, к которым группа имеет предпочтение.

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

Недостатки:

Этот метод не рассматривает множество затрат на системном уровне (интеграция, управление конфигурациями), связанных с разработкой ПО.

Этот метод может быть не точен, потому что необходимая информация может оказаться недоступной на ранней фазе разработки.

Метод требует значительных затрат времени Могут возникнуть существенные затруднения в применении метода, если время и персонал ограничены.

Использованные источники при анализе:

1.Parametric cost estimation handbook — www.rspa.com/reflib/estimation.htm

2.4 Алгоритмические методы Алгоритмический метод разработан с целью применить математические уравнения для представления оценки затрат на разработку ПО. Эти математические уравнения основаны на исследованиях и используют на входах SLOC (линии исходного кода) число представляемых функций, языки, методологию разработки, уровни навыков, оценки рисков и т. д. Алгоритмические методы хорошо изучены и многие модели основываются на них, например модели COCOMO, Путнема и модели, основанные на функциональных точках.

Преимущества:

Этот метод дает возможность создавать повторяемые оценки.

В этом методе легко можно изменять входные данные, усовершенствовать и обобщать формулы.

Этот метод эффективен и может поддерживать семейство оценок или чувствительность анализа.

Недостатки:

Этот метод не применим к исключительным условиям таким как: невключенный персонал, невключенная команда и непредвиденное соответствие между уровнем навыков и задач.

Неточная входная информация может повлечь неточность оценки.

Некоторые факторы не могут быть просто измерены.

Использованные источники при анализе:

1.Parametric cost estimation handbook — www.rspa.com/reflib/estimation.htm

2. «Effort Estimation Using Analogy» Martin Shepperd, Chris Schofield Barbara, Kitchenham;

Глава 3. Модели оценки затрат на разработку ПО

3.1 Модель Путнэма жизненного цикла программного обеспечения — SLIM

В конце 1970 Лари Путнэм из QSM (Quantitative Software management) разработал модель жизненного цикла ПО — SLIM (Software Life-cycle model). SLIM была разработана на основе анализа жизненного цикла ПО, котором применялось распределение Рейлиха (Rayleigh distribution) для оценки усилий разработчиков за определенное время. Усилия потраченные собственно на разработку, как правило составляют 40 процентов от всего жизненного цикла. Подразумевается, что эта модель не должна применяться до стадий кодирования и проектирования.

Рис. Распределение Рейлиха

f (t)=E — усилия потраченные на разработку

t — время, потраченное на разработку Уравнение Путнэма:

SLOC = C E1/3 t4/3

SLOC — число строк кода

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

Оценка для С:

C=2000 (недостаточно)

C=8000 (хорошо)

C=12 000 (отлично)

E — общие усилия приложенные при разработке проекта, измеряется в человек за год.

t — время, которое понадобится для реализации проекта, измеряется в годах С определяется следующими факторами:

1) уровнем зрелости компании и используемыми практиками управления процессов

2) степенью применения хороших практик программирования

3) используемыми языками программирования

4) средствами разработки ПО

5) умением и опытом команды разработчиков

6) сложность, разрабатываемого продукта

Для оценки, приложенных усилий Путнэм предложил использовать уравнение, построенное на человеческой производительности (manpower-buildup equation):

D = E / t3

D — ускорение производительности работника (manpower acceleration), константа.

Значения D:

D=12.3 для новых много функциональных систем, работающих со множеством интерфейсов и взаимодействующих с другими системами.

D=15 для систем, не предназначенных для взаимодействия с другими системами

D=27 для изменения уже существующих систем Применяя уравнение построенное на человеческой производительности мы можем найти общее усилие E:

E = (SLOC / C)9/7? D4/7

Преимущества:

SLIM-модель проста и имеет небольшое число параметров.

Недостатки:

SLIM-модель практически бесполезна до стадии планирования и кодирования

SLIM-модель сильно зависит от технологического параметра.

SLIM-модель нечувствительна и не применима для небольших проеков.

На сегодняшний день QSM разработала набор средств основанный на SLIM-модели:

SLIM-Control, SLIM-Metrics, SLIM-estimate.

Использованные источники при анализе:

1. Software Development Cost Estimation Approaches — A Survey

Barry Boehm, Chris Abts, 2000

2. Software Cost Estimation: Metrics and Models, Kim Johnson

3. The Comparison of the Software Cost Estimating Methods, Liming Wu

3.2 Checkpoint

Checkpoint — это основанный на знаниях инструмент для оценки проектов, разработанный в SPR на основе работ Каперса-Джонса. Он содержит базу данных, включающую 8000 программных проектов и он сфокусирован на 4-х областях, которыми необходимо управлять, чтобы улучшать качество и продуктивность ПО. Checkpoint использует метод показателей функциональности для первоначального ввода размера. Эта модель сфокусирована на 3-х основных возможностях для поддержки всего жизненного цикла создания ПО.

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

Измерения: Checkpoint позволяет используя метрики проекта проводить сравнительный анализ производительности (методом прогона контрольных задач) (benchmark analysis), определять лучшие практики и совершенствовать внутренние базы знаний.

Оценивание (assessment): Checkpoint способствует сравнивает действительные и оцененные действия с учетом промышленных стандартов. Эта модель также оценивает сильные и слабые стороны среды программного продукта (software environment).

Использованные источники при анализе:

1. Software Development Cost Estimation Approaches — A Survey

Barry Boehm, Chris Abts, 2000

3.3 PRICE-S

Модель PRICE-S была изначально разработана в RCA для внутреннего использования с целью оценивания программных проектов в рамках лунной программы — Аполлон (Apollo moon program). Она была окончательно реализована в 1977 и используется для оценки некоторых проектов военного ведомства США (US DoD), NASA и ряда других правительственных организаций. Уравнения на которых основывается модель засекречены, хотя некоторые алгоритмы были опубликованы. PRICE-S модель состоит из трех подмоделей, которые оценивают графики работ и затраты на разработку ПО. Три основные подмодели и их функции:

Подмодель приобретение (The acquisition submodel): эта подмодель рассматривает графики работ и затраты. Модель описывает все типы разработки ПО, включая бизнес системы, системы управления и контроля, авиа и космические системы. PRICE-S обращает внимание на методы разработки ПО, доступные на сегодняшний день такие как объектно-ориентированное программирование, реинжениринг, генерация кода, спиральная разработка, быстрая разработка и измерения продуктивности ПО.

Подмодель-измерение (The sizing model): эта подмодель облегчает оценивание размера ПО, которое должно быть разработано. Измерение может быть произведено в числе строк кода, в функциональных точках или в предсказывающих объектных точках (Predictive Object Point — POP).

Подмодель жизненный цикл затрат (The Life-cycle Cost Submodel): эта подмодель используется для быстрого и легкого оценивания во время стадий сопровождения и поддержки ПО. Используется вместе с подмоделью приобретения, в которой определяются затраты на разработку и планирование.

Разработкой инструментов на основе этой модели занимается компания PRICE Systems которая уже создала инструмент Foresight 2.0 для оценки времени, затрат и усилий необходимых для реализации коммерческих и невоенных правительственных проектов.

Использованные источники при анализе:

1. Software Development Cost Estimation Approaches — A Survey

Barry Boehm, Chris Abts, 2000

2. Parametric cost estimation handbook — www.rspa.com/reflib/estimation.htm

3.4 SELECT Estimator

SELECT Estimator разработан компанией SELECT Software Tools и представляет часть набора интегрированных продуктов разработанных для проведения моделирования на элементной основе. Компания была основана в 1988 г. в Англии.

SELECT Estimator был выпущен в 1988 г., с целью разработки широко масштабных распределенных систем. Он объектно-ориентирован и основывает свои оценки на базе бизнес-объектов и компонент. Этот инструмент предполагает разбиение на части жизненного цикла (но может быть ориентирован под другие модели развития).

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

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

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

Техники объектной матрицы, начинается с измерения размера трудозатрат в человеко-днях обычно необходимых для разработки частей данного проекта. Эта оценка трудозатрат учитывает все виды деятельности необходимых для нормального жизненного цикла разработки программного обеспечения, но не учитывает ничего касательно характеристик проекта или используемой технологии, что может квалифицироваться как оценка трудозатрат. Предварительно определенные профили деятельности, охватывающие планирование, анализ, разработку, программирование тестирование, интеграцию и оценку используются в соответствии с типом элемента проекта, который разделяет обычные трудозатраты в трудозатраты по виду деятельности. (Эти профили деятельности основаны на собранных и поддерживаемых Object Factory проектных данных.)

Основная оценка трудозатрат производится, при помощи «квалификаторов» для добавления или извлечения процентного соотношения из каждого отдельно оцененного вида деятельности.

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

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

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

SELECT Estimator уточняет оценку затрат посредством объектной матрицы, повышая качество факторов квалификатора и технологических факторов.

Сам инструмент состоит из двух модулей, архитектора проекта и оценщика (SELECT 1998).

Рис. Связь между оценщиком и архитектором проекта Архитектор проекта (Project Architect): этот модуль, который объединяет и квалифицирует большинство элементов проекта. Эта информация затем поступает в модуль оценки (Estimator) для оценки сроков и стоимости разработки. Измерения выполняются в рамках следующих элементов:

Приложения (Applications) — подсистемы ПО, поддерживающие подраздел бизнеса.

Классы (Classes) — представление бизнес-концепций.

Варианты использования (Use cases) — бизнес-требования, определенные на основании точки зрения пользователя.

Пакеты (Packages) — поддерживающие рабочие среды с четко определенной ответственностью за определенные разделы инфраструктуры.

Компоненты (Components) — абстракции служб нижнего уровня бизнеса (services).

Службы (Services) — обычные элементы системы, доступные через приложения и компоненты.

Квалификаторы элементов ПО, определяемые по шкале от нижнего до верхнего уровней включают:

Сложность (Complexity) — охватывая вычисления и количество связей между компонентами системы.

Повторное использование (Reuse) — охватывает COTS и другое существующее ПО.

Универсальность (Generality) — случай, когда ПО должно быть разработано для повторного использования.

Технология (Technology) — выбор языка программирования.

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

Оценщик (Estimator):

Этот модуль использует оценку трудозатрат произведенных архитектором проекта для оценки графика работ и затрат. Другие входные данные включают размер команды (Team Size) и уровни квалификации (Skill Levels) (делящиеся как новичок, опытный специалист и эксперт); количество продуктивных рабочих дней за месяц и процент случайности; уровня квалификации разработчиков. Конечные выходные данные — общие трудозатраты в человеко-днях, длительность работы в месяцах и общая стоимость разработки.

Использованные источники при анализе:

1. Software Development Cost Estimation Approaches — A Survey

Barry Boehm, Chris Abts, 2000

2. Parametric cost estimation handbook — www.rspa.com/reflib/estimation.htm

3.5 Модель COCOMO II

Модель оценивания затрат COCOMO II является развитием иерархической модели Б. Боэма COCOMO и предназначена для оценивания трудовых затрат (трудоемкости) на разработку ПО. Эта модель использует сочетание экспертного и алгоритмического методов оценивания и учитывает современный уровень программной инженерии (характеристик ПО, технологий разработки, организации процесса разработки). В настоящее время это наиболее полная, конструктивная и широко применяемая модель оценивания трудозатрат.

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

Предварительная модель (Application Composition Model). Обеспечивает предварительную оценку трудозатрат на ПС на ранних стадиях разработки. Модель предназначена для оценки трудоемкости прототипирования, а также разработки ПО с использованием интегрированных сред (ICASE).

Предпроектная модель (Early Design Model). Обеспечивает предварительную оценку трудозатрат на разработку как ПО в целом, так и отдельных программных компонентов (подсистем) на предпроектных стадиях ЖЦ. Может применяться для технико-экономического обоснования затрат на создание ПО, а также для распределения затрат по стадиям разработки.

3. Детальная модель (Post Architecture Model). Уточняет оценку, выполненную по предпроектной модели. Обеспечивает поуровневую оценку трудозатрат на разработку ПО — от программных компонентов до программных модулей. Может применяться на стадиях проектирования и разработки ПО, а также при сопровождении.

В числе достоинств модели СОСОМО II следует отметить: определенность, точность, объективность, детальность, простота применения.

Недостатки модели COCOMOII:

Оценка трудозатрат по Предварительной модели:

Оценка трудозатрат по модели выполняется на уровне программной системы в целом.

Расчет трудозатрат на разработку ПО производится по следующему алгоритму.

1. Вычисляется функциональный размер ПО. Для этого сначала определяется общий функциональный размер ПО (ОР) по всем составляющим ее информационно-функциональным объектам (экранам, отчетам, модулям), включая все объекты, которые будут использоваться в системе повторно.

Затем определяется функциональный размер разрабатываемых компонентов ПО (NOP) по формуле

NOP = (OP — (100 — %Reuse))/100

где %Reuse — доля (в процентах) повторно используемых объектов (экранов, отчетов и модулей).

2. Оценивается уровень производительности, PROD, как среднее атрибутов «Опыт работы и квалификация разработчика» и «Зрелость и возможности ICASE»

3. Трудозатраты на разработку вычисляются в человеко-месяцах (чел-мес.) по формуле:

Т = NOP/PROD

Вычисление трудозатрат для предпроектной модели:

Атрибут приложенных трудозатрата — EAF (effort adjustment factor) вычисляется на основе 15 атрибутов затрат, которые группируются в четыре категории: продукт, компьютер, персонал и проект. Каждый из этих оценивается по шести бальной шкале на основе имеющихся таблиц.

Затем все значения из этих таблиц перемножаются и получаем EAF.

Основное уравнение для подсчета трудозатрат для предварительной модели:

E = a? KLOC?EAF,

где a = 2,45 константа, полученная по результатам статистического анализа фактических данных более 80 реальных проектов

KLOC — число линий кода Вычисление трудозатрат для детальной модели:

Детальная модель используется на стадии внедрения и сопровождения. Показатели функциональности или LOC используются для измерения. Детальная модель включает набор из 17 атрибутов и 5 факторов, определяющих размер проекта: новизна проекта жесткость проекта (согласованность) управление риском/ архитектурой технологическая зрелость процесса разработки определяются при помощи таблиц.

Уравнение трудозатрат для детальной модели:

E = a? KLOCb?EAF

где a = 2,55 константа, полученная по результатам статистического анализа фактических проектов

b = 1.01 + 0.01 ?? Wi

Wi — i-ый фактор

Использованные источники при анализе:

1. Software Development Cost Estimation Approaches — A Survey

Barry Boehm, Chris Abts, 2000

2. Software Cost Estimation: Metrics and Models, Kim Johnson

3. The Comparison of the Software Cost Estimating Methods, Liming Wu

4. Boehm, B.W., Abts, C., Clark, B., and Devnani-Chulani. S. (1997). COCOMOII Model Definition Manual.

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

Используемый источник:

1.Boehm, B.W. «An Overview of COCOMO2.0 Software Cost Model «

Заключение

В своей курсовой работе я осветил основные методы: алгоритмические методы (algorithmic methods), оценка по аналогии (estimating by analogy), методу суждения эксперта (expert judgment method), метод цены, чтобы выиграть метод (price to win method), нисходящий метод (top-down method) и метод восходящий (bottom-up method) и модели и инструменты для оценки трудозатрат при разработке ПО, показал каким образом можно измерить программный продукт (SLOC, FP), показал на каких этапах разработки можно применять ту или иную модель и описал как лучше всего себя вести при оценки трудозатрат проекта. В связи с отсутствием инструментов оценки трудозатрат было невозможно провести практический анализ.

Использованные источники

1."Экономическая роль индустрии информационных технологий", статья с www.msdn.ru

2."Microsoft и развитие национальной экономики", статья с www.msdn.ru

3. «Информационные и телекоммуникационные технологии: преобразования в Европе», Наука и техника, 2004 г.

4. Parametric cost estimation handbook — www.rspa.com/reflib/estimation.htm

5. A review of studies on expert estimation of software development effort, M. Jorgensen

6. Software Development Cost Estimation Approaches — A Survey

Barry Boehm, Chris Abts, 2000

7. Software Cost Estimation: Metrics and Models, Kim Johnson

8. The Comparison of the Software Cost Estimating Methods, Liming Wu

9. Boehm, B.W., Abts, C., Clark, B., and Devnani-Chulani. S. (1997). COCOMOII Model Definition Manual.

10.Shaw, M. (1995). Cost and Effort Estimation. CPSC451 Lecture Notes. The University of Calgary.

11. http://www.sunset.usc.edu/research/COCOMOII/cocomo_main.htm

12. Full Function Points: Counting Practices Manual / St-Pierre D., Maya M., Abran A., Desharnais J.-M., Bourque P.// Technical Report 1997;04, Quebec, Montreal, Canada (www.lrgl.uqam.ca/ffp.html).

13. Reifer D.J. Web development: Estimating Quick-to-Market Software // IEEE Software. — nov/dec. — 2000. — P. 57−54.