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

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

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

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

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

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

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

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

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

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

Архитектура

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

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

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

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

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

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

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