Що таке повний цикл розробки програмного забезпечення

Розбираємо на прикладі простого мобільного застосунку – щоб стало зрозуміло, як насправді створюється програмний продукт.

Ви відкриваєте на телефоні застосунок – будь-який. Натискаєте кнопку, бачите результат. Усе працює секунду. За цією секундою стоїть робота, про яку більшість людей навіть не здогадуються.

Створення програмного продукту – це не написання коду. Точніше, не лише написання коду.

Усе разом це називається повний цикл розробки програмного забезпечення (англійською – Software Development Life Cycle, SDLC). У цій статті розберемо його простими словами, на прикладі звичайного мобільного застосунку. А наприкінці поговоримо про те, чому розуміння цього циклу важливе для тих, хто обирає ІТ-спеціальність для вступу.

Простежимо весь шлях на одному наскрізному прикладі – застосунку «Щоденник тренувань». Це маленький, але справжній продукт: ви вводите вправу, вагу, кількість підходів, а застосунок показує ваш прогрес від тижня до тижня. Корисна штука для тих, хто ходить у спортзал і не хоче все це писати в зошит.

Звучить просто? На перший погляд – так. Зараз побачите, скільки за цим стоїть.

Гуру, котик-помічник кафедри ІПЗ

Привіт! Зараз ми разом простежимо, як з ідеї народжується справжній застосунок – крок за кроком, на прикладі звичайного щоденника тренувань. Я буду поруч і підкажу головне там, де легко заплутатися.

Етап 1.
З’ясувати, що саме треба зробити (аналіз вимог)

Здавалось би – що тут думати? Застосунок для запису тренувань. Сів, записав, готово. Але починається все з простих питань, які насправді складні:

• Хто наш користувач? Початківець, який щойно прийшов у зал, чи досвідчений атлет із десятирічним стажем? У них зовсім різні потреби.
• Що саме записувати? Тільки вагу і повтори? А час між підходами? А самопочуття? Чим більше полів – тим повільніший ввід, але точніша аналітика.
• Як часто люди користуватимуться? Двічі-тричі на тиждень – застосунок має «запам’ятовувати», де ми зупинилися. Щодня – інтерфейс має бути дуже швидким.
• Які ще функції потрібні? Нагадування про тренування? Поради щодо харчування? Можливість показати досягнення друзям?

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

Етап 2.
Спроєктувати, як це буде влаштовано (архітектура та дизайн)

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

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

Дизайн інтерфейсу

Як виглядатиме головний екран? Список тренувань чи кнопка «Почати тренування»? У залі телефон часто беруть однією рукою – отже, всі важливі кнопки мають бути в зоні великого пальця. Шрифт – великий, бо в залі окуляри ніхто не одягає. Кольори – контрастні, бо світло різне.

Архітектура застосунку

Це невидима частина, але найважливіша. Головне питання – де зберігати дані:

• На самому телефоні? А що, якщо людина зміняла телефон і втратила всю історію тренувань за два роки?
• На сервері в інтернеті? А що, якщо в залі немає інтернету (а так буває часто в підвальних залах)?

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

Технологічний стек

На чому писати? Окремий застосунок для Android і окремий для iOS – це дві команди розробників і два бюджети. Або один кросплатформений застосунок (наприклад, на Flutter чи React Native) – одна команда, але деякі функції можуть працювати трохи повільніше.

Хто це робить: UI/UX-дизайнери (інтерфейс), архітектори ПЗ (внутрішня структура), технічні лідери команд. На малих проєктах це може робити один досвідчений інженер.

Етап 3.
Написати програмний код (розробка)

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

• Інтерфейс – екрани, кнопки, форми вводу. Та частина, яку бачить користувач (Frontend).
• Логіку обробки даних – код, який рахує тижневий прогрес, складає графіки, перевіряє коректність значень. Те, що відбувається «всередині».
• Серверну частину – те, що працює в інтернеті: зберігає дані всіх користувачів, синхронізує тренування між пристроями (Backend).
• Базу даних – місце, де структуровано лежить вся інформація: ваші тренування, вправи, налаштування.

На цьому етапі команда поділяє роботу: хтось робить екран зі списком вправ, хтось – форму введення підходів, хтось – серверну частину, хтось – графіки. Щоб 5–10 розробників не плуталися й не псували один одному код, використовуються спеціальні інструменти й методології: системи контролю версій (Git), таск-трекери (Jira), регулярні зустрічі команди (Scrum), огляди коду (code review).

Чому не можна просто «писати код як хочеш»? Бо через місяць ніхто, включно з автором, не пам’ятатиме, навіщо в одному місці зроблено те-то. Тому є стандарти: як іменувати змінні, як структурувати файли, як коментувати складні місця, як описувати зміни. Усе це разом називається інженерною культурою розробки.

Хто це робить: розробники (Frontend, Backend, Mobile, Database) – кожен у своїй спеціалізації.

ГУРУ ПІДКАЗУЄ

Зверни увагу: «написати код» і «написати код, який зрозуміє вся команда й через рік» – це різні речі. Саме тому є Git, code review та стандарти. Це і є інженерна культура – і саме її найскладніше надолужити самотужки.

Етап 4.
Перевірити, що все працює (тестування)

Цей етап – як перевірка нової машини перед тим, як її поставити в шоурум. Що тестувати у застосунку для тренувань? Здавалося б – додав вправу, побачив у списку, готово. Але ось реальні сценарії, які треба перевірити:

• Користувач ввів вагу «−50 кг»? Застосунок має показати помилку, а не зберегти від’ємне число.
• Ввів «0 повторів»? Технічно не від’ємне, але смислу немає.
• Натиснув «Зберегти», а інтернет пропав на середині? Дані мають зберегтися локально, а не зникнути.
• Відкрив застосунок на двох пристроях і додає різні вправи? Як уникнути конфлікту даних?

Таких сценаріїв – сотні. Кожен має бути перевірений. Тестування буває ручне (тестувальник просто клацає по застосунку та шукає помилки) і автоматичне (написаний окремий код, який сам перевіряє сотні сценаріїв за хвилину). У серйозних компаніях більшість тестів – автоматичні.

Хто це робить: QA-інженери (Quality Assurance – забезпечення якості). У хороших командах розробники самі пишуть базові тести, а QA фокусуються на складніших сценаріях.

Етап 5.
Запустити в роботу (розгортання, deployment)

Застосунок написаний, протестований. Здавалось би – викладай у App Store і Google Play, і все. Але між «застосунок працює на ноутбуці розробника» та «застосунок працює у 10 000 користувачів» – велика прірва. Що потрібно зробити:

• Розгорнути серверну частину на хмарних серверах (наприклад, AWS чи Google Cloud) так, щоб вона витримувала не лише сьогоднішні 100 користувачів, а й майбутні 100 000.
• Розмістити базу даних на сервері, налаштувати резервне копіювання, щоб дані не пропали внаслідок збою.
• Подбати про захист від атак – у застосунку зберігаються особисті дані (вага, тренування). Потрібні авторизація, шифрування, захист від злому.
• Пройти магазини застосунків – модерацію в App Store і Google Play, підготувати скріншоти, описи, угоду користувача.
• Налаштувати аналітику та моніторинг – інструменти, які покажуть, де люди застрягають, які функції найпопулярніші, які екрани викликають помилки.

Хто це робить: DevOps-інженери, SRE (Site Reliability Engineers), фахівці з кібербезпеки.

Етап 6.
Підтримувати та розвивати (супровід)

Запустилися – і думаєте, що все? Ні. Тут починається найдовший етап у житті будь-якого продукту. Користувачі починають користуватися застосунком, і відразу з’являється кілька типових ситуацій:

• Знаходять помилки, які пропустили тестувальники, – їх треба швидко виправляти й випускати оновлення.
• Просять нові функції: «додайте можливість поділитися тренуванням», «зробіть інтеграцію з Apple Watch», «дайте підказки техніки виконання».
• Користуються несподіваним чином: виявляється, 30% людей використовують застосунок не для силових тренувань, а для йоги. Чи варто додати окремий режим?
• Іноді все ламається: оновлення Android несподівано порушує роботу однієї функції – треба зрозуміти чому й випустити виправлення.

Крім того, треба слідкувати за серверами й масштабувати їх, оновлювати безпеку (з’являються нові способи атак), стежити за актуальністю (вийшов новий iPhone чи нова версія Android) і регулярно випускати оновлення з новими функціями.

Якщо код був написаний за стандартами – нові розробники швидко розбираються. Якщо ні – кожна зміна вимагає тижнів вивчення «що тут взагалі відбувається». Якщо була інженерна культура – продукт живе довго й розвивається. Якщо ні – він повільно деградує, поки не з’являється конкурент і не витісняє його з ринку.

Хто це робить: уся команда, що створила продукт, плюс інженери технічної підтримки. Окремої посади «супровід» немає – це частина роботи всіх.

А чи завжди потрібні всі ці етапи?

Може скластися враження, що це все – якісь надмірно складні процедури, і насправді можна простіше. Часом – так, можна. Якщо ви робите крихітний скрипт для себе (наприклад, для автоматизації власної роботи з таблицями) – можна обмежитися лише написанням коду. Жодних окремих етапів аналітики чи тестування. Свій продукт, свій ризик.

Але як тільки продукт виходить за межі однієї людини – потрібен повний цикл. Чим більше користувачів, чим серйозніша задача, чим більша команда – тим суворіше треба дотримуватися всіх етапів. У великих компаніях на кшталт Google або українських Grammarly, MacPaw, Reface цикл дотримується дуже строго: ціна помилки висока, бо мільйонна аудиторія миттєво помітить будь-який збій.

І до чого тут вибір спеціальності?

Тепер головне. Різні ІТ-спеціальності в університетах готують до різних частин цього циклу:

• Деякі програми зосереджені переважно на написанні коду (третій етап). Випускник уміє писати програми, але не обов’язково розуміє, як їх правильно проєктувати, тестувати, супроводжувати.
• Деякі – на математичних та алгоритмічних засадах, тобто на тому, що відбувається «всередині» коду. Випускник сильний у складних обчислювальних задачах, машинному навчанні, обробці даних. Це окрема, дуже цінна спеціалізація.
• Деякі – на експлуатації та інтеграції великих ІТ-систем (п’ятий і шостий етапи): розгортання, безпека, надійність, інтеграція компонентів.

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

• Етап 1. Аналіз вимог до програмного забезпечення
• Етап 2. Архітектура та проєктування ПЗ, моделювання ПЗ та патерни проєктування, UI/UX дизайн
• Етап 3. Конструювання ПЗ, програмування на Python, C++, Java, веб-програмування
• Етап 4. Якість ПЗ та тестування
• Організація команди. Гнучкі методології (Scrum, Agile) і менеджмент проєктів ПЗ
• Етапи 5–6. Супровід ПЗ, безпека програм та даних

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

Як зрозуміти, чи ваш це шлях?

Спробуйте відповісти собі:

• Вам цікаво розуміти всю картину, як з ідеї виростає робочий застосунок? Чи лише якийсь конкретний шматочок?
• Вам подобається працювати в команді, координуючи свою роботу з іншими? Чи комфортніше зосереджуватися на самостійній технічній задачі?
• Ви бачите себе людиною, яка створює продукт цілком (можливо, навіть власний стартап)? Чи спеціалістом, який глибоко занурюється в одну вузьку область?

ГУРУ РОЗМІРКОВУЄ

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

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

Якщо лишилися питання

Гуру наостанок

Я радий, що ти пройшов увесь цикл разом зі мною! Тепер ти знаєш головне: програма – це не лише код, а цілий шлях від ідеї до підтримки роками.

Захочеш дізнатися більше чи щось запитати – ми завжди на зв’язку.

До зустрічі на кафедрі!