Навигация
Модель прототипирования
56436
знаков
1
таблица
10
изображений
3.4 Модель прототипирования
Рис.6 Модель прототипирования
Модель прототипитования позволяет создать прототип программного продукта до или в течение этапа составления требований к программному продукту. Потенциальные пользователи работают с этим прототипом, определяя его сильные и слабые стороны, о результатах сообщают разработчикам программного продукта. Таким образом, обеспечивается обратная связь между пользователями и разработчиками, которая используется для изменения или корректировки спецификации требований к программному продукту. В результате такой работы продукт будет отражать реальные потребности пользователей.
Жизненный цикл разработки программного продукта начинается с разработки плана проекта, затем выполняется быстрый анализ, после чего создаются база данных, пользовательский интерфейс и выполняется разработка необходимых функций. В результате этой работы получается документ, содержащий частичную спецификацию требований к программному продукту. Данный документ в дальнейшем является основой для итерационного цикла быстрого прототипирования.
В результате прототипирования разработчик демонстрирует пользователям готовый прототип, а пользователи оценивают его функционирование. После этого определяются проблемы, над устранением которых совместно работают пользователи и разработчики. Этот процесс продолжается до тех пор, пока пользователи не будут удовлетворены степенью соответствия программного продукта, поставленным перед ним требованиям. Затем прототип демонстрируют пользователям с целью получения предложений по его усовершенствованию, которые включаются в последовательные итерации до тех пор, пока рабочая модель не окажется удовлетворительной. После этого получают от пользователей официальное одобрение (утверждение) функциональных возможностей прототипа и выполняют его окончательное преобразование в готовый программный продукт.
Модель протипирования обладает целым рядом преимуществ:
1) Взаимодействие заказчика с разрабатываемой системой начинается на раннем этапе;
2) Благодаря реакции заказчика на прототип сводится к минимуму число неточностей в требованиях;
3) Снижается вероятность возникновения путаницы, искажения информации или недоразумений при определении требований к программному прдукту, что приводит к созданию более качественного программного продукта;
4) В процессе разработки всегда можно учесть новые, даже неожиданные требования заказчика;
5) Прототип представляет собой формальную спецификацию, воплощенную в программный продукт;
6) Прототип позволяет очень гибко выполнять проектирование и разработку, включая несколько итераций на всех фазах жизненного цикла разработки;
7) Заказчик всегда видит прогресс в процессе разработки программного продукта;
8) Возможность возникновения противоречий между разработчиками и заказчиками сведена к минимуму;
9) Уменьшается число доработок, что снижает стоимость разработки: возникающие проблемы решаются на ранних стадиях, что резко сокращает расходы на их устранение; заказчики принимают участие в процессе разработки на протяжении всего жизненного цикла и в конечном итоге в большей степени довольны результатом работы.
Кроме указанных достоинств модели прототипирования присущ и целый ряд недостатков:
1) Решение сложных задач может отодвигаться на будущее;
2) Заказчик может предпочесть получить прототип, а не законченную полную версию программного продукта;
3) Прототипирование может неоправданно затянуться;
4) Перед началом работы неизвестно, сколько итераций придется выполнить.
Модель прототипирования рекомендуется применять в следующих случаях:
1) Требования к программному продукту заранее неизвестны;
2) Требования не постоянны или неудачно сформулированы;
3) Требования необходимо уточнить;
4) Нужна проверка концепции;
5) Существует потребность в пользовательском интерфейсе;
6) Выполняется новая, не имеющая аналогов разработка;
7) Разработчики не уверены в том, какое решение следует выбрать.
3.5 Модель быстрой разработки приложений (RAD-модель)
В RAD-модели (рис.7) конечный пользователь играет решающую роль. В тесном взаимодействии с разработчиками он участвует в формировании требований и апробации их на работающих прототипах. Таким образом, в начале жизненного цикла на конечного пользователя выпадает большая часть работы, но в результате этого создаваемая система формируется более быстро.
В традиционном жизненном цикле разработки большую часть работы составляют программирование и тестирование. При автоматизации программирования и повторном использовании кода, применяемых в RAD-модели, большую часть работы составляют планирование и проектирование.
На рисунке (рис.7), поясняющем принцип RAD-модели, указаны этапы процесса разработки и отображено участие заказчиков (штриховая линия) на каждом из них.
Модель включает в себя следующие фазы:
Составление требований и планирование - осуществляются с использованием, так называемого метода совместного планирования требований (планирование работ по созданию программного продукта и составление требований к программному продукту выполняются одновременно), который заключается в структурном анализе и обсуждении решаемых задач;
Описание пользователя – проектирование программного продукта, выполняемое при непосредственном участии заказчика;
Создание – детальное проектирование, кодирование и тестирование программного продукта, а также поставка его заказчику;
Сопровождение – приемочные испытания, установка программного продукта и обучение пользователей.
Модель обладает следующими достоинствами:
1) Использование современных инструментальных средств позволяет сократить время цикла разработки;
2) Привлечение к работе заказчика сводит к минимуму риск того, что он останется недоволен готовым программным продуктом;
3) Повторно используются компоненты уже существующих программ.
В то же время ей присущи и недостатки:
1) Если заказчики не могут постоянно участвовать в процессе разработки, то это может негативно сказаться на программном продукте;
2) Для работы нужны высококвалифицированные кадры, умеющие пользоваться современными инструментальными средствами;
3) Существует риск, что работа над программным продуктом никогда не будет завершена, так как может быть зациклена, поэтому всегда надо вовремя остановиться.
Рассмотренную RAD-модель можно применять при разработке программных продуктов, которые хорошо поддаются моделированию, когда требования к программным продуктам хорошо известны, а заказчик может принять непосредственное участие в процессе разработки.
Рис.7 Модель быстрой разработки приложений
Похожие работы
... продукта и создание удобных карточек заполнения атрибутов БД: простота создания связей и их модернизация. Глава II. Разработка программы для автоматизации деятельности таксопарка 2.1 Анализ требований заказчика Программа Автоматизированное рабочее место диспетчера такси разработана по спиральной модели жизненного цикла автоматизированных информационных систем. На каждом этапе создания ...
... же разработать информационное обеспечение по учёту ТС магазина «Техносила». Глава 1. Теоретические особенности организации технического обеспечения 1.1 Основные требования и характеристики современных и применение технических средств АИС Автоматизированная информационная система (АИС) представляет собой комплекс информационных, программных, технических, организационно-методических и ...
... . 90. Перечислите меры по защите информации от несанкционированного копирования и распространения программ. Зав. кафедрой -------------------------------------------------- Экзаменационный билет по предмету ОСНОВЫ АВТОМАТИЗИРОВАННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ Билет № 17 91. Вычислите значение логических высказываний: (AÚB)Ù(BÚC) (A®B)Ù (B®C), если А=0, ...
... системы. Основными нормативными документами, регламентирующими процесс создания любого проекта ИС и ИТ, являются ГОСТы и их комплексы на создание и документальное оформление информационной технологии, автоматизированных систем, программных средств, организации и обработки данных, а также руководящие документы Гостехкомиссии России по разработке, изготовлению и эксплуатации программных и ...
0 комментариев