Как много проектирование должно продолжаться до того, как произойдет какое-либо кодирование?

Ответ 1

Я не хочу оторваться как сломанная запись (я часто использовал эту цитату в последнее время), но эта цитата из John Gall действительно актуальна для многих аспектов создания программного обеспечения. (хотя он говорил о биологических системах)

википедия: Gall Law

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

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

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

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

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

Ответ 2

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

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

С юмористической точки зрения можно найти здесь.

Ответ 3

G'day,

Это очень зависит от характера проекта.

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

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

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

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

Изменить: Система находилась в Карлсруэ в центре управления воздушным движением на маршруте, управляемом DFS, немецкой версией FAA. Существующая система радиолокационной обработки будет заменена Raytheon, однако поставка основной системы была отложена. Таким образом, DFS решила обновить позиции контроллера до тех, что для новой системы, но временно подключить их к существующей системе обработки УВД. Отсюда и название проекта Karlsruhe AdvancedDisplay System или KADS. Совершенно новое крыло было построено на задней части существующего центра УВД, когда была заменена вся комната управления.

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

Они задокументировали:

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

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

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

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

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

BTW Количество старых инженеров-программистов, которые пришли на стадии требований и сказали, что мы не работаем, потому что не было написано кода, было довольно забавно. Определенно свидетельство старого подхода "сиденья для брюк", которое было очевидно, когда вы смотрели на какой-то код. (-:

НТН

веселит,

Ответ 4

Это так в прошлом веке, так академично.

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

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

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

Ответ 5

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

Это имеет смысл, вы не понимаете это правильно (или почти правым) для начала, вы будете ввернуты.

Однако на практике у немногих есть роскошь времени и ресурсов. Хуже всего то, что нетехнические парни (особенно те, кто там) хотят видеть вещи (UI, прототип), чтобы действительно чувствовать себя уверенными в достигнутом прогрессе.

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

Что касается UML, вот несколько интересных сообщений на SO:
Является ли UML практичным? Является ли UML по-прежнему считаться жизнеспособным способом документирования дизайна программного обеспечения? Должен ли я использовать UML при разработке нового кода и алгоритмов?
Если вы не проектируете в UML, то что вы разрабатываете в?

Ответ 6

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

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

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

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

Ответ 7

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

Ответ 8

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

Часто проекты, запланированные на "Т", часто очень далеки от оригинальных спецификаций... потому что иногда вы достигаете технических ограничений или из-за непредвиденных условий, когда оригинальные проекты просто не работают.

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

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

Что касается UML-диаграмм и реального планирования глубины?

Я работал в компаниях, начиная от крупных операторов беспроводной связи и заканчивая крупными жилыми и коммерческими компаниями, до довольно приличной биллинговой компании... и я могу честно сказать, что я не видел людей НАСТОЯТЕЛЬНО использую диаграммы UML с любыми своего рода успех.

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

Что касается ужасного внешнего кода, который он, возможно, получил... вы получаете то, за что платите. Я не собираюсь делать какие-либо обобщения и т.д., Но я думаю, что даже здесь, в Америке, у вас, вероятно, соотношение 10: 1 для некомпетентных разработчиков и компетентных... и я думаю, что отношения здесь больше. Я бы не предполагал, что причиной проблем с кодом было планирование

Ответ 9

Да, эта одна из "традиционных" метадологий

В эти дни Проворные итеративные процессы разработки имеют намного больше шума и "заменяют" более старые " модель водопада".

Контраст, как нам говорят, находится между старыми, сначала планируйте, записывайте требования, записывайте спецификации, документируйте, а затем, наконец, в конце. Код, модель, с "более новым": Agile. В Agile система постепенно развивается в консультации с пользователями. Один пытается всегда иметь запущенную систему и модульные тесты. Направление может быть изменено до того, как требования будут серьезно неправильно истолкованы, а потраченные впустую усилия будут сделаны в неправильном направлении.

Я не согласен с этим объяснением.

Я не согласен с Agile, просто идея, что она новая. Скорее, я бы сказал, что Agile является недавно популярным

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

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

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

Сказав все это, вам не помешает попробовать, и некоторые из тех методов документации имеют ценность за пределами модели водопада.

Ответ 10

Спросите своего профессора, если они когда-либо имели неакадемическую работу. Затем попросите их описать самую большую систему, которую они когда-либо писали; какая самая большая команда, в которой они когда-либо были; были ли они когда-либо выставлены или отправлены или выпущены система.

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

Ответ 11

Передние конструкции, например. UML-модели, являются гипотезами, которые проходят тестирование и обычно ошибочны во время кодирования. Короче говоря, кодирование не аналогично "constrction"; скорее кодирование проектируется.

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

Ответ 12

Я не удивлен многими комментариями по этому вопросу.

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

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

Из-за всех современных процессов IDE/Debug все стало больше пробной ошибки-google-trial - теперь это может работать! -finished?

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

Ведь ты все еще в школе!

Удачи.

Ответ 13

Водопад ИМХО становится менее актуальным и более гибким из-за эволюции современных языков программирования. Раньше потребовалось бы навсегда запрограммировать даже самую простую вещь (проверьте синтаксис COBOL, если вы хотите увидеть, как не быть тощим и выразительным), поэтому было очень важно написать документы, объясняющие, что вы хотели чтобы сделать, а затем пойти реализовать его. В настоящее время процесс документа намного короче, потому что самый простой и естественный способ для программиста выразить свой дизайн (шокер!) В самом коде.

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

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

Удачи!

Ответ 14

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

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

Cheers,
Иван

Ответ 15

Планы - ничто; планирование - это все.

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

Должны ли вы следовать за дизайном класса в письме? Почти наверняка нет; Я никогда не работал над проектом, где требования не менялись на полпути из-за каких-то непредвиденных обстоятельств. Но по крайней мере вы идете в нее с некоторым представлением о том, что нужно сделать. Мне кажется, что вы слишком жестко следили за своими документами, что может вызвать проблемы.

Ответ 16

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

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

Ответ 17

В реальной ситуации у вас, вероятно, нет роскоши, чтобы сделать сложный дизайн, который полностью описал бы то, что вы собираетесь строить. Плюс это может быть контрпродуктивным, поскольку этот дизайн станет старым и сломанным в первый день кодирования (на устаревшем на 2-м). После Agile методология намного безопаснее с итеративным построением прототипов и постоянным перераспределением и уточнением. В этом случае вы (или ваша команда) можете начать кодирование почти сразу. Есть несколько хороших книг по Xp и Agile Methodology, таких как Искусство гибкого развития, которое может дать лучшую идею
Сказал, что - не иметь дизайн - это не очень хорошая идея. Вам всегда нужен план. Это просто с планами Agile меняются "по ходу"

Ответ 18

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

Ответ 19

Как правило, вы получаете набор требований, и вы начинаете проектировать архитектуру. Основываясь на некоторых моделях оценки стоимости, вы делаете цитату, если у вас есть бизнес (хорошо в вашем случае, если у вас есть это и плачевно выплачено: --D), то вы можете продолжить подробный дизайн. Реальное кодирование может быть выполнено обезьянами кода... Разумное и правильное проектирование системы является ключом к успеху: требования выполнены и стоят в рамках бюджета.

Конструирование, на мой взгляд, не определяет условия pre и post, которые являются деталями, но более определяют пакеты и распределяют/разделяют требования к ним. Помимо определения больших компонентов в вашей системе и того, как они взаимодействуют. Вы должны думать о том, чтобы свободно связывать их, чтобы улучшить тестируемость (дизайн для тестов), среди прочего: так что фокус явно не на некоторых предварительных и почтовых условиях в реальных масштабных проектах...

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

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

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

Ответ 20

В зависимости от проекта у меня есть два варианта, которые мне нравятся.

Для небольших проектов, которые я хочу быстро закончить, мне нравится следовать правилам http://www.extremeprogramming.org/ (гибкое программирование), где вы "пикируете" "ваши идеи, а не полностью их устранение.

Для более серьезных проектов, хотя я хотел бы набросать базовую модель (UML/database/sequence) до начала. Эта модель основана на требованиях, сформулированных ранее. Модель в основном предназначена для того, чтобы дать мне представление о том, какие классы нужно строить и как они должны работать. Я никогда не разбираюсь в методах, но это время реализации.

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

Ответ 21

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

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

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

Ответ 22

Я просто посередине узнал, как наилучшим образом реализовать проекты кодирования, планирование/кодирование для повторения или не для итерации. Сколько времени потратить на план и т.д.

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

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

Ответ 23

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

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

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

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

Ответ 24

Я думаю, вы хотите, чтобы мы сказали вам, что ваш профессор ошибается. Вот некоторые боеприпасы: http://www.developerdotstar.com/mag/articles/reeves_design_main.html Мне еще предстоит выяснить, является ли reeves на 100% правильным, но пока это.

Ответ 25

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

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

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

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

Ответ 26

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

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

Ответ 27

Академические учителя никогда не занимались реалистичными проектами:). Они несут ответственность за этот дух водопада. Также UML Tools сегодня не удобны, хотя Visual Studio 2010 Ultimate приближается.