Процесс разработки заказного программного обеспечения
Давайте начнем обзор процесса разработки с самого распространенного случая: разработки программного обеспечения на заказ. Услуга: wmg international.
Работа над проектом начинается на подготовительном этапе. Цель этого этапа — создать концепцию будущей системы на основе предложения заказчика и оценить возможность и практичность проекта на основе этой концепции. Если заказчик решает нанять подрядчика на конкурсной основе, то предварительный этап фактически является подготовительным этапом к тендеру потенциальных подрядчиков и включает в себя подготовку необходимой документации.
Нет необходимости тратить время и ресурсы на проект, концепция которого не разработана и считается невыполнимой. Такие проекты должны быть завершены. В некоторых случаях потребуется итерационная работа с клиентом по корректировке концепции проекта до тех пор, пока требования клиента и затраты подрядчика не будут сбалансированы или пока не будет принято решение о прекращении работ.
Проект с концепцией, готовой к реализации, вступает в фазу разработки требований. На этом этапе подрядчик должен иметь список всех явных и неявных требований клиента. Часто клиент не определился со своими потребностями или выясняется, что его потребности противоречат друг другу, возможностям клиента и возможностям подрядчика. Цель этого этапа — выявить все потенциальные потребности, разрешить противоречивые требования, сформулировать согласованное техническое решение и проанализировать осуществимость подготовленного решения.
Уточнение требований может привести к пересмотру концепции проекта. Если после уточнения всех требований не удается найти приемлемое техническое решение, от проекта, возможно, придется отказаться или отложить его на некоторое время, чтобы дождаться более приемлемой ситуации.
Если техническое решение найдено, подрядчик приступает к разработке архитектуры будущей системы. Цель этого этапа — определить логическую и физическую архитектуру верхнего уровня, которая полностью охватывает все требования заказчика. В ходе разработки архитектуры пересматриваются и уточняются концепции, требования и предварительные технические решения, что позволяет предотвратить наиболее опасные риски.
После завершения разработки архитектуры следует пересмотреть ключевые параметры проекта, чтобы определить, сможет ли подрядчик выполнить проект. На этапе архитектурного проектирования полезно отказаться от избыточных или слишком громоздких функций. Оптимизируя архитектурный проект, часто можно остаться в рамках приемлемых проектных параметров. Также может потребоваться более радикальное сокращение функциональности разрабатываемой системы. Однако остановку проекта на этом этапе следует считать победой, если на то есть веская причина. Продолжение работ в таких случаях приведет лишь к еще большим потерям.
После создания сбалансированной и удовлетворительной архитектуры системы подрядчик может переходить к внедрению и сдаче системы. Внедрение может быть выполнено в один или несколько этапов. Для небольших проектов вполне возможно обеспечить функциональность всей системы за один этап. Однако чем крупнее проект, тем больше зависимостей между подсистемами создаваемой системы. В таких ситуациях реализация должна быть разделена на несколько этапов, чтобы в конце каждого этапа команда разработчиков имела готовый продукт. Наиболее важные и базовые функциональные возможности должны разрабатываться на ранних этапах, а дополнения, работающие поверх этих базовых компонентов, должны быть реализованы позже. В этом случае наиболее опасные для системы ошибки исправляются на ранней стадии, и риск того, что прикладная функциональность системы станет нестабильной основой, значительно снижается.
После поставки полностью готовой системы проекты заказного программного обеспечения обычно переходят в фазу ввода в эксплуатацию. Цель этой фазы — проверить качество разработанной системы в реальных условиях эксплуатации. Как правило, на этом этапе подрядчик совместно с заказчиком измеряет количественные показатели для определения качества разработанной системы. Сначала проверяются функциональные характеристики качества, затем нефункциональные. При наличии несоответствий исполнитель корректирует код системы.
