Тема 1. Процессы и модели разработки программных средств

Тема 1. Процессы и модели разработки
программных средств
Оглавление по теме
1.1. Понятие технологии конструирования программного обеспечения
1.1.1. Проблемы создания качественных компьютерных приложений:
1.1.2. Методы,
обеспечения
средства
и
процедуры
технологии
конструирования
программного
1.1.3. Типовые приемы конструирования пакетов программ сложной структуры
1.2. Модели разработки ПО
1.2.1. Стратегии конструирования ПО
1.2.2. Жизненный цикл программного обеспечения
1.2.3. Макетирование
1.2.4. Инкрементная модель
1.2.5. Быстрая разработка приложений (RAD)
1.2.6. Спиральная модель
1.2.7. Компонентно-ориентированная модель
1.3 Процессы разработки программного обеспечения
1.3.1. Упорядочивающие прогнозирующие процессы
1.3.2 Адаптируемость пакетов программ. Адаптивные процессы
1.4. Организация проектирования программного обеспечения
1.4.1. Этапы процесса руководства проектом
1.4.2. Планирование проектных задач
1.4.3. Предварительная оценка программного проекта
1.1. Понятие технологии конструирования
программного обеспечения
1.1.1. Проблемы создания качественных компьютерных
приложений
 ПО не использует потенциальные возможности аппаратуры;
 умение строить новые программы отстает от требований к программам;
 низкое качество разработки программ.
Ключ к решению этих проблем:
 грамотная организация процесса создания ПО;
 реализация технологических принципов промышленного конструирования
программных средств (ПС).
1.1.2. Методы, средства и процедуры технологии
конструирования программного обеспечения
1
Технология конструирования программного обеспечения (ТКПО)-система
инженерных принципов для создания экономичного ПО, которое надежно и
эффективно работает в реальных компьютерах.
Рис. 1. Технология конструирования программного обеспечения (ТКПО)
Различают: методы, средства и процедуры ТКПО.
Методы обеспечивают решение задач:






планирования и оценки проекта;
анализа системных и программных требований;
проектирования алгоритмов, структур данных и программных структур;
кодирования;
тестирования;
сопровождения.
Средства
(утилиты)
ТКПО
обеспечивают
автоматизированную
автоматическую поддержку методов с помощью CASE-систем.
или
CASE–система–Computer Aided Software Engineering (программная инженерия с
компьютерной поддержкой).
Процедуры–соединяют методы и средства в непрерывную технологическую
цепь разработки.
Процедуры определяют:
порядок применения методов и средств;
формирование отчетов в соответствии с требованиями;
контроль качества и координирование изменений;
формирование “вех” (промежуточных этапов) для оценки прогресса.
Таким образом, процесс конструирования ПО состоит из последовательности
шагов, использующих:




 методы;
 утилиты;
 процедуры.
Такие процессы называют парадигмами или моделями ТКПО.
1.1.3. Типовые приемы конструирования пакетов программ
сложной структуры
Анализ сложной системы
составляющие элементы.
требует
ее
2
декомпозиции
—
разбиения
на
Известны две схемы декомпозиции:
 алгоритмическая;
 объектно-ориентированная.
Алгоритмическая декомпозиция применяется в обычных ПС. В основе лежит
разбиение по действиям (алгоритмам).
Объектно-ориентированная — обеспечивает разбиение по автономным лицам
(объектам) реального (или виртуального) мира.
Лица (объекты) содержат в себе описания действий и описания данных.
1.2. Модели разработки ПО
1.2.1. Стратегии конструирования ПО
1. Однократный проход (водопадная стратегия)
2. Инкрементная стратегия
3. Эволюционная стратегия
Однократный проход (водопадная стратегия) — линейная последовательность
этапов конструирования;
Инкрементная
стратегия.
В
начале
процесса
определяются
все
пользовательские и системные требования, затем - создаются последовательности
версий.
Эволюционная стратегия. Система строится в виде последовательности версий,
но:
 в начале процесса определены не все требования;
 требования уточняются по мере разработки версий.
1.2.2. Жизненный цикл программного обеспечения
3
Рис. 2. Жизненный цикл ПО
Достоинства жизненного цикла (ЖЦ):
 дает план и временной график по всем этапам проекта;
 упорядочивает ход конструирования.
Недостатки ЖЦ:
 реальные проекты требуют отклонения от стандартной последовательности
шагов;
 цикл основан на точной формулировке исходных требований к ПО;
 результаты проекта доступны заказчику только в конце работы.
1.2.3. Макетирование
Макетирование (прототипирование) (рис. 3)— это процесс создания модели
требуемого программного продукта.
Модель может принимать одну из трех форм:
 бумажный макет или макет на основе ПК;
 работающий макет;
 существующая программа.
4
Рис. 3. Схема макетирования
Основная цель макетирования — снять неопределенности в требованиях
заказчика.
Достоинство макетирования:
 обеспечивает определение полных требований к ПО.
Недостатки макетирования:
 заказчик может принять макет за продукт;
 разработчик может принять макет за продукт.
1.2.4. Инкрементная модель
Инкрементный процесс итеративен, но в отличие
обеспечивает на каждом инкременте работающий продукт.
от
макетирования,
Рис. 4. Инкрементная модель
Современная
реализация
инкрементного
подхода
—
экстремальное
программирование (ХР) (Кент Бек, 1999). ХР ориентировано на очень малые
приращения функциональности.
1.2.5. Быстрая разработка приложений (RAD)
5
Rapid
Application
Development
информационных систем (ИС).
(RAD).
используется
при
разработке
В RAD выделяются следующие этапы (рис. 5):





бизнес-моделирование;
моделирование данных;
моделирование обработки;
генерация приложения с помощью средств автоматизации;
тестирование и объединение.
Рис. 5. Этапы быстрой разработки приложений
Недостатки и ограничения RAD:
1. Для больших проектов в RAD требуются существенные людские ресурсы.
2. RAD применима только для приложений, которые могут декомпозироваться
на отдельные модули и в которых производительность не является
критической величиной.
3. RAD не применима в условиях высоких технических рисков.
1.2.6. Спиральная модель
(автор: Барри Боэм, 1988)
Спиральная модель (рис. 6) основана на свойствах классического жизненного
цикла и макетирования, к которым добавляется анализ риска.
6
Рис. 6. Спиральная модель
Спиральная модель определяет четыре действия:
1. Планирование — определение целей, вариантов и ограничений.
2. Анализ риска — анализ вариантов и распознавание/выбор риска.
3. Конструирование — разработка продукта следующего уровня.
4. Оценивание — оценка заказчиком текущих результатов конструирования.
Достоинства спиральной модели:
наиболее реально отображает разработку программного обеспечения;
позволяет явно учитывать риск на каждом витке эволюции разработки;
включает шаг системного подхода в итерационную структуру разработки;
использует моделирование для уменьшения риска и совершенствования
программного изделия.
Недостатки спиральной модели:




 новизна (отсутствует достаточная статистика эффективности модели);
 повышенные требования к заказчику;
 трудности контроля и управления временем разработки.
1.2.7. Компонентно-ориентированная модель
Компонентно-ориентированная модель (рис. 7) является развитием спиральной
модели (рис. 6).
7
Рис. 7. Компонентно-ориентированная модель
Достоинства компонентно-ориентированной модели:
 уменьшает на 30% время разработки программного продукта;
 уменьшает стоимость программной разработки до 70%;
 увеличивает в полтора раза производительность разработки.
1.3. Процессы разработки программного
обеспечения
Процессы разработки программного обеспечения - строго упорядочивающие
тяжеловесные (heavyweight) или прогнозирующие (predictive) процессы. В них
прогнозируется весь объем предстоящих работ.
Процессы разработки программного обеспечения - группа новых, адаптивных,
облегченных (lightweight) или подвижных (agile) процессов.
1.3.1. Упорядочивающие прогнозирующие процессы
Прогнозирующий процесс—применяют при фиксированных требованиях и
многочисленной группе разработчиков разной квалификации. В этих процессах
прогнозируется весь объем предстоящих работ, поэтому они называются
прогнозирующими (predictive) процессами.
Порядок, который должен выполнять при этом человек-разработчик,
чрезвычайно строг. Иными словами, человеческие слабости в расчет не
8
принимаются, а объем необходимой документации способен отнять покой и сон у
"совестливого" разработчика.
В
основе
организации
прогнозирующих
(тяжеловесных)
процессов
конструирования лежит утверждение об экспоненциальной кривой стоимости
изменения. Согласно этой кривой, по мере развития проекта стоимость внесения
изменений экспоненциально возрастает — то, что на этапе формирования
требований стоит единицу, на этапе сопровождения будет стоить тысячу.
1.3.2. Адаптируемость пакетов программ. Адаптивные
процессы
Адаптивные
процессы
привлекательны
отсутствием
бюрократизма,
характерного для тяжеловесных (прогнозирующих) процессов. Новые процессы
должны воплотить в жизнь разумный компромисс между слишком строгой
дисциплиной и полным ее отсутствием. Иначе говоря, порядка в них достаточно
для того, чтобы получить разумную отдачу от разработчиков.
Подвижные
процессы
требуют
меньшего
объема
документации
и
ориентированы на человека. В них явно указано на необходимость использования
природных качеств человеческой натуры (а не на применение действий,
направленных наперекор этим качествам).
Более того, подвижные процессы учитывают особенности современного
заказчика, а именно частые изменения его требований к программному продукту.
Известно, что для прогнозирующих процессов частые изменения требований
подобны смерти.
В отличие от них, подвижные процессы адаптируют изменения требований и
даже выигрывают от этого. Словом, подвижные процессы имеют адаптивную
природу.
Адаптивный процесс используют при:
 частых изменениях требований;
 малочисленной группе квалифицированных разработчиков;
 грамотном заказчике, который участвует в разработке.
1.4. Организация проектирования программного
обеспечения
Организация проектирования программного обеспечения определяет сущность
процесса разработки от его начала до конца.
1.4.1. Этапы процесса руководства проектом
Рис. 8. Руководство программным проектом
9
Для проведения успешного проекта нужно оценить:
объем предстоящих работ;
возможный риск;
требуемые ресурсы;
предстоящие задачи;
промежуточные этапы;
необходимые усилия (стоимость);
план работ, которому необходимо следовать.
Руководство программным проектом:







 начинается перед технической работой;
 продолжается по мере развития ПО от идеи к реальности;
 достигает наивысшего уровня к концу работ.
Перед планированием проекта следует:
 установить цели и проблемную область проекта;
 обсудить альтернативные решения;
 выявить технические и управленческие ограничения.
1.4.2. Планирование проектных задач
При планировании программного проекта необходимо оценить:
 людские ресурсы (в человеко-месяцах);
 продолжительность (в календарных датах);
 стоимость.
Обычно исходят из прошлого опыта. Если новый проект по размеру и функциям
похож на предыдущий проект, потребуются примерно такие же ресурсы, время и
деньги.
Планирование:





определяется набор проектных задач;
устанавливаются связи между задачами;
оценивается сложность каждой задачи;
определяются людские и другие ресурсы;
создается сетевой график задач, проводится его временная разметка.
1.4.3. Предварительная оценка программного проекта
Измерения, меры и метрики
Измерения процесса производятся в целях его улучшения. Измерения продукта
производятся для повышения его качества.
В результате измерения определяется мера — количественная характеристика
опорного свойства объекта. Остальные свойства оцениваются в результате
вычисления функций от значений опорных характеристик. Вычисления этих
функций проводятся по формулам, дающим числовые значения и называемым
метриками.
В IEEE Standard Glossary of Software Engineering Terms метрика определена как
мера степени обладания свойством, имеющая числовое значение. В программной
инженерии понятия мера и метрика рассматривают как синонимы.
Процесс оценки. Анализ риска
10
Анализируется влияние неопределенности перед созданием программного
продукта на проект.
Определяется:
 нет ли скрытых от внимания трудных технических проблем?
 не станут ли изменения, проявившиеся в ходе проектирования, причиной
недопустимого отставания по срокам?
В результате принимается решение — выполнять проект или нет.
Трассировка и контроль
Каждая задача плана отслеживается руководителем проекта. При отставании
применяется повторное планирование. Определяется влияние отставания на
промежуточную веху и общее время конструирования.
Веха — временная метка, к которой привязано подведение промежуточных
итогов.
В результате повторного планирования могут быть:
 перераспределены ресурсы;
 реорганизованы задачи;
 пересмотрены выходные обязательства.
Планирование проектных задач
Основная задача при планировании — определение структуры распределения
работ.
Рис. 9. WBS — Work Breakdown Structure
Параллельность действий повышает требования к планированию, т. к.
параллельные задачи выполняются асинхронно, планировщик должен определить
межзадачные зависимости. Руководитель проекта должен знать задачи, лежащие
на критическом пути. Чтобы весь проект был выполнен в срок, необходимо
выполнять в срок все критические задачи.
11
Основной рычаг в планировании — вычисление границ времени выполнения
задачи:
1. Раннее время начала решения задачи Tin min при условии, что все
предыдущие задачи решены в кратчайшее время.
2. Позднее время начала решения задачи Tin max (еще не вызывает общей
задержки проекта).
3. Раннее время конца решения задачи Tout min.
4. Позднее время конца решения задачи Tout max.
5. Общий резерв — количество избытков и потерь планирования задач во
времени, не приводящих к увеличению длительности критического пути.
Рекомендуемое правило распределения затрат проекта:
 на
анализ и проектирование приходится
планирование и системный анализ — 5%);
 на кодирование — 20%;
 на тестирование и отладку — 40%.
12
40%
затрат
(из
них
на