4)провести сравнительный анализ полученных по трем предыдущим
пунктам результатов и оценить стоимость проекта, используя данные о стоимости человеко-месяца из первого задания.

Дополнительные задачи

1. На основе уравнений базовой СОСОМО для систем распространенного типа построить зависимость трудоемкости разработки программного проекта от его размера при изменении объема кода от 10 до 120 ТСИК.

2. На основе уравнений базовой СОСОМО для систем распространенного типа построить зависимость сроков разработки программного проекта от его размера при изменении объема кода от 10 до 120 ТСИК.

3. На основе уравнений базовой СОСОМО для систем распространенного типа построить зависимость сроков разработки программного проекта от затрат труда при изменении его значений от 10 до 200 ЧМ.

4. На основе уравнений базовой СОСОМО для систем распространенно­го типа построить зависимость средней производительности труда от размера программного средства при изменении объема его кода от 10 до 120 ТСИК.

5. На основе уравнений базовой СОСОМО для систем распространенного типа построить зависимость средней штатной численности от его размера при изменении объема кода от 10 до 120 ТСИК.

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

12.3.4. Метод функциональных точек

Общее описание метода оценки. Функционально-ориентированные метрики – это косвенные меры для оценки программного продукта и процесса его разработки; они фокусируют внимание на "функциональности" программного изделия или "полезности" программы. В 1979 г был предложен подход к измерению производительности труда разработчиков программного обеспечения , названный методом функциональной точки (FP –function point method).

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

Порядок расчета трудоемкости разработки ПО:

определение количества и сложности функциональных типов приложения;

определение количества связанных с каждым функциональным типом элементарных данных (DET), элементарных записей (RET) и файлов типа ссылок (FTR);

определение сложности (в зависимости от количества DET, RET и FTR);

подсчет количества функциональных точек приложения;

подсчет количества функциональных точек с учетом общих характеристик системы

оценка трудоемкости разработки (с использованием различных статистических данных).

В состав функциональных типов (function type) включаются следующие элементы приложений разрабатываемой системы:

внутренний логический файл (Internal Logical File, ILF) - идентифицируемая совокупность логически взаимосвязанных записей данных, поддерживаемая внутри приложения посредством элементарного процесса;

внешний интерфейсный файл (External Interface File, EIF) - идентифицируемая совокупность логически взаимосвязанных записей данных, передаваемых другому приложению или получаемых от него и поддерживаемых вне данного приложения;

входной элемент приложения (External Input, El) - элементарный процесс, связанный с обработкой входной информации приложения - входного документа или экранной формы. Обрабатываемые данные могут соответствовать одному или более ILF;

выходной элемент приложения (External Output, EO) - элементарный процесс, связанный с обработкой выходной информации приложения - выходного отчета, документа, экранной формы;

внешний запрос (External Query, EQ) - элементарный процесс, состоящий из комбинации «запрос/ответ», не связанной с вычислением производных данных или обновлением ILF (базы данных).

Информационные параметры определяются следующим образом.

·Число входов пользователей. Подсчитывается каждый вход пользо­вателя, который дает отличающиеся от других данные, ориентированные на определенное приложение. Входы должны отличаться от запросов пользова­телей, которые подсчитываются отдельно.

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

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

·Число Файлов. Подсчитывается количество главных логических фай­
лов (логических групп данных), которые могут входить в состав достаточно большой базы данных.

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

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

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

· Нет влияния - 0.

· Случайное влияние -1.

· Умеренное влияние - 2.

· Среднее влияние - 3.

· Значительное влияние - 4.

· Существенное влияние - 5.

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

1. Требует ли система надежного резервирования и последующего
восстановления после отказа?

2. Требуется ли передача данных?

3. Имеются ли функции распределенной обработки?

4. Критична ли производительность программного продукта?

5. Будет ли система функционировать в существующей или в более сложной операционной обстановке?

6. Требует ли система онлайнового ввода данных ?

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

8. Осуществляется ли обновление главного файла в онлайновом режиме?

9. Являются ли сложными входы, выходы, файлы или запросы?

10. Являются ли сложными алгоритмы обработки данных?

11. Предназначены ли созданные программы для повторного использования?

12. Включены ли в проект работы по вводу в действие и по адаптации системы?

13. Предусматривает ли конфигурация системы ее установку в различных организациях?

14. Предусмотрено ли в проекте удобство работы пользователей и простота внесения изменений?

После анализа и экспертного определения каждого из перечисленных коэффициентов вычисляется окончательное значение числа функциональных точек.

Пример 4. Определение числа функциональных точек для программного продукта

Методические указания к выполнению примера 4.

На основе требований пользователя и схем потоков данных будущей программной системы провести подсчет числа функциональных точек ФТ. С этой целью провести анализ информационной области проектируемого программного продукта и определить пять ее информационных параметров (см. таблицу 7), оценив важность каждого. Проанализировать и оценить каждый из перечисленных выше четырнадцати факторов, характеризующих особенности функционирования разрабатываемой информационной системы .

Развитие функционального подхода.

Мера функциональной точки, первоначально предложенная для применения к приложениям в области деловых информационных систем, была затем распространена с некоторыми модификациями на другие приложения. Развитие этого метода оценки программных продуктов получило название метода характерных точек (feature points). Этот метод может быть применен для оценки проектов более широкого круга приложений. Мера характерных точек особенно пригодна для приложений с высокой степенью алгоритмической сложности, которая присуща системам реального времени, управленческим процессам и встроенным системам, поэтому именно для них целесообразно применять меру характерной точки (XT).

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

Следует отметить, что оба метода (ФТ и XT) отражают одну и туже сторону программного продукта - его "функциональность" и "полезность". И тот и другой подходы дают близкие результаты для обычных инженерных вычислительных задач и информационных систем. Для более сложных систем осо­бенно реального времени итоговое значение для XT на 20-35% выше, чем итог, определенный с использованием ФТ.

Согласование размеро-ориентированных и функционально-ориентированных подходов к оценке программных проектов.

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

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

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

Таблица 12.3.10 – Соотношение метрик функциональных точек и строк кода

Язык программирования

Ассемблер

Объектно-ориентированные языки

Языки 4-го поколения

Генераторы кода

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

12.3.5 Подходы к оценке производительности труда группы разработчиков

В небольших проектах разработки программных средств один человек анализирует требования, проектирует программное изделие, кодирует, проводит тестирование и отладку программ, осуществляет интеграцию модулей и выполняет комплексные испытания изделия. Когда размер проекта возрастает, в его выполнение включается все большее число людей. Трудно предста­вить себе разработку проекта трудоемкостью 10 человеко-лет, которую выполнял бы один исполнитель.

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

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

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

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

Второй подход основан на использовании для расчетов установленной эмпирической закономерности - производительность труда отдельного работника падает пропорционально корню кубическому из n. Это так называемый закон Филиппа.

Третий подход использует модель Путнема, в которой (также на основании опытных данных) представлена взаимосвязь основных параметров программного проекта. В результате использования этой модели также появляется возможность выявить зависимость производительности труда от числа исполнителей n.

Ниже представлено описание использования этих трех методик для оценки производительности труда группы разработчиков:

учет взаимосвязей людей в группе (две модификации);

учет закона Филиппа при оценке производительности труда;

использование модели Путнема для оценки параметров проектов при отклонениях от оптимальных сроков разработки.

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

12.3.5.1. Учет числа взаимосвязей между разработчиками в группе

Очевидно, что при работе в коллективе разработчики должны обсуждать и согласовывать возникающие вопросы друг с другом. В результате общее число взаимосвязей в группе равно числу сочетаний из n по 2.

Если в качестве параметра модели использовать относительные затраты времени на одну информационную взаимосвязь по отношению к общему времени работы разработчика, то для ряда значений этого параметра k (например, 0,01, 0,05), можно оценить общую производительность труда группы и трудоемкость разработки проекта.

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

Представляет интерес определение оптимального состава группы, когда производительность группы будет максимальной, а также определение количества исполнителей, при котором производительность труда группы упадет до 0. Очевидно, что эти значения будут определяться величиной параметра k.

Пример 5.1. Определение производительности труда группы взаимодействующих исполнителей

Методические указания к выполнению примера 5.1.

Будем полагать, что группа состоит из заданного числа n разработчиков, между которыми осуществляются взаимосвязи. Число таких попарных связей определяется как число сочетаний из л по 2 и равно n*(n-1)/2. Принимая за k относительную долю времени (по отношению к общему времени работы), затрачиваемую на одну взаимосвязь, определить зависимость средней производительности труда одного работника и суммарной производительности группы, длительности и трудоемкости разработки проекта от числа работников в группе n. Определить также оптимальное значение числа работников, обеспечивающее максимальную общую производительность труда группы. Расчеты провести при нескольких значениях параметра k. Данные о производительности труда одного исполнителя и о размерах программного продукта взять из первого задания.

Последовательность выполнения задания

1.Назовем время, затрачиваемое на разработку программного изделия, полезным временем, т. е. будем вычитать из общего времени работы исполни­теля Т1 ту часть k, которая тратится на обсуждение и согласование возникаю­щих проблем с другими членами группы. Тогда легко показать, что полезное время работы одного сотрудника равно

а полезное время работы группы

2.Формулы, приведенные в предыдущем пункте, позволяют определить изменение производительности труда одного исполнителя от размера группы. Очевидно, что с ростом численности группы производительность труда отдельного исполнителя ПТ1 будет уменьшаться в соответствии с формулой

На основе этой формулы построить зависимость ПТ1 от n для ряда значений параметра k. Для каждого выбранного значения параметра k определить размер группы, при котором производительность отдельного работника становится равной 0.

3.Зная производительность труда одного работника, определить суммарную производительность труда группы ПТС как ПТС=n*Т1Т1.

Построить зависимость суммарной производительности труда от числа работников в группе при тех же значениях параметра k.

4.Построить зависимость длительности разработки программного про­дукта от изменения численности группы для принятых значений параметра k.

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

