і схеми розробки проекту.
" Водоспад" - схема розробки проекту.
Дуже часто проектування описують як окремий етап розробки проекту між аналізом і розробкою. Однак в дійсності чіткого поділу етапів розробки проекту немає - проектування, як правило, не має явно вираженого початку і закінчення і часто триває на етапах тестування і реалізації. Говорячи про етап тестування, також слід зазначити, що і етап аналізу, і етап проектування містять елементи роботи тестерів, наприклад для отримання експериментального обгрунтування вибору того чи іншого рішення, а також для оцінки критеріїв якості одержуваної системи. На етапі експлуатації доречний розмову і про супровід системи. p> Нижче ми розглянемо кожен з етапів, докладніше зупинившись на етапі проектування.
Стратегія.
Визначення стратегії передбачає обстеження системи. Основне завдання обстеження - оцінка реального обсягу проекту, його цілей і завдань, а також отримання визначень сутностей і функцій на високому рівні.
На цьому етапі залучаються висококваліфіковані бізнес-аналітики, які мають постійний доступ до керівництву фірми; етап передбачає тісну взаємодію з основними користувачами системи і бізнес-експертами. Основне завдання взаємодії - отримати якомога повнішу інформацію про систему (повне і однозначне розуміння вимог замовника) і передати дану інформацію у формалізованому вигляді системним аналітикам для подальшого проведення етапу аналізу. Як правило, інформація про систему може бути отримана в результаті бесід або семінарів з керівництвом, експертами і користувачами. Таким чином визначаються суть даного бізнесу, перспективи його розвитку та вимоги до системи.
По завершенні основної стадії обстеження системи технічні фахівці формують вірогідні технічні підходи і приблизно розраховують витрати на апаратне забезпечення, закуповується програмне забезпечення та розробку нового програмного забезпечення (Що, власне, і передбачається проектом). p> Результатом етапу визначення стратегії є документ, де чітко сформульовано, що отримає замовник, якщо погодиться фінансувати проект; коли він отримає готовий продукт (графік виконання робіт); скільки це буде коштувати (для великих проектів повинен бути складений графік фінансування на різних етапах робіт). У документі повинні бути відображені не тільки витрати, але і вигода, наприклад час окупності проекту, очікуваний економічний ефект (якщо його вдається оцінити).
У документі обов'язково повинні бути описані:
обмеження, ризики, критичні фактори, що впливають на успішність проекту, наприклад час реакції системи на запит є заданим обмеженням, а не бажаним чинником;
сукупність умов, при яких передбачається експлуатувати майбутню систему: архітектура системи, апаратні і програмні ресурси, що надаються системі, зовнішні умови її функціонування, склад людей і робіт, які забезпечують безперебійне функціонування системи;
терміни завершення окремих етапів, форма здачі робіт, ресурси, що залучаються в процесі розробки проекту, заходи по захисту інформації;
опис виконуваних системою функцій;
майбутні вимоги до системи в разі її розвитку, наприклад можливість роботи користувача з системою з допомогою Інтернету тощо;
сутності, необхідні для виконання функцій системи;
інтерфейси і розподіл функцій між людиною і системою;
вимоги до програмних і інформаційним компонентів ПЗ, вимоги до СУБД (якщо проект передбачається реалізовувати для декількох СУБД, то вимоги до кожної з них, або загальні вимоги до абстрактної СУБД і список рекомендованих для даного проекту СУБД, які задовольняють заданим умовам);
що не реалізовано в рамках проекту.
Виконана на даному етапі робота дозволяє відповісти на питання, чи варто продовжувати даний проект і які вимоги замовника можуть бути задоволені при тих чи інших умовах. Може виявитися, що проект продовжувати не має сенсу, наприклад через те, що ті або інші вимоги не можуть бути задоволені з якихось об'єктивних причин. Якщо приймається рішення про продовження проекту, то для проведення наступного етапу аналізу вже є уявлення про обсяг проекту і кошторис витрат.
Слід зазначити, що і на етапі вибору стратегії, і на етапі аналізу, і при проектуванні незалежно від методу, застосовуваного при розробці проекту, завжди слід класифікувати плановані функції системи за ступенем важливості. Один з можливих форматів подання такої класифікації - MoSCoW - запропонований в Clegg, Dai and Richard Barker, Case Method Fast-track: A RAD Approach, Adison-Wesley, 1994. p> Ця абревіатура розшифровується так: Must have - необхідні функції; Should have - бажані функції; Could have - можливі функції; Won't have - відсутні функції.
Функції першої категорії забезпечують критичні для успішної роботи системи можливості.
Реалізація функцій другий і третьої категорій обмежується часовими і фінансовими рамками: розробляємо те, що ...
