Studopediya

КАТЕГОРИЯ:


Астрономия- (809) Биология- (7483) Биотехнологии- (1457) Военное дело- (14632) Высокие технологии- (1363) География- (913) Геология- (1438) Государство- (451) Демография- (1065) Дом- (47672) Журналистика и СМИ- (912) Изобретательство- (14524) Иностранные языки- (4268) Информатика- (17799) Искусство- (1338) История- (13644) Компьютеры- (11121) Косметика- (55) Кулинария- (373) Культура- (8427) Лингвистика- (374) Литература- (1642) Маркетинг- (23702) Математика- (16968) Машиностроение- (1700) Медицина- (12668) Менеджмент- (24684) Механика- (15423) Науковедение- (506) Образование- (11852) Охрана труда- (3308) Педагогика- (5571) Полиграфия- (1312) Политика- (7869) Право- (5454) Приборостроение- (1369) Программирование- (2801) Производство- (97182) Промышленность- (8706) Психология- (18388) Религия- (3217) Связь- (10668) Сельское хозяйство- (299) Социология- (6455) Спорт- (42831) Строительство- (4793) Торговля- (5050) Транспорт- (2929) Туризм- (1568) Физика- (3942) Философия- (17015) Финансы- (26596) Химия- (22929) Экология- (12095) Экономика- (9961) Электроника- (8441) Электротехника- (4623) Энергетика- (12629) Юриспруденция- (1492) Ядерная техника- (1748) Arhitektura- (3434) Astronomiya- (809) Biologiya- (7483) Biotehnologii- (1457) Военни бизнесмен (14632) Висока technologies- (1363) Geografiya- (913) Geologiya- (1438) на държавата (451) Demografiya- ( 1065) Къща- (47672) журналистика и смирен (912) Izobretatelstvo- (14524) външен >(4268) Informatika- (17799) Iskusstvo- (1338) историята е (13644) Компютри- (11,121) Kosmetika- (55) Kulinariya- (373) културата е (8427) Lingvistika- (374) Literatura- (1642) маркетинг-(23702) математиците на (16968) Механична инженерно (1700) медицина-(12668) Management- (24684) Mehanika- (15423) Naukovedenie- (506) образователна (11852) truda- сигурност (3308) Pedagogika- (5571) Poligrafiya- (1312) Politika- (7869) Лево- (5454) Priborostroenie- (1369) Programmirovanie- (2801) производствено (97 182 ) индустрия- (8706) Psihologiya- (18388) Religiya- (3217) Svyaz (10668) Agriculture- (299) Sotsiologiya- (6455) на (42831) спортист строително (4793) Torgovlya- (5050) транспорт ( 2929) Turizm- (1568) физик (3942) Filosofiya- (17015) Finansy- (26596) химия (22929) Ekologiya- (12095) Ekonomika- (9961) Electronics- (8441) Elektrotehnika- (4623) Мощност инженерно ( 12629) Yurisprudentsiya- (1492) ядрена technics- (1748)

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




име характеристики на
Cascade модел Ясна и лесен за използване Constant строг контрол върху напредъка на работата по разработване на софтуер не е на разположение за промяна
V-образен модел Лесен за използване Специално значение се дава на изпитване и сравняване на резултатите от изпитванията и фази за проектиране
Модел на прототипи Създава "бързо" частично прилагане на системата за изготвяне на окончателните изисквания осигуряват обратна връзка между потребители и разработчици в хода на изискванията на проекта използва непълна
Развитие Модел Rapid Application проектни екипи са малки (3..7 хора) и се състои от високо квалифицирани специалисти, намалено време за развитие цикъл (до 3 месеца) и подобрена производителност Code повторна употреба и автоматизация на процеса на проектиране
Multi-пас модел Бързо създаване на работеща система намалява възможността за промени в процеса е невъзможно преход от развитието на текущото изпълнение на новата версия за строежа на сегашната частична продажба
Спирала модел Калъфи каскада модел дисекция фаза на по-малки парчета, позволява гъвкавост, за да извърши проектирането рискува да анализира и управлява потребители са запознати с ПП на по-ранен етап, защото на прототипи

Cascade модел

За първи път в появата и най-често е модел водопад (Фигура 8).

Унифицираната информационна система на 1970-те и 1980-те години, приложния софтуер е едно цяло. каскада модел е бил използван, за да се развие този тип софтуер, или "водопад» (yaterfall) (фиг. 8).

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



