Софтуерни технологии
Изтегляне 204.11 Kb.
|
| 1
a 2.3.8. Еволюционен модел Във всички разглеждани дотук модели целият процес на разработка се ос- новава на създаването и използването на малко или повече формални описа- ния, наричани обикновено спецификации. Те създават яснота и определеност на разработването, но и създават трудности. Основната от тях е, че никой въз- ложител не е в състояние от самото начало да фиксира своите изисквания така, че те повече да не се изменят в процеса на разработката. Прототипният модел прави известен опит за преодоляване на тази трудност, но това е само зачатък. ^ Еволюционният модел (1.3. по класификацията) се опитва да интегрира спе- цифициране, проектиране и реализация. Етапите в един еволюционен процес (забележете впрочем, че тук се говори за процес, а терминът „жизнен цикъл" се изоставя) са: Формулиране първи вариант на изискванията към ПП. Тази „скица" не е необходимо да бъде нито пълна, нито дори непротиворечива, но трябва да дава достатъчно указания на разработчиците, какво се очаква от Ш1. Разработване на ПП възможно най-бързо на основата на така формули- раните изисквания. Оценяване на ПП съвместно с потребителите или с възложителя и вна- сяне на изменения с оглед предявените нови изисквания от него. Това означава изменение на първоначалната функционалност на ПП и добавяне на нова, ако е необходимо. Този подход обикновено се поддържа от т. нар. езици от четвърто поколе- ние (4GL). Разработеният ПП може да се използва като база за строго специфи- циране на крайния ПП или да еволюира до ПП, който ще се достави на потре- бителя. Ясно е, че този модел води до ПП, съответстващ в най-висока степен на нуждите на потребителя. Същевременно той поставя и сериозни проб- леми [5]: Тъй като се фокусира върху крайния потребител, моделът не дава доста- тъчно приоритет на организационните аспекти на разработването. Постоянното изменяне по време на разработката влошава структурата на ПП до такава степен, че съпровождането му може да стане изключително трудно и скъпо. На практика това означава, че след относително кратък период целият ПП ще трябва да се напише отново. Цялостният процес няма желаната прозрачност и по този начин ръко- водството на проекта не е в състояние да оцени развитието му. Това е основна- та причина ръководителите да се въздържат от прилагането на еволюционния модел при големи проекти, в които най-тежкият проблем е управлението. 2.3.9. Спирален модел През 1988 година Боем [6] прави опит да интегрира еволюционния модел с изискванията на управлението, предлагайки спиралния модел (1.4. по класи- фикацията). В този модел разработването се движи спираловидно, основавайки се на спецификации. На всеки сегмент на спиралата се прави оценка на риска и се провежда редукция. При тази редукция се създават прототипи с оглед реду- 28 циране неопределеността на спецификациите, установяване на потребителски интерфейс и т. н. Това довежда или до обогатяване на спецификациите и до внасяне на по-голяма определеност в техния ПП, или пък до еволюция на про- тотипа до крайния ПП. При това се допуска различни компоненти на ПП да бъдат разработвани с прилагане на различни методи. Смята се, че еволюционният и спиралният модел са най-подходящи за раз- работването на интерактивни системи със значителен потребителски интерфейс и за авангардни системи (например основани на изкуствен интелект), чиито изис- квания много трудно могат да бъдат формулирани в началото. Изтегляне 204.11 Kb. Сподели с приятели:
|