ОГЛЯД ФОРМАЛЬНИХ МЕТОДОЛОГІЙ РОЗРОБКИ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

МЕТОДОЛОГІЇ РОЗРОБКИ ПО Існує три основні моделі процесу розробки: 1. Водопадна (Waterfall) 2. Ітеративна модель (Iterative development) 3. Розробка, що базується на компонентах (Component-based engineering) Ітеративна модель (Iterative development) RUP (Rational Unified Process) В Agile входять методики: MSF (Microsoft Solution Framework) XP SCRUM Agile TDD (Test Driven Development)

RUP (Rational Unified Process) Кожна ітерація – це реалізація деякого сценарію (use-case), який повинна виконувати система, тобто, як вона повинна працювати для отримання певного результату. Таких сценаріїв у системи може бути багато. На кожній ітерації проводиться реалізація окремо взятого сценарію та презентується замовнику. На наступній ітерації реалізується другий сценарій у відповідності із доповненнями замовника виправляється перший.

RUP (Rational Unified Process) Тривалість однієї ітерації – місяць. Всі ітерації розбиваються на 4 фази: 1. Відправна точка (Inception) – визначаються високорівневі вимоги та ціль розробки. 2. Обговорення (Elaboration) – обговорення та отримання базової архітектури. 3. Розробка (Construction) – реалізація. 4. Інтеграція (Transition) – здача та отримання замовником. В кожній фазі по 2 -3 ітерації. Очевидно, що в фазі “обговорення” ітерацій буде менше ніж у фазі “розробки”. Результатом кожної ітерації повинен бути виконуючий файл.

MSF (Microsoft Solution Framework) На відміну від RUP тут є інструмент для організації роботи над проектом Visual Studio Team System. Підхід Microsoft – потрібно крутити ітераційно наступні етапи: - envisioning (представлення), - planning (проектування), - developing (розробка), - stabilizing (налагодження), - deploying (розгортання). Члени команди розбиваються згідно ролям: розробники, тестувальники, керівники і д. р. При цьому ніякого ієрархічного підпорядкування.

MSF (Microsoft Solution Framework) Принципи майже ті ж, що і в RUP: люди працюють паралельно, нюанси з'ясовуються в роботі, перший результат з'являється швидко, продукт зростає з прототипів, час ітерації 2 тижні.

Agile Має місце та самі ідея з ітерацій. Але окрім вище згаданих додаються ще наступні принципи: 1. Фіксовані ітерації. Жорсткі часові відсічення присутні на всіх етапах і ітераціях. 2. Ітерації меншої тривалості та більшої частоти. 3. Жорстка відповідність планам ітерацій. 4. Раннє та всебічне тестування 5. Постійне навчання та адаптація 6. Оперативна реакція на нові вимоги

Agile 1. XP – інженерні практики екстремального програмування, серед яких парне програмування, ревізія коду, тісне спілкування з замовником та всередині команди і т. п. . 2. SCRUM – методика роботи команди, яка включає самооганізацію всіх учасників процесу, щоденні зустрічі, спілкування з замовником, формування баглогів. 3. TDD (Test Driven Development) – методика персонального мікропроектування, під час якої розробка тестів передує кодуванню.

Agile День в agile команді починається з мітингу, на якому кожен розробник розповідає про те, що робив, про те, що буде робити і які в нього виникають проблеми. Після мітингу настає час вирішення актуальної задачі. В такому випадку краще діяти в наступній послідовності: 1. Написання тестів. При цьому відбувається формалізація вимог до коду і мікропроектування. 2. Кодування. Написання робочого коду, що задовольняє написаним раніше тестам. 3. Невелика відладка. Коригування коду для повного проходження тестів. 4. Рефакторинг. Зміна структури функціональності.

TDD (Test Driven Development) Часто може зустрічатися щось на кшталт "модульне тестування - це добре, але часу на нього у нас немає". Тестування дійсно збільшує витрати часу на кодування (за різними оцінками, на величину від 15 до 100%). З іншого боку, тестування радикально скорочує витрати часу на: Øналагодження; Øрефакторинг; Øспілкування між програмістами і тестерами з приводу "багів" та інші наслідки потрапляння помилок в черговий build.