12.3.5.2. Связи каждого участника группы с остальными

Общее описание метода оценки производительности.

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

Пример 5.2 . Определение производительности труда группы исполнителей при взаимодействии каждого с остальными

Методические указания к выполнению примера 5.2

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

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

12.3.5.3. Применение модели Филиппа

Общее описание метода.

Применив закона Филиппа в качестве модели для оценки изменения производительности разработчика при работе в группе исполнителей довольно близко соответствует результатам, полученным на практике. В соответствии с этим законом производительность труда отдельного разработчика в группе уменьшается в корень кубический из n (численности группы).

Таким образом, этот подход позволяет определить в зависимости от размера группы:

1)производительность труда одного исполнителя, работающего в группе как

2) общую суммарную производительность труда группы, как

3)трудоемкость разработки проекта как

4)длительность разработки проекта как

Пример 5.3 . Определение параметров программного проекта с использованием модели производительности группы

Методические указания к выполнению примера 5.3.

Заданы размер программного продукта РП (строк кода) и средняя производительность труда СПТ (строк кода на человеко-месяц) отдельного разработчика. Определить зависимость суммарной производительности труда, трудоемкости и длительности разработки программного продукта от числа разработчиков в группе.

Последовательность выполнения задания.

1. Определить суммарную производительность труда группы из n человек как полагая, что производительность одного человека в группе ПТ1 уменьшается в корень кубический из n раз по сравнению со сред­ней производительностью труда отдельного разработчика. Построить зависимость ПТ1 и ПТС от n.

2.Определить трудоемкость разработки программного продукта как

И построить зависимость трудоемкости разработки от числа разработчиков n.

3.Определить длительность разработки программного продукта как

И построить зависимость длительности разработки от числа разработчиков n в группе.

Дополнительные задачи.

1. Построить в виде графика функцию относительного (по сравнению с одним исполнителем) увеличения суммарной производительности труда труппы в зависимости от числа участников разработки n.

2. Построить в виде графика функцию относительного (по сравнению с одним исполнителем) увеличения трудоемкости разработки программного продукта группой разработчиков в зависимости от числа участников разработки n.

3. Построить в виде графика функцию относительного (по сравнению с одним исполнителем) сокращения длительности разработки программного продукта группой разработчиков в зависимости от числа участников разработки n.

4. Провести сопоставительный анализ относительного (по сравнению с одним исполнителем) увеличения трудоемкости разработки программного продукта группой разработчиков в зависимости от числа участников разработки n для случая попарных взаимосвязей между участниками группы и при использовании закона Филиппа. Расчеты провести для двух значений параметра k.

5. Провести сопоставительный анализ относительного (по сравнению с одним исполнителем) увеличения трудоемкости разработки программного продукта группой разработчиков в зависимости от числа участников разработ­ки n для случая информационных взаимосвязей каждого исполнителя с остальными членами группы и при использовании закона Филиппа. Расчеты провести для двух значений параметра k.

6. Имеются данные о средней производительности труда одного работника СПТ, численности группы ШЧ и о размерах разрабатываемого программного продукта РП. Определить, как изменится длительность разработки проекта ДР, если по истечении половины времени разработки штатная численность будет увеличена в 1,5 раза.

12.3.5.4. Применение модели Путнема

Общее описание метода.

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

Модель Путнема связывает трудозатраты (ТР) с длительностью разра­ботки проекта (ДР) и размером программного продукта (РП) следующей фор­мулой:

ТР - усилия на разработку проекта (человеко-лет);

РП - число строк кода;

ДР - хронологическое время разработки проекта (годы);.

С - технологическая константа, отражающая технологический уровень в разработке проекта (на практике С=2000 для низкого уровня разработки, С=8000 для хорошей методологии и средств разработки и С более 11000 - для исключительно высокого уровня).

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

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

Пример 5.4. Определение характера изменения параметров про­граммного проекта при отклонениях от номинальной длительности разработки с использованием модели Путнема

Методические указания к выполнению примера 5.4.

Заданы или были определены с использованием модели СОСОМО для конкретного программного продукта значения трудоемкости разработки ТР (человеко-месяцев), длительность разработки ДР (месяцев) и соответствующая им штатная численность разработчиков ШЧ (человек). Приняв эти значе­ния за исходные данные для расчета, определить, как будет изменяться по отношению к этим условиям трудоемкость и требуемая штатная численность при изменении сроков разработки программного продукта. Диапазон изменения длительности разработки ДР относительно исходного (номинального) значения задать в диапазоне от 0.5 до 1.5 с интервалом 0.1.

Последовательность выполнения задания.

1. Для определения исходных данных для оценки влияния длительности разработки на трудоемкость и другие параметры программного продукта можно воспользоваться экспертной оценкой размера продукта РП. На основе дан­ных о числе строк кода с помощью ресурсной модели КОМОСТ определить трудоемкость ТР (в человеко-годах) и длительность разработки ДР в (годах) проекта для условий близких к оптимальным. Одновременно следует опреде­лить штатную численность группы разработчиков и их производительность труда.

