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

Содержание

• Определение - Что означает модель жизненного цикла разработки программного обеспечения (SDLC)?
• Введение в Microsoft Azure и Microsoft Cloud | Из этого руководства вы узнаете, что такое облачные вычисления и как Microsoft Azure может помочь вам перенести и запустить свой бизнес из облака.
• Techopedia объясняет модель жизненного цикла разработки программного обеспечения (SDLC)

Определение - Что означает модель жизненного цикла разработки программного обеспечения (SDLC)?

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

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

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

Введение в Microsoft Azure и Microsoft Cloud | Из этого руководства вы узнаете, что такое облачные вычисления и как Microsoft Azure может помочь вам перенести и запустить свой бизнес из облака.

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

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

• Извлечение требования: клиент имеет смутное представление о том, что требуется. После тщательного анализа требований и шагов планирования для достижения цели абстрактная идея клиента реализуется группой разработчиков программного обеспечения.
• Описание программного обеспечения: Описывает, что программное обеспечение является следующим шагом в процессе.
• Абстрактное представление системы: создается для подтверждения того, что оно соответствует требованиям продукта и взаимодействует с другими программными продуктами вместе с базовым оборудованием.
• Требования к клиенту: реализовано с помощью кода, запрограммированного программистами.
• Тестирование кода: код тестируется, чтобы убедиться, что он не содержит ошибок и соответствует требованиям клиента.
• Документация внутреннего дизайна: для будущего обслуживания и улучшения продукта.
• Обслуживание: выполняется для изменения архитектуры системы в соответствии с будущими потребностями. Это может потребовать добавления кода или изменения существующего кода.

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

• Модель водопада: разработчики формулируют требования, анализируют их, определяют решение и создают архитектуру программного обеспечения, представление интерфейса и алгоритмические детали. Затем они разрабатывают код, тестируют код, разворачивают программное обеспечение и поддерживают его. Хотя метод водопада прост для понимания и задает стабильность требований, он может создать ложное впечатление о недостаточном участии клиентов. Основная проблема этой модели заключается в том, что требование об исправлении ошибок должно быть известно заранее и на ранней стадии. В противном случае весь процесс может продолжиться в неправильном направлении, что может негативно повлиять на себестоимость продукции.
• V-образная модель: вариант модели водопада. Это подчеркивает проверку и валидацию продукта. Все результаты являются тестируемыми, а прогресс отслеживается вехами. Тестирование осуществляется параллельно с этапом разработки.
• Модель прототипа: прототип разрабатывается в фазе требований и оценивается конечными пользователями. Основываясь на отзывах пользователей, разработчики изменяют прототип, чтобы удовлетворить требования пользователей. Хотя эта модель легко завершает требования, ее использование в производственной среде может привести к проблемам с качеством, тем самым заставляя процесс исправления продолжаться вечно.
• Спиральная модель: использует модели как водопада, так и прототипа. Он добавляет языки программирования 4-го поколения, быстрое создание прототипов приложений и анализ рисков в модель водопада. Разработаны системные требования и создан предварительный проект системы. Первоначальный прототип разработан и испытан. На основе оценки результатов испытаний создается второй прототип. Последующие прототипы создаются для обеспечения удовлетворенности клиентов. Система создана на основе окончательного прототипа. Окончательная система оценивается и тестируется. Хотя эта модель в значительной степени снижает риск, она может не соответствовать бюджету и применяется по-разному для каждого приложения.
• Итеративная и инкрементная модель SDLC: Определяет и реализует часть программного обеспечения, которая затем анализируется, а дополнительные требования добавляются и реализуются в группах. Каждый выпуск предоставляет операционный продукт, который сначала предоставляет клиентам важные функции, снижая первоначальные затраты на доставку. Риск изменения требований значительно снижается, и клиентам разрешается реагировать на каждую сборку. Несмотря на свои сильные стороны, эта модель требует хорошего планирования и раннего определения полной и полностью функциональной системы. Это также требует четко определенных интерфейсных модулей.
• Модель гибкой разработки: используется для срочных приложений в организациях, использующих дисциплинированные методы. Это ускоряет фазы жизненного цикла и уменьшает объем.
• Модель Magic Box: модель разработки веб-приложений. Это самый быстрый способ завершить проект с наименьшим количеством ошибок, поскольку он дает возможность изменить код и структуры базы данных.