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

Ответ 1

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

Ответ 2

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

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

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

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

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

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

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

Ответ 3

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

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

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

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

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

Ответ 4

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

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

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

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

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

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

Ответ 5

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

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

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

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