Софтуерни технологии
Изтегляне 3.19 Mb.
|
- Навигация на страницата:
- 2.4. Модел на Гънтър
| Нели Манева • Аврам Ескенази
СОФТУЕРНИ ТЕХНОЛОГИИ Издателска къща «Анубис* София,2001 2.3.2. функционален модел Най-характерният пример за функционален модел е разработеният от Xa- милтън и Зелдин [2] — в нашата класификация той попада в категорията с код 1.1.2. Според тези автори най-същественият признак, по който следва да се декомпозира ЖЦ на ПП, е типът извършвани дейности. Такава група от прили- чащи си дейности по този модел се нарича функция. Следващата схема илюст- рира разглеждания функционален модел. разработването на много големи софтуерни системи. В този модел се отделя особено внимание на дейностите по съпровождането. В този смисъл Фокс като че ли изпреварва своето време. Доста по-късно от неговата книга [3] се появяват, от една страна, задълбочени изследвания, които обективно доказват голямата цена на съпровождането (като агрегация на усилия, квалификация, време и други ресурси), а така също все повече се среща идеята за непрекъс- натото усъвършенстване на веднъж разработения ПП. На фиг. 2.3. е илюстри- ран моделът на Фокс. 
 Дефинирането на проблема би следвало да дойде от взаимодействието