TDD (Test Driven Development) З практичної точки зору, основою TDD є цикл "red / green / refactor". 1) У першій фазі програміст пише тест. 2) В другій - код, необхідний для того, щоб тест працював. 3) В третій, при необхідності, проводиться рефакторинг. Послідовність фаз дуже важлива. Відповідно до принципу "Test First", слід писати тільки такий код, який абсолютно необхідний, щоб тести виконувалися успішно.

ТРИ КОЛЬОРИ 1. Червоне світло - тести не пройдені через помилки у головному коді. Необхідно виправити виконуваний код. 2. Зелене світло - тести не пройдені через відсутність тестованої функції. Функція, що тестується, ще написана в головному коді, необхідно зробити заглушку, або повністю написати функцію. 3. Синє світло - всі тести пройдені, можна відпочити або почати писати новий тест.

TDD (Test Driven Development) Перш за все, для успішного застосування TDD необхідне вміння збирати та інтерпретувати деякі стандартні метрики тестування. В XP-групі для оцінки якості тестування застосовуються: ØКоефіцієнт покриття коду (code coverage); ØКількість тестів ØКількість asserts; ØКількість рядків коду в модульних тестах; ØСумарний час виконання тестів. Найбільш важливий показник - коефіцієнт тестового покриття, або code coverage, що обчислюється як відношення числа інструкцій, виконаних тестами, до загальної кількості інструкцій у модулі або додатку.

TDD (Test Driven Development) Загальний coverage програми є основним засобом оцінки повноти модульного тестування, і в нашому випадку навіть існує угода із замовником щодо його мінімально допустимого рівня. Як правило, задовільним вважається coverage не нижче 75% або більше, залежно від конкретного додатка. 100% сoverage не є чимось незвичайним і досить легко досягається при використанні "Test First".

TDD (Test Driven Development) Використовувати сoverage для оцінки стану модульних тестів слід обережно. Ця метрика скоріше дозволяє виявити проблеми, ніж вказати на їх відсутність. "Погані" значення coverage чітко сигналізують про те, що тестів у додатку недостатньо, тоді як "хороші" значення не дозволяють зробити зворотного висновку. Проблема в тому, що повнота тестів ніяк не пов'язана з їх коректністю. За рамками coverage залишається також важливе питання про діапазони параметрів функцій. Проте coverage зручно застосовувати, з одного боку, для загального спостереження за тестуванням в проекті, а з іншого - для виявлення не покритих тестами ділянок коду.

TDD (Test Driven Development) Три інших показника зазвичай має сенс розглядати разом. На відміну від coverage, кількість тестів, asserts і рядків коду найцікавіше спостерігати в динаміці. ! При нормальному використанні TDD повинні рости щодня і рівномірно, причини різких змін необхідно виявляти. Певний інтерес представляє аналіз відносин між цими та іншими метриками: наприклад, велика різниця між кількістю asserts і тестів може говорити про те, що тестів в середньому більше, ніж потрібно.

TDD (Test Driven Development) Підтвердити або спростувати це твердження може середня кількість рядків коду в тесті. Іноді має сенс розглядати такі показники, як: -середня кількість тестів, які додаються щодня; -відношення тестів до основного коду за кількістю рядків та інші, Але складно підібрати вдале поєднання.

TDD (Test Driven Development) Час виконання тестів виступає важливою метрикою з двох причин: ØПо-перше, різке погіршення часу виконання тестів є досить надійним сигналом появи проблем з продуктивністю програми. ØПо-друге, чим довше виконуються тести, тим менш зручно з ними працювати і тим рідше програмісти їх запускають. Тому необхідно стежити за тим, щоб час роботи тестів не збільшувалася через недбалість, а іноді має сенс навіть докладати певних зусиль щодо їх оптимізації.

TDD (Test Driven Development) Декомпозиція задачі: v. Кодування починається одразу v. Точних вимог не потібно v. Постійно переглядається дизайн v. В будь-який момент можна повернусь на 180 градусів Задачу легко оцінити: 1. Після перших Чер. Зел. Реф отримуємо достатньо детальний чеклист 2. Можна дати більш точну оцінку роботі, якби прийшлось тримати все в голові.

