 ПОЗНАВАТЕЛЬНОЕ Сила воли ведет к действию, а позитивные действия формируют позитивное отношение Как определить диапазон голоса - ваш вокал Игровые автоматы с быстрым выводом Как самому избавиться от обидчивости Противоречивые взгляды на качества, присущие мужчинам Вкуснейший "Салат из свеклы с чесноком" Натюрморт и его изобразительные возможности Применение, как принимать мумие? Мумие для волос, лица, при переломах, при кровотечении и т.д. Как научиться брать на себя ответственность Зачем нужны границы в отношениях с детьми? Световозвращающие элементы на детской одежде Как победить свой возраст? Восемь уникальных способов, которые помогут достичь долголетия Классификация ожирения по ИМТ (ВОЗ) Глава 3. Завет мужчины с женщиной
Оси и плоскости тела человека - Тело человека состоит из определенных топографических частей и участков, в которых расположены органы, мышцы, сосуды, нервы и т.д.
| Функционально-ориентированные метрики
Заведующий кафедрой Н. Сапожников “ ” 200 г.
Методические указания На Практическое занятие № 1 по «ПО СКС» Класс 156, 157 Дата и время Место проведения: класс ПК Тема: Руководство программным проектом и расчет метрик Цели: 1. Закрепление и углубление теоретических знаний. 2. Составления руководства программным проектом 3. Расчет метрик двух типов 4. Развитие и закрепление интереса у обучаемых к преподаваемому предмету. В результате проведения практического занятия студенты должны ЗНАТЬ: - Основы составления руководства программным проектом - Порядок расчета размерно-ориентированных метрик - Основы выполнение размерно-ориентированных оценок УМЕТЬ: - Составит руководство программным проектом - Рассчитать размерно-ориентированные метрики
Организационно-методические указания По проведению Практического занятия № … по дисциплине «Программное обеспечение СКС» Вводная теоретическая часть Размерно-ориентированные метрики Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Они основываются на LOC-оценках (Line Of Code) – количество строк в программном продукте. Исходные данные для расчёта сводят в таблицу:
Вычисляются метрики по следующим формулам: 1) производительность:
2) качество:
3) удельная стоимость:
4) документированность:
Достоинства размерно-ориентированной метрики 1) распространенность метрики; 2) легко вычислить и её простота. Недостатки размерно-ориентированной метрики 1) зависит от АЕП; 2) требует исходные данные в начале; 3) не применима к процедурам АЕП. Функционально-ориентированные метрики Функционально-ориентированные метрики косвенно измеряют программный продукт и процесс его разработки. Рассматривается функциональность и полезность продукт. Функционально-ориентированные метрики используют пять информационных характеристик: 1) количество внешних вводов – все вводы пользователя разных прикладных задач; 2) количество внешних выводов – выводы результатов к пользователю, вычисленные программой (распечатки, экраны, сообщения об ошибках); 3) количество внешних запросов – диалоговый ввод, приводящий к немедленному ответу в виде диалогового вывода, то есть все запросы/ответы; 4) количество внутренних логических файлов – логические файлы (логические группы данных, в виде части БД или отдельного файла); 5) количество внешних интерфейсных файлов – логические файлы из других приложений, используемые программой. Первые три информационные характеристики относятся к категории транзакций. Транзакция – элементарный процесс, различаемый пользователем и перемещающий данные между внешней средой и программой. Они используют внутренние и внешние файлы. Определения транзакций 1) внешний ввод – элементарный процесс, перемещающий данные из внешней среды в программу; 2) внешний вывод - элементарный процесс, перемещающий данные, вычисленные в программе во внешнюю среду или обновление внутренних логических файлов; 3) внешний запрос – элементарный процесс, работающий с вводимыми и выводимыми данными, его результат – данные, возвращаемые из внутренних логических файлов и внешних интерфейсных файлов, где входная часть процесса не модифицирует внутренние логические файлы, а входная часть не несёт данных, вычисляемых программой; 4) внутренний логический файл – группа логически связанных данных, размещённая внутри программы и обслуживающаяся через внешние вводы; 5) внешний интерфейсный файл – группа логически связанных данных, размещаемых внутри других программ поддерживаемых этой программой. Характеристики могут иметь низкий, редкий и высокий ранг. На их основе формируется числовая оценка ранга. Для ранжирования транзакций учитывают типы: - тип элемента записи – подгруздка элементов данных, рассматриваемая пользователем в пределах файла; - тип элемента данных – уникальное не рекурсивное поле, распознаваемое пользователем. Учёт элементов имеет свои правила. Данные для определения ранга и оценки сложности транзакции и файлов определяются статически. После сбора всей необходимой информации рассматривается метрика – количество функциональных указателей FP (Function Points). Исходные данные для расчёта сводятся в таблицу:
А – метка заполнитель
где 0 – нет влияния; 1 – случайное; 2 – небольшое; 3 – среднее; 4 – важное; 5 – основное. Значения выбираются эмпирически по ответам на 14 вопросов. Вопросы характеризуют системные параметры программ и приложений. На основе FP метрик рассчитывают: 1) производительность:
2) качество:
3) удельная стоимость:
4) документированность:
Область применения этой метрики – коммерческие информационные системы. Существуют и другие метрики, например: для инженерных ПО и ПО реального времени используют метрики указателей свойств, где добавляется характеристика – количество алгоритмов, таких как, обработка прерываний, системное обслуживание устройств.
Основная часть Предварительная оценка программного проекта В качестве иллюстрации применения методики оценки, изложенной в разделе «Выполнение оценки проекта на основе LOC- и FP-метрик», рассмотрим конкретный пример. Предположим, что поступил заказ от концерна «СУПЕРАВТО». Необходимо создать ПО для рабочей станции дизайнера автомобиля (РДА). Заказчик определил проблемную область проекта в своей спецификации: · ПО РДА должно формировать 2- и 3-мерные изображения для дизайнера; · дизайнер должен вести диалог с РДА и управлять им с помощью стандартизованного графического пользовательского интерфейса; · геометрические данные и прикладные данные должны содержаться в базе данных РДА; · модули проектного анализа рабочей станции должны формировать данные для широкого класса дисплеев SVGA; · ПО РДА должно управлять и вести диалог со следующими периферийными устройствами: мышь, дигитайзер (графический планшет для ручного ввода), плоттер (графопостроитель), сканер, струйный и лазерный принтеры. Прежде всего надо детализировать проблемную область. Следует выделить базовые функции ПО и очертить количественные границы. Очевидно, нужно определить, что такое «стандартизованный графический пользовательский интерфейс», какими должны быть размер и другие характеристики базы данных РДА и т.д. Будем считать, что эта работа проделана и что идентифицированы следующие основные функции ПО:
Теперь нужно оценить каждую из функций количественно, с помощью LOC-оценки. По каждой функции эксперты предоставляют лучшее, худшее и вероятностное значения. Ожидаемую LOC-оценку реализации функции определяем по формуле LOCожi=(LOCлучшi+LOCхудшi +4*LOCвероятi)/6, Результаты расчетов заносим в табл. Начальная таблица оценки проекта
Для определения удельной стоимости и производительности обратимся в архив фирмы, где хранятся данные метрического базиса, собранные по уже выполненным проектам. Предположим, что из метрического базиса извлечены данные по функциям-аналогам, представленные в таблице
Данные из метрического базиса фирмы
Видно, что наибольшую удельную стоимость имеет строка функции управления периферией (требуется специфические и конкретные знания по разнообразным периферийным устройствам),наименьшую удельную стоимость- строка функции управления пользовательским интерфейсом (применяются широко известные решения). Считается, что удельная стоимость строки является константой и не изменяется от реализации. Следовательно, стоимость разработки каждой функции рассчитывается по формуле: СТОИМОСТЬi =LOCожi*УД_СТОИМОСТЬанi Для вычисления производительности разработки каждой функции выберем самый точный подход-подход настраиваемой призводительности: ПРОИЗВi = ПРОИЗВанi*(LOCанi/LOCожi) Соответственно, затраты на разработку каждой функции будем определять по выражению ЗАТРАТЫi=(LOCожi/ПРОИЗВi)[чел-мес] Теперь мы имеем все необходимые данные для завершения расчетов. Заполним до конца таблицу оценки нашего проекта
Учитывая важность полученных результатов, проверим расчеты с помощью FP-указателей. На данном этапе оценивания разумно допустить, что все информационные характеристики имеют средний уровень сложности. В этом случае результаты экспертной оценки принимают вид, представленный в табл. Оценка информационных характеристик проекта
Оценка системных параметров проекта
Таким образом, получаем:
Используя значение производительности, взятое в метрическом базисе фирмы, Производительность=2,55 [FP/чел.-мес] Вычисляем значение затрат и стоимости: Затраты=FP/Производительность=145,9 [чел.-мес] Стоимость=Затраты*$4500=$656500. Итак, результаты проверки показали хорошую достоверность результатов. Но мы не будем останавливаться на достигнутом и организуем еще одну проверку, с помощью модели COCOMO II. Примем, что все масштабные факторы и факторы затрат имеют номинальные значения. В силу этого показатель степени В=1,16, а множитель поправки Мр=1. Кроме того, будем считать, что автоматическая генерация кода и повторное использование компонентов не предусматривается. Следовательно, мы вправе применить формулу ЗАТРАТЫ=А*РАЗМЕРВ [чел.-мес] И получаем: ЗАТРАТЫ=2,5(33,3)1,16 =145,87 [чел.-мес] Соответственно, номинальная длительность проекта равна Длительность=[3.0*(ЗАТРАТЫ)(0,33+0,2(в-1,01))]=3(145,87)0,36=18 [мс]. Заключение Подведем итоги. Выполнена предварительная оценка программного проекта. Для минимизации риска оценивания использованы три методики, доказавшие корректность полученных результатов. Литература 1. Конспект лекций по ПОСКС. 2. Орлов С.А. Технологии разработки ПО. Разработка сложных программных систем. - С.-П.: «Питер» - 2003, 473 ст. 3. Соммервилл И. Инженерия программного обеспечения. М.: Издательский дом «Вильямс», 2002. – 624 с. 4. Прата С. Язык программирования С++. Лекции и упражнения. Учебник: Перевод с англ./ - СПб: ООО «ДиаСофт ЮП», 2003. – 1104 с. Инструктивно-методические указания по проведению практического занятия № 1 обсуждены и одобрены на заседании кафедры КС . Протокол № ____ от “___” ____________ 200 г. |
- коэффициент регулировки сложности:
