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

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

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

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

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

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

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

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

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

Читайте на 4+1 Представлении Kruchten.

Вот способ, которым можно продолжить двигаться.

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

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

3. Запишите рассказы. Если Вы хотите, можно нарисовать схемы Действия.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мы используем Экраны Макета на работе ("Быстрые и Легкие Экранные Прототипы"). Легко изменить экраны, и scetches ясно дают понять, что это - только дизайн.

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

От концептуального разрушения: руководство по лучшим идеям James L. Adams:

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

(стр. 71, 3-й Выпуск)

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

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

Между прочим, Концептуальное Разрушение настоятельно рекомендовано, читая.

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

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