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

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

Концепцию модульного программирования можно сформулировать в виде нескольких понятий и положений:

• Функциональная декомпозиция задачи - разбиение большой задачи на ряд более мелких, функционально самостоятельных подзадач - модулей. Модули связаны между собой только по входным и выходным данным.
• Модуль - основа концепции модульного программирования. Каждый модуль в функциональной декомпозиции представляет собой "черный ящик" с одним входом и одним выходом. Модульный подход позволяет безболезненно производить модернизацию программы в процессе ее эксплуатации и облегчает ее сопровождение. Дополнительно модульный подход позволяет разрабатывать части программ одного проекта на разных языках программирования, после чего с помощью компоновочных средств объединять их в единый загрузочный модуль.
• Реализуемые решения должны быть простыми и ясными. Если назначение модуля непонятно, то это говорит о том, что декомпозиция начальной или промежуточной задачи была проведена недостаточно качественно. В этом случае необходимо еще раз проанализировать задачу и, возможно, провести дополнительное разбиение на подзадачи. При наличии сложных мест в проекте их нужно подробнее документировать с помощью продуманной системы комментариев. Этот процесс нужно продолжать до тех пор, пока действительно не удастся добиться ясного понимания назначения всех модулей задачи и их оптимального сочетания.
• Назначение всех переменных модуля должно быть описано с помощью комментариев по мере их определения.

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

15. Процесс контроля качества. Методы  «белого» и «черного» ящика.  Инспектирование.

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

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

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

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

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

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

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

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

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

♦ Авторы обычно в состоянии  исправить найденные дефекты.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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