♦ определить их достоинства и недостатки.

♦ Количественно определить качество программного обеспечения.

♦ Понять необходимую документацию:.

♦ примерно по одному документу для каждой фазы водопадного процесса;.

♦ план для управления конфигурациями.

Главы 1, 2, 4, 5 и 6 разбиты на две части — «Основы» и «Детали». При первом прочтении каждую из частей «Детали» можно пропускать, откладывая их изучение на потом. Прохождение материала в таком порядке позволит студенческим командам разработать небольшой прототип их учебного проекта — реализацию избранных минимальных аспектов приложения, как объясняется в разделе 5 главы 3. Этот прототип может быть использован позже в ходе полного анализа требований (главы 3 и 4) и процесса проектирования (главы 5 и 6). Такой прототип должен быть максимально простым. Его основное предназначение — позволить команде попрактиковаться в совместной работе над проектом.

♦ Основы: разделы 1.1-1.5.

♦ Детали: разделы 1.6-1.9.

♦ Упражнения.

♦ Примеры:.

1) План управления конфигурациями программного обеспечения (SCMP);.

2) План контроля качества программного обеспечения (SQAP), часть 1 (часть 2 находится в конце главы 2).

Основы_.

1.1. Введение в процесс разработки программного обеспечения.

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

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

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

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

♦ Автономное:.

♦ устанавливаемое на одиночный компьютер;.

♦ не связанное с другим программным и аппаратным обеспечением;.

♦ пример — текстовый редактор.

♦ Встроенное:.

♦ часть уникального приложения с привлечением аппаратного обеспечения;.

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

♦ Реального времени:.

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

♦ пример — программное обеспечение радиолокатора.

♦ Сетевое:.

♦ состоит из частей, взаимодействующих через сеть;.

♦ пример — основанная на веб-технологии видеоигра.

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

1.1.1. Типичная схема разработки программного обеспечения.

Как же рождаются сложные и пригодные к использованию приложения? Стандартная последовательность шагов такова.

1.

Понять природу и сферу применения предлагаемого продукта.

2.

Выбрать процесс разработки и создать план. Раздел 1.4 и глава 2.

3.

Собрать требования. Главы 3 и 4.

4.

Спроектировать и собрать продукт. Главы 5, 6 и 7.

5.

Выполнить тестирование продукта. Главы 8 и 9.

6.

Выпустить продукт и обеспечить его сопровождение. Глава 10.

1.

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

2.

С самого начала проекта должна вестись документация, которая, скорее всего, будет изменяться и обновляться в ходе разработки. Поэтому сразу же необходимо определиться и со средствами, при помощи которых будут отслеживаться вносимые в документацию и в программный код изменения. Этот процесс называется управлением конфигурациями и рассматривается в разделе 1.7.3. Управление конфигурациями не является абсолютной необходимостью, но его отсутствие может привести к большим недоразумениям и общей потере продуктивности. Далее нужно определиться с самим процессом разработки. Разновидности методов разработки рассматриваются в разделе 1.4. Иногда стандарты, принятые внутри компании, определяют используемый процесс.

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

3.

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

4.

Затем наступает черед проектирования и реализации самого продукта. Этим вопросам посвящены главы 5, 6 и 7.

В зависимости от используемого процесса разработки шаги 3 и 4 могут быть выполнены несколько раз.

5.

Программный продукт, как окончательный, так и промежуточный, подлежит тщательному тестированию. Тестированию посвящены в главы 8 и 9.

6. Наконец, когда продукт выпущен, наступает фаза его сопровождения, включающая внесение в него исправлений и улучшений. Сопровождение, которое требует до 80 % ресурсов, потребовавшихся на разработку, рассматривается в главе 10.

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

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

1.2.1.

Становление инженерии программного обеспечения.

Разработка программного обеспечения является очень молодой и быстро развивающейся отраслью инженерной науки. Она подвержена постоянным и быстрым изменениям. Так, всего лишь в начале 90-х годов Британское сообщество вычислительной техники (British Computer Society) начало присваивать разработчикам программ звание инженера (Chartered Engineer), а в Соединенных Штатах только в 1998 году стало возможным хоть где-то (а точнее, в штате Техас) зарегистрироваться в качестве профессионального инженера программного обеспечения. Но по-прежнему, даже в начале двадцать первого века, общепризнанным остается тот факт, что разработке программного обеспечения не достает достаточно развитой научной базы. По некоторым оценкам, 75 % организаций, занимающихся разработкой программ, делают это на примитивном уровне. С другой стороны, в этой области сформировалось немало интересных идей, и мы надеемся, что знакомство с ними в рамках настоящей книги вдохновит читателя на собственное исследование.

1.2.2.

Влияние структурного.

и объектно-ориентированного программирования.

С момента зарождения технология разработки программ испытала несколько подъемов в своем развитии. Один из них связан с публикацией письма Эдсгера Дийкстры (Edsger Dijkstra) в Ассоциацию вычислительной техники (АСМ — Association for Computing Machinery), озаглавленного так: «О вреде использования операторов GOTO» [26]. В те времена программы писались с активным использованием операторов безусловного перехода. Обращая внимание на недостатки таких программ, Дийкстра предложил концепцию структурного программирования, позволяющую избежать использования этих операторов. Концепция Дийкстры основывалась на том наблюдении Бема и Якопини [12], что для записи любой программы в принципе достаточно только трех конструкций управления — последовательного выполнения, ветвления и цикла, то есть что теоретически необходимость в использовании операторов перехода отсутствует.

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

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

На объектно-ориентированной парадигме основаны современные языки и системы программирования, такие как Java и CORBA. Отметим, что CORBA позволяет приложениям использовать функции, написанные на различных языках, и выполнять их на различных платформах. В качестве примера в этом же контексте можно упомянуть Visual Basic и рассматриваемую в следующем разделе модель СОМ фирмы Microsoft.

В этой книге предполагается, что читатель владеет методами объектно-ориентированного программирования.

1.2.3. Повторное использование компонентов.

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

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

На уровне проектирования и реализации повторное использование программных кодов упрощается благодаря появлению таких стандартов, как COM (Component Object Model) и Java Beans. СОМ-объекты являются примером инструмента модульного программирования. Идею СОМ-объектов иллюстрирует рис. 1.4. СОМ-объект Счет — это фактически исполняемый модуль среды Windows, который может быть динамически использован любым другим приложением Windows. Этот объект поддерживает три интерфейса. В частности, он поддерживает интерфейс Identification, то есть в этом объекте имеется, например, функция setNameC...) и т. п. Основная идея состоит в том, что объект Счет может быть использован сколь угодно часто, так как мы знаем, для чего он предназначен. Заметим, что одни СОМ-объекты могут строиться из других СОМ-объектов и могут представлять довольно большие сущности, как, например, целая электронная таблица.

На общем уровне, согласно [80], программный компонент определяется как «элемент программы, обладающий следующими двумя свойствами:.

♦ этот элемент может использоваться другими элементами программы, которые при этом называются клиентами;.

♦ автору этого элемента нет необходимости знать клиенты и их авторов». Хорошим источником сведений по общей концепции программных компонентов является [105].

1.2.4. Формальные методы.

К формальным относятся те методы проектирования программ, которые основаны на математике. В свое время Дийкстра [25], Хоар [44] и другие указывали, что поскольку программы имеют точно определенное поведение, они могут рассматриваться как математические объекты. При этом полезно вспомнить, что развитие многих других инженерных дисциплин происходило именно на математической основе. Так, например, электротехника имеет глубокие корни в математике, и последняя в настоящее время является неотъемлемой частью электротехнического образования. Многие утверждают, что нечто аналогичное должно произойти и с разработкой программ.

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

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

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

1.2.5. Удобство и простота использования.

Важной составляющей разработки программ является проектирование взаимодействия пользователя с программой. В частности, широкое применение графического пользовательского интерфейса ведет к тому, что многие аспекты разработки приложений лежат за пределами математики и даже алгоритмики (например, [109]) и, в частности, требуют серьезного внимания к психологическим основам взаимодействия человек — машина. В настоящей книге вопросы пригодности к использованию рассматриваются как составная часть анализа требований (главы 3 и 4), проектирования (главы 5 и 6) и тестирования (глава 9).

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

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

Эта книга посвящена прежде всего процессу, проекту и продукту. Вопросы, касающиеся персонала, рассматриваются лишь частично и ограничиваются в основном затрагиваемыми в главе 2 ключевыми факторами, обусловливающими успешность проекта. Для получения подробных сведений по этим вопросам мы рекомендуем книги Брукса [18] и Хэмфри [54].

В современной практике разработки программного обеспечения существует пять ключевых требований, в основном сформулированных Хэмфри [50] (рис. 1.5). Первое из них — заранее выбрать свою шкалу измерения качества для проекта и продукта. Например, «500 строк полностью протестированного программного кода, написанного одним человеком за месяц» или «не более трех ошибок на тысячу строк программного кода». Второе требование состоит в сборе информации по всем проектам с целью создания базы для оценки будущих проектов. Третье положение гласит, что все требования, схемы, программные коды и материалы тестирования должны быть легко доступны всем членам команды. Суть четвертого условия состоит в том, что все участники команды должны следовать избранному процессу разработки

. Роль четырех «П» в достижении пяти ключевых требований демонстрирует рис. 1.5. При этом подчеркивается тот факт, что ничто не может быть достигнуто без участия членов команды, работающей над проектом. Например, создание программ только согласно выбранным решениям (пункт 4, б на рис. 1.5) — это требование, которое может быть проконтролировано в проектах и которое потребует определенных усилий от персонала, работающего над проектом.

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

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

1.3.1. Артефакты и роли.

В понятие продукта разработки включается не только программный код — сюда относятся различные артефакты, такие как планы, отчеты, диаграммы. Кроме того, участвующие в процессе разработчики играют разнообразные роли. В терминологии рассматриваемого далее Унифицированного процесса разработки программного обеспечения (USDP) [64] эти роли называются работниками (workers). Используемая в USDP нотация для артефактов и работников приводится на рис. 1.6. В главах 5 и 6, посвященных программному проектированию, мы рассмотрим так называемые модели, позволяющие описывать проектирование с различных точек зрения.

1.4. Разновидности процесса разработки.

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

1.4.1. Водопадная модель процесса.

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

♦ Анализ требований состоит в сборе требований к продукту. Результатом анализа, как правило, является некоторый текст. Эта стадия рассматривается в главах 3 и 4.

♦ Проектирование описывает внутреннюю структуру продукта. Обычно такое описание дается в форме диаграмм и текстов. Этот этап рассматривается в главе 5 (архитектура) и в главе 6 (детальное проектирование).

+ Реализация — это программирование. Результатом реализации является программный код всех уровней, будь то код, генерируемый высокоуровневой системой программирования, компилятором языка четвертого поколения или какой-либо другой. Фазе реализации посвящена глава 7.

♦ Интеграция — это процесс сборки всего продукта из отдельных частей. Интеграция и тестирование рассматриваются в главах 8 и 9.

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

Иногда водопадный процесс расширяют (рис. 1.8) следующими дополнительными фазами.

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

♦ Объектно-ориентированный анализ, состоящий в выделении ключевых классов (раздел 1.2.2 и глава 6) и выполняемый после анализа требований и до фазы проектирования.

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

♦ Сопровождение, состоящее в модификации и внесении исправлений в приложение и осуществляемое в самом конце процесса (глава 10).

В чистом виде водопадный процесс применяется достаточно редко, разве что в случае небольших проектов или когда команда реализует проект, очень похожий на один из тех, что были осуществлены ею ранее. Основной причиной неприменимости водопадного процесса в чистом виде является сложность большинства приложений. В нашей книге мы используем в качестве примера программного продукта ролевую игру, однако существует столь много различных толкований понятия «ролевая видеоигра» (RPG — Role-Playing Game), что было бы совершенно непрактично попытаться определить все до последнего требования к нашей игре, прежде чем приступать к проектированию и реализации. Тем не менее водопадный процесс является основой для большинства других разновидностей процесса.

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

1.4.2. Спиральная модель процесса.

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

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

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

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

И все же для большинства программных проектов преимущества спирального процесса перевешивают его недостатки. Здесь можно сослаться на опыт Министерства обороны США, которое, признав эти преимущества, в 80-х годах отказалось от принятой им ранее установки на использование простой водопадной модели во всех программных проектах.

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

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

1.4.3. Инкрементальная модель процесса.

Иногда представляется возможным понемногу продвигать проект вперед при практически непрерывном процессе. Такая модель процесса особенно полезна на поздних стадиях проекта, когда продукт находится на сопровождении или когда разрабатываемый продукт очень схож с созданным ранее. Например, Кукумано и Сэлби [21] подготовили доклад по процессу, используемому в некоторых отделениях корпорации Microsoft, где обновления программного кода и документации представляются ежедневно к конкретному времени для интеграции и ночного тестирования. Другие организации используют для этого недельные циклы. Для поддержания соответствующего уровня инкрементальной разработки необходимо иметь четко установленную архитектуру проекта и исключительно синхронизированную систему документации (рис. 1.10). Для организации инкрементальной разработки обычно выбирается характерный временной интервал, например неделя. Затем в течение этого интервала происходит обновление исходного проекта (документации, набора тестов, программного кода и т. д.). Теоретически шаги разработки (increments) могут выполняться и параллельно, но такой процесс очень сложно скоординировать. Инкрементальная разработка проходит лучше всего, если следующая стадия п+1 начинается по возможности после того, как обновление всех модулей на стадии п закончено, и хуже всего, если время, требуемое на обновление модулей, значительно превышает выбранный интервал. Для того чтобы убедиться в этом, представьте, что необходимо изменить модуль 789, который зависит от семи других модулей: 890, 23, 489, 991, 7653, 2134 и 2314. Если изменение занимает девять недель, то модуль 789 должен быть построен исходя из предполагаемого состояния всех семи модулей через девять недель. Эту работу очень трудно скоординировать, так как каждая из семи частей может быть изменена до девяти раз (еженедельно), причем каждое новое изменение может основываться на исследовании эффективности предыдущих изменений.

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

1.4.4. Унифицированный процесс разработки программного обеспечения (USDP).

Унифицированный процесс разработки программного обеспечения (USDP — Unified Software Development Process) впервые был предложен в книге Якобсона, Буча и Рамбо [64], изданной в 1999 году. Этот процесс является детищем более ранних методологий, разработанных этими тремя авторами: «Объектная методология» Якобсона, «Методология Буча» [14] и «Техника объектного моделирования» Рамбо [96].

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

♦ Начальные итерации — предварительные (подготовительные) взаимодействия с акционерами:.

♦ основной покупатель;.

♦ пользователи;.

♦ инвесторы;.

♦ другие.

♦ Итерации проектирования: их завершение желательно и просто необходимо; выбор базовой архитектуры.

♦ Итерации конструирования: приводят к изначальной оперативной способности.

♦ Итерации перехода: выпуск готового продукта.

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

С учетом приведенной выше классификации итераций, USDP может быть представлен матрицей (рис. 1.11 и рис. 1.12). Как и большинство процессов объектно-ориентированного анализа и проектирования, фазы водопадного процесса, представленные Якобсоном, также включают в себя фазу анализа. На рис. 1.11 показано, где эта фаза совпадает с классическими фазами водопадного процесса. Анализ состоит из той части процесса анализа требований, в которой выбираются и соотносятся между собой базовые классы приложения. Кроме того, в USDP отсутствует своя фаза интеграции, обычно представленная в классическом водопадном процессе. Это произошло в связи с убежденностью Буча [15] в том, что объектно-ориентированные приложения могут и должны использовать непрерывную интеграцию. Другими словами, сразу после добавления новых частей исходное приложение интегрируется. Таким образом, отпадает необходимость в специальной фазе интеграции.

Приблизительный тип и уровень работ для каждого базового рабочего итерационного процесса USDP показан на рис. 1.13. Большинство итераций в разной степени затрагивают практически все фазы водопадного процесса (базовые рабочие процессы). Начальные итерации содержат в основном анализ требований, непосредственно анализ, а также могут включать проектирование и реализацию для создания предварительного прототипа, который может быть использован для обсуждения проекта с заинтересованными сторонами. Итерации проектирования затрагивают в основном анализ требований, а также некоторую часть проектирования и реализации. Итерации конструирования включают в себя проектирование и реализацию, а итерации перехода — реализацию и тестирование.

USDP описывает шесть моделей (типов рассмотрения свойств приложения) (рис. 1.14). Эти модели будут обсуждаться в дальнейшем, при этом не всегда будет использоваться терминология USDP. Модель вариантов использования описывает случаи, в которых приложение будет использоваться. Аналитическая модель описывает базовые классы для приложения. Модель проектирования описывает связи и отношения между классами и выделенными объектами. Модель развертывания описывает распределение программного обеспечения по компьютерам. Модель реализации описывает внутреннюю организацию программного кода. Модель тестирования состоит из тестирующих компонентов, тестовых процедур и различных вариантов тестирования.

1.4.5. Сравнение процессов разработки.

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

Далее следуют пояснения к табл. 1.1.

1.

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

2.

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

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

ОДИН ИЗ СПОСОБОВ ВЫБОРА ПРОЦЕССА РАЗРАБОТКИ -.

Последовательность шагов, позволяющая команде студентов решить, каким процессом.

воспользоваться, может быть следующей.

1.

Выберите, какой из процессов вам больше подходит: водопадный, спиральный или инкрементальный.

♦ Для семестрового проекта обычно используется спиральный процесс.

♦ Допускается комбинирование. Например, начинаем проект со спирального процесса, а под конец используем инкрементальный.

2.

Решите вопрос о количестве итераций:.

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

♦ три итерации предоставляют больше практики, однако это риск. Делайте первое приращение как можно меньшим;.

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

3.

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

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

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

1.5. Документация.

1.5.1. Введение в документирование.

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

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

Листинг 1.1. Недокументированный код.

int a(int 1. char с) {.

if(c== "m") if(i

< 1000) return 0:.

else.

if(i

< 10000) return 500:.

else.

return 1200:.

else.

return 1300:.

}.

Листинг 1.2. Частично документированный код.

"int taxdnt anEarning. char aStatus).

{.

if(aStatus == "m").

if(anEarning

< 1000).

return 0: // Женатые не облагаются налогом.

else.

if(anEarnlng

< 10000).

return 500: // Женат. S1000-S10000.

else.

return 1200: // Женат. >

=$10000 // Если не женат, то использовать ставку налога в размере $1300 else.

return 1300:.

}.

Когда мы смотрим на тщательно документированный программный код (листинг 1.3), его значение становится намного понятнее. Благодаря документированию мы узнаем очень важный новый факт, заключающийся в том, что приведенные ставки заработной платы действительны только для ограниченного отрезка времени. Ссылка на одно из требований в SRS является еще одной важной частью документации. Символы, которым предшествует относятся к зарезервированным словам Javadoc. Они будут подробно рассмотрены в главе 8.

Листинг 1.3. Документированный код.

* Этот метод реализует требование 4.3:.

* "Установить действие налога с 01.09.98 по 31.12.99".

* @ author Э. Брауде.

* (3 version 2.3.4 (08.06.98).

* @ param anEarning: зарплата.

* I? param aStatus: m" означает "женат", иное означает "не женат".

*/.

int tax(int anEarning, char aStatus) { . . .

Однако история этой части программного кода еще не окончена. Благодаря управлению конфигурациями из документа План управления конфигурациями ПО мы узнаем, что текущей версией tax() является 2.7.3, а используется версия 2.3.4. Другими словами, фрагмент кода, рассмотренный нами, во многом уже не относится к делу, так как текущая версия 2.7.3 может выглядеть совсем по-другому.

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

1.5.2. Стандарты документации.

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

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

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

Организации должны делать стандарты как минимум простыми и понятными. Организации могут допускать некоторую гибкость и автономность в этом вопросе, но при этом рассчитывать на получение определенной стандартной информации для улучшения всего процесса производства. Например, организация вправе рассчитывать на получение данных, включающих в себя время, потраченное на разработку приложения, и объем программного кода, измеренные указанным способом. Такие стандартные измерения позволяют использовать данные по всей организации. Улучшение процесса включает в себя эволюционный метапроцесс (процесс, имеющий дело с другими процессами) внутри организации. Одним из примеров является модель зрелости возможностей (СММ), которая классифицирует организации, занимающиеся разработкой программного обеспечения, по пяти категориям возрастающих возможностей. Эта модель рассматривается в разделе 1.8.3.

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

♦ Институт инженеров по электротехнике и радиоэлектронике (IEEE, www. ieee.org) в течение многих лет остается очень активен в создании стандартов документации программного обеспечения. Большинство стандартов разработаны различными комитетами, состоящими из опытных и ответственных инженеров-профессионалов. Некоторые из стандартов IEEE стали также стандартами ANSI. Эта глава, например, ссылается на три стандарта IEEE (разделы 1.6.5, 1.7.2 и 1.7.3).

♦ Международная организация по стандартизации (ISO) имеет огромное влияние во всем мире, особенно среди организаций производителей, имеющих дело с Евросоюзом (ЕС). ЕС предписывает следование стандартам ISO любой компании, имеющей дело со странами — членами Евросоюза, что является мощным стимулом для поддержания этих стандартов странами всего мира.

+ Институт технологий разработки программного обеспечения (SEI) был учрежден Министерством обороны США в университете Карнеги-Меллон для поднятия уровня технологии программного обеспечения у подрядчиков Министерства обороны. Работа SEI также была принята многими коммерческими компаниями, которые считают улучшение процесса разработки программного обеспечения своей стратегической корпоративной задачей. В этой главе приводится важный стандарт, разработанный SEI, который называется Моделью зрелости возможностей (СММ).

♦ Консорциум по технологии манипулирования объектами (OMG, www. omg.org) является некоммерческой организацией, в которую в качестве членов входят около 700 компаний. OMG устанавливает стандарты для распределенных объектно-ориентированных вычислений. В частности, OMG использует унифицированный язык моделирования UML в качестве своего стандарта для описания проектов. Например, нотация интерфейса, использованная в описании технологии СОМ на рис. 1.4, является UML-нотацией.

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

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

Ниже приводится описание каждого документа из набора IEEE с ссылками на полные описания в этой книге. Другие стандарты внутренне организованы по тому же принципу.

♦ SWP (Software Verification and Validation Plan): План экспертизы программного обеспечения. Этот план определяет, каким образом и в какой последовательности должны проверяться стадии проекта, а также сам продукт на соответствие поставленным требованиям. Верификация — это процесс проверки правильности сборки приложения; валидация проверяет тот факт, что собран требуемый продукт. Полностью это описано в разделе 1.6.6. Зачастую валидацию и верификацию осуществляют сторонние организации, в этом случае экспертиза называется независимой (IV&V — Independent V&V).

♦ SQAP (Software Quality Assurance Plan): План контроля качества программного обеспечения. Этот план определяет, каким образом проект должен достигнуть соответствия установленному уровню качества. Подробные объяснения можно найти в разделе 1.6.5, в примере в конце этой главы и в главе 2.

♦ SCMP (Software Configuration Management Plan): План управления конфигурациями программного обеспечения. SCMP определяет, как и где должны храниться документы, программный код и их версии, а также устанавливает их взаимное соответствие. Было бы крайне неразумным начинать работу без такого плана, так как самый первый созданный документ обречен на изменения, а мы должны знать, как управлять этими изменениями до того, как мы начнем составлять документ. В этой главе приводится описание IEEE SCMP. Для примера мы ограничимся довольно простым планом, приведенным в конце этой главы. Средние и большие компании, как правило, стараются выработать единое управление конфигурациями для всех своих проектов. Таким образом, инженерам требуется только научиться следовать предписанным процедурам в соответствии с SCMP. SCMP описывается далее в разделе 1.7 и в примере в конце главы.

♦ SPMP (Software Project Management Plan): План управления программным проектом. Этот план определяет, каким образом управлять проектом. Обычно он соответствует известному процессу разработки, например стандартному процессу компании. SPMP обсуждается в главе 2, которая посвящена управлению проектом.

4- SRS (Software Requirements Specification): Спецификация требований к программному обеспечению. Этот документ определяет требования к приложению и является подобием контракта и путеводной нити для заказчика и разработчиков. SRS рассматривается подробнее в главах 3 и 4.

♦ SDD (Software Design Document): Проектная документация программного обеспечения. SDD представляет архитектуру и детали проектирования приложения, обычно с использованием диаграмм объектных моделей и потоков данных. Подробнее о SDD см. в главах 5 и 6.

♦ STD (Software Test Documentation): Документация по тестированию программного обеспечения. Этот документ описывает, каким образом должно проводиться тестирование приложения и его компонентов. Подробные пояснения см. в главах 8 и 9.

Иногда в проектах привлекается дополнительная документация (например, см. [56]). Документация для итеративной разработки может быть организована двумя способами. Некоторые документы, в частности SDD, могут содержать свою версию для каждой итерации. Другой способ — дописывать дополнения, которые появляются по мере развития приложения.

Унифицированный язык моделирования (UML) был разработан для стандартизации описания программных проектов, в особенности объектно-ориентированных. UML был принят в качестве стандарта консорциумом OMG. Эта книга использует UML в качестве нотации для различных артефактов, включая проектирование и физическую конфигурацию исходных файлов. Выборочно UML описан непосредственно в тексте книги.

ОДИН ИЗ СПОСОБОВ ОПРЕДЕЛЕНИЯ -.

НЕОБХОДИМОСТИ ТОЙ ИЛИ ИНОЙ ДОКУМЕНТАЦИИ.

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

1.

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

♦ SCMP* — раздел 1.7.3.2.

2.

Установите, кто что будет делать и когда они будут это делать.

♦ SPMP* — глава 2.

3.

Задокументируйте, что должно быть реализовано.

♦ Для себя, для заказчика, для вашей команды;.

♦ SRS* — главы 3 и 4.

4.

Задокументируйте проектирование приложения до того, как приступать к программированию.

♦ SDD* — главы 5 и 6.

5.

Напишите и задокументируйте программный код.

♦ Основы кодирования рассматриваются в главе 7.

6.

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

♦ Благодаря этому тесты могут быть воспроизведены и дополнены.

♦ STD — главы 8 и 9.

Детали_.

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

1.6. Качество.

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

♦ удовлетворяет ясно сформулированным требованиям;.

+ проверяет входные данные и предсказуемо реагирует на некорректные входные данные;.

♦ тщательно проинспектирован не только самим автором кода, но и другими разработчиками;.

♦ прошел исчерпывающее многостороннее тестирование;.

♦ тщательно документирован;.

♦ имеет надежную оценку степени дефектности (процента ошибок).

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

Аналогично, высококачественный программный продукт обычно является:.

♦ расширяемым (готовым к возможным изменениям для расширения функциональности);.

4- развиваемым (легко адаптируемым к изменению требований);.

4- переносимым (пригодным к использованию на нескольких платформах);.

4 общим (применимым к нескольким различным ситуациям).

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

1.6.1. Метрики.

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

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

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

4 объем выполненной работы, измеренный в физических единицах (например, число строк кода);.

♦ время, затраченное на выполнение работы;.

♦ степень дефектности (число дефектов на 1000 строк кода, число дефектов на страницу документации и т. д.).

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

Предварительные или желаемые значения метрик заранее прогнозируются, а затем сравниваются с полученными результатами. Например, наша организация ожидает 0,2 дефекта на страницу описания требований (в среднем — один на пять страниц, как известно по прошлым проектам). Нашей целью для данного проекта может являться 0,15 дефекта на страницу. Реальная же степень дефектности может составлять 0,17. Это говорит о том, что наши методы лучше использованных в прошлом, однако недостаточно хороши для достижения поставленной цели.

1.6.2.

Процесс контроля качества.

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

В дополнение к ответственности индивидуальных разработчиков и проверкам работы их коллег многие организации определили процесс раздельной систематической и полной проверки, в дальнейшем — контроль качества (QA — quality assurance). В функции контроля качества входят проверки, инспектирование (формальный тип проверки, приводимый ниже) и тестирование. Контроль качества должен начинаться вместе с запуском каждого проекта (рис. 1.16). Лучше всего привлекать контроль качества и для проверки правильности используемого процесса и актуальности документации. Представитель группы контроля качества часто принимает участие в инспектировании. В идеале контроль качества должен осуществляться некоторой независимой организацией. Многие компании слишком малы для осуществления столь сложного контроля качества, и в этом случае сами инженеры осуществляют функции контроля качества по отношению к работе друг друга.

1.6.3.

Методы «белого ящика» и «черного ящика».

В случае контроля качества методом «черного ящика» приложение (или какаялибо его законченная часть) анализируется как целое. Этот метод используется для проверки того, что приложение (его часть) отвечает предъявляемым требованиям. Контроль качества методом «белого (стеклянного) ящика» осуществляется на уровне компонентов, из которых построено тестируемое приложение (его часть). Можно провести такую аналогию: если вы проверяете работу телевизора, просто включая и выключая его и переключая каналы, то вы применяете метод «черного ящика»; если же вы тестируете телевизор, анализируя его работу на уровне взаимодействия микросхем, то есть компонентов, из которых телевизор собран, вы применяете метод «белого ящика». Промежуточным является метод «серого ящика» (ситуация, когда вы проверяете основные компоненты телевизора). Заметим, что грань между «белым» и «серым» здесь зачастую расплывчата.

Чаще всего о методах «черного» и «белого ящика» говорят в контексте тестирования. Однако эти методы применимы и к другим способам контроля качества. Метод «белого ящика» основан на рассмотрении анализируемого артефакта с точки зрения его структуры, формы и назначения; здесь применяются формальные методы и рассматриваемое в следующем разделе инспектирование. Метод «черного ящика» задается вопросом: «Обладает ли построенный объект требуемым поведением?». Подробнее эти методы изучаются в главах 8 и 9.

1.6.4. Введение в инспектирование.

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

Основная идея инспектирования хорошо описана Фагином [30], который заметил, что автор в большинстве случаев способен исправить дефект своей работы, когда тог обнаружен. Таким образом, инспектирование необходимо использовать хотя бы для того, чтобы автор замечал дефекты в своей работе до того, как представит ее начальству. Подразумевается, что инспектирование выполняется коллегами по разработке. Это можно представить в виде следующего заключения: ♦ Авторы обычно в состоянии исправить найденные дефекты.

♦ Следствие: помогайте авторам находить дефекты до завершения работы.

♦ Следствие: пусть их коллеги ищут дефекты.

Принцип инспектирования может быть обобщен четырьмя правилами.

1.

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

2.

Участие коллег. Инспектирование проводится внутри группы разработчиков программного обеспечения и не предполагает вовлечения в отношения «начальник—подчиненный». Инспектируется текущая работа, а не способности ее автора. Автор несет ответственность только за конечный продукт, тогда как инспектирование проводится до того, как работа сдана. Однако работа, представленная автором для инспектирования, должна быть лучшим вариантом, но ни в коем случае не черновиком. Было бы пустой тратой ресурсов группы искать, находить и описывать дефекты, которые автор, приложив некоторые усилия, в состоянии найти сам.

3.

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

♦ Ведущий ответственен за правильное проведение инспектирования. Ведущий также является инспектирующим.

♦ Автор несет ответственность за свою работу и за исправление всех найденных в ней дефектов. Автор является одновременно и инспектирующим, проводящим время в поиске новых дефектов.

♦ Корректор отвечает за деятельность команды и направляет ее в нужное русло. Корректор принимает участие в инспектировании.

♦ Регистратор отвечает за учет описания и классификацию дефектов, как это принято в команде. Регистратор также участвует в инспектировании.

Далее приводятся дополнительные роли инспектирующих. Необходимость их введения зависит от специфики инспектируемых артефактов.

♦ Профильный инспектирующий проверяет артефакт по одному конкретному критерию (например, на надежность).

♦ Специализированный инспектирующий — это специалист в той области, которой принадлежит инспектируемый артефакт (например, эксперт по радиолокации для приложения управления радиолокатором.).

♦ Простой инспектирующий не имеет специальной роли, кроме проверки материала на наличие дефектов.

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

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

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

1.

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

2.

В ходе проекта ответственные лица просто должны назначать, какая группа сотрудников участвует в инспектировании и какие части проделанной работы должны быть проверены. Части должны быть логически завершенными. Итог инспектирования подводится на 1-4-часовом собрании (обсуждаемом ниже в пункте 5).

3.

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

4.

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

5.

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

6.

Как правило, автор в состоянии исправить все дефекты. Это называется фазой доработки. Если инспекционное собрание решает, что дефекты настолько серьезны, что требуется повторное инспектирование данного объекта, то объект еще раз запускается в процесс.

7.

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

8.

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

9.

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

Среднее относительное время для каждой фазы процесса инспектирования, используемое, например, одним из клиентов автора, приведено в табл. 1.2. Для определенности в качестве времени, отведенного на инспекционное собрание, взят один час. Самостоятельные компании и группы разработчиков ведут учет времени, потраченного на инспектирование, и объема проверенной работы с целью их дальнейшего использования при оценке будущих инспектирований. Время, приводимое в табл. 1.2, может обеспокоить непосвященных, сомневающихся в том, что проверка кода может отнимать столько времени. Производство профессиональных качественных продуктов действительно занимает значительное количество времени. На обнаружение ошибок в конечном итоге затрачивается намного больше времени, чем предполагалось изначально. По оценке Джеани и Лалли [36], на инспектирование уходит порядка 10-15 % бюджета разработки.

В различных источниках (например, [30]) отмечается, что инспектирование, несмотря на большие затраты времени экспертов и дороговизну проведения, вполне окупает себя. Если начать подсчитывать стоимость инспектирования, то можно схватиться за голову, однако всегда следует сравнивать эту стоимость со стоимостью пропущенных дефектов. В конечном итоге, все дефекты должны быть найдены и исправлены. Если это не делается вскорости после того, как дефект был внесен, то стоимость исправления катастрофически возрастает. Сравнение стоимости обнаружения и исправления дефекта во время инспектирования и во время интеграции приводится в табл. 1.3. Эти оценки, полученные от клиента автора, являются весьма сдержанными.

В данном примере (см. табл. 1.3) на отыскание каждого дефекта уходит от 0,7 до 2 часов, в случае если поиск ведется в рамках процесса инспектирования. С другой стороны, на это уходит от 0,2 до 10 часов при поиске дефектов в уже собранном приложении (то есть по окончании процесса разработки). Собрав эти данные для конкретной группы разработчиков и проекта, можно предсказать время, необходимое на тестирование, и т. д. Например, чтобы вычислить среднее время, затрачиваемое на поиск дефекта, необходимо количество часов, проведенных за тестированием, разделить на количество найденных дефектов.

Конкретные примеры выгоды от проведения инспектирования такими компаниями, как IBM, ICL и Standard Bank, приводятся в [37]. Основная выгода заключается в нахождении дефектов на ранних стадиях процесса разработки, и здесь цель оправдывает средства. По оценкам многих компаний, чем раньше начинают проводить инспектирование, тем больше экономия. В частности, непомерно высокий процент дефектов в продукте, как правило, является результатом искажения исходных требований. Например, представьте себе цену отыскания и исправления следующего дефекта в исходных требованиях.

♦ Реализованное требование: если температура достигает рубежа в 5,02 % до максимально допустимого предела, то, как определено стандартом 67 892, мотор должен быть отключен.

♦ Настоящее требование: если температура достигает рубежа в 5,02 % до максимально допустимого предела, то, как определено стандартом 67 892, работа мотора должна быть завершена.

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

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

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

ОДИН ИЗ СПОСОБОВ ПОДГОТОВКИ И ПРОВЕДЕНИЯ ИНСПЕКТИРОВАНИЯ -.

1.

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

♦ спланируйте инспектирование всех фаз начиная с подготовки требований;.

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

2.

Подготовьтесь к накоплению данных по инспектированию:.

♦ учитывать количество дефектов на одну логически законченную часть работы (например, на тысячу строк кода), потраченное время;.

♦ разработать классификацию дефектов по описанию, степени серьезности и типу;.

♦ решить, кто, где и как должен хранить и использовать метрические данные;.

♦ при невыполнении: назначить одного ответственного за это человека;.

♦ обычно при устранении ошибок данные сбрасываются.

3.

Обозначить роли участников инспектирования:.

♦ «третий — не лишний» (автор; посредник-регистратор; корректор);.

♦ «одна голова — хорошо, а две — лучше» (автор; инспектирующий);.

4.

Обеспечить подготовленность каждого участника.

5.

Классифицировать ошибки перед обсуждением на инспекционном собрании.

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

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

1.6.5. План контроля качества (SQAP): стандарт IEEE.

Для учета всех факторов контроля качества удобно пользоваться списками контрольных вопросов. Такие списки содержат пункты, которые необходимо последовательно проверить, они особенно удобны при использовании стандартов проектирования. Первые шесть разделов содержания стандарта IEEE 730 перечислены ниже. Остальные разделы будут рассмотрены в главе 2. В основном стандарт IEEE больше приспособлен для обширных проектов, но подходит и для малых. Стандарт напоминает нам обо всех факторах, которые должны быть учтены, и позволяет легко отбросить части, не относящиеся к конкретному проекту.

1.

Цель.

2.

Задействованные документы.

3.

Управление.

3.1.

Организация.

3.2.

Задачи.

3.3.

Ответственность.

4.

Документация.

4.1.

Цель.

4.2.

Минимальные требования к документации.

4.3.

Прочее.

5.

Стандарты, практики, соглашения и метрики.

5.1.

Цель.

5.2.

Содержание.

6.

Обзоры и аудиты.

6.1.

Цель.

6.2.

Минимальные требования.

6.2.1.

Обзор требований к программному обеспечению.

6.2.2.

Предварительный обзор проектных решений.

6.2.3.

Критический обзор проектных решений.

6.2.4.

Обзор SVVP.

6.2.5.

Аудит функциональности.

6.2.6.

Аудит физических компонентов.

6.2.7.

Аудит процесса.

6.2.8.

Обзор управления.

6.2.9.

Обзор SCMP 6.2.10. Окончательный обзор.

6.3.

Прочее.

7-15. См. следующую главу (раздел 2.12.2). Данный документ определяет:.

♦ кто будет нести ответственность за качество (раздел 3 этой главы) — физическое лицо, менеджер, группа, организация и т. п;.

♦ какая документация требуется (раздел 4 этой главы) — (глава 2, Управление проектом);.

♦ какие методы будут использоваться для гарантии качества (раздел 5 этой главы) — инспектирование, доказательство корректности, тестирование и т. д;.

♦ какие мероприятия должны быть проведены в ходе управления процессом (раздел 6 этой главы) — собрания, аудиты, обзоры и т. п.

1.6.6. Верификация и валидация.

Верификация и валидация (V&V — Verification and Validation) являются составной частью плана контроля качества. Верификация отвечает на вопрос «Правильно ли построен наш объект?». Или более детально: «Делаем ли мы на данной фазе в точности то, что было запланировано в предыдущей фазе?». Валидация же отвечает на вопрос: «Делаем ли мы то, что нужно?». Или другими словами: «Отвечает ли построенный объект пожеланиям и нуждам заказчика?». Разницу между этими понятиями иллюстрирует рис. 1.18. К сожалению, в литературе термины верификация и валидация часто путаются. Мы же далее будем использовать эти термины именно в соответствии с данным определением.

Чтобы закрепить наше понимание различия между верификацией и валидацией, приведем простой пример. Заказчик хочет, чтобы мы разработали приложение, которое «решает линейные уравнения вида ax + b =~ с». Мы формулируем это пожелание в виде следующих детальных требований.

1.

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

2.

Приложение отыскивает решение уравнения ах + b = с с точностью до 1/1000.

Затем мы пишем программу, реализующую эти требования.

Валидация нашей программы состоит в прогоне набора тестов. Например, мы вводим а = 1, b = 1, с = 1 и проверяем, что программа выдает х = 0. (Подробнее о тестировании — в главах 8 и 9). Тестирование выявляет наличие каких-либо дефектов в программе, но не позволяет убедиться, что дефекты в программе отсутствуют. Иными словами, на основе валидации мы не можем гарантировать, что наша программа не содержит дефектов.

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

1.

Получение требований заказчика.

2.

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

3.

Подготовка кода программы.

4.

Тестирование программы.

Верификация будет заключаться в следующих проверках.

♦ 1 —> 2. Соответствуют ли детальные требования тому, что заказчик действительно хочет? Здесь верификация может включать в себя следующие пункты: может ли быть а = 0? Если да, то что в этом случае должна делать программа? Если нет, то, возможно, заказчику требуется решать уравнения вида х + b = с вообще, возможно, что заказчику естественнее задавать линейное уравнение в каком-либо другом виде; обсуждение с заказчиком.

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

♦ 2 —» 3. Реализует ли код программы сформулированные требования? Это подразумевает инспектирование кода, в процессе которого код анализируется с точки зрения соответствия каждому отдельному требованию. Анализ может включать в себя математические доказательства или основываться на них.

♦ 3 44. Достаточно ли выполненный (или подготовленный) набор тестов охватывает область применимости программы? Инспектирование тестов (главы 8 и 9).

1.6.6.1. Стандарт IEEE 1012-1986.

Стандарт IEEE 1012-1986 для верификации и валидации задает основу, с помощью которой определяется, каким образом должны проводиться верификация и валидация. Стандарт 1012-1986 был переутвержден в 1992 году. В идеале одинаковые процедуры верификации и валидации должны применяться ко всем проектам компании. Лучше всего, если валидацией и верификацией занимается сторонняя организация (независимая экспертиза, обозначаемая IV&V). Оглавление этого стандарта приводится далее.

1.

Цель.

2.

Задействованные документы.

3.

Определения.

4.

Обзор V&V.

4.1.

Организация.

4.2.

Основной график работ.

4.3.

Ресурсы.

4.4.

Ответственность.

4.5.

Инструменты, техники, методики.

5.

Жизненный цикл V&V.

5.1.

Управление V&V.

5.2.

Фаза концепции V&V.

5.3.

Фаза требований V&V.

5.4.

Фаза проектирования V&V.

5.5.

Фаза реализации V&V.

5.6.

Фаза тестирования V&V.

5.7.

Фаза установки и прекращения V&V.

5.8.

Фаза работы и сопровождения V&V.

6.

Отчетность по V&V программного обеспечения.

6.1.

Обязательные отчеты.

6.2.

Дополнительные отчеты.

7. Административные процедуры V&V.

7.1.

Отчеты и решения относительно отклонений.

7.2.

Политика итеративности задачи.

7.3.

Политика уклончивости.

7.4.

Стандарты, практики и соглашения.

ОДИН ИЗ СПОСОБОВ ПРОИЗВОДСТВА -.

КАЧЕСТВЕННОГО ПРОГРАММНОГО ПРОДУКТА.

1.

Определитесь с уровнем качества:.

♦ минимально: количество дефектов на единицу кода;.

♦ в группе: количество неверных требований; количество отсутствующих в проекте классов; количество дефектов в тестировании; количество дефектов, найденных в ходе работы приложения;.

♦ персонально: учесть количество дефектов в коде, компилировать, тестировать модули по отдельности.

2.

Включите инспектирование и обзоры в график работы над проектом:.

♦ составление графика работ — в следующей главе;.

♦ следуйте схеме инспектирования (см. рис. 1.17).

3.

Документируйте ваши требования по качеству и все действия:.

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

♦ SQAP (пример в конце главы); если позволяет время — SWP.

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

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

Третий шаг касается спецификации желаемого уровня качества и процедур. Использование такого стандарта, как IEEE SQAP, предоставляет полный список проблем, которые необходимо решить. Написание и реализация SVVP обычно чересчур трудоемки для включения в односеместровый проект.

1.7. Управление документацией.

1.7.1.

Введение.

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

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

1.7.2.

Согласованность и целостность документации.

Ключ к поддержанию непротиворечивости состоит в том, что в документации каждая спецификация должна располагаться только в одном месте. Такую документацию мы называем целостной (single source documentation).

Для примера представим себе некоторое научное приложение с таким требованием: «счетчик числа бактерий является целочисленной переменной, принимающей значения от 1 до 100 ООО ООО; эта переменная должна быть всегда доступна». Это требование документируется в SRS, и, на первый взгляд, выглядит заманчивым повторить его в разных других местах — скажем, в исходном коде (в заголовке подходящей функции) и в руководстве пользователя. Однако прежде чем так сделать, полезно оценить те проблемы, к которым приводят подобные повторения. А проблемы эти проистекают из неизбежных изменений, которым подвергается проект на протяжении всего своего жизненного цикла и которые требуется отражать в документации. Если потребовалось изменить наше требование, касающееся счетчика числа бактерий, это изменение нужно отразить везде, где оно повторяется. Отразить все изменения в спецификациях с отслеживанием всех мест, где эти спецификации повторяются, практически нереально, особенно если принять во внимание, что обычно это приходится делать в условиях сжатых сроков выполнения проекта. Поэтому подобные повторения являются источником противоречивости в документации, а противоречия ведут к неудаче проекта. Разумеется, мы не можем избежать необходимости ссылаться из разных мест на один и тот же факт, но делать это нужно, не нарушая целостности документации, например, используя механизм гиперссылок.

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

Динамические компоненты, отмеченные на рис. 1.19, — это те части документов, которые должны обновляться и (или) дополняться в ходе работы над проектом. Другими словами, большинство документов — «живые» объекты, о которых необходимо заботиться. Пример тому — SCMP, который описывает версии конкретного документа. При внесении дополнений и изменений в ходе итеративной разработки проекта часто проводится обновление SRS.

Иногда встречаются ситуации, в которых просто необходимо переопределить требование (представить его в другом виде). Например, руководства пользователя пишутся в несколько иной манере, нежели документация разработки. К тому же иногда требуется многоуровневая структура документации. Так, на одном уровне нужен только краткий обзор, тогда как на другом — все до малейших деталей. Усложнение структуры документации может привести к несогласованности ее ведения. Решением проблемы с несогласованностью в документации могут стать гиперссылки при условии поддержки перекрестных ссылок. Например, некоторый обзорный раздел может ссылаться на соответствующие разделы с подробными описаниями или требование из SRS может ссылаться на соответствующий раздел в руководстве пользователя. Это не избавляет от повторного изложения одного материала, но облегчает поддержку целостности, поскольку обе версии виртуально находятся «рядом». В главе 7 приведен пример целостной документации, где заголовки функций в исходном тексте программы ссылаются на соответствующие требования в SRS.

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

1.7.3. Управление конфигурациями.

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

Незаконченное строительство дороги — хороший пример идущего инженерного проекта. Его легко увидеть, и уж конечно невозможно потерять! Мы же должны быть гораздо аккуратнее во время работы над программным продуктом, поскольку он или какая-то из частей как раз могут быть потеряны. Говоря о потере продукта или его части, мы имеем в виду не столько потерю самих файлов, сколько несоответствие их версий. Важнейшим требованием к ведению проекта является знание точного местонахождения частей проекта и связей, установленных между ними. Части проекта включают в себя не только исходный текст программ, но и всю документацию, в том числе план проекта. По этой причине мы столь рано начинаем говорить в этой книге об управлении конфигурациями. Мы должны уметь отслеживать изменения в документах еще до того, как разработан SPMP (глава 2).

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

1.7.3.1. Элементы конфигурации.

Для отслеживания частей проекта сначала мы должны определить их границы. Элементы конфигурации (CIs — configuration items) — это части проекта, отслеживаемые системой управления конфигурациями. Например, как показано на рис. 1.20, шестая версия метода расчета социальных отчислений для модуля подготовки платежных ведомостей некой бухгалтерской системы может быть названа элементом конфигурации S6.

Элемент конфигурации может состоять из других элементов конфигурации. Так, на рис. 1.20 элемент «Платежная ведомость версии 0.3.4.2» — модуль подготовки платежных ведомостей бухгалтерской системы — состоит из версии 6 части S, версии 1 части А, версии 3 части Е и т. д. В первом примере метод расчета выплат S обновляется с S6 до S7. Во втором к системе добавляется новый метод F1. Система конфигураций должна уметь различать все эти версии. На рис. 1.20 видно, что для этого изменяется номер версии модуля. Обычно классы — это отдельные элементы конфигураций. Отдельные функции могут быть элементами конфигураций, хотя это и не типичный случай. Мы не будем использовать элементы конфигураций мельче, чем функции, так как отслеживание составляющих частей функции практически неосуществимо. Значимые наборы данных, такие как глобальные таблицы, тоже могут быть элементами конфигураций.

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

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

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

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

Обычно системы управления конфигурациями удовлетворяют следующим минимальным требованиям.

♦ Деятельность по определению элементов конфигурации.

♦ Отказ в праве на модификацию — для предотвращения одновременной работы более чем одного человека над элементом конфигурации.

♦ Авторизация доступа с правом модификации — дополнительно (не обязательно).

♦ Процедура включения в проект:.

♦ процесс авторизации;.

♦ привлечение тестирования и т. д.

♦ Запись о предыдущих группировках согласующихся элементов конфигурации.

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

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

1.7.3.2. План управления конфигурациями (SCMP): стандарт IEEE 828-1990.

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

1.

Введение.

2.

Управление конфигурациями.

2.1.

Организация.

2.2.

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

2.3.

Применяемые политики, директивы и процедуры.

3.

Виды деятельности.

3.1.

Определение конфигурации.

3.1.1.

Определение элементов конфигурации.

3.1.2.

Именование элементов конфигурации.

3.1.3.

Получение элементов конфигурации.

3.2.

Контроль конфигурации.

3.2.1.

Запрос на изменения.

3.2.2.

Оценка изменений.

3.2.3.

Одобрение или неодобрение изменений.

3.2.4.

Реализация изменений.

3.3.

Определение статуса конфигурации.

3.4.

Аудиты и обзоры конфигурации.

3.5.

Контроль интерфейса.

3.6.

Контроль поставщиков и субподрядчиков.

4.

Расписание.

5.

Ресурсы.

6.

Сопровождение.

В разделе 3.3 SCMP задокументировано, каким образом определяется статус управления конфигурациями (например: письменно, раз в неделю). Раздел 3.6 присутствует, если используется специальный инструментарий для управления конфигурациями или если управление конфигурациями выполняется субподрядчиком. Стандарт IEEE подробно описывает назначение каждого из приведенных разделов. Мы пользуемся IEEE 828-1990 в примере в конце этой главы.

Широко используются коммерческие системы управления конфигурациями, такие как SourceSafe компании Microsoft.

ОДИН ИЗ СПОСОБОВ ПЛАНИРОВАНИЯ УПРАВЛЕНИЯ КОНФИГУРАЦИЯМИ -.

1.

Составьте наборосок вашего SCMP:.

♦ установите порядок действий при внесении изменений;.

♦ не указывайте ссылки на инструменты, если они еще не определены;.

♦ обратитесь к примеру в конце этой главы.

2.

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

♦ В учебных заданиях достаточно блокировки и резервного копирования.

3.

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

♦ широко используются коммерческие инструменты;.

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

4.

Завершите ваш SCMP.

Для учебных команд вполне подойдут веб-сайты, такие как

, обеспечивающие хранение документации. Одним из простых способов систематизации доступа для модификации является изменение типа документа. Например, когда Джо берет SQAP на модификацию, то имя файла меняется с SQAP.txt на SQAP.joe. Хотя управление конфигурациями относится и к документации, и к исходному коду, соглашение об именовании файлов обычно планируется отдельно. Например, мы не можем заменить myClass.java на myCtass.joe, не нарушив при этом порядок компиляции. Некоторые группы поддерживают два комплекта файлов. В одном комплекте содержится текущая версия, являющаяся основой, которая может быть изменена только в ходе формального процесса. Другой комплект содержит версии, находящиеся в разработке.

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

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

1.8. Введение в методы оценки возможностей.

Разработка программного обеспечения стала восприниматься как одно из ценнейших качеств и возможностей организаций. Однако тут же возникает вопрос: «Как оценить эту возможность?», который в свою очередь приводит к вопросу: «Насколько мы готовы?». Немногие организации могут ответить на этот вопрос «Отлично».

Этот раздел описывает варианты оценки возможностей инженеров, команд и организаций в программных разработках. Уотте Хэмфри и Институт технологий разработки программного обеспечения (SEI) разработали Индивидуальный процесс разработки программного обеспечения, Командный процесс разработки программного обеспечения и Модель зрелости возможностей, чтобы оценить эти уровни возможностей. Данный раздел описывает каждый из этих вариантов и их взаимосвязи.

Разработка программного обеспечения может быть рассмотрена с точки зрения самостоятельного разработчика (раздел 1.8.1), команды (раздел 1.8.2) или целой организации (раздел 1.8.3).

1.8.1. Введение в Индивидуальный процесс разработки программного обеспечения (PSP).

Хэмфри весьма искусно определил, какими конкретно навыками должен обладать компетентный иженер — разработчик программного обеспечения. Они описаны в Индивидуальном процессе разработки программного обеспечения (PSP — Personal Software Process), который «предоставляет детальные описания методов планирования и оценки, показывает разработчикам, как измерять собственную продуктивность и соотносить ее с существующим планом, и объясняет, почему описанные методы могут помочь им в их работе» [52]. Предполагается, что PSP помогает выработать определенные рабочие навыки, особенно связанные с количественной оценкой работы. (Как много времени я провел над этим кодом? И сколько написал строк? А сколько ошибок в них допустил? И так далее.) При этом PSP предполагает, что инженер уже обладает знаниями непосредственно в области программирования.

PSP делится на стадии постепенного роста, названные PSPO, PSP1, PSP2 и PSP3 [49] (рис. 1.21).

♦ PSP0: Базовый процесс.

PSP0 разрешает студенту пользоваться собственными методами разработки, но требует от него:.

♦ записывать время, затраченное на работу над проектом;.

♦ записывать найденные дефекты;.

♦ записывать типы дефектов.

PSP0 дополняется PSP0.1, который предписывает студенту выбрать:.

♦ стандартное определение понятия «строка кода»;.

♦ способ для указания того, как он мог бы улучшить свои навыки разработчика.

♦ PSP1: Индивидуальный процесс планирования.

PSP1 призван помочь инженеру полнее понять отношение между размером программы и временем, которое он тратит на ее разработку. PSP1 должен сформировать упорядоченную систему, в рамках которой инженер может производить оценки, выполнять задачи, проверять статус работы и записывать результаты. Всем разработчикам ПО постоянно задается один и тот же вопрос: «Сколько времени у вас это займет?». PSP помогает инженерам научиться реалистично отвечать на этот вопрос. PSP1 добавляет следующие требования к PSP0:.

♦ способность оценивать размер задачи;.

♦ систематический подход к описанию результатов тестирования. PSP1 дополняется PSP1.1, который описывает способности:.

♦ планировать программные задачи;.

♦ распределять их по времени и составлять график работы.

♦ PSP2: Индивидуальный процесс контроля качества.

PSP2 разработан, чтобы помочь инженерам объективно и реалистично справляться с программными дефектами. Идея заключается в том, чтобы обнаружить и исправить максимальное количество дефектов перед сдачей работы до формальной проверки-инспектирования (см. раздел 1.6.4). PSP2 включает в себя:.

♦ индивидуальную проверку проекта и архитектуры;.

♦ индивидуальную проверку кода.

PSP2 дополняется PSP2.1, который включает:.

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

♦ PSP3: Циклический индивидуальный процесс.

PSP3 предназначен для применения процесса PSP к большим программным модулям (содержащим тысячи строк кода) путем разбиения больших программ на меньшие этапы. PSP3 описывает:.

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

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

1.8.2. Командный процесс разработки программного обеспечения (TSP).

В 1999 году Уотте Хэмфри представил положительные результаты в постановке целей и процедур зрелости для командной разработки программ. Он назвал этот процесс Командный процесс разработки программного обеспечения (TSP — Team Software Process [50]). Перечислим задачи TSP.

♦ Собрать самоуправляемые команды:.

♦ 3-20 разработчиков;.

♦ установить собственные цели;.

♦ составить свой процесс и планы;.

♦ отслеживать работу.

♦ Показать менеджерам, как управлять командами:.

♦ инструктаж;.

♦ мотивация;.

♦ поддержка максимальной производительности.

♦ Ускорить продвижение по шкале СММ:.

♦ сделать пятый уровень СММ нормой.

♦ Обеспечить пути улучшения для высокоразвитых организаций.

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

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

1.8.3. Модель зрелости возможностей (СММ).

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

В 80-х годах Институт технологий разработки программного обеспечения (SEI) от имени Министерства обороны США установил простую классификацию возможностей субподрядчиков. План Министерства обороны состоял в том, чтобы давать оборонные заказы только таким подрядчикам, которые обладают определенным уровнем возможностей. Система, разработанная SEI, известна как Модель зрелости возможностей (СММ — Capability Maturity Model). СММ оказалась очень эффективной для определения уровня компетентности в разработке программного обеспечения. Многие организации, как военные, так и гражданские, использовали СММ для измерения своих усилий по улучшению процесса разработки. Например, вместо того чтобы характеризовать организацию как «достаточно хорошую» в области разработки программного обеспечения, можно точно указать, что организация «находится на уровне 3 по СММ». Среди известных автору организаций, которые намерены улучшить свои показатели по СММ, есть и мощные компании военно-промышленного комплекса, и компании, занимающиеся программным обеспечением проверки орфографии.

СММ классифицирует организации по пяти уровням следующим образом.

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

Процесс: не определен; зависит от конкретной задачи. Результат: зависит от индивидуальных способностей. Недостаток: нет четко заданного процесса.

♦ Уровень 2: Повторяемый. Уровень 2 соответствует организациям, которые до некоторой степени отслеживают свой процесс работы. Поддерживаются записи о трудозатратах и планах. Функциональность каждого проекта описана в письменной форме. Следовательно, возможно оценить затраты на разработку аналогичного проекта той же командой. Это заметное улучшение по сравнению с уровнем 1. Для дальнейшего улучшения необходимо иметь возможность оценивать затраты независимо от наличия или отсутствия конкретных людей в команде проекта. В середине 1999 года только 20 % организаций имели уровень 2 или выше.

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

♦ Уровень 3: Установленный. Уровень 3 соответствует организациям, которые имеют определенный, документированный и установленный процесс работы, не зависящий от отдельных личностей. Обычно это один из процессов, описанных в данной главе: водопадный, спиральный или инкрементальный. Некоторые организации используют существующие стандарты IEEE, в то время как другие определяют свои собственные корпоративные стандарты. Грубо говоря, как только руководство вводит в действие согласованные профессиональные стандарты, а разработчики их выполняют, организация достигает уровня 3. Обычно это предполагает проведение специального обучения персонала. Допускается настройка стандартного процесса для конкретной команды применительно к конкретным обстоятельствам. Хотя организации уровня 3 в состоянии производить программное обеспечение гарантированного качества и таких организаций относительно немного, им все же не хватает возможности точно предсказывать затраты на проект. Такие организации в состоянии достаточно надежно сделать предсказание только для проектов, которые полностью аналогичны уже выполненным ранее. Процесс: документированный; стандартный; настраиваемый. Результат: целостность.

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

♦ Уровень 4: Управляемый. Уровень 4 соответствует организациям, которые могут точно предсказать сроки и стоимость работы. Один из способов, которым это делается, состоит в том, чтобы классифицировать работы и их части и измерять и сохранять данные о стоимости и трудозатратах на проектирование и реализацию этих частей. Такие измерения накапливаются в базе данных, и на их основе делаются оценки новых работ. Как отмечает Хэмфри, это еще не «ракетные технологии», но это требует значительных организационных возможностей.

Кажется, что уровень 4 — это предел возможностей, но это не так. Мы знаем, что технологии программирования меняются быстро. Например, объектноориентированная парадигма привнесла значительные изменения в технологию: повторное использование и концепция компонентов оказывают все возрастающее влияние на разработку. Но появление новых парадигм и идей непредсказуемо. Таким образом, возможности организации уровня 4, которые не меняются в соответствии с изменениями обстановки, постепенно уменьшаются.

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

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

Недостаток: нет механизма улучшения процесса.

♦ Уровень 5: Оптимизированный. Вместо того чтобы пытаться предсказывать новые изменения в технологиях, гораздо лучше установить постоянно действующую процедуру поиска и освоения новых и улучшенных методов и инструментов. Таким образом, уровень 5 соответствует организациям, в которых имеется встроенный процесс улучшения процесса. Другими словами, их процесс (можно сказать, метапроцесс) включает в себя процесс постоянного улучшения текущего процесса разработки в организации на основе постоянной оценки текущего процесса, поиска новых средств и технологий и включения их в текущий процесс. Этой впечатляющей возможностью в начале 2000 года обладали только несколько организаций. Однако со времени появления СММ уровень 5 постепенно превращается из недостижимой мечты в конкретную цель. Процесс: непрерывное улучшение процесса за счет измеряемых количественных показателей; расширяемые возможности; инновационные идеи и технологии.

1.8.4. Связь между PSP, TSP и СММ.

В [51] Хэмфри связывает три модели возможностей, которые обсуждались в предыдущих разделах. Сравнение этих моделей приводится в табл. 1.4. В качестве примера взаимосвязи PSP, TSP и СММ отметим, что программы обучения относятся только к СММ: поскольку в них вовлекается вся организация, они не могут быть частью TSP или PSP. Другой пример заключается в том, что для программной конфигурации требуется работа в команде, и она никак не предназначена для персональной программной разработки.

1.9. Подведение итогов.

Создание программных продуктов является трудным делом. Водопадный процесс является простейшим типом процесса; в то же время он служит базовым процессом для спиральной (или итеративной) разработки. Третий из основных типов процесса — инкрементальная разработка. Успех зависит от профессионального взгляда с ориентацией на качество, всесторонней поддержки самостоятельных разработчиков и команд (например, через PSP/TSP) и выполнения полноценного, стандартизированного процесса разработки (как это приведено в СММ). Идеальный процесс разработки включает в себя и постоянное оценивание и улучшение. Подведем итоги и укажем типичный набор документации проекта.

♦ Разработка программного обеспечения — это очень серьезное занятие.

♦ Основные модели процессов:.

♦ водопадная, спиральная, инкрементальная.

♦ База возможностей: СММ, TSP, PSP.

♦ Качество — это отличительная черта профессионализма:.

♦ метрики, которые необходимо задать;.

♦ повсеместное инспектирование;.

♦ тщательное тестирование;.

♦ непрерывное улучшение процесса разработки.

♦ Документация: SCMP, SWP, SQAP, SPMP, SRS, SDD, STP, программный код, руководство пользователя.

Упражнения.

Ответы и подсказки для упражнений, помеченных символами «о» или «п», приводятся в конце этой главы.

Вопросы для проверки.

П1.1".

1.

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

2.

Являются ли некоторые из них более важными, нежели другие?.

П1.2". (Для ответов используйте текст книги.).

1.

Назовите четыре основных фазы в разработке программного продукта.

2.

Что такое водопадный процесс?.

3.

Каким образом водопадный процесс применяется в современном процессе разработки?.

П1.3°. Назовите кроме водопадного еще два процесса разработки программного обеспечения.

П1.4

1.

В чем заключается разница между верификацией и валидацией? (Для ответа см. раздел 1.6.6.).

2.

Каковы достоинства и недостатки составления плана экспертизы (верификации и валидации) до составления плана ведения открываемого проекта?.

П1.5". Приведите два преимущества и два недостатка использования стандартов для документации.

П1.6

1.

Что такое метрики?.

2.

Почему метрики полезно использовать?.

П1.7°.

1.

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

2.

Кратко опишите эти методы. Обозначьте их основные составляющие и цели. (Ответ: раздел 1.8.).

3. Убедитесь в том, что вы рассказали обо всех уровнях СММ в предыдущем вопросе.

Упражнения в команде.

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

К1.Г. (Тема: «План управления конфигурациями».).

Выработайте план управления конфигурациями программного обеспечения для вашего текущего проекта, используя стандарт IEEE 828-1990. Пример в конце этой главы будет помогать вам в этом; однако ваш документ будет более индивидуальным, отражая доступные вам ресурсы. Не включайте материал, который не способствует достижению целей создания этого документа. Избегайте узких мест и лишних процедур. Проверьте ваш план, используя его для создания необходимых документов в упражнении К 1.2, приведенном ниже.

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

Критерии оценки.

1.

Практичность. Насколько можно быть уверенным в том, что документы и их версии будут сохранны, доступны и согласованы? («Отлично» — наиболее вероятно.).

2.

Конкретность. Насколько конкретен план в смысле указания ролей и мест хранения? («Отлично» — каждый разработчик точно знает, что делать.).

3.

Оценка и улучшение процесса. До какой степени команда понимает сильные и слабые стороны своего процесса? Насколько конкретны планы по улучшению процесса? («Отлично» — полное понимание, планы конкретны и реалистичны.).

К1.2". (SVVP.).

Выработайте необходимые части SVVP, используя стандарт IEEE 1012-1986. Измерьте и приведите метрики, упомянутые в задаче К1Л.

Критерии оценки.

1.

Практичность. Насколько план обеспечивает достаточную валидацию и верификацию проделанной работы? («Отлично» — вполне практично в среде проекта.).

2.

Конкретность. Насколько конкретен план в смысле указания процедур и участников? («Отлично» — точно описывает, как выполняется V&V в среде проекта.).

3. Отношение участников. В какой степени участники проекта воспринимают ваш план как помощь? («Отлично» — написан с учетом интересов разработчиков.).

Подсказки.

П1.1.

1. Четыре составляющие начинаются на букву «П». (Ответ приведен ниже.).

К1.1 и К1.2. Не углубляйтесь в разделы, которые вам еще не знакомы. Добавляйте только те части, которые можно сделать за семестр. Добейтесь реалистичности плана.

Ответы.

П1.1. 1 и 2. Персонал, Процесс, Проект и Продукт. Все они важны. По мнению автора, ни один из них не является более важным, чем другие.

П1.2.

1.

Анализ требований, проектирование, реализация, интеграция и тестирование.

П1.3. Спиральный и инкрементальный процессы.

П1.4.

2.

Среди преимуществ — то, что процедуры контроля качества могут быть специфицированы сразу для всей организации, гарантируя тем самым унифицированность продуктов организации. Это позволило бы сэкономить время на переделке и адаптации процедур из проекта в проект. Недостатком является то, что невозможно предусмотреть все детали данного плана до момента утверждения плана проекта. (Например, мы не можем составить расписание верификации и валидации.).

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

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

П1.7. СММ для организаций, TSP для команд и PSP для разработчиков.

Пример 1. План управления конфигурациями (SCMP).

[Примечание для студентов. Неплохо, если каждый участник команды будет подписывать документы, которые готовит. Это концентрирует внимание и повышает чувство ответственности за содержание документов.].

Утверждаю.

_Дата _.

Содержание данного SCMP следует стандарту IEEE 828-1990.

01.05.98 Э. Брауде: Создание первой версии.

10.01.99 Р. Боствик: Рецензирование 18.01.99 Э. Брауде: Расширен раздел 5.2 18.05.99 Э. Брауде: Проверка для выпуска 30.04.99 Э. Брауде: Окончательное форматирование 02.05.99 Э. Брауде: Выпуск.

1.

Введение.

Данный План управления конфигурациями ПО (SCMP) описывает, как ведется работа с артефактами игры Встреча.

1.1.

Сокращения.

CI — Configuration Item. Элемент конфигурации — любой элемент, отслеживаемый системой управления конфигурациями.

СМ — Configuration Management. Управление конфигурациями — процесс поддержки релевантных версий артефактов проекта.

SCMP — Software Configuration Management Plan. Данный документ.

1.2.

Термины.

Утвержденный CI — CI, подписанный руководством проекта.

Артефакт — окончательный или промежуточный материал проекта (например, документ, исходный код, объектный код, результат теста).

Главный файл — специальным образом построенный файл для данного проекта, определяется в разделе 3.1.2.

2.

Управление конфигурациями 2.1. Организация.

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

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

2.2.

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

[Примечание для студентов. Определите ответственность каждой роли. Если этого не сделать, то некоторые действия не будут выполняться, а другие будут выполняться несколькими членами команды больше чем один раз. Определите, кто является заместителем по каждой роли.].

2.2.1.

Ведущий конфигурацию.

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

Ведущий конфигурацию отвечает за организацию и управление конфигурациями. Если это возможно, ведущий конфигурацию должен обсуждать планы управления конфигурациями с командой разработчиков до того, как эти планы вводятся в действие. Ведущий конфигурацию поддерживает данный документ (SCMP). Ведущий конфигурацию отвечает за установку и сопровождение инструментов управления конфигурациями, определенных в разделе 2.3. Архивация данных должна производиться в соответствии с корпоративной инструкцией 12345.

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

Дополнительные обязанности ведущего конфигурацию описаны в разделах 3.3, 3.4, 3.5 и 3.6.

2.2.2.

Лидер проекта.

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

Дополнительные обязанности лидера проекта описаны в разделах 3.3 и 3.4.

2.2.3.

Разработчики.

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

2.3.

Применяемые политики, директивы и процедуры.

[Примечание для студентов. Такая деятельность, как управление конфигурациями, обычно осуществляется в соответствии с общей политикой организации. Студенческая команда должна идентифицировать и перечислить в этом разделе соответствующие правила и инструкции. При этом пункт 3 следует включить обязательно.] 1. Управление конфигурациями для данного проекта должно осуществляться в соответствии с указаниями по управлению конфигурациями, изложенными в корпоративном документе 7890 версии 6 от 15.08.98.

2.

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

3.

Все текущие и предшествующие версии CI должны сохраняться.

4.

К главному файлу (определен в разделе 3.1.2) имеет доступ только ведущий конфигурацию, а в его отсутствие — начальник отдела.

5.

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

6.

Лидер проекта и начальник отдела должны всегда иметь полный доступ ко всем документам, которые затрагивает управление конфигурациями. Каждые две недели лидер проекта должен предоставлять форму https://

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

7.

В проекте Встреча будет использоваться средство SuperCMTool версии 3.4, поставляемое компанией SuperCMTool.

[Примечание для студентов. Все названия выдуманы.].

8.

Архивация должна производиться в соответствии с правилами отдела, документ 123456.

3. Виды деятельности 3.1. Определение конфигурации.

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

3.1.1. Определение элементов конфигурации.

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

3.1.2. Именование элементов конфигурации.

Ведущий конфигурацию несет ответственность за маркировку всех CI. Соглашение об именах следующее. Корневой каталог: Encounter. Вложенные каталоги: SRS или SDD или...

Файл с именем N_N_N.xxx соответствует версии N.N.N документа. Например, версия SRS 2.4.8 имеет имя Encounter/SRS/2_4_8.txt. Главный файл с именем Master находится в корневом каталоге и содержит информацию о текущем состоянии и предыдущих состояниях проекта. Например, файл Master может включать такую информацию.

Текущая версия проекта Встреча 3.7.1. Она включает версию 2.4.8 SRS и версию 1.4 SDD.

Предыдущая версия проекта Встреча 3.6.11. Она включает версию 2.4.8 SRS и версию 1.3 SDD.

Эта информация должна быть представлена в форме следующей таблицы.

3.1.3. Получение элементов конфигурации.

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

Для модификации CI разработчик должен взять CI с помощью процедуры checkout инструмента SuperCMTool. Отметим, что SuperCMTool предлагает пользователю заполнить специальную форму и указать, на какой срок берется CI. Эта информация запоминается и предоставляется другим пользователям, желающим взять данный CI на модификацию. Любой желающий взять данный CI должен договориться с текущим владельцем CI о передаче средствами SuperCMTool. Ни при каких обстоятельствах разработчики не должны передавать друг другу CI прямо, в обход SuperCMTool. Для любого разработчика любой CI должен быть доступен на чтение в любое время.

3.2. Контроль конфигурации.

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

3.2.1. Запрос на изменения.

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

. Encounter.submitCI ведущему конфигурацию и лидеру проекта вместе с исходным CI и измененным CI.

3.2.2.

Оценка изменений.

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

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

3.2.3.

Одобрение или неодобрение изменений.

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

3.2.4.

Реализация изменений.

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

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

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

3.3.

Определение статуса конфигурации.

Ведущий конфигурацию обязан обновлять информацию о конфигурации на сайте

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

3.4.

Аудиты и обзоры конфигурации.

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

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

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

3.5.

Управление интерфейсом.

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

3.6.

Контроль поставщиков и субподрядчиков.

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

4. Расписание.

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

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

5.

Ресурсы.

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

6.

Сопровождение.

[Примечание для студентов. Все документы проекта изменяются по ходу проекта, но SCMP особенно чувствителен к изменениям, поскольку в нем определяется способ управления изменениями.].

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

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

♦ Оценить эффективность данного плана.

♦ Количественно оценить потери, вызванные дефектами данного плана.

♦ Оценить эффективность использования инструмента SuperCMTool.

♦ Изучить литературу по новым методам управления конфигурациями; количественно оценить выгоды и затраты на проведение улучшений.

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

♦ Предложить конкретные улучшения текущего процесса управления конфигурациями.

♦ Перечислить выгоды от улучшений.

♦ Предоставить оценки стоимости эффекта введения улучшений.

♦ Упорядочить предлагаемые улучшения по значению отношения выгодызатраты.

Пример 2. План контроля качества (SQAP), часть 1.

Утверждаю.

_Дата_.

Содержание данного SQAP следует стандарту IEEE 730-1989 17.01.99 Э. Брауде: Создание первой версии.

30.05.99 Р. Боствик: Рецензирование и добавление разделов от 7 до конца. 31.05.99 Э. Брауде: Интеграция и пересмотр содержания.

1.

Цель.

В этом документе описан план получения качественного продукта при выполнении проекта Встреча. Этот план включает средства обеспечения поддержки игры Встреча.

2.

Задействованные документы.

См. раздел 4.2.

3.

Управление.

3.1.

Организация.

[Примечание для студентов. Этот раздел устанавливает, какие роли задействованы в процессе обеспечения качества. Фактическое распределение обязанностей дано в разделе 3.3.].

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

3.2.

Задачи.

[Примечание для студентов. Здесь определяется, что необходимо делать.] Задачи по контролю качества включают в себя:.

♦ документацию;.

♦ обзорные собрания;.

♦ верификацию (включая инспектирование);.

♦ валидацию (прежде всего тестирование);.

♦ виды деятельности, направленные на улучшение самого процесса обеспечения качества.

Эти задачи детализированы в данном документе.

3.3.

Ответственность.

[Примечание для студентов. Здесь определяется, кто что должен делать.].

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

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

[Примечание для студентов. Здесь не упоминаются конкретные имена, поскольку они должны быть указаны в подходящем месте, а именно в SPMP. Если продублировать здесь имена, то потребовалось бы обновлять более одного документа при изменении конкретных имен.].

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

4.

Документация.

4.1.

Цель.

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

4.2.

Минимальные требования к документации.

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

Должны быть созданы следующие документы.

♦ SQAP: План контроля качества (данный документ).

♦ SCMP: План управления конфигурациями.

♦ SPMP: План управления программным проектом.

♦ SRS: Спецификация требований к программному обеспечению.

♦ SDD: Проектная документация программного обеспечения.

♦ STD: Документация по тестированию программного обеспечения.

♦ Руководство пользователя. 4- План сопровождения.

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

4.3.

Прочее.

План экспертизы программного обеспечения (SVVP) должен быть создан и поддерживаться независимо от SQAP.

5.

Стандарты, практики, соглашения и метрики 5.1. Цель.

Данный раздел описывает стандарты, практики, соглашения и метрики, используемые в проекте Встреча. Эти материалы призваны не только обеспечить качество проекта Встреча, но и получить количественные данные о самом процессе контроля качества. Полученные данные должны быть использованы организацией Gaming Consolidated Industries (GCI) для повышения уровня по СММ с 3 до 4.

5.2. Содержание.

[Примечание для студентов. Опишите стандарты, практики, соглашения и метрики, которые должны быть использованы. Здесь также можно указать общие цели организации в области качества или перенести их в специальное приложение. Содержание данного раздела должно быть конкретным. Например, следует избегать таких фраз, как «качество должно быть высоким, насколько это возможно».].

Стандарты.

Для ведения документации используются стандарты IEEE с соответствующими модификациями.

Практики.

1.

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

2.

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

3.

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

4.

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

Соглашения.

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

Метрики.

Для каждого процесса и каждого документа должны измеряться по меньшей мере три показателя.

1.

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

2.

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

3.

Количество дефектов на единицу объема (например, на тысячу строк кода).

Компания GCI ставит перед собой цель достичь следующих показателей качества своих продуктов.

[Примечание для студентов. Числа, использованные ниже, должны опираться на собранные ранее данные.].

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

♦ Требования: не более одного незначительного дефекта на сто детальных требований.

♦ Проектирование: не более одного незначительного дефекта на пять диаграмм.

+ Псевдокод: не более двух незначительных дефектов на тысячу строк.

♦ Код: не более двух незначительных дефектов на тысячу строк кода, не считая комментариев.

Фактические данные по проекту должны быть представлены в приложении 1 к данному документу.

6. Обзоры и аудиты.

6.1.

Цель.

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

6.2.

Минимальные требования.

[Примечание для студентов. В больших проектах требуется полный список обзоров и аудитов, приведенный здесь. Студенческая команда как минимум должна провести обзоры и инспектирование требований и проектирования, а также заключительный обзор после окончания проекта. «Обзор» подразумевает обсуждение предлагаемого артефакта. «Инспектирование» применяется к законченному артефакту.].

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

Данный обзор проводится по всему документу с требованиями в присутствии всей команды. Обзор ведет лидер проекта. Предполагается, что требования не были инспектированы до данного обзора. Данный обзор не подменяет инспектирование требований. Ответственный за требования обязан проследить, чтобы инспектирование требований состоялось (см. SPMP).

6.2.1 А. Инспектирование требований к программному обеспечению.

Все требования должны быть инспектированы в соответствии с Руководством по проведению инспектирования компании GCI, документ 345678.

6.2.2.

Предварительный обзор проектных решений.

Данный обзор альтернативных архитектурных решений выполняется всей командой. Обзор проводится лидером проекта или его заместителем. Подразумевается, что команда даст предложения, которые будут учтены в окончательном варианте проекта. Альтернативные архитектуры не должны инспектироваться до данного обзора. Ответственный за проектирование обязан проследить, чтобы данный обзор состоялся (см. SPMP).

6.2.3.

Критический обзор проектных решений.

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

6.2.4.

Обзор SWP.

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

6.2.5.

Аудит функциональности.

Лидер проекта перед поставкой продукта обязан организовать проверку того, что продукт соответствует SRS. Если необходимо сделать какие-то исключения, лидер проекта обязан получить предварительное разрешение на поставку от своего руководителя. Данные исключения должны быть доведены до сведения заказчика с помощью соответствующих средств, в том числе файла README и сопроводительного письма.

6.2.6.

Аудит физических компонентов.

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

6.2.7.

Аудиты процесса.

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

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

6.2.8.

Обзор управления.

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

6.2.9.

Обзор SCMP.

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

6.2.10.

Заключительный обзор.

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

6.3. Инспектирование.

Все артефакты проекта Встреча должны инспектироваться. Разделы с 7 по 15 обсуждаются в главе 2.