- •Введение
- •Содержание
- •1.1 Анализ и характеристика областей знаний swebok
- •1.1.1. Требования к по (Software Requirements)
- •1.1.2. Проектирование по (Software design)
- •1.1.3. Конструирование по (Software Construction)
- •1.1.4. Тестирование по (Software Testing)
- •1.1.5. Сопровождение по (Software maintenance)
- •1.1.6. Управление конфигурацией по
- •1.1.7. Управление инженерией по
- •1.1.8. Процесс инженерии по (Software Engineering Process)
- •1.1.9. Методы и инструменты инженерии по
- •1.1.10. Качество по (Software Quality)
- •1.2. Жизненный цикл пс, связь с ядром знаний swebok
- •Контрольные вопросы и задания
- •Лекция 2: Модели жизненного цикла для разработки программных систем Содержание
- •2.1. Процессы жц стандарта iso/iec 12207
- •2.2. Типы моделей жц
- •2.2.1. Каскадная модель жц
- •2.2.2. Инкрементная модель жц
- •2.2.3. Спиральная модель
- •2.2.5. Стандартизация модели жц
- •2.3. Сопоставление жц стандарта iso/iec 12207 и областей swebok
- •2.3.1. Характеристика процессов стандарта iso/iec 12207
- •2.3.2. Характеристика областей знаний swebok
- •Контрольные вопросы и задания
- •Лекция 3: Методы определения требований в программной инженерии Содержание
- •3.1. Общие подходы к определению требований
- •3.1.1. Классификация требований
- •3.1.2. Анализ и сбор требований
- •3.1.3. Инженерия требований
- •3.1.4. Фиксация требований
- •3.1.5. Трассировка требований
- •Сложность программного обеспечения
- •1.8.1. Каскадная (водопадная) модель
- •1.8.2. Итеративная и инкрементальная модель
- •1.8.3. Спиральная модель Боэма
- •1.9.1. Методология Rational Unified Process (rup)
- •2. Проектирование (Elaboration)
- •3. Построение (Construction)
- •4. Внедрение (Transition)
- •1.9.2. Экстремальное программирование
- •Живое планирование (planning game)
- •Программирование парами (pair programming)
- •Включение заказчика в команду (on-site customer)
- •Использование кода как средства коммуникации
- •Открытое рабочее пространство (open workspace)
- •Изменение правил по необходимости (just rules)
1.8.1. Каскадная (водопадная) модель
Каскадная модель предполагает однократное, строго последовательное во времени выполнение всех фаз проекта с детальным предварительным планированием при однократно определенных требованиях к системе.
На рисунке 1.1 изображены типичные фазы каскадной модели ЖЦ программного продукта. Охарактеризуем содержание основных фаз.
Рисунок 1.1. - Каскадная модель жизненного цикла ПО
Подразумевается, что разработка начинается на системном уровне и проходит через анализ, проектирование, кодирование, тестирование и сопровождение.
Системный анализ задает роль каждого элемента в компьютерной системе, взаимодействие элементов друг с другом. Поскольку ПО является лишь частью большой системы, то анализ начинается с определения требований ко всем системным элементам и назначения подмножества этих требований программному «элементу». Необходимость системного подхода явно проявляется, когда формируется интерфейс ПО с другими элементами (аппаратурой, людьми, базами данных). На этом же этапе начинается решение задачи планирования проекта, определяются объем проектных работ и их риск, необходимые трудозатраты, формируются рабочие задачи и план-график работ.
Анализ требований относится к программному элементу - программному обеспечению. Уточняются и детализируются его функции, характеристики и интерфейс. Все определения документируются в спецификации анализа. Здесь же завершается решение задачи планирования проекта.
Проектирование состоит в создании:
архитектуры ПО;
модульной структуры ПО;
алгоритмической структуры ПО;
структуры данных;
входного и выходного интерфейса (входных и выходных форм данных).
Исходные данные для проектирования содержатся в спецификации анализа, то есть в ходе проектирования выполняется трансляция требований к ПО во множество проектных представлений. При решении задач проектирования основное внимание уделяется качеству будущего программного продукта.
Кодирование состоит в переводе результатов проектирования в текст на языке программирования.
Тестирование — выполнение программы для выявления дефектов в функциях, логике и форме реализации программного продукта.
Сопровождение — это внесение изменений в эксплуатируемое ПО. Цели изменений:
исправление ошибок;
адаптация к изменениям внешней для ПО среды;
усовершенствование ПО по требованиям заказчика.
Достоинства каскадной модели: дает план и временной график по всем этапам проекта, упорядочивает ход конструирования.
Недостаток этой модели состоит в том, что проект проходит через весь процесс только один раз, предполагая, что все ошибки будут сосредоточены в реализации и устранены при тестировании. Неточность какого-нибудь требования или некорректная его интерпретация, изменение потребностей заказчика приводит к тому, что вся работа начинается сначала и затраты на разработку резко возрастают.
Практика показывает, что в реальном мире, особенно в мире бизнес-систем, каскадная модель не должна применяться.
1.8.2. Итеративная и инкрементальная модель
В соответствии с итеративной и инкрементальной моделью (рис. 1.2) имеются четыре основные фазы жизненного цикла разработки ПО: начало, исследование, построение и внедрение. На каждой фазе проект проходит множество итераций, приводящих к созданию работоспособных версий: на начальных создаются прототипы, уточняются требования, прорабатываются наиболее сложные проблемы; конечные приводят к созданию продукта, его совершенствованию и расширению функциональности.
Рисунок 1.2. - Итеративная модель предлагает использование итераций на всех этапах жизненного цикла
Каждая итерация – это мини-проект, включающий все фазы ЖЦ в применении к созданию меньших фрагментов функциональности по сравнению с проектом в целом. Цель каждой итерации – получение работающей версии программной системы, включающей функциональность, определенную содержанием всех предыдущих и текущей итерации. Результат последней итерации содержит всю требуемую функциональность продукта.
Таким образом, с точки зрения структуры ЖЦ модель является итеративной, а инкрементальной она называется потому, что с завершением каждой итерации программный продукт развивается инкрементально, т.е. наращивается его функциональность. Такую модель еще называют эволюционной.
Итеративная модель дает возможность успешно справляться с рисками. Если во время работы над очередной версией будет установлено, что трудозатраты на реализацию необходимой функциональности слишком велики, то превышения бюджета и нарушения сроков можно будет избежать путем соотнесения приоритетов разработки и трудозатрат в начале каждой итерации. Таким образом, данная модель хорошо подходит для большинства типов программных проектов, но особенно ее преимущества заметны при работе над продуктами, предназначенными для выхода на свободный рынок, в силу изначальной ориентации на выпуск последовательных версий.
Наиболее известным и распространенным вариантом эволюционной модели является спиральная модель.
