Эволюционное vs одноразовое прототипирование [закрыто]

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

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

Я думаю, что мы, педанты, проиграли эту конкретную битву-предполагаемые " прототипы "(которые по определению следует переписать с нуля!!!- ) фактически " эволюционируют "в (часто наполовину испеченные" беты") и т. д.

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

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

но они не собираются программировать на C++, вряд ли вообще на Java, может быть, на Python, но в милях от "productionized" - действительно, они гораздо более склонны создавать умное доказательство концепции в php, javascript, perl, bash, Excel+VBA и других "быстрых и грязных" технологиях, которые мы даже не хотим к мечта о productionizing и поддерживать навсегда!-)

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

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

ответ из БУНДАЛЛЫ, ХАМИСИ

прототип обычно имитирует только несколько аспектов функций возможной программы и может полностью отличаться от возможной реализации. Вопреки тому, что предлагали мои коллеги выше, я бы не советовал своему боссу выбирать модель прототипа выброса. Я согласен с Анитой. Учитывая две прототипные модели и предоставленные обстоятельства, я настоятельно рекомендую руководству (моему боссу) выбрать эволюционный прототип модели. Поскольку компания велика со всеми другими переменными, такими как сложность кода, новизна используемого языка программирования, я бы не стал использовать модель прототипа. Модель прототипа throw away становится отправной точкой, с которой пользователи могут пересмотреть свои ожидания и уточнить свои требования. Когда это достигнуто, прототип модели "выбрасывается", и система формально разрабатывается на основе идентифицированных требования (Цриннион, 1991). Но в этой ситуации пользователи могут не знать всех требований сразу из-за сложности факторов, заданных в этой конкретной ситуации. Эволюционное прототипирование - это процесс разработки компьютерной системы путем постепенного совершенствования. Каждое уточнение системы содержит спецификацию системы и этап разработки программного обеспечения. В отличие от традиционного водопадного подхода и инкрементного прототипирования, которые требовали от каждого все правильно в первый раз этот подход позволяет участникам задуматься об уроках, извлеченных из предыдущего цикла(циклов). Обычно проходит три таких цикла постепенного очищения. Однако ничто не останавливает процесс непрерывной эволюции, который часто имеет место во многих системах. Согласно Дэвису (1992), эволюционное прототипирование признает, что мы не понимаем всех требований (как нам было сказано выше, что система сложна, компания большая, код будет сложным,а язык довольно новым для команды программирования). Основная цель при использовании эволюционного прототипирования - построить очень надежный прототип структурированным образом и постоянно совершенствовать его. Причина этого в том, что эволюционный прототип, будучи построен, формирует сердце новой системы, и будут построены улучшения и дальнейшие требования. Этот метод позволяет команде разработчиков добавлять функции или вносить изменения, которые не могут быть задуманы во время требования и этап проектирования. Для того чтобы система была полезной, она должна развиваться за счет использования в предполагаемой оперативной среде. Продукт никогда не" делается"; он всегда созревает по мере изменения среды использования. Разработчики часто пытаются определить систему, используя их наиболее знакомую систему отсчета-где они находятся в настоящее время (или, скорее, текущее состояние системы). Они делают предположения о том, как будет вестись бизнес и на какой технологической базе будет осуществляться бизнес. План принят развивать способности, и, рано или поздно, что-то подобное предполагал поставку. (SPC, 1997). Эволюционные прототипы имеют преимущество перед одноразовыми прототипами в том, что они являются функциональными системами. Хотя они могут не иметь всех функций, запланированных пользователями, они могут использоваться на временной основе до тех пор, пока не будет поставлена окончательная система. В эволюционном прототипировании, разработчики могут сосредоточиться на разработке частей системы, которые они понимают, а не работаем над разработкой целой системы. Чтобы минимизировать риск, разработчик не реализует плохо понятые функции. Частичная система отправляется на сайты клиентов. Когда пользователи работают с системой, они обнаруживают возможности для новых функций и предоставляют запросы на эти функции разработчикам. Затем разработчики берут эти запросы на улучшение вместе со своими собственными и используют рациональные методы управления конфигурациями для изменения спецификации требований к программному обеспечению, обновления дизайна, перекодирования и повторного тестирования. (Bersoff and Davis, 1991). Однако основные проблемы с эволюционным прототипированием связаны с плохим управлением: отсутствие определенных этапов, отсутствие достижений - всегда откладывание того, что будет в настоящем прототипе до следующего, отсутствие надлежащей оценки, отсутствие ясности между прототипом и внедренной системой, отсутствие постоянной приверженности со стороны пользователей. Этот процесс требует большей степени постоянной приверженности со стороны пользователей в течение более длительного периода времени, чем обычно требуется. Пользователи должны быть постоянно информированы о том, что происходит, и быть полностью осведомлены о ожиданий "прообразами".

ссылки

Bersoff, Э. Дэвис, А. (1991). Влияние моделей жизненного цикла управления конфигурацией программного обеспечения. Связь. АСМ.

Цриннион, Ж.(1991). Эволюционное развитие систем, практическое руководство по использованию прототипирования в рамках методологии структурированных систем. Plenum Press, New York.

Дэвис, А. (1992). Оперативное прототипирование: новый подход к разработке. Программное обеспечение IEEE.

консорциум производительности программного обеспечения (SPC). (1997). Эволюционное Быстрое Развитие. Документ SPC SPC-97057-CMC, версия 01.00.04.