Модель життєвого циклу розробки програмного забезпечення (SDLC)

Зміст

• Визначення - Що означає модель життєвого циклу розробки програмного забезпечення (SDLC)?
• Вступ до Microsoft Azure та Microsoft Cloud | У цьому посібнику ви дізнаєтеся, що стосується хмарних обчислень та як Microsoft Azure може допомогти вам мігрувати та вести свій бізнес із хмари.
• Techopedia пояснює модель життєвого циклу розробки програмного забезпечення (SDLC)

Визначення - Що означає модель життєвого циклу розробки програмного забезпечення (SDLC)?

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

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

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

Вступ до Microsoft Azure та Microsoft Cloud | У цьому посібнику ви дізнаєтеся, що стосується хмарних обчислень та як Microsoft Azure може допомогти вам мігрувати та вести свій бізнес із хмари.

Techopedia пояснює модель життєвого циклу розробки програмного забезпечення (SDLC)

Основні заходи з розробки програмного забезпечення включають:

• Витяг вимоги: Клієнт має неясне уявлення про те, що потрібно. Після ретельного аналізу вимог та кроків планування для досягнення мети, група абстрактних інженерів-программістів реалізує абстрактну ідею клієнта.
• Опис програмного забезпечення: описує, що програмне забезпечення є наступним кроком у процесі.
• Анотація представлення системи: Створена для підтвердження того, що вона відповідає вимогам продукту та інтерфейсів з іншими програмними продуктами разом із базовим обладнанням.
• Клієнтські вимоги: реалізується за допомогою коду, запрограмованого інженерами програмного забезпечення.
• Тестування коду: код перевіряється, щоб переконатися, що він не містить помилок та дотримується вимог клієнта.
• Документація внутрішнього дизайну: Для подальшого обслуговування та вдосконалення продукту.
• Технічне обслуговування: Це виконується для зміни архітектури системи відповідно до майбутніх потреб. Це може зажадати додавання коду або зміни існуючого коду.

Вищеописаний процес розробки впорядкований серією моделей. Команда розробників вибирає найкращу підходящу модель. Різні моделі:

• Модель водоспаду: розробники констатують вимоги, аналізують їх, визначають рішення та обрамляють архітектуру програмного забезпечення, представлення інтерфейсу та алгоритмічні деталі. Потім вони розробляють код, тестують його, розгортають програмне забезпечення та підтримують його. Хоча метод водоспаду легко зрозуміти і встановлює стабільність вимог, він може створити помилкове враження, що він не забезпечує великої участі клієнтів. Основна проблема цієї моделі полягає в тому, що вимога виправляти помилки повинна бути відома наперед та на ранній стадії. В іншому випадку весь процес може тривати в неправильному напрямку, що може негативно вплинути на собівартість продукції.
• V Фасонна модель: це варіація моделі водоспаду. Він підкреслює перевірку та перевірку продукту. Усі результати перевіряються, а прогрес відстежується віхами. Тестування проводиться паралельно фазі розробки.
• Модель прототипу: Прототип розробляється на етапі вимог та оцінюється кінцевими користувачами. На основі відгуків користувачів розробники змінюють прототип, щоб задовольнити потреби користувача. Хоча ця модель легко доопрацьовує вимоги, її використання у виробничому середовищі може спричинити проблеми з якістю, завдяки чому процес виправлення триватиме назавжди.
• Спіральна модель: Використовує як моделі водоспаду, так і прототипи. Він додає мови програмування 4-го покоління, швидку розробку додатків та аналіз ризиків до моделі водоспаду. Розроблені вимоги до системи та створено попередній дизайн системи. Початковий прототип розроблений та протестований. На основі оцінки результатів випробувань створюється другий прототип. Подальші прототипи побудовані для забезпечення задоволеності клієнтів. Система створена на основі остаточного прототипу. Підсумкова система оцінюється і тестується. Хоча ця модель значною мірою знижує ризик, вона може не відповідати бюджету і застосовуватись по-різному для кожної програми.
• Ітеративна та додаткова модель SDLC: Вказує та реалізує частину програмного забезпечення, яке потім переглядається та додаються та впроваджуються подальші вимоги в групах. Кожен випуск постачає операційний продукт, представляючи спочатку клієнтам важливі функції, знижуючи початкові витрати на доставку. Ризик зміни вимог значно знижується, і клієнтам дозволяється реагувати на кожну збірку. Незважаючи на свої сильні сторони, ця модель вимагає гарного планування та раннього визначення повноцінної та повністю функціональної системи. Для цього потрібні також чітко визначені модульні інтерфейси.
• Модель гнучкої розробки: використовується для критично важливих для часу застосувань в організаціях, що використовують дисципліновані методи. Це прискорює фази життєвого циклу і зменшує сферу застосування.
• Модель магічної коробки: це модель розробки веб-додатків. Це найшвидший спосіб закінчити проект з найменшими помилками, оскільки це дає можливість змінити код і структури бази даних.