Главная страница
Навигация по странице:

  • 3.1 Инкрементная модель

  • курсовая работа. Учебное пособие по дисциплине технология разработки программного обеспечения специальность Программирование в компьютерных системах


    Скачать 7.57 Mb.
    НазваниеУчебное пособие по дисциплине технология разработки программного обеспечения специальность Программирование в компьютерных системах
    Анкоркурсовая работа
    Дата08.01.2023
    Размер7.57 Mb.
    Формат файлаdoc
    Имя файла2_5397965015586183048-7.doc
    ТипУчебное пособие
    #877236
    страница5 из 30
    1   2   3   4   5   6   7   8   9   ...   30

    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 имеет и свои недостатки, и ограничения.

    1. Для больших проектов в RAD требуются существенные людские ресурсы (необходимо создать достаточное количество групп).

    2. RAD применима только для таких приложений, которые могут декомпозироваться на отдельные модули и в которых производительность не является критической величиной.

    3. RAD не применима в условиях высоких технических рисков (то есть при использовании новой технологии).
    3.3 Спиральная модель


    Спиральная модель — классический пример применения эволюционной стратегии конструирования. Спиральная модель (автор Барри Боэм, 1988) базируется на лучших свойствах классического жизненного цикла и макетирования, к которым добавляется новый элемент — анализ риска, отсутствующий в этих парадигмах.

    Как показано на рис.6, модель определяет четыре действия, представляемые четырьмя квадрантами спирали.

    1. Планирование – определение целей, вариантов и ограничений.

    2. Анализ риска – анализ вариантов и распознавание/выбор риска.

    3. Конструирование — разработка продукта следующего уровня.

    4. Оценивание — оценка заказчиком текущих результатов конструирования.

    Интегрирующий аспект спиральной модели очевиден при учете радиального измерения спирали. С каждой итерацией по спирали (продвижением от центра к периферии) строятся все более полные версии ПО. В первом витке спирали определяются начальные цели, варианты и ограничения, распознается и анализируется риск. Если анализ риска показывает неопределенность требований, на помощь разработчику и заказчику приходит макетирование (используемое в квадранте конструирования). Для дальнейшего определения проблемных и уточненных требований может быть использовано моделирование. Заказчик оценивает инженерную (конструкторскую) работу и вносит предложения по модификации (квадрант оценки заказчиком). Следующая фаза планирования и анализа риска базируется на предложениях заказчика. В каждом цикле по спирали результаты анализа риска формируются в виде «продолжать, не продолжать». Если риск слишком велик, проект может быть остановлен.



    Рис. 6. Спиральная модель:

    1 – начальный сбор требований и планирование проектов; 2 – та же работа, но на основе рекомендаций заказчика; 3 – анализ риска на основе начальных требований; 4 – анализ риска на основе реакции заказчика; 5 – переход к комплексной системе; 6 – начальный макет системы; 7 – следующий уровень макета; 8 – сконструированная система; 9 – оценивание заказчиком.

    В большинстве случаев движение по спирали продолжается, с каждым шагом продвигая разработчиков к более общей модели системы. В каждом цикле по спирали требуется конструирование (нижний правый квадрант), которое может быть реализовано классическим жизненным циклом или макетированием. Заметим, что количество действий по разработке (происходящих в правом нижнем квадранте) возрастает по мере продвижения от центра спирали.

    Достоинства спиральной модели:

    1. наиболее реально (в виде эволюции) отображает разработку программного обеспечения;

    2. позволяет явно учитывать риск на каждом витке эволюции разработки;

    3. включает шаг системного подхода в итерационную структуру разработки;

    4. использует моделирование для уменьшения риска и совершенствования программного изделия.

    Недостатки спиральной модели:

    1. новизна (отсутствует достаточная статистика эффективности модели);

    2. повышенные требования к заказчику;

    3. трудности контроля и управления временем разработки.
      1. 1   2   3   4   5   6   7   8   9   ...   30


    написать администратору сайта