Для анализа проекта используются контрольные точки и вехи. Контрольная точка - событие в ЖЦ для проверки выполненной и оценки оставшейся работы по проекту. Моментами времени для контрольных точек часто выступают границы стадий. Веха - событие ЖЦ для обозначения завершения произведённого результата или их набора. Вехи часто используются в качестве контрольных точек.

Вследствие итерационного выполнения работ получаемые результаты постепенно улучшаются до целевых результатов, диктуемых заданными требованиями, которые также могут изменяться. Итерация - ограниченная во времени повторяемая часть проекта. Итерацией может выступать весь цикл разработки или его часть, что определяется их длительностью и моделью ЖЦ. В этом случае итерация цикла разработки называется макро-итерацией или просто циклом, итерация стадии - просто итерацией, а итерация этапа - микро-итерацией.

Для управляемого выполнения отдельных задач используются таймбоксы. Таймбокс (букв. временной ящик) - небольшой промежуток времени для выполнения конкретной задачи и произведения её результатов. Таймбокс характеризуется жёстко заданными временными рамками. Рамки нужно соблюсти, даже если придётся выдать не вполне завершённые результаты. Иначе задача считается проваленной и приходится или отказаться от неё, или запланировать её повторно.

Таким образом, описание измерений технологии корректируется следующим образом. Вертикальное измерение оперирует также такими понятиями, как произведённые результаты (артефакты, рабочие продукты) и исполнители (роли и ответственности). Горизонтальное измерение оперирует также такими понятиями, как контрольные точки и вехи, итерации и таймбоксы. Однако эти понятия можно рассматривать и как характеристику нового, третьего измерения. Это измерение оказывается связанным с формализацией, необходимой для управления проектом.

Существует два основных набора технологических процессов. Классический набор - совокупность основных процессов, сложившихся исторически в результате практического опыта разработки ПО. Стандартный набор - совокупность процессов из ISO/IEC 12207:1999 «Информационная технология - Процессы жизненного цикла ПО». Процессы классического набора фактически являются подмножеством стандартного, выступая там как процессы или действия процессов. Классический набор включает 9 процессов: 1. Исследование; 2. Управление; 3. Анализ; 4. Проектирование; 5. Кодирование; 6. Тестирование; 7. Ввод в действие; 8. Сопровождение; 9. Снятие с эксплуатации. Стандартный набор включает 3 группы процессов: основные, вспомогательные и организационные процессы.

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

Попроцессное формирование стадий обычно используют для классических процессов (или их под- или надмножества). В подходах с этой классификацией обычно выделяют 9 стадий: 1. Исследование идеи; 2. Планирование; 3. Анализ требований; 4. Проектирование; 5. Кодирование; 6. Тестирование и отладка; 7. Ввод в действие; 8. Эксплуатация и сопровождение; 9. Снятие с эксплуатации.

Пофазное формирование стадий обычно используют для стандартных процессов (или их под- или надмножества). В большинстве подходов с этой классификацией выделяют 4 основные фазы: 1. Начало; 2. Середина; 3. Кульминация; 4. Переход. В ряде подходов выделяют 2 дополнительные фазы: 5. Работа; 6. Окончание.

Классификация подходов тесно связана с характеристиками выполняемых проектов. По каждому признаку классификации проектов можно выделить множество проектов, для которых будут указаны только граничные значения. По масштабу, определяющему количество исполнителей и протяжённость (время выполнения) проекта, выделяют 5 категорий проектов (табл.5.1).

Табл. 5.1. Категории проектов

Категория	Число исполнителей	Протяжённость проекта
мелкий	от 1 до 3	от 1 часа до 2 месяцев
малый	от 3 до 10	от 2 до 6 месяцев
средний	от 10 до 30	от 6 месяцев до 1 года
крупный	от 30 до 100	от 1 года до 2 лет
гигантский	от 100 до 300 и более	от 2 до 6 лет и более

В настоящее время выделяют два класса подходов. Строгие (тж. тяжёлые, жёсткие) подходы ориентированы в основном на применение в средних, крупных и гигантских проектах с фиксированным объёмом работ. Поэтому основное требование к таким проектам - предсказуемость. Гибкие (тж. лёгкие, живые) подходы ориентированы в основном на применение в мелких, малых или средних проектах в случае неясных или изменяющихся требований к системе. Поэтому основное требование к таким проектам - непосредственное участие заказчика в проекте. Для большинства гибких подходов важным является требование адаптируемости.

Внутри классов подходов принято условно выделять группы подходов с рядом принципов, общих для этих подходов. К классу строгих подходов относят каскадные, каркасные, генетические и формальные подходы, к классу гибких - эволюционные и адаптивные подходы.

Контрольные вопросы

1. Дайте определение понятиям «жизненный цикл ПО» и «модель ЖЦ».

2. Дайте определение понятию «технология» («технологический подход»).

3. Дайте определение понятию «действие». Какие наборы действий выделяют?

4. Дайте определение понятиям, связанным с процессом.

5. Дайте определение понятиям «дисциплина», «поток работ» и «процедура».

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

7. Дайте определение понятиям «методика» и «практика».

8. Перечислите ограничения проекта. Как они связаны с подходом разработки?

9. Дайте определение понятиям, связанным с формализацией разработки.

10. Перечислите и поясните основные наборы технологических процессов.

11. Приведите классические технологические процессы.

12. Приведите группы стандартных технологических процессов.

13. Перечислите и поясните виды формирования технологических стадий.

14. Приведите классические стадии и фазы.

15. Перечислите категории проектов по масштабу.

16. Перечислите классы и группы технологических подходов.

Лекция 6

Тема лекции: Технология разработки ПО (продолжение)

Основное содержание

Основными моделями ЖЦ ПО считаются: Каскадная модель, Итеративная инкрементная модель, Эволюционная модель и Спиральная модель.

