Софтуерни технологии



страница12/18
Дата23.07.2016
Размер3.19 Mb.
#2714
ТипАнализ
1   ...   8   9   10   11   12   13   14   15   ...   18

Фиг. 9.2.

117


Наредбата на задачите е следната:



Първоначално ръководителят на проекта разпределя работата на разра-


ботчиците по задачите по следния начин:

9 дни
33 дни
12 дни

  1. души
    1 човек

  2. души

Задача 1
Задача 2
Задача 3

18 човекодни

  1. човекодни

  2. човекодни

Съответната Гант-диаграма показва, че за цялата фаза ще са необходими
45 дни.

Веднага се виждат два основни недостатъка на този график — фазата про-


дължава твърде дълго и средната производителност е около 40%. Затова ръко-
водителят на проекта решава да промени разпределението на разработчиците
по задачи, като определя 1 човек за първата задача, двама души за втората и
трима за третата:

18 дни
17 дни
12 дни

  1. човек

  2. души

  3. души

Задача 1
Задача 2
Задача 3

18 човекодни

  1. човекодни

  2. човекодни

Съответната Гант-диаграма на Фиг. 9.5. показва, че за цялата фаза са необ-
ходими 30 дни и средната производителност вече е 60%.

Този график е по-добър, защото продължителността на проекта е 30 дни



118

(при 29 дни от предварителната оценка) и производителността е близка до очак-


ваната.



Задача Работни дни

1 ... 17 18 19 ... 30

1
2
3


Фнг. 9.5.

Освен съставянето на графици организирането на проекта включва и про-


верка, дали те се спазват. Проследяването на проекти става чрез регламентира-
не на система за контрол. Контролират се основните параметри на проекта —
размер на междинните продукти, производителност на разработчиците, цена на
разработката, продължителност. Текущото състояние се сравнява с планирано-
то и при несъответствия се планират коригиращи действия. Основен принцип
на контрола на проекта е, че се контролира работата, а не работещите. Контро-
лът се основава на проверки за свършената работа по всяка задача и осъщест-
вяване на обратна връзка. Реализира се чрез последователност от проверки,
чрез които се натрупват контролни данни — отчети, справки, протоколи, екс-
пертни оценки и др. Основни техники за събиране на данни са провеждане на
интервюта, прилагане на инструментални средства, реализиращи процедурите
на измерване на зададени метрики, или преглеждане на материали, свързани с
реализацията на проекта. Данните се проверяват за правилност и непротиворе-
чивост (чрез сравняване с исторически данни, анализ от експерти или чрез про-
верка на процедурите за събирането им). Проверените данни се използват за
оперативно управление на проекта. Съществено е, че контролът трябва да обх-
ваща стандартните дейности и ситуации, а не изключенията. Нивата на контрол
са обикновено четири: организация, отдел, проект, работна група. За всяко ни-
во на контрол са определени съответни процедури.

9.7. Примерен план на софтуерен проект

Изложените по-горе управленски концепции и принципи се илюстрират


чрез съставяне на план на проекта, който след утвърждаването си е задължите-
лен документ, направляващ систематичната и организирана реализация на про-
екта. Предлаганата в [4] структура на плана е следната:

ПЛАН


I. Въведение

А. Предназначение на документа

Б. Цели на проекта

Цели


Основни функции

Изисквания към функционирането на продукта

Управленски и технически ограничения

II. Оценка на проекта

119

A. Исторически данни, използвани за оценката
Б. Техники за оценяване

B. Оценки

III. Рискове за проекта
А. Анализ на риска

Идентифициране на рисковите фактори


Оценка на риска

Б. Управление на риска

Техники за избягване на рисковите ситуации

Процедури за следене на рисковите фактори

IV. Управление на проекта чрез календарни планове и графици

A. Декомпозиране на работата по проекта на основни задачи


Б. Съставяне на мрежов график

B. Разпределение на ресурсите

V. Ресурси

A. Човешки ресурси

Б. Хардуерни и софтуерни ресурси

B. Специални ресурси

VI. Организация на екипа, работещ по проекта
А. Структура и състав на работната група