2. На основе данных о ТР и ДР по формуле Путнема определить кон­станту А, равную

3. Изменяя значение длительности разработки программного проекта ДР относительно исходной оценки, определить относительное изменение трудоемкости ТР (относительные параметры определять относительно исходных данных, подсчитанных по СОСОМО). Диапазон изменения длительности разработки проекта принять соответствующим заданию.

4. Изменяя значение длительности разработки программного проекта ДР относительно исходного определить относительное изменение штатной численности разработчиков ШЧ. Диапазон изменения длительности разработ­ки проекта принять соответствующим заданию 8.

5. Изменяя значение длительности разработки программного проекта ДР относительно исходного, определить относительное изменение средней производительности труда разработчика в группе ПТ1. Диапазон изменения длительности разработки проекта принять соответствующим заданию.

12.4. Примеры выбора метода и расчета оценок эффективности

12.4.1. Информационной системы управления инновационным учебным заведением

Необходимо разработать информационную систему управления инновационным учебным заведением. Для оценки эффективности разработки выбран функционально-стоимостной анализ ФСА (англ. ABC – Activity Based Costing).

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

Анализ внутренних функций различных объектов системы производится путем построения функциональной модели (ФМ). ФМ представляет собой структуру рассматриваемой системы без привязки к каким-либо материальным носителям (узлам, блокам, операциям технологических или производственных процессов, подразделениям предприятий и объединений).

Именно при разработке ФМ определяются излишние функции, выявляются основные причинно-следственные связи рассматриваемых объектов ФСА.

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

Основные функции определяют принцип действия объекта и включают функции ввода энергии, информации, их преобразования и вывода. Вспомогательная функция обеспечивает реализацию одной или нескольких основных, а также второстепенных внешних функций изделия. Нейтральные функции в построении ФМ не участвуют (рисунок 12.4.1.1).

Рисунок 12.4.1.1 – Функциональная модель

Для определения значимости функций строятся матрицы парного сравнения (таблицы 12.4.1.1 – 12.4.1.5).

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

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

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

Таблица 12.4.1.1 – Матрица парного сравнения функций 1-го уровня

Индекс функции

Количество

предпочтений

Значимость

Итого

Таблица 12.4.1.2 – Матрица парного сравнения функций 2-го уровня (F1)

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

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

В методе различаются следующие типы транзакций (Таблица 9):

  • EI (external inputs) - внешние входные транзакции, элементарная операция по обработке данных или управляющей информации, поступающих в систему из вне.
  • EO (external outputs) - внешние выходные транзакции, элементарная операция по генерации данных или управляющей информации, которые выходят за пределы системы. Предполагает определенную логику обработки или вычислений информации из одного или более ILF.
  • EQ (external inquiries) - внешние запросы, элементарная операция, которая в ответ на внешний запрос извлекает данные или управляющую информацию из ILF или EIF.

Таблица 9. Основные отличия между типами транзакций. Легенда: О - основная; Д - дополнительная; NA - не применима.

Оценка сложности транзакции основывается на следующих ее характеристиках:

  • FTR (file type referenced) - позволяет подсчитать количество различных файлов (информационных объектов) типа ILF и/или EIF модифицируемых или считываемых в транзакции.
  • DET (data element type) - неповторяемое уникальное поле данных. Примеры. EI: поле ввода, кнопка. EO: поле данных отчета, сообщение об ошибке. EQ: поле ввода для поиска, поле вывода результата поиска.

Для оценки сложности транзакций служат матрицы, которые представлены в Таблица 10 и Таблица 11.

Таблица 10. Матрица сложности внешних входных транзакций (EI)

Оценка транзакций в не выровненных функциональных точках (UFP) может быть получена из матрицы (Таблица 12)

Таблица 12. Сложность транзакций в не выровненных функциональных точках (UFP)

В качестве примера, рассмотрим оценку управляющей транзакции (EI) для диалогового окна, задающего параметры проверки орфографии в MS Office Outlook (Рисунок 40).

Рисунок 40. Диалоговое окно, управляющее проверкой орфографии в MS Office Outlook

Каждый "Check box" оценивается, как 1 DET. Выпадающий список - 1 DET. Каждая управляющая кнопка должна рассматриваться как отдельная транзакция. Например, если оценивать управляющую транзакцию по кнопке «OK», то, для данной транзакции мы имеем 1 FTR и 8 DET. Поэтому, согласно матрице (Таблица 10), мы можем оценить сложность транзакции, как Low. И, наконец, в соответствие с матрицей (Таблица 12), данная транзакция должна быть оценена в 3 не выровненных функциональных точек (UFP).

Определение суммарного количества не выровненных функциональных точек (UFP)

Общий объем продукта в не выровненных функциональных точках (UFP) определяется путем суммирования по всем информационным объектам (ILF, EIF) и элементарным операциям (транзакциям EI, EO, EQ).

Определение значения фактора выравнивания (FAV)

