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

Question

Мне интересно узнать, как спроектировать / спланировать разработку веб-приложений в сценарии с несколькими группами разработчиков.

Принимая на себя роль «Руководитель проекта / Ведущий»:

1. Какие «документы» нужны для успешной разработки веб-приложения?
2. Какие UML-диаграммы нужны и в какой степени?
3. На этапе проектирования / планирования каждый (в соответствии с вариантом использования) должен быть представлен в виде диаграммы?
4. Насколько подробными (глубина и ширина) должны быть диаграммы классов?

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

---

Продолжение (Добавлено 18.11.09): Что кодеры / разработчики используют в качестве руководства при кодировании, т. Е. Создание классов, и их соответствующие методы и свойства?

Если не существует полного (но изменчивого) списка классов с их методами и свойствами, не вызывает ли эта неоднозначность сильную зависимость от знаний / опыта каждого кодера, что приводит к отклонениям в качестве кода / удобстве использования / поддерживаемости?

Answer 1

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

Answer 2

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

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

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

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

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

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

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

Answer 3

Делайте это как можно проще.

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

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

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

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

Answer 4

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

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

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

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

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

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

Answer 5

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

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

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

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