Найти!

Методології розробки програмного забезпечення

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

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

Матеріал цього розділу відноситься, швидше, до дисципліни «управління проектами», тому тут розглянуто вкрай стисло: будь-ласка, не сприймайте його як вичерпне керівництво — тут навряд чи розглянуто соту частку відсотка відповідної предметної галузі.

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

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

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

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

Каскадна (водоспадна) модель зараз представляє, скоріше, історичний інтерес, т.к. у сучасних проектах практично не застосовується. Вона передбачає одноразове виконання кожної із фаз проекту, які, своєю чергою, суворо слідують друг за одним (Рис. 1.2). Дуже спрощено можна сказати, що, в рамках цієї моделі, у будь-який момент часу команді «видна» лише попередня та наступна фаза. У реальній розробці ПЗ доводиться «бачити весь проект цілком» і повертатися до попередніх фаз, щоб виправити недоробки або щось уточнити.

Каскадна модель (waterfall)

Рис. 1.2. Каскадна (водоспадна) модель

Особливості каскадної моделі:

- Високий рівень формалізації процесів;
- Велика кількість документації;
- Жорстка послідовність етапів життєвого циклу без можливості повернення на попередній етап.
Мінуси:
• Waterfall-проект повинен мати актуальну документацію. Обов'язкова актуалізація проектної документації. Надлишкова документація.
• Дуже не гнучка методологія.
• Може створити помилкове враження про роботу над проектом (наприклад, фраза «45% виконано» не несе за собою жодної корисної інформації, а є лише інструментом для менеджера проекту).
• Замовник не має можливості ознайомитися з системою заздалегідь і навіть з «Пілотом» системи.
• Користувач не має змоги звикати до продукту поступово.
• Усі вимоги мають бути відомі на початку життєвого циклу проекту.
• Виникає потреба у жорсткому управлінні та регулярному контролі, інакше проект швидко виб'ється з графіків.
• Відсутня можливість врахувати переробку, весь проект робиться за один раз.
Плюси:
• Висока прозорість розробки та фаз проекту.
• Точна послідовність.
• Стабільність вимог.
• Суворий контроль за менеджментом проекту.
• Полегшує роботу зі складання плану проекту та збору команди проекту.
• Добре визначає процедуру контролю якості.

«Вир» або каскадна модель з проміжним контролем

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

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

Ітеративна модель

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

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

Спіральна модель життєвого циклу програмного забезпечення

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

Переваги моделі:

  1. Результат досягається у найкоротші терміни.
  2. Конкурентоспроможність досить висока.
  3. При зміні вимог не доведеться починати все з нуля.
    Але ця модель має один істотний недолік: неможливість регламентування стадій виконання.

V модель – розробка через тестування

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

V-модель забезпечує підтримку у плануванні та реалізації проекту. У ході проекту ставляться такі завдання:
• Мінімізація ризиків: V-подібна модель робить проект більш прозорим і підвищує якість контролю проекту шляхом стандартизації проміжних цілей та опису відповідних результатів і відповідальних осіб. Це дозволяє виявляти відхилення та ризики у проекті на ранніх стадіях та покращує якість управління проектів, зменшуючи ризики.
• Підвищення та гарантії якості: V-Model – стандартизована модель розробки, що дозволяє досягти від проекту результатів бажаної якості. Проміжні результати можна перевірити на ранніх стадіях. Універсальне документування полегшує читаність, зрозумілість та перевірюваність.
Зменшення загальної вартості проекту: ресурси на розробку, виробництво, управління та підтримку можуть бути заздалегідь прораховані та проконтрольовані. Отримані результати також універсальні та легко прогнозуються. Це зменшує витрати на наступні стадії та проекти.
• Підвищення якості комунікації між учасниками проекту: універсальний опис усіх елементів та умов полегшує порозуміння всіх учасників проекту. Таким чином, зменшуються неточності у розумінні між користувачем, покупцем, постачальником та розробником.

Модель на основі розробки прототипу

Дана модель ґрунтується на розробці прототипів та прототипування продукту та відноситься до другої групи.

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

  • Прояснити незрозумілі вимоги (прототип UI).

  • Вибрати одне із низки концептуальних рішень (реалізація сценаріїв).

  • Проаналізувати здійсненність проекту.

Класифікація прототипів:

  • Горизонтальні прототипи — моделює виключно UI, не торкаючись логіки обробки та бази даних.

  • Вертикальні прототипи – перевірка архітектурних рішень.

  • Одноразові прототипи – для швидкої розробки.

  • Еволюційні прототипи – перше наближення еволюційної системи.

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

