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

Question

Кто побеждает в дебатах «Прототипирование с низкой или высокой точностью»?Должен ли нулевой прототип (P0) быть первой версией конечного продукта?Или P-0 всегда должен быть бросовым продуктом?Какой подход предпочитает отрасль?

Отличная статья из Википедии: Прототипирование программного обеспечения

Answer 1

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

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

Answer 2

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

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

Answer 3

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

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

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

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

Поэтому, называя их прототипы «доказательством концепции», мы надеемся побудить их воплотить свои смелые концепции в конкретную форму (смутная болтовня на естественном языке и частое размахивание руками наименее полезны и в любом случае чужды культуре компании;-) и однако четко указывают на то, что такие проекты, если они включены в число целей и приоритетов разработчиков программного обеспечения, НЕОБХОДИМО программировать с нуля - доказательство концепции служит в лучшем случае хорошим черновиком/наброском спецификации того, что будет инженеры стремятся, однозначно НЕ к постепенному обогащению, а к переделке с корнем!-).

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

Answer 4

Ответ от БУНДАЛЛА, ХАМИСИ

Прототип обычно имитирует лишь несколько аспектов функций будущей программы и может полностью отличаться от конечной реализации.Вопреки тому, что предлагали выше мои коллеги, я бы НЕ советовал своему начальнику выбирать выбрасываемую прототипную модель.Я согласен с Анитой в этом вопросе.Учитывая две модели-прототипы и предоставленные обстоятельства, я бы настоятельно посоветовал руководству (моему начальнику) сделать выбор в пользу модели эволюционного прототипа.Поскольку компания большая, учитывая все другие переменные, такие как сложность кода, новизна используемого языка программирования, я бы не стал использовать модель выбрасываемого прототипа.Модель одноразового прототипа становится отправной точкой, благодаря которой пользователи могут пересмотреть свои ожидания и уточнить свои требования.Когда это достигается, прототип модели «выбрасывается», а система формально разрабатывается на основе выявленных требований (Crinnion, 1991).Но в этой ситуации пользователи могут не знать всех требований сразу из-за сложности факторов, заданных в этой конкретной ситуации.Эволюционное прототипирование — это процесс разработки компьютерной системы путем постепенного усовершенствования.Каждая доработка системы содержит спецификацию системы и этап разработки программного обеспечения.В отличие от традиционного водопадного подхода и поэтапного прототипирования, которые требовали от каждого сделать все правильно с первого раза, этот подход позволяет участникам поразмышлять над уроками, извлеченными из предыдущих циклов.Обычно необходимо пройти три таких цикла постепенного совершенствования.Однако ничто не останавливает процесс непрерывной эволюции, который часто имеет место во многих системах.По мнению Дэвиса (1992), эволюционное прототипирование признает, что мы не понимаем всех требований (поскольку выше нам сказали, что система сложна, компания велика, код будет сложным, а язык достаточно нов для команда программистов).Основная цель использования эволюционного прототипирования — создать очень надежный и структурированный прототип и постоянно его совершенствовать.Причина этого в том, что Эволюционный прототип после его создания образует сердце новой системы, и в него будут внесены улучшения и дополнительные требования.Этот метод позволяет команде разработчиков добавлять функции или вносить изменения, которые невозможно было задумать на этапе разработки требований и проектирования.Чтобы система была полезной, она должна развиваться посредством использования в предполагаемой операционной среде.Продукт никогда не будет «выполнен»; Это всегда созревает по мере изменения среды использования.Разработчики часто пытаются определить систему, используя наиболее знакомую систему координат — то, где они находятся в данный момент (или, скорее, текущее состояние системы).Они делают предположения о том, как будет вестись бизнес, и о технологической базе, на которой этот бизнес будет реализован.Принимается план развития потенциала, и рано или поздно нечто, напоминающее предполагаемую систему, будет реализовано.(СПЦ, 1997).Эволюционные прототипы имеют преимущество перед одноразовыми прототипами в том, что они являются функциональными системами.Хотя они могут не иметь всех функций, запланированных пользователями, их можно использовать на временной основе до тех пор, пока не будет поставлена ​​окончательная система.При эволюционном прототипировании разработчики могут сосредоточиться на разработке частей системы, которые они понимают, вместо того, чтобы работать над разработкой всей системы.Чтобы минимизировать риск, разработчик не реализует малоизученные функции.Частичная система отправляется на объекты заказчика.Работая с системой, пользователи обнаруживают возможности для новых функций и отправляют запросы на эти функции разработчикам.Затем разработчики принимают эти запросы на улучшения вместе со своими собственными и используют надежные методы управления конфигурацией для изменения спецификации требований к программному обеспечению, обновления дизайна, перекодирования и повторного тестирования.(Берсофф и Дэвис, 1991).Однако основные проблемы эволюционного прототипирования связаны с плохим управлением:Отсутствие определенных этапов, отсутствие достижений — постоянное откладывание того, что будет в нынешнем прототипе, до следующего, отсутствие должной оценки, отсутствие ясности между прототипом и реализованной системой, отсутствие постоянной приверженности со стороны пользователей.Этот процесс требует большей степени постоянной приверженности пользователей в течение более длительного периода времени, чем это требуется традиционно.Пользователи должны быть постоянно информированы о том, что происходит, и полностью осознавать ожидания «прототипов».

Рекомендации

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

Кринион, Дж. (1991).Разработка эволюционных систем, практическое руководство по использованию прототипирования в рамках методологии структурированных систем.Пленум Пресс, Нью-Йорк.

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

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