20. Формальні методології розробки пз(rup, Scrum, msf, xp, OpenUp, tdd).

RUP

Rational Unified Process — ітераційний процес розробки ПЗ, створений в компанії IBM. RUP базується на наступних принципах:

• Рання ідентифікація та безперервне (до закінчення проекту) усунення основних ризиків.

• Концентрація на виконанні вимог замовників до виконуваній програмі (аналіз і побудова моделі прецедентів).

• Очікування змін у вимогах, проектних рішеннях і реалізації в процесі розробки.

• Компонентна архітектура, реалізована і тестована на ранніх стадіях проекту.

• Постійне забезпечення якості на всіх етапах розробки проекту (продукту).

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

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

Scrum

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

У методології Scrum є всього три ролі:

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

• Product Owner - людина, що постачає вимоги програмістам. В обов'язки цього співробітника входить своєчасне надання вимог до продукту, визначення дат і змісту релізів, ефективне управління пріоритетами і коректування вимог.

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

Артефакти в методології Scrum:

• Product Backlog - це список наявних на даний момент бізнес-вимог і технічних вимог до системи з зазначенням пріоритетів. Product Backlog включає в себе завдання, помилки, технології, проблеми, запити і т.д.

• Sprint Backlog містить функціональність, обрану Product Owner з Product Backlog. Всі функції розбиті за завданнями, кожна з яких оцінюється командою.

• Результатом Sprint є готовий продукт, що можна передавати замовнику. Кожен sprint представляє собою «водопад». Протягом спринту робляться всі роботи зі збору вимог, дизайну, кодування і тестування продукту.

MSF

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

• Управління продуктом

• Управління програмою

• Розробка

• Тестування

• Задоволення споживача

• Управління випуском

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

1. Роль команди розробників не може бути об'єднана ні з якою іншою роллю.

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

Процес розробки з MSF є ітеративним і включає в себе наступні основні фази:

1. Вироблення концепції

2. Планування

3. Розробка

4. Стабілізація

5. Впровадження

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

XP

Extreme Programming — Екстремальне програмування - є найбільш відомою з гнучких методологій. Вона будується на 12 принципах, які можна об'єднати в 4 групи:

• Короткий цикл зворотного зв'язку

o Розробка через тестування

o Гра в планування

o Замовник завжди поруч

o Парне програмування

• Безперервний, а не пакетний процес

o Безперервна інтеграція

o Рефакторинг

o Часті невеликі релізи

• Розуміння, поділюване всіма

o Простота

o Метафора системи

o Колективне володіння кодом або обраними шаблонами проектування

o Стандарт кодування

• Соціальна захищеність програміста

o 40-годинний робочий тиждень

OpenUP

OpenUp — це Ітеративний-інкрементальний метод розробки ПЗ. Позиціонується як легкий і гнучкий варіант RUP.

В основу OpenUP покладено такі основні принципи:

• Спільна робота з метою узгодження інтересів та досягнення спільного розуміння;

• Розвиток з метою безперервного забезпечення зворотного зв'язку та вдосконалення проекту;

• Концентрація на архітектурних питаннях на ранніх стадіях для мінімізації ризиків та організації розробки;

• Вирівнювання конкурентних переваг для максимізації споживчої цінності для зацікавлених осіб.

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

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

TDD

Розробка через тестування (англ. Test-driven development (TDD)) — технологія розробки програмного забезпечення, яка використовує короткі ітерації розробки, що базуються на попередньому написанні тестів, які визначають необхідні покращення або нові функції. Кожна ітерація має на меті розробити код, який пройде ці тести. Нарешті, програміст або група вдосконалюють код для погодження змін. Один із ключових моментів TDD полягає у тому, що підготовка тестів перед написанням самого коду пришвидшує процес внесення змін.