40821

Моделі життєвого циклу та методології розробки ПЗ

Лекция

Производство и промышленные технологии

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

Украинкский

2013-10-22

451.75 KB

114 чел.

Тема 3. Моделі життєвого циклу та методології розробки ПЗ

Моделі життєвого циклу

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

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

Найчастіше говорять про наступні моделі життєвого циклу:

• Водоспадна (каскадна) або послідовна

• Ітераційна й інкрементна

• Спіральна (spiral) або модель Боема 

Водоспадна (каскадна) модель (англ. waterfall model)

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

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

У результаті завершення певних фаз формується базова лінія, яка в даній точці "заморожує" продукти розробки. Якщо виникає потреба в їх зміні, тоді для внесення змін використовується формальний процес змін.

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

Спроби оптимізації каскадної моделі призвели до виникнення інших циклів розробки ПЗ.

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

Рис. 3.1. Каскадна модель життєвого циклу.

Переваги:

  1.  Проста і зручна в застосуванні, так як процес розробки виконується поетапно;
  2.  Повна і узгоджена документація на кожному етапі;
  3.  Легко визначити терміни і витрати на проект.

Недоліки:

У водоспадній моделі перехід від однієї фази проекту до іншого передбачає повну коректність результату (виходу) попередньої фази. Однак неточність будь-якої вимоги або некоректна її інтерпретація в результаті призводить до того, що доводиться "відкатуватися" до ранньої фази проекту і необхідна переробка не просто вибиває проектну команду з графіка, але призводить часто до якісного зростання витрат і, не виключено, до припинення проекту в тій формі, в якій він спочатку замислювався. На думку сучасних фахівців, основна помилка авторів водоспадної моделі полягає в припущеннях, що проект проходить через весь процес один раз, спроектована архітектура гарна і проста у використанні, проект здійснення розумний, а помилки в реалізації легко усуваються в міру тестування. Ця модель виходить з того, що всі помилки будуть зосереджені в реалізації, а тому їх усунення відбувається рівномірно під час тестування компонентів і системи. Таким чином, водоспадна модель для великих проектів мало реалістична і може бути ефективно використана тільки для створення невеликих систем.

Ітеративна й інкрементна модель – еволюційний підхід.

Альтернативою послідовної моделі є так звана модель ітеративної і інкрементної розробки (англ. iterative and incremental development, IID), що отримала також від Т. Гілба в 70-і рр. назву еволюційної моделі. Також цю модель називають ітеративною моделлю та інкрементною моделлю.

Рис.3.2. Ітеративна та інкрементна модель

Модель IID передбачає розбиття життєвого циклу проекту на послідовність ітерацій, кожна з яких нагадує "міні-проект", включаючи всі процеси розробки в застосуванні до створення менших фрагментів функціональності, порівняно з проектом в цілому. Мета кожної ітерації — отримання працюючої версії програмної системи, що включає функціональність, визначену інтегрованим змістом всіх попередніх та поточної ітерації. Результат фінальної ітерації містить всю необхідну функціональність продукту. Таким чином, із завершенням кожної ітерації продукт отримує приріст — інкремент — до його можливостей, які, значить, розвиваються еволюційно. Ітеративність, інкрементальність і еволюційність в даному випадку є вислів одного й того ж сенсу різними словами зі злегка різних точок зору.

З точки зору структури життєвого циклу таку модель називають ітеративною (iterative). З точки зору розвитку продукту — інкрементальною (incremental). Досвід індустрії показує, що  неможливо розглядати кожен з цих поглядів ізольовано. Найчастіше таку змішану еволюційну модель називають просто ітеративна (кажучи про процес) та/або інкрементна (Кажучи про нарощування функціональності продукту).

Рис. 3.3. Можливий хід робіт за ітеративною моделлю

Каскадна модель з можливістю повернення на попередній крок при необхідності переглянути його результати, стає ітеративною.

Ітеративний процес припускає, що різні види діяльності не прив'язані намертво до певних етапів розробки, а виконуються в міру необхідності, іноді повторюються, до тих пір, поки не буде отриманий потрібний результат.

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

Різні варіанти ітераційного підходу реалізовані в більшості сучасних методологій розробки (RUP, MSF, XP).

Спіральна модель

Спіральна модель (англ. spiral model) була розроблена в середині 1980-х років Баррі Боем. Вона заснована на класичному циклі Демінга PDCA (plan-do-check-act — планування-дія-перевірка-коректування). При використанні цієї моделі ПЗ створюється в кілька ітерацій (витків спіралі) методом прототипування.

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

Назву "спіральна" ця модель отримала через зображення ходу робіт в "полярних координатах", в яких кут відповідає виконуваному етапу в рамках загальної структури ітерацій, а віддалення від початку координат — витраченим ресурсам.

Рис. 3.4. Спіральна модель

На кожній ітерації оцінюються:

  1.  ризик перевищення термінів і вартості проекту;
  2.  необхідність виконання ще однієї ітерації;
  3.  ступінь повноти і точності розуміння вимог до системи;
  4.  доцільність припинення проекту.

Важливо розуміти, що спіральна модель є не альтернативою еволюційної моделі (моделі IID), а спеціально опрацьованим варіантом. На жаль, нерідко спіральну модель або помилково використовують як синонім еволюційної моделі взагалі, або (не менш помилково) згадують як абсолютно самостійну модель поряд з IID.

