Правильный подход для разработки веб-приложения (разрабатывают программное обеспечение, не графику),
Я нашел комментарий Ника Урбана очень полезным:
sudo /opt/cisco/anyconnect/bin/websecurity_uninstall.sh
8 ответов
Хотя я согласен с тем, что вам нужно иметь какое-то широкое согласие в отношении объема и стоимости создаваемой системы, я думаю, что это цепляние за соломинку, чтобы думать, что вы можете полностью определить систему до передачи в руки покупателя. Как вы обнаружили, покупатель очень часто не знает, чего он хочет, пока не увидит это. Один из способов решить эту проблему - использовать макеты, как вы привыкли. Я тоже использую их во время проектирования и планирования.
Однако чаще всего вам нужно передать реальный продукт в руки покупателя, чтобы получить неизбежную обратную связь о том, что работает, а что нет. Лучше сделать это раньше, чем позже, поскольку изменения, которые происходят на поздних стадиях разработки, намного сложнее и дороже, по крайней мере, в традиционных методах. Использование гибкого метода, который предоставляет работающее программное обеспечение на ранней стадии и часто, в сочетании с достаточным планированием и документацией, дает лучшую обратную связь с клиентами, чем повторение множества спецификаций для продукта, который клиент может найти, что он не хочет (или, по крайней мере, хочет, чтобы как они сказали).
Я бы посоветовал вам нужны некоторые документы, которые в общих чертах описывают масштаб проекта. Достаточно, чтобы вы могли прийти к соглашению о том, что является частью системы, а что нет. Если вы создаете приложение для управления запасами, им не следует ожидать, например, также системы управления отношениями с клиентами. Затем примените методы гибкой разработки, чтобы в легкой форме отслеживать желаемую функциональность и получать рабочий код как можно раньше, а впоследствии на регулярной основе.
Спецификация - самая важная часть (самая долгая) проекта. Он сообщает вам (и вашему клиенту), что вы строите и , за что они вам платят .
Нет ничего хорошего в том, чтобы закончить сборку и затем обнаружить, что у клиента на уме другая идея. Технические характеристики гарантируют, что вы все читаете одну и ту же книгу . Объединение в него некоторых идей графического интерфейса - тоже хорошая идея.
Суть в том, что и вы, и клиент должны знать, чего ожидать, до начала работы. Ваши экраны и макеты должны быть частью более широкой спецификации
Ваш подход кажется немного неправильным для большого приложения. Их ожидания кажутся мне правильными.
Я использую макеты экрана в Balsamiq . Он демонстрирует общий вид и удобство использования, не отвлекаясь от эстетики дизайна
Во-первых, вы неправильно поняли терминологию. В заголовке вопроса вы спрашиваете: «Правильный подход к разработке веб-приложения», но при этом обратите внимание: Ваш клиент попросил вас написать спецификации для приложения.
Спецификация не соответствует дизайну. Опасно пытаться уравнять их.
Как сказал другой респондент, спецификация состоит в том, чтобы и вы, и ваш клиент знали , что вы строите. Дизайн - это искусство того, как его построить.
Спецификации обычно не включают макеты. Вкратце, они включают утверждения, которые точно описывают, что программное обеспечение должно делать . Обратите внимание, что это сильно отличается от того, как это должно быть сделано . Что касается веб-приложений, я бы сказал, что макеты следует делать на этапе проектирования. Так что да, отвечая на ваш вопрос, вы неверны в своем подходе. Хотя то, что я сказал, технически правильно, как отмечает Тванфоссон, сложно полностью спроектировать систему до начала разработки. Я рекомендую вам прочитать его ответ и обсудить со своими клиентами более реалистичный подход.
У всех свой подход к программному обеспечению развитие. Ваш метод так же жизнеспособен, как и ваш клиент. Однако, поскольку ваш клиент платит вам, я предлагаю вам соответствовать их стандартам ИЛИ предложить свой метод и посмотреть, как они отреагируют.
Следующие статьи могут оказаться полезными в ваших сообщениях:
- Секрет айсберга, раскрытый
- Безболезненные функциональные спецификации - Часть 2: Что такое спецификация?
- Безболезненные функциональные характеристики - Часть 3: Но ... Как?
Помните, что вы все еще можете создать макет HTML для себя, если это поможет вам подумать об остальном. В значительной степени дизайн HTML будет тогда вашим решением.
Лично я поклонник FIT и Fitnesse для спецификаций. Они упрощают поддержание актуальности и включают некоторые тесты для проверки соответствия кода спецификациям.
Еще нужно помнить, что, как правило, заказчик не совсем знает, чего он хочет, поэтому даже с полная спецификация не считает это полностью исправленным.
Пользовательский интерфейс не является самой важной частью приложения, сосредоточение внимания на этой части на столь раннем этапе может привести к ложным предположениям и навязывать выбор на основе интерфейса, а не функциональности.
Я предлагаю сначала сосредоточиться на функциональности, чтобы понять, что приложение должно делать, а не как оно будет выглядеть на экране. Интерфейс будет меняться со временем, клиент захочет, чтобы эта кнопка находилась слева, а не справа, синего, а не желтого цвета, это текстовое поле больше и другого шрифта, это подробности позже, если вы предоставите интерфейс со спецификациями вы рискуете обсудить эти второстепенные детали вместо важных функций.
Взгляните на Применение UML и шаблонов , я думаю, это может быть полезно. Одна из книг из серии "Экстремальное программирование" тоже была хороша, я проверю позже, какую именно.
Вы можете взглянуть на ответы на следующий вопрос, хотя вопрос касается среднего размера, он все же может быть довольно сложным:
Спрашивали ли вы клиента, почему не приветствуются схемы или прототипы снимков экрана? У них могут быть свои причины для этого, например, попытка ограничить объем выполняемой работы до того, как начнется «настоящая» работа. По идее, это не так уж плохо, если предположить, что они уже делали спецификацию с другими раньше и привыкли к этому процессу. Если для них это в новинку, возможно, стоит обсудить, почему вы хотите иметь эти прототипы, например