Month: September 2023

Модель Великого вибуху

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

Модель великого вибуху – застосування

Модель великого вибуху передбачає зосередження всіх можливих ресурсів на розробці програмного забезпечення та кодуванні з дуже незначним плануванням або без нього. Вимоги розуміються та впроваджуються по мірі надходження. Будь-які необхідні зміни можуть вимагати або не потребувати оновлення всього програмного забезпечення.

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

Модель великого вибуху – переваги

Перевага моделі Великого Вибуху полягає в тому, що вона дуже проста і не потребує ретельного планування. Проста в управлінні та не вимагає офіційних процедур.

Переваги моделі Великого вибуху такі:

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

Модель великого вибуху – недоліки

Модель великого вибуху є моделлю дуже високого ризику, і зміни у вимогах або неправильно зрозумілі вимоги можуть навіть призвести до повного скасування проєкту.

Недоліки моделі Великого вибуху такі:

• Дуже високий ризик і невизначеність.
• Не дуже хороша модель для складних і об’єктно-орієнтованих проєктів.
• Погана модель для тривалих проєктів.
• У разі нечіткого формулювання вимог, можуть бути суттєві перевитрати.

Прототипування програмного забезпечення

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

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

Що таке прототипування програмного забезпечення?

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

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

Нижче наведено поетапний підхід до розробки прототипу програмного забезпечення.

Ідентифікація базової вимоги

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

Розробка початкового прототипу

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

Огляд прототипу

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

Перегляд та вдосконалення прототипу

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

Горизонтальні та вертикальні прототипи

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

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

Прототипування програмного забезпечення – типи

Використовуються різні типи прототипів програмного забезпечення. Нижче наведено основні типи прототипів програмного забезпечення, які широко використовуються:

Одноразове/швидке створення прототипів

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

Еволюційне прототипування

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

Інкрементне прототипування

Інкрементне прототипування означає створення кількох функціональних прототипів різних підсистем і подальшу інтеграцію всіх доступних прототипів для формування повної системи.

Екстремальне прототипування

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

Прототипування програмного забезпечення – застосування

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

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

Прототипування програмного забезпечення – переваги

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

Переваги моделі створення прототипів такі:

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

Прототипування програмного забезпечення – недоліки

Недоліки моделі прототипування такі:

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

Модель RAD

Модель RAD (швидка розробка додатків) базується на створенні прототипів та ітераційній розробці без спеціального планування. Сам процес написання програмного забезпечення передбачає планування, необхідне для розробки продукту.

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

Що таке RAD?

Швидка розробка програм – це методологія розробки програмного забезпечення, яка використовує мінімальне планування на користь швидкого прототипування. Прототип – це робоча модель, функціонально еквівалентна компоненту продукту.

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

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

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

Дизайн моделі RAD

Модель RAD включає фази бізнес-моделювання, моделювання даних, моделювання процесів, генерація додатків, тестування та оборот.

Бізнес-моделювання

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

Моделювання даних

Інформація, зібрана на етапі бізнес-моделювання, переглядається та аналізується для формування наборів об’єктів даних, життєво важливих для бізнесу. Атрибути всіх наборів даних ідентифіковані та визначені. Відносини між цими об’єктами даних встановлюються та детально визначаються відповідно до бізнес-моделі.

Моделювання процесів

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

Генерація додатків

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

Тестування

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

Модель RAD проти традиційного SDLC

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

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

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

Модель RAD – застосування

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

Наступні вказівки описують типові сценарії, коли RAD можна використовувати:

• RAD слід використовувати лише тоді, коли систему можна модулювати, щоб розробляти її поступово.
• RAD слід використовувати, якщо існує велика кількість архітекторів для моделювання.
• RAD слід використовувати, лише якщо бюджет дозволяє використання інструментів автоматичного створення коду.
• Модель RAD SDLC слід обирати лише за наявності експертів із відповідних бізнес-знань.
• Слід використовувати там, де вимоги змінюються під час проєкту, а робочі прототипи повинні бути представлені замовнику невеликими ітераціями по 2-3 місяці.

Модель RAD – переваги

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

Переваги моделі RAD наступні:

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

Модель RAD – недоліки

RAD працює добре, лише якщо доступні висококваліфіковані інженери, а замовник також зобов’язаний створити цільовий прототип у встановлені терміни. Якщо обох сторін бракує зобов’язань, модель може зазнати невдачі.

Недоліки моделі RAD такі:

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

