Сколько разработки должно продолжиться, прежде чем какое-либо кодирование происходит? [закрытый]

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

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

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

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

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

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

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

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

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

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

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

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

Удачи!

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

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

Удачи!

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

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

Удачи!

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

Удачи!

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

Удачи!

I think you want us to tell you that your professor is wrong. Here's some ammunition: http://www.developerdotstar.com/mag/articles/reeves_design_main.html I have yet to discover if reeves is 100% correct but so far it is.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ура,
Иван

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

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

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

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

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

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

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

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

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

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

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

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

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

В конце концов, ты еще в школе!

Удачи.

Предварительные разработки, например модели UML, - это гипотезы, которые проверяются и обычно оказываются неверными во время кодирования. Короче говоря, кодирование не аналог «конструирования»; скорее кодирование - это проектирование.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это имеет смысл. , вы не поймете это правильно (или почти правильно) с самого начала, вы облажаетесь.

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

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

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

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

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

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

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

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

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

Некоторые юмористические взгляды на это можно найти здесь .

G'day,

It very much depends on the nature of the project.

I have worked on projects where the new system was a replacement for an existing system and the vast majority of time was spent gathering the behaviour of the existing system to establish requirements.

This phase, and then the design phase, took nearly eighteen months. The coding took about four months in calendar terms. In effort terms it was much more, but the net result was a stable system that the customer loved.

Oh, by the way, this was a replacement for an existing air traffic control system, a German air traffic control system, so for them to put it live after only one month of the three months scheduled evaluation period was quite an achievement that I'm incredibly proud of.

I think the large evaluation and design phase for this project was the best approach.

Edit: The system was in Karlsruhe at the en-route air traffic control centre run by the DFS, the German version of the FAA. The existing radar processing system was going to be replaced by Raytheon however delivery of the main system was delayed. So the DFS decided to upgrade the controller positions to those for the new system but attach them to the existing ATC processing system temporarily. Hence the name of the project Karlsruhe AdvancedDisplay System or KADS. A completely new wing was built on the back of the existing ATC centre as the whole control room was being replaced.

There was an enforced requirements gathering phase where the team was on-site working alongside the software engineers who'd built the existing system.

They documented:

• all messages between the existing radar processing system and the controller positions
• all behaviours of the existing controller positions, touch panels, keyboards, display characteristics, etc.

These requirements were then signed off by the DFS and the design phase started. This lasted about a month while several parts were prototyped and the best solutions identified. In parallel with the implementation was a test design phase where all requirements were traced through to the code and had an associated test.

Then coding and testing kicked off with several deliveries, approx. ten, done, each with an associated test and acceptance phase. A Scrum approach before it had a name in that we selected what chunks of work were to go into each "release" phase at the beginning of the phase. Final delivery came in on time and on budget.

The DFS intended to run the new system in parallel with the existing system for three months so that they could evaluate the performance and stability of the new system. Transferring completely over to the new system was an "all or nothing" proposal. They had to physically jackhammer the old radar lines out to remove the old telephone switch gear and there was no going back after that.

So for the German ATC service to be so happy with the system that they would do that was a big pat on the back for us!

BTW The number of the old software engineers who came up during the requirements phase and said that we weren't working because there was no code being written was quite funny. Definitely evidence of an old "seat of the pants" approach that was evident when you looked at some of the code. (-:

HTH

cheers,

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

В планах ничего нет; планирование - это все.

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

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