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