Методические рекомендации для студентов специальностей 230105 Программное обеспечение вычислительной техники и автоматизированных систем (стр. 8 из 11)

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

• Средства оценки, являющиеся коммерческими продуктами, такие, как SLIM (Quantitative Systems Management), ESTIMACS (Computer Associates), KnowledgePLAN и CHECKPOINT (Software Productivity Research (SPR)). Глава фирмы SPR Каперс Джонс, "гуру" в области метрик ПО, оценивает рынок средств оценки проектов примерно в 50 продуктов. Эти продукты нельзя назвать совершенными, и все они требуют от пользователя высокого уровня квалификации (здесь, как и в других областях деятельности, действует принцип "что заложишь, то и получишь"). В лучшем случае с помощью таких продуктов можно получить оценку с точностью ±10%. Даже если точность будет ±50%, это все равно лучше, чем брать данные "с потолка".
• Динамические модели систем — множество имитационных моделей, которые позволяют исследовать нелинейные зависимости между различными факторами, влияющими на динамику проектных процессов. Например, если частью стратегии проекта является требование сверхурочной работы участников проекта со стороны менеджера, каков будет эффект через несколько недель или месяцев? Естественно предположить, что по сравнению с нормальным восьмичасовым рабочим днем отдача увеличится, однако наиболее опытный менеджер проекта также отметит, что производительность (измеряемая в количестве функциональных точек в день, строках кода в час и т.д.) по мере накопления усталости будет постепенно снижаться. Кроме того, возрастет количество ошибок, что, очевидно, повлияет на трудоемкость тестирования и отладки.
• Аналитические модели для оценки проектов, описанные в литературе. Лучшими являются работы Барри Боэма (модель СОСОМО, разработанная им в начале 80-х гг., была позднее модифицирована в модель СОСОМО-2). Другой классической работой является книга Фредерика Брукса "Мифический человеко-месяц", также переизданная в 1995 г. с учетом современной технологии и практики разработки ПО.
• Различные руководства и отчеты организаций, подобных Software Engineering Institute (SEI), которые могут помочь при выполнении оценки проектов.
• Такие распространенные методы, как прототипирование, также могут использоваться для оценки критичности тех или иных проектных ограничений для всей разрабатываемой системы в целом. Этот подход позволяет привнести немного здравого смысла в проектную команду и в окружающих ее менеджеров и заказчиков. Если руководство хочет, чтобы команда из трех разработчиков написала 1 млн строк кода за 12 мес, то следовало бы в течение первого месяца разработать небольшой прототип будущей системы, который, по крайней мере, позволит грубо оценить производительность проектной команды, а также реализуемость проекта в целом.

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

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

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

Метод разработан на основе опыта реализации множества проектов создания ПО и поддерживается международной организацией IFPUG (International Function Point User Group). Существуют специальные программные средства, автоматизирующие проведение оценок по методу функциональных точек и позволяющие оценить, насколько быстро и с какими затратами в действительности удастся реализовать проект. Одним из таких средств является KnowledgePLAN — продукт фирмы SPR.

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

оценка затрат на разработку ПО

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

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

Оценка затрат на разработку ПО предполагает выполнение следующих четырех шагов:

1. оценка размера разрабатываемого продукта. Для ПО в прежнее время основной мерой оценки являлось количество строк кода (LOC - Lines Of Code), а в настоящее время является количество функциональных точек (FPs - Function Points). Под функциональной точкой понимается любой из следующих элементов разрабатываемого продукта:

• входной элемент приложения (входной элемент или экранная форма);
• выходной элемент приложения (отчет, документ, экранная форма);
• запрос (пара «вопрос/ответ»);
• логический файл (совокупность записей данных, используемых внутри приложения);
• интерфейс приложения (совокупность записей данных, передаваемых другому приложению или получаемых от него)

оценка трудоемкости в человеко-месяцах или человеко-часах;

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

оценка стоимости проекта.

Для расчетов используются Функционально ориентированные метрики

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

1. Количество внешних входов, т.е., подсчитываются все вводы пользователя по которым, поступают все прикладные данные. Вводы должны быть отделены от запросов.
2. Количество внешних выводов (отчёты, экраны, сообщения об ошибках, распечатки) внутри каждого элемента.
3. Количество внешних запросов. Запрос – это диалоговый ввод, который приводит к немедленному программному ответу в форме диалогового вывода, при этом диалоговый ввод в приложении не сохраняется, а диалоговый вывод не требует выполнения вычислений.
4. количество внутренних логических файлов, т.е., логические группы данных, которые могут быть частью базы данных или отдельным файлом.
5. Количество внешних интерфейсных файлов. Подсчитываются все логические файлы из других приложений, на которые ссылается данное приложение.

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

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

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

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

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

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

Примеры элементов данных :

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