Непланируемая модель или модель «кодирование - исправление» является самой простой моделью ЖЦ ПО. Принцип модели (рис.6.1) заключается в написании кода программы без какого-либо серьёзного предварительного анализа требований и проектирования, запусках программы для проверки его работоспособности и последующем исправлении ошибок и/или добавлении функциональности до получения варианта программы, удовлетворяющего пользователя.

Рис.6.1. Непланируемая модель

Классическая каскадная модель или модель водопада создана по аналогии с методиками из других инженерных областей, где существует практика поэтапного создания продукта от составления спецификаций до поставки заказчику. Принцип модели (рис.6.2) заключается в однократном выполнении процессов в виде заранее ограниченных и однозначно упорядоченных во времени стадий, осуществляемых как бы в их естественных границах. Все процессы, действия, задачи выполняются чётко последовательно, не допускается никаких перекрытий, параллелизма и возвратов назад. Это жёсткое ограничение делает такую модель практически нереализуемой, так как на уже законченных стадиях не допустимы никакие ошибки, что требует получения артефактов идеального качества.

Рис.6.2. Классическая каскадная модель

На практике применяются каскадные модели без учёта этих ограничений.

Модифицированная каскадная модель или модель водоворота является простейшим случаем таких моделей. Принцип модели (рис.6.3) заключается в возможности возвращения на предыдущую стадию в случае нахождения ошибки на текущей стадии и пересмотре или уточнении ранее принятых решений.



Рис.6.3. Модифицированная каскадная модель

Прототипируемая модель или модель прототипирования создана для решения проблем при разработке в условиях неопределённости исходных требований путём разработки прототипов требуемого продукта. Модель требует быстрого построения множества прототипов, поэтому реализация этой модели возможна только при использовании соответствующего инструментария автоматизации.

Классическая модель прототипирования использует разработку прототипов для постепенного выявления всех требований. Принцип модели (рис.6.4) заключается в первоначальной разработке сильно упрощённого прототипа, который в соответствии с пожеланиями пользователя циклически усовершенствуется и усложняется до тех пор, пока требования к ПО не становятся очевидными. После этого выполняется формализация выявленных требований (составляется спецификация) и ведётся собственно разработка продукта по какой-либо модели. Разработка прототипа и продукта рассматривается как отдельная итерация ЖЦ ПО.



Рис.6.4. Классическая модель прототипирования

Модификацией классической модели прототипирования является модель одноразового прототипирования. Принцип этой модели заключается в том, что начальный прототип является одноразовым.

Благодаря прототипированию реализованные требования к ПО приближаются к целевым требованиям и снижаются неопределённости разработки (усилия, стоимости, сроки) вплоть до получения конечного продукта. В целом проекты с моделями прототипирования обычно завершаются на 40% раньше аналогичных проектов с каскадными моделями, а код получается на 45% более коротким. Однако этот код обычно оказывается более запутанным и сложным для сопровождения, а документация - не столь полной и качественной.

Итеративная инкрементная модель или модель запланированного усовершенствования продукта использует разработку прототипов (выпусков) для последовательной реализации групп требований. Принцип модели (рис.6.5) заключается в предварительном выделении требований и разработке прототипов, по функциональности всё более приближающихся к продукту. Первый прототип-выпуск основывается на наиболее понятной группе требований, в последующие реализации добавляются всё новые группы требований, пока не будет закончено создание продукта. Для каждого прототипа выполняются необходимые процессы, причём анализ требований и проектирование архитектуры выполняются одновременно, а остальные процессы - индивидуально для каждого прототипа.

Рис.6.5. Итеративная инкрементная модель

Рассматриваемая модель в явном виде включает в своё название два принципа, характерные в том или ином виде для многих моделей прототипирования: итеративность и инкрементность разработки. Итеративность означает разбиение ЖЦ на последовательность итераций, каждая из которых напоминает мини-проект. Цель каждой итерации - разработка прототипа, результатом последней итерации является продукт. Инкрементность означает разработку продукта путём постепенного учёта требований к системе. Фактически это также приводит к разработке прототипов, причём последний (часто лишь по срокам) прототип считается продуктом.

Эволюционная модель использует разработку прототипов (версий) для реализации частично установленных требований при последовательном уточнении и расширении этих требований. Принцип модели (рис.6.6) заключается в постепенной формулировке требований и разработке прототипов, по требованиям всё более приближающихся к продукту. Первый прототип-версия основывается на наиболее сложной и непонятной группе требований, в последующих версиях эти требования уточняются и расширяются с учётом разработки ранних версий.

Рис.6.6. Эволюционная модель

Рассматриваемая модель в явном виде включает в своё название принцип, характерный для ряда моделей прототипирования: эволюционность разработки. Эволюционность означает разработку продукта путём включения и доработки реализации требований по мере их прояснения.

Спиральная модель является результатом анализа и адаптации известных моделей: непланируемой, каскадной и прототипируемой. Модель получила своё название из-за графического представления в виде спирали, проходящей через 4 стадии разработки (рис.6.7). Каждое их прохождение есть фаза разработки.



Рис.6.7. Спиральная модель в упрощённом виде

Классическая спиральная модель впервые сформулирована Б.У. Боэмом в 1988 г. Поэтому её также называют модель Боэма.

Рис.6.8. Классическая спиральная модель

В графическом представлении модели используются полярные координаты (рис.6.8). При этом в заданный момент времени полярный угол соответствует успешности выполняемого проекта, а полярный радиус, точнее удаление по нему от полюса,- совокупной стоимости разработки.

Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию ЖЦ. Риск - это некоторое событие или обстоятельство, препятствующее нормальному достижению цели проекта. Большая часть рисков связана с организационными и процессными аспектами взаимодействия специалистов в команде.

Принцип модели (рис.6.8) заключается в разработке ПО путём прототипирования за несколько витков спирали, именуемых итерациями, циклами, фазами. Каждая итерация состоит из 4 стадий: 1. Определение целей, альтернатив и ограничений; 2. Анализ и проверка альтернатив, идентификация и разрешение рисков; 3. Разработка продукта следующего уровня; 4. Планирование следующей итерации (очередного цикла).

Каждый процесс или группа процессов разработки в рамках итерации предваряются анализом рисков и завершаются проверкой.

В 2000 г. Боэм на основе опыта использования спиральной модели сформулировал 6 ключевых практик, обеспечивающих успешное её применение:

1. Параллельное, а не последовательное определение артефактов проекта.

2. Согласие в том, что на каждом цикле уделяется внимание: поставленным целям и ограничениям, альтернативам организации процесса и технологических решений, закладываемых в продукт, идентификации и разрешению рисков, оценки со стороны заинтересованных лиц, достижению согласия в том, что можно и необходимо двигаться дальше.

3. Использование соображений, связанных с рисками, для определения уровня усилий, необходимого для каждой работы на всех циклах спирали.

4. Использование соображений, связанных с рисками, для определения уровня детализации каждого артефакта, создаваемого на всех циклах спирали.

5. Управление ЖЦ в контексте обязательств на основе 3 контрольных точек: 1. Цели ЖЦ (LCO); 2. Архитектура ЖЦ (LCA); 3. Начальный операционный вариант (IOC).

6. Уделение внимания проектным работам и артефактам ПО и ЖЦ.

Классическая спиральная модель носит обобщённый характер и требует конкретизации для получения пригодной на практике модели. Особенно это касается детализации её компонентов.

Модифицированная спиральная модель представляет собой один из промежуточных вариантов по уровню детализации. Детализация в этой модели (рис.6.9) связана с уточнением некоторых процессов, увеличением числа итераций при сокращении их длительности и определением контрольных точек.



Рис.6.9. Модифицированная спиральная модель

Данная модель содержит следующий общий набор контрольных точек: 1. Концепция эксплуатации (COO); 2. Цели ЖЦ (LCO), включая содержание ЖЦ; 3. Архитектура ЖЦ (LCA), здесь же можно говорить о готовности концептуальной архитектуры целевого ПО; 4. Начальный операционный вариант (IOC) - вариант ПС, готовый для опытной эксплуатации; 5. Конечный операционный вариант (FOC) - вариант ПО в виде продукта, готового для реальной эксплуатации.

Фактически получается эволюционный ЖЦ в форме спиральной модели.

Контрольные вопросы

1. Перечислите основные модели ЖЦ ПО. В чём суть непланируемой модели? Приведите графическое представление этой модели.

2. В чём суть классической каскадной модели? В чём суть модифицированной каскадной модели?

3. В чём суть прототипируемой модели? Объясните название этой модели.

4. В чём суть классической модели прототипирования?

5. В чём суть итеративной инкрементной модели?

6. В чём суть эволюционной модели?

7. В чём суть спиральной модели? Объясните название этой модели.

8. В чём суть классической спиральной модели?

9. Охарактеризуйте особенность классической спиральной модели. Перечислите ключевые практики и контрольные точки для модели.

10. В чём суть модифицированной спиральной модели?

Лекция 7

Тема лекции: Технология разработки ПО (продолжение)

Основное содержание

Процесс 1. Исследование идеи - процесс ЖЦ, который заключается в появлении и превращении возникшей идеи в определённую концепцию и в формировании проекта. Идея может привести либо к развитию уже существующего ПП, либо к созданию нового. Формальным результатом исследования идеи является одностраничное описание проекта.

Процесс 2. Управление - процесс ЖЦ, который заключается в принятии решений по правильной организации имеющихся ресурсов проекта в рамках поставленных ограничений для получения продукта, удовлетворяющего потребности пользователя и требования заказчика.

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

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

Процесс 3. Анализ требований - процесс ЖЦ, который заключается в уточнении, формализации и документировании требований заказчика. Основной вопрос, который решается здесь - «ЧТО должен делать будущий продукт?» В этом процессе наиболее важным является понимание понятия «требование». Существует несколько точек зрения на понятие «требование».

Требование - условие или возможность, необходимая для решения проблемы или достижения определённых целей с помощью разрабатываемого продукта. Требование к продукту - условие или возможность, которую должен удовлетворять или которой должен обладать продукт или его компонент для обеспечения условий разработки, связанных с контрактом, стандартами, спецификациями. Аналогично формулируется требование к процессу ЖЦ.

Спецификация требований является результатом формализации требований. В общем случае спецификация - достаточно полное и точное формальное описание работы, которую необходимо выполнить. Спецификация требований - это спецификация, включающая однозначно интерпретируемые требования, реализация которых проверяема, а стоимость и ресурсы - предсказуемы.

Существуют две существенно отличающиеся части спецификаций, соответствующие предъявляемым к ПО требованиям. Функциональные спецификации задают содержание функционирования системы. Они описывают функции ПО на основе требований к системе. Эксплуатационные (нефункциональные) спецификации задают характеристики системы и ограничения её функционирования. Они описывают особенности ПО на основе правил и стандартов.

Анализ требований также включает концептуальное моделирование. Разработка модели ПрО - ключевой элемент этого процесса. Цель моделирования - понимание проблемы, задачи и методов их решения до того, как начнётся собственно решение.

Формальным результатом анализа является спецификация требований и концептуальная модель ПрО.

Процесс 4. Проектирование - процесс ЖЦ, который заключается в исследовании структуры ПО и взаимосвязи его компонентов. Основной вопрос, который решается здесь - «КАК продукт будет удовлетворять полученным требованиям?». В этом процессе наиболее важным является представление разрабатываемого ПО (как единого целого) в виде системы.

Проектирование обычно разделяется на два взаимосвязанных подпроцесса:

1. Проектирование архитектуры (проектирование структуры, проектирование «в большом», архитектурное или высокоуровневое проектирование).

2. Проектирование компонентов (проектирование модулей, проектирование «в малом», детализированное или низкоуровневое проектирование).

В некоторых случаях выделяют связующий промежуточный подпроцесс:

3. Проектирование взаимодействия (проектирование управления, проектирование «в среднем», механистическое или среднеуровневое проектирование).

Проектирование архитектуры заключается в декомпозиции структуры системы и организации её компонентов. Проектирование компонентов описывает специфическое поведение и характеристики отдельных компонентов системы для их кодирования. Проектирование взаимодействия определяет организацию взаимодействия компонентов системы, выделенных при проектировании архитектуры и детализируемых при проектировании компонентов.

Архитектура ПО - представление ПО как системы из совокупности взаимодействующих частей. Компонент является относительно самостоятельной частью системы, в которой можно выделять только взаимосвязанные элементы. Дизайн представляет собой целостный взгляд на архитектуру ПО и состоит из различных точек зрения. Архитектурное представление - это архитектура ПО с определённой точки зрения. Архитектурная структура - дальнейшая детализация ПО, необходимая для реализации ПО и удовлетворения требований, предъявляемых к ПО. Дизайн ПО - комплекс архитектурных представлений и структур.

Формальным результатом проектирования являются дизайн продукта.

Процесс 5. Кодирование - процесс ЖЦ, который заключается в написании программного кода разрабатываемого ПО. Однако на практике такое определение оказывается слишком узким для этого классического процесса. Поэтому в настоящее время используется понятие «конструирование», определяемое следующим образом: Конструирование - процесс ЖЦ, который заключается в создании программного кода разрабатываемого ПО посредством комбинации дальнейшей детализации дизайна, кодирования и необходимого тестирования. В результате этот процесс оказывается наиболее связанным со смежными процессами - проектированием и тестированием.

К основным концепциям конструирования относят:

- Минимизация сложности: создание простого и легко читаемого кода.

- Ожидание изменений: создание легко адаптируемого кода.

- Конструирование с проверкой: создание легко тестируемого кода.

- Стандарты в конструировании: следование стандартам при создании кода.

Поддержка этих концепций осуществляется заданием стиля программирования, единого для всего создаваемого программного кода проекта, и использованием методов защитного программирования. Большинство вопросов, связанных с выполнением процесса конструирования, относится к инженерии ПО.

Формальным результатом конструирования являются программный код.

Процесс 6. Тестирование - процесс ЖЦ, который заключается в оценке и улучшении качества ПО. В общем случае тестирование состоит в обнаружении проблем нарушения работы ПО.

Этот процесс представляет собой динамическую верификацию поведения программы на ограниченном наборе тестов, выбранных соответствующим образом из обычно выполняемых действий прикладной области и обеспечивающих проверку соответствия ожидаемому поведению системы. При разработке с использованием формальных подходов вместо тестирования выполняют инспектирование - статическую верификацию поведения программы, которое не исключает применения статистического тестирования.

В настоящее время считается, что верификацию любого вида необходимо выполнять во время всего ЖЦ ПО. Большинство вопросов, связанных с выполнением процесса верификации, относится к инженерии ПО.

Формальным результатом тестирования являются «оттестированный» программный код, т.е. код с исключением недостатков, выявленных по сбоям.

Процесс 7. Ввод в действие - процесс ЖЦ, который заключается в передаче разработанного ПО в эксплуатацию. Он включает следующие действия: 1. Распространение (доставка заказчику) продукта и 2. Инсталляция (установка на конкретные системы) продукта.

Процесс 8. Сопровождение - процесс ЖЦ, который заключается модификации ПО после ввода его в действие для улучшения качества и дальнейшего совершенствования. В общем случае сопровождение состоит в обеспечении эффективной поддержки эксплуатируемого ПО при сохранении его целостности.

Основным принципом этого процесса является закон Биледи: используемый ПП подвергается непрерывным изменениям для поддержания его экономической выгоды. На практике именно недооценка сопровождения приводит к снижению эффективности ПО и отдачи от проекта. В настоящее время считается, что этот процесс по сути является продолжающейся разработкой.

Выделяют 4 категории сопровождения, рассматриваемых с точки зрения двух подходов и разбиваемых на две группы (табл.7.1).

программный обеспечение стандартный система

Табл. 7.1. Категории сопровождения

Подход	Коррекция	Расширение
Проактивный	Профилактика	Совершенствование
Реактивный	Корректировка	Адаптация

Таким образом, получаем следующие категории сопровождения. Корректирующее сопровождение - модификация для исправления обнаруженных дефектов: устранение сбоев и т.д. Адаптивное сопровождение - модификация для учёта требуемых изменений: учёт новых требований, изменение окружения ПО и т.д. Совершенствующее сопровождение - модификация для улучшения возможностей ПО: повышение характеристик ПО и т.д. Профилактическое сопровождение - модификация для предупреждения возможных проблем: определение и исправление скрытых дефектов до их реального появления в виде сбоев и т.д.

Эти категории соответствуют разным уровням модификации ПО. Ревизия (пересмотр) - незначительные, часто локальные, изменения кода.

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

Коррекция предполагает ревизию и реструктурирование, а расширение - реорганизацию и реконструирование. Кроме того, необходимо учитывать класс решаемой задачи и стоимость сопровождения.

Процесс 9. Снятие с эксплуатации - процесс ЖЦ, который заключается в прекращении сопровождения эксплуатируемого ПО. Он выполняется, когда невозможно выполнить ни одну из категорий сопровождения. Он осуществляется предварительным оповещением пользователей о прекращении сопровождения. Но использование ПО возможно вплоть до его морального устаревания.

