Софтуерни технологии
Изтегляне 2.27 Mb.
|
Свързани:
empty doc
123
10.2. Критерии Критериите, формулирани от Боем, са следните. 10.2.1. Определеност Този критерий означава точно и обективно определяне на началните данни и понятия, както и на крайните резултати и количествените характеристики. Доколкото всеки метод на оценка се основава на някакъв модел на жизнения цикъл, то е много важно да се знае кои са точно фазите му и какво е тяхното съдържание, какви функции се изпълняват по време на всяка фаза и в какво точно се състои всяка от тях. Смята се, че една от причините моделът СОСОМО да е получил широка известност и приложение е тъкмо отличното спазване на този критерий. 10.2.2. Точност Има се предвид съответствието между предсказаната от модела цена на разработване и реално получилата се накрая. Изглежда, че наред със същността на метода от голямо значение е определеността и точността на входните данни, както и квалификацията на експертите, които правят оценката. Има различни начини за повишаване на точността. Колкото и авторите да се опитват да направят модела и метода си универсален, по правило той работи най-добре за определен клас програмни продукти. При всеки опит за прилага- нето му извън този клас точността на резултатите рязко се влошава и тогава се прави опит за настройка — промяна на базовите уравнения, добавяне на нови фактори, премахване на нерелевантни такива. Има твърде много изследвания, които показват недобра точност на немал- ко от методите дори при прилагането им към "подходящи" за метода продукти. Така например в [4] на основата на 15 големи проекта с прилагането на 4 раз- лични модела е показано, че при определянето продължителността на ня- колко (вече завършени) проекта грешката се е движила между 85% и 772%. Макар и не така разочароващи, грешки са показани и в точността на предсказ- ването на цената на разработван софтуер. 10.2.3. Обективност Както и при други оценяващи процедури, важен критерий е постигането на възможно най-голяма обективност, или иначе казано — максимално избяг- ване на субективния фактор. Навсякъде, където се очаква лична оценка от стра- на на експерти, се изготвят предварително указания, въвеждат се тегла, опреде- лянето на чиито стойности се формализира в рамките на възможното, предоста- вят се еталони. 124 10.2.4. Детайлност По принцип колкото един модел е по-подробен, толкова той е по-адеква- тен на реалните обекти и процеси и следва основаният на него метод да даде по- точни резултати. За съжаление по-дълбоката детайлност изисква както повече ресурси (време, хора, пари) в етапа на разработване на модела, така и при при- лагането му в конкретни случаи. При това положение се търси компромис меж- ду цената на извършваната оценка и желаната степен на точност. В споменатия вече СОСОМО този проблем е решен с помощта на предлаганите 3 версии на модела — базова, междинна и детайлна. 70.2.5. Устойчивост Този критерий е въведен от Боем с цел отделяне на неподлежащи на оцен- ка разработки поради съществуващи граници на приложение на метода. Така например неустойчив се оказва моделът DOTY, при който започват да се наб- людават силни отклонения в оценките при продукти с над 10 000 реда първичен код. Самият Боем признава, че неговият модел СОСОМО също може да се по- каже като неустойчив при оценяване на малки проекти — до 2 000 реда първи- чен код. Една от причините за това явление е, че всички модели са създавани на основата на изследване на големи и много големи проекти и уравненията, чрез които се пресмятат оценките, се базират на тях. Впрочем има правен опит — моделът P3 programmer's Personal Planner), предназначен за относително мал- ки проекти — до 18 000 първични реда и до колектив от максимум 3 души. Подобен модел представлява особен интерес днес, при непрекъснато растящи- те нужди от малки програмни продукти за персоналните компютри. 10.2.6. Област на приложение Както казахме, няма универсален модел за определяне цената и продължител- ността на разработване на софтуерен продукт. Следователно за всеки модел трябва да може ясно да се определи областта на приложение. Така например PRICE S е предназначен за оценка на аерокосмически софтуер, знае се, че методът на функ- ционалните точки работи най-добре за информационни системи и бизнесприложе- ния. Областта на приложение на някои модели е по-широка благодарение на въз- можността определени коефициенти в уравненията за оценка да бъдат предвари- телно променяни. Отново пример е СОСОМО, както ще се види по-нататък. 10.2.7. Конструктивност Всеки модел трябва да дава възможност да бъдат анализирани и разбрани получените резултати. Както се видя, в известни случаи даден модел води до по- ниски или по-високи резултати от реално получените накрая. Винаги обаче тряб- ва да бъде възможно тези отклонения да бъдат обяснени. Целта е конструктив- на — подобряване на модела. 125 Към тази характеристика спада и още една особеност. Моделът трябва да бъде конструктивен и в смисъл, че допуска получаването на различни резулта- ти в зависимост от това, на какъв фактор потребителят придава по-голямо зна- чение. С други думи, моделът може да предлага различни алтернативи според това, дали се държи на скъсяване на сроковете (разбира се, в допустимите гра- ници) за сметка на ползването на повече или по-скъпа работна сила или пък точно обратното. 10.2.8. Простота на прилагане Този критерий определя степента на трудност на разбирането и получава- нето на входните данни, както и степента на трудност на изпълнение на проце- дурите по оценяване. По принцип по-добра точност се получава при по-голяма детайлност, която обикновено се реализира йерархично. В този случай обаче нараства значително трудоемкостта, а и множеството фактори също усложня- ват прилагането на метода. Ясно е, че става дума за критерий, който е в пряка зависимост с други критерии — точност, определеност. Тази бележка впрочем може да се обобщи — десетте разглеждани критерия са в голяма степен зависи- ми и често подобрение в един от тях води до влошаване в други. 10.2.9. Предсназуемост Този критерий засяга проблема за практическото използване на моделите. Ясно е, че стремежът на всеки потребител е да получи възможно най-точна оцен- ка колкото се може по-рано в процеса на разработване на софтуер. По-нататък, при разглеждането на модела СОСОМО ще видим, че той се основава на броя редове първичен код. За съжаление това не е толкова лесно предсказуем пара- метър, т. е. дори и много голям опит не може да гарантира сравнително точно определяне на този брой в началната фаза на жизнения цикъл на софтуерния продукт. Значителна част от изследователските усилия са били и продължават да бъдат съсредоточени тъкмо на този проблем: като входни данни — основа на съответния метод да се избере точно и раннопредсказуем фактор. 10.2.10. Икономичност Това изискване е очевидно, но и то като много от вече изброените има компромисен характер. От една страна, желателно е входните данни за оценка- та да бъдат по-малко на брой и лесно измерими, от друга — да не са прекалено малко, така че да доведат до фатална неточност на крайните резултати. С други думи — желателна е икономичност, но не и на всяка цена. При отделни модели е забелязано, че когато се преминава от една област на приложение към друга, някои от факторите се оказват в новата област толкова взаимосвързани, че от- падането на някои от тях става възможно. По този начин се повишава иконо- мичността на модела. 126 Изтегляне 2.27 Mb. Сподели с приятели:
|