Цикл разработки программного обеспечения

Эта статья предлагается к удалению. Пояснение причин и соответствующее обсуждение вы можете найти на странице Википедия:К удалению/30 июля 2012. Пока процесс обсуждения не завершён, статью можно попытаться улучшить, однако следует воздерживаться от переименований или немотивированного удаления содержания, подробнее см. руководство к дальнейшему действию. Не снимайте пометку о выставлении на удаление до окончания обсуждения. Администраторам: ссылки сюда, история (последнее изменение), журналы, удалить.

Эта статья или раздел нуждается в переработке. Пожалуйста, улучшите статью в соответствии с правилами написания статей.

Эта статья нуждается в дополнительных источниках для улучшения проверяемости. Вы можете помочь улучшить эту статью, добавив ссылки на авторитетные источники. Не подтверждённая источниками информация может быть поставлена под сомнение и удалена.

Разработка программного обеспечения

Процесс разработки ПО
Шаги процесса
Анализ • Проектирование • Программирование • Документирование • Тестирование
Модели
Итеративная • Спиральная • Каскадная • V-Model • Dual Vee Model
Методологии
Agile (XP, Lean, Scrum, FDD и др.) • Cleanroom • OpenUP • RAD • RUP • MSF • DSDM • TDD
Сопутствующие дисциплины
Конфигурационное управление • Управление проектами • Управление требованиями

Цикл разработки программного обеспечения — структурированное деление, положенное в процессе разработки программного продукта. Существуют несколько моделей для этого процесса, каждая из которых описывает свой подход к элементам деления, присутствующим в процессе разработки программного обеспечения.

Предисловие

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

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

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

Действия в процессе написания, представленные в модели водопада. Есть и другие модели, по-другому представляющие себе этот процесс.

Анализ требований к продукту

Самая важная задача при создании программного продукта — это выработка требований, или анализ требований к продукту. Заказчик чаще всего представляет весьма размытую идею о том, каким должен быть конечный результат, и не имеет представления о том, как должна работать программа. Незаконченные, нелепые, а иногда противоречащие друг другу требования распознаются хорошими инженерами на этой стадии. Частая демонстрация живого кода может уменьшить риск того, что начальные требования были не верны. Один из методов нахождения проблем такого рода — это анализ элементов программного обеспечения.

Когда общие требования получены от клиента, их необходимо уточнить и отобразить в документе. Реализованная функциональность может отличаться от определённой, в результате высокой стоимости разработки и/или непонятных требованиях к продукту. Если разработка проводится вне фирмы заказчика, то данный документ может использоваться для разрешения споров связанных с функциональностью продукта.

Анализ области работы часто является первой ступенью лестницы проектирования нового фрагмента программного обеспечения, вне зависимости от того, является ли он добавлением к уже существующему приложению или новым приложением, подсистемой или совершенно новой системой. Принимая, что разработчики (так же как и аналитик) не являются в начале достаточно образованными в области знаний нового программного обеспечения, первая задача — это собственно исследование этой самой области знаний. Чем лучше разработчики знают область, в которой работают, тем меньше потом возникает работы. Также её проводят для того, чтобы позже не появлялось путаницы в терминологии и понимании того, что делает эта программа. Если аналитик использует неверную терминологию, то опять же возможны недопонимания, в результате того, что программа будет делать не то, что нужно. Эта работа исключает случаи вроде «Я знаю, что вы верите в то, что поняли, что я говорю, но я не уверен, что вы понимаете, что то, что вы слышали — это не то, что я имею в виду.»

Спецификация

Спецификация — это набор требований и параметров программного продукта, возможно, в виде формального документа. Хороший способ определить, хороша ли спецификация — это попросить третью сторону провести анализ, чтобы убедиться что требования и способы их решений логически верны.

Архитектура

Архитектура системы приложения создаётся для того, чтобы быть уверенным, что программное обеспечение будет выполнять требования к нему, оставляя возможность для того, чтобы добавлять решения для новых требований. Также на стадии построения архитектуры решаются проблемы интерфейсов между программным обеспечением и операционной системой или оборудованием.

Проектирование, реализация и тестирование

Проектирование — процесс создания общей архитектуры и алгоритмов согласно спецификациям. Реализация (имплементация) — это та часть процесса, во время которой программисты собственно создают программный код продукта. Тестирование — всеобъемлющая и важная часть процесса разработки программного обеспечения. Эта часть процесса заключается в том, чтобы выявить и решить различные ошибки. Документирование проводится для того, чтобы в будущем было проще поддерживать и улучшать программный продукт. Это также может в себя включать описание внешних или внутренних программных интерфейсов.

Распространение и поддержка

Распространение начинается после того, как код достаточно оттестирован, и признан готовым к релизу.

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

Поддержка и улучшение продукта вместе с исправлением найденных ошибок может занимать больше времени, чем собственно процесс разработки этого продукта. Может быть полезным откорректировать код, который не подходит по дизайну — это может упростить нахождение ошибок и их исправления до того, как их заметят пользователи.