Гнучка модель SDLC – це комбінація ітераційних і інкрементальних моделей процесів з акцентом на адаптивність процесів і задоволеність клієнтів шляхом швидкої доставки робочого програмного продукту. Гнучкі методи розбивають продукт на невеликі поетапні збірки. Ці збірки надаються в ітераціях. Кожна ітерація зазвичай триває від одного до трьох тижнів. Кожна ітерація включає міжфункціональні команди, які працюють одночасно над різними сферами, такими як:

• Планування
• Аналіз вимог
• Дизайн
• Кодування
• Тестування

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

Що таке Agile?

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

Процес Agile почав впроваджуватися в середині 90-х років та з часом став дуже популярним завдяки своїй гнучкості та адаптивності.

До найпопулярніших гнучких методологій належать Rational Unified Process (1994), Scrum (1995), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development та Dynamic Systems Development Method (DSDM) (1995).

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

Ключові ідеї (постулати) Agile Manifesto:

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

Agile та традиційні моделі SDLC

Agile базується на адаптивних методах розробки програмного забезпечення , тоді як традиційні моделі SDLC, такі як модель водоспаду, базуються на лінійному підході. Лінійний підхід в традиційних моделях SDLC зазвичай передбачає з детальне планування і повний прогноз щодо точних завдань і функцій, які будуть повинні бути виконані протягом життєвого циклу продукту.

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

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

Взаємодія з клієнтами є основою цієї Agile-методології, а відкрите спілкування з мінімальною документацією є типовою рисою Agile-середовища розробки.

Гнучка модель – переваги та недоліки

Гнучкі методи останнім часом широко поширені у світі програмного забезпечення. Однак цей метод не завжди підходить для всіх продуктів.

Переваги гнучкої моделі такі:

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

Недоліки гнучкої моделі такі:

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

V-модель – це модель SDLC, де виконання процесів відбувається послідовним чином у V-подібній формі. Вона також відома як модель верифікації та валідації.

V-модель є розширенням моделі водоспаду та базується на асоціації фази тестування для кожної відповідної стадії розробки. Це означає, що для кожної окремої фази циклу розробки існує безпосередньо пов’язана фаза тестування. Це високодисциплінована модель, і наступний етап починається лише після завершення попереднього.

У V-моделі паралельно планується відповідна фаза тестування до фази розробки. Отже, існує певний етап розробки і до цього етапу є фази веріфікації та валідації.

V-модель – етапи

У V-моделі є кілька етапів.

Аналіз бізнес-вимог

Це перша фаза циклу розробки, на якій вимоги до продукту розглядаються з точки зору клієнта. Цей етап передбачає детальне спілкування з клієнтом, щоб зрозуміти його очікування та точні вимоги. Це дуже важлива діяльність, і нею потрібно добре керувати, оскільки більшість клієнтів не впевнені, що саме їм потрібно. На цій стадії здійснюється планування проєкту приймального випробування, оскільки бізнес-вимоги можна використовувати як вхідні дані для приймального тестування (acceptance testing).

Проєктування системи

Коли у вас є чіткі та детальні вимоги до продукту, настав час розробити повну систему. Проєкт системи містить розуміння та деталізацію повного обладнання та налаштування зв’язку для продукту, що розробляється. План тестування системи розробляється на основі проєкту системи. Виконання цього на ранньому етапі залишає більше часу для фактичного виконання тесту пізніше.

Архітектурне проєктування

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

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

Проєктування модуля

На цьому етапі вказується детальна внутрішня конструкція для всіх системних модулів, що називається низькорівневим дизайном (Low Level Design) . Важливо, щоб дизайн був сумісний з іншими модулями архітектури системи та іншими зовнішніми системами. Модульні тести є важливою частиною будь-якого процесу розробки та допомагають усунути максимальну кількість недоліків і помилок на дуже ранній стадії. Ці модульні тести можуть бути розроблені на цьому етапі на основі дизайну внутрішнього модуля.

Фаза кодування

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

Модульне тестування

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

Інтеграційне тестування

Інтеграційне тестування пов’язане з етапом архітектурного проєктування. Інтеграційні тести виконуються для перевірки співіснування та зв’язку внутрішніх модулів у системі.

Тестування системи

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

Приймальне тестування

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

V-Модель – Застосування

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

Наступні умови є одними з найбільш поширених сценаріїв для використання V-моделі:

• Вимоги чітко визначені, чітко задокументовані та фіксовані.
• Визначення продукту стабільне.
• Технологія не є динамічною і добре зрозуміла команді проєкту. Немає двозначних або невизначених вимог.

V-модель – переваги

Перевага методу V-моделі полягає в тому, що його дуже легко зрозуміти та застосувати. Простота цієї моделі також полегшує керування.

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

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

V-модель – недоліки

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

Недоліки методу V-моделі наступні:

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