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



страница2/18
Дата16.11.2017
Размер3.19 Mb.
Размер3.19 Mb.
1   2   3   4   5   6   7   8   9   ...   18

32

а) административно-правни — свързани със съставянето на някои от доку-


ментите:

  • договори,

  • мрежови графици,

  • финансови отчети,

  • данъчна документация.

Частта от групата, отговаряща за този тип дейности, включва и специалист
с правно образование.

б) технически — състоят се в осигуряването на:



  • изчислителната техника и нейното поддържане,

  • заявените инструментални софтуерни средства,

  • стандарти и други нормативни документи.

в) изпитания от клас С — това са крайни изпитания, състоящи се в случаен
избор сред готовите за разпращане комплекти от ПП и проверката им за качес-
тво и комплектност.

Документиране

Съответната на тази функция група отговаря за създаването и поддържа-


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

Групата включва специалисти с филологическо образование, евентуал-


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

Изпитания

Тази функция обхваща дейностите по установяване на наличието на де-


фекти и на разлики между действителните свойства на ПП и спецификациите
му. Разграничават се 3 вида изпитания:

а) Клас А — вътрешни, извършвани от самите разработчици при програ-


мирането и сглобяването на ПП.

б) Клас В — независими, които се изпълняват от групата по изпитанията.

в) Клас С — случайни, описани по-горе и извършвани от групата по обс-
лужването.

Тъй като групата по изпитания се занимава с откриване на дефекти, тя се


състои от висококвалифицирани специалисти информатици.

Поддържане

Тази функция обхваща всички дейности, свързани с преките контакти на


фирмата производител с потребителите:

33

  • проучване на потребителското мнение във фазата анализ на осъществи-
    мостта;

  • защитаване интересите на потребителя още при избора на проектантски
    или програмистки решения;

  • обучение на потребителя;

  • регламентиране и осъществяване на обратна връзка с потребителя на
    даден ПП: получаване и систематизиране на съобщенията за грешки и на заяв-
    ките за изменения по искане от страна на потребителите;

  • връзки с обществеността.

Съпровождане

Обхваща всички дейности по внасяне на промени в готовия ПП:



  • поправяне на грешки;

  • добавяне на нови възможности;

  • адаптиране на ПП към нова операционна или хардуерна среда.

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

Съпровождането може да се извършва на различни равнища:

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

б) развитие на ПП и отстраняване на грешки;

в) отстраняване на грешки;

г) регистриране на съобщенията за грешки и на заявките за подобряване с оглед


вземането им под внимание при евентуално разработване на нов подобен ПП.

Режимът на съпровождане може да зависи от конкретно подписания дого-


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

На фиг. 2.7. са представени по хоризонталната ос фазите на ЖЦ на ПП, по


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

Литература

  1. Gunther R.C., Management methodology for software product engineering. New York, 1978.

  2. Hamilton M., S. Zeldin. The Functional Life Cycle Model and Its Automation: USE.IT J of
    System and Software, 3 (1983), p. 25—62.

  3. Fox J.M., Software and its Development. Prentice-Hall, Inc., Englewood Cliffs, 1982.

  4. Appleton D., The Asset-based Life Cycle Model, Very Large Projects, Datamation January
    15,1986,p.63-70.

  5. Sommerville I., Software Process Models, ACM Computing Surveys, Vol.28, No.l, March
    1996, p. 269-271.

  6. Boehm B.W., A spiral model of software development and enhancement. IEEE Computer 21
    5,p.61-72. ' '






Изследване

Осъщест-
вимост

Проекти-
ране

Програми-
ране

Изпитания

Използване

Планиране



















Разработване



















Обслужване



















Документиране



















Изпитания



















Поддържане



















Съпровождане



















Фиг. 2.7. Модел на Гънтър
34

35

3. КОНВЕНЦИОНАЛЕН ПОДХОД
ЗА РАЗРАБОТВАНЕ НА СОФТУЕР

Когато текущото състояние на научното знание не е в състояние да удов-


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

В тази глава ще представим основните принципи на традиционния подход