на потребителя с разработчика. Анализът представлява изясняване на проблема и избиране на решение в най-общия му вид. Разпределението на ресурсите е особена функция, доколкото в другите модели на практика не се среща. Тук в нея се включва планирането и разпреде- лението на всякакви ресурси, необходими за изпълнението на разработката — човешки, хардуерни, софтуерни, документационни и пр. Документирането е функцията, резултатът от която са различните видо- ве документация — вътрешна (за нуждите на разработката), потребителска (за нуждите на експлоатацията, която се извършва от потребителя) и съпровожда- ща (за нуждите на съпровождането, следователно отново става въпрос за вът- решна документация, ползвана от самия разработчик). Изпълнението е реализацията на планираните и фиксирани във вече изб- роените функции дейности. Всички функции са свързани с една управленска, която въплъщава идеята за непрекъсната управляемост и контролируемост на процесите по разработва- нето на програмния продукт. Логическата връзка между отделните функции се илюстрира от стрелките и тяхната посока. Този модел, съгласно авторите му, се е използвал реално — на неговата основа е било разработено инструментално програмно средство (1111) под име- то USEIT. В литературата обаче не са известни други модели, изцяло и единст- вено основани на функционалността. 2.3.3. Разклонен модел на фокс Това е също особен модел (1.1.1.3. по класификацията). Той отразява гледната точка на един известен специалист с огромен практически опит от 22 Впрочем самият Фокс твърди, че терминът „съпровождане" не е подходящ, и използва "поддържане". Без да се впускаме в доводите на Фокс, ще игнорира- ме този негов възглед, за да постигнем единство в терминологията на всички разглеждани модели. Като важен принос на Фокс следва да разглеждаме въведената от него yc- поредност на две от фазите. Тази идея ще видим видоизменена по-нататък в каскадния модел. Разработването съгласно Фокс е най-тежката фаза от ЖЦ на ПП. Безп- роблемното използване зависи силно от вложените усилия при разработване- то. Съпровождането според Фокс може да отнеме при големи ПП толкова усилия, колкото и разработването. Известно внимание Фокс отделя на възможни модификации, които нарича патологични ЖЦ. При тях някоя от фазите не е застъпена или пък непрекъсна- тостта особено на връзката между разработването и съпровождането е разкъ- сана. Това се случва при някои разработки, когато тези две фази се възлагат на различни колективи. Ясно е, че такова равнище на подробност не би довело до адекватен модел, приложим за практически нужди, поради което Фокс въвежда още едно ниво за всяка от фазите, което съдържа разбивка на характерните за съответната фаза дейности („усилия", както ги нарича той). За разработването това са:
•— Написване на програмите
За съпровождането дейностите са следните: — Добавяне на нови функции 23
2.3.4. Тримерен модел на Питърс—Tpun Този модел (1.2.2. по класификацията) представлява само теоретически ин- терес. Той е опит да се обхванат заедно различни страни на процеса на разра- ботване на софтуер, но като че ли третото въведено измерение, свързано с из- ползваните формални апарати, няма практическо значение (поне равностойно на останалите две измерения). Съгласно авторите, следва да се разглеждат три измерения (аспекта) на раз- работването на ПП — време, логика и формализъм. Фигуративно те могат да се представят като паралелепипед. Ние ще се задоволим с кратко описание на тези три измерения.
избор на алтернатива. — Формализъм. В това измерение авторите включват необходимите спо- ред тях за разработването формални модели на ПП. Отличават се следните мо- дели по реда на тяхното възникване и реализация. Започва се чисто мислен модел, очевидно отразяващ първоначалните идеи на разработчика за ПП. Този модел се преобразува в структурен. Препоръчително е той да се базира на ня- какъв математически формализъм от рода на графи (евентуално някакъв фикси- ран тип графи — дървета, мрежи и np.). Последният модел е лингвистичен и той придобива формата на последователност от текстови оператори с определен синтаксис или семантика. С други думи казано, това е вече било проект на 1111 на определено ниво, описан формално, било ПП, реализиран във вид на опре- делен програмен език. 2.3.5. Частични модели Терминът „частични" вероятно търпи известна критика. Той е използван, за да се покаже, че в този тип модели по правило липсват съществени части от 24 естествения ЖЦ на ПП. Причината за това е, че тези модели се опитват да отразят т. нар. reuse техника, чийто смисъл е малко или повече използване на вече създадени компоненти от други ПП — програмни модули, проектантски решения, документация. Подходът на повторното използване се смята в мо- мента за изключително перспективен. Полагат се усилия за оценяването на резултатите от прилагането му, както и за разработването на подходящи инс- трументални средства — например библиотеки от модули за повторно изпол- зване с подходящи механизми за търсене на нужните на конкретния нов ПП компоненти. Като пример за такъв модел ще разгледаме предложения в [4]. Основното понятие в него е asset, чийто най-точен превод на български е като че ли не особено хубавата дума заготовка. Съгласно модела има няколко възможни рав- нища на ползване на заготовки. Съответната схема е дадена на фиг. 2.4. 
Във всички случаи прилагането на модела започва с оценка на изисквани- ята. Оттам нататък в зависимост от резултата първоначално става насочване или към ниво 3, или към ниво 2. Насочването към ниво 3 означава, че разработването на новия ПП е въз- можно практически изцяло на основата на заготовки. След подбора им следва сглобяването им и ПП е готов за разпространение. Следващ по сложност е вариантът с насочване към ниво 2. Прави се наст- ройка на избраните заготовки. На практика оттук са възможни два изхода:
Възможно е оценката на изискванията да покаже, че не е възможно насоч- ване нито към ниво 3, нито към ниво 2. В този случай насочването е към ниво 1. 25
достъпните заготовки. Оттук са възможни два изхода — точно както от наст- ройката на ниво 2. Последната възможност е ниво 0. Към процедурата на ниво 0 — проекти- ране и създаване на заготовки — не се отива непосредствено от оценката на изискванията. Насочването към нея е от ниво 1 или ниво 2, когато се е оказало, че получените програмни модули не отговарят на изискванията. Ясно е, че в този модел не са отразени някои от дейностите, характерни за разработването на ПП. Идеята е да се подчертаят най-важните и специфични дейности по използването на готови елементи. 2.3.6. Каскаден модел Това е модел от групата на хронологичните и модифицирани (1.1.1.2. по класификацията). Модификацията се състои в това, че отделните фази се при- покриват във времето. Това е една стъпка на подобрение на адекватността на модела на ЖЦ на ПП по отношение на стандартните модели. За илюстрация на фиг. 2.5. е един примерен вариант на каскадния модел. Трябва да отбележим, че в този пример степента на припокриване не съответства непременно на взаим- ното изображение на правоъгълниците. 
2.3.7. Прототипен модел Този модифициран хронологичен модел (1.1.1.2. по класификацията) се използва твърде интензивно в практиката. Същността му се състои в това, че се реализира умалена версия (прототип) на крайния ПП, върху която се правят експерименти за установяване на съответствие с изискванията на потребителя. В зависимост от получените резултати се правят корекции с различна степен на връщане към предходните стъпки. Естествено, колкото по-близко е връщането, толкова по-бързо и евтино става окончателното завършване на прототипа. След 26 окончателното доказване на правилността на функциониране на прототипа и съответствието му с изискванията за разработката се пристъпва към реализаци- ята на крайния ПП. Предимствата на такова прототипиране са очевидни — те спестяват различни ресурси на разработчика. Недостатъкът е липсата на гаран- ции, че прототипът ще съдържа всички съществени свойства на крайния ПП. В най-лошия случай може да се окаже, че поради неумело създаден прототип край- ният ПП е разработен със значително повече ресурси, отколкото ако се е про- цедирало по стандартния начин, без прототип. На фиг. 2.6. е илюстриран про- тотипният модел. 
Както се вижда, след преминаването за първи път през първите 3 фази се достига до оценка на прототипа. Обикновено се установяват несъответствия с изискванията. Тогава разработчикът се връща на предходната фаза и променя прототипа (отначало чисто програмно, после на ниво проект, ако трябва), след което отново прави оценка. След известно повторение на този цикъл може да се окаже, че само промяна в прототипа не води до желаните резултати и тогава връщането трябва да стане една фаза по-назад. Следователно се налага промя- на в определянето на някои изисквания. Това само по себе си е неприятно, защото всъщност изисква съгласието на потребителя (възложителя). Може оба- че да се окаже, че дори и такива реални промени не водят до установяване на съответствие прототип—изисквания. Тогава следва връщане в начално положе- ние, т. е. налага се да се направи наново изследване на проблема и възможнос- тите за реализацията му, вероятно да се достигне до установяване на пропусна- ти особености и отново да се повторят всички следващи стъпки до оценката на новия прототип. В даден момент прототипът отговаря на всички изисквания. Тогава се прис- тъпва към реализация на крайния ПП. Тестването, естествено, остава абсолют- но необходима процедура и едва след неговото успешно приключване може да се пристъпи към използването на така създадения ПП. 27
a 2.3.8. Еволюционен модел Във всички разглеждани дотук модели целият процес на разработка се ос- новава на създаването и използването на малко или повече формални описа- ния, наричани обикновено спецификации. Те създават яснота и определеност на разработването, но и създават трудности. Основната от тях е, че никой въз- ложител не е в състояние от самото начало да фиксира своите изисквания така, че те повече да не се изменят в процеса на разработката. Прототипният модел прави известен опит за преодоляване на тази трудност, но това е само зачатък. Еволюционният модел (1.3. по класификацията) се опитва да интегрира спе- цифициране, проектиране и реализация. Етапите в един еволюционен процес (забележете впрочем, че тук се говори за процес, а терминът „жизнен цикъл" се изоставя) са:
Този подход обикновено се поддържа от т. нар. езици от четвърто поколе- ние (4GL). Разработеният ПП може да се използва като база за строго специфи- циране на крайния ПП или да еволюира до ПП, който ще се достави на потре- бителя. Ясно е, че този модел води до ПП, съответстващ в най-висока степен на нуждите на потребителя. Същевременно той поставя и сериозни проб- леми [5]:
2.3.9. Спирален модел През 1988 година Боем [6] прави опит да интегрира еволюционния модел с изискванията на управлението, предлагайки спиралния модел (1.4. по класи- фикацията). В този модел разработването се движи спираловидно, основавайки се на спецификации. На всеки сегмент на спиралата се прави оценка на риска и се провежда редукция. При тази редукция се създават прототипи с оглед реду- 28 циране неопределеността на спецификациите, установяване на потребителски интерфейс и т. н. Това довежда или до обогатяване на спецификациите и до внасяне на по-голяма определеност в техния ПП, или пък до еволюция на про- тотипа до крайния ПП. При това се допуска различни компоненти на ПП да бъдат разработвани с прилагане на различни методи. Смята се, че еволюционният и спиралният модел са най-подходящи за раз- работването на интерактивни системи със значителен потребителски интерфейс и за авангардни системи (например основани на изкуствен интелект), чиито изис- квания много трудно могат да бъдат формулирани в началото. 2.4. Модел на Гънтър 2.4.1. Обща характеристика По-горе бяха изтъкнати съображенията за по-подробното разглеждане на този модел. Както се вижда, по класификацията той е в групата на двумерните модели — 1.2.1. Едното измерение е хронологично, другото — функционално. Съгласно хронологичното измерение, разработването на ПП преминава през 6 етапа, наречени фази. По време на тези фази с различна интензивност се осъ- ществяват 7 функции. 2.4.2. фази За всяка фаза ще определяме началния й момент, същността на фазата, какъв е резултатът в края на фазата и каква е средната й продължителност. Пос- ледната характеристика ще бъде давана така, както е определена от Гънтър при създаването на модела с изричната забележка, че при сегашното разнообразие от ПП, нови инструментални средства и въобще значителен технологичен нап- редък тези времена могат само да дават известна представа за съотнасянето по продължителност на отделните фази. Изследване Начало. Това е началото на ЖЦ на ПП и е моментът на възникване на идеята за създаване на ПП. Същност. През тази фаза се уточняват предназначението, основните фун- кции и изисквания към разработвания ПП. Обикновено тази фаза включва мар- кетингово проучване на съществуващите в момента на софтуерния пазар ана- логични ПП. Резултат. След анализиране на съществуващи или описани в литература- та аналогични ПП в края на фазата трябва да бъдат формулирани всички основ- ни изисквания към ПП. Както и по-нататък, всеки подобен резултат се оформя в писмен документ. В случая той се нарича съглашение за изискванията (СИ). Продължителност. 4—10 седмици. 29
Начало. Моментът на назначаване на ръководител на проекта. Същност. През фазата изследване се установява какъв ПП трябва да бъде разработван. Въпросът е може ли това да се осъществи. Предназначението на тази фаза е да се установи може ли да се създаде ПП. Това става чрез анализ на: а) Техническа осъществимост: анализ на достъпния хардуер както за осъществя- ване на разработката, така и за използване на готовия ПП. Освен вида на хардуера трябва да се анализират и необходимите за разработката други технически средства (инструментален софтуер, налични и изискуеми стандартизационни документи и np.). б) Икономическа осъществимост: анализират се и се оценяват в рамките на възможното цената на разработване, цена, на която би се продавал ПП, и цената за експлоатация на ПП. Анализът на цената на разработване трябва да завършва с пълна яснота, как ще бъдат осигурявани необходимите средства, т. е. икономи- ческата осъществимост показва и откъде ще се осигурят необходимите средства. в) Експлоатационна осъществимост: анализират се преимуществата и не- достатъците на замисления ПП от гледна точка на потребителите му, например: изисква ли се специална квалификация, какви технологични операции трябва да се извършват и дали са по силите на средния потребител, ще се реализират ли разумни стойност по отношение на бързината на обработките и т. н. г) Пазарна осъществимост: на основата на маркетингово проучване се прави опит да се прогнозира дали новият ПП ще се търси, може ли да бъде конкурентоспо- собен и какви ще са силните му страни в сравнение с аналогичните ПП. Този анализ е важен за изграждането на маркетинговата стратегия на фирмата по отношение на ПП. Анализът на всички видове осъществимост се извършва от група специа- листи със съответната квалификация. Резултат. След евентуални промени се утвърждават формулираните в СИ изисквания. Продължителност. 1—10 седмици след края на предишната фаза. Проектиране Начало. Съвпада с края на фазата изследване. Същност. Целта е обхващането и отразяването на потребителския възглед за ПП. Това се нарича външен проект на предвидения ПП. Той представя ПП като черна кутия, към която се подават определени данни и се получават определени резултати. В детайли се обсъжда с потребителя и се проектира потребителският интерфейс. Разглеждат се и се уточняват връзките на ПП с операционната среда и други софтуерни средства, с които е свързано използването на ПП. Резултат. Създаденият външен проект се оформя като документа "Външ- на спецификация". Продължителност. 10 седмици. Програмиране Начало. Програмирането може да започне, когато външната специфика- ция е представена в някакъв вид, макар да не е преминала окончателно формал- но утвърждаване. Във всички случаи обаче СИ трябва да е било утвърдено. 30 Същност. През тази фаза се създава детайлен (вътрешен) проект. В него фактически е описано как ще се реализира ПП. Създава се с цялостната струк- турна схема на ПП. Вътрешният проект представя детайлно архитектурата на ПП с пълно описание на всяка програмна част, описание на потока на данните и потока на управлението. Детайлният проект трябва да се опише на такова ниво на подробност, че по това описание да могат да се напишат програмите на ПП. През тази фаза се извършва и така нареченото модулно тестване, т. е. всяка програмирана единица се тества самостоятелно. След завършване на модулното тестване всички създадени програмни части се интегрират в един- на система, която по-нататък (но не в тази фаза) се тества като едно цяло (системно тестване) Резултат. Получава се работоспособен ПП, който може да бъде предста- вен за независимо тестване и последващи приемни изпитания. Продължителност. Особено силно зависи от сложността и обема на ПП. По принцип обаче Гънтър смята, че не трябва да надвишава 10 месеца. Ако предварителните оценки показват по-голяма продължителност, то проектът тряб- ва още в началото да се декомпозира на няколко отделни части с продължител- ност на фазата програмиране под 10 месеца. Оценка Начало. Това е моментът, в който ПП е сглобен от готовите програмни модули. Същност. Целта е да се извърши така нареченото независимо тестване, т. е. създаденият ПП да се тества от специалисти, които не са участвали в разра- ботването му. След това се провеждат приемни изпитания. Тяхната основна цел е да се провери съответствието между разработения ПП и СИ, съответствията между ПП и съставените за него спецификации; да се документира експлоата- ционната годност на ПП в реални потребителски условия; да се проверят качес- твата на документацията, включително нейната пълнота. Резултат. Документ (протокол, сертификат), удостоверяващ експлоата- ционната годност на ПП, който позволява последващо предаване за разпрост- ранение и експлоатация. Продължителност. Силно зависи от качеството на работа през предиш- ните фази. Най-оптимистичната оценка е 1/3 от продължителността на фазата програмиране. Има случаи обаче, когато се достига продължителността на прог- рамирането. Използване Начало. Това е моментът на издаване на документа за годност. Същност. Тази фаза включва инсталирането и последващата експлоатация на ПП. Извършва се обучение на потребителите с различна продължителност в зависимост от квалификацията на потребителите и сложността на ПП. Всички видове съпровождане (усъвършенстване, отстраняване на грешки, добавяне на нови функции) също се извършват по време на тази фаза. Резултат. Експлоатацията на ПП. Продължителност. Определя се от конкретния ПП. Физическият край на 31
ки край на ПП — когато след достатъчно дълъг период на използване ПП е достигнал до такова състояние, че не са необходими никакви съпровождащи дейности от страна на разработчика за този ПП. 2.4.3. функции Под функция се разбира съвкупност от сходни дейности, извършвани от група хора със съответната квалификация. Съгласно модела на Гънтър за всяка от седемте функции има отделна група от хора. Реално обаче това може да се осъществи само в големите софтуерни фирми. Планиране Тази функция обхваща дейностите по съставяне и проследяване на изпълне- нието на всички видове планове. В зависимост от обхвата си плановете се делят на: а) такива, които се отнасят до организацията производител (фирмата) като цяло:
б) свързани с всеки конкретен ПП:
Групата по планиране следва да се състои от хора с икономическо образо- вание и с някаква специализация в областта на информатиката и на софтуерни- те технологии. Най-интензивно групата по планиране работи по време на фази- те изследване и проектиране. Разработване Тази функция включва всички дейности, свързани с традиционните предс- тави за програмирането. Групата по разработване проектира, следователно със- тавя външната и вътрешната спецификация, извършва програмирането и тест- ването (разбира се, без независимото), отстранява грешки, сглобява готовите модули, консултира съставящите съпровождащата документация. Тази група включва специалисти информатици и е основната. Обслужване Основната идея на Гънтър, въвеждайки тази фаза, е, че не е възможно и разумно на висококвалифицирани специалисти да се възлагат дейности от чис- то технически характер. Дейностите по обслужването се разделят на следните групи: Каталог: 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. Сподели с приятели:
|