Предимства на метода на каскада:

· На всеки етап формира пълен набор от документи от проекта, който отговаря на критериите за пълнота и последователност;

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

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

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

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

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

Това се дължи на следните причини:

· Потребителите не са в състояние незабавно да представи на всички ваши изисквания и не може да се предскаже как ще се променят в хода на развитие;

· По време на развитие може да промени във външната среда, които оказват влияние на системните изисквания.

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

Моделът на каскада се характеризира със следните основни характеристики:

- Последователно прилагане на нейните съставни фази;

- В края на всеки предишен етап преди началото на следващата;

- Липса на времеви стъпки припокриване (следващ етап не започне, докато предишната е завършена);

- Липса на (или някои ограничения), за да се върнат на предишните етапи;

- Наличие на резултата до края на развитието.

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

повтарящ се модел

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

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

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

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

V-образен модел

Този модел (фиг. 10) е проектиран като един вид каскада модел, който се фокусира върху проверката и заверката на софтуер. Моделът показва, че изпитването на продукта се обсъжда, проектирани и планирано от най-ранните етапи от живота развитие цикъл (фиг. 10, този процес е показана с прекъснати стрелки).

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

Този модел се основава на систематичен подход към проблема, за решаването на които има четири основни стъпки идентифицирани: анализ, проектиране, разработване и преразглеждане. Когато анализът извършва планиране и изискванията на проекта. Design е разделена на високо равнище и подробно (ниско ниво). Развитие включва кодиране и преглед - различни видове тестове.

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

Моделът включва следните фази:

1. Изготвяне на изискванията на проекта и планиране - определено системни изисквания и планиране на работата се извършва;

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

3. Високо ниво дизайн - определено софтуер структура, връзката между неговите основни компоненти и функции, изпълнявани от тях;

4. Подробно дизайн - се определя от алгоритъма на всеки компонент;

5. Coding - вие трансформира алгоритми рафт софтуер;

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

7. Интеграция на тестване - интегриране на софтуера и неговото тестване;

8. тестване на системата - проверява функционирането на софтуерния продукт след пускането му в хардуер среда в съответствие с изискванията на спецификацията;

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

Предимства на V-образен модел:

· По-голяма роля, даден на проверката и заверката на софтуер, като се започне с най-ранните етапи на своето развитие, се планират всички дейности;

· Приема за сертифициране и проверка на не само на самия софтуер, но и всички, получили вътрешна и външна данни;

· В хода на работата могат лесно да бъдат проследени, тъй като завършването на всеки етап е референтната точка.

В допълнение към тези предимства модела има редица недостатъци:

· Не брои итерация между фазите;

· Вие не може да прави всякакви промени в различни етапи от жизнения цикъл;

· Изисквания тестване е твърде късно, така че промените да засегнат изпълнението на работния график.

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

Модел на прототипи

Прототипи модел (фиг. 11), за да се създаде прототип на софтуерния продукт, преди или по време на втората фаза на изискванията на софтуерния продукт.

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

Жизненият цикъл на разработка на софтуер започва с разработването на плана на проекта (Фигура 11 в етапа на планиране съответства на центъра на елипсата), след което се извършва бърз анализ, и след това се създаде база данни (разбира се, ако тя се използва в PP), потребителски интерфейс и развитие извършва необходимите функции , В резултат на тази работа получава документ, съдържащ частично спецификация на изискванията за софтуерен продукт. Този документ допълнително осигурява основата за един повтарящ се цикъл на бързо създаване на прототипи.

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

прототипиране модел има редица предимства:

· Взаимодействие с клиента, за да разработят системи започва още на ранен етап;

· Благодарение на реакция на клиента до прототипа се свеждат до минимум броя на неточности в претенциите;

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

· В процеса на развитие могат да бъдат взети под внимание, са винаги нови, дори неочаквани изисквания на клиента;

· Prototype е формална спецификация, въплътени в един софтуерен продукт;

· Prototype го прави много гъвкави, за да извърши проектирането и разработването, включително няколко повторения във всички фази на живота развитие цикъл;

· Клиентът винаги може да видите напредъка в развитието на софтуер;

· Възможността за конфликт между разработчици и клиенти е сведена до минимум;

· Намаляване на броя на модификации, които намаляват разходите за развитие:

· Възникващите проблеми са решени в ранните етапи, които драстично намалява разходите за отстраняването им;

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

В допълнение към предимствата, присъщи на прототипи модел и редица недостатъци:

· Решения на сложни проблеми могат да бъдат изтласкани в бъдещето;

· Клиентът може да избере да получава прототип, а не пълен пълна версия на софтуерния продукт;

· Прототипи може да се отлага неправомерно;

· Преди работа е неизвестно колко повторения ще трябва да изпълнява.

прототипиране модел препоръчва в следните случаи:

· За софтуера изисквания не са известни предварително,

· Изисквания нестабилна или недобре формулирана;

· Изисквания трябва да бъдат изяснени;

· Имате нужда от доказване на концепцията;

· Съществува необходимост в потребителския интерфейс;

· Изпълнява нов, несравним развитие;

· Разработчици не са сигурни какво трябва да бъде избран на разтвора.

Модел бърза разработка на приложения (RAD-модел)

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

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

Фигура 12 илюстрира принципите на RAD-модел на определени етапи от процеса на развитие и показва част от клиентите (пунктирана линия) на всеки един от тях.

Моделът включва следните фази:

· Изготвяне изисквания и планиране - се извършва с помощта на така наречените участие изискванията метод планиране (планиране на работата по създаване и съставянето PP, към изискванията на ПП са едновременно удовлетворен), който е структурен анализ и обсъждане на проблемите, за да бъде решен;

· Описание на потребителя - проектиране PP осъществява с прякото участие на клиента;

· Създаване - Работно проектиране, кодиране и тестване на ПП, както и доставка до клиента;

· Поддръжка - тестване приемане, монтаж на PP и обучение на потребителите.

Моделът има следните предимства:

· Използването на модерни инструменти, за да се намали времето на цикъла на развитие;

· Участието на клиента, за да се намали рискът, че той ще остане недоволен готов софтуерен продукт;

· Повторна употреба на съществуващи компоненти на програмата.

В същото време, присъщи недостатъци:

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

· Необходимост от висококвалифициран персонал, които са в състояние да използват съвременни средства;

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

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

Multi-пас модел

Multi-пас модел (фигура 13) - след няколко повторения на процеса на изграждане на софтуерни прототипи с добавянето на всяка нова итерация на следните характеристики или повишаване на ефективността на софтуера.

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

Ползи многоходова модел:

· В началото на фондове за развитие са необходими само за проектиране и изпълнение на основните функции на софтуера;

· След всяко нарастване получен функционален продукт;

· Намалява риска от повреди и променящите се изисквания;

· улучшается понимание как разработчиками, так и пользователями программного продукта требований для более поздних итераций;

· инкременты функциональных возможностей легко поддаются тестированию.

Недостатки многопроходной модели:

· не предусмотрены итерации внутри каждого инкремента;

· определение полной функциональности должно быть осуществлено в самом начале жизненного цикла разработки;

· может возникнуть тенденция оттягивания решения трудных задач;

· общие затраты на создание программного продукта не будут снижены по сравнению с другими моделями;

· обязательным условием является наличие хорошего планирования и проектирования.

Многопроходная модель может быть применена, если большинство требований к программному продукту будут сформулированы заранее, а для выполнения проекта будет выделен большой период времени.

Спиральная модель

Для преодоления проблем, связанных с использованием многопроходной модели, в середине 1980-х годов была предложена спиральная модель жизненного цикла (Рис.14). Ее принципиальная особенность заключается в том, что прикладной программный продукт создается не сразу, как в случае каскадного подхода, а по частям с использованием метода прототипирования. Под прототипом понимается действующий программный компонент, реализующий отдельные функции и внешние интерфейсы разрабатываемого программного продукта. Создание прототипов осуществляется за несколько итераций, или витков спирали. Каждая итерация соответствует созданию фрагмента, или версии программного продукта, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации. На каждой итерации производится тщательная оценка риска превышения сроков и стоимости проекта с целью определения необходимости выполнения еще одной итерации, степени полноты и точности понимания требований к системе, а также целесообразности прекращения проекта. Спиральная модель избавляет пользователей и разработчиков программного продукта от полного и точного формулирования требований к системе на начальной стадии, поскольку они уточняются на каждой итерации. Таким образом, углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.

Рис.14 Спиральная модель

