Методології розробки пз
Методологія - це система принципів, а також сукупність ідей, понять, методів, способів і засобів, що визначають стиль розробки програмного забезпечення. Методологія - це реалізація стандарту. Самі стандарти лише говорять про те, що повинно бути, залишаючи свободу вибору та адаптації. Конкретні речі реалізується через обрану методологію. Саме вона визначає, як буде виконуватися розробка. Існує багато успішних методологій створення програмного забезпечення. Вибір конкретної методології залежить від розміру команди, від специфіки і складності проекту, від стабільності та зрілості процесів в компанії і від особистих якостей співробітників. Методології представляють собою ядро теорії управління розробкою програмного забезпечення. До існуючої класифікації залежно від використовуваної в ній моделі життєвого циклу (водоспадні і ітераційні методології) додалася більш загальна класифікація на прогнозовані і адаптивні методології. Прогнозовані методології фокусуються на детальному плануванні майбутнього. Відомі заплановані завдання і ресурси на весь термін проекту. Команда насилу реагує на можливі зміни. План оптимізований виходячи зі складу робіт та існуючих вимог. Зміна вимог може привести до істотної зміни плану, а також дизайну проекту. Часто створюється спеціальний комітет з «управління змінами», щоб у проекті враховувалися тільки найважливіші вимоги. Адаптивні методології націлені на подолання очікуваної неповноти вимог і їх постійної зміни. Коли змінюються вимоги, команда розробників теж змінюється. Команда, що бере участь в адаптивної розробці, насилу може передбачити майбутнє проекту. Існує точний план лише на найближчий час. Більш віддалені в часі плани існують лише як декларації про цілі проекту, очікуваних витратах і результатах.
MICROSOFT SOLUTIONS FRAMEWORK
MICROSOFT SOLUTIONS FRAMEWORK - методологія розробки програмного забезпечення, запропонована корпорацією Microsoft. MSF спирається на практичний досвід Microsoft і описує управління людьми і робочими процесами в процесі розробки рішення. Базові концепції та принципи моделі процесів MSF:
єдине бачення проекту - всі зацікавлені особи і просто учасники проекту повинні чітко уявляти кінцевий результат, усім має бути зрозуміла мета проекту;
управління компромісами - пошук компромісів між ресурсами проекту, календарним графіком і реалізованими можливостями;
гнучкість - готовність до мінливих проектним умовам;
концентрація на бізнес-пріоритетах - зосередженість на тій віддачі і вигоді, яку очікує отримати споживач рішення;
заохочення вільного спілкування всередині проекту;
створення базових версії - фіксація стану будь-якого проектного артефакту, в тому числі програмного коду, плану проекту, керівництва користувача, настройки серверів і подальше ефективне управління змінами, аналітика проекту.
MSF пропонує перевірені методики для планування, проектування, розробки і впровадження успішних IT-рішень. Завдяки своїй гнучкості, масштабованості і відсутності жорстких інструкцій MSF здатний задовольнити потреби організації або проектної групи будь-якого розміру. Методологія MSF складається з принципів, моделей і дисциплін з управління персоналом, процесами, технологічними елементами і пов'язаними з усіма цими факторами питаннями, характерними для більшості проектів.
RATIONAL UNIFIED PROCESS
RATIONAL UNIFIED PROCESS - методологія розробки програмного забезпечення, створена компанією Rational Software. В основі методології лежать 6 основних принципів:
компонентна архітектура, реалізована і тестована на ранніх стадіях проекту;
робота над проектом в згуртованої команді, ключова роль в якій належить архітекторам;
рання ідентифікація і безперервне усунення можливих ризиків;
концентрація на виконанні вимог замовників до виконуваній програмі;
очікування змін у вимогах, проектних рішеннях і реалізації в процесі розробки;
постійне забезпечення якості на всіх етапах розробки проекту.
Використання методології RUP направлено на ітеративну модель розробки. Особливість методології полягає в тому, що ступінь формалізації може змінюватися в залежності від потреб проекту. Можна по закінченні кожного етапу і кожній ітерації створювати всі необхідні документи і досягти максимального рівня формалізації, а можна створювати тільки необхідні для роботи документи, аж до повної їх відсутності. За рахунок такого підходу до формалізації процесів методологія є досить гнучкою і широко популярною. Дана методологія застосовна як в невеликих і швидких проектах, де за рахунок відсутності формалізації потрібно скоротити час виконання проекту та витрати, так і у великих і складних проектах, де потрібен високий рівень формалізму, наприклад, з метою подальшої сертифікації продукту. Ця перевага дає можливість використовувати одну і ту ж команду розробників для реалізації різних за обсягом і вимогам.
Agile
Цінності Agile-методології:
особистості та їх взаємодії важливіше, ніж процеси та інструменти;
працююче програмне забезпечення важливіше, ніж повна документація;
співпраця з замовником важливіше, ніж контрактні зобов'язання;
реакція на зміни важливіше, ніж робота за планом.
Принципи Agile-методології:
задоволення клієнта за рахунок ранньої та безперебійної поставки цінного ПЗ;
вітаються зміни вимог, навіть в кінці розробки (це може підвищити конкурентно спроможність отриманого продукту);
часта поставка робочого ПЗ (кожен місяц або тиждень ,або ще частіше);
тісне, щоденне спілкування замовника з розробниками протягом всього проекту;
проектом займаються мотивовані особистості, які забезпечені потрібними умовами роботи, підтримкою і довірою;
рекомендований метод передачі інформації - особиста розмова (обличчям до обличчя);
працююче ПЗ - кращий вимірювач прогресса;
спонсори, розробники і користувачі повинні мати можливість підтримувати постійний темп на невизначений термін;
постійну увагу на поліпшення технічної майстерності і зручний дизайн;
простота - мистецтво НЕ робити зайвої роботи;
кращі архітектура, вимоги та дизайн виходять у самоорганізованої команди;
постійна адаптація (поліпшення ефективності роботи) до мінливих умов.
SCRUM SCRUM - методологія, призначена для невеликих команд (до 10 осіб). Весь проект поділяється на ітерації (спринт) тривалістю 30 днів кожний. Вибирається список функцій системи, які планується реалізувати протягом наступного спринту. Найважливіші умови - незмінність обраних функцій під час виконання однієї ітерації і суворе дотримання термінів випуску чергового релізу, навіть якщо до його випуску не вдасться реалізувати весь запланований функціонал. Керівник розробки проводить щоденні 20 хвилинні наради, які так і називають - scrum, результатом яких є визначення функції системи, реалізованих за попередній день, виниклі складнощі і план на наступний день. Такі наради дозволяють постійно відслідковувати хід проекту, швидко виявляти виниклі проблеми і оперативно на них реагувати.
KANBAN
KANBAN - гнучка методологія розробки програмного забезпечення, орієнтована на завдання.
Основні правила:
візуалізація розробки;
поділ роботи на завдання;
використання відміток про становище завдання в розробці;
обмеження робіт, що виконуються одночасно, на кожному етапі розробки;
вимір часу циклу (середній час на виконання одного завдання) і оптимізація процесу.
Переваги KANBAN:
зменшення числа паралельно виконуваних завдань значно зменшує час виконання кожної окремої задачі;
швидке виявлення проблемних завдань;
обчислення часу на виконання усередненої задачі. DYNAMIC SYSTEM DEVELOPMENT METHOD
DYNAMIC SYSTEM DEVELOPMENT METHOD з'явився в результаті роботи консорціум з 17 англійських компаній. Ціла організація займається розробкою посібників з цієї методології, організацією навчальних курсів, програм акредитації та т.п. Крім того, цінність DSDM має грошовий еквівалент. Все починається з вивчення здійсненності програми і області її застосування. У першому випадку, ви намагаєтеся зрозуміти, чи підходить DSDM для даного проекту. Вивчати область застосування програми передбачається на короткій серії семінарів, де програмісти дізнаються про ту сферу бізнесу, для якої їм належить працювати. Тут же обговорюються основні положення, що стосуються архітектури майбутньої системи і план проекту. Далі процес ділиться на три взаємопов'язаних циклу: цикл функціональної моделі відповідає за створення аналітичної документації і прототипів, цикл проектування і конструювання - за приведення системи в робочий стан, і нарешті, останній цикл - цикл реалізації - забезпечує розгортання програмної системи. Базові принципи, на яких будується DSDM, це активна взаємодія з користувачами, часті випуски версій, самостійність розробників у прийнятті рішень і тестування протягом всього циклу робіт. Як і більшість інших гнучких методологій, DSDM використовує короткі ітерації, тривалістю від двох до шести тижнів кожна. Особливий упор робиться на високій якості роботи й адаптованості до змін у вимогах.
Extreme Programming
Екстремальне програмування (XP) - це спрощена методологія організації розробки програм для невеликих і середніх за розміром команд розробників, що займаються створенням програмного продукту в умовах неясних або швидко мінливих вимог.
Цілі XP
Основними цілями XP є підвищення довіри замовника до програмного продукту шляхом надання реальних доказів успішності розвитку процесу розробки і різке скорочення термінів розробки продукту. При цьому XP зосереджено на мінімізації помилок на ранніх стадіях розробки. Це дозволяє домогтися максимальної швидкості випуску готового продукту і дає можливість говорити про прогнозованість роботи. Практично всі прийоми XP спрямовані на підвищення якості програмного продукту.
принципи XP
Ітеративна. Розробка ведеться короткими ітераціями при наявності активного взаємозв'язку із замовником. Ітерації як такі пропонується робити короткими, рекомендована тривалість - 2-3 тижні і не більше 1 місяця. За одну ітерацію група програмістів зобов'язана реалізувати кілька властивостей системи, кожне з яких описується в користувальницької історії. Користувальницькі історії (ПІ) в даному випадку є початковою інформацією, на підставі якої створюється модуль. Вони відрізняються від варіантів використання (ВІ). Опис ПІ коротке - 1-2 абзацу, тоді як ВІ зазвичай описуються досить докладно, з основним і альтернативними потоками, і доповнюються моделлю. ПІ пишуться самими користувачами, які в XP є частиною команди, на відміну від ВІ, які описує системний аналітик. Відсутність формалізації опису вхідних даних проекту в XP прагнуть компенсувати за рахунок активного включення в процес розробки замовника як повноправного члена команди.
Простота рішень. Ухвалюється перше найпростіше робоче рішення. Екстремальність методу пов'язана з високим ступенем ризику рішення, обумовленого поверховістю аналізу і жорстким тимчасовим графіком. Реалізується мінімальний набір основних функцій системи на першій і кожної наступної ітерації; функціональність розширюється на кожній ітерації.
Інтенсивна розробка малими групами (не більше ніж 10 чоловік) і парне програмування (коли два програміста разом створюють код на одному загальному робочому місці), активне спілкування в групі і між групами. Все це націлене на якомога більш раннє виявлення проблем (як помилок, так і зриву термінів). Парне програмування спрямоване на вирішення завдання стабілізації проекту. При застосуванні XP методології високий ризик втрати коду через догляду програміста, який не витримав інтенсивного графіка роботи. У цьому випадку другий програміст з пари грає роль «спадкоємця» коду. Важливо й те, як саме розподілені групи в робочому просторі - в XP використовується відкрите робочий простір, яке передбачає швидкий і вільний доступ всіх до всіх.
Зворотний зв'язок із замовником, представник якого фактично залучений в процес розробки.
Достатня ступінь сміливості і бажання йти на ризик.
Прийоми XP (практики)
Зазвичай XP характеризують набором з 12 правил (практик), які необхідно виконувати для досягнення хорошого результату. Жодна з практик не є принципово новою, але в XP вони зібрані разом.
Планування процесу. Вся команда розробників збирається разом, приймається колективне рішення про те, які властивості системи будуть реалізовані в найближчій ітерації. Трудомісткість реалізації кожної властивості визначається самими програмістами.
Тісна взаємодія з замовником. Представник замовника повинен бути членом XP-команди. Він пише ПІ, вибирає історії, які будуть реалізовані в конкретній ітерації, і відповідає на питання, що стосуються бізнесу. Представник замовника повинен бути експертом в автоматизованій предметної області. Необхідна наявність постійне зворотного зв'язку з представником замовника.
Загальносистемні правила іменування. Хороші системні правила іменування припускають простоту іменування класів та змінних. Команда розробників повинна мати єдині правила іменування.
Проста архітектура. Будь-яке властивість системи має бути реалізовано якомога простіше. Програмісти в XP-команді працюють під девізом: «Нічого зайвого!». Ухвалюється перше найпростіше працююче рішення, реалізується необхідний рівень функціональності на даний момент. Тим самим економиться час програміста.
Рефакторінг. Це оптимізація існуючого коду з метою його спрощення, Така робота повинна вестися постійно. Зберігаючи код прозорим і визначаючи його елементи всього один раз, програмісти скорочують число помилок, які згодом доведеться усувати. При реалізації кожного нового властивості системи програміст повинен подумати над тим, чи можна спростити існуючий код і як це допоможе реалізувати нову властивість. Крім того, не можна суміщати рефакторинг з дизайном: якщо створюється новий код, рефакторинг слід відкласти.
Парне програмування. Всі програмісти мають працювати в парах: один пише код, інший дивиться. Таким чином, необхідно розміщувати групу програмістів в одному місці. XP найбільш успішно працює в нерозподілених колективах програмістів і користувачів.
40-годинний робочий тиждень. Програміст не повинен працювати більше 8 годин на день. Необхідність понаднормової роботи - це чіткий індикатор проблеми на даному конкретному напрямку розробки. Пошук причин понаднормової роботи та їх якнайшвидше усунення - одне з основних правил.
Колективне володіння кодом. Кожен програміст в колективі повинен мати доступ до коду будь-якої частини системи і право вносити зміни в будь-який код. Обов'язкове правило: якщо програміст вніс зміни і система після цього працює некоректно, то саме цей програміст повинен виправити помилки.
Єдині стандарти кодування. Стандарти кодування потрібні для забезпечення інших практик: колективного володіння кодом, парного програмування і рефакторінга. Без єдиного стандарту виконувати ці практики як мінімум складніше, а в реальності взагалі неможливо: група працюватиме в режимі постійного браку часу. Команда працює над проектом тривалий час. Люди приходять і йдуть. Ніхто не кодує поодинці і код належить усім. Завжди будуть моменти, коли необхідно буде зрозуміти і скорегувати чужий код. Розробники будуть видаляти дублюючий код, аналізувати і покращувати чужі класи тощо. П. Згодом не можна буде сказати, хто автор конкретного класу. Отже, всі повинні підкорятися загальним стандартам кодування - форматування коду, іменування класів, змінних, констант, стиль коментарів. Вищесказане означає, що всі члени команди повинні домовитися про загальні стандартах кодування. Неважливо яких, але всі зобов'язані їм підпорядковуються.
Невеликі релізи. Мінімальна ітерація - один день, максимальна - місяць; чим частіше здійснюються релізи, тим більше недоліків системи буде виявлено. Перші релізи допомагають виявити недоліки на самих ранніх стадіях, далі функціональність системи розширюється на підставі ПІ. Оскільки користувач включається в процес розробки починаючи з першого релізу, то він оцінює систему і видає призначену для користувача історію та зауваження. На підставі цього визначається наступна ітерація, тобто, яким буде новий реліз. В XP все спрямовано на забезпечення безперервної зворотного зв'язку з користувачами.
Безперервна інтеграція. Інтеграція нових частин системи повинна відбуватися якомога частіше, як мінімум раз на кілька годин. Основне правило інтеграції наступне: інтеграцію можна виробляти, якщо всі тести проходять успішно. Якщо тести не проходять, то програміст повинен або внести виправлення і тоді інтегрувати складові частини системи, або взагалі не інтегрувати їх. Правило це - жорстке і однозначне. Якщо у створеній частини системи є хоча б одна помилка, то інтеграцію виробляти не можна. Часта інтеграція дозволяє швидше одержати готову систему, замість того щоб витрачати на складання тиждень.
Тестування. На відміну від більшості інших методологій тестування в XP - одне з найважливіших складових. Екстремальний підхід припускає, що тести пишуться до написання коду. Кожен модуль зобов'язаний мати unit test - тест даного модуля. Таким чином, в XP здійснюється регресійне тестування, «непогіршення якості» при додаванні функціональності. Більшість помилок виправляються на стадії кодування. Тести пишуть самі програмісти, будь-який з них має право написати тест для будь-якого модуля. Ще один важливий принцип: тест визначає код, а не навпаки (test-driven development), тобто шматок коду кладеться в сховище тоді і тільки тоді, коли всі тести пройшли успішно, в іншому випадку дана зміна коду відкидається.
Процес XP є неформальним, але вимагає високого рівня самодисципліни. Якщо це правило не виконується, то XP миттєво перетворюється на хаотичний і неконтрольований процес. XP не вимагає від програмістів написання безлічі звітів та побудови маси моделей. В XP кожен програміст вважається кваліфікованим працівником, який професійно і з великою відповідальністю ставиться до своїх обов'язків. Якщо в команді цього немає, то впроваджувати XP абсолютно безглуздо - краще для початку зайнятися перебудовою команди. Ризик розробки знижується тільки в команді, якій XP підходить ідеально, у всіх інших випадках XP - це процес розробки з найбільш високим ступенем ризику, оскільки інші методи зниження комерційних ризиків, крім людського фактора, в XP просто відсутні.