Таблиця 1.3. - Порівняння моделей розробки ПЗ


Agile (ідеологія) – маніфест розробки програмного забезпечення

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

  • Люди та взаємодія важливіші за процеси та інструменти.
  • Працюючий продукт важливіший за вичерпну документацію.
  • Співпраця із замовником важливіша за узгодження умов контракту.
  • Готовність до змін важливіша за проходження початкового плану.

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

Основні принципи Agile-маніфесту

Ми дотримуємося таких принципів:

  • Найвищим пріоритетом для нас є задоволення потреб замовника завдяки регулярній та ранній поставці цінного програмного забезпечення.

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

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

  • Протягом усього проекту розробники та представники бізнесу мають щоденно працювати разом.

  • Над проектом мають працювати вмотивовані професіонали. Щоб роботу було зроблено, створіть умови, забезпечте підтримку та повністю довіртеся їм.

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

  • Діючий продукт - основний показник прогресу.

  • Інвестори, розробники та користувачі повинні мати можливість підтримувати постійний ритм безкінечно. Agile допомагає налагодити такий сталий процес розробки.

  • Постійна увага до технічної досконалості та якості проектування підвищує гнучкість проекту.

  • Простота – мистецтво мінімізації зайвої роботи – вкрай необхідна.

  • Найкращі вимоги, архітектурні та технічні рішення народжуються у команд, що самоорганізуються.

  • Команда повинна систематично аналізувати можливі способи покращення ефективності та відповідно коригувати стиль своєї роботи.

SCRUM

Scrum (Скрам) - це не абревіатура, цей термін взятий з регбі, який позначає бій навколо м'яча.

Сам термін Scrum можна визначити так - це методологія управління проектами, яка побудована на засадах тайм-менеджменту. Основною її особливістю є залучення до процесу всіх учасників, причому у кожного учасника є своя певна роль. Суть у тому, що не лише команда працює над розв'язанням задачі, але всі ті, кому цікаве розв'язання задачі. Не просто поставили завдання і розслабилися, а постійно «працюють» із командою, і ця робота не означає лише постійний контроль.

Основні терміни, що використовуються в методології:

  • Власник продукту (Product owner) - людина, яка має безпосередній інтерес у якісному кінцевому продукті, він розуміє, як цей продукт має виглядати/працювати. Ця людина не працює в команді, вона працює на стороні замовника/клієнта (це може бути як інша компанія, так і інший відділ), але ця людина працює з командою. І це та людина, яка розставляє пріоритети для завдань.

  • Scrum-майстер - це людина, яку можна назвати керівником проекту, хоча це не зовсім так. Головне, що це людина «заражена Scrum-бацилою» настільки, що несе її як своїй команді, так і замовнику і, відповідно, стежить за тим, щоб усі принципи Scrum дотримувалися.

  • Scrum-команда це команда, яка приймає всі принципи Scrum і готова з ними працювати.

  • Спринт — час, який береться до виконання певного (обмеженого) списку завдань. Рекомендується брати 2-4 тижні (тривалість визначається командою один раз).

  • Беклог (backlog) – це список усіх робіт. Можна сказати, це щоденник загального користування. Розрізняють 2 види беклогів: Product-Белог і спринт-Белог.

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

2. Спринт-беклог – це список робіт, який визначила команда та погодила з Власником продукту на найближчий звітний період (спринт). Завдання в спринт-бэклог беруться з product-бэклога.

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

Приклад роботи PR-агентства. Як би це могло виглядати, якби вони працювали по Scrum:

Компанія-клієнт «Ікс» хоче провести через 2 місяці масштабний захід для своїх партнерів та журналістів. Послуги щодо організації такого заходу компанія «Ікс» замовила у агентства «Зет». Компанію «Ікс» представляє PR-менеджер, який відповідає за організацію заходу клієнта. У термінології Scrum ця людина називається "Власник продукту". З боку агенції за організацію заходу відповідає account-менеджер (Scrum-майстер), у підпорядкуванні якого знаходиться команда (Scrum-команда). На спільній нараді (плануванні спринту) компанія та агентство вирішують, що вони звітуватимуть/плануватимуть кожні 2 тижні (довжина спринту). На перші 2 тижні вони запланували список завдань (спринт-белог), проте команда оцінила, що не всі з цього списку вони встигнуть виконати. Тоді PR-менеджер (він же Власник продукту) говорить, які з цього списку завдань є пріоритетнішими на найближчі 2 тижні, після чого команда береться за виконання завдань. Єдине, що тут має бути враховано, що на момент планування першого спринту повинен бути спланований весь список завдань на 2 місяці (product-беклог), щоб не вийшло так, що на момент проведення заходу щось не виконано.

