Софтуерни технологии
Метод на функционалните точки
Изтегляне 2.27 Mb.
|
Свързани:
empty doc
| 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) — такъв е всеки потребител- ски изходен управляваш поток или поток от данни, който напуска външната граница на измерваното приложение. Като примери могат да се посочат раз- лични видове съобщения до потребителя или изходни отчети. Класифициране- то на този тип на трите нива на сложност е аналогично на предходния тип. Допълнително за видовете отчети се ползват следните определения: прост — отчетът съдържа една или две колони, данните почти не се преобразуват при извеждането им; междинен — отчетът съдържа много колони, налични са междинни суми по нива; сложен — резултатите в отчета се получават след сложни преобразувания на данните, налага се комбиниране на данни от много и сложни файлове, налага се да се вземат мерки за постигане на по-добра ефективност на обработките. Изтегляне 2.27 Mb. Сподели с приятели:
|