Андон Ф.И., Коваль Г.И., Коротун Т.М., Лаврищева Е.М., Суслов В.Ю. Основы инженерии качества программных систем

Подождите немного. Документ загружается.

264 Глава 6

• график выполнения задач с указанием даты начала и завершения выполне-

ния, а также получения входной информации и отправки результатов;

• ресурсы для выполнения каждой задачи (по категориям – персонал, обо-

рудование, инструменты, обучение);

• риски и допущения, связанные с каждой задачей, а также рекомендации по

устранению, снижению или наблюдению рисков;

• обязанности и ответственность лиц, участвующих в решении задачи.

Требования к отчетным документам V&V. В этом разделе указываются ви-

ды, структура и содержание обязательных отчетов по V&V - Отчетов о задачах

V&V, Итоговых отчетов о действиях V&V, Отчетов об аномалиях и заключитель-

ного отчета о V&V - и, возможно, других (необязательных) отчетов.

Требования к административным процедурам. В этом разделе устанавлива-

ются требования по следующим аспектам административной поддержки V&V:

• составление отчетов и принятие решений по аномалиям – критерии оп-

ределения и регистрации аномалий, список распределения (рассылки) отчетов для

устранения аномалий, полномочия и сроки устранения аномалий, уровни критич-

ности каждой аномалии. Подходы к классификации аномалий определяются стан-

дартом IEEE Std. 1044 [9] и руководством [10];

• критерии определения, в какой степени необходимо осуществить повтор-

ное выполнение задачи V&V при изменениях входных данных или процедур, ис-

пользуемых при ее решении. Критерии могут основываться на оценке существен-

ности изменений, уровня целостности ПО, отражения изменений на бюджете, гра-

фике и качестве;

• критерии и процедуры оформления отклонений от плана, касающиеся

идентификации задачи, обоснования отклонений и степени влияния на качество

ПО. Должны быть также указаны уровни ответственности за утверждение отклоне-

ний от плана;

• процедуры контроля, используемые при V&V. Они должны описывать,

каким образом будут собираться, храниться и защищаться результаты V&V и рабо-

чие продукты, если эти действия не поддерживаются процедурами SQA, управле-

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

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

V&V будут защищены от случайного или преднамеренного изменения;

• стандарты, практические рекомендации и соглашения, регулирующие

выполнение задач V&V, включая внутренние стандарты (стандарты предприятия),

методики и документы, разъясняющие политику организации.

Требования к документированию V&V. В этом разделе указываются назначе-

ние, формат и содержание документов всех видов и уровней тестирования ПС –

планов тестирования, проектов тестов, наборов тестов, процедур тестирования и

результатов тестирования (глава 7).

Полнота и правильность плана SVVP должны проверяться и подтверждаться

руководством проекта. Для этого могут использоваться контрольные перечни во-

просов, касающихся всех аспектов деятельности по V&V и учитывающих особен-

ности прикладной области, для которой создается ПС.

Отчеты по верификации и валидации. Результаты выполнения действий и

задач V&V документируются в сводном отчете о V&V, который может включать:

Отчеты о задачах V&V, Итоговые отчеты о действиях V&V, Отчеты об аномалиях,

Глава 6 265

Тестовые документы V&V, Заключительный отчет о V&V и, возможно, другие от-

четы, оговоренные в плане SVVP.

Отчет о задаче V&V кратко описывает ход ее выполнения и полученные ос-

новные результаты, а также включает характеристику обнаруженных аномалий,

оценку степени изменения базовой версии ПО и состояния управления конфигура-

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

обстоятельств, которые могут повлиять на дальнейшие действия по V&V (напри-

мер, привести к изменениям в SVVP).

Итоговый отчет о действии по V&V любого из основных процессов ЖЦ

обобщает результаты выполнения задач V&V и включает краткое описание задач,

оценку качества ПО, обзор аномалий, идентификацию и оценку рисков и рекомен-

дации относительно аномалий и рисков.

Отчет об аномалиях (проблемах, дефектах) описывает каждую обнаружен-

ную аномалию и содержит оценку ее влияния на ПС и степень критичности. Под-

робнее этот вид отчетов описан в разделе 6.3 и главе 7.

Заключительный отчет о V&V составляется по завершении действий по вво-

ду ПС в эксплуатацию или по завершении деятельности по V&V (если эти события

не совпадают). Он включает обзор всех действий по V&V в ЖЦ ПС, всех результа-

тов выполнения задач, обнаруженных аномалий и принятых относительно них мер,

а также оценку качества ПО и описание извлеченных уроков и рекомендаций.

6.2. Виды и методы проверки программных систем

6.2.1. Классификация методов проверки

Методы, применяемые при выполнении процессов верификации, валидации,

совместного просмотра и аудита, можно классифицировать по-разному, например:

• динамические (связанные с выполнением программ

) и статические (свя-

занные с просмотром текста);

• поисковые (направленные на поиск ошибок) и поддерживающие принятие

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

либо отличительных особенностей, выполнения оценок и др.);

• для коллективной работы и для индивидуальной (аналитической) работы;

• формальные (требующие четкого соблюдения метода) и неформальные;

• коллегиальные (выполняемые коллегами по работе, равными в правах, и не

грозящие административными последствиями) и ревизионные и т.п.

Одни и те же методы могут применяться для выполнения разных процессов

проверки, и, наоборот, при выполнении одного процесса проверки может исполь-

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

решения которой он применяется, а сама задача имеет название, одноименное ме-

тоду, например, анализ прослеживаемости, анализ критичности и др. Во избежание

путаницы с одноименными наименованиями методов, процессов и задач далее при

описании методов приводятся их эквивалентные названия на английском языке.

Для удобства изложения мы используем классификацию методов на коллек-

тивные и индивидуальные аналитические и попутно характеризуем их с точки зре-

К динамическим методам мы относим и методы «прокрутки» программы вручную.

266 Глава 6

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

ческой проверки. Методы динамической проверки (методы тестирования) можно

найти в главе 7.

6.2.2. Обзор аналитических методов

Аналитические методы предназначены для индивидуального исследования

рабочих продуктов ПС с использованием (или без) инструментальных средств под-

держки. Они могут быть отнесены к категории поисковых методов, методов под-

держки принятия решений либо иметь двойное назначение. В таблице 6.3 дана

краткая характеристика методов с указанием ссылок на доступные источники с их

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

применения, которые могут использоваться для целей V&V, имеют гораздо более

широкое поле приложения (например, в процессах SQA, анализа требований, про-

ектирования, тестирования или управления риском). Обзор многих методов анализа

можно найти у Д. Веллес в работах [11], [12].

Таблица 6.3. Методы анализа рабочих продуктов ПС

Метод Краткая характеристика и рекомендации по применению

Вопросники

(Checklists)

Перечень вопросов, касающихся определенного аспекта проверки

рабочего продукта.

Создается для каждого вида рабочих продуктов (требований, про-

екта и др.) с учетом особенностей класса ПС (ПС реального времени,

информационные и др.). Структурирован по категориям возможных

дефектов. Оптимальный объем вопросника – 1 лист для каждой кате-

гории. Подробнее – в п.6.3.2. Может использоваться для поиска де-

фектов и обоснования принимаемых решений.

Анализ алго-

ритма

(Algorithm

analysis)

Цель - определить функциональную корректность алгоритма и его

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

нений или оценку пригодности численных методов.Алгоритмы ана-

лизируются с точки зрения их корректности, эффективности, просто-

ты, оптимальности и точности.

Исследует влияние усечений и округлений, оценивает обеспечи-

ваемую точность хранения при использовании различных типов пе-

ременных (например, с простой или удвоенной точностью) и влияние

преобразования типов.

Обнаруживает неправильные, неэффективные (по памяти и време-

ни) или неустойчивые алгоритмы; недостаточную точность вычисле-

ний; неработоспособность на полном диапазоне данных; неправиль-

ный анализ погрешности вычисления и др.

Может использоваться для поиска дефектов.

Графиче-

ский анализ

(Graphical

analysis)

Анализ состояний продуктов и процессов с использованием диа-

грамм: столбиковых, гистограмм, Парето, рассеяния, выполнения,

причинно-следственной связи и др.

Может использоваться для поиска дефектов и обоснования при-

нимаемых решений.

Формальное

доказательство

правильности

(Formal proof)

Применяется для математического доказательства соответствия

детальной формальной спецификации (требований, проекта или кода)

исходной спецификации. Предполагает, что для генерации специфи-

каций применялись формальные методы.

Может использоваться для поиска дефектов.

Глава 6 267

Метод Краткая характеристика и рекомендации по применению

Анализ ин-

терфейса

(Interface analy-

sis)

Проверка интерфейсов различных типов - внешнего, внутреннего,

аппаратного, программного, программно-аппаратного и программно-

информационного (базы данных). Может включать следующее:

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

ческие значения;

- анализ ситуации, когда часть переменных интерфейса имеет кри-

тические значения, а остальные - имеют нормальные значения;

- анализ ситуации, когда одна (поочередно каждая) переменная ин-

терфейса принимает все значения из области значений, а остальные –

только нормальные значения.

Обнаруживает следующие типы ошибок: ошибки описания вхо-

дов/выходов; несоответствие фактических и формальных параметров

(точность, тип, количество); некорректное использование функций

или вызов подпрограмм; несогласованность атрибутов глобальных

переменных и др.

Может использоваться для поиска дефектов.

Анализ

потоков

данных

(Dataflow analy-

sis)

Анализ потока

информации

(Information

flow analysis)

Применяется для обнаружения неопределенных входов/выходов

или форматов данных, нарушения порядка обработки (чтения данных

до их записи), отсутствия обработки (неоднократной записи в одни и

те же переменные без использования (чтения) записанных данных).

Использует информацию о потоках управления и о структурах

хранения (переменных), в которые пишутся или из которых читаются

данные, обрабатываемые приложением.

Анализ потока информации – расширение анализа потоков данных,

автоматизирован в современных CASE-инструментах.

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

сайте: www.cc.gatech.edu/aristotle/Publications/dataflow.html

Может использоваться для поиска дефектов и обоснования при-

нимаемых решений.

Анализ

влияния

изменений

(Change impact

analysis)

Используется для определения объема и сложности внесения изме-

нений в рабочие продукты на определенной стадии ЖЦ. Основные

стадии – обзор запроса об изменениях, оценка степени распростране-

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

Использует анализ трассируемости, анализ взаимозависимостей

элементов системы, анализ согласованности.

Может использоваться для обоснования принимаемых решений.

Анализ базы

данных

(Database analy-

sis)

Применяется для анализа программных приложений с большим

объемом хранимых данных во внутренних структурах хранения или

базе данных, для проверки целостности данных, возможности пере-

полнения массивов и таблиц, непротиворечивости типов данных, спо-

собов их использования, привилегий доступа. Цель - гарантировать,

что структуры данных, методы и права доступа не противоречат про-

екту приложения. Может использоваться для поиска дефектов.

Анализ хода

работ

(анализ освоен-

ного объема)

(Earned Value

Analysis)

Графическое представление изменения соотношения планового и

реального состояния проекта с течением времени. Используется для

контроля проекта: соблюдения графика, финансовых затрат, трудо-

вых ресурсов проекта. Применяется в пакетах управления проектами

Microsoft Project, Open Plan, Suretrak, Primavera Project Planner, Spider

Project (Россия). Сайт по управлению проектами - http://project.km.ru/

Может использоваться для обоснования принимаемых решений.

268 Глава 6

Метод Краткая характеристика и рекомендации по применению

Анализ опера-

ционного

профиля

(Operational

profile analysis)

Профиль - полное множество альтернатив (например, множество

альтернативных сценариев работы пользователей), для каждой из ко-

торых существует определенная вероятность появления. Полнота

множества альтернатив означает, что сумма вероятностей их появле-

ния равна единице.

Анализ операционного профиля используется для рационального

распределения усилий по V&V рабочих продуктов ПС, построения

системы тестов и тестовых сценариев, максимально приближенных к

реальным условиям среды функционирования ПС и др.

Может использоваться для обоснования принимаемых решений.

Анализ трас-

сируемости

(Traceability

analysis)

Существует несколько типов анализа трассируемости - трассировка

требований, трассировка проекта, трассировка кода и трассировка

теста. Проверяется, что каждое требование нашло отражение в проек-

те/коде, что все аспекты проекта/кода основаны на определенных

требованиях, что тестирование дает результаты, совместимые с уста-

новленными требованиями. Основан на применении матриц трасси-

ровки требований:

- матрица «требования/метод оценивания» - для проверки охвата

всех требований определенной формой V&V;

- матрица «требования/тесты» - для проверки охвата всех требова-

ний тестированием;

- матрица «требования/модули» - для проверки покрытия каждого

требования группой модулей (программных компонентов), реали-

зующих это требование.

Типы обнаруживаемых ошибок:

- при анализе трассируемости требований - пропущенные функ-

ции, неправильное упорядочение требований по важности, специфи-

кация ПО несовместима с другими спецификациями системы;

- при анализе трассируемости проекта - нереализованные требо-

вания, неправильная интерпретация специфицированных требований,

детальный проект не соответствует архитектурному;

- при анализе трассируемости кода – несоответствие кода проекту,

несоответствие кода стандартам, ПО в целом или отдельные компо-

ненты не выполняют требуемые функции и др.

Может использоваться для поиска дефектов и обоснования при-

нимаемых решений.

Анализ

деревьев

событий

(Event tree

analysis)

(ETA)

Идентифицирует компоненты, события отказов которых могут по-

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

каждого события (вызывающего цепь других событий) трассируются

до тех пор, пока не прояснятся опасности (самого верхнего уровня),

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

ской цепочки событий определяется вероятность каждого события и

комбинации событий.

Дерево событий представляет полный спектр возможных послед-

ствий определенного события отказа компонента (являющегося кор-

нем дерева). Не отражает причин появления события отказа.

Подробнее – в главе 7, а также на сайте:

www.cis.strath.ac.uk/teaching/ug/classes/52.422/risk.assessment.two.doc

Может использоваться для поиска дефектов.

Глава 6 269

Метод Краткая характеристика и рекомендации по применению

Анализ

деревьев

отказов

(ошибок)

(Fault tree analy-

sis)

(FTA)

Возможный отказ компонента системы рассматривается как собы-

тие верхнего уровня, причины которого скрыты внутри компонента.

Анализ дерева отказов – это процесс идентификации рисков, свя-

занных с компонентом системы. Дерево отказов – иерархическая

структура, на вершине (в корне) которой – состояние отказа компо-

нента, прилегающие ветви – события, приводящие к переходу в это

состояние. Исток каждой ветви – состояние элемента компонента,

приведшее к наступлению соответствующего события.

Это дедуктивный метод поиска условий и факторов (причин) появ-

ления события отказа компонента.

Трассирование событий может начинаться не с события отказа

компонента системы, а с внешнего события, представляющего опас-

ность. Подробнее – в главе 7, а также на сайте:

www.cis.strath.ac.uk/teaching/ug/classes/52.422/risk.assessment.two.doc

Может использоваться для поиска дефектов.

Анализ режи-

мов (механиз-

мов) и

последствий

отказа

(Failure mode

and effect analy-

sis (FMEA))

Анализ режи-

мов и критич-

ности отказов

(Failure mode

and criticality

analysis

(FMECA))

Методы предотвращения появления отказов. Используются для

идентификации типов потенциальных дефектов и механизмов их по-

явления (режимов работы системы, в которых они могут появиться) с

целью определения их возможного влияния на изучаемый объект

(систему, компонент), а также классификации типов дефектов по кри-

тичности последствий (в критических системах). Широко применя-

ются в инженерии надежности и безопасности технических систем.

Представляют подход, обратный (индуктивный) по отношению к

методу FTA (направление анализа – от события отказа отдельного

компонента (с учетом его критичности или без) до опасного внешнего

события для пользователя).

Идентифицируют те компоненты, которые требуют повышенного

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

управления риском, тестирования ПО в условиях ограниченных ре-

сурсов, обеспечения отказоустойчивости ПО, построения процедур

сопровождения и др.

Подробнее – в главе 7 или на сайте www.itemsoft.com/fmeca.shtml

Могут использоваться для обоснования принимаемых решений.

Анализ опас-

ностей

(Hazard

analysis)

Анализ угроз

(Threat analysis)

Опасность/угроза - состояние системы или среды, попадание в ко-

торое приводит к катастрофическим последствиям для общества. В

программной инженерии термин «опасность» чаще связывается с

процедурами обеспечения безопасности функционирования (safety), а

«угроза» - с процедурами защиты информации (security).

Методы применяются при разработке высокоцелостных систем.

Используют метод ETA. Могут использоваться для поиска дефектов и

обоснования принимаемых решений.

Анализ риска

(Risk analysis)

Может использовать методы FMEA, FMECA, FTA, а также методы,

представленные в главе 10

Может использоваться для обоснования принимаемых решений.

Анализ

критичности

(Criticality

analysis)

Используется для определения стратегий V&V, применимых к

компонентам (модулям) с высоким риском отказов. Ранжирует ком-

поненты по степени вклада в безопасность. Устанавливает, в какой

степени безопасность функционирования системы зависит от кор-

ректной работы отдельных компонентов ПО, и каким образом на нее

могут повлиять отклонения в реализации ПО.

270 Глава 6

Метод Краткая характеристика и рекомендации по применению

Классификация компонентов по уровню критичности может вы-

полняться с помощью указания их роли в обеспечении безопасности

(не играет, играет косвенно, играет непосредственно, играет вспомо-

гательную роль), а также с помощью индекса критичности.

Использует результаты анализа опасности, FMEA, FMECA для

идентификации требований (элементов проекта, кода), неправильная

реализация которых может вызвать наиболее серьезные последствия.

Может использоваться для обоснования принимаемых решений.

Проверка за

столом

(Desk checking)

(Code reading)

Чтение исходного кода и комментариев программы независимым

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

фектов, проверки интерфейсов процедур, проверки соответствия

стандартам соглашениям. Изучение содержательной стороны про-

граммы с целью ее сравнения с внешними спецификациями. Метод

полезен для выявления следующих типов ошибок (дефектов):

- ошибки логики и управления: недостижимый код, неправильное

вложение циклов и ветвей, неправильная последовательность процес-

сов, бесконечные циклы, метки без ссылок и др.;

- ошибки вычислений: неправильный доступ к компонентам масси-

ва, несоответствие списков параметров; ошибки инициализации, ус-

таревшие данные, неопределенные переменные, необъявленные пе-

ременные, неправильное употребление переменных (локальных и

глобальных), неопределенные границы данных, неэффективная пере-

дача управления и др.;

- прочие: вызов не существующих подпрограмм, ошибки входов/

выходов, неэффективное программирование, плохой стиль.

Может использоваться для поиска дефектов.

Ортогональ-

ная

классифика-

ция

дефектов

(ODC)

(Orthogonal de-

fect classifica-

tion)

Характеристика каждого обнаруженного дефекта по трем аспек-

там:

- тип дефекта. Назначается исходя из характера действий, ко-

торые должны быть выполнены для устранения дефекта (исправление

документации, интерфейсов, функций, алгоритмов, назначений зна-

чений и др.). Служит мерой совершенства продукта;

- триггер дефекта (причина обнаружения). Направление про-

верки (в рамках одного из трех видов проверки – обзоры, автономное

и функциональное тестирование, системное тестирование и испыта-

ния), при выполнении которой был обнаружен дефект (проверка пол-

ноты, проверка согласованности, путевое тестирование, нормальный

режим и др.). Служит мерой эффективности V&V;

- влияние дефекта. Критерии оценки воздействия, которое де-

фект может оказать (или уже оказал) на степень удовлетворенности

конечного пользователя продуктом (функциональность, надежность,

удобство применения и др.). Служит мерой качества продукта при

использовании.

ODC – парадигма измерения характеристик процессов и продук-

тов на основе причинно-следственного анализа дефектов. Подробно-

сти – на сайтах:

www.research.ibm.com/softeng/ODC/ODC.HTM

www.chillarege.com/odc/articles/odcrisk/odcissre.html

Может использоваться для обоснования принимаемых решений.

Глава 6 271

Метод Краткая характеристика и рекомендации по применению

Анализ слож-

ности

(Complexity

analysis)

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

сложных для корректной реализации, тестирования и сопровождения.

Может использоваться для обоснования принимаемых решений.

Прототипоро-

вание

(Prototyping)

Применяется для согласования и оценки реализуемости требова-

ний, оценки проекта интерфейса пользователя, предсказания размера

и сложности ПС, определения стратегий тестирования.

Может использоваться для поиска дефектов.

6.2.3. Обзор методов коллективной проверки

Коллективные проверки предполагают участие в них нескольких (по крайней

мере, двух) лиц и принятие согласованного коллективного решения

. Лица, прини-

мающие участие в коллективных проверках, должны, с одной стороны, владеть ме-

тодами индивидуальной аналитической проверки рабочих продуктов, а с другой -

обладать навыками коллективной работы.

Коллективные проверки могут проходить либо в форме неформальных соб-

раний, либо в форме формальных совещаний, заранее подготовленных и имеющих

строго определенную процедуру проведения. Формальные проверки строже и счи-

таются более эффективными, однако, их сложнее применять на практике. К тому

же, в условиях нехватки знаний процедур их проведения и отсутствия опыта прак-

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

шение о типе проверки принимается руководством проекта на основе опыта разра-

ботчиков и критичности проекта. Допускаются компромиссные решения о прове-

дении полуформальных проверок.

Объектами всех видов проверок являются любые рабочие продукты ПC (или

их части), создаваемые на стадиях ЖЦ и в процессах ЖЦ. Действует принцип: «все,

что может быть проверено, должно быть проверено тщательно и своевременно».

Проверяться могут:

- документы ПС (описание требований, описание проекта, описание постано-

вок задач, текст кода, эксплуатационная документация и др.), «представляющие»

(характеризующие) ПС на определенной стадии ее существования;

- документы проекта разработки ПС (планы, протоколы и др.), характери-

зующие ход разработки ПС и ресурсы проекта;

- документы процесса ЖЦ ПС (планы, описание процесса, руководства по

выполнению и др.).

Нужно заметить, что в стандартах, регламентирующих процессы проверки,

нет «единодушия» в терминах, используемых для определения одних и тех же по-

нятий. В частности, множество материалов, передаваемых для проверки, может на-

зываться и «рабочим продуктом» (в единственном и множественном числе), и

«программным продуктом» (в единственном и множественном числе).

Далее мы будем считать, что независимо от вида проверки и стадии ЖЦ, на

которой она проводится, объектом проверки является один рабочий продукт (или,

Если проверка, осуществляемая группой лиц, не предполагает коллективного обсу-

ждения и принятия согласованного решения, она не является коллективной (например, од-

новременное тестирование разных компонентов ПС разными тестировщиками).

272 Глава 6

для краткости, просто продукт проверки), который может представлять собой со-

вокупность любых передаваемых для проверки материалов (документов, про-

грамм), например, совокупность тестов, совокупность описаний постановок задач и

др.

Проведение формальных коллективных проверок регламентируется стандар-

том IEEE Std. 1028 [13]. В этом стандарте по единой схеме описаны 5 видов про-

верки:

технический обзор,

управленческий обзор,

инспекция,

сквозной контроль,

аудиторская проверка.

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

требования к входам и выходам, критерии начала и завершения, а также методиче-

ские указания по процедурам проверки.

Краткая характеристика перечисленных методов дана в таблице 6.4. Более

подробное описание одного из самых распространенных и мощных методов про-

верки – метода формальной инспекции - содержится в разделе 6.3.

Таблица 6.4. Обзор методов коллективной проверки

Цель и объект проверки Участники и роли

Технический обзор (Technical review)

Систематическая оценка пригодности продукта для использо-

вания по назначению и идентификация расхождений со специфи-

кациями и отклонений от стандартов, руководств и планов. Воз-

можно рассмотрение альтернатив и выработка рекомендаций.

Инициируется лицом, которое несет ответственность за разра-

ботку такой системы, функциональные и технические характери-

стики которой будут удовлетворять требованиям потребителя.

Планируется (в планах управления проектом). Возможны допол-

нительные технические обзоры по запросу руководства проекта,

группы качества, группы системной инженерии, группы про-

граммной инженерии.

Поддерживает принятие решений ЛПР (лицом, принимающим

решение) о возможности перехода к следующей стадии ЖЦ, о

необходимых корректирующих действиях, касающихся техниче-

ских аспектов разработки системы.

Объекты обзора – спецификация требований, описание про-

екта, тестовые документы и др.

Участники обзора (в количестве не менее 3 человек) подбира-

ются лидером (с помощью руководства) из числа компетентных

специалистов в области разработки ПС. Имеют достаточно вре-

мени для изучения продукта, способны обнаружить технические

проблемы и предложить способы их решения (альтернативы). По

запросу лидера могут прослушать вводный обзор процедур про-

верки или продукта.

Участники – группа

проекта (руководство,

заказчики и пользова-

тели – необязательно)

Роли:

- ЛПР (принимает ре-

шение)

- лидер обзора (обу-

чен, готовит и ведет

совещание),

- секретарь (фиксиру-

ет проблемы),

- персонал проекта

(активно участвует в

обсуждении, предла-

гает альтернативы)

- руководящий состав

(идентифицирует про-

блемы, требующие

управленческих реше-

ний)

Глава 6 273

Цель и объект проверки Участники и роли

Подготовленность участников к техническому обзору прове-

ряется лидером. Если участники недостаточно подготовлены, ли-

дер может перенести совещание.

Продукт изучается участниками до начала совещания (этап

подготовки). Описание проблем передается лидеру. Лидер упоря-

дочивает проблемы по степени важности. Знакомит с ними авто-

ров продукта.

На совещании проблемы обсуждаются, оцениваются связан-

ные с ними риски, предлагаются технические решения, даются

рекомендации руководству. Если зафиксированы многочислен-

ные проблемы или есть проблемы, классифицированные как кри-

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

переделок продукта.

Процессы ЖЦ: совместный просмотр, V&V, SQA

Управленческий обзор (management review)

Систематическая оценка состояния процессов ЖЦ с целью

контроля продвижения проекта, определения состояния выпол-

нения планов и графиков, распределения ресурсов, соблюдения

стандартов и регулирующих норм, а также оценивание эффектив-

ности используемых приемов руководства.

Инициируется лицом, несущим непосредственную ответст-

венность за разработку системы. Планируется (в планах проекта).

Поддерживает принятие решений ЛПР (лицом, принимающим

решение) о корректирующих действиях, изменениях в распреде-

лении ресурсов проекта и др.

Объекты обзора – планы проекта, планы любых процессов,

отчеты о выполнении процессов, процедуры управления.

Продукт проверяется участниками (в количестве не менее 2

человек) до начала совещания (этап подготовки). Описание про-

блем передается лидеру. Лидер упорядочивает проблемы по сте-

пени важности. Знакомит с ними авторов продукта.

На совещании проблемы обсуждаются, оцениваются связан-

ные с ними риски, даются рекомендации ЛПР, предлагаются ме-

роприятия по улучшению процессов.

Процессы ЖЦ: совместный просмотр, V&V, SQA

Участники - руково-

дство проекта и пер-

сонал (заказчики и

пользователи - необя-

зательно)

Роли:

- ЛПР (принимает ре-

шение)

- лидер обзора (обу-

чен, готовит и ведет

совещание),

- секретарь (фиксиру-

ет проблемы),

- руководящий состав

(активно участвует в

обсуждении),

- персонал проекта

(предоставляет необ-

ходимую информа-

цию)

Коллегиальная проверка (Peer review)

Общее название методов проверки, имеющих следующие характерные особенности:

• участники проверки – коллеги автора продукта (равные в правах);

• участие лиц, занимающих руководящие посты по отношению к любому из членов

группы проверки, не допускается;

• лидеры группы имеют специальную подготовку (по применению методов);

• цель проверок – поиск дефектов, повышение качества продукта, совершенствование

процессов;

• рекомендуется сбор статистических данных (по продукту и процессу проверки).

Коллегиальная проверка институциализируется как ключевое направление процесса про-

граммной инженерии на 3-м уровне зрелости по модели СММ.