Відмінною особливістю спіральної моделі є спеціальна увага, що приділяється ризикам, що впливає на організацію життєвого циклу, і контрольним точкам. Боем формулює 10 найбільш поширених (за пріоритетами) ризиків:

  1.  Дефіцит фахівців.
  2.  Нереалістичні терміни і бюджет.
  3.  Реалізація невідповідної функціональності.
  4.  Розробка неправильного користувальницького інтерфейсу.
  5.  Перфекціонізм, непотрібна оптимізація і відточування деталей.
  6.  Безперервний потік змін.
  7.  Брак інформації про зовнішні компоненти, що визначають оточення системи або залучених до інтеграцію.
  8.  Недоліки в роботах, виконуваних зовнішніми (по відношенню до проекту) ресурсами.
  9.  Недостатня продуктивність одержуваної системи.
  10.  Розрив у кваліфікації фахівців різних областей.

Еволюціонування спіральної моделі пов'язано з питаннями деталізації робіт. Особливо варто виділити акцент на більш важливих питаннях - вимог, дизайну та коду, тобто надання більшої важливості питанням ітерацій, в тому числі, збільшення їх кількості при скороченні тривалості кожної ітерації. У результаті, можна визначити загальний набір контрольних точок в сьогоднішній спіральної моделі:

  1.  Concept of Operations (COO) - концепція (використання) системи;
  2.  Life Cycle Objectives (LCO) - цілі та зміст життєвого циклу;
  3.  Life Cycle Architecture (LCA) - архітектура життєвого циклу; тут же можливо говорити про готовність концептуальної архітектури цільової програмної системи;
  4.  Initial Operational Capability (IOC) - перша версія створюваного продукту, придатна для дослідної експлуатації;
  5.  Final Operational Capability (FOC) - готовий продукт, розгорнутий (встановлений і налаштований) для реальної експлуатації.

Методології розробки ПЗ

Залежно від поставленої замовником задачі, фахівці використовують різні підходи до її реалізації. Таких підходів/методик декілька і всі вони мають свої переваги, і свої недоліки в залежності від того яка саме задача ставиться перед виконавцем робіт.

  1.  Rational Unified Process (RUP).
  2.  Microsoft Solutions Framework (MSF).
  3.  Екстремальне програмування — Extreme Programming (XP).
  4.  Швидка розробка додатків — Rapid Application Development (RAD).
  5.  Метод розробки динамічних систем — Dynamic Systems Development Method (DSDM).

Методологія Rational Unified Process (RUP)

Провідною методологією, у якій інструментально підтримуються всі етапи життєвого циклу розробки ПЗ, є методологія Rational Unified Process (RUP). Вона опирається на перевірені практикою методи аналізу, проектування й розробки ПЗ, методи керування проектами. RUP забезпечує прозорість і керованість процесу й дозволяє створювати ПЗ відповідно до вимог замовника на момент здачі ПЗ, а також відповідно до можливостей інструментальних засобів підтримки розробки.

В основі методології RUP, як і багатьох інших програмних методологій, що поєднують інженерні методи створення ПЗ, лежить "покроковий підхід". Він визначає етапи життєвого циклу, контрольні точки, правила робіт для кожного етапу й, тим самим, упорядковує проектування й розробку ПЗ. Для кожного етапу життєвого циклу методологія задає:

  1.  склад і послідовність робіт, а також правила їх виконання;
  2.  розподіл повноважень серед учасників проекту (ролі);
  3.  склад і шаблони проміжних і підсумкових документів, що формуються;
  4.  порядок контролю й перевірки якості.

RUP як методологія

Методологія RUP дозволяє об'єднати проектну команду, надаючи в її розпорядження перевірені світовою практикою кращі підходи до розробки ІС. До них відносяться такі процеси життєвого циклу створення ПЗ, як керування проектами, бізнес-моделювання, керування вимогами, аналіз і проектування, тестування й контроль змін.

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

Rational Unified Process — керований процес. Ітеративний підхід припускає керування вимогами й змінами, щоб між усіма учасниками проекту забезпечувати єдине розуміння очікуваних функціональних можливостей, необхідний рівень якості, найкраще керування витратами й графіками виконання робіт.

Rational Unified Process — процес створення й фізичного втілення візуальних моделей. RUP фокусує увагу не на створенні великої кількості паперових документів, а на розвитку й застосуванні візуальних моделей — семантично багатих представлень розроблювальної ІС. RUP зосереджує увагу на розробці й подальшому розвитку надійної й гнучкої архітектури, яка полегшує паралельну розробку, мінімізує необхідність змін, збільшує можливість багаторазового використання й надійність експлуатації системи.

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

Rational Unified Process підтримує об'єктно-орієнтовану технологію. Моделювання по методології RUP є об'єктно-орієнтованим і базується на поняттях об'єктів, класів і залежностей між ними. Ці моделі, подібно багатьом іншим технічним штучним об'єктам (артефактам), у якості єдиного стандарту для організації взаємодії учасників проекту використовують Unified Modelling Language™ (UML) — універсальна мова моделювання.

Rational Unified Process підтримує компонентно-орієнтований підхід. Компоненти — це нетривіальні модулі або підсистеми, які виконують конкретну функцію й можуть бути використані багаторазово.

Rational Unified Process — процес, що адаптується і конфігурується. Досвід одиничного проекту, навіть успішно завершеного, навряд чи підійде для створення ПЗ у всіх випадках і умовах. Але здатність RUP до адаптації підійде як маленьким групам розроблювачів, так і великим організаціям.

Rational Unified Process підтримує об'єктивно здійснюване керування якістю. Оцінка якості всіх робіт, виконуваних будь-якими учасниками проекту, використовує об'єктивні метрики й критерії. Методологія RUP створювалася із прицілом на підтримку керування якістю в рамках вимог SEI CMM/CMMI.

Структура життєвого циклу проекту

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

Час відбиває динамічний аспект життєвого циклу проекту, виражений у термінах циклів, фаз, ітерацій і контрольних точок, які розділяють дві окремі фази. Вертикальна вісь відбиває статичний аспект проекту. Він описується в термінах процесів, артефактів (одиниця інформації, створювана або модифікується в ході будь-якого процесу) і ролей (відповідальність за адекватне виконання тієї або іншої діяльності в процесі). RUP організує виконання проекту по фазах, кожна з яких складається з однієї або декількох ітерацій. При ітеративному підході обсяг робіт по кожному процесу варіюється протягом усього життєвого циклу. Контрольні точки наприкінці фаз дозволяють оцінити, наскільки успішною була попередня фаза й наскільки успішний увесь проект у цілому. RUP визначає наступні основні процеси:

  1.  моделювання бізнес-процесів;
  2.  керування вимогами;
  3.  аналіз і проектування;
  4.  реалізація;
  5.  тестування;
  6.  розгортання;
  7.  конфігураційне керування й керування змінами;
  8.  керування проектом;
  9.  керування середовищем.

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

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

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

Реалізація необхідна для виявлення порядку організації програмного коду в термінах окремих підсистем, перетворення вихідного коду у виконувані компоненти, тестування створених компонентів і інтеграції окремих компонентів у підсистеми й системи.

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

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

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

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

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

Найважливіші акценти

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

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

Для спрощення перехід до методології RUP допускається поступове його впровадження. Але при цьому акцентується увага на декількох найважливіших елементах, без яких складно гарантувати успіх у проекті.

Microsoft Solutions Framework (MSF)

Microsoft Solutions Framework (MSF) — методологія розробки програмного забезпечення, запропонована корпорацією Microsoft. MSF опирається на практичний досвід Microsoft і описує керування людьми й робочими процесами в процесі розробки рішення.

MSF являє собою погоджений набір концепцій, моделей і правил.

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

Створення бізнес-рішення в рамках відведених часу й бюджету вимагає наявності випробуваної методологічної основи. MSF пропонує перевірені методики для планування, проектування, розробки й впровадження успішних IТ-рішень. Завдяки своїй гнучкості, масштабованості й відсутності твердих інструкцій MSF здатний задовольнити потреби організації або проектної групи будь-якого розміру. Методологія MSF складається із принципів, моделей і дисциплін по керуванню персоналом, процесами, технологічними елементами й зв'язаними з усіма цими факторами питаннями, характерними для більшості проектів.

MSF складається із двох моделей і трьох дисциплін.

MSF містить:

  1.  моделі:
  2.  модель проектної групи
  3.  модель процесів
  4.  дисципліни:
  5.  дисципліна керування проектами
  6.  дисципліна керування ризиками
  7.  дисципліна керування підготовкою

Модель проектної групи MSF

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

MSF заснований на постулаті про шість якісних цілей, досягнення яких визначає успішність проекту:

  1.  Управління продуктом
  2.  Управління програмою
  3.  Розробка
  4.  Тестування
  5.  Задоволення споживача
  6.  Керування випуском

Вони відповідальні за різні області компетенції та пов'язані з ними цілі і завдання. Суть концепції - побудувати основу виробничих відносин і пов'язану з нею модель команди такими, щоб вони були пристосованими для задоволення потреб будь-якого проекту. Одна роль може бути представлена однією або кількома співробітниками, в залежності від розміру проекту, його складності і професійних навичок, необхідних для реалізації всіх областей компетенції команди. Для невеликих команд можливо (і часто необхідно) об'єднання ролей, але при цьому повинні виконуватися наступні умови:

  1.  Роль команди розробників не може бути об'єднана ні з якою іншою роллю.
  2.  Уникнути поєднання ролей, що мають зумовлені конфлікти інтересів.

Модель процесів MSF

Модель процесів MSF (MSF process model) представляє загальну методологію розробки й впровадження IT рішень. Особливість цієї моделі полягає в тому, що завдяки своїй гнучкості й відсутності процедур, що жорстко нав'язують, вона може бути застосована при розробці досить широкого кола IT проектів. Ця модель поєднує в собі властивості двох стандартних виробничих моделей: каскадної (waterfall) і спіральної (spiral). Модель процесів в MSF 3.0 була доповнена ще одним інноваційним аспектом: вона покриває весь життєвий цикл створення рішення, починаючи з його відправної точки й закінчуючи безпосередньо впровадженням. Такий підхід допомагає проектним групам сфокусувати свою увагу на бізнес-віддачі (business value) рішення, оскільки ця віддача стає реальною лише після завершення впровадження й початку використання продукту.

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

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

