Життєвий цикл ПЗ
Для розробки якісного програмного забезпечення необхідно добре розуміти основні принципи життєвого циклу ПЗ, вимоги замовника до продукту, що створюється, а також враховувати його фінансові можливості. Існує кілька моделей життєвого циклу (каскадна модель, спіральна модель, швидке прототипування і т.д.). Вибір певної моделі життєвого циклу залежить, в основному, від змісту та цілей проекту, а також від розміру його фінансування.
Як правило, ми віддаємо перевагу спіральній моделі, яка включає гнучкі методології розробки Agile. Тим не менш, іноді ми використовуємо каскадну модель (яка також називається «Водоспад») та її похідні для виконання невеликих або нескладних проектів. У цій статті ми надамо опис каскадної моделі, яка є класичним типом життєвого циклу програмного забезпечення.
Згідно з цією моделлю, проект реалізується покроково, відповідно до точної послідовності дій: збирання та вивчення вимог, проектування програмного забезпечення та його розробка, тестування та технічна підтримка. Каскадна модель досить гнучка, деякі етапи можуть частково збігатися.
Давайте почергово розглянемо всі етапи життєвого циклу:
1. Аналіз вимог
На цьому етапі важливо задокументувати всі вимоги щодо майбутнього програмного забезпечення. Необхідно присвятити достатньо часу для обговорення деталей проекту з усіма зацікавленими сторонами. Усі дані потрібно проаналізувати і систематизувати. Важливо також врахувати всі технічні обмеження, які можуть виникнути за замовника. Підсумком цього етапу має стати створення докладної специфікації,відповідає всім вимогам замовника. Також слід звернути увагу на інші чинники, які можуть ускладнювати процес розробки. До них належать дедлайни, встановлені замовником, а також бюджетні обмеження.
Зверніть увагу: Чим більше інформації про проект ви зберете, тим менше часу витратите на виправлення помилок, доопрацювання проекту, перегляди бюджету, обговорення та вирішення інших питань.
Бачення проекту
Важливим завданням є створення докладного документа бачення (або образу) проекту, який включає короткий опис проекту, бізнес-мети, а також критерії успіху проекту, фактори бізнес-ризиків та опис кінцевого користувача продукту.
Готовий документ необхідно передати на затвердження замовнику, щоб переконатися, що всі поставлені вимоги були враховані, а також щоб проінформувати його про будь-які ризики, які можуть виникнути після релізу проекту.
Збір вимог
Після вирішення всіх основних питань рекомендується провести додаткові обговорення та інтерактивні семінари з усіма зацікавленими сторонами. Це допоможе виявити будь-які неочевидні моменти, які надалі можуть стати причиною внесення змін до інтерфейсу програми або необхідності переписування патернів коду. Цей етап може також включати заповнення анкет, розгляд кейсів, мозковий штурм і т.д.
Багато проектів заходять у глухий кут через додаткові вимоги, які спливають на стадії розробки. Тому дуже важливо розуміти початкові бізнес-мети та головну ідею майбутнього додатку.
2. Проектування програмного забезпечення
Наступним етапом життєвого циклу ПЗ є створення документа, що описує масштаби та межі проекту. Цей документ включає в себемокапи або скетчі інтерфейсу майбутнього додатка, а також докладну специфікацію вимог програмного забезпечення. Необхідно зазначити, що в деяких випадках документ бачення (образу) проекту та документ про масштаби та межі проекту можуть бути подані як єдиний документ “Про образ та межі проекту”.
Масштаби та межі проекту
У документі, що описує масштаби та межі проекту, повинні бути перелічені основні функції програмного забезпечення, що створюється. Вони визначаються на підставі документа бачення проекту і, безумовно, з урахуванням зазначених часових рамок та встановленого бюджету. Крім того, до цього документа входять мокапи або скетчі, створені на основі документа бачення проекту, а також зібраних вимог. Ви можете намалювати скетч інтерфейсу користувача від руки або використовувати для цього програми створення мокапів, а потім погодити його із замовником. Нижче наведено список корисних програм для створення мокапів, які ми використовуємо на практиці:
У процесі обговорення проекту у замовника може з'являтися дедалі більше нових ідей щодо його реалізації. Тому рекомендується дати йому час на обмірковування свого проекту та вимог до нього, а потім повторно зібратися та обговорити деталі проекту, щоб нічого не згаяти. На цьому етапі також порушується питання про післяпродажне обслуговування продукту. Ви повинні повідомити замовника про те, яким чином буде здійснюватись технічна підтримка після завершення етапу тестування та подальшого релізу продукту. Зверніть увагу на те, що документ бачення проекту та документ про масштаби та межі проекту мають бути створені до підписання контракту.
Специфікація вимог програмного забезпечення
Специфікація вимогпрограмного забезпечення (SRS) описує вимоги, яким має відповідати створюване програмне забезпечення. Вона має бути логічною, послідовною, доступною та повною. Вимоги можуть виражатися в різних формах, наприклад, у вигляді традиційних тверджень повинності (н-р, “Система Staff Manager повинна підтримувати такі браузери: Google Chrome, Apple Safari, Mozilla Firefox, Opera, IE 8+”) або у вигляді історій користувача ( н-р, “оскільки я менеджер, мені необхідний доступ до персональної інформації всіх співробітників”). Існує велика кількість шаблонів специфікацій. Вибір певного шаблону залежить від специфіки проекту. У більшості випадків, специфікація включає опис продукту, класи користувачів, функціональні і нефункціональні вимоги до програмного забезпечення, що розробляється. Іноді шаблон також входить прототип. Головне — зробити специфікацію зрозумілою, лаконічною та корисною для розробників.
Для створення прототипу вам необхідно з'ясувати:
- спосіб отримання та обробки вхідних даних для створення необхідних даних на виході;
- форма, у якій мають бути представлені вихідні дані.
Мокапи (або прототипи) передаються UI/UX-дизайнерам, які перетворюють їх на барвисті шаблони.
3. Розробка програмного забезпечення
Необхідно відзначити, що розробка програмного забезпечення може також включати створення інтерактивного прототипу, який, по суті, є основою майбутнього додатку. Такий прототип допомагає визначити архітектуру системи загалом. На даному етапі пишеться мало коду: наприклад, код кнопок та простих форм, щоб дати замовнику загальне уявлення про те, як працюватиме кінцевий продукт. Тому мивключили створення прототипу етап розробки програмного забезпечення.
Як тільки інтерактивний прототип та дизайн програми готовий та затверджений замовником, починається розробка стандартів програми (конвенції найменувань, способу документування коду, інструкцій для кінцевого користувача тощо). Після цього можна сміливо переходити до наступного етапу життєвого циклу, а саме до розробки програмного забезпечення. Розробка ПЗ може бути розділена на невеликі частини, або юніти, і кожен юніт розробляється та тестується розробниками для перевірки його функціональності (модульне тестування).
4. Тестування програмного забезпечення
Після завершення етапу розробки продукт повинен пройти ретельне тестування, щоб переконатися, що він відповідає поставленим вимогам. На етапі приймального тестування необхідно, щоб замовник спробував застосувати продукт локально таким же чином, як він збирається використовувати його після релізу. Після виправлення основних помилок програмне забезпечення можна впроваджувати. Для виправлення незначних помилок може використовуватися проста система відстеження, що дозволить виправляти будь-які недоробки на етапі супроводу ПЗ.
5. Технічна підтримка програмного забезпечення
Після того, як продукт було протестовано та розгорнуто на сервері замовника, починається наступна фаза життєвого циклу розробки програмного забезпечення, яка називається супроводом або технічною підтримкою ПЗ. Загалом супровід має на увазі під собою виправлення дрібних багів, які виявляються на цьому етапі. Проте цілком можливо, що вам доведеться вносити деякі зміни в створене програмне забезпечення, незважаючи на всі зусилля, докладені вами напопередніх етапах. Замовник може вирішити змінити функціональність розробленого продукту. Отже, вам доведеться збирати, описувати та обговорювати нові вимоги із замовником, щоб внести до продукту необхідні зміни. В даному випадку вам доведеться працювати з новим каскадним проектом, і всі вищеописані кроки доведеться повторювати з початку.
Висновок
Ми розглянули ключові етапи розробки, які необхідні для створення якісного програмного забезпечення. Для того, щоб ваш проект був успішним, необхідно обговорити всі вимоги до майбутнього додатку з безпосереднім замовником, а також детально задокументувати всю роботу, яка має бути проведена на кожному етапі розробки.
Каскадну модель обов'язково використовують при створенні систем життєзабезпечення, що використовуються у військовій справі, космічних розробках та медицині, наприклад, при розробці програмного забезпечення для контролю польотів, систем подушок безпеки і т.д. Вона також може застосовуватися для розробки невеликих і нескладних проектів. Однак, якщо на одному з початкових етапів буде допущена помилка, існує ймовірність того, що її буде виявлено лише на етапі розробки або тестування. Тому рекомендується застосовувати цю модель тільки в тому випадку, якщо всі вимоги гранично зрозумілі і не змінюватимуться з часом.