Разработка итерациями отражает объективно существующий спиральный цикл создания системы, позволяя переходить на следующую стадию, не дожидаясь полного завершения работы на текущей стадии, поскольку при итеративном способе разработки недостающую работу можно выполнить на следующей итерации. Главная задача такой разработки — как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Спиральная модель не исключает использования каскадного подхода на завершающих стадиях проекта в тех случаях, когда требования к системе оказываются полностью определенными.

Основная проблема спирального цикла — определение момента перехода на следующую стадию. Для ее решения необходимо ввести временные ограничения на каждую из стадий жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.

Спиральная модель обладает следующими достоинствами:

· заказчик имеет возможность увидеть разрабатываемый программный продукт на ранних стадиях разработки;

· Клиентите са активно ангажирани в разработването на софтуер;

· Ползи, въплътени в моделите на модел каскадни и мулти-пас.

Недостатъци спирала модел:

· Сложна структура;

· Спирала може да продължи неопределено време, тъй като всеки отговор на клиента може да генерира нов цикъл.

Използвайки модела на спирала е препоръчително, ако има поне една от следните причини:

· Препоръчително е да се създаде прототип;

· Организация има необходимите умения за адаптиране на модела;

· Искате ли да стартирате проекти със средно и високо рискови нива;

· Клиентите не са сигурни за техните нужди;

· Изисквания са твърде сложни;

· Проектът е много голям.

Рационално Objectory Process

(Методология на обектно-ориентираното програмиране)

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

· Life модел цикъл;

· Действия;

· Нотация език.

UML Lifecycle

Rational Software компания, която разработи UML, и също така предложи модел на жизнения цикъл, който се нарича Rational Objectory процес (ROP). Независимо, че технологията директен трансфер не е, защото рационално в този случай се използва в смисъл на "рационално" и в същото време като името на компанията, на второ място, objectory думи на английски език, не съществува.

Основните свойства на ROP-технология.

Рационално Objectory Процес - един повтарящ се процес, по време на който последователно усъвършенстване на резултатите.

Рационално Objectory процес е насочен към създаването на модели, а не да се развиват всички други елементи на проекта (като текстови документи).

Действия Rational Objectory процес са определени предимно чрез използването на единици.

Рационално Objectory Process разделена на цикли, всеки от които на свой ред се състои от четири фази:

• началния етап (Inception);

• развитие (Разработване);

• Design (Строителство);

• Въвеждане в експлоатация (Transition).

Резултатът на всеки цикъл е версия на софтуерната система.

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

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

В края на началната фаза следните резултати са следните:

• първоначалната речник на термините проект;

• общо описание на системата - основните изисквания за проекта, неговите характеристики и ограничения;

• първоначален модел на случаите на използване;

• първоначалния бизнес план;

• план на проекта, която отразява на сцената и итерация;

• един или повече прототипи.

На етапа на развитие разкрива по-подробни изисквания към системата, извършва анализ на домейн на високо равнище и дизайн на основната архитектура на системата, създава план за проектиране и елиминира най-рисковите елементи на проекта.

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

Етап отнема около една пета от проекта за създаване на времето, което води до:

• оценка на изпълнението на всяка употреба;

• идентифициране на най-сериозните рискове, както и възможността за тяхната ликвидация.

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

Трябва да се отбележи, че:

• повторения са пределни според функция. Всяка итерация добавя алтернативен дизайн за случаи на употреба, изпълнявани по време на предишните повторения;

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

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

Целта на етапа на въвеждане в експлоатация е прехвърлянето на готовия продукт на разположение на крайните потребители. Тази стъпка включва:

· Beta, гарантира, че новата линия с очакванията на потребителите;

· Паралелна работа на съществуващата система, която е обект на постепенна замяна;

· Оптимизиране на ефективността;

· Обучение на потребители и специалисти по поддръжката на услуги.





; Дата: 05.01.2014; ; Прегледи: 1016; Нарушаването на авторските права? ;


Ние ценим Вашето мнение! Беше ли полезна публикуван материал? Да | не



ТЪРСЕНЕ:


Вижте също:



zdes-stroika.ru - Studopediya (2013 - 2017) на година. Тя не е автор на материали, и дава на студентите с безплатно образование и използва! Най-новото допълнение , Al IP: 66.102.9.26
Page генерирана за: 0.062 сек.