Особливості моделі процесів MSF є:

  1.  Підхід, заснований на фазах і віхах.
  2.  Ітеративний підхід.
  3.  Інтегрований підхід до створення й впровадження рішень.

Модель процесів включає такі основні фази процесу розробки:

  1.  Виробіток концепції (Envisioning). Основними завданнями є створення ядра проектної групи і підготовка документа загального опису і рамок проекту (vision / scope document).
  2.  Планування (Planning). На фазі планування проводиться основна робота по складанню планів проекту. Вона включає в себе підготовку проектної групою функціональної специфікації, розробку дизайнів, підготовку робочих планів, оцінку проектних витрат і термінів розробки різних складових проекту.
  3.  Розробка (Developing). На фазі розробки проектна група фокусується на створенні компонент рішення (включаючи як документацію, так і програмний код).
  4.  Стабілізація (Stabilizing). Під час фази стабілізації проводиться тестування розробленого рішення. При цьому увага фокусується на його експлуатації в реалістичній моделі виробничого середовища. Проектна група займається пріоритезацією і усуненням помилок, а також підготовкою рішення до випуску.
  5.  Впровадження (Deploying). Під час цієї фази проектна група впроваджує технології і компоненти рішення, стабілізує запроваджене рішення, передає роботу персоналу підтримки і супроводу і отримує з боку замовника остаточне схвалення результатів проекту.

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

  1.  що (які артефакти) є результатом цієї фази
  2.  над чим працює кожний з рольових кластерів на цій фазі.

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

Ітеративний підхід до процесу розробки вимагає використання гнучкого способу ведення документації. «Живі» документи (living documents) повинні змінюватися в міру еволюції проекту разом зі змінами вимог до кінцевого продукту. У рамках MSF пропонується ряд шаблонів стандартних документів, які є артефактами кожної стадії розробки продукту й можуть бути використані для планування й контролю процесу розробки.

Рішення не представляє бізнес-цінності, поки воно не впроваджене. Саме із цієї причини модель процесів MSF містить увесь життєвий цикл створення рішення, включаючи його впровадження — аж до моменту, коли рішення починає давати віддачу.

Дисципліна управління ризиками MSF. Управління ризиками - це одна з основних дисциплін у Microsoft Solution Framework. У методології MSF з самого початку враховується, що IT-проекти можуть змінюватися в процесі реалізації, що вносить додаткову невизначеність. У дисципліні управління ризиками MSF пропонується попереджуючий підхід до управління ризиками, їх постійна оцінка і облік при прийнятті рішень.

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

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

Екстремальне програмування — Extreme Programming (XP).

Екстремальне програмування (XP) – це спрощена методологія організації розробки програм для невеликих і середніх по розміру команд розроблювачів, що займаються створенням програмного продукту в умовах неясних або швидко мінливих вимог.

Цілі XP

Основними цілями XP є підвищення довіри замовника до програмного продукту шляхом надання реальних доказів успішності розвитку процесу розробки й різке скорочення строків розробки продукту. При цьому XP зосереджене на мінімізації помилок на ранніх стадіях розробки. Це дозволяє добитися максимальної швидкості випуску готового продукту й дає можливість говорити про прогностичність роботи. Практично всі прийоми XP спрямовані на підвищення якості програмного продукту.

Принципи XP

Основними принципами є:

• Ітеративність. Розробка ведеться короткими ітераціями при наявності активного взаємозв'язку із замовником. За одну ітерацію група програмістів зобов'язана реалізувати кілька властивостей системи, кожна з яких описується в користувацькій історії (КІ). Відсутність формалізації опису вхідних даних проекту в XP прагнуть компенсувати за рахунок активного включення в процес розробки замовника як повноправного члена команди.

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

• Інтенсивна розробка малими групами (не більше 10 людей) і парне програмування (коли два програмісти разом створюють код на одному загальнім робочім місці), активне спілкування в групі й між групами. Усе це націлене на як можна більш раннє виявлення проблем (як помилок, так і зриву строків). Парне програмування спрямоване на розв’язок завдання стабілізації проекту. При застосуванні XP методології високий ризик втрати коду через відхід програміста, що не витримав інтенсивного графіка роботи. У цьому випадку другий програміст із пари відіграє роль «спадкоємця» коду. Немаловажне й те, як саме розподілені групи в робочому просторі – в XP використовується відкритий робочий простір, який припускає швидкий і вільний доступ усіх до всіх.

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

• Достатній ступінь сміливості й бажання йти на ризик.

Прийоми XP

Зазвичай XP характеризують набором з 12 правил (практик), які необхідно виконувати для досягнення гарного результату. Жодна із практик не є принципово новою, але в XP вони зібрані разом.

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

2. Тісна взаємодія із замовником. Представник замовника повинен бути членом XР-команди. Він пише КІ, вибирає історії, які будуть реалізовані в конкретній ітерації, і відповідає на запитання, що стосуються бізнесу. Представник замовника повинен бути експертом в предметній області, що автоматизується. Необхідна наявність постійного зворотного зв'язку із представником замовника.

