Что нужно разработчику на внешнем интерфейсе для обеспечения успешного проекта?

Question

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

Итак, какую информацию изначально нужно (или нужно) разработчикам от владельца, чтобы избежать необходимости делатьпредположения о деловых (или других) требованиях?Нужно ли создавать диаграммы перехода состояний или писать сценарии использования?

По сути, как мне взять концепцию в моей голове и упаковать ее таким образом, чтобы разработчик мог делать то, что он делает лучше всего?(при условии, что это создает хорошее программное обеспечение. Хаха)

Любой совет приветствуется.

Шон

Answer 1

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

Но, чем лучше вы видите, чего вы хотите, тем более плавным он будет.будет.

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

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

Итак, вы можете написать:

Потребности пользователячтобы иметь возможность войти в систему с помощью OpenID.

Это сообщит разработчику одну функцию, которую вы хотите, и кто вы ожидаете, чтобы сделать это действие.

Но, не используйте технологии,вы можете подумать, что сервис SOAP - ваш лучший выбор, но, поговорив об этом, вы обнаружите, что есть лучшее решение.

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

Answer 2

Я считаю, что слова не помогают понять, как система должна работать. Каркасные схемы, чертежи досок / переходные схемы и прототипы с низкой точностью - это отличные способы донести конкретную идею. Одним из примеров прототипа с низкой точностью воспроизведения является прототип бумаги, на который можно нажимать, который позволяет пользователю нажимать «кнопки» на бумаге для перехода от одного чертежа к другому. Это стоит очень мало времени (дешевле), но имеет большое значение для обмена идеями между двумя сторонами.

Держитесь подальше от формальной документации, диаграмм UML или диаграмм классов (технической документации), которые не говорят с вами. Это то, к чему стремятся крупные, склонные к риску компании, чтобы стать более «зрелыми». Это также побочные продукты идеи, которая хэшируется, и звучит так, будто вы находитесь в стадии хэширования.

Answer 3

Мне нравятся макеты пользовательского интерфейса, основанные на реальных потоках программы / сайта, например, регистрация клиента или размещение заказа.Диаграммы / рисунки графических интерфейсов с примерами структурированных, непротиворечивых данных однозначны.

Я согласен, что UML и варианты использования действительно полезны, только если все говорят на UML, а проекты достаточно сложны (мало)

Возможно, вы захотите ознакомиться с методами Agile / Scrum.Они становятся своего рода стандартом и при правильном управлении могут сэкономить недели на разработке.

Answer 4

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

Answer 5

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

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

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

Answer 6

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