Цикл разработки
В зависимости от потребностей проекта выбирается соответствующий подход к циклу разработки. В процессе создания программного обеспечения используются разные виды жизненных циклов, но типичный цикл разработки программного обеспечения выглядит следующим образом.
Подготовка — сбор и обработка требований. Предварительное планирование этапов работ, сроков, ресурсов и стоимости.
Проектирование — получение технических заданий, разработка спецификаций. Партнер получает документальное изложение своих требований и планы проведения работ.
Создание. Дизайн — получение графических макетов, визуальных форм, разработка интерфейсов. Создание индивидуального стиля. Кодирование — получение исходного кода. Тестирование — проверка программы на соответствие всем предъявляемым к ней требованиям. Документирование — получение возможности передачи накопленных знаний другим разработчикам.
Поддержка. Внедрение — установка программного обеспечения, обучение пользователей. Сопровождение — исправление выявленных ошибок, поддержка пользователей.
Зачастую в крупных проектах на этапе проектирования почти невозможно озвучить все требования к программному обеспечению. Существенные изменения вносятся заказчиком уже в процессе разработки, объем работ меняется. Мы осознаем, что это обычная ситуация, когда речь идет о сложных системах.
Проблема решается посредством применения итеративной разработки при повременной оплате работ. Адекватная организация работы позволяет заказчику без негативных последствий изменить направление разработки, внести дополнительные задания, требовать детальной проработки узких мест.
Методологии разработки по (модели процесса)
Процесс разработки программного обеспечения (англ. software development process, software process) — структура, согласно которой построена разработка программного обеспечения (ПО). Существует несколько моделей такого процесса (методологий разработки ПО), каждая из которых описывает свой подход, в виде задач и/или деятельности, которые имеют место в ходе процесса.
Выделяют следующие основные модели процесса или методологии разработки ПО:
Каскадная разработка или модель водопада (англ. waterfall model) — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки. В качестве источника названия «водопад» часто указывают статью, опубликованную У. У. Ройсом (W. W. Royce) в 1970 году; забавно, что сам Ройс использовал итеративную модель разработки и даже не использовал термин «водопад».
Итеративная разработка (англ. iteration — повторение) — выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы. Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл: Планирование — Реализация — Проверка — Оценка (англ. plan-do-check-act cycle). В ходе разработки всегда выявляются дополнительные требования или изменяются выявленные ранее. Также появляются новые ограничения, связанные с принятыми техническими решениями. В наиболее полной мере их удается учесть именно в итерационной разработке, поскольку именно при таком подходе руководство проекта в полной мере готово к изменениям. Итеративный подход сейчас является наиболее распространенным из-за своих очевидных преимуществ и различные его вариации используеются в компании ДПГруп. Итеративные методы разработки программного обеспечения, которые применяет ДПГруп:
Rational Unified Process (RUP) — методология разработки программного обеспечения, созданная компанией Rational Software.
В основе RUP лежат следующие основные принципы:
Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков.
Концентрация на выполнении требований заказчиков к исполняемой программе (анализ и построение модели прецедентов).
Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки.
Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.
Постоянное обеспечение качества на всех этапах разработки проекта (продукта).
Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.
Гибкая методология разработки (англ. Agile software development). Большинство гибких методологий нацелены на минимизацию рисков, путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся одну-две недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре, и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, кодирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации, команда выполняет переоценку приоритетов разработки.
Agile-методы делают упор на непосредственное общение лицом к лицу. Большинство agile-команд расположены в одном офисе иногда называемом bullpen. Как минимум она включает и «заказчиков» (заказчики которые определяют продукт, также это могут быть менеджеры продукта, бизнес-аналитики или клиенты). Офис может также включать тестировщиков, дизайнеров интерфейса, технических писателей и менеджеров. Одной из наиболее известных и передовых гибких методик является методололгия SCRUM, которая и применяется нашей компанией.
Метод анализа существующих решений
1 Метод используется на этапе анализа проектной ситуации. Исследуются существующие аналоги с целью выявления недостатков - визуальных, функциональных и конструкционных.
2 Цель - выявить противоречия (проблемы) в существующих изделиях и определить задачи, которые вы планируете решить в своем проекте.