Життєвий цикл спринту

 **1.Планирование спринта.**

На початку кожного спринту проводиться планування цього спринту. У плануванні спринту беруть участь замовники, користувачі, менеджмент, Product Owner, Скрам Майстер та команда.

Планування спринту і двох послідовних мітингів.

1) Планування спринту, мітинг перший.

Учасники: команда, Product Owner, Scrum Master, користувачі, менеджмент

Мета: Визначити мету спринту (Sprint Goal) та Sprint Backlog -функціональність, яка буде розроблена протягом наступного спринту для досягнення мети спринту.

Артефакт : Sprint Backlog

2) Планування спринту, мітинг другий.

Учасники: Скрам Майстер, команда

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

Артефакт: у Sprint Backlog з'являються завдання

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

**2.Остановка спринта \(Sprint Abnormal Termination\).**

Зупинка спринту провадиться у виняткових ситуаціях. Спринт може бути зупинений до закінчення відведених 30 днів. Спринт може зупинити команду, якщо розуміє, що не може досягти мети спринту у відведений час. Спринт може зупинити Product Owner, якщо потреба у досягненні мети спринту зникла.

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

**3.Daily Scrum Meeting.**

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

Скрам мітинг проводить Скрам Майстер. Він по колу ставить запитання кожному члену команди:

• Що вчора зроблено?

• Що буде зроблено сьогодні?

• З якими проблемами зіткнувся?

Скрам Майстер збирає всі відкриті для обговорення питання у вигляді Action Items, наприклад у форматі що/хто/коли, наприклад:

• Обговорити проблему з відображенням контролю.

• Петя і Вася.

• Відразу після скраму.

Діаграма згоряння задач (Burndown chart)

Діаграма, яка показує кількість зробленої роботи. Оновлюється щодня для того, щоб у простій формі показати зрушення в роботі над спринтом. Графік має бути загальнодоступним.
Існують різні види діаграми:
• Діаграма згоряння робіт для спринту — показує, скільки завдань вже зроблено і скільки ще залишається зробити в поточному спринті.
• Діаграма згоряння робіт для випуску проекту показує, скільки завдань зроблено і скільки ще залишається зробити до випуску товару (зазвичай будується з урахуванням кількох спринтів).

Ретроспектива

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

Канбан

Термін "канбан" має дослівний переклад: "Кан" означає видимий, візуальний і "бан" - картка або дошка. На заводах Toyota картки "канбан" використовуються повсюдно для того, щоб не захаращувати склади і робочі місця заздалегідь створеними запчастинами. Наприклад, уявіть, що Ви ставите двері на Toyota Королла. У Вас біля робочого місця знаходиться пачка із 10 дверей. Ви їх ставите одну за одною на нові машини і, коли в пачці залишається 5 дверей, то Ви знаєте, що час замовити нові двері. Ви берете картку "канбан", пишете на ній замовлення на 10 дверей і відносите її тому, хто робить двері. Ви знаєте, що він їх зробить саме до того моменту, як у Вас закінчаться 5 дверей, що залишилися. І саме так і відбувається: коли Ви ставите останні двері, прибуває пачка з 10 нових дверей. І так постійно:

А тепер уявіть, що така система діє на всьому заводі. Ніде немає складів, де запчастини лежать тижнями та місяцями. Усі працюють тільки за запитом та виробляють саме стільки запчастин, скільки запрошено. Якщо раптом замовлень побільшало чи менше, то система сама легко підлаштовується під зміни.

Основне завдання карт "канбан" у цій системі - це зменшення кількості роботи, що «виконується в даний момент» (work in progress).

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

Цей метод Бережливого виробництва (Lean manufacturing) був придуманий в Тойота, і зараз багато виробничих компаній у всьому світі його впроваджують або вже впровадили.

Але це все стосується виробництва, а не розробки програмного забезпечення.

А що ж таке канбан-розробка стосовно ПЗ і чим вона відрізняється від інших гнучких методологій, чи то SCRUM чи XP?

По-перше, треба одразу зрозуміти, що канбан – це не конкретний процес, а система цінностей. Як, втім, і SCRUM із XP. Це означає, що ніхто Вам не скаже, що і як робити кроки.

По-друге, весь канбан можна описати однією простою фразою — «зменшення роботи, що виконується в даний момент (work in progress)».

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

Різниця між канбан та SCRUM:

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

Канбан-розробка відрізняється від SCRUM, насамперед, орієнтацією на завдання. Якщо в SCRUM основна орієнтація команди - це успішне виконання спринтів (треба визнати, що це так), то в канбан на першому місці завдання.

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

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

Команда для роботи використовує канбан-дошку. Наприклад, вона може виглядати так:

Стовпці зліва направо:

  • Цілі проекту: необов'язковий, але корисний стовпець. Сюди можна помістити високорівневі цілі проекту, щоби команда їх бачила і всі про них знали. Наприклад, "Збільшити швидкість роботи на 20%" або "Додати підтримку Windows 7".
  • Черга завдань: тут зберігаються завдання, які готові почати їх виконувати. Завжди до виконання береться верхня, найпріоритетніша завдання та її картка переміщається у наступний стовпець.
  • Опрацювання дизайну: цей та інші стовпці до «Закінчено» можуть змінюватися, т.к. саме команда вирішує, які кроки проходить завдання до стану «Закінчено». Наприклад, в цьому стовпці можуть бути завдання, для яких дизайн коду або інтерфейсу ще не зрозумілий і обговорюється. Коли обговорення закінчено, завдання пересувається у наступний стовпець.
  • Розробка: тут завдання висить до того часу, поки розробка фічі завершено. Після завершення вона пересувається у наступний стовпець. Або якщо архітектура не вірна або неточна, завдання можна повернути в попередній стовпець.
  • Тестування: у цьому стовпці завдання знаходиться, доки вона тестується. Якщо знайдено помилки, повертається до Розробки. Якщо ні – пересувається далі.
  • Деплоймент: всі проекти мають свій деплоймент. У когось це означає викласти нову версію продукту на сервер, а у когось просто закомітити код в репозиторій.
  • Закінчено: сюди стікер потрапляє лише тоді, коли всі роботи із завдання закінчено повністю.

У будь-якій роботі трапляються термінові завдання. Заплановані чи ні, але такі, які треба зробити зараз. Для таких можна виділити спеціальне місце (на зображенні зазначено, як «Expedite»). У Expedite можна помістити одне термінове завдання і команда повинна почати виконувати її негайно і завершити якнайшвидше. Але може бути лише одне таке завдання! Якщо з'являється ще одна — вона має бути додана до «Черги завдань».

А тепер найважливіше. Чи бачите цифри під кожним стовпцем? Це число завдань, які можуть бути одночасно у цих стовпцях. Цифри підбираються експериментально, але, вважається, вони мають залежати від кількості розробників у команді. Наприклад, якщо ви маєте 8 програмістів у команді, то у рядок «Розробка» ви можете помістити цифру 4. Це означає, що одночасно програмісти робитимуть не більше 4-х завдань, значить у них буде багато причин для спілкування та обміну досвідом. Якщо ви поставите туди цифру 2, то 8 програмістів, які займаються двома завданнями, можуть занудьгувати або гаяти занадто багато часу на обговореннях. Якщо поставити 8, то кожен займатиметься своїм завданням і деякі завдання затримуватимуться на дошці надовго, а головне завдання канбан — це зменшення часу проходження завдання від початку до стадії готовності.

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

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

Дванадцять основних прийомів екстремального програмування (за першим виданням книги Extreme programming explained) можуть бути об'єднані у чотири групи:

1.Короткий цикл зворотного зв'язку (Fine-scale feedback):

• Розробка через тестування (Test-driven development).

• Гра у планування (Planning game).

• Замовник завжди поряд (Whole team, Onsite customer).

• Парне програмування (Pair programming).

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

• Безперервна інтеграція (Continuous integration).

• Рефакторинг (Design improvement, Refactoring).

• Часті маленькі релізи (Small releases).

3. Розуміння, що поділяється всіма:

• Простота (Simple design).

• Метафора системи (System metaphor).

• Колективне володіння кодом (Collective code ownership) або вибраними шаблонами проектування (Collective patterns ownership).

• Стандарт кодування (Coding standard або Coding conventions).

4.Соціальна захищеність програміста (Programmer welfare):

• 40-годинний робочий тиждень (Sustainable pace, Forty-hour week).

РАЦІОНАЛЬНИЙ УНІФІКОВАНИЙ ПРОЦЕС (РУП)

RATIONAL UNIFIED PROCESS (RUP) – методологія розробки програмного забезпечення, створена компанією Rational Software.

В основі методології лежать 6 основних принципів:

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

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

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