Софтуерни технологии
Изтегляне 204.11 Kb.
|
| 2.3.6. Каскаден модел
Това е модел от групата на хронологичните и модифицирани (1.1.1.2. по класификацията). Модификацията се състои в това, че отделните фази се при- покриват във времето. Това е една стъпка на подобрение на адекватността на модела на ЖЦ на ПП по отношение на стандартните модели. За илюстрация на фиг. 2.5. е един примерен вариант на каскадния модел. Трябва да отбележим, че в този пример степента на припокриване не съответства непременно на взаим- ното изображение на правоъгълниците. 2.3.7. Прототипен модел Този модифициран хронологичен модел (1.1.1.2. по класификацията) се използва твърде интензивно в практиката. Същността му се състои в това, че се реализира умалена версия (прототип) на крайния ПП, върху която се правят експерименти за установяване на съответствие с изискванията на потребителя. В зависимост от получените резултати се правят корекции с различна степен на връщане към предходните стъпки. Естествено, колкото по-близко е връщането, толкова по-бързо и евтино става окончателното завършване на прототипа. След окончателното доказване на правилността на функциониране на прототипа и съответствието му с изискванията за разработката се пристъпва към реализаци- ята на крайния ПП. Предимствата на такова прототипиране са очевидни — те спестяват различни ресурси на разработчика. Недостатъкът е липсата на гаран- ции, че прототипът ще съдържа всички съществени свойства на крайния ПП. В най-лошия случай може да се окаже, че поради неумело създаден прототип край- ният ПП е разработен със значително повече ресурси, отколкото ако се е про- цедирало по стандартния начин, без прототип. На фиг. 2.6. е илюстриран про- тотипният модел. Както се вижда, след преминаването за първи път през първите 3 фази се достига до оценка на прототипа. Обикновено се установяват несъответствия с изискванията. Тогава разработчикът се връща на предходната фаза и променя прототипа (отначало чисто програмно, после на ниво проект, ако трябва), след което отново прави оценка. След известно повторение на този цикъл може да се окаже, че само промяна в прототипа не води до желаните резултати и тогава връщането трябва да стане една фаза по-назад. Следователно се налага промя- на в определянето на някои изисквания. Това само по себе си е неприятно, защото всъщност изисква съгласието на потребителя (възложителя). Може оба- че да се окаже, че дори и такива реални промени не водят до установяване на съответствие прототип—изисквания. Тогава следва връщане в начално положе- ние, т. е. налага се да се направи наново изследване на проблема и възможнос- тите за реализацията му, вероятно да се достигне до установяване на пропусна- ти особености и отново да се повторят всички следващи стъпки до оценката на новия прототип. В даден момент прототипът отговаря на всички изисквания. Тогава се прис- тъпва към реализация на крайния ПП. Тестването, естествено, остава абсолют- но необходима процедура и едва след неговото успешно приключване може да се пристъпи към използването на така създадения ПП. Изтегляне 204.11 Kb. Сподели с приятели:
|