3. Загальносистемні правила іменування. Гарні системні правила іменування припускають простоту іменування класів і змінних. Команда розроблювачів повинна мати єдині правила іменування.

4. Проста архітектура. Будь-яка властивість системи повинна бути реалізована як можна простіше. Програмісти в XР-команді працюють під девізом: «Нічого зайвого!». Ухвалюється перше найпростіше працююче рішення, реалізується необхідний рівень функціональності на даний момент. Тим самим заощаджується час програміста.

5. Рефакторинг. Це оптимізація існуючого коду з метою його спрощення, Така робота повинна вестися постійно. Зберігаючи код прозорим і визначаючи його елементи всього один раз, програмісти скорочують число помилок, які згодом прийде усувати. При реалізації кожної нової властивості системи програміст повинен подумати над тим, чи можна спростити існуючий код і як це допоможе реалізувати нову властивість. Крім того, не можна сполучати рефакторинг із дизайном: якщо створюється новий код, рефакторинг слід відкласти.

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

7. 40-годинний робочий тиждень. Програміст не повинен працювати більш 8 годин на день. Необхідність понаднормової роботи – це чіткий індикатор проблеми на даному конкретному напрямку розробки. Пошук причин понаднормової роботи і їх якнайшвидше усунення – одне з основних правил.

8. Колективне володіння кодом. Кожний програміст у колективі повинен мати доступ до коду будь-якої частини системи й право вносити зміни в будь-який код. Обов'язкове правило: якщо програміст вніс зміни й система після цього працює некоректно, то саме цей програміст повинен виправити помилки.

9. Єдині стандарти кодування. Стандарти кодування потрібні для забезпечення інших практик: колективного володіння кодом, парного програмування й рефакторинга. Без єдиного стандарту виконувати ці практики як мінімум складніше, а в реальності взагалі неможливо: група буде працювати в режимі постійної нестачі часу. Команда працює над проектом тривалий час. Люди приходять і йдуть. Ніхто не кодує поодинці й код належить усім. Завжди будуть моменти, коли необхідно буде зрозуміти й скорегувати чужий код. Отже, усі повинні підкорятися загальним стандартам кодування – форматування коду, іменування класів, змінних, констант, стиль коментарів.

10. Невеликі релізи. Мінімальна ітерація – один день, максимальна – місяць; чим частіше здійснюються релізи, тим більше недоліків системи буде виявлено. Перші релізи допомагають виявити недоліки на самих ранніх стадіях, далі функціональність системи розширюється на підставі КІ. Оскільки користувач включається в процес розробки починаючи з першого релізу, то він оцінює систему й видає користувацьку історію й зауваження. На підставі цього визначається наступна ітерація, тобто, яким буде новий реліз. В XP усе спрямоване на забезпечення безперервного зворотного зв'язку з користувачами.

11. Безперервна інтеграція. Інтеграція нових частин системи повинна відбуватися якнайчастіше, як мінімум раз у кілька годин. Основне правило інтеграції наступне: інтеграцію можна робити, якщо всі тести проходять успішно. Якщо тести не проходять, то програміст повинен або внести виправлення й тоді інтегрувати складові частини системи, або взагалі не інтегрувати їх. Часта інтеграція дозволяє швидше одержати готову систему, замість того щоб витрачати на складання тиждень.

12. Тестування. На відміну від більшості інших методологій тестування в XP – одне з найважливіших складових. Екстремальний підхід припускає, що тести пишуться до написання коду. Кожний модуль зобов'язаний мати unit test – тест даного модуля. Таким чином, в XP здійснюється регресійне тестування, «непогіршення якості» при додаванні функціональності. Більшість помилок виправляються на стадії кодування. Тести пишуть самі програмісти, кожний з них має право написати тест для будь-якого модуля. Ще один важливий принцип: тест визначає код, а не навпаки (test-driven development), тобто частина коду кладеться в сховище тоді й тільки тоді, коли всі тести пройшли успішно, а якщо ні, то дана зміна коду відкидається.

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

Швидка розробка додатків — Rapid Application Development (RAD)

RAD (від англ. Rapid application development - швидка розробка додатків) — концепція створення засобів розробки програмних продуктів, що приділяє особливу увагу швидкості і зручності програмування, створенню технологічного процесу, що дозволяє програмісту максимально швидко створювати комп'ютерні програми. Практичне визначення: RAD — це життєвий цикл процесу проектування, створений для досягнення більш високої швидкості розробки та якості ПЗ, ніж це можливо при традиційному підході до проектування. З кінця XX століття RAD набула широкого поширення і схвалення.

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

Технологію RAD доцільно застосовувати, коли чітко визначені деякі пріоритетні напрямки розробки проекту.

  1.  Виконання проекту необхідно в стислі терміни.
  2.  Нечітко визначені вимоги до ПЗ.
  3.  Проект виконується в умовах обмеженості бюджету.
  4.  Інтерфейс користувача (GUI) (Graphical user interface, графічний інтерфейс користувача) є головний фактор.
  5.  Можливість розбивки проекту на функціональні компоненти.
  6.  Низька обчислювальна складність ПЗ.

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

Основні принципи

