Табл. 10.1. Типове проекти по големина
Намаляването на производителността с нарастването на размера на проект
та е естествена — тя се обяснява с увеличаването на броя на взаимодействията
между растящия брой членове на колектива разработчик, всяко от които изиск-
ва допълнителни усилия и следователно отнема от времето за директно създава-
не на първичния код.
10.3.4. Усъвършенстване на модела
Първото усъвършенстване на дотук изложения базов модел е въвеждане-
то на 3 типа софтуерни проекти — разпространен, полунезависим и вграден
(макар и немного сполучливи, това са използвани вече в нашата литература
преводи на оригиналните термини organic, semidetached, embedded). 3a всеки
от тях формулата е различна. В табл.10.2. всеки тип се характеризира кратко,
илюстрира се с примери и му се съпоставя предложената от Боем формула.
Следващото усъвършенстване е свързано с установяването на факта, че
все пак редовете първичен код не биха могли да са единственият параметър на
установената формула. Преминава се към по-сложни модели — междинен
(intermediate) u детайлен (detailed), в които се отчитат допълнителни фактори.
Те заедно с възможните им рейтинги са дадени в табл.10.3.
128
Табл. 10.2. Типове софтуерни проекти
Оценявани атрибути
|
Много
нисък
|
Нисък
|
Норма-
лен
|
Висок
|
Много
висок
|
Свръх висок
|
Атрибути на продукта
|
|
|
|
|
|
|
Изисквана надеждност
|
0.75
|
0,88
|
1,00
|
1,15
|
1.40
|
|
Размер на базата данни
|
|
0,94
|
1,00
|
1,08
|
1,16
|
|
Сложност на продукта
|
0,70
|
0,85
|
1,00
|
1,15
|
1,30
|
1,65
|
Атрибути на компютъра
|
|
|
|
|
|
|
Ограничение по бързина
|
|
|
1,00
|
1,11
|
1,30
|
1,65
|
Ограничение по оперативна
памет
|
|
|
1,00
|
1,06
|
1,21
|
1,65
|
Изменяемост на виртуалната
машина
|
|
0,87
|
1,00
|
1,15
|
1,30
|
|
Цикъл на обръщение към ком-
пютъра
|
|
0,87
|
1,00
|
1,07
|
1,15
|
|
Атрибути на изпълнителя
|
|
|
|
|
|
|
Квалификация на проектанти-
те
|
1,46
|
1,19
|
1,00
|
0,86
|
0,71
|
|
Опит в приложната област
Квалификация на програмис-
тите
|
1,29
1,42
|
1,13
1,17
|
1,00
1,00
|
0,91
0,86
|
0,82
0,70
|
|
Опит от работа с компютъра
|
1,21
|
1,10
|
1,00
|
0,90
|
|
|
Опит с езика за програмиране
|
1,14
|
1.07
|
1,00
|
0,95
|
|
|
Атрибути на проекта
|
|
|
|
|
|
|
Прилагане на съвременни ме-
тоди
|
1,24
|
1,10
|
1,00
|
0,91
|
0,82
|
|
Ползване инструментални
средства
|
1,24
|
1,10
|
1,00
|
0,91
|
0,83
|
|
Ограничения в срока на разра-
ботка
|
1,23
|
1,08
|
1.00
|
1,04
|
1.10
|
|
Табл. 10.3. Атрибути и рейтинги
129
При извършването на оценката експертите следва да се ръководят от тази
таблица и за конкретния проект трябва да определят за всеки атрибут съответ-
ния рейтинг. Получените стойности се заместват в формулата, която вече е при-
добила по-сложен вид:
ЧМ = к х ХРПКР х A1 x A2... х А15,
където ЧМ и ХРПК са вече познатите величини,
к и р са коефициенти, които са различни за различните типове софтуер,
както се вижда и от табл. 10.2.
А, са рейтингите на атрибутите
Разликата в междинния и детайлния модел е в начина на получаване на
крайната оценка. Основната разлика е в това, че при детайлния вариант се при-
лагат различни коригиращи коефициенти (рейтинги) за всяка фаза от производ-
ствения процес. По-сложен е и процесът, чрез който от оценките на отделните
модули се получават оценки за подсистемите и от тях — за цялостния продукт.
При междинния вариант нивото модул се игнорира.
10.3.5. Критика на„редове първичен код"
Основните критики към СОСОМО се свеждат до следните две:
-
Няма нито стандарт, нито единно виждане за това, какво е „ред първичен код".
-
Много е трудно дори за експерти с голям опит да предскажат достатъч-
но точно в ранен етап на разработването броя на редовете първичен код.
По въпроса за редовете първичен код се изтъкват следните проблеми:
-
Какво всъщност да се разглежда — физически или логически редове.
Физическият край на даден ред се получава с натискането на клавиша Enter,
което води до генериране на съответни служебни символи за край на реда. Ло-
гическият край е някакъв ограничител, зависещ от конкретния език за програ-
миране, например двоеточие, запетая или друг точно определен знак. Езици,
които позволяват написването на няколко оператора на един ред, могат да да-
дат неколкократна разлика при двата вида броене. Същото може да се случи в
обратна посока и когато (за прегледност или по други причини) един логически
оператор се разполага върху 2 или повече реда. Показателно е едно изследване
[7], което показва, че в САЩ 35% от ръководителите на проекти броят физи-
ческите редове, 15% броят логическите, а останалите 50% въобще не смятат за
уместно да борят редовете първичен код.
-
Друг елемент на несигурност внасят различните от семантична гледна
точка типове редове. Почти всеки процедурен език включва 4 типа първични
редове:
-
изпълними оператори, чрез които се задават различни операции (логи-
чески, аритметични, вход/изход и др.);
-
определения на данни, чрез които се дефинират различните типове данни;
-
коментари, които дават разясняваща информация;
-
празни редове, които се ползват за повишаване прегледността на прог-
рамата.
Установено е, че в дадено типично бизнесприложение около 40% от общия
брой оператори за изпълними, 35% са определения на данни, 15% са комента-
ри и 10% — празни редове. При системния софтуер (например операционни
130
системи) 45% са изпълними оператори, 30% са определения на данни и отново
15% са коментари и 10% празни редове.
Правени са изследвания сред създателите на софтуер и отново е установе-
но различие в разбиранията — 10% броят само изпълнимите редове, 20 % бро-
ят изпълнимите редове и определенията на данни, 15% добавят коментарите, а
5% броят дори и празните редове. Както вече беше казано, 50% въобще не
броят редовете първичен код.
3. Голям проблем е повторно използваемият код. По съвсем общи оцен-
ки един програмист на традиционните процедурни езици за програмиране Фор-
тран, С, КОБОЛ, средно копира от други програми между 20 и 30% код в сво-
ите програми. За обектно ориентирани езици като Smalltalk, C++ този процент
достига до 50. Има отделни софтуерни фирми, които са организирали специал-
ни библиотеки от модули за повторно използване и там въпросният процент
достига дори 75. При това положение спорът се върти около това как да се брои
даден повторно използван модул:
-
да се брои при всяко негово появяване;
-
да се брои само веднъж независимо от броя появявания;
-
въобще да не се брои, доколкото този модул не е разработван за оценя-
вания проект.
Изследванията показват, че в САЩ първата алтернатива се прилага от 25%
от професионалистите, втората — от 20%, третата — от 5%. За останалите 30%
вече се разбра, че не броят.
4. Друга област на несигурност е как да се ползват редовете първичен код
при приложения, писани на повече от един език. Има данни, че около една
трета от софтуера в САЩ е написан на повече от един език за програмиране.
Колкото и да изглежда невероятно, дори около 1996 година най-срещаните ком-
бинации от езици все още са били следните:
-
КОБОЛ заедно с някакъв език за обработка на заявки за търсене от типа
на SQL;
-
КОБОЛ и език за дефиниция на данни от типа на DL/1;
-
КОБОЛ и някакъв специализиран език;
-
С и Асемблер;
-
АДА и Асемблер.
Доколкото, както стана вече ясно, няма стандарти и единство дори при
броенето в приложения с един език, още по-малко, може да се очаква такова
единство при софтуер, написан на повече от език.
5. Има и някои допълнителни, по-малки проблеми от рода на това да се
включва или изключва временно поставен в програмата код, код от типа мак-
рос, код, свързан с управлението на заданието в рамките на операционната
система. Трудности предизвиква и разликата в стила на програмистите. Преди
време в IBM направили малък експеримент, като възложили на 8 програмисти
да напишат първичен код по зададена спецификация. Разликата в броя редове
първичен код (преброени, естествено, по една и съща фиксирана методика) меж-
ду най-големия и най-малкия била петкратна.
Независимо от критиката по горните 5 пункта моделът СОСОМО продъл-
жава да има своите привърженици и да се прилага. Причината е в особената
сложност и динамика на софтуера и неговото създаване и невъзможността, по-
не за момента, да се предложи напълно адекватен метод и модел. Това е и при-
131
чината да са създадени и да продължават да се предлагат и да се усъвършенст-
ват немалък брой методи, независимо от огромните усилия, необходими за съз-
даването, валидирането и прилагането им.
10.4. Метод на функционалните точки
10.4.1. История и мотиви
Методът на функционалните точки е предложен през 1979 г. от Олбрихт
[5]. След това самият той в съавторство [6], както и много други учени работят
усилено и продължително върху усъвършенстването му, практическото му при-
ложение, сравнението му с други модели и методи.
Основният мотив на автора са недостатъците на фактора брой редове първи-
чен код. Както видяхме, той е основата на няколко модела, сред които най-пред-
ставителен е COCOMO. Като най-съществени негови недостатъци вече изтък-
нахме трудната му ранна определяемост и липсата на единно виждане за същ-
ността му. Поставяйки си за цел да намери по-добър фактор в това отношение
(ясен и лесен за определяне в ранен стадий на производствения процес), Олбрихт
достига до понятието „функционална точка". На основата на този базов обект
той изгражда модел и метод и по-късно ги подобрява. Главната му идея е, че уси-
лията за разработването на даден софтуер (а следователно и цената му) се опре-
делят от неговата функционалност. Последната може да бъде измерена на осно-
вата на въпросните функционални точки. Доколкото функционалните точки (респ.
техният брой и вид) могат да бъдат определени с помощта само на някои първо-
начални проектни документи от типа на съглашение за изискванията и външна
спецификация, това означава и ранно получаване на желаните оценки.
Всъщност в цитираната вече[5] Олбрихт сам формулира в явен вид 5 цели,
които се стреми да постигне със своето предложение за модел и метод:
-
да се използват външните характеристики на софтуера;
-
да се третират средства, важни за крайния потребител;
-
да може да се прилага в ранна фаза на производствения процес;
-
да може да се свърже лесно с икономически оценки;
-
да има независимост от редовете първичен код.
10.4.2. Същност на модела
Моделът се основава на 5 функционални типа. Това са 5 непресичащи се
класа от обекти с точно определени функции. Допълнително се определят по 3
нива на сложност — просто, средно, сложно — за всеки тип. Тези типове са
следните:
Външен входен тип (External Input Type) — такъв е всеки потребителски
входен управляващ поток или поток от данни, който пресича външната граница
на измерваното приложение и който добавя или изменя данни в даден вътрешен
логически тип. Този тип може да бъде:
— прост, когато съдържа малък брой типове данни и когато тези данни се
отразяват върху малък брой вътрешни логически типове;
132
-
междинен, когато не може да се определи еднозначно нито като прост,
нито като сложен;
-
сложен, когато съдържа значителен брой типове данни и когато тези дан-
ни се отразяват върху голям брой вътрешни логически типове; при това проекти-
рането на външния входен тип изисква значителни допълнителни усилия, тъй ка-
то трябва да се вземат предвид проблемите на човеко-машинния интерфейс.
Типичен пример за този тип са входните екрани. Въвежданите чрез тях
данни "навлизат" в приложението и променят един или повече вътрешни логи-
чески типа.
Външен изходен mun (External Output Type) — такъв е всеки потребител-
ски изходен управляваш поток или поток от данни, който напуска външната
граница на измерваното приложение. Като примери могат да се посочат раз-
лични видове съобщения до потребителя или изходни отчети. Класифициране-
то на този тип на трите нива на сложност е аналогично на предходния тип.
Допълнително за видовете отчети се ползват следните определения:
-
прост — отчетът съдържа една или две колони, данните почти не се
преобразуват при извеждането им;
-
междинен — отчетът съдържа много колони, налични са междинни суми
по нива;
-
сложен — резултатите в отчета се получават след сложни преобразувания
на данните, налага се комбиниране на данни от много и сложни файлове, налага
се да се вземат мерки за постигане на по-добра ефективност на обработките.
Вътрешен логически файлов тип (Internal Logical File Type) — такава е вся-
ка съществена група от потребителски данни или управляваща информация. Типич-
ни примери са логическите файлове и въобще всяка логическа група от данни, обо-
собена като такава поради потребителска представа и която се генерира, използва и
поддържа от приложението. Класифицира се на три нива по следния начин:
-
прост — малко типове записи, малък брой типове елементи от данни, не
се изискват усилия за постигане на ефективност или за съхраняване и възстано-
вяване;
-
междинен — типът не може еднозначно да се определи като прост или
сложен;
-
сложен — голям брой типове записи и типове елементи от данни, изис-
кват се специални грижи за осигуряване на по-висока ефективност, както и за
процедури по запазване и възстановяване.
Външен интерфейсен файлов тип (External interface File Type) — това е
файл, който се предава или се ползва съвместно от две или повече приложения.
За да се определят трите нива на сложност, се ползват дефинициите за вътреш-
ния логически файлов тип.
Външен справочен mun (External Inquiry Type) — всяка комбинация вход/
изход, при която входът предизвиква незабавен изходен резултат. Такива ком-
бинации се реализират например в дадена информационна система, когато пот-
ребителят формулира и въведе заявка и получи от приложението съответния
отговор. Класификацията на трите нива се определя така:
-
входната част се класифицира съгласно определенията за външния вхо-
ден тип;
-
изходната част се класифицира съгласно определенията за външния из-
ходен тип;
133
— сложността на външния справочен тип е равна на по-голямата от така
определените две сложности.
10.4.3. Процедура по пресмятането
Преброяват се елементите на всеки от упоменатите 5 функционални типа.
След това за всеки елемент от всеки функционален тип се определя нивото
на сложност съгласно дадените вече определения.
С така получените данни се попълва следната таблица (табл. 10.4.):
Обозначението „X а" в трите колони за сложностите означава, че получе-
ната за тази клетка бройка трябва да се умножи по теглото „а". Точките в коло-
ната „Общо" означават, че на това място следва да се попълни сумата от полу-
чените в предходните 3 колони числа.
Като се сумират 5-те числа от най-дясната колона, се получава общият
брой ненастроени функционални точки FC за изследваното приложение.
Следващата стъпка хронологично е предложена по-късно. Тя е предизви-
кана от осъзнатата от авторите необходимост от съществени уточнения и до-
настройки на така получения брой FC.
Разглеждат се изброените по-долу 14 характеристики и за всяка от тях
се определя степента й на влияние върху оценяваното приложение. Допусти-
мите стойности за всяка характеристика са от 0 до 5 и имат следния смисъл:
-
— не е налична или не влияе въобще
-
— незначително влияние
-
— умерено влияние
-
— средно влияние
-
— значително влияние
-
— силно влияние.
Самите характеристики са следните:
-
Данните и управляващата информация, използвани в приложението, се
изпращат или получават по комуникационни линии.
-
В приложението има разпределена обработка на данни.
-
За приложението е важно достигането на висока ефективност.
-
Приложението ще се експлоатира върху силно натоварена операцион-
на конфигурация — хардуер и софтуер.
-
Интензивността на транзакциите е висока.
134
-
Наличен е интерактивен режим на въвеждане на данни и на управля-
ваща информация.
-
Цели се ефективност от гледище на потребителя.
-
Наличен е интерактивен режим на актуализирането на данните.
-
Логиката на обработките е сложна (многобройни логически и матема-
тически уравнения, необходимост от обработка на много изключения и др.).
-
Програмният код трябва да е повторно използваем (reusable).
-
Цели се лесно инсталиране.
-
Цели се лесна експлоатация (ефективна начална процедура, съхра-
няване, възстановяване и др.).
-
Приложението може да се ползва за разнообразни потребители.
-
Приложението е гъвкаво и лесно се модифицира.
Определя се величината PC (processing complexity) като сума от 14-те оп-
ределени стойности. Очевидно тя е в интервала [0,70].
На нейна основа се определя коригиращият коефициент РСА (processing
complexity adjustment) по формулата
РСА = 0.65 + (0.01 х РСА)
Ясно е, че РСА ще бъде в интервала [0.65, 1.35].
Крайният резултат — настроеният брой функционални точки FP (Function
Points Measure), ce получава по формулата:
FP = FC х РСА
Лесно се вижда, че коригиращият коефициент РСА всъщност коригира пър-
воначалния резултат с +/- 35%.
10.4.4. Използване на модела
При наличието на достатъчно статистически данни не е трудно да се опре-
дели цената на създаване на една функционална точка. Оттук лесно може да се
пресметне и очакваната цена на разработване на даден софтуерен продукт.
Изследванията, свързани с функционалните точки, са довели и до други
много интересни резултати, свързани, най-общо казано, с икономиката на соф-
туера.
Едно такова изследване според [7] показва какъв е приблизителният брой
функционални точки, притежавани от определен тип организация в САЩ.
Ясно, че е възможно да се прегледа с приемливо равнище на точност наличният
в дадена фирма софтуер и за всеки продукт да се определи броят функционал-
ни точки. Ето каква картина се получава за различните групи (табл. 10.5.):
По подобен начин са получени данни и какво количество функционални
точки използват избрани групи от потребители в САЩ. Резултатите са дадени в
Табл. 10.6.:
Както и авторът на [7], следва да отбележим изрично, че данните от тези 2
таблици могат да съдържат значителни отклонения. Основни причини са пионер-
ският им характер и динамиката на някои от професиите (почти е сигурно напри-
мер, че в областта на телекомуникациите консумацията на софтуер е нараснала
значително през последните години). Независимо от това, вижда се обещаваща
методология за изследване на различни аспекти на икономиката на софтуера.
135
![](2714_html_m1f11e617.gif)
За да дадем представа за пътищата, по които са се развивали разглежданите
тук модели, ще направим кратък преглед на още някои от тях.
10.5.1.Doty
Този модел наподобява COCOMO. Основава се на 2 формули:
Сподели с приятели: |