на разработване на софтуер, следвайки хронологичен модел на ЖЦ, последова-
телните фази на който са определяне на софтуерната система, проектиране,
програмиране, интегриране и тестване, използване.


3.1. Модели на жизнения цикъл и подходи за разработване

Проучването на специализираната литература показва, че продължава съз-


даването на нови модели на ЖЦ. Поради стремежа да обхванат най-различни
аспекти (технологични, организационни и икономически) новосъздаваните мо-
дели са все по-сложни и оттам — все по-малко приложими в практиката. Затова
в последно време усилията са насочени към разглеждане на noдxoдu за разра-
ботване. Всеки подход за разработване определя основните правила, практики
и процедури, които трябва да се следват в процеса на създаване на ПП.

Подходите могат да бъдат с различна степен на общност. Някои от тях


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

Най-общите фундаментални подходи се наричат парадигми. Ще разгранича-


ваме два такива подхода: традиционен (конвенционален) и обектно ориентиран.
Традиционният подход се е формирал с възникването на научното направление соф-
туерни технологии като възможно решение на т. нар. софтуерна криза. За съжале-
ние десетилетия след прилагането му някои тревожни симптоми на софтуерната
криза — висока цена на разработване и незадоволително качество — продължават
да се наблюдават. Затова бе създаден нов поход — обектно ориентираният. Такова
развитие е в пълно съответствие с диаграмата на Kuhn [1], показана на фиг. 3.1



3.2. Определяне на софтуерната система

Целта на тази фаза е да се определят предназначението и обхватът на соф-


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

3.2.1. Определяне на изискванията

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


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

Ще опишем целите, съдържанието и прилаганите техники за всяка от пос-


ледователните стъпки.

а) Формулиране на изискванията

Основна цел на този етап е съставяне на съвкупност от всички възможни
изисквания въз основа на определените вече предназначение и обхват на пред-
лаганата софтуерна система. В [2] е предложен подходът FAST (Facilitated Ap-
plication Specification Techniques). Съгласно този подход се съставят работни
групи с представители на потребителите и разработчиците, със съвместните
усилия на които се идентифицира проблемът, обсъждат се алтернативни реше-
ния и се подготвя предварително множество от изисквания. Регламентирани са
формите на комуникации, подготовката и организирането на ефективни обсъж-
дания и др. Друга подходяща техника е анализът на различните гледни точ-

37


ки, описан в [3]. Първоначално се идентифицират, например чрез „мозъчна атака"
(Brainstorming), всички възможни потребители на системата, които след това се
групират по сходство на гледните точки, които те представят. В резултат на
интервюта, провеждани от системните аналитици с членове на групата, разго-
вори и целенасочени обсъждания се определят изискванията на групата. Ако е
необходимо, се разработват сценарии (use-cases) за реализацията на някаква
основна функция и дори прототипи за нея, за да могат да се дефинират по-
точно съответните изисквания. Всяко изискване се описва (същност на изиск-
ването, кой и защо го предлага). Тази документация е необходима за по-ната-
тъшното разглеждане и оценяване.

б) Анализ на изискванията

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

в) Утвърждаване на изискванията

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

г) Проследяване на изискванията

Препоръчва се планиране на дейностите по проследяване на изискванията,
като в определените за проекта контролни точки се включат и проверки за пос-
тигнатата степен на удовлетворяване на избрана подсъвкупност от изисквания.

3.2.2. Аналитичен модел

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


изграждане на първия формален модел на целевата система — т. нар. аналити-
чен
модел. Той е резултат от проведения структурен анализ и предназначение-
то му е да улесни следващите дейности по проектиране. Основните съставящи
на аналитичния модел са:

а) Модел на данните

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

38

обекта включва описание на същността и на атрибутите му, които представят


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

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


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

За всяко отношение могат да се определят стойностите на две основни


характеристики: кардиналност и модалност. Кардиналността е характе-
ристика, която определя колко екземпляра от единия обект могат да са в отно-
шение с екземпляри от другия обект. Кардиналността се описва с „един" и ,мно-
гo" и може да бъде един-към-един (1:1 читател — ЕГН), един-към-много (l:N
читател — книги) и много-към-много (M:N читатели — групи по интереси).