Б. Проследяване и отчитане на извършената работа

VII. Проследяване и контролиране на проекта

VIII. Приложения



9.8. Правила за осъществяване на софтуерни проекти

Натрупаният практически опит дава възможност да се формулират основ-


ни правила, спазването на които би повишило ефективността на реализираните
проекти. Списъкът от правила не е подреден, няма претенции за изчерпател-
ност и може да се разглежда като споделяне на know-how.

  1. Комуникации. Регламентират се начините на комуникации между дого-
    варящите се страни и всички участници в проекта — форма и честота на про-
    веждане, организиране и документиране.

  2. Определяне на крайния срок. Задава се продължителността на проекта
    в дни или месеци. Обикновено се определя датата, до която проектът трябва да

бъде завършен.

  1. Възлагане на проекта — само чрез писмен договор, подписан и одоб-
    рен от договарящите се страни.

  2. Подизпълнители. Изпълнителят може да възложи части от проекта на
    трета страна само след изричното съгласие на възложителя въз основа на под-
    договор, и то само ако са спазени изискванията към процеса на разработка и

към създавания продукт.

  1. Осигуряване на необходимата документация. Възложителят предос-
    тавя или съдейства за осигуряването на документация, материали, справки за
    законови или ведомствени разпоредби и други. Всички материали се връщат
    след завършване на проекта и съдържанието им е фирмена тайна.

  2. Финансова дисциплина. Изпълнителят трябва да документира всич-

120

ки разходи. Възложителят има право да изпрати финансови ревизори, на


които се предоставят всички необходими документи. Ревизията завършва с
ревизионен акт.

7. Задължения на изпълнителя:

  • да извърши съответната работа в договорения срок, обем и качество,
    изпълнявайки всички изисквания, определени в договора и приложенията към
    него;

  • да спазва законите и действащата нормативна база, а при възникване на
    особени ситуации да уведомява възложителя;

  • да реализира проекта ефективно.




  1. Конфиденциалност. Фирмената информация,'до която изпълнителят
    получава достъп при реализацията на проекта, не може да бъде разгласявана.

  2. Публични изяви, свързани с новоразработвания продукт, да се правят с
    цитиране на възложителя и само с изричното му съгласие.




  1. Индустриална и интелектуална собственост. Всички първични дан-
    ни и материали (диаграми, схеми, проекти, отчети, статистики, изводи и др.) са
    собственост на възложителя. Изпълнителят може да има копия от тях, за да из-
    пълнява проекта, но не може да ги използва и разпространява без изричното
    съгласие на възложителя. Изпълнението на проекта не може да нарушава чужди
    авторски права.

  2. Независимост. По принцип изпълнението на проекта не може да се
    обвързва с цели и средства на трета страна. При доказана зависимост догово-
    рът може да бъде прекратен едностранно от възложителя, който освен това мо-
    же да потърси правата си чрез съда.

  3. Работна група. Определя се в началото на проекта. Структурата и
    съставът й се описват в плана на разработката и се променят само със съгласи-
    ето на възложителя в случаите на невъзможност за участие или доказана неком-
    петентност. Работната група може да се разширява, за да се спази определен
    срок, но ако разширението не е съгласувано и одобрено от възложителя, е за
    сметка на изпълнителя.

  4. Проблеми. Възложителят оказва съдействие за разрешаване на проце-
    дурни, бюрократични или други трудности, възникнали при осъществяване на
    проекта.

  5. Отчети. Формата, броят и съдържанието на отчетите се определят в
    началото на проекта и се описват в плана за реализацията му. Отчетите могат да
    бъдат планирани или извънредни. След завършване на проекта се изготвя зак-
    лючителен отчет, който освен финансов анализ е и обзор на проблемите, въз-
    никнали при осъществяване на проекта.

  6. Закъсняване на проекти. Санкциите се описват в договора и могат да
    бъдат прекратяване на договора, продължаване за сметка на изпълнителя или
    плащане на неустойки.

  7. Удължаване на срока. Причини могат да бъдат формулиране на нови
    изисквания, неизпълнение на задължения на възложителя или непредвидени об-
    стоятелства. Препоръчва се предварително уведомяване и след разглеждане от
    двете страни — сключване на допълнително споразумение.

  8. Изменения на характеристики на проекта. Съгласуват се с изпъл-
    нителя, като се договарят измененията в цената и сроковете, които се отразяват
    в анекс към договора.

