6. Прогностические модели процесса разработки: каскадная, RAD, спиральная
Primary tabs
Forums:
6. Прогностические модели процесса разработки: каскадная, RAD, спиральная
Прогностические (прогнозирующие- "тяжеловесные" процессы) - предполагают планирование всего объема работ и, соответственно, достаточно большой объем документации
Основная цель таких процессов – отделить успешные практики разработки и сопровождения ПО от конкретных людей, умеющих их применять
Многочисленные вспомогательные действия [позволяют] выполнить успешную разработку с помощью имеющихся работников, не обязательно являющихся "суперпрофессионалами"
---------
Каскадная модель
Наиболее широко известной и применяемой долгое время оставалась так называемая каскадная или водопадная (waterfall) модель жизненного цикла
Впервые четко сформулирована в 1970 году Уильямом Ройсом (W.W.Royce) и затем закреплена в стандартах Министерства обороны США/
Предполагает строго последовательное поэтапное выполнение различных видов деятельности с четким определением границ между этапами
Набор документов, созданный на предыдущем этапе, передается в качестве входных данных для следующего этапа
СТРУКТУРА =
Выработка системных требований->Выработка требований к ПО->Анализ->Проектирование->Кодирование->Тестирование->Эксплуатация
Достоинства модели:
- упорядоченность процесса разработки
- возможность его строгого планирования во времени.
Недостатки модели:
- необходимость точной и полной формулировки требований к ПС перед началом разработки
- невозможность изменения решений, принятых на предыдущих этапах
- результаты проекта становятся доступны заказчику только по завершении работ.
RAD-модель
Модель быстрой разработки приложений (Rapid Application Development) появилась в 80-х годах прошлого века и является еще одним примером реализации инкрементной стратегии
Предполагает выделение в системе нескольких основных бизнес-функций и разработку каждой из них отдельной группой разработчиков с последующей интеграцией в целую систему
Каждая группа делает следующее(для той части проекта , что разрабатывает) =
Моделирование предметной области->Моделирование данных->Моделирование обработки->Генерация приложения->Объединение и тестирование
Применение данной модели оправдано в проектах, не требующих выполнения сложных алгоритмов, но при жестких ограничениях по сроками выполнения
Как правило RAD-модель используется при работе с мощными инструментальными средствами разработки – визуальными средами проектирования и программирования
Основным достоинством модели является уменьшение сроков разработки
Ее главный недостаток заключается в необходимости использования большого числа квалифицированных разработчиков, что может существенно повысить стоимость разработки
-------------------
Спиральная модель
Предложена в 1988 г. Барри Боэмом (Barry W. Boehm) и является классическим примером реализации эволюционной стратегии.
Модель определяет четыре действия:=
- планирование
- анализ рисков
- конструирование
- оценивание.
О них подробнее =
1) Планирование заключается в =
- определении целей очередной итерации процесса разработки,
- выборе вариантов решения
- и оценке ограничений
2) Анализ рисков – анализ вариантов решения и оценка связанных с ними рисков, т.е. возможностей получения неудовлетворительных результатов
3) Конструирование – это основное действие, заключающееся в создании следующей версии ПО
4) Оценивание – оценка заказчиком качества очередной версии ПО, внесение им предложений по модификации продукта, корректировка требований
Достоинства модели:
- данная модель отображает процесс разработки ПО в наиболее реальном виде;
- позволяет явно учитывать риски на каждом витке эволюционного процесса
- позволяет принимать различные управленческие решения (при переходе с одного этапа разработки на другой) вплоть до прекращения работ
Недостатки модели:
- повышенные требования к заказчику;
- трудности контроля и управления временем разработки
- Log in to post comments
- 11057 reads
vedro-compota
Wed, 01/25/2012 - 02:31
Permalink
текст опорного ответа
Водопадная (каскадная, последовательная) модель
Водопадная модель жизненного цикла (англ. waterfall model) была предложена в 1970 г. Уинстоном Ройсом. Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Этапы проекта в соответствии с каскадной моделью:
· Формирование требований;
· Проектирование;
· Реализация;
· Тестирование;
· Внедрение;
· Эксплуатация и сопровождение.
Преимущества:
· Полная и согласованная документация на каждом этапе;
· Легко определить сроки и затраты на проект.
Недостатки:
· необходимость точной и полной формулировки требований к ПС перед началом разработки;
· невозможность изменения решений, принятых на предыдущих этапах;
· результаты проекта становятся доступны заказчику только по завершении работ.
Эта модель исходит из того, что все ошибки будут сосредоточены в реализации, а потому их устранение происходит равномерно во время тестирования компонентов и системы. Таким образом, водопадная модель для крупных проектов мало реалистична и может быть эффективно использована только для создания небольших систем.
RAD –Rapid Application Development
Основные принципы
Принципы RAD технологии направлены на обеспечение трех основных ее преимуществ – высокой скорости разработки, низкой стоимости и высокого качества. Достигнуть высокого качества программного продукта весьма непросто и одна из главных причин возникающих трудностей заключается в том, что разработчик и заказчик видят предмет разработки (ПО) по-разному.
· Инструментарий должен быть нацелен на минимизацию времени разработки.
· Создание прототипа для уточнения требований заказчика.
· Цикличность разработки: каждая новая версия продукта основывается на оценке результата работы предыдущей версии заказчиком.
· Минимизация времени разработки версии, за счёт переноса уже готовых модулей и добавления функциональности в новую версию.
· Команда разработчиков должна тесно сотрудничать, каждый участник должен быть готов выполнять несколько обязанностей.
· Управление проектом должно минимизировать длительность цикла разработки.
Фазы разработки
Планирование - совокупность требований, полученных при системном планировании и анализе процедуры разработки жизненного цикла (SDLC). На этом этапе пользователи, менеджеры и IT-специалисты обсуждают задачи проекта, его объём, системные требования, а также сложности, которые могут возникнуть при разработке. Фаза завершается согласованием ключевых моментов с RAD-группой и получением от руководителей проекта разрешения на продолжение.
Пользовательское проектирование - на протяжении данного этапа пользователи, взаимодействуя с системными аналитиками, разрабатывают модели и прототипы, которые включают в себя все необходимые системные функции. Для перевода пользовательских прототипов в рабочие модели RAD-группа обычно использует технику объединенной разработки приложений (JAD) и CASE-инструменты. Пользовательское проектирование оказывается длительным интерактивным процессом, который позволяет пользователям понять, изменить и в конечном счете выбрать рабочую модель, отвечающую их требованиям.
Конструирование - этап, в котором основная задача заключается в разработке программ и приложений. Аналогична стадии "реализация" в SDLC. В RAD, однако, пользователи продолжают принимать участие и по-прежнему могут предлагать изменения или улучшения в виде разработанных ими докладов. В их задачи входит программирование и разработка приложений, написание кода, интеграция модулей и системное тестирование.
Переключение - включает в себя операции по конверсии данных, тестирование, переход на новую систему и тренировку пользователей. По своим задачам напоминает финальную стадию SDLC. Сравнивая с традиционными методами разработки ПО, весь процесс оказывается сжатым по времени. Как результат, новая система оказывается быстрее построенной, доставленной до заказчика и установленной на рабочих местах.
Преимущества
· быстрота продвижения программного продукта на рынок;
· интерфейс, устраивающий пользователя;
· легкая адаптируемость проекта к изменяющимся требованиям;
· простота развития функциональности системы.
Спиральная модель
Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.
Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации.
На каждой итерации оцениваются:
· риск превышения сроков и стоимости проекта;
· необходимость выполнения ещё одной итерации;
· степень полноты и точности понимания требований к системе;
· целесообразность прекращения проекта.
Боэм формулирует 10 наиболее распространённых (по приоритетам) рисков:
· Дефицит специалистов.
· Нереалистичные сроки и бюджет.
· Реализация несоответствующей функциональности.
· Разработка неправильного пользовательского интерфейса.
· Перфекционизм, ненужная оптимизация и оттачивание деталей.
· Непрекращающийся поток изменений.
· Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию.
· Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
· Недостаточная производительность получаемой системы.
· Разрыв в квалификации специалистов разных областей.
В сегодняшней спиральной модели определён следующий общий набор контрольных точек:
Concept of Operations (COO) — концепция (использования) системы;
Life Cycle Objectives (LCO) — цели и содержание жизненного цикла;
Life Cycle Architecture (LCA) — архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы;
Initial Operational Capability (IOC) — первая версия создаваемого продукта, пригодная для опытной эксплуатации;
Final Operational Capability (FOC) –— готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации.
_____________
матфак вгу и остальная классика =)