Принципи RAD технології спрямовані на забезпечення трьох основних її переваг — високої швидкості розробки, низької вартості і високої якості. Досягти високої якості програмного продукту вельми непросто і одна з головних причин виникаючих труднощів полягає в тому, що розробник і замовник бачать предмет розробки (ПЗ) по-різному.

  1.  Інструментарій повинен бути націлений на мінімізацію часу розробки.
  2.  Створення прототипу для уточнення вимог замовника.
  3.  Циклічність розробки: кожна нова версія продукту ґрунтується на оцінці результату роботи попередньої версії замовником.
  4.  Мінімізація часу розробки версії, за рахунок перенесення вже готових модулів і додавання функціональності в нову версію.
  5.  Команда розробників повинна тісно співпрацювати, кожен учасник повинен бути готовий виконувати декілька обов'язків.
  6.  Управління проектом має мінімізувати тривалість циклу розробки.

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

Фази розробки

  1.  Планування — сукупність вимог, отриманих при системному плануванні та аналізі процедури розробки життєвого циклу (SDLC). На цьому етапі користувачі, менеджери та IT-фахівці обговорюють завдання проекту, його обсяг, системні вимоги, а також складнощі, які можуть виникнути при розробці. Фаза завершується узгодженням ключових моментів з RAD-групою і отриманням від керівників проекту дозволу на продовження.
  2.  Користувальницьке проектування — протягом даного етапу користувачі, взаємодіючи з системними аналітиками, розробляють моделі і прототипи, які включають в себе всі необхідні системні функції. Для перекладу користувацьких прототипів в робочі моделі RAD-група зазвичай використовує техніку об'єднаної розробки додатків (JAD) і CASE-інструменти. Користувальницьке проектування виявляється тривалим інтерактивним процесом, який дозволяє користувачам зрозуміти, змінити і в кінцевому рахунку вибрати робочу модель, що відповідає їх вимогам.
  3.  Конструювання — етап, в якому основна задача полягає в розробці програм і додатків. Аналогічна стадії "реалізація" в SDLC. У RAD, однак, користувачі продовжують брати участь і як і раніше можуть пропонувати зміни або поліпшення у вигляді розроблених ними доповідей. В їх завдання входить програмування і розробка додатків, написання коду, інтеграція модулів і системне тестування.
  4.  Перемикання — включає в себе операції по конверсії даних, тестування, перехід на нову систему і тренування користувачів. За своїм завданням нагадує фінальну стадію SDLC. Порівнюючи з традиційними методами розробки ПЗ, весь процес виявляється стислим за часом. Як результат, нова система виявляється швидше побудованої, доставленої до замовника і встановленої на робочих місцях.

Переваги

Технологія швидкої розробки додатків (RAD) дозволяє забезпечити:

  1.  швидкість просування програмного продукту на ринок;
  2.  інтерфейс, що влаштовує користувача;
  3.  легку адаптованість проекту до змінюваним вимогам;
  4.  простоту розвитку функціональності системи.

Метод розробки динамічних систем — Dynamic Systems Development Method (DSDM).

Метод розробки динамічних систем (Dynamic Systems Development Method, DSDM) — це головним чином методика розробки програмного забезпечення, заснована на концепції швидкої розробки додатків (RAD). У 2007 році DSDM став основним підходом до управління проектом і розробки додатків. DSDM — це ітеративний і інкрементний підхід, який надає особливого значення тривалої участі в процесі користувача/споживача.

Мета методу — здати готовий проект вчасно і вкластися в бюджет, але в той же час регулюючи зміни вимог до проекту під час його розробки.

Принципи

Існує 9 принципів, що складаються з 4 основних і 5 початкових точок.

  1.  Залучення користувача — це основа ведення ефективного проекту, де розробники ділять з користувачами робочий простір і тому прийняті рішення будуть більш точними.
  2.  Команда повинна бути уповноважена приймати важливі для проекту рішення без узгодження з начальством.
  3.  Часта поставка версій результату, з урахуванням такого правила, що «поставити щось хороше раніше - це завжди краще, ніж поставити все ідеально зроблене наприкінці».
  4.  Головний критерій як можна більш швидке постачання програмного забезпечення, яке задовольняє поточним потребам ринку. Але в той же час постачання продукту, який задовольняє потребам ринку, менш важливо, ніж рішення критичних проблем у функціоналі продукту.
  5.  Розробка — ітеративна і інкрементна. Вона ґрунтується на зворотному зв'язку з користувачем, щоб досягти оптимального з економічної точки зору рішення.
  6.  Будь-які зміни під час розробки — зворотні.
  7.  Вимоги встановлюються на високому рівні перш, ніж розпочнеться проект.
  8.  Тестування інтегровано в життєвий цикл розробки.
  9.  Взаємодія і співпраця між усіма учасниками необхідна для його ефективності.

Передумови для використання DSDM

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

Життєвий цикл проекту

Огляд: три стадії DSDM

Фреймворк DSDM складається із трьох послідовних стадій, які називаються предпроектна стадія, стадія життєвого циклу проекту й постпроектна стадія. Стадія життєвого циклу проекту - найбільш продумана і детально розроблена з усіх інших. Вона складається з п'яти етапів, які формують ітеративний, інкрементний підхід до розробки інформаційних систем.