TDD (Test Driven Development) Все знаходиться на папері, а не в голові Клієнт полюбляє змінювати вимоги. Він буде задоволений тим, що ці зміни приймаються легко. Клієнт отримує систему раніше чим зазвичай, зможе її спробувати, і раніше повідомити, де саме, його “не так зрозуміли”.

TDD (Test Driven Development) + парне програмування Одна голова добре, а дві – краще! Адже один знає одне, а інший – інше. Відбувається інтенсивний обмін досвідом Причому навіть, Senior навчається у Junior

TDD (Test Driven Development) + парне програмування Тут есть свои роли Штурман та Пілот Один спеціаліст зазвичай воює з кодом, тоді як пара найчастіше грає в програмування.

TDD (Test Driven Development) + парне програмування У розпорядженні лише один комп’ютер. Тому завдання виконується швидше

TDD (Test Driven Development) + парне програмування За рахунок чого прискорюється робота? Зосередження уваги на проекті: жодних e-mail, ICQ, Skype, Facebook! 2 пари бачать більше багів

TDD (Test Driven Development) + парне програмування Пілот • Пише код • Зосереджений на одній задачі • Коментує те, що він робить Штурман Складає список задач: • Слідкує за тим, що говорить та пише пілот • Не дає пілоту реалізувати «о! це крута фішка» »

TDD (Test Driven Development) + парне програмування Якщо штурман – Senior? Його задача – мовчати та не заважати пілоту. Тим паче, якщо пілот Junior.

TDD (Test Driven Development) + парне програмування Коли відбувається зміна ролями? ØКоли штурман сидить поруч та починає засипати. Особливо, якщо штурман - Senior! ØПісля переви на каву, чай ØКоли пілот в тупіке ØЯкщо поточне завдання вирішене пілотом ØЯкщо минуло більше 15 хвилин

TDD (Test Driven Development) + парне програмування Перед початко слід виписати всі ідеї по характеристикам та властивостям повинні задокументуватися Працювати не більше 8 годин за день!

TDD (Test Driven Development) + парне програмування Блоксхема Комміт! Комміт!

TDD (Test Driven Development) + парне програмування “Нет отладчику - пишем тесты!” Ø TDD та Debug протирічать один одному Ø TDD був придуманий, щоб не робити Debug Ø Не роби Debug! Ø Просто напиши тест Намагаємось вивести систему з ладу! Написання тесту для, того аби вивести систему з ладу

TDD (Test Driven Development) + парне програмування Кожні 15 хвилин комміт Øкомміт для кодера == save для геймера Øкомміт одразу, як тільки всі тести стали зеленими Ø «мама, я еще чуть-чуть. . . » не має місце! Спочатку тест (Test first) 1) Гарантія, що код охоплений тестами 2) Зменшує стрес розробника, викликаний недостатнім тестуванням

TDD (Test Driven Development) + парне програмування Якщо не так, то - rollback ØЯкщо більше 30 хвилин кодуємо → rollback ØЯкщо зламано більше одного тесту → rollback ØЯкщо зайшли в тупік → rollback ØІнколи в цілях профілактики, для отримання нових ідей.

TDD (Test Driven Development) + парне програмування Коли я не використовую TDD? ØВикористовую debug ØНамагаюся продумати всю архітектуру наперед і / або подовгу відкладаю написання першого рядка коду ØОдна ітерація Чер. Зел. Реф займає> 20 хв. ØВсе, що належить зробити в недалекому майбутньому я тримаю в голові. ØЗ'явилася гарна ідея (яка потім заощадить багато часу) - я тут же беруся її реалізувати. ØБуває, що на один крихітний червоний тест я пишу відразу багато коду.

TDD (Test Driven Development) + парне програмування Зрозуміло, до тестів застосовуються ті ж вимоги стандартів кодування, що і до основного коду. Один з головних питань у модульному тестуванні - що потрібно тестувати і в якому обсязі? Класична відповідь TDD: тестувати потрібно все, що потенційно може не працювати. Найбільш практичний критерій - тестове покриття. Тестів повинно бути написано як мінімум стільки, щоб coverage знаходився в межах норми.