Помимо функциональных требований на продукт накладываются общесистемные требования, которые ограничивают разработчиков в выборе решения и увеличивают сложность разработки. Для учета этой сложности применяется фактор выравнивания (VAF). Значение фактора VAF зависит от 14 параметров, которые определяют системные характеристики продукта:

1. Обмен данными (0 - продукт представляет собой автономное приложение; 5 - продукт обменивается данными по более, чем одному телекоммуникационному протоколу).

2. Распределенная обработка данных (0 - продукт не перемещает данные; 5 - распределенная обработка данных выполняется несколькими компонентами системы).

3. Производительность (0 - пользовательские требования по производительности не установлены; 5 - время отклика сильно ограничено критично для всех бизнес-операций, для удовлетворения требованиям необходимы специальные проектные решения и инструменты анализа.

4. Ограничения по аппаратным ресурсам (0 - нет ограничений; 5 - продукт целиком должен функционировать на определенном процессоре и не может быть распределен).

- транзакций не много, без пиков; 5 - число транзакций велико и неравномерно, требуются специальные решения и инструменты).

6. Интенсивность взаимодействия с пользователем (0 - все транзакции обрабатываются в пакетном режиме; 5 - более 30% транзакций - интерактивные).

7. Эргономика (эффективность работы конечных пользователей) (0 - нет специальных требований; 5 - требования по эффективности очень жесткие).

8. Интенсивность изменения данных (ILF) пользователями (0 - не требуются; 5 - изменения интенсивные, жесткие требования по восстановлению).

9. Сложность обработки (0 - обработка минимальна; 5 - требования безопасности, логическая и математическая сложность, многопоточность).

10. Повторное использование (0 - не требуется; 5 - продукт разрабатывается как стандартный многоразовый компонент).

11. Удобство инсталляции (0 - нет требований; 5 - установка и обновление ПО производится автоматически).

12. Удобство администрирования (0 - не требуется; 5 - система автоматически самовосстанавливается).

13. Портируемость (0 - продукт имеет только 1 инсталляцию на единственном процессоре; 5 - система является распределенной и предполагает установку на различные «железо» и ОС).

14. Гибкость (0 - не требуется; 5 - гибкая система запросов и построение произвольных отчетов, модель данных изменяется пользователем в интерактивном режиме).

14 системных параметров (degree of influence, DI) оцениваются по шкале от 0 до 5. Расчет суммарного эффекта 14 системных характеристик (total degree of influence, TDI) осуществляется простым суммированием:

TDI = ∑ DI

Расчет значения фактора выравнивания производится по формуле

VAF = (TDI *0.01) + 0.65

Например, если, каждый из 14 системных параметров получил оценку 3, то их суммарный эффект составит TDI = 3 * 14 = 42. В этом случае значение фактора выравнивания будет: VAF = (42 * 0.01) + 0.65 = 1.07

Расчет количества вьровненных функциональных точек (AFP)

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

AFP = UFP * VAF.

Она учитывает только новую функциональностсть, которая реализуется в продукте. Проект разработки продукта оценивается в DFP (development functional point) по формуле:

DFP = (UFP + CFP) * VAF,

где CFP (conversion functional point) - функциональные точки, подсчитанные для дополнительной функциональности, которая потребуется при установке продукта, например, миграции данных.

Проект доработки и совершенствования продукта оценивается в EFP (enhancement functional point) по формуле:

EFP = (ADD + CHGA + CFP) * VAFA + (DEL* VAFB),

  • ADD - функциональные точки для добавленной функциональности;
  • CHGA - функциональные точки для измененных функций, рассчитанные после модификации;
  • VAFA - величина фактора выравнивания рассчитанного после завершения проекта;
  • DEL - объем удаленной функциональности;
  • VAFB - величина фактора выравнивания рассчитанного до начала проекта.

Суммарное влияние процедуры выравнивания лежит в пределах ±35% относительно объема рассчитанного в UFP.

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

Определение границ программного средства

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

Идентификация и оценка функциональности даннных (ILF, EIF)

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

Число типов элементов данных (DET) внутреннего логического файла равно шести:

1. n - количество строк в матрице. Количество строк равно количеству столбцов, так как расчет ведется для так называемых квадратных матриц.

2. Mas - заданная матрица.

3. - заданная точность.

4. x 0 - начальное приближение.

5. - результат вычислений - максимальное собственное число заданной матрицы.

6. k - количество итераций, необходимых для вычисления максимального собственного числа матрицы с заданной точностью.

Число типов элементов записей (RET) для внутреннего логического файла равно четырем:

1. Mas - матрица.

2. x 0 - вектор.

3. n, k - целые числа.

4. , - вещественные числа.

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

Внешних интерфейсных файлов (ELF) данное программное средство не имеет.

Идентификация и оценка функциональности транзакций (EI, EO, EQ)

Данное программное средство предусматривает два внешних ввода (EI): ввод данных с клавиатуры и ввода данных из файла.

Для ввода данных с клавиатуры число типов элементов данных (DET) равно пяти: Mas, x 0 , n, а также кнопка «Ввести данные с клавиатуры». Количество используемых типов (FTR) равно пяти.

