КАТЕГОРИИ: Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748) |
Модель прототипирования жизненного цикла разработки ПО
Область применения V-образной модели Недостатки V-образной модели При использовании V-образной модели в работе над проектом, для которого она не является в достаточной степени приемлемой, становятся очевидными ее недостатки:
Графически модель зачастую изображается (как показано на рис. 4) без указания интегральных задач. Этот вопрос достаточно легко решается, он здесь упоминается только для того, чтобы напомнить читателю о том, что интегральные задачи имеют место при использовании всех моделей жизненного цикла. С целью преодоления этих недостатков V-образную модель можно модифицировать, включив в нее итерационные циклы, предназначенные для разрешения изменений в требованиях за рамками фазы анализа.
Подобно своей предшественнице, каскадной модели, V-образная модель лучше всего срабатывает тогда, когда вся информация о требованиях доступна заранее. Общераспространенная модификация V-образной модели, направленная на преодоление ее недостатков, включает в себя внесение итерационных циклов для разрешения изменения в требованиях за рамками фазы анализа. Использование модели эффективно в том случае, когда доступными являются информация о методе реализации решения и технология, а персонал владеет необходимыми умениями и опытом в работе с данной технологией. V-образная модель — это отличный выбор для систем, в которых требуется высокая надежность, таких как прикладные программы для наблюдения за пациентами в клиниках, а также встроенное ПО для устройств управления аварийными подушками безопасности в автомобилях.
Ставшее классикой произведение Фреда Брукса (Fred Brook) под названием "Легендарный человек-месяц" (The Mythical Man-Month) сегодня столь же актуально, как и в 1975 году. Технологии радикально изменили мир, но многие недостатки менеджмента программных проектов по-прежнему те же. Десятки лет тому назад Брукс сказал: "В большинстве проектов первая построенная система едва ли пригодна к употреблению. Она может быть слишком медленной, слишком объемной, неудобной в использовании или обладать всеми тремя перечисленными недостатками. Нет другого выбора, кроме как начать с самого начала, приложив все усилия, и построить модернизированную версию, в которой решались бы все три проблемы... В случае, когда в проекте используется новая системная концепция или новая технология, разработчик вынужден построить систему, которой впоследствии не воспользуется, поскольку даже при наилучшем планировании невозможно предвидеть достижение нужного результата. Следовательно, вопрос менеджмента заключается не в том, создавать или нет экспериментальную систему, которой затем не воспользуются. Вы в любом случае так и сделаете. Единственный вопрос в том, нужно ли планировать создание продукта одноразового использования заранее или обещать поставить его заказчикам..." Именно эта концепция построения экспериментальной, или прототипной системы привела к возникновению "структурной", "эволюционной" модели быстрого прототипирования (RAD), и спиральной модели. В своей боле поздней, в равной степени полной плодотворных идей работе под названием "No Silver Bullet, the Essence and Accidents of Programming" Брукс считает, что большинство ошибок, возникающих при разработке ПО, все же связаны с неправильным пониманием концепции системы, а не с синтаксисом или логикой. Разработка ПО всегда будет трудной задачей, и мы никогда не найдем чудодейственную панацею или "серебряную пулю". Он подчеркивает положительный момент в применении методов быстрого прототипирования: "Самой тяжелой составляющей процесса построения программной системы является принятие однозначного решения о том, что именно необходимо построить. Ни одна из остальных составляющих работы над концепцией не представляет собой такую трудность, как определение детальных технических требований, включая все аспекты соприкосновения продукта с людьми, машинами и другими программными системами. Ни одна другая составляющая работы в такой степени не наносит ущерб полученной в результате системе, если она выполнена неправильно. Именно эту составляющую процесса разработки тяжелее всего исправить на более поздних этапах. Следовательно, самая важная функция, которую выполняет разработчик клиентских программ, заключается в итеративном извлечении и уточнении требований к продукту. Ведь на самом деле клиент не имеет представления о том, что именно он хочет получить. На данный момент времени одной из самых обещающих среди технологических попыток, сосредоточенных на сущности, а не на трудностях решения проблемы разработки ПО, является разработка методов и средств для ускоренного прототипиро-вания систем как составляющей итеративной спецификации требований". Уотте Хэмфри (Watts Humphrey), который известен как вдохновитель создания модели СММ, разработанной Институтом SEI, поддерживает Брукса в его подходе к важности требований и их разработки: "В большинстве систем заключен основной принцип, который включает в себя больше, чем незначительное эволюционное изменение. Система может изменить само эксплуатационное окружение. Поскольку пользователи могут рассуждать о том или ином явлении только в рамках известного им окружения, требования к таким системам всегда формулируются в рамках текущего окружения. Следовательно, эти требования непременно будут неполными, неточными и обманчивыми. Главной задачей для системного разработчика является изобретение процесса разработки, с помощью которого можно будет обнаружить, определить и разработать реальные требования. Этого можно достичь только при максимальном включении пользователя в процесс разработки и зачастую с помощью периодического тестирования прототипов или версий, полученных на ранних этапах разработки. Оказывается, что такие процессы всегда занимают больше времени, но неизменно в конце приводят к разработке лучшей системы намного быстрее, чем при использовании какой-либо другой стратегии".
Дата добавления: 2015-03-31; Просмотров: 929; Нарушение авторских прав?; Мы поможем в написании вашей работы! Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет |