Вы сначала разрабатываете / набрасываете эскиз / отрисовываете решение для разработки, а затем разрабатываете его?Если да, то каким образом?[закрыто]

Question

Я много работаю с лицами, принимающими решения, которые хотят лучше использовать технологии в своем бизнесе.Я обнаружил, что картинка стоит тысячи слов а создание прототипа системы в виде какой-либо диаграммы всегда вносит большой вклад в обсуждение.Я использовал Visio, UML (в некоторой степени), Mind Maps, блок-схемы и смоделировал WinForms, чтобы запустить vision для этих спонсоров, чтобы убедиться, что все находятся на одной странице.Мне всегда казалось, что я ищу общий процесс, который можно было бы использовать для увязки бизнес-видения с процессом разработки, чтобы все мы пришли к одному результату ".Что-то функциональное, что решает проблему".

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

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

Что вы используете, чтобы запечатлеть видение системы / приложения, которое затем представляете спонсорам проекта?(все это до того, как вы напишете одну строку кода)...

Answer 1

Бумага или белая доска!

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

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

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

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

Стоит отметить, что TDD и выполнение проектов "spike"[1] также могут помочь при проектировании системы.

[1] Из книги Extreme Programming Adventures на C #, страница 8:

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

Answer 2

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

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

Что касается хранилища, белая доска может отлично подойти для мозгового штурма и когда идея все еще дорабатывается, но я бы сказал, что электронная и wiki - лучше, когда идея приобретает достаточно окончательную форму (OmniGraffle - король составления диаграмм, если вам посчастливилось использовать Mac на работе:) .Наличие области, в которой вы размещаете все эти диаграммы, может быть чрезвычайно полезным для новичка, чтобы быстро получить представление об общей части системы без необходимости копаться в коде.Кроме того, поскольку диаграммы действий представляют более крупные логические блоки, не возникает необходимости постоянно поддерживать их в актуальном состоянии.Когда вы вносите крупные изменения в систему, тогда да, но, надеюсь, скорее всего, для планирования изменений вы все равно будете использовать существующую схему.

Answer 3

Почитайте о книге Крухтена 4+1 Просмотров.

Вот как вы можете поступить.

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

2. Расставьте приоритеты в вариантах использования, чтобы сосредоточиться на высокоэффективных вариантах использования.

3. Пишите рассказы.Если вы хотите, вы можете нарисовать диаграммы активности.

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

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

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

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

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

Answer 4

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

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

После этого шага (который иногда проходит процедуру утверждения) Я создаю эскизы интерфейса (ручка / карандаш и графическая бумага) и начинаю компоновку баз данных.Этот и следующий шаг, как правило, являются наиболее трудоемким процессом.

Следующий шаг - взять эскизы и превратить их в очищенные каркасы.Для этого шага я использую OmniGraffle - он на несколько световых лет опережает Visio.

После этого вы можете захотеть создать типичные диаграммы UML или другие макеты объектов / организацию функциональности, но бизнесмены не будут так сильно заботиться о такого рода деталях :)

Answer 5

Когда я разрабатываю дизайн, я забочусь о том, чтобы четко и легко донести идеи до аудитории.Эта аудитория состоит (как правило) из разных людей с разным опытом работы.Чего я не хочу делать, так это переходить в "режим обучения" для конкретной модели проектирования.Если мне приходится тратить много времени на то, чтобы объяснить моему клиенту, что означает стрелка со сплошной головкой и чем она отличается от полой или что означает квадрат по сравнению с кругом, я не добиваюсь прогресса - по крайней мере, не того прогресса, которого я хочу.

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

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

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

В двух словах, я создаю простые чертежи (в определенном формате), которые могут донести дизайн до заинтересованных сторон и заинтересованных держателей.Я удостоверяюсь, что знаю, что я хочу, чтобы это делало, и, что более важно, - что ИМ НУЖНО, чтобы это делало, и разговариваю с этим.Обычно это не попадает в заросли, потому что люди там теряются, и я не считаю, что стоит тратить время на то, чтобы расписать все до энной степени.В конечном счете, если мы с заказчиком (и всеми другими заинтересованными сторонами) находимся на одной волне после обсуждения дизайна, я счастлив.

Answer 6

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

Обычно я не люблю прототипы, потому что слишком часто прототип становится конечным продуктом.Мне не повезло работать над проектом, который, по сути, расширял коммерческое предложение, оказавшееся "доказательством концепции", которое было упаковано и продано.Проект был отменен после того, как в основном приложении было зарегистрировано более 1000 дефектов (не считая каких-либо улучшений или настроек, над которыми мы в настоящее время работали).

Я пробовал использовать UML и обнаружил, что, если человек, смотрящий на диаграммы, не понимает UML, они мало чем помогут.Экранные макеты, как правило, неплохая идея, но они показывают только ту сторону приложения, которая непосредственно воздействует на пользователя, так что вы не получите много пользы от всего, что не является презентацией.Как ни странно, такие инструменты, как Workflow designer в Visual Studio, создают довольно четкие диаграммы, которые легко понять неспециалистам, поэтому это хороший инструмент для создания основного рабочего процесса приложения, если ваше приложение достаточно сложное, чтобы извлечь из него пользу.

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

Answer 7

Я предлагаю прочитать статьи Джоэла о "Безболезненных функциональных спецификациях".Часть 1 озаглавлена "Зачем беспокоиться?".

Мы используем Макетные экраны за работой ("Быстрые и простые прототипы экрана").Экраны легко переделать, и на скетчах ясно видно, что это всего лишь дизайн.

Затем макеты включаются в документ Word, содержащий спецификацию.

Answer 8

От Концептуальный Блокбастер:Руководство К Лучшим идеям автор : Джеймс Л.Адамс:

Интеллектуальные блоки приводят к неэффективному выбору ментальной тактики или нехватке интеллектуальных боеприпасов....1.Решение задачи с использованием неправильного языка (вербального, математического, визуального) - как при попытке решить задачу математически, когда ее легче решить визуально

(стр.71, 3-е издание)

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

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

Кстати, настоятельно рекомендуется прочитать "Концептуальный блокбастинг".

Answer 9

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

С другой стороны, если вы работаете над гибким проектом, в котором можно быстро вносить изменения в код (и быстро откатывать ошибки), возможно, вам удастся создать эволюционный прототип со всеми работами.Архитектура вашего приложения должна быть достаточно гибкой, чтобы поддерживать быстрые изменения (напримершаблон проектирования голых объектов или MVC в стиле Rails).Это помогает создать культуру разработки, которая поощряет эксперименты и признает, что BDUF не является предиктором успешной работы программного обеспечения.

Answer 10

просмотры 4 + 1 хороши только для технических специалистов.И только в том случае, если они достаточно заинтересованы.Помните те последние дюжины раз, когда вам с трудом удавалось обсудить с заказчиком схемы вариантов использования?

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

Любопытно, что есть два подхода, которые сработали для меня:

1. Предоставить пользователям полное руководство пользователя (еще до начала разработки) ИЛИ
2. Используйте макеты, которые совсем не похожи на готовое приложение:Сначала обсудите основные экраны вашего приложения.Когда будете удовлетворены, продолжайте обсуждать макеты, но по одному сценарию за раз.

Для варианта (1) вы можете использовать все, что захотите, на самом деле это не имеет значения.

Для варианта (2) вполне нормально начать с ручки и бумаги.Но вскоре вам лучше использовать специализированный инструмент для создания макетов (как только вам понадобится отредактировать, поддерживать или упорядочить свои макеты).

В итоге я написал свой собственный инструмент для создания макетов еще в 2005 году, и он стал довольно популярным: Макетные экраны

И вот самый полный список инструментов для создания макетов, о которых я знаю.Многие из них бесплатны: http://c2.com/cgi/wiki ?Инструменты гипрототипирования