Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
shpory_trpp.doc
Скачиваний:
0
Добавлен:
01.05.2025
Размер:
243.2 Кб
Скачать

Преимущества модели rad.

1) время цикла разработки сокращается благодаря использо­ванию мощных инструментальных средств. 2) повторное использование компонент уже существующих программ. 3) существует возможность произвести быстрый изначальный просмотр продукта.

Недостатки модели rad

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

6) Модель прототипирования жизненного цикла разработки по.

Прототипирование — это процесс построения рабочей модели системы. Прототип — это эквивалент экспериментальной модели или "макета" в мире аппаратного обеспечения.

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

Таким образом, создается план проекта, а затем выполняется быстрый анализ, по­сле чего проектируется база данных, пользовательский интерфейс и разработка функций. Второе действие — это быстрый анализ, на протяжении которого предва­рительные опросы пользователей используются для разработки умышленно непол­ной высокоуровневой модели системы на уровне документации. В результате выпол­нения этой задачи получают документ, содержащий частичную спецификацию требо­ваний, который используется для построения исходного прототипа, создаваемого на последующих трех этапах. Дизайнер конструирует модель (используя для этого инст­рументальные средства), то есть частичное представление системы, которое включа­ет в себя только те базовые свойства, которые необходимы для удовлетворения тре­бований заказчика. Затем начинается итерационный цикл быстрого прототипирования. Разработчик проекта демонстрирует прототип, а пользователь оценивает его функционирование. После этого определяются проблемы, над устранением которых совместно работают пользователь и дизайнер. Этот процесс продолжается до тех пор, пока пользователь не будет удовлетворен тем, каким образом система отобража­ет поставленные к ней требования. Команда разработчиков проекта продолжает вы­полнять этот процесс до тех пор, пока пользователь не согласится, что быстрый про­тотип в точности отображает системные требования. Создание базы данных пред­ставляет собой первую из этих двух фаз. После создания исходной базы данных можно начать разработку меню, после чего следует разработка функций, то есть соз­дается рабочая модель. Затем модель демонстрируют пользователю с целью получе­ния предложений по ее усовершенствованию, которые объединяются в последова­тельные итерации до тех пор, пока рабочая модель не окажется удовлетворительной. Затем получают официальное одобрение пользователем функциональных возможно­стей прототипа. После этого создается документ предварительного проекта системы. Основным компонентом является фаза итерации прототипа, на протяжении кото­рого при использовании сценариев, предоставленных рабочей моделью, пользова­тель может разыграть роли и потребовать, чтобы последовательное уточнение мо­дели продолжалось до тех пор, пока не будут удовлетворены все функциональных требования. Получив одобрение пользователя, быстрый прототип преобразуют де­тальный проект, и систему настраивают на производственное использование. Именно на этом этапе настройки ускоренный прототип становится полностью дей­ствующей системой, которая заменяет собой частичную систему, полученную в итерационном цикле прототипирования. Преимущества применения прототипирования: 1)уменьшение времени, стоимости, рисков: прототипирование улучшает качество спецификаций; чем позднее проводятся изменения в спецификации, тем они дороже, поэтому, уточнение «чего же пользователи/заказчики хотят на самом деле» на ранних стадиях разработки — снижает общую стоимость. 2) вовлечение пользователя в процесс разработки: прототипирование вовлекает будущих пользователей в процесс разработки, и позволяет им видеть то, как именно будет выглядеть будущая программа, что позволяет избавиться от возможных расхождений в представлении о программе между разработчиками и пользователями. Недостатки: 1)недостаточный анализ: концентрация усилий на ограниченном прототипе может отвлекать разработчиков от надлежащего анализа требований на полную систему. 2)смешение прототипа и готовой системы в представлении пользователей: пользователи могут подумать, что прототип, который предполагается «выбросить», и есть основа будущей системы. Исходя из этого предположения, пользователи могут требовать от прототипа более точного поведения, могут разочароваться в возможностях разработчиков. 3) чрезмерное время на создание прототипа: ключевое свойство прототипа — то, что он создается за короткое время. Если разработчики не принимают это во внимание, то они тратят время на создание слишком сложного прототипа, и теряют преимущества от применения прототипирования вообще.

7) Многопроходная модель Многопроходная модель (рис. 3.6) — это несколько итераций процесса построения прототипа ПП с добавлением на каждой следующей итерации новых функциональных возможностей или повышением эффективности ПП. Предполагается, что на ранних этапах жизненного цикла разработки (планирование, анализ требований и разработка проекта) выполняется конструирование ПП в целом. Тогда же определяется и число необходимых инкрементов и относящихся к ним функций. Каждый инкремент затем проходит через оставшиеся фазы жизненного цикла (кодирование и тестирование). Сначала выполняются конструирование, тестирование и реализация базо¬вых функций, составляющих основу ПП. Последующие итерации направлены на улучшение функциональных возможностей ПП. Преимущества многопроходной модели: • в начале разработки требуются средства только для разработки и реализации основных функций ПП; • после каждого инкремента получается функциональный продукт; • снижается риск неудачи и изменения требований; • улучшается понимание как разработчиками, так и пользователями ПП требований для более поздних итераций;  • инкременты функциональных возможностей легко поддаются тестированию. Недостатки многопроходной модели: • не предусмотрены итерации внутри каждого инкремента; • определение полной функциональности должно быть осуществлено в самом начале жизненного цикла разработки; • может возникнуть тенденция оттягивания решения трудных задач; • общие затраты на создание ПП не будут снижены по сравнению с другими моделями; • обязательным условием является наличие хорошего планирования и проектирования. Многопроходная модель может быть применена, если большинство требований к ПП будут сформулированы заранее, а для выполнения проекта будет выделен большой период времени.

8) Спиральная модель. Для преодоления проблем, связанных с использованием многопроходной модели, в середине 1980-х годов была предложена спиральная модель жизненного цикла (рис. 3.7). Ее принципиальная особенность заключается в том, что прикладной ПП создается не сразу, как в случае каскадного подхода, а по частям с использованием метода прототипирования. Под прототипом понимается действующий программный компонент, реализующий отдельные функции и внешние интерфейсы разрабатываемого ПП. Создание прототипов осуществляется за несколько итераций, или витков спирали. Каждая итерация соответствует созданию фрагмента, или версии ПП, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации. На каждой итерации производится тщательная оценка риска превышения сроков и стоимости проекта с целью определения необходимости выполнения еще одной итерации, степени полноты и точности понимания требований к системе, а также целесообразности прекращения проекта. Спиральная модель избавляет пользователей и разработчиков ПП от полного и точного формулирования требований к системе на начальной стадии, поскольку они уточняются на каждой итерации. Таким образом, углубляются и последовательно конкретизируются детали проекта и, в результате, выбирается обоснованный вариант, который доводится до реализации. Разработка итерациями отражает объективно существующий спиральный цикл создания системы, позволяя переходить на следующую стадию, не дожидаясь полного завершения работы на текущей стадии, поскольку при итеративном способе разработки недостающую работу можно выполнить на следующей итерации. Главная задача такой разработки — как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Спиральная модель не исключает использования каскадного подхода на завершающих стадиях проекта в тех случаях, когда требования к системе оказываются полностью определенными. Основная проблема спирального цикла — определение момента перехода на следующую стадию. Для ее решения необходимо ввести временные ограничения на каждую из стадий жизненного никла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. Спиральная модель обладает следующими достоинствами: • заказчик имеет возможность увидеть разрабатываемый ПП на ранних стадиях разработки; • заказчики принимают активное участие в разработке ПП; • в модели воплощены преимущества каскадной и многопроходной моделей. Недостатки спиральной модели: • усложненная структура; • спираль может продолжаться до бесконечности, так как каждая ответная реакция заказчика может породить новый цикл.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]