121

вано, фирмата производител е била осъдена да плати на клиента обезщетение
от десетки милиони долари.

Друг обичаен рисков фактор е срокът на доставка. Все още не е възмож-


но да се планира напълно сигурно крайният срок на доставка на разработван
програмен продукт поради — да гo кажем най-общо — огромния брой опреде-
лящи фактори, за част от които няма обективни измерители, а се разчита на
експертното мнение на опитни специалисти и ръководители. Неслучайно опи-
тът тук е от решаващо значение, защото е добре изследван и описан т. нар. 90%
синдром — неопитните софтуеристи ръководители, проектанти, програмисти)
планират и работят (несъзнателно) така, че обикновено 90% от програмния про-
дукт се завършват за определен (обикновено точно определен) период от вре-
ме, а за останалите 10% се оказва, че е необходимо в най-добрия случай още
толкова време.

1.2.7. Софтуерът средство, a не цел

Софтуерът е функция от трети ред. Това означава, че софтуерът е средст-


во, което задейства (управлява) някаква система, а тя самата довежда до иска-
ния резултат. Потребителят иска да получи документ в определена форма и с
определено съдържание, което става с помощта на компютъра, задействан от
текстообработваща програма. В случая документът е цел от първи ред. Компю-
търът е средството, с което се достига до резултата, и поради това е от втори
ред, а текстообработващата програма е от трети ред.

Смисълът на тази малко абстрактна конструкция е в това софтуеристите да


помнят винаги, че това, което създават, е всъщност само средство за постигане
на някаква цел. От доста време вече има трудове, посветени на психологията на
т. нар. „софтуерни фанатици" и техните приоритети, противоречащи на здра-
вия разум.

1.3. Софтуерни технологии

1.3.1. Терминология

Терминът Software Engineering се е появил за първи път на една конферен-


ция на НАТО през 1969 година. Както вече беше казано в началото, за най-
подходящ еквивалент на български смятаме софтуерни технологии, а отх-
върляме другия кандидат — софтуерно инженерство. Поучително е да се отбе-
лежи, че споменатата конференция е била проведена с цел обсъждане на проб-
лема със софтуерната криза. Няколко години преди това са се появили ком-
гпотрите от т. нар. трето поколение, тяхната мощност, превъзхождаща на поря-
дък тази на компютрите от второ поколение, е изисквала програмни продукти,
непознати дотогава по своя мащаб и сложност. Оказало се е, че в този период
не е било ясно как да се произведе такъв софтуер. Така възниква естествената
необходимост от специална дисциплина, която да се опита да помогне за прео-
доляването на софтуерната криза.

14

1.3.2. Определения

Известни са немалък брой определения на софтуерни технологии. Ето ня-
кои от тях:


  • Наур през 1969 година определя: установяването и използването на
    здрави принципи за разработване с цел по икономичен начин да се произведе
    софтуер, който е надежден и функционира ефективно върху реална машина;

  • според дефиницията на IEEE (Асоциацията на американските електрон-
    ни инженери) софтуерните технологии представляват систематичен подход към
    разработването, експлоатирането, съпровождането и изваждането от експлоа-
    тация на софтуера;

  • определението на Феърли от 1984 г. гласи: технологична и мениджърска
    дисциплина, занимаваща се систематично с производството и съпровождането
    на софтуерните продукти, които се разработват навреме и на основата на точно
    определени разходи.

Може да се смята, че второто от тези определения най-много се приближа-
ва до съвременното разбиране за същността на софтуерните технологии. Едно
допълнение, което смятаме за необходимо, е прилагателното „качествен" към
„софтуер". Второ, огромното разпространение на търговска основа на прог-
рамни продукти е свързано с техния маркетинг. От друга страна, изваждането
от експлоатация по важност и по съдържание далече отстъпва на другите еле-
менти на дефиницията. Следователно определението, което ще ползваме оттук
нататък, гласи:

Софтуерните технологии представляват систематичен подход
към разработването на качествен софтуер, както и към неговото
предлагане на пазара, експлоатация и съпровождане.


1.3.3. Цели

При така поставеното условие за качество на разработвания софтуер не-


обходимо е да се идентифицират основните му атрибути. Това ще бъде напра-
вено тук на най-общо ниво, а ще бъде разгледано подробно в специална глава
на тази книга.

Всеки програмен продукт следва да може да бъде лесно съпровождан.


Това означава, че в него трябва да могат относително лесно да се внасят изме-
нения и подобрения, както и лесно да се отстраняват грешки. За да може това
да се осъществява, е необходимо програмният продукт да бъде добре доку-
ментиран.

Софтуерът трябва да бъде надежден. Това означава, че грешките в него


трябва да сведени до възможния минимум, а продуктът да изпълнява очаквани-
те от потребителя функции.

Програмният продукт трябва да бъде ефективен. Това не означава изпол-


зване на възможностите на хардуера до границите на допустимото — най-мал-
кото защото такъв софтуер обикновено се съпровожда много трудно. Все пак
потребителят очаква оптимално в известен смисъл експлоатиране на ресурсите
на компютъра преди всичко по отношение на икономичното използване на опе-
ративната памет и достигането на голяма бързина на изпълнение.

15


18. Ползване на отпуск. Ако не е договорено друго, препоръчително е да
не се разрешава отпуск на членове на екипа, ако продължителността на проекта
е под 6 месеца. При по-дълги проекти може да се разрешава, като периодът на
отпуска се определя така, че да не се нарушава планираното изпълнение на

проекта.


  1. Плащания. Плащанията не могат да надхвърлят договорената стой-
    ност на проекта. Схемата за плащанията се приема в началото на проекта и не
    подлежи на промяна. Броят на междинните плащания зависи от продължител-
    ността на проекта, като е прието поне 20% да се изплащат след окончателното
    приемане на проекта. В условия на инфлация се допуска индексиране на цени-
    те по предварително договорена формула.

  2. Прекратяване на договора. Договаря се при какви случаи е възмож-
    но едностранно прекратяване, с какъв срок на предизвестие и с какви финансо-
    ви последици.




  1. Особени ситуации. При възникване на извънредни обстоятелства, въз-
    препятстващи изпълнението на задълженията на някоя от страните, се подписва
    допълнително споразумение за последствията.

  2. Разрешаване на противоречия. Противоречията и споровете се раз-
    решават чрез преговори, а ако не се постигне съгласие — по съдебен път.

Лumepamypa

  1. Page-Jones, Practical Project Management, Dorset House, 1985.

  2. Pressman, R. Software Engineering—A Practitioner'sApproach. R.S. Pressman & Associates,

Inc. 2000.

3. Charette, R., Software Engineering Risk Analysis and Management, McGraw-HilWntertext,

1989.

4. Spinner, M., Elements of Project Management: Plan, Schedule and Control. Prentice-hall, Inc..



Englewood Cliffs, New Jersey, 1981.

10. ЦЕНА НА СОФТУЕРА

10.1. Необходимост и цели

Всеки ръководител на софтуерен проект би желал във възможно най-ра-


нен момент от жизнения цикъл на разработвания програмен продукт да знае
колкото се може по-точно какви разходи ще трябва да се направят до завършва-
нето му и колко ще продължи целият процес.

С този проблем теоретиците започват да се занимават още през 60-те годи-


ни и в резултат се появява и първият метод за оценяване разходите по произ-
веждането на даден програмен продукт — SDC, 1965 г. Последват го още ня-
колко метода, основани на съответни модели, докато се стига до 1981 година,
когато се появява COCOMO, предложен от Боем [1].

Тази разработка се смята за фундаментална — от една страна, тя намира


реално приложение в практиката, а от друга — поставя на здрави основи пос-
ледващите изследвания по цената и по-общо — по икономиката на разработва-
нето на софтуер.

Оказва се обаче, че процесът на намиране цената на разработване води до


резултати, полезни и в други насоки [2]:

  • избор на проект за реализация — очевидно един от решаващите фак-
    тори при такъв избор е цената на бъдещата разработка;

  • определяне състава на колектива разработчик, което също е в
    пряка зависимост от установената цена и, обратно — изменяйки състава (по
    брой, квалификация, опит и др.), можем пряко да влияем върху цената на
    разработката;

  • определяне на маркетинговата политика по отношение разработва-
    ния софтуер — както е известно, цената е един от основните компоненти на
    т.нар. маркетингов микс (вж.11.4.2.);

  • оценяване работата на членовете на колектива — това може да
    става на основата на сравнение на предварително получените оценки с крайни-
    те резултати от работата.

Един от много важните приноси на Боем в споменатия труд [1] е, че той
формулира множество от критерии, които следва да удовлетворява даден мо-
дел, респективно метод, за установяване цената на разработване на софтуерни
продукти.


122

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


10.3. Моделът на Боем СОСОМО

10.3.1. Цели и основни идеи

СОСОМО произлиза от Constructive Cost Model.

Основната му цел е за всеки планиран софтуерен проект да се оцени цена-
та и срокът на разработване.

Основополагащите му идея е използването броя редове първичен код.

Първоначално предложеният модел е усъвършенстван в различни направ-
ления — чрез въвеждане на 3 нива на подробност, чрез отличаване на 3 типа на
разработване, чрез въвеждане на коригиращи коефициенти за определящите
параметри.

10.3.2. Същност на модела

За оценяване на трудоемкостта на даден софтуерен проект се прилага фор-


мулата:

ЧМ = 2.4 х ХРПК1.05,

където ЧМ означава брой човекомесеца

ХРПК означава хиляди реда първичен код.

За оценяване продължителността на разработване на софтуерния проект
формулата е:

В = 2.5 х ЧМ0.38,


където В е срокът на разработване в месеци.

Формулите се прилагат при следните предположения:

а) редовете първичен код (т. е. тези, които се пишат на някакъв език за
програмиране):


  • се броят без коментарните редове;

  • принадлежат на крайния продукт (а не на междинни негови версии);

  • не включват използваните стандартни програми;

б) включват се само фазите проектиране, програмиране и оценка, включи-
телно усилията по управлението и документирането по време на тези фази;

в) не се включват обучението, планирането и инсталирането на софтуера


при потребителя;

г) включва се трудът на проектантите и програмистите, но не и този на


компютърните оператори, висшите ръководители и секретарките;

д) смята се, че един човекомесец е от 19 дни, или 152 часа;

е) предполага се, че никакви сериозни промени не се правят в продукта
след одобряването на документа, който съдържа изискванията към него;

ж) двете страни — потребителят и разработчикът — се предполага, че са


добросъвестни през цялото време.

10.3.3. Пример и следствия

За илюстрация да дадем един прост пример.

Да предположим, че в резултат на предварителна експертиза бъдещият соф-

127






туерен продукт се оценява на 32 000 реда първичен код. Като приложим двете
формули, ще получим следните числови резултати:

ЧМ = 2.4 х 32105 = 91 (човекомесеца)

В = 2.5 х 91038 = 14 (месеца)

От тези базови резултати могат да се получат още две важни характеристики:



Производителност: 32 000 / 91 = 352 реда първичен код за човекомесец

Екип: 91 / 14 = 6.5 човека.

Тълкуванието на последната бройка е ясно — един или повече специалисти


от екипа ще бъдат заети с проекта не през всичките 14 месеца на разработката.

Правени са изследвания за това, как се изменя производителността с про-


мяната на размера на проекта. Боем предлага едно условно разделяне на проек-
тите на малки, междинни, средни и големи (колкото и възражения да предизвик-
ва една такава класификация). За тези 4 категории са получени следните данни,
показани в табл. 10.1:





Сподели с приятели:
1   ...   8   9   10   11   12   13   14   15   ...   18




©obuch.info 2024
отнасят до администрацията

    Начална страница