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

1. Во всех случаях у вас должна быть исчерпывающая и актуальная запись точных требований. Сюда входят как функциональные, так и нефункциональные требования. Это может быть документ Word, электронная таблица или специализированная система требований. Вам просто нужно что-то, что позволит вам отслеживать все требования и то, как они менялись с течением времени. Вот хороший источник информации и обсуждения документации по требованиям Agile.
2. По моему опыту, диаграммы вариантов использования оказались важными, а диаграммы компонентов и развертывания также полезны. Диаграммы классов и последовательностей также могут быть полезны, но в большинстве случаев я думаю, что их следует использовать скорее как основные изменяемые рекомендации, чем неизменные требования к разработке. Классы и методы обычно могут быть изменены (особенно если вы используете TDD), и если вам действительно нужна диаграмма, лучше обновить ее после разработки кода, а не подгонять свой код под диаграммы.
3. Я не думаю, что каждый класс нужно изображать на диаграмме. Я думаю, что диаграммы классов моделей могут быть полезны для отслеживания того, где находятся данные, а иногда также полезны некоторые диаграммы классов контроллеров и представлений. Но в большей части моего опыта требования и тестовые случаи были основным источником направления в том, как проектируются классы, и они рефакторингуются по мере роста и изменения системы.
4. В модельных классах я не думаю, что обычно требуется что-то большее, чем атрибуты. Если вы моделируете классы контроллеров, обычно целесообразно включать как основные атрибуты, так и методы.

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

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

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

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

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

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

Наконец, полезно прочитать серию статей Джоэла о функциональных спецификациях.

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

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

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

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

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

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

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

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

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

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

Мы используем Visual Studio 2008, Subversion, HP Quality Center, ASP.Net 3.5, Sitecore 6.0 и MS-SQL Server 2005.

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

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

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

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