Технологии разработки программных систем

15. В чём суть методологии объектно-ориентированного программирования?

16. В чём суть методологии функционального программирования?

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

18. В чём суть методологии сентенциального программирования?

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

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

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

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



Раздел 3. Технология разработки ПО

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

3.1 Основные понятия и определения

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

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

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

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

Технологию удобно характеризовать в двух измерениях - вертикальном (представляющем процессы) и горизонтальном (представляющем стадии).

Связующим понятием между процессами и стадиями является «действие». Действие (тж. работа, вид деятельности) - часть деятельности по проекту, выполняемая отдельным исполнителем или группой исполнителей. Фактически процессы и стадии представляют собой определённые наборы действий: по признаку преобразования данных действия объединяются в процессы, а повременному признаку и/или получаемому результату - в стадии.

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

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

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

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

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

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

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

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

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

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

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

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

Для формализации внесения изменений в произведённый результат используется понятие «базовая линия». Базовая линия - официально принятый вариант произведённого результата, обозначенный и зафиксированный в конкретный момент времени ЖЦ. Изменения, вносимые в базовую линию, должны быть предварительно утверждены, т.е. должны пройти через специальное формализованное действие. Для проекта в целом базовая линия обычно переводится как базовый план - исходный план проекта с утверждёнными изменениями.

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

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

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

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

3.2 Основные классификации

Существует два основных набора технологических процессов. 1. Классический набор - совокупность основных процессов, сложившихся исторически в результате практического опыта разработки ПО. 2. Стандартный набор - совокупность процессов, определённых в стандарте ISO/IEC 12207:1995 «Information Technology - Software Life Cycle Processes» («Информационная технология - Процессы жизненного цикла ПО»).

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

Классический набор включает 9 процессов: 1. Исследование; 2. Управление; 3. Анализ; 4. Проектирование / Дизайн; 5. Кодирование, Конструирование; 6. Тестирование; 7. Ввод в действие; 8. Сопровождение; 9. Снятие с эксплуатации.

Перечисленные процессы подробно рассматриваются в §3.4.

Стандартный набор включает существенно большее число процессов, объединённых в три тематические группы: основные, вспомогательные и организационные процессы. Перечисленные процессы подробно рассматриваются в §3.6.

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

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

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

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

В большинстве подходов с этой классификацией выделяют 4 основные фазы:

1. Начало - Изучение ПрО и получение требований.

2. Середина - Анализ требований и проектирование.

3. Кульминация - Конструирование (кодирование и тестирование).

4. Переход - Внедрение (ввод в действие и опытная эксплуатация).

В ряде подходов выделяют 2 дополнительные фазы:

5. Работа - Эксплуатация и сопровождение.

6. Окончание - Снятие с эксплуатации.

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

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

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

По степени коммерциализации выделяют: коммерческий проект с ориентацией на получение прибыли и некоммерческий проект - без получения прибыли.

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

Таблица 3.1 - Категории проектов

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

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

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

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

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

3.3 Модели жизненного цикла ПО

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

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

Рассмотрим часто встречающиеся модели. Некоторые другие модели кратко рассмотрены в разделах пособия, посвящённых использующих их подходам.

Непланируемая модель

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



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

Наиболее часто модель используется в мелких проектах. Она лежит в основе одноимённого подхода, условно относимого к группе гибких подходов.

Каскадная модель

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

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



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

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

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

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

Классическая каскадная модель сформировалась в период с 1970 по 1980 годы и считается исходной для множества других моделей. У.У. Ройс в своей статье 1970 г. привёл эту модель как пример нереалистичной нерабочей модели ЖЦ ПО.

Прототипируемая модель

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

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

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

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



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

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

Итеративная инкрементная модель

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



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

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

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

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

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

Эволюционная модель

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

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



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

Спиральная модель

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

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

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

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

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

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

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

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

2. Анализ и проверка альтернатив, идентификация и разрешение рисков.

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

4. Планирование следующей итерации (очередного цикла).

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

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

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

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

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

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

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

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

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

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

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

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

Данная модель содержит следующий общий набор контрольных точек:

1. Концепция эксплуатации (COO);

2. Цели ЖЦ (LCO), включая содержание ЖЦ;

3. Архитектура ЖЦ (LCA), здесь же можно говорить о готовности концептуальной архитектуры целевого ПО;

4. Начальный операционный вариант (IOC) - вариант ПС, готовый для опытной эксплуатации;

5. Конечный операционный вариант (FOC) - вариант ПО в виде продукта, готового для реальной эксплуатации.

Последняя контрольная точка в ряде подходов на основе этой модели называется по-другому: Выпускаемый продукт (PR).

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

3.4 Классические технологические процессы

Процесс 1. Исследование идеи

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

Процесс 2. Управление

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

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

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

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

Процесс 3. Анализ

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

В этом процессе наиболее важным является понимание понятия «требование». Существует несколько точек зрения на понятие «требование».

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

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

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

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

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

Процесс 4. Проектирование

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

В этом процессе наиболее важным является представление разрабатываемого ПО (как единого целого) в виде системы, рассмотренное в §1.1.

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

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

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

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

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

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

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

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

Процесс 5. Кодирование

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

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

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

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

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

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

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

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

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

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

Процесс 6. Тестирование

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

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

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

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

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

Процесс 7. Ввод в действие

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

Процесс 8. Сопровождение

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

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

Таблица 3.2 - Категории сопровождения

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

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

Таким образом, получаем следующие категории сопровождения:

1. Корректирующее сопровождение - модификация для исправления обнаруженных дефектов: устранение сбоев и т.д.

2. Адаптивное сопровождение - модификация для учёта требуемых изменений: учёт новых требований, изменение окружения ПО и т.д.

3. Совершенствующее сопровождение - модификация для улучшения возможностей ПО: повышение характеристик ПО и т.д.

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

Эти категории соответствуют разным уровням модификации ПО:

1. Ревизия (пересмотр) - незначительные, часто локальные, изменения кода.

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

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

4. Реконструирование (реконструкция, повторное конструирование) - перекодирование существенной части кода.

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

Процесс 9. Снятие с эксплуатации

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

3.5 Методики анализа и проектирования

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

1. Структурная (функциональная) декомпозиция рассматривает структуру и поведение системы в терминах иерархии функций и передачи информации.

2. Объектная декомпозиция рассматривает структуру системы в виде объектов и связей между ними, а поведение системы - в терминах обмена сообщениями между объектами.

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

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

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

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

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

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

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

3.6 Стандартные технологические процессы

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

Стандарт ISO/IEC 12207

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

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

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

Таким образом, стандарт определяет высокоуровневую архитектуру ЖЦ ПО.

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

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

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



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

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

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

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

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

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

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

Основные процессы

Первые два процесса связаны с договорной точкой зрения (рис.3.10 и 3.11).

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

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

Третий (как и пятый) процесс связан с инженерной точкой зрения (рис.3.11).

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

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

Четвёртый процесс связан с эксплуатационной точкой зрения (рис.3.11).

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

Пятый (как и третий) процесс связан с инженерной точкой зрения (рис.3.11).

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

Вспомогательные процессы

Все процессы связаны с точкой зрения поддержки (рис.3.11). Кроме того, все процессы, кроме первого, второго и последнего (восьмого), определяют управление качеством (рис.3.10).

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

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

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

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

Организационные процессы

Все процессы связаны с управленческой точкой зрения (рис.3.11). Кроме того, первый процесс определяют непосредственно управление (рис.3.10).

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

Адаптация стандарта

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

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

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

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

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

В следующем стандарте ISO/IEC 15288:2002 адаптация рассматривается уже как отдельный процесс ЖЦ в рамках отдельной группы процессов.

Стандарт ISO/IEC 15288

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