Уровень сложности для данного типа ввода определен как высокий.

Для ввода данных из файла результаты аналогичны результатам для ввода с клавиатуры, за исключение использования символьной строки с именем файла и соответствующей кнопки для загрузки данных. То есть, DET = 6, FTR=5. Уровень сложности для данного типа ввода определен как высокий.

Данное программное средство имеет только один внешний запрос (EQ) - запрос на корректность введенных данных. Для этого необходимы переменные Mas, x 0 , n, их значения проверяются соответственно: для матрицы - проверка на занесение недопустимых символом - знаков либо букв, для начального приближения - на равенство нулю, занесение недопустимых символов, для размера матрицы - принадлежность к заданным пределам, для точности - ограничение по порядку. Таким образом, DET=4, FTR=3. Информация на выходе данного запроса - «Введенная информация корректна» или «Введенная информация некорректна». То есть, DET=FTR=1. Таким образом, уровень сложности внешнего запроса определен как средний.

Данное программное средство предусматривает два внешних вывода: вывод данных в файл и вывод данных на экран. Для вывода данных на экран число типов элементов данных DET равно четырем: заданная точность, полученное максимальное собственное число матрицы, количество итераций, а также кнопка «Вычислить результаты». Количество используемых типов FTR равно трем. Таким образом, уровень сложности вывода на экран определен как средний.

Для записи данных в файл количество типов элементов данных DET равно пяти: максимальное собственное число, заданная точность, количество итераций, имя файла, а также кнопка «Записать результаты в файл». Количество используемых типов FTR равно четырем. Таким образом, уровень сложности вывода в файл определен как средний.

Определение нормирующего фактора (VAF)

Рассчитаем ненормированное количество функциональных точек.

Таблица 1. Расчет UFPC

Основные характеристики системы:

· Программное средство реализовано как единый пакет на автономном персонально компьютере - 0.

· Данные между компонентами программного средства и системы не передаются - 0.

· Требования к производительности и проектированию программного средства были установлены и рассмотрены, но чтобы удовлетворить их никаких специальных мер не требовалось - 1.

· Явных или неявных ограничений на использование ресурсов не установлено - 0.

· Пиковые периоды транзакций не ожидаются - 0.

· Сложность диалоговых транзакций - более 30% обрабатываются в интерактивном режиме - 5.

· Эффективность программного средства для конечного пользователя - 2.

· Оперативное обновление отсутствует - 0.

· Сложность обработки данных - 3.

· В программном средстве нет кода, предназначенного для повторного использования - 0.

· Нет особых требований пользователя, и не требуется специальной установочной программы - 0.

· Простота использования - 1.

· При проектировании требования по установке программного средства были учтены, причем программное средство может выполняться, только на похожем (совместимом) аппаратном и / или программном обеспечении - 2.

· Изменение программного средства не предусмотрена - 0.

Нормирующий фактор (VAF) вычислим следующим образом:

VAF=0,65+0,01*TDI=0,65+0,01*(1+5+2+3+2)=0,78

Подсчет нормированного числа функциональных точек

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

APFC=UPFC*VAF=35*0,78=26,3

Оценка количества строк исходного кода с использованием бэкфайер-метода

Программное средство будет разрабатываться в среде MS Visual Studio 2008, поэтому значение языкового множителя равно 34. Таким образом, приблизительное количество строк законченное программы в среде MS Visual Studio 2008 будет равно.

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

хорошую работу на сайт">

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

Размещено на http://www.allbest.ru/

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

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

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

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

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

Для прогнозирования и планирования любых процессов или характеристик объектов (в частности программных средств) используются исходные данные двух типов:

· функции и номенклатура характеристик самого прогнозируемого объекта или процесса, для которого необходимо спланировать жизненный цикл;

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

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

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

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

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

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

· вследствие несовершенства методов оценивания ПС следует сравнивать оценки с действительными значениями технико-экономических показателей и использовать эти результаты для улучшения методов оценивания;

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

Основными ресурсами у разработчиков при создании сложных комплексов программ являются:

· допустимые трудозатраты (стоимость) на разработку ПО с требуемым качеством;

· время - длительность полного цикла создания программного продукта;

· необходимое и доступное число специалистов соответствующей квалификации.

Потребность в этих ресурсах в наибольшей степени зависит от размера (масштаба) и сложности разрабатываемого программного средства. Уточнения размеров программного средства и его компонентов могут быть решены последовательно к концу детального проектирования, однако при этом сохраняется неопределенность оценки размера комплекса программ и его трудоемкости порядка 5 - 10%, связанная с тем, насколько хорошо программисты понимают спецификации, в соответствии с которыми они должны кодировать программу. При этом целесообразно учитывать, что:

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

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

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

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

Недостаточно достоверные оценки влекут проблемы взаимодействия разработчика с заказчиком и увеличивают степень риска проекта.

Оценивание размера ПО

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

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

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

В настоящее время при оценке размера ПО чаще всего пользуются двумя основными единицами измерения - строками программного кода (Lines of code, LOC) и функциональными точками.

В качестве единиц измерения также можно использовать точки свойств, количество «жирных точек» на диаграмме потока данных (Data flow diagram, DFD), количество сущностей на диаграмме сущностей, объем документации, количество объектов, атрибутов и служб на объектной диаграмме. Вне зависимости от того, оценивается ли конечный продукт, как в случае использования LOC, либо его некоторая абстракция или модель, оценке подвергается то, чего еще нет в природе. Поэтому оценивание размеров представляет значительные трудности.

Использование LOC в качестве единицы измерения размера программного продукта

LOC оценка представляет собой наиболее универсальную метрику, поскольку может использоваться при создании любых программных продуктов. Она проще и понятнее как для специалистов, так и для заказчиков и инвесторов. Например, если утверждается, что один компонент программной системы, состоящей из n компонентов, в среднем потребует написания около 1000 строк программного кода, то каждый в состоянии прикинуть ее общий размер и хотя бы примерно оценить трудозатраты, требующиеся для ее создания, исходя из предположения, что средняя производительность одного программиста по-прежнему составляет около 3000 строк кода в год.

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

· число строк исходного кода зависит от уровня мастерства программиста. Фактически, чем выше мастерство программиста, тем меньшим количеством строк кода ему удастся обойтись для реализации определенной функциональной возможности (или функциональности) ПС;

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

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

· в программистском сообществе не достигнуто соглашения о методе подсчета строк кода. Языковые конструкции, используемые, например, в Visual C++, Ассемблере, Коболе или SQL, абсолютно различны. Метод же остается общим для любых приложений, в том числе использующих комбинацию различных языков;

· заказчику сложно понять, каково соотношение указанных им функциональных и нефункциональных (технических) требований к ПС и объемов программистской работы.

В то же время для повышения достоверности оценок есть несколько достаточно простых рекомендаций:

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

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

· Определения данных учитывайте лишь один раз.

· Не учитывайте строки, содержащие комментарии.

· Не учитывайте отладочный код либо другой временный код (пробное ПО, средства тестирования и пр.).

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

На практике при оценке размера больших программных систем чаще пользуются показателем тысяч строк исходного кода KSLOC. Эта метрика чаще всего используется при оценках производительности, которая рассчитывается как KSLOC/SM, где SM - staff-month (человеко-месяцы).

Оценка показателя LOC с помощью экспертных оценок и восходящего суммирования.

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

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

Этот показатель можно улучшить, если каждый оценщик укажет не одно, а три возможных значения размера: пессимистическое, оптимистическое и более или менее реалистическое. Затем к реалистическому значению, умноженному на 4, добавляется оптимистическая и пессимистическая оценки, и вся сумма делится на 6.

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

Например, если некоторый объект, отображенный на структуре WBS, может занимать от 200 до 400 строк кода и скорее всего его размер ближе к 200, то используя предложенный подход можно получить следующую оценку: (200+(250*4)+400)/6 = 266 LOC.

Оценка количества LOC по аналогии

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

Например, у нас имеется уже готовый модуль А, размер которого составляет 2345 LOC. Мы хотим создать новый модуль, который будет во многом схож с модулем А, но в него будут добавлены некоторые дополнительные свойства. Кроме того, мы придумали как сделать программный код более компактным. В результате этого размер модуля А" может быть оценен в 3000 LOC.

Конечно данный метод не является очень точным, так как при написании модуля А могли использоваться различные языки программирования, применяться алгоритмы с различными уровнями сложности, использоваться различный объем моделирования (моделирование, эмуляция, реальное приложение), но такая оценка все-таки имеет под собой какое-то количественное обоснование.

Преимущества использования LOC в качестве единицы измерения

· Эти единицы широко распространены и могут адаптироваться.

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

· Непосредственно связаны с конечным продуктом.

· Единицы LOC могут быть оценены еще до завершения проекта.

· Оценка размеров ПО производится с учетом точки зрения разработчиков.

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

· Знание размера программного продуктам в LOC - единицах позволяет применять большинство существующих методов оценки технико-экономических показателей проекта (таких как трудозатраты, длительность проекта, его стоимость и др.).

Недостатки, связанные с применением LOC - оценок

· Данные единицы измерения сложно применять на ранних стадиях жизненного цикла, когда высок уровень неопределенности.

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

· Применение методов оценки с помощью количества строк не регламентируется промышленными стандартами, например ISO.

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

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

· При подсчете LOC - единиц следует различать автоматически сгенерированный код и написанный вручную. Это сильно затрудняет применение автоматических методов подсчета.

· Показатели LOC не могут осуществляться при нормализации в случае, если использовались разные платформы или типы языков программирования.

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

· Генераторы кода зачастую провоцируют избыточный его объем, что может привести к значительным погрешностям в оценке размера ПС.

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

Количество дефектов / количество строк кода

Фаза кодирования в большинстве проектов занимает от 7% до 20% трудозатрат, поэтому более важным является качество кода, а не его объем.

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

