- •Фундаментальные основы конструирования программного обеспечения
- •2. Минимизация сложности программного обеспечения
- •3. Ожидание изменений в программном обеспечении как фактор, влияющий на конструирование по
- •4. Конструирование по с возможностью проверки
- •7 Планирование конструирования (Construction Planning)
- •8 Измерения в конструировании (Construction Measurement)
- •9 Проектирование в конструировании (Construction Design)
- •10 Языки конструирования (Construction Languages)
- •13 Повторное использование по (Reuse)
- •18 Определение дисциплины программная инженерия
- •19 Состав коллективов при создании больших программных проектов
- •20. Основы программных требований
- •21 Инженерия требований к по
- •22 Управление требованиями к по
- •23 Выявление требований
- •24. Анализ требований
- •26 Валидация требований к по
- •27 Управление требованиями
- •28 Определение термина Проектирование по (Software design)
- •29 Базовые концепции проектирования по
- •30 Базовые элементы Архитектуры по
- •31 Анализ и оценка качества проектирования по
- •32 Нотации проектирования
- •33. Определение термина «Конструирование по»
- •34 Виды тестирования по
- •35 Техники тестирования по
- •36 Управление тестированием по
- •37 Измерение результатов тестирования.
- •38 Сопровождение по (Software maintenance)
- •39 Основные концепции сопровождения по
- •40 Эволюция по.
- •41 Управление конфигурацией по (Software Configuration Management–
- •42 Управление инженерией по (Software Engineering Management)
- •43 Организационное управление инженерией по
- •44 Процесс управления проектом разработки по
- •45 Управление рисками при разработке программного проекта
- •47 Процесс инженерии по (Software Engineering Process)
- •48 Инфраструктура процесса разработки по
- •49 Определение процесса разработки по
- •50 Оценка процесса разработки по
- •51 Модели жизненного цикла при разработке программных систем
- •52 Каскадная модель жц
- •53 Инкрементная модель жц
- •54 Спиральная модель
- •55 Эволюционная модель жц
- •56 Стандартизованная модель системы
- •57 Основные процесс стандарта iso/iec 12207
- •58 Вспомогательные процессы стандарта iso/iec 12207
- •59 Организационные процессы стандарта iso/iec 12207
- •60 Характеристика модели процессов в ядре swebok
52 Каскадная модель жц
Одной из первых начала применяться каскадная или водопадная модель, в которой
каждая работа выполняется один раз и в том порядке, как они представлены в схеме
модели ЖЦ. Т.е. делается предположение, что каждая работа будет выполнена
настолько тщательно, что после ее завершения и перехода к следующему этапу
возвращения к предыдущему не потребуется. Разработчик проверяет промежуточный
результат разными известными методами верификации и фиксирует его в качестве готового эталона для следующего этапа
53 Инкрементная модель жц
Эту заложена еще называют нарастающей моделью, суть которой состоит в
возможности усовершенствования продукта. Разработка начинается с
предоставления набора требований и реализации системы путем последовательного
конструирования и фиксации промежуточных продуктов (1, …, N) системы,
постепенно приближающейся к итоговой системе.
Первая создаваемая промежуточная структура системы реализует часть требований, в
последующую структуру добавляют дополнительные требования и так до тех пор,
пока не будет окончательно согласованы требования и соответственно разработка
продукта системы. Над каждой промежуточной структурой выполняются
необходимые процессы, работы и задачи, например, анализ требований и создание 52
архитектуры могут быть выполнены одновременно. Процессы разработки
технического проекта ПС, его программирование и тестирование, сборка и
квалификационные испытания ПС выполняются при создании каждой последующей
структуре.
Данную модель разработки целесообразно использовать, в случае когда:
– желательно реализовать некоторые возможности системы быстро за счет создания
промежуточного продукта;
– система разделена на отдельные составные части структуры, которые можно
представлять как некоторый промежуточный продукт;
– возможно увеличение финансирования на разработку отдельных частей системы.
54 Спиральная модель
Исходя из возможности внесения изменений как в процесс, так и в создаваемый
промежуточный продукт была создана спиральная модель.
.
Данная модель ЖЦ допускает анализ продута на витке разработки, его проверку,
оценку его правильности и принятия решения двигаться на следующий виток или
опуститься на нижний для доработки.
Отличие этой модели от каскадной модели состоит в возможности спиральной модели
обеспечивать многоразовое возвращение к процессу формулирования требований и к
повторной разработке с любого процесса выполнения работ. 54
На изображенной спиральной модели (рис.2.3), каждый виток спирали соответствует
одной из версий разработки системы. При необходимости внесения изменений в
систему на каждом процессе витка для получения версии системы, обязательно
вносятся изменения в предварительно зафиксированные требования, после чего
происходит возврат на предыдущий виток спирали для продолжения реализации
новой версии системы с учетом изменений.
55 Эволюционная модель жц
В случае эволюционной модели система разрабатывается в виде последовательности
блоков структур (конструкций). В отличие от инкрементной модели ЖЦ,
подразумевается, что требования устанавливаются частично и уточняются в каждом
последующем промежуточном блоке структуры системы
Работы и задачи процесса разработки в соответствии с данной моделью выполняются
не однократно, но в той же последовательности, что для всех блоков структуры.
Так как промежуточные блоки структуры соответствуют реализации некоторых
требований, то соответственно их реализацию можно проверять на процессе
сопровождения и эксплуатации, т.е. параллельно с процессом разработки блоков
структуры системы. При этом вспомогательные и организационные процессы могут 55
выполняться параллельно с процессом разработки и накапливать сведения по данным
количественных и качественных оценок на процессах разработки.
Преимущества применения данной модели ЖЦ состоит в следующем:
– проведение быстрой реализация некоторых возможностей системы;
– промежуточный продукт может использоваться на следующем процессе;
– в системе выделяются отдельные части для реализации их в отдельности;
– возможность увеличения финансирования системы;
– обратная связь устанавливается с заказчиком для уточнения требований;
– упрощение внесения изменений.
.