Модели (парадигмы)

Моделью водопада называется методология, разделяющая процесс разработки на следующие этапы (ступени):

1. Спецификация требований
2. Проектирование
3. Кодирование
4. Интеграция
5. Тестирование и отладка (валидация и верификация)
6. Установка
7. Поддержка

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

Проблема этой системы заключается в том, что процесс не предлагает возможностей для исправления ошибок на ранних стадиях (к примеру, в требованиях).

Данный подход используется в проектах с большим риском в основном в больших контрактах для системы обороны.

Итеративная (инкрементальная, эволюционная)^[1] предполагает разработку маленького ядра, на которое накручивается остальная функциональность. Итерационные процессы часто используются коммерческими разработчиками, поскольку они позволяют просто менять программный код в зависимости от изменений требований заказчика до того, как их изменение может привести к катастрофе.

Методологии

Основная статья: Методология программирования

Гибкая методология разработки

Гибкая методология разработки создана организациями, занимающимися итерационной разработкой. Для этого используется более гибкий, сфокусированный на людях подход, чем использующийся в традиционных подходах. Гибкие процессы используют обратную связь вместо планирования как главный контролирующий механизм. Обратная связь ведётся посредством регулярных тестов, а также частых релизах разрабатываемого продукта. Интересно, что исследования показывают потенциал для хорошего улучшения производительности относительно стандартного «водопадного» метода. К примеру исследование, опубликованное в августе 2006 года, и базированное на опросах более чем 700 компаний, гласит об огромной прибыли при использовании этой модели.^[2] Исследование было повторено в августе 2007 года с базой в 1,700 компаний.^[3]

XP: Экстремальное программирование

Экстремальное программирование (XP) основано на итеративной модели. В XP процесс делится на очень маленькие ступеньки, по сравнению с планируемыми процессами. Это приводит к тому, что первые шаги могут занимать дни или недели вместо месяцев или даже лет для каждой ступени в модели «водопад». Сначала пишутся автоматические тесты, чтобы описать цели разработки. Потом идёт кодирование, которое заканчивается в тот момент, когда все тесты проходят, и программисты не могут придумать новых тестов. Дизайн делается теми же людьми, которые пишут код. (только последняя ступень — соединение дизайна и кода является общим для всех гибких процессов). Незаконченная, но функционирующая система показывается узкому кругу пользователей (чаще всего это сами разработчики). В этот момент начинают писать тесты для следующей наиболее важной части системы.

Test Driven Development — разработка через тестирование — техника программирования, при которой модульные тесты для программы или ее фрагмента пишутся до самой программы и, по существу, управляют ее разработкой. Является одной из основных практик экстремального программирования.

Формальные методы

Формальные методы — математические представления проблемы создания программного обеспечения, а также оборудования на уровнях требований, спецификации, а также дизайна. Как пример можно привести B-Method, Сети Петри, RAISE . Доступны разные формальные нотации спецификаций, такие как Z notation. Чаще всего для создания и валидации приложений и их дизайна используется теория конечных автоматов.

Формальные методы используются при разработке авиационного ПО, а также там, где безопасность ПО наиболее критична. Существуют так же стандарты на критерии безопасности.

См. также

Другие методологии: Разработка управляемая моделями User experience Top-down and bottom-up design Chaos model Evolutionary prototyping Prototyping ICONIX Process (UML-based object modeling with use cases) Unified Process V-model Extreme Programming Software Development Rhythms Specification and Description Language Incremental funding methodology Verification and Validation (software) Service-Oriented Modeling Framework

Related subjects: Rapid application development Software design Software development Software Estimation Abstract Model Development stage IPO+S Model List of software engineering topics Performance engineering Process Programming paradigm Programming productivity Project Systems Development Life Cycle (SDLC) Software documentation Systems design List of software development philosophies Test effort Best Coding Practices Service-Oriented Modeling Framework

Примечания

1. ↑ Iterative and Incremental Development: A Brief History
2. ↑ Agile Journal — Agile Survey Results: Solid Experience And Real Results
3. ↑ Agile Journal — Agile Survey Results: Widespread Adoption, Emphasis on Productivity and Quality

Ссылки

• No Silver Bullet: Essence and Accidents of Software Engineering", 1986
• Gerhard Fischer, «The Software Technology of the 21st Century: From Software Reuse to Collaborative Software Design», 2001
• Lydia Ash: The Web Testing Companion: The Insider’s Guide to Efficient and Effective Tests, Wiley, May 2, 2003. ISBN 0-471-43021-8
• SaaSSDLC.com — Software as a Service Systems Development Life Cycle Project
• Software development life cycle (SDLC) [visual image], software development life cycle
• Iterative Development and The Leaning Tower of Pisa — From The Trench
• Processes and Templates