Система управління взаємовідносинами з клієнтами CRM

V-подібна модель. V-подібна модель була створена з метою допомогти команді, що працює над проектом, в плануванні із забезпеченням подальшої можливості тестування системи [33].

У цій моделі особливе значення надається діям, спрямованим на верифікацію та атестацію продукту. Вона демонструє, що тестування продукту обговорюється, проектується і планується на ранніх етапах життєвого циклу розробки. План випробування приймання замовником розробляється на етапі планування, а компонувального випробування системи – на фазах аналізу, розробки проекту і т. д. Цей процес розробки планів випробування позначений пунктирною лінією між прямокутниками V-подібної моделі на рис. 2. 5.

 

Рисунок 2. 5 – V-подібна модель ЖЦ розробки

 

Дана модель була розроблена як різновид каскадної моделі, а значить, успадкувала від неї таку ж послідовну структуру. Кожна наступна фаза починається з завершення отримання результативних даних попередньої фази. Модель демонструє комплексний підхід до визначення фаз процесу розробки системи. У ній підкреслені взаємозв'язки, що існують між аналітичними фазами і фазами проектування, які передують кодуванню, після якого йдуть фази тестування. Пунктирні лінії означають, що ці фази необхідно розглядати паралельно [34].

При використанні V-подібної моделі при розробці проекту, для якого вона в достатній мірі підходить, забезпечується кілька переваг, зокрема це те, що в моделі особливе значення надається плануванню, направленому на верифікацію та атестацію розробляється продукту на ранніх стадіях його розробки. Також в моделі передбачені атестація та верифікація всіх зовнішніх і внутрішніх отриманих даних, а не тільки самого продукту. Визначення вимог виконується перед розробкою проекту системи, а проектування програмного забезпечення – перед розробкою компонентів, що дозволяє уникнути конфлікту невідповідності.

У противному випадку, якщо модель не достатньо підходить для використання в певному, то з нею буде важче впоратися, особливо з паралельними подіями. Модель не пристосована до динамічних змін, адже вимоги фіксуються з самого початку процесу створення проекту. Також в ній не приділяється увага аналізу ризиків.

Модель Microsoft Solution Framework (MSF). Модель процесів MSF являє загальну методологію розробки до впровадження новітніх інформаційних технологій. Особливість цієї моделі полягає в тому, що завдяки своїй гнучкості та відсутності жорсткої прив’язки процедур вона може бути застосована при розробці досить широкого кола IT проектів. Ця модель поєднує в собі властивості двох стандартних моделей ЖЦ розробки: каскадної і спіральної.

Процес MSF орієнтований на «віхи» – ключові точки проекту, що характеризують досягнення в його рамках будь-якого істотного (проміжного або кінцевого) результату (рис. 2. 6).

Модель процесів MSF враховує постійні зміни проектних вимог. Вона виходить з того, що розробка рішення повинна складатися з коротких циклів, що створюють поступальний рух від найпростіших версій рішення до його остаточного вигляду.

Модель MSF найчастіше застосовується до процесу розробки традиційного ПЗ, але також вона може бути використана для розробки і впровадження рішень в області електронної комерції та інших складних ІС, які можуть виникнути в майбутньому [35].

 

Рисунок 2. 6 – Модель MSF життєвого циклу розробки

 

Модель прототипування. В основі моделі прототипування [36] лежить ідея побудови експериментальної (прототипної) системи, на модифікаціях якої ітеративно і швидко відпрацьовуються вимоги до проектованого продукту. Така модель зазвичай носить назву структурної еволюційної моделі швидкого прототипування і зображена на рис. 2. 7:

 

Рисунок 2. 7 – Модель прототипування життєвого циклу розборки

 

Під еволюційним прискореним прототипом розуміють легко створювану, розширювану і здатну до модифікацій робочу модель системи, яка дає досить повне уявлення про ключові компоненти і функції системи до моменту її безпосередньої реалізації.

Замовники (кінцеві користувачі) системи аналізують наданий прототип і видають свої зауваження до тих пір, поки прототип не буде задовольняти всім їхнім вимогам. Після завершення процесу визначення вимог (шляхом розробки прискорених прототипів) формується детальний проект системи, а на основі прототипу створюється кінцевий робочий продукт [37, 38, 39].

Переваги використання моделі швидкого прототипування виявляються найбільш виразно при розробці таких АС, для яких немає аналогів, або у випадку, коли:

всі вимоги заздалегідь не відомі;

алгоритми або інтерфейси ускладнені;

вимоги не постійні або можуть бути невірно роз’яснені або невдало сформульовані;

слід уточнити вимоги;

існує потреба в розробці користувальницьких інтерфейсів;

потрібна перевірка концепції;

здійснюються тимчасові демонстрації;

побудоване за принципом структурної моделі, еволюційне швидке прототипування можна успішно використовувати у великих системах, в яких деякі моделі піддаються прототипуванню, а деякі-розробляються більш традиційним чином;

виконується нова, яка не має аналогів розробка (на відміну від експлуатації продукту на вже існуючій системі) ;

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

вимоги схильні швидких змін, коли замовник неохоче погоджується на фіксований набір вимог або якщо про прикладну програму відсутнє чітке уявлення;

розробники не впевнені в тому, яку оптимальну архітектуру або алгоритми слід застосовувати;

потрібно продемонструвати технічну здійсненність, коли технічний ризик високий;

розробляється, особливо у випадку програм, коли проявляється середня і висока ступінь ризику;

здійснюється застосування в комбінації з каскадної моделлю: на початковому