Первой и наиболее удачной альтернативой методу подсчета исходных строк кода стала разработанная в 1979 году Алланом Альбрехтом из IBМ методология, названная «Анализ показателей функциональности» (FPA, от Function Points Analysis). В ее основе лежит взгляд на ПС извне, с позиций пользователя системы, а не «со стороны» ее внутренних свойств (таких, как LOC). В результате анализа исходных требований к ПС и выяснения реальных потребностей пользователей определяется объем функциональных возможностей системы, показателями которых служат функции обработки информации настолько низкого уровня, насколько они укладываются в систему мышления пользователей, а кроме функций - данные, которые эти функции обрабатывают. Таким образом, методология FPA базируется на идее декомпозиции функций и данных до предельно допустимого (с точки зрения пользователя) уровня. Объем функциональных возможностей ПС (далее просто функциональный размер) определяется в так называемых условных единицах функциональности FP - от Function Points.

В течение пяти лет с момента появления, методология FPA и метод расчета размера отшлифовывались А. Альбрехтом и проходили практическую апробацию, а в середине 80-х годов была создана Международная группа пользователей показателей функциональности (IFPUG, от International Function Points User Group), которая и поддерживает дальнейшую эволюцию метода.

Метод функциональных точек позволяет решать следующие задачи:

· Разрешить проблему, связанную с трудностью получения LOC - оценок на ранних стадиях жизненного цикла.

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

В методе функциональных точек используется 5 информационных характеристик.

1. Количество внешних вводов. Подсчитываются все вводы пользователя, по которым поступают разные прикладные данные. Вводы должны быть отделены от запросов, которые подсчитываются отдельно.

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

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

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

5. Количество внешних интерфейсных файлов. Подсчитываются все логические файлы из других приложений, на которые ссылается данное приложение.

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

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

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

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

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

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

Для транзакций ранжирование основано на количестве ссылок на файлы и количестве типов элементов данных. Для файлов ранжирование основано на количестве типов элементов-записей и типов элементов данных, входящих в файл.

программный трудоемкость жизненный цикл

Размещено на Allbest.ru

...

Подобные документы

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

    контрольная работа , добавлен 12.11.2008

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

    презентация , добавлен 09.02.2015

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

    курсовая работа , добавлен 28.12.2012

    Жизненный цикл проекта и его фазы. Оценка устойчивости проекта (рисков и уровня безубыточности). Факторы потерь времени в ходе его реализации. Планирование работ по проекту создания бильярдного клуба за 51 неделю, с затратами не более 3,5 млн. руб.

    курсовая работа , добавлен 22.12.2011

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

    презентация , добавлен 28.11.2013

    Понятие жизненного цикла организации, его различные модели и основные этапы. Действия руководителя на различных стадиях развития организации, перспективные модели ее эволюции. Анализ жизненных циклов, пройденных компанией на примере ООО "Лекрус Урал".

    курсовая работа , добавлен 28.02.2012

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

    курсовая работа , добавлен 10.11.2010

    Организация основного производства. Понятие и классификация производственных процессов. Технологическая цепочка производства изделий. Расчет длительности производственного цикла простого процесса. Пути сокращения длительности производственных циклов.

    презентация , добавлен 06.11.2012

    Общее понятие о жизненном цикле проекта. Основные процессы управления проектом. Анализ жизненного цикла и процессов нефтегазового проекта на примере проекта деятельности ОАО "ЛУКОЙЛ". Оценка фазы жизненного цикла проекта и рекомендации по управлению ним.

    курсовая работа , добавлен 13.01.2014

    Организационная структура управления проектом открытия ресторана. Разбиение работ по проекту. Матрица разделения административных задач управления. Определение относительных показателей внутренней трудоемкости. Сравнение трудоемкости и полезности.

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

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

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

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

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

Число Файлов. Подсчитывается количество главных логических файлов (логических групп данных), которые могут входить в состав достаточно большой базы данных.

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

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

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

Нет влияния - 0.

Случайное влияние -1.

Умеренное влияние - 2.

Среднее влияние - 3.

Значительное влияние - 4.

Существенное влияние - 5.

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

1. Требует ли система надежного резервирования и последующего восстановления после отказа?

2. Требуется ли передача данных?

3. Имеются ли функции распределенной обработки?

4. Критична ли производительность программного продукта?

5. Будет ли система функционировать в существующей или в более сложной операционной обстановке?

6.Требует ли система онлайнового ввода данных?

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

8. Осуществляется ли обновление главного файла в онлайновом режиме?

9. Являются ли сложными входы, выходы, файлы или запросы?

10. Являются ли сложными алгоритмы обработки данных

Весовые коэффициенты приведены в табл.

Порядок расчета

1. Определяют параметры системы (входы/выходы)

2. Каждому параметру присваивают свой весовой коэффициент, учитывающий сложность реализации параметра

3. Определяют общий итог по всем параметрам

4. Число ФТ определяют по формуле ФТ=общий итог(0,65+0,01суммы коэффициентов)

ФТ можно использовать для определения производительности труда, стоимость разработки одной точки, количество страниц документации на одну точку и т.д.