Методы тестирования программного обеспечения. Степанченко И.В. - 28 стр.

UptoLike

Составители: 

30
ны группы. Этот феномен известен давно и часто его применяют для
решения проблем. Когда решение неочевидно, то объяснение про-
блемы другому человеку заставляет разработчика «разложить все по
полочкам» и решение «само приходит» к разработчику.
2. Программа анализируется по списку вопросов для выявления исто-
рически сложившихся общих ошибок программирования.
Председатель является
ответственным за обеспечение результатив-
ности дискуссии. Ее участники должны сосредоточить свое внимание на
нахождении ошибок, а не на их корректировке. (Корректировка ошибок
выполняется программистом после инспекционного заседания.)
По окончании заседания программисту передается список найден-
ных ошибок. Если список включает много ошибок или если эти ошибки
требуют внесения значительных изменений, председателем
может быть
принято решение о проведении после корректировки повторной инспек-
ции программы. Список анализируется и ошибки распределяются по ка-
тегориям, что позволяет совершенствовать его с целью повышения эф-
фективности будущих инспекций. Можно даже вести учет типов ошибок,
на основании которого следует проводить дополнительную стажировку
программиста в слабых областях.
В большинстве примеров
описания процесса инспектирования ут-
верждается, что во время инспекционного заседания ошибки не должны
корректироваться. Однако существует и другая точка зрения [16]: «Вме-
сто того, чтобы сначала сосредоточиться на основных проблемах проек-
тирования, необходимо решить второстепенные вопросы. Два или три
человека, включая разработчика программы, должны внести очевидные
исправления в проект с тем,
чтобы впоследствии решить главные задачи.
Однако обсуждение второстепенных вопросов сконцентрирует внимание
группы на частной области проектирования. Во время обсуждения наи-
лучшего способа внесения изменений в проект кто-либо из членов груп-
пы может заметить еще одну проблему. Теперь группе придется рассмат-
ривать две проблемы по отношению к одним и тем же
аспектам проекти-
рования, объяснения будут полными и быстрыми. В течение нескольких
минут целая область проекта может быть полностью исследована и лю-
бые проблемы станут очевидными... Как упоминалось выше, многие
важные проблемы, возникавшие во время обзоров блок-схем, были реше-
ны в результате многократных безуспешных попыток решить вопросы,
которые на первый
взгляд казались тривиальными».
Время и место проведения инспекции должны быть спланированы
так, чтобы избежать любых прерываний инспекционного заседания. Его
оптимальная продолжительность, по-видимому, лежит в пределах от 90
до 120 мин. Так как это заседание является экспериментом, требующим
     ны группы. Этот феномен известен давно и часто его применяют для
     решения проблем. Когда решение неочевидно, то объяснение про-
     блемы другому человеку заставляет разработчика «разложить все по
     полочкам» и решение «само приходит» к разработчику.
2. Программа анализируется по списку вопросов для выявления исто-
     рически сложившихся общих ошибок программирования.
     Председатель является ответственным за обеспечение результатив-
ности дискуссии. Ее участники должны сосредоточить свое внимание на
нахождении ошибок, а не на их корректировке. (Корректировка ошибок
выполняется программистом после инспекционного заседания.)
     По окончании заседания программисту передается список найден-
ных ошибок. Если список включает много ошибок или если эти ошибки
требуют внесения значительных изменений, председателем может быть
принято решение о проведении после корректировки повторной инспек-
ции программы. Список анализируется и ошибки распределяются по ка-
тегориям, что позволяет совершенствовать его с целью повышения эф-
фективности будущих инспекций. Можно даже вести учет типов ошибок,
на основании которого следует проводить дополнительную стажировку
программиста в слабых областях.
     В большинстве примеров описания процесса инспектирования ут-
верждается, что во время инспекционного заседания ошибки не должны
корректироваться. Однако существует и другая точка зрения [16]: «Вме-
сто того, чтобы сначала сосредоточиться на основных проблемах проек-
тирования, необходимо решить второстепенные вопросы. Два или три
человека, включая разработчика программы, должны внести очевидные
исправления в проект с тем, чтобы впоследствии решить главные задачи.
Однако обсуждение второстепенных вопросов сконцентрирует внимание
группы на частной области проектирования. Во время обсуждения наи-
лучшего способа внесения изменений в проект кто-либо из членов груп-
пы может заметить еще одну проблему. Теперь группе придется рассмат-
ривать две проблемы по отношению к одним и тем же аспектам проекти-
рования, объяснения будут полными и быстрыми. В течение нескольких
минут целая область проекта может быть полностью исследована и лю-
бые проблемы станут очевидными... Как упоминалось выше, многие
важные проблемы, возникавшие во время обзоров блок-схем, были реше-
ны в результате многократных безуспешных попыток решить вопросы,
которые на первый взгляд казались тривиальными».
     Время и место проведения инспекции должны быть спланированы
так, чтобы избежать любых прерываний инспекционного заседания. Его
оптимальная продолжительность, по-видимому, лежит в пределах от 90
до 120 мин. Так как это заседание является экспериментом, требующим
                                 30