Модалността определя дали отношението между два обекта е задължи-
телно (модалност 1) или незадължително (модалност 0). Например отношение-
то заема между читател — книга в двете посоки има модалност 0, защото във
всеки момент има читатели, които не са заели книги, и книги, които не са взети
от читатели.

Използвайки приетите означения, отношенията между разглежданите обек-


ти могат да се представят графично по следния начин:

Диаграма, представяща обектите и отношенията между тях, се нарича ди-


аграма елемент-връзка (entity-relationship diagram ERD). Тя е предложена за
пръв път от Чен [4] за проектиране на релационни СУБД и после многократно
е разширявана и по съдържание, и по форма. ERD е графично представяне, в
което обектите се представят с надписани правоъгълници, а отношенията —
чрез свързващите ги надписани линии. Въведени са специални означения за
кардиналността и модалността на всяко отношение.

Описанието на обектите и атрибутите им заедно с диаграмата, представя-


ща отношенията между тях, определят модела на данните.

б) Функционален модел

Предназначението на този модел е да представи основните функции на соф-
туерната система чрез проследяване на преобразуването на информацията в нея.
Диаграмата на потока на данните (Data Flow Diagram) e графично представяне,

39




Като задължителна част на аналитичния модел се разглежда и речникът на
данните, който представлява систематично и точно описание на всеки елемент
на данните, споменат в някой от моделите на софтуерната система. Описанието
на елемент от речника обикновено съдържа:

  • име на обекта;

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

  • списък на срещанията на този обект — къде и как се използва;

  • описание на същността на обекта;

  • допълнителна информация.

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

Фиг. 33

описващо трансформациите на данните така, че от входните данни в системата да


се получат исканите изходи. Използваните графични елементи са: правоъгълник
за означаване на външни обекти, предаващи или приемащи информация от сис-
темата; кръг — за означаване на функция, променяща данните по някакъв начин
и надписани стрелки, представящи съответните входни и изходни данни. Пример
за диаграма на потока на данните (ДПД) е показан на фиг. 3.3

Широкото практическо използване на ДПД се обуславя от тяхната изклю-


чителна простота и нагледност. Те могат да се съставят с различна степен на
детайлизираност. Например така наречената фундаментална ДПД (диаграма на
ниво 0) представя софтуерната система като една обобщена функция, преобра-
зуваща входа на системата в изхода. По-нататъшното анализиране изяснява ос-
новните функции, докато се достигне до описание, което може да бъде основа
за проектирането. Графичното представяне на функциите може да се съпътства
с допълнително описание на всеки елемент в ДПД. Това описание се нарича
спецификация на процеса. Освен входа, изхода и същността на извършваната
трансформация могат да се задават и допълнителни изисквания към всяка от
описваните функции.

Класическият структурен анализ е разширен с допълнителни техники за


отразяване на особеностите на определени класове софтуерни системи. Нап-
ример за моделиране на системи в реално време е предложено създаването на
диаграми на потока на управление [5]. Диаграмите на потока на управление
(ДПУ) и съответните им подробни описания, наречени спецификация на уп-
равлението
(control specification), могат да бъдат създавани с помощта на съ-
ответни инструментални средства.

в) Поведенчески модел

За някои видове системи се предлага създаването и на модел на поведението
на софтуерната система. При този подход системата се описва чрез различимите
си състояния и начина на преминаване от едно състояние в друго. Диаграмата
на преобразуване на състоянията (state transition diagram) представя графич-
но наблюдаваните състояния на системата (чрез правоъгълници) и събитията, пре-
дизвикващи преминаването от едно състояние в друго (чрез стрелки). Събитията
се описват чрез наредени двойки (пораждащо събитие, ответно действие).



Сподели с приятели:
1   2   3   4   5   6   7   8   9   ...   18


©zdrasti.info 2017
отнасят до администрацията

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