курсовая работа. Учебное пособие по дисциплине технология разработки программного обеспечения специальность Программирование в компьютерных системах
 Скачать 7.57 Mb.
|
2. Стратегии конструирования ПОСуществуют 3 стратегии конструирования ПО. водопадная стратегия(однократный проход) — линейная последовательность этапов конструирования; инкрементная стратегия. В начале процесса определяются все пользовательские и системные требования, оставшаяся часть конструирования выполняется в виде последовательности версий. Первая версия реализует часть запланированных возможностей, следующая версия реализует дополнительные возможности и т. д., пока не будет получена полная система; эволюционная стратегия. Система также строится в виде последовательности версий, но в начале процесса определены не все требования. Требования уточняются в результате разработки версий. Характеристики стратегий конструирования программного обеспечения в соответствии с требованиями стандарта IEEE/EIA 12207.2 приведены в табл. 1. Таблица 1 - Характеристики стратегий конструирования
3. Модели конструирования3.1 Инкрементная модель Инкрементная модель является классическим примером инкрементной стратегии конструирования (рис.4). Она объединяет элементы последовательной водопадной модели с итерационной философией макетирования. Поставка 1-й инкремент 1-го инкремента  Поставка 2-й инкремент 2-го инкремента  Поставка 3-й инкремент 3-го инкремента  Рис.4. Инкрементная модель Каждая линейная последовательность здесь вырабатывает поставляемый инкремент ПО. Например, ПО для обработки слов в 1-м инкременте реализует функции базовой обработки файлов, функции редактирования и документирования; во 2-м инкременте — более сложные возможности редактирования и документирования; в 3-м инкременте — проверку орфографии и грамматики; в 4-м инкременте — возможности компоновки страницы. Первый инкремент приводит к получению базового продукта, реализующего базовые требования (правда, многие вспомогательные требования остаются нереализованными). План следующего инкремента предусматривает модификацию базового продукта, обеспечивающую дополнительные характеристики и функциональность По своей природе инкрементный процесс итеративен, но, в отличие от макетирования, инкрементная модель обеспечивает на каждом инкременте работающий продукт. 3.2 Модель RAD - Быстрая разработка приложений Модель быстрой разработки приложении (Rapid Application Development) — второй пример применения инкрементной стратегии конструирования (рис. 5). 2-я группа  1-я группа   60-90 дней Рис.5. Модель быстрой разработки приложений RAD-модель обеспечивает экстремально короткий цикл разработки. RAD — высокоскоростная адаптация линейной последовательной модели, в которой быстрая разработка достигается за счет использования компонентно-ориентированного конструирования. Если требования полностью определены, а проектная область ограничена, RAD-процесс позволяет группе создать полностью функциональную систему за очень короткое время (60-90 дней). RAD- подход ориентирован на разработку информационных систем и выделяет следующие этапы: бизнес-моделирование. Моделируется информационный поток между бизнес - функциями. Ищется ответ на следующие вопросы: Какая информация руководит бизнес процессом? Какая генерируется информация? Кто генерирует ее? Где информация применяется? Кто обрабатывает ее? моделирование данных. Информационный поток, определенный на этапе бизнес моделирования, отображается в набор объектов данных, которые требуются для поддержки бизнеса. Идентифицируются характеристики (свойства, атрибуты) каждого объекта, определяются отношения между объектами; моделирование обработки. Определяются преобразования объектов данных, обеспечивающие реализацию бизнес функций. Создаются описания обработки для добавления, модификации, удаления или нахождения (исправления) объектов данных; генерация приложения. Предполагается использование методов, ориентированных на языки программирования 4-го поколения. Вместо создания ПО с помощью языков программирования 3-го поколения, RAD-процесс работает с повторно используемыми программными компонентами или создает повторно-используемые компоненты. Для обеспечения конструирования используются утилиты автоматизации; тестирование и объединение. Поскольку применяются повторно используемые компоненты, многие программные элементы уже протестированы. Это уменьшает время тестирования (хотя все новые элементы должны быть протестированы). Применение RAD возможно в том случае, когда каждая главная функция может быть завершена за 3 месяца. Каждая главная функция адресуется отдельной группе разработчиков, а затем интегрируется в целую систему. Применение RAD имеет и свои недостатки, и ограничения. Для больших проектов в RAD требуются существенные людские ресурсы (необходимо создать достаточное количество групп). RAD применима только для таких приложений, которые могут декомпозироваться на отдельные модули и в которых производительность не является критической величиной. RAD не применима в условиях высоких технических рисков (то есть при использовании новой технологии). 3.3 Спиральная модельСпиральная модель — классический пример применения эволюционной стратегии конструирования. Спиральная модель (автор Барри Боэм, 1988) базируется на лучших свойствах классического жизненного цикла и макетирования, к которым добавляется новый элемент — анализ риска, отсутствующий в этих парадигмах. Как показано на рис.6, модель определяет четыре действия, представляемые четырьмя квадрантами спирали. Планирование – определение целей, вариантов и ограничений. Анализ риска – анализ вариантов и распознавание/выбор риска. Конструирование — разработка продукта следующего уровня. Оценивание — оценка заказчиком текущих результатов конструирования. Интегрирующий аспект спиральной модели очевиден при учете радиального измерения спирали. С каждой итерацией по спирали (продвижением от центра к периферии) строятся все более полные версии ПО. В первом витке спирали определяются начальные цели, варианты и ограничения, распознается и анализируется риск. Если анализ риска показывает неопределенность требований, на помощь разработчику и заказчику приходит макетирование (используемое в квадранте конструирования). Для дальнейшего определения проблемных и уточненных требований может быть использовано моделирование. Заказчик оценивает инженерную (конструкторскую) работу и вносит предложения по модификации (квадрант оценки заказчиком). Следующая фаза планирования и анализа риска базируется на предложениях заказчика. В каждом цикле по спирали результаты анализа риска формируются в виде «продолжать, не продолжать». Если риск слишком велик, проект может быть остановлен.              Рис. 6. Спиральная модель: 1 – начальный сбор требований и планирование проектов; 2 – та же работа, но на основе рекомендаций заказчика; 3 – анализ риска на основе начальных требований; 4 – анализ риска на основе реакции заказчика; 5 – переход к комплексной системе; 6 – начальный макет системы; 7 – следующий уровень макета; 8 – сконструированная система; 9 – оценивание заказчиком. В большинстве случаев движение по спирали продолжается, с каждым шагом продвигая разработчиков к более общей модели системы. В каждом цикле по спирали требуется конструирование (нижний правый квадрант), которое может быть реализовано классическим жизненным циклом или макетированием. Заметим, что количество действий по разработке (происходящих в правом нижнем квадранте) возрастает по мере продвижения от центра спирали. Достоинства спиральной модели: наиболее реально (в виде эволюции) отображает разработку программного обеспечения; позволяет явно учитывать риск на каждом витке эволюции разработки; включает шаг системного подхода в итерационную структуру разработки; использует моделирование для уменьшения риска и совершенствования программного изделия. Недостатки спиральной модели: новизна (отсутствует достаточная статистика эффективности модели); повышенные требования к заказчику; трудности контроля и управления временем разработки. |