Стадія 1 - Предпроектна

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

Стадія 2 - Життєвий цикл проекту

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

Стадія 3 - Постпроектна

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

Етапи життєвого циклу проекту

Етап 1А: Дослідження реалізованості

Протягом цього етапу, перевіряється реалізованість проекту в рамках DSDM. Передумови для використання DSDM перевіряються відповіддю на питання: «Чи може даний проект задовольнити необхідним економічним вимогам?», «Проект підходить для використання методу DSDM?» І «Які ризики в цьому проекті найважливіші?». Найбільш важливий метод на цьому етапі - використання робочих груп.

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

Етап 1Б: Дослідження економічної доцільності

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

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

Етап 2: Створення функціональної моделі

Вимоги, які були визначені на попередньому етапі, перетворюються в функціональну модель. Вона складається з діючого прототипу і моделей. Прототипування — ключова методика проекту на даному етапі, що дозволяє організувати залучення користувачів в проект. Розроблений прототип аналізується різними групами користувачів. Щоб досягти необхідної якості, на кожній ітерації застосовується тестування. Найважливіша частина тестування представлена на даному етапі. Створення функціональної моделі можна розділити на наступні підетапи:

  1.  Визначення функціонального прототипу: визначення функціоналу, який буде закладено в прототипі на даному етапі.
  2.  Узгодження планів: відбувається узгодження як і в які терміни має бути розроблений функціонал прототипу.
  3.  Створення функціонального прототипу: розробити прототип. Вивчити і доопрацювати прототип на даній ітерації згідно функціонального прототипу, отриманого на попередніх ітераціях.
  4.  Аналіз функціонального прототипу: перевірити справність спроектованої системи. На цьому підетапів застосовується тестування та перегляд результатів.

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

Етап 3: Проектування та розробка

Головне завдання цієї ітерації - об'єднати функціональні компоненти з попереднього етапу в єдину систему, що задовольняє вимогам користувачів. Тут також розглядаються нефункціональні вимоги. І знову на даному етапі відбувається тестування. Проектування і розробку можна розділити на наступні підетапи:

  1.  Визначення конструктивного прототипу: визначення функціональних та нефункціональних вимог, які повинні бути в системі.
  2.  Узгодження планів: відбувається узгодження як і в які терміни повинні бути реалізовані поставлені вимоги.
  3.  Створення конструктивного прототипу: створення системи, яку можна віддати користувачам для повсякденного використання. Вивчити і доопрацювати прототип на даній ітерації.
  4.  Аналіз конструктивного прототипу: перевірити справність спроектованої системи. На цьому підетапі застосовується тестування та перегляд результатів. Для створення користувацької документації використовуються протокол випробування та відгуки користувачів.

Підсумок етапу - створення конструктивного прототипу для тестування користувачами. Протестована система переходить на наступний етап. На даному етапі зовнішній вигляд і функціонал системи в загальному готові. Ще один підсумок - створення для користувача документації.

Етап 4: Реалізація

На етапі реалізації протестована система разом з користувацькою документацією доставляється майбутнім користувачам і відбувається їхнє навчання роботи з системою. Система аналізується на відповідність вимогам, поставлених на ранніх етапах проекту. Реалізацію можна розділити на наступні підетапи:

  1.  Затвердження системи користувачем: кінцеві користувачі стверджують протестовану систему для наступної реалізації і створення керівництва.
  2.  Навчання користувачів: навчання майбутнього користувача роботі з системою. Результат підетапу - контингент навчених користувачів.
  3.  Реалізація: реалізація протестованої системи серед користувачів.
  4.  Аналіз ринку системи: аналіз впливу випущеної системи на ринок. Головне питання - чи досягнута мета, поставлена при проектуванні системи. Ґрунтуючись на цьому проект переходить на наступну стадію (постпроектну) або повертається на попередню для доопрацювання.

Підсумок етапу: закінчена система, придатна для використання кінцевими користувачами, контингент навчених користувачів і детальний документ аналізу проекту.

Ітеративна і інкрементна природа DSDM

Крім тайм-боксингу і розподілу вимог по пріоритетах метод DSDM також використовує ітеративний і інкрементний підхід до створення інформаційних систем.

Етап створення функціональної моделі, етап проектування і розробки та етап реалізації можуть проходити по своїм підстадіям багато разів перш, ніж рухатися далі до наступної стадії. На кожній ітерації розглядаються нові функції і кожна поточна ітерація ґрунтується на попередній. І якщо буде потрібно, кожну ітерацію можна залишити недоробленою.

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

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

Порівняння з іншими методами розробки інформаційних систем

Вже було розроблено та застосовано безліч методів розробки інформаційних систем. Наприклад, методи швидкої розробки додатків RAD, методи ООП. Більшість цих методів схожі один на одного і на DSDM. Метод екстремального програмування також використовує ітеративний підхід до розробки інформаційних систем із залученням користувачів.

Метод Rational Unified Process - самий схожий на DSDM, також є динамічним методом розробки інформаційних систем. І знову ж у ньому застосовується ітеративний підхід в розробці.

Існують і інші методи, які можуть здатися схожими на DSDM, але існує ряд відмінностей. По-перше, він надає необхідні інструменти і способи розробки. Це дозволяє користувачам особливим чином доповнити процес розробки своїми власними методами і допомогти у прийнятті рішень. Ще одна унікальна особливість - можна змінювати не час або засоби розробки, а вимоги до проекту. Такий підхід забезпечує досягнення основних цілей DSDM - вкластися за часом і не вийти за рамки бюджету. І останнє - взаєморозуміння і спілкування між усіма учасниками і їх залучення в проект.


 

А также другие работы, которые могут Вас заинтересовать

43212. Деталь типа тело вращения – вал-шестерня 2.4 MB
  Изделие – редуктор зубчатый цилиндрический двухступенчатый предназначен для увеличения передаваемого крутящего момента и может быть использован во многих механизмах – лебёдка, станция приводная транспортёров, станция натяжная и др.
43213. Автоматизация листовых штамповочных работ 5.59 MB
  Расчет зависимости частоты вращения ротора серводвигателя от шага подачи ленты валковой подачи от числа ходов ползуна пресса и от фазового угла подачи ленты в зону штампа 3 Экономическая часть 3. При полной автоматизации работы коэффициент использования числа ходов пресса достигает 100 хотя абсолютное число используемых ходов за рабочую смену несколько ниже предельно возможного изза потерь времени на перестановку штампов заправку ленты и т. Работа комплекса начинается с того что рулон ленты устанавливается...
43214. Электропривод цепного транспортера 1.73 MB
  Вращающий момент с вала электродвигателя передается через упругую муфту с вогнутым профилем торообразной оболочки на быстроходный вал двухступенчатого цилиндрического редуктора. ВЫБОР ЭЛЕКТРОДВИГАТЕЛЯ Основными исходными данными для выбора электродвигателя являются мощность на выходном валу привода и частота вращения его вала между которыми существует связь: где: мощность на выходном валу привода кВт; окружная сила тяговое усилие кН; скорость ленты м с; Требуемая мощность электродвигателя где: требуемая мощность...
43215. Інформаційне та комунікаційне забезпечення, зв’язки з громадськістю в системі управлінської діяльності органу державної влади 38.05 KB
  Усі громадяни України, юридичні особи та державні органи мають право на інформацію. Але реалізація права на інформацію громадянами, юридичними особами і державою не повинна порушувати громадські, політичні, економічні, соціальні, духовні, екологічні та інші права, свободи і законні інтереси інших громадян, права та інтереси юридичних осіб.
43216. Проектирование редуктора вертолёта 1.14 MB
  Определение геометрических размеров передачи. Напряжение изгиба четвёртого колеса Проверочный расчет цилиндрических колёс на статическую прочность при перегрузке Выбор оптимального варианта из расчитанных передач Предварительное определение диаметров валов Предварительный подбор подшипников. Определение усилий в зацеплениях. Определение усилий в зацеплениях на второй передаче. Определение реакций в опорах валов Расчёт долговечности подшипников качения. Определение крутящих моментов на всех валах...
43217. Створення ПЗ для віртуального лабораторного стенду засобами LabVIEW 147 KB
  LabVIEW – це універсальне середовище для розробки систем збору, обробки даних та управління експериментом. Дане середовище має велику бібліотеку функцій, методів аналізу (спектральний та кореляційний аналіз, вейвлетний аналіз, методи фільтрації, статистична обробка та ін.), бібліотеки драйверів пристроїв, що відповідають найпоширенішим стандартам. Основою роботи в середовищі LabVIEW є графічне програмування з використанням блок-діаграм, що складаються з функціональних вузлів та зв’язків між ними). Всі дії зводяться до побудови структурної схеми програми в інтерактивній графічній системі з набором всіх необхідних бібліотечних образів, з яких збираються об’єкти.
43218. Реконструкция здания исторической застройки 99.5 KB
  Введение Реконструкция и обновление городской застройки и зданий стали в последние десятилетия одним из основных направлений архитектурностроительной науки что потребовало приобретения студентами соответствующих знаний и навыков закрепляемых в ходе курсовой работы по дисциплине Реконструкция зданий и сооружений. Реконструкция актуальна как для зданий исторической застройки с традиционными конструкциями так и для зданий массового строительства 19501960 гг. В связи с этим программа дисциплины предусматривает выполнение студентами двух...
43219. Реализация интерпретатора для модифицированной грамматики учебного языка MILAN 1.68 MB
  Position текущая позиция в строке просматриваемая лексическим анализатором; Number_String текущая строка программы просматриваемая лексическим анализатором; при любом условии любой символ. Семантические функции к Rсхеме лексического анализатора: y0: подготовка инициализация таблиц и переменных Position=0 Number_String=1; y1: чтение следующего символа программы на языке МИЛАН; y2: увеличение счётчика текущей позиции Position; y3: переход на новую строку в программе увеличение счётчика текущей строки и...
43220. Реконструкция зданий и сооружений 55.5 KB
  В тоже время здания возводились из капитально огнестойких и долговечных конструкций обеспечивающих срок службы зданий 100125 лет. Единственной рациональной альтернативной сносу являются модернизация и реконструкция рассматриваемых зданий методами градостроительного преобразования и переустройства которые должны быть произведены с учётом экономических социально – функциональных технических эстетических и экологических...