Насколько распространено прототипирование как первый этап разработки?

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

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

Где во всем этом формализме суть: как выглядит, работает программа и какой опыт она дает? Разве не имеет больше смысла проектировать из этого? Не лучше ли выяснить, как программа должна работать через прототип, и стремиться реализовать ее по-настоящему?

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

Если мы создаем приложение с графическим интерфейсом, мы почти ВСЕГДА создаем прототип или POC (подтверждение концепции). Мы установим визуальный словарь приложения. Мы обычно вовлекаем наших клиентов частично через POC и следим, чтобы они понимали, какова цель и на чем им следует сосредоточиться. Я никогда не сожалел, что произвел прототип. Просто убедитесь, что вы не пытаетесь превратить код прототипа в производственный код, запустите производственный код с нуля на основе того, что вы узнали из прототипа.

Сказав все это, мы почти никогда не создаем прототипы серверных приложений (сервисы, промежуточное ПО и т. Д.). На самом деле я не вижу отдачи от инвестиций (если вы не используете какую-то новую технологию и вам не нужно доказывать разные концепции).

В деловом мире это очень важно

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

Дело в том, что пользовательские «потоковые» диаграммы и прототипы lo-fi действительно имеют смысл.

Как работает «программа», вероятно, самая легкая часть. В приложениях LOB (Line Of Business) большинство из них просто CRUD. Задача заключается в бизнес - логике и правилах . Именно здесь диаграммы пользователей и потоки бизнес-процессов становятся чрезвычайно важными для понимания и эффективного планирования.

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

По моему опыту, прототипирование несколько необычно. Меня, конечно, учили в связи со спецификацией, требованиями, архитектурой и т. Д., И это может быть очень полезно.

Что касается того, «каким должно быть программное обеспечение», то это требования. Вы, кажется, упускаете всю суть.

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

Мое личное наблюдение состоит в том, что прототипам дается много слов, но слишком часто прототип, когда он показывает признаки жизни, просто переименовывается в «Beta» или, что еще хуже, v1.0.

Есть два вида прототипирования - три, на самом деле:

1. мы создаем прототипы, чтобы усовершенствовать дизайн и снизить риски, прежде чем начинать «реальное» кодирование (Инжиниринг)

2. мы строим проект как серию улучшенных прототипов (Agile)

3. мы создаем прототип и отправляем его, как только он заработает (Ковбой)

То, что вы ищете, называется спецификацией - вы можете прочитать описание этого здесь в одной из статей Джоэла.

http://www.joelonsoftware.com/articles/fog0000000035.html

Прототип также можно считать «итерацией 0» того, что вам нужно сделать. Он выполняет несколько вещей:

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

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