Моделі розробки ПЗ
Last updated
Last updated
Щоб краще розібратися в тому, як тестування співвідноситься з програмуванням та іншими видами проектної діяльності, спочатку розглянемо самі основи - моделі розробки (lifecycle model) (як частина життєвого циклу (software lifecycle)). При цьому відразу підкреслимо, що розробка програмного забезпечення є лише частиною життєвого циклу програмного забезпечення, і тут ми говоримо саме про розробку.
Модель розробки ПЗ (Software Development Model, SDM) - структура, що систематизує різні види проектної діяльності, їх взаємодію та послідовність у процесі розробки ПЗ. Вибір тієї чи іншої моделі залежить від масштабу та складності проекту, предметної галузі, доступних ресурсів та безлічі інших факторів. Вибір моделі розробки ПЗ серйозно впливає на процес тестування, визначаючи вибір стратегії, розклад, необхідні ресурси і т.д.
Знати і розуміти моделі розробки ПЗ потрібно для того, щоб вже з перших днів роботи усвідомлювати, що відбувається навколо, що, навіщо і чому ви робите. Багато тестувальників-початківців відзначають, що відчуття безглуздості того, що відбувається, відвідує їх, навіть якщо поточні завдання цікаві. Чим повніше ви представлятимете картину того, що відбувається на проекті, тим ясніше вам буде видно ваш власний внесок у загальну справу і сенс того, чим ви займаєтеся. Ще одна важлива річ, яку слід розуміти, полягає в тому, що жодна модель не є догмою чи універсальним рішенням. Нема ідеальної моделі. Є та, яка гірша чи найкраще підходить для конкретного проекту, конкретної команди, конкретних умов.
Водоспадна модель (waterfall model) сьогодні представляє швидше історичний інтерес, т.к. у сучасних проектах практично не застосовується, крім авіабудування, військової чи космічної галузі, медицини та фінансового сектора. Вона передбачає одноразове виконання кожної із фаз проекту, які, своєю чергою, суворо слідують друг за одним. Дуже спрощено можна сказати, що в рамках цієї моделі будь-якої миті часу команді «видна» лише попередня і наступна фаза. У реальній розробці ПЗ доводиться «бачити весь проект цілком» і повертатися до попередніх фаз, щоб виправити недоробки або щось уточнити.
До недоліків водоспадної моделі прийнято відносити той факт, що участь користувачів ПЗ в ній або не передбачено взагалі або передбачено лише побічно на стадії одноразового збору вимог. З точки зору тестування ця модель погана тим, що тестування в явному вигляді з'являється тут лише з середини розвитку проекту, досягаючи свого максимуму в самому кінці.
V-подібна модель (V-model)
V-модель (V-model): Модель, що описує процеси життєвого циклу розробки програмного забезпечення з складання специфікації вимог до етапу супроводу. V модель показує інтеграцію процесів тестування на кожну фазу циклу розробки програмного забезпечення. (ISTQB)
V-подібна модель (V-model) є логічним розвитком водоспаду. Можна помітити (рисунок 2.1.b), що у випадку як водоспадна, і v-образная моделі життєвого циклу ПЗ можуть містити той самий набір стадій, але принципова відмінність у тому, як ця інформація використовується у процесі реалізації проекту. Дуже спрощено можна сказати, що при використанні v-подібної моделі на кожній стадії на спуску потрібно думати про те, що і як відбуватиметься на відповідній стадії на підйомі. Тестування тут з'являється вже на ранніх стадіях розвитку проекту, що дозволяє мінімізувати ризики, а також виявити та усунути безліч потенційних проблем до того, як вони стануть проблемами реальними.
Ітераційна інкрементальна модель (iterative model, incremental model)
Інкрементна модель розробки (incremental development model): Модель життєвого циклу розробки, в якій проект поділено на серію прирощень, кожне з яких додає частину функціональності у загальних вимогах проекту. Вимоги пріоритезовані та впроваджуються у порядку пріоритетів. У деяких (але не в усіх) версіях цієї моделі життєвого циклу кожен підпроект слідує «міні V-моделі» зі своїми власними фазами проектування, кодування та тестування. (ISTQB)
Ітеративна модель розробки (iterative development model): Модель життєвого циклу розробки, в якій проект розділений зазвичай на велику кількість ітерацій. Ітерація це повний цикл розробки, що завершується випуском (внутрішнім або зовнішнім) робочого продукту, що є частиною кінцевого продукту, що розробляється, який розростається від ітерації до ітерації. (ISTQB)
Ітераційна інкрементальна модель є фундаментальною основою сучасного підходу до розробки програмного забезпечення. Ключовою особливістю даної моделі є розбиття проекту на відносно невеликі проміжки (ітерації), кожен з яких у загальному випадку може включати всі класичні стадії, властиві водоспадній і v-подібної моделям. Підсумком ітерації є збільшення (інкремент) функціональності продукту, виражене у проміжному білді (build).
Довжина ітерацій може змінюватися в залежності від безлічі факторів, проте сам принцип багаторазового повторення дозволяє гарантувати, що і тестування, і демонстрація продукту кінцевому замовнику (з отриманням зворотного зв'язку) активно застосовуватиметься з самого початку та протягом усього часу розробки проекту. У багатьох випадках допускається розпаралелювання окремих стадій усередині ітерації та активне доопрацювання з метою усунення недоліків, виявлених на будь-якій з (попередніх) стадій. Ітераційна інкрементальна модель дуже добре зарекомендувала себе на об'ємних та складних проектах, які виконують великі команди протягом тривалих термінів. Однак до основних недоліків цієї моделі часто відносять високі накладні витрати, викликані високою «бюрократизацією» та загальною громіздкістю моделі.
Спіральна модель (spiral model)
Спіральна модель є окремий випадок ітераційної інкрементальної моделі, в якому особлива увага приділяється управлінню ризиками, що особливо впливають на організацію процесу розробки проекту та контрольні точки.
Зверніть увагу на те, що тут явно виділено чотири ключові фази:
опрацювання цілей, альтернатив та обмежень;
аналіз ризиків та прототипування;
розробка (проміжної версії) продукту;
планування наступного циклу.
З точки зору тестування та управління якістю підвищена увага ризикам є відчутною перевагою при використанні спіральної моделі для розробки концептуальних проектів, в яких вимоги є природно складними і нестабільними (можуть багаторазово змінюватися в процесі виконання проекту).
Гнучка модель (agile model)
Гнучка методологія розробки програмного забезпечення (agile software development): Група методологій розробки програмного забезпечення, заснованих на ітеративної поетапної розробки, де вимоги і рішення розвиваються за допомогою співпраці між міжфункціональними командами, що самоорганізуються. (ISTQB)
Гнучка модель є сукупністю різних підходів до розробки ПЗ і базується на т.зв. "agile-маніфесте". Покладені в основу гнучкої моделі підходи є логічним розвитком та продовженням всього того, що було за десятиліття створено та випробувано у водоспадній, v-подібній, ітераційній інкрементальній, спіральній та інших моделях. Причому тут вперше було досягнуто відчутного результату у зниженні бюрократичної складової та максимальної адаптації процесу розробки ПЗ до миттєвих змін ринку та вимог замовника.
Дуже спрощено (майже на межі допустимого) можна сказати, що гнучка модель є полегшеною з точки зору документації суміші ітераційної інкрементальної та спіральної моделей; при цьому слід пам'ятати про «agile-маніфест» і всі переваги і недоліки, що з нього випливають.
Головним недоліком гнучкої моделі вважається складність її застосування до великих проектів, а також часто помилкове впровадження її підходів, викликане недорозумінням фундаментальних принципів моделі. Проте можна стверджувати, що дедалі більше проектів починають використовувати гнучку модель розробки.
У деяких джерелах можна знайти ще пару моделей :
Prototype Model
Prototype Model – це модель, у якій прототип розробляється раніше, ніж фактичне програмне забезпечення. Моделі-прототипи мають обмежені функціональні можливості та неефективну продуктивність порівняно з реальним програмним забезпеченням. Фіктивні функції використовують для створення прототипів. Це цінний механізм розуміння потреб клієнтів. Впроваджуються відгуки, і прототип знову перевіряється замовником щодо будь-яких змін. Цей процес триває доти, доки модель не буде прийнята замовником. Після збору вимог створюється швидкий дизайн та створюється прототип, який представляється замовнику для оцінки. Відгуки клієнтів та уточнені вимоги використовуються для модифікації прототипу та знову надаються замовнику для оцінки. Після того, як замовник затверджує прототип, він використовується як вимога до створення реального програмного забезпечення. Фактичне програмне забезпечення збудовано з використанням підходу моделі водоспаду.
Переваги прототипу моделі: Модель прототипу знижує вартість та час розробки, оскільки дефекти виявляються набагато раніше. Відсутні функції або функціональні можливості або зміна вимог можуть бути виявлені на етапі оцінки та можуть бути реалізовані у доопрацьованому прототипі. Залучення клієнта на початковому етапі зменшує плутанину у вимогах чи розумінні будь-якої функціональності.
Недоліки прототипу моделі: Оскільки замовник бере участь у кожному етапі, замовник може змінити вимоги до кінцевого продукту, що збільшує складність обсягу робіт і може збільшити час доставки продукту.
Модель Великого Вибуху ( Big Bang Model )
Big Bang Model не має певного процесу. Гроші та зусилля об'єднуються, оскільки вхід і вихід є розробленим продуктом, який може збігатися, а може і не збігатися з тим, що потрібно замовнику. Модель Великого Вибуху не потребує особливого планування та складання графіків. Розробник виконує аналіз вимог та кодування, а також розробляє продукт відповідно до його розуміння. Ця модель використовується лише для невеликих проектів. Ні команди тестування та формального тестування не проводиться, і це може бути причиною провалу проекту.
Переваги моделі великого вибуху Це дуже проста модель. Потрібно менше планування та складання графіків. Розробник може створювати власне програмне забезпечення.
Недоліки великого вибуху: Моделі Великого вибуху не можна використовувати для великих, поточних і складних проектів. Високий ризик та невизначеність.
Джерела:
Дод. матеріал:
. Розділ 2.
“Додаток С (довідковий). Тестування у різних моделях життєвого циклу”