Как проектировать / планировать разработку веб-приложений?

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

лично я не верю в жесткие форматы спецификаций или процессов. Я подгоняю для того чтобы одеть проект и клиент с целью четкого общения.

предполагая, что требования уже задокументированы, два типа документов, которые я всегда стремлюсь создать как минимум для веб-приложений на основе рабочего процесса:

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

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

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

и наконец, функциональные характеристики полезное чтение.

держите его как можно проще.

документ, определяющий основные требования к функциям является первым шагом.

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

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

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

1. требования-это один набор документов, который может включать графику, документы Word, сообщения электронной почты и другие способы записи. Список того, что находится в среде разработки(IDE, управление версиями, отслеживание ошибок), стиль кодирования и рекомендации-это еще один набор документов, которые могут быть полезны для успешной команды разработчиков приложений. Существует план проекта, который представляет собой большую диаграмму Ганта и заметки о выпуске, которые являются еще некоторыми документами, которые мы создаем.
2. I не видел много диаграмм UML, кроме того, что банда четырех имеет на своем сайте для объяснения некоторых шаблонов дизайна.
3. у нас есть отставание пунктов для завершения и оценки того, насколько сложна каждая история. Это может отличаться от подхода, который вы используете. С нашим гибким подходом может быть не так много дизайна / плана, как ваша ситуация.
4. у нас редко есть диаграммы классов, хотя в Visual Studio есть браузер объектов, который удобен для просмотра того, что уже есть построенный.

где я работаю, мы, как правило, работаем в парах для создания объектов домена и их членов, методов и свойств. Классы создаются по мере необходимости для историй или если мы очищаем или рефакторинг набора классов.

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

фон в среде, где я на всякий случай, если кто-то хочет знать:

где я работаю у нас есть 5 разработчиков, ведущий QA, бизнес-аналитик, руководитель команды, архитектор и менеджер проекта в качестве основных людей в проекте на данный момент. Мы используем Scrum, парное программирование и некоторые идеи TDD в нашей работе.

мы используем Visual Studio 2008, Subversion, центр качества HP, ASP.Net 3.5, Sitecore 6.0 и MS-SQL Server 2005.

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

при разработке взаимодействия между различными серверами, которые будут опрашивать / толкать сообщения в разное время вам понадобится Диаграммы Последовательности точно.

избежать overdesigning его в Диаграммы Классов ненужные классы, как правило, грибы, вырезать Используйте больше методов, следите за тем, какая среда будет работать каждый класс (некоторые будут работать на стороне сервера, некоторые на стороне клиента - javascript - некоторые будут запланированными заданиями и запускаться на реальном сервере, некоторые будут CGI (или модуль) инкапсулированы веб-сервером и запускаться по требованию, некоторые будут взаимодействовать с базой данных.

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