Софтуерни технологии
Изтегляне 2.27 Mb.
|
Свързани:
empty doc
| Вътрешен логически файлов тип (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 За да дадем представа за пътищата, по които са се развивали разглежданите тук модели, ще направим кратък преглед на още някои от тях. 10.5.1.Doty Този модел наподобява COCOMO. Основава се на 2 формули: Изтегляне 2.27 Mb. Сподели с приятели:
|