Софтуерни технологии
Табл. 10.1. Типове проекти по големина
Изтегляне 3.19 Mb.
|
- Навигация на страницата:
- Табл. 10.2. Типове софтуерни проекти
- Норма- лен Висок Много висок
- Атрибути на компютъра
- Атрибути на изпълнителя
- Атрибути на проекта
- Табл. 10.3. Атрибути и рейтинги
- 10.4. Метод на функционалните точки
Табл. 10.1. Типове проекти по големина Намаляването на производителността с нарастването на размера на проект та е естествена — тя се обяснява с увеличаването на броя на взаимодействията между растящия брой членове на колектива разработчик, всяко от които изиск- ва допълнителни усилия и следователно отнема от времето за директно създава- не на първичния код. 10.3.4. Усъвършенстване на модела Първото усъвършенстване на дотук изложения базов модел е въвеждане- то на 3 типа софтуерни проекти — разпространен, полунезависим и вграден (макар и немного сполучливи, това са използвани вече в нашата литература преводи на оригиналните термини organic, semidetached, embedded). 3a всеки от тях формулата е различна. В табл.10.2. всеки тип се характеризира кратко, илюстрира се с примери и му се съпоставя предложената от Боем формула. Следващото усъвършенстване е свързано с установяването на факта, че все пак редовете първичен код не биха могли да са единственият параметър на установената формула. Преминава се към по-сложни модели — междинен (intermediate) u детайлен (detailed), в които се отчитат допълнителни фактори. Те заедно с възможните им рейтинги са дадени в табл.10.3. 128
Табл. 10.2. Типове софтуерни проекти
Табл. 10.3. Атрибути и рейтинги 129  При извършването на оценката експертите следва да се ръководят от тази
таблица и за конкретния проект трябва да определят за всеки атрибут съответ- ния рейтинг. Получените стойности се заместват в формулата, която вече е при- добила по-сложен вид: ЧМ = к х ХРПКР х A1 x A2... х А15, където ЧМ и ХРПК са вече познатите величини, к и р са коефициенти, които са различни за различните типове софтуер, както се вижда и от табл. 10.2. А, са рейтингите на атрибутите Разликата в междинния и детайлния модел е в начина на получаване на
Основните критики към СОСОМО се свеждат до следните две:
По въпроса за редовете първичен код се изтъкват следните проблеми:
редове:
Установено е, че в дадено типично бизнесприложение около 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 година най-срещаните ком- бинации от езици все още са били следните:
Доколкото, както стана вече ясно, няма стандарти и единство дори при броенето в приложения с един език, още по-малко, може да се очаква такова единство при софтуер, написан на повече от език. 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
Определя се величината PC (processing complexity) като сума от 14-те оп- ределени стойности. Очевидно тя е в интервала [0,70]. На нейна основа се определя коригиращият коефициент РСА (processing complexity adjustment) по формулата РСА = 0.65 + (0.01 х РСА) Ясно е, че РСА ще бъде в интервала [0.65, 1.35]. Крайният резултат — настроеният брой функционални точки FP (Function Points Measure), ce получава по формулата: FP = FC х РСА Лесно се вижда, че коригиращият коефициент РСА всъщност коригира пър-
При наличието на достатъчно статистически данни не е трудно да се опре- дели цената на създаване на една функционална точка. Оттук лесно може да се пресметне и очакваната цена на разработване на даден софтуерен продукт. Изследванията, свързани с функционалните точки, са довели и до други много интересни резултати, свързани, най-общо казано, с икономиката на соф- туера. Едно такова изследване според [7] показва какъв е приблизителният брой функционални точки, притежавани от определен тип организация в САЩ. Ясно, че е възможно да се прегледа с приемливо равнище на точност наличният в дадена фирма софтуер и за всеки продукт да се определи броят функционал- ни точки. Ето каква картина се получава за различните групи (табл. 10.5.): По подобен начин са получени данни и какво количество функционални точки използват избрани групи от потребители в САЩ. Резултатите са дадени в Табл. 10.6.: Както и авторът на [7], следва да отбележим изрично, че данните от тези 2 таблици могат да съдържат значителни отклонения. Основни причини са пионер- ският им характер и динамиката на някои от професиите (почти е сигурно напри- мер, че в областта на телекомуникациите консумацията на софтуер е нараснала значително през последните години). Независимо от това, вижда се обещаваща методология за изследване на различни аспекти на икономиката на софтуера. 135
 
За да дадем представа за пътищата, по които са се развивали разглежданите тук модели, ще направим кратък преглед на още някои от тях. 10.5.1.Doty Този модел наподобява COCOMO. Основава се на 2 формули: Каталог: fmi -> fmi-ftp-upload-folder -> 4%20Semestur%202005 -> Predmeti -> AMP AMP -> Спецификация на софтуерен проект fmi-ftp-upload-folder -> Oracle e-business Suite Модул Financials, подмодул Fixed Assets fmi-ftp-upload-folder -> Бази от данни Упражнение 9 fmi-ftp-upload-folder -> Basic structures напишете pl/sql блок, който въвежда номера в таблицата messages AMP -> Спецификация на изискванията AMP -> 10. Управление на документацията Документация предназначена за разработчиците AMP -> 1. Анализ на риска Изтегляне 3.19 Mb. Сподели с приятели:
|