Лабораторная работа №2 по курсу «Современные технологии обработки экономической информации (часть 2)»

Министерство образования Республики Беларусь
Учреждение образования
«Белорусский государственный университет информатики и
радиоэлектроники»
Кафедра экономической информатики
Лабораторная работа №2 по курсу:
«Современные технологии обработки экономической информации (часть 2)»
Тема: «Оценка трудоёмкости»
Проверил: Салапура Марина Николаевна
Выполнил: студент группы 602321с
(дистанционная форма обучения)
Wasja
Минск 2011
1 Задание
Описать проект создания медицинского оборудования и выполнить оценку его трудоемкости и объемов работ любым из изученных методов. Написать
сценарий выполнения этот проект и соотнести его оценку с фактическим результатом.
2 Выполнение работы
Современное медицинское оборудование базируется на широком использовании вычислительных ресурсов, позволяющих получать, накапливать и анализировать большие объемы информации, а также выдавать полученные результаты в понятном человеку виде (диаграммы, изображения, таблицы и т.п.). Поэтому современная медицинская техника представляет собой аппаратнопрограммные комплексы, требующие для своей работы специально разработанного программного обеспечения, к которому предъявляются жесткие требования
по быстродействию, надежности и точности вычислений.
Программное обеспечение для проекта создания медицинского оборудования (эхокардиографа) включает в себя четыре функционально-обособленных
модуля:
− встраиваемая программа для блока цифровой обработки сигналов от датчиков – реализуется на ассемблере для процессора TMS320C54x;
− драйвер для блока цифровой обработки сигналов от датчиков под операционные системы Windows 2k/XP/2k3/Vista/7 – реализуется на языке C++ с применением вставок на ассемблере x86;
− клиентская программа для управления эхокардиографом под операционные системы Windows 2k/XP/2k3/Vista/7 – реализуется на языке C#;
− серверная программа для хранения данных проведенных измерений под
операционные системы Windows 2k/XP/2k3/Vista/7 – реализуется на языке C#.
Использование собственного опыта или опыта коллег, полученного в похожих проектах, это наиболее точный подход, который позволяет получить достаточно реалистичные оценки трудоемкости и срока реализации программного
проекта, быстро и без больших затрат. Если собственный опыт аналогичных
проектов отсутствует, а коллеги-эксперты недоступны, то необходимо использовать формальные методики, основанные на обобщенном отраслевом опыте. Среди них наибольшее распространение получили два подхода: FPA IFPUG (метод
функциональных точек) и метод COCOMO II (Constructive Cost Model). При
этом IFPUG FPA наиболее предпочтительно применять на стороне заказчика, а
СОСОМО II – на стороне разработчика, так как для заказчика разница в конкретных условиях разработки не важна, а для разработчика – важна. Для рассматриваемого проекта имеет смысл использовать метод COCOMO II.
Методика COCOMO, позволяющая оценить трудоемкость и время разработки программного продукта, впервые была опубликована Бари Боэмом в 1981
г. как результат анализа 63 проектов компании «TRW Aerospace». В 1997 методика была усовершенствована и получила название COCOMO II. Калибровка
параметров была проведена по 161 проекту разработки, кроме того модель базируется на регрессии с параметрами, определяемыми на основе отраслевых данных и характеристик конкретного проекта.
В методе COCOMO II различаются две стадии оценки проекта: предварительная оценка (7 множителей трудоемкости) на начальной фазе и детальная
оценка (17 множителей трудоемкости) после проработки архитектуры.
Формула оценки трудоемкости проекта в человеко-месяцах имеет вид:
n
PM = A ⋅ SIZE E ⋅ ∏ EM i ; A = 2,94 ;
(1)
i =1
5
E = B + 0,01 ⋅ ∑ SF j ; B = 0,91 ,
(2)
j =1
где SIZE – размер продукта в тысячах строках исходного кода (KSLOC);
EMi – множители трудоемкости;
SFj – факторы масштаба;
n – число множителей трудоемкости.
Особенность метода является необходимость знать заранее размер программного продукта в тысячах строках исходного кода (KSLOC). Этот размер
может быть, например, получен экспертами с применением метода PERT. Так
же, если был проведен анализ продукта методом функциональных точек, то его
размер может быть рассчитан с использованием собственных статистических
данных или с использованием статистики по отрасли (Таблица 1).
Таблица 1 – Оценка количества строк, необходимых на реализацию одной не
выровненной функциональной точки
Язык программирования
Assembler
C
C++
C#
J2EE
JavaScript
PL/SQL
Visual Basic
Наиболее вероятная
172
148
60
59
61
56
46
50
Оценка количества строк
Оптимистичная
86
9
29
51
50
44
14
14
Пессимистичная
320
704
178
66
100
65
110
276
В методе используются пять факторов масштаба (их значения сведены в
таблицу 2), которые определяются следующими характеристиками проекта:
1) PREC – прецедентность, наличие опыт аналогичных разработок («Очень
низкий» – опыт в продукте и платформе отсутствует; «Экстра высокий» – продукт и платформа полностью знакомы).
2) FLEX – гибкость процесса разработки («Очень низкий» – процесс строго
детерминирован; «Экстра высокий» – определены только общие цели).
3) RESL – архитектура и разрешение рисков («Очень низкий» – риски неизвестны/не проанализированы; «Экстра высокий» – риски проработаны).
4) TEAM – сработанность команды («Очень низкий» – формальные взаимодействия; «Экстра высокий» – полное доверие, взаимозаменяемость и взаимопомощь).
5) PMAT – зрелость процессов («Очень низкий» – CMM Level 1, т.е. организация не имеет явно осознанного процесса разработки программ; «Экстра высокий» – CMM Level 5, т.е. в организации есть постоянно действующая процедура
поиска и освоения новых и улучшенных методов и инструментов).
Таблица 2 – Значение фактора масштаба, в зависимости от оценки его уровня
Фактор масштаба
PREC
FLEX
RESL
TEAM
PMAT
Очень низкий
6.20
5.07
7.07
5.48
7.80
Низкий
4.96
4.05
5.65
4.38
6.24
Оценка уровня фактора
Нормальный Высокий Очень высокий
3.72
2.48
1.24
3.04
2.03
1.01
4.24
2.83
1.41
3.29
2.19
1.10
4.68
3.12
1.56
Экстра высокий
0.00
0.00
0.00
0.00
0.00
Для предварительной оценки трудоемкости программного проекта необходимо также оценить для проекта уровень семи множителей трудоемкости
(таблица 3):
1) PERS – квалификация персонала («Экстра низкий» – аналитики и программисты имеют низшую квалификацию, текучесть больше 45%; «Экстра высокий» – аналитики и программисты имеют высшую квалификацию, текучесть
меньше 4%).
2) RCPX – сложность и надежность продукта («Экстра низкий» – продукт
простой, специальных требований по надежности нет, БД маленькая, документация не требуется; «Экстра высокий» – продукт очень сложный, требования по
надежности жесткие, БД сверхбольшая, документация требуется в полном объеме).
3) RUSE – разработка для повторного использования («Низкий» – не требуется; «Экстра высокий» – требуется повторное использование в других продуктах).
4) PDIF – сложность платформы разработки («Низкий» – специальные ограничения по памяти и быстродействию отсутствуют, платформа стабильна; «Экстра высокий» – жесткие ограничения по памяти и быстродействию, платформа
нестабильна).
5) PREX – опыт персонала («Экстра низкий» – новое приложение, инструменты и платформа; «Экстра высокий» – приложение, инструменты и платформа хорошо известны).
6) FCIL – оборудование («Экстра низкий» – инструменты простейшие, коммуникации затруднены; «Экстра высокий» – интегрированные средства поддержки жизненного цикла, интерактивные мультимедиа коммуникации).
7) SCED – сжатие расписания («Очень низкий» – 75% от номинальной длительности; «Очень высокий» – 160% от номинальной длительности).
Таблица 3 – Значения множителей трудоемкости
PERS
RCPX
RUSE
PDIF
PREX
FCIL
SCED
Экстра низкий
2.12
0.49
n/a
n/a
1.59
1.43
n/a
Оценка уровня множителя трудоемкости
Очень низкий Низкий Нормальный Высокий Очень высокий
1.62
1.26
1.00
0.83
0.63
0.60
0.83
1.00
1.33
1.91
n/a
0.95
1.00
1.07
1.15
n/a
0.87
1.00
1.29
1.81
1.33
1.22
1.00
0.87
0.74
1.30
1.10
1.00
0.87
0.73
1.43
1.14
1.00
1.00
1.00
Экстра высокий
0.5
2.72
1.24
2.61
0.62
0.62
n/a
Для того чтобы адекватно спланировать проект и оценить его трудоемкость, необходимо выполнить предварительное проектирование программного
продукта. В результате декомпозиции мы получаем некоторое количество компонентов, которые составляют программный продукт. Следует понимать, что
суммарная трудоемкость проекта не равна простой сумме трудоемкостей разработки каждого из компонентов (сумма не учитывает взаимосвязи компонентов и
трудозатраты на их интеграцию):
N
PM ≠ ∑ PM k
k =1
(3)
Методика COCOMO II определяет следующую последовательность вычисления трудоемкости проекта при многокомпонентной разработке:
1) Суммарный размер продукта рассчитывается, как сумма размеров его
компонентов:
N
SIZE A = ∑ SIZE k
k =1
(4)
2) Базовая трудоемкость проекта рассчитывается по формуле:
PM B = A ⋅ ( SIZE A ) E ⋅ SCED
(5)
3) Затем рассчитывается базовая трудоемкость каждого компонента:
PM kB = PM B ⋅
SIZE k
SIZE A
(6)
4) На следующем шаге рассчитывается оценка трудоемкости компонентов с
учетом всех множителей трудоемкости, кроме множителя SCED.
6
PM k' = PM kB ⋅ ∏ EM i
i =1
5) Итоговая трудоемкость проекта определятся по формуле:
(7)
N
PM = ∑ PM k'
(8)
k =1
Исходя из описания проекта, можно сделать вывод о целесообразности
расчета многокомпонентной разработки, при этом в составе разрабатываемой
программной системы можно выделить пять компонентов – два на ассемблере,
один на C++ и два на C#. Базируясь на опыте предыдущих разработок, был определен приблизительный размер данных компонентов (в не выровненных функциональных точках). Это позволило определить суммарный размер продукта
(таблица 4) по формуле (4) с использованием статистических данных из таблицы
1 (для наиболее вероятного случая).
Таблица 4 – Размер компонентов программного продукта
№
Компонент
1 Встраиваемая программа для блока ЦОС (Assembler)
2 Драйвер для блока ЦОС (Assembler)
3 Драйвер для блока ЦОС (C++)
4 Клиентская программа (C#)
5 Серверная программа (C#)
Всего:
Число точек
25
34
76
254
392
Число строк
4 300
5 848
4 560
14 986
23 128
52 822
Для определения значения параметра E по формуле (2) необходимо определиться со значениями факторов масштаба:
− PREC – предполагается, что предприятие имеет большой опыт разработки программного обеспечения, поэтому принимается значение «Высокий»;
− FLEX – на предприятии используются различные подходы к гибкости
процесса разработки в зависимости от отдела, поэтому принимается значение
«Нормальный»;
− RESL – на предприятии отсутствует комплексная система управления
рисками, приблизительной оценкой рисков занимаются руководители проектов,
основываясь на своем опыте, поэтому принимается значение «Нормальный»;
− TEAM – на предприятии каждый проект закрепляется за отдельным отделом, состоящим из давно работающих совместно программистов, поэтому принимается значение «Высокий»;
− PMAT – на предприятии установлен определенный, четко документированный процесс работы, не зависящий от отдельных личностей, поэтому принимается значение «Нормальный».
E = 0,91 + 0,01 ⋅ (2,48 + 3,04 + 4,24 + 2,19 + 4,68) = 1,08
Для расчета базовой трудоемкости проекта необходимо задать значение
множителя трудоемкости SCED. Исходя из того, что строгих сроков на разработку предприятию не установлено, принимается значение «Нормальный». Тогда, по формуле (5):
PM B = 2,94 ⋅ (52,822)1, 08 ⋅ 1,00 = 213,298 (чел.-мес.)
Значения базовой трудоемкости для каждого из компонентов сведены в
таблицу 5, там же приведены соответствующие значения множителей трудоемкости, вычисленные значения трудоемкостей для всех компонентов и итоговое
значение трудоемкости для всего проекта в целом. При выборе значений множителей были использованы следующие соображения:
− PERS – предполагается, что предприятие имеет низкую текучесть кадров
и достаточно высокую квалификацию персонала, что позволяет принять значение «Очень высокий»;
− RCPX – как было сказано ранее, использование продукта в медицинских
целях предполагает повышенную надежность продукта, поэтому принимается
значение «Экстра высокий»;
− RUSE – компоненты, непосредственно связанные с обработкой данных
(встраиваемая программа и драйвер), являются узкоспециализированными, поэтому для них принимается значение «Низкий», для остальных компонентов –
«Нормальный»;
− PDIF – для компонента, реализующего встраиваемую программу, имеет
смысл принять значение «Экстра высокий» (поскольку на нее накладываются
жесткие ограничения по памяти и быстродействию), для компонентов, реализующих драйвер, – «Высокий», для остальных – «Нормальный»;
− PREX – предыдущий опыт персонала позволяет принять значение «Высокий» для всех компонентов;
− FCIL – используемое на предприятии для разработки современное оборудование и системы коммуникации позволяют назначить значение «Высокий».
Таблица 5 – Трудоемкость компонентов
№
Компонент
Встраиваемая программа для блока
ЦОС (Assembler)
Драйвер для блока
2
ЦОС (Assembler)
Драйвер для блока
3
ЦОС (C++)
Клиентская про4
грамма (C#)
Серверная про5
грамма (C#)
Всего:
1
PM kB
PERS
RCPX
RUSE
PDIF
PREX
FCIL
PM k'
17,364
0,63
2,72
0,95
2,61
0,87
0,87
55,842
23,615
0,63
2,72
0,95
1,29
0,87
0,87
37,536
18,414
0,63
2,72
0,95
1,29
0,87
0,87
29,269
60,514
0,63
2,72
1,00
1,00
0,87
0,87
78,488
93,392
0,63
2,72
1,00
1,00
0,87
0,87
121,132
322,267
Вывод: итоговая трудоемкость разработки проекта медицинской техники,
рассчитанная методом COCOMO II, составила 322,267 человеко-месяцев. Сравнивая полученный результат с фактической трудоемкости проекта (отдел из 25
человек завершил проект за один год) можно сделать вывод о достаточной адекватности полученного результата.