В настоящее время наиболее употребительными при разработке ПО являются две методологии - структурная и объектно-ориентированная (OO). Принципиальное различие между ними заключается в разных способах декомпозиции систем. Структурная (функциональная) декомпозиция рассматривает структуру и поведение системы в терминах иерархии функций и передачи информации. Объектная декомпозиция рассматривает структуру системы в виде объектов и связей между ними, а поведение системы - в терминах обмена сообщениями между объектами.

Следует отметить, что в основе многих объектно-ориентированных методов лежит структурный метод, которому придана объектная окраска.

Анализ и проектирование - два достаточно близких и тесно связанных процесса. Они выполняют общую задачу, результатом которой должно стать чёткое представление о системе, на основе которого будет создан программный код.

В основе анализа и проектирования лежат модели и методы для формализации требований. Объединённые в некоторую комбинацию, они образуют методики или методические подходы к анализу и проектированию. Подходы имеют названия, причём большинство из них названы по именам своих авторов. Большинство методов и подходов применимы как при анализе, так и при проектировании.

Модели и методы анализа требований. Структурная методология: Диаграммы потоков данных (DFD); Диаграммы потоков управления; Таблицы / деревья решений; Сети Петри; Диаграммы функционального моделирования. ОО методология: КОК-карты (CRC); Диаграммы прецедентов; Диаграммы классов и объектов; Диаграммы состояний; Диаграммы деятельности; Диаграммы последовательности.

Модели и методы проектирования архитектуры. Структурная методология: Нисходящее проектирование; Восходящее проектирование. ОО методология: Проектирование предметных областей; Проектирование наведением мостов.

Модели и методы проектирования компонентов. Структурная методология: Диаграммы «сущность - связь» (ERD); Структурные карты; Скобочные диаграммы Варнье - Орра; Диаграммы деятельности; Диаграммы переходов состояний (STD); Блок-схемы, структурные схемы; Псевдокод; Блок-схемы, потоковые схемы; Диаграммы Несси - Шнейдермана. ОО методология: Диаграммы кооперации; Диаграммы компонентов; Диаграммы развёртывания.

Подходы (методики) к анализу и проектированию. Структурная методология: Подход Йордона / ДеМарко (SAD); Подход Гейна - Сарсона (SSA); Подход Константайна (SSD); Подход Джексона (JSD); Подход Варнье - Орра (DSSD); Подход Мартина (IE); Подход структурированного анализа и проектирования (SADT); Подход промышленной технологии DATARUN; Подход промышленного метода Oracle. ОО методология: Подход на основе языка UML; Подход Гради Буча (Booch); Подход Джеймса Рамбо (OMT); Подход Айвара Якобсона (OOSE); Подход Шлеер - Меллора (RD).

Контрольные вопросы

1. Охарактеризуйте классический процесс «Исследование идеи».

2. Охарактеризуйте классический процесс «Управление».

3. Охарактеризуйте классический процесс «Анализ».

4. Охарактеризуйте классический процесс «Проектирование».

5. Охарактеризуйте классический процесс «Кодирование».

6. Охарактеризуйте классический процесс «Тестирование».

7. Охарактеризуйте классический процесс «Ввод в действие».

8. Охарактеризуйте классический процесс «Сопровождение».

9. Охарактеризуйте классический процесс «Снятие с эксплуатации».

10. Дайте определения понятиям, связанным с моделями и методами анализа и проектирования.

11. Перечислите основные модели и методы анализа требований для структурной и объектно-ориентированной методологии.

12. Перечислите основные модели и методы проектирования архитектуры для структурной и объектно-ориентированной методологии.

13. Перечислите основные модели и методы проектирования компонентов для структурной и объектно-ориентированной методологии.

14. Перечислите основные подходы (методики) к анализу и проектированию для структурной и объектно-ориентированной методологии.

Лекция 8

Тема лекции: Технология разработки ПО (продолжение)

Основное содержание

Одним из фундаментальных взглядов на ЖЦ является стандарт процессов ЖЦ ISO/IEC 12207:1995 «Information Technology - Software Life Cycle Processes» («Информационная технология - Процессы жизненного цикла ПО»).

Стандарт определяет ЖЦ как структуру дробления работ (СДР). Детализация, техники и метрики проведения работ - вопрос инженерии. Организация последовательности работ определяется моделью. Совокупность моделей, процессов, техник и организации команды задаются технологией на основе методологии.

Рис.8.1. Общая структура стандартных процессов

Стандарт определяет высокоуровневую архитектуру ЖЦ ПО. ЖЦ в рамках стандарта представляет собой структуру дробления работ на следующие элементы: процессы, действия и задачи. Она реализована на основе регламентации требований к этим элементам, входящим в типовую структуру ЖЦ ПО (рис.8.1).

Каждый процесс состоит из набора действий и решаемых при выполнении соответствующего действия задач. С точки зрения соподчинённости и важности все процессы разбиты на 3 группы: основные, вспомогательные и организационные (рис.8.1). Таким образом, общая иерархия элементов ЖЦ выглядит следующим образом: Группа процессов Процессы Действия Задачи.

Рис.8.2. Взаимосвязь между стандартными процессами

Стандарт предлагает 5 точек зрения на процессы, соответствующих заинтересованным лицам (рис.8.2). Заказчики и поставщики имеют договорную точку зрения. Операторы службы поддержки и пользователи имеют эксплуатационную точку зрения. Разработчики системы и специалисты по сопровождению имеют инженерную точку зрения. Исполнители вспомогательных процессов имеют точку зрения поддержки. Менеджеры имеют управленческую точку зрения.

Таким образом, архитектура строится как набор процессов и взаимных связей между ними. Основные процессы обращаются к вспомогательным, а организационные действуют на всём протяжении ЖЦ и связаны с основными (рис.8.2).

Стандарт описывает следующие 17 процессов ЖЦ ПО в 3 группах (рис.8.1):

1. Основные процессы: 1. Приобретение / Заказ; 2. Поставка; 3. Разработка; 4. Эксплуатация; 5. Сопровождение.

2. Вспомогательные процессы: 1. Документирование; 2. Управление конфигурацией; 3. Обеспечение качества; 4. Верификация / Проверка; 5. Аттестация / Валидация; 6. Совместный обзор; 7. Аудит / Ревизия; 8. Разрешение проблем.

3. Организационные процессы: 1. Управление; 2. Инфраструктура; 3. Усовершенствование; 4. Обучение.

Стандарт также описывает следующие 4 стадии ЖЦ ПО: 1. Формирование концепции; 2. Разработка; 3. Сопровождение; 4. Снятие с эксплуатации.

Приобретение состоит из действий заказчика. Процесс включает следующие действия: Инициирование; Подготовка запроса на предложение; Подготовка и корректировка договора; Мониторинг поставщика; Приёмка и завершение.

Поставка состоит из действий поставщика. Процесс включает следующие действия: Инициирование; Подготовка предложения; Разработка договора; Планирование; Выполнение и контроль; Обзор и оценка; Приёмка и завершение.

Разработка состоит из действий разработчика. Процесс включает следующие действия: Подготовка процесса; Анализ требований к системе; Проектирование [архитектуры] системы; Анализ требований к ПО; Архитектурное проектирование ПО; Детализированное проектирование ПО; Кодирование и тестирование ПО; Интеграция ПО; Квалификационное тестирование ПО; Интеграция системы [в целом]; Квалификационные тестирование системы; Установка ПО; Поддержка приёмки ПО. Стандарт отмечает, что действия могут пересекаться по времени, т.е. проводиться одновременно или с наложением, а также могут предполагать рекурсию и разбиение на итерации.

Эксплуатация состоит из действий оператора службы поддержки. Процесс включает следующие действия: Подготовка процесса; Эксплуатационное тестирование; Эксплуатация системы; Поддержка пользователя.

Сопровождение состоит из действий специалистов сопровождения. Процесс включает следующие действия: Подготовка процесса; Анализ проблем и модификаций; Реализация модификаций; Обзор и приёмка при сопровождении; Миграция [в другую среду]; Снятие ПО с эксплуатации.

Документирование: действия по формализованному описанию информации, созданной на протяжении ЖЦ. Управление конфигурацией: действия по управлению конфигурацией процесса и ПО.

Обеспечение качества: действия по объективному обеспечению соответствия процесса и ПО установленным требованиям и утверждённым планам. Верификация: действия соответствующего субъекта (заказчика, поставщика или независимой стороны) по проверке соответствия (верификации) создаваемых артефактов (как промежуточных продуктов) установленным требованиям в виде спецификаций по мере реализации проекта. Аттестация: действия соответствующего субъекта (заказчика, поставщика или независимой стороны) по проверке соответствия (аттестации, сертификации) создаваемого конечного продукта функциональному назначению. Он является более общим процессом, чем верификация, так как учитывает возможное несоответствие ожиданий заказчика и сформулированных требований к системе.

Совместный обзор: действия по оценке состояния и результатов какого-либо действия; Процесс может использоваться двумя любыми субъектами, когда один из субъектов проверяет другого субъекта при совместном рассмотрении результатов или хода выполнения соответствующих действий. Аудит: действия независимых (по отношению к проекту) экспертов по определению соответствия деятельности субъекта принятым требованиям, планам и договору.

Разрешение проблем: действия по анализу и устранению (решению) проблем (включая обнаруженные несоответствия), независимо от их характера и источника, обнаруженных при реализации проекта.

Управление: основные действия по управлению, включая управление проектом, при реализации процессов ЖЦ. Инфраструктура: основные действия по выбору и поддержке базовой структуры какого-либо процесса ЖЦ, в том числе подходов, стандартов и инструментальных средств. Усовершенствование: основные действия, выполняемые субъектом при создании, оценке, контроле и усовершенствовании выбранных процессов ЖЦ. Обучение: действия по обучению и последующему постоянному повышению квалификации персонала.

Адаптация стандарта подразумевает применение требований стандарта к конкретному проекту, например, в рамках создания внутриорганизационных регламентов ведения проектов ПО.

Адаптация включает следующие виды действий: Определение исходной информации для адаптации стандарта; Определение условий выполнения проекта; Отбор элементов ЖЦ, используемых в проекте или регламентах; Документирование и обоснование требований, решений и процессов, связанных с адаптацией и полученных в её результате.

Адаптация также подразумевает определение основных характеристик проекта, в частности выбор методологии и технологии разработки ПО, а также соответствующей модели ЖЦ ПО. Соответствие проекта стандарту определяется как реализация в рамках конкретного проекта такой модели ЖЦ ПО, которая построена на основе выбора из этого стандарта соответствующих элементов. Выполнение процесса или действия считается завершённым, если решены все требуемые в них задачи в соответствии с предварительно установленными в договорной документации проекта критериями и требованиями.

Любая организация может применять стандарт в качестве условия обеспечения своих договоров. При этом она обязана определить и оговорить минимальный набор требуемых элементов, который обеспечивает проверку её соответствия этому стандарту. Дополнительные нестандартные элементы, необходимые для реализации проекта устанавливаются в договоре.

В настоящее время продолжается разработка нового стандарта ISO/IEC 15288:2002 «Systems Engineering - System Life Cycle Processes» («Системная инженерия - Процессы жизненного цикла систем»), в частности ведётся согласование этого стандарта с предыдущим стандартом ISO/IEC 12207:1995.

В отличие от предыдущего стандарта этот стандарт ориентирован на системы в целом (а не только на ПО в общем и программные системы в частности). Он касается систем, созданных человеком и включающих один или несколько из следующих элементов: аппаратное обеспечение, программное обеспечение, люди, процессы, процедуры, основные средства и природные ресурсы.

Стандарт предназначен для использования:

- заказчиком и поставщиком - для разработки взаимных соглашений (договоров, контрактов и т.п.), касающихся процессов и действий, которые отбираются, согласовываются и выполняются в контексте данного стандарта;

- организацией - для формирования среды необходимых процессов и оценки соответствия между заявленной и утверждённой моделью ЖЦ и её конкретной реализацией;

- проектной командой - для выбора, систематизации и применения элементов среды, сформированной для производства продукции или услуги, и оценки проекта на соответствие заявленной и сформированной среде.

Стандарт обеспечивает основы для моделирования и реализации общих процессов, составляющих ЖЦ систем, предоставляя возможность для их оценки и совершенствования, и, охватывая все концепции и идеи, имеющие отношение к этим системам, начиная от замысла и вплоть до момента снятия с эксплуатации. Процессы ЖЦ, задаваемые стандартом, могут использоваться однократно, многократно или рекурсивно, как по отношению к системе в целом, так и к любым её элементам, применяться для систем единичного и массового производства, а также адаптируемых к требованиям организации и/или проекта.

Процессы в стандарте образуют полное множество, из которого организация может конструировать модели ЖЦ систем, соответствующие их продуктам и услугам. Процессы могут поддерживаться инфраструктурой, включающей методы, процедуры, технологии, инструменты и обученный персонал. Организация может применять среду процессов для выполнения и управления проектами и развития систем на протяжении их ЖЦ.

Стандарт представляет ЖЦ системы как структуру дробления работ.

Рис.8.3. Взаимосвязь между группами процессов

Стандарт описывает следующие 26 процессов в 5 группах (рис.8.3):

1. Договорные процессы: 1. Приобретение [системы]; 2. Поставка [системы].

2. Организационные процессы: 1. Управление инфраструктурой / Управление окружением; 2. Управление инвестициями / Управление портфелем проектов; 3. Управление процессами ЖЦ / Управление моделью ЖЦ; 4. Управление ресурсами / Управление персоналом; 5. Управление качеством.

3. Проектные процессы:

- Процессы управления проектами: 1. Планирование [проекта]; 2. Мониторинг / Управление выполнением и контроль [проекта].

- Процессы поддержки проектов: 3. Оценивание / Измерение; 4. Управление решениями / Выработка решений; 5. Управление рисками; 6. Управление конфигурацией; 7. Управление информацией.

4. Технические процессы: 1. Определение требований [заинтересованных лиц]; 2. Анализ требований; 3. Проектирование архитектуры; 4. Реализация / Изготовление; 5. Интеграция / Комплексирование; 6. Верификация / Проверка; 7. Переход / Ввод в действие; 8. Аттестация / Валидация; 9. Эксплуатация / Функционирование; 10. Сопровождение / Обслуживание; 11. Снятие с эксплуатации / Вывод из действия.

5. Специальные процессы: 1. Настройка / Адаптация.

Стандарт также описывает следующие 6 стадий ЖЦ системы: 1. Формирование концепции: анализ потребностей, выбор концепции и проектных решений; 2. Разработка: проектирование системы; 3. Реализация: изготовление системы; 4. Эксплуатация: ввод в действие и использование системы; 5. Поддержка: обеспечение функционирования системы; 6. Снятие с эксплуатации: прекращение использования, демонтаж, архивирование системы.

Крайне важной для практики является детализация стандарта до уровня целей, результатов и конкретных действий. Помимо процессов стандарт определяет 208 действий и 123 различных результата этих действий.

Контрольные вопросы

1. В чём заключается цель стандарта ISO/IEC 12207:1995?

2. Как определяется ЖЦ в стандарте ISO/IEC 12207:1995?

3. Перечислите группы стандартных процессов.

4. Перечислите процессы стандарта ISO/IEC 12207:1995.

5. Перечислите стадии по стандарту ISO/IEC 12207:1995.

6. Дайте краткое описание основных стандартных процессов.

7. Дайте краткое описание вспомогательных стандартных процессов.

8. Дайте краткое описание организационных стандартных процессов.

9. Дайте краткое описание процесса адаптации стандарта.

10. В чём заключается назначение стандарта ISO/IEC 15288:2002?

11. Приведите группы процессов по стандарту ISO/IEC 15288:2002.

12. Перечислите процессы стандарта ISO/IEC 15288:2002.

13. Перечислите стадии по стандарту ISO/IEC 15288:2002.

Лекция 9

Тема лекции: Подходы разработки ПО

Основное содержание

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

Многие подходы используют для своего описания понятия «процесс», «процесс разработки ПО / системы», под которым понимается собственно подход к разработке, а не какой-либо процесс ЖЦ, описываемый этим подходом. Кроме того, в названиях подходов можно встретить и такие понятия, как «каркас», «метод», «методология», «доставка», «разработка» и «инженерия» и т.п.

Каскадные подходы являются строгими подходами, получившими также название жёстких подходов. Эти подходы основаны на одноимённых моделях ЖЦ. Они требуют определённости, полноты и точности требований, предъявляемых к ПО, и чёткости оценки полученного в результате разработки продукта.

Данные подходы рекомендуются для промышленной разработки систем военного назначения, аэрокосмических систем или систем управления технологическими процессами в реальном времени, а также других критических систем.

Выделяют каскадные подходы следующих двух видов:

1. Простые каскадные подходы: классический и модифицированный.

2. Развитые каскадные подходы: каскадно-возвратный, каскадно-итерационный, каскадно-перекрывающийся и каскадно-декомпозиционный.

В моделях ЖЦ для каскадных подходов используются классический набор процессов и попроцессное формирование стадий.

Классический каскадный подход является теоретически наиболее привлекательным, но не рекомендуемым к практическому применению подходом из-за жёстких ограничений, наложенных на выполнение процессов и отдельных действий. Снятие ограничений или учёт других особенностей разработки ПО приводит к более реалистичным каскадным подходам на основе соответствующих моделей.

Модифицированный каскадный подход заменяет одно из ограничений на более слабое. В этом подходе допускается возврат только на непосредственно предыдущую стадию. Однако на практике ошибки одной стадий не всегда проявляются на стадии, непосредственно следующей за стадией, вызвавшей ошибку.

Каскадно-возвратный подход позволяет возвратиться на любую из предыдущих стадий ЖЦ. Это принцип отражает итерационный характер разработки ПО. Кроме этого подход учитывает существенное запаздывание с достижением результата проекта из-за влияния корректировки при возвратах.

Рис.9.1. Каскадно-возвратная модель

Каскадно-возвратная модель или модель с промежуточным контролем представляет собой модель с обратными связями между стадиями. Принцип модели (рис.9.1) проявляется в обработке ошибок, выявленных промежуточным контролем. Он заключается в проведении проверок и корректировок проекта на каждой из стадий. Если на какой-либо стадии в ходе контроля обнаружилась ошибка, допущенная на более ранней стадии, работы стадии, вызвавшей ошибку, необходимо провести повторно. При этом анализируются причины ошибки и корректируются, по необходимости, исходные данные стадии или перечень работ.

Каскадно-итерационный подход предусматривает последовательные итерации каждого процесса. Каждая итерация является завершённым этапом, и её итогом будет некоторый конкретный результат. Обычно данный результат будет промежуточным, не реализующим всю ожидаемую функциональность.

Рис.9.2. Каскадно-итерационная модель

Каскадно-итерационная модель представляет собой модель с обратными связями внутри стадий. Принцип модели (рис.9.2) заключается в повторении (итерировании) каждого процесса ЖЦ до тех пор, пока не будет достигнут требуемый результат процесса в целом.

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

Каскадно-перекрывающаяся модель является вариантом модифицированной каскадной модели без учёта ограничения на перекрытие процессов и представляет собой модель с параллелизмом процессов. Принцип модели (рис.9.3) заключается в выполнении процесса не в заданных временных рамках, а с началом в предыдущей стадии и завершением в последующей стадии, перекрывая соседние процессы и сокращая время на разработку ПО. Кроме этого, возникающие в текущем процессе проблемы могут быть разрешены в предыдущем ещё незаконченном процессе, как это происходит и в модифицированной каскадной модели.

Рис.9.3. Каскадно-перекрывающаяся модель

Каскадно-декомпозиционный подход предполагает возможность представления проекта в виде композиции множества подпроектов. Наличие необходимого числа команд для их выполнения позволяет значительно сократить время разработки и эффективным образом использовать имеющиеся ресурсы.



Рис.9.4. Каскадно-декомпозиционная модель

Каскадно-декомпозиционная модель является каскадной моделью с учётом декомпозиции системы на модули и представляет собой модель с параллелизмом подпроцессов. Принцип модели (рис.9.4) заключается в разделении проекта на подпроекты по числу выделенных компонентов и/или имеющихся команд.

Каркасные подходы являются развитием каскадных подходов на основе применения развитых моделей ЖЦ и адаптации к современным условиям. В настоящее время среди строгих подходов именно они применяются на практике.

Выделяют каркасные подходы следующих двух видов:

1. Унифицированные каркасные подходы: Унифицированный процесс (UP) и его модификации, Рациональный унифицированный процесс (RUP).

2. Специализированные каркасные подходы: Каркас решений Майкрософт (MSF), Процесс ICONIX (ICONIX Process), Модельно-основанная (системная) архитектура и программная инженерия (MBASE).

Каркасные подходы предоставляют развитый и адаптируемый под конкретные условия и потребности технологический каркас для применения в реальных проектах. Он включает в себя набор дисциплин и моделей для процессов (или их групп) и представлений (форм) соответственно.

Модели ЖЦ для каркасных подходов приведены при изложении соответствующих подходов. Они являются развитием спиральной модели с учётом других моделей и практических особенностей разработки ПО. В этих моделях используются стандартный набор процессов и пофазное формирование стадий.

Унифицированный процесс (УП, UP - Unified Process) - классический унифицированный каркасный подход, развиваемый самостоятельно, отдельно от унифицированного каркасного подхода, предлагаемого фирмой IBM Rational.

Первая книга с описанием этого подхода,- «Унифицированный процесс разработки ПО» сотрудников Rational Software А. Якобсона, Г. Буча и Дж. Рамбо (1999 г.). В дальнейшем авторы книги предпочли для этого подхода название Rational Unified Process. Авторы последующих публикаций по этой тематике, не являющиеся сотрудниками этой фирмы, используют название Unified Process.

Данный подход представляет собой расширяемый каркас процессов, который может быть настроен для применения конкретными организациями или при выполнении определённых проектов. Он предназначен для описания обобщённого процесса разработки, включая те его элементы, которые являются общими по отношению к различным уточнениям и другим проектным особенностям.

УП обладает следующими особенностями: 1. Итеративность и инкрементность; 2. Управляемость прецедентами; 3. Ориентированность на архитектуру; 4. Сосредоточенность на рисках.

Итеративность и инкрементность означает использование указанных принципов на основе спиральной модели. В ЖЦ выделяются фазы, состоящих из последовательности итераций, которые ограничены временными рамками. Результатом итерации является инкремент - очередной прототип.

...