В.В. Кулямин - Технологии программирования. Компонентный подход (1133554), страница 35
Текст из файла (страница 35)
Инспекция программ по Фагану (Fagan inspection process).Контекст использования. Поиск ошибок на ранних этапах разработки программногообеспечения — при подготовке требований, проектировании, начальных этапахкодирования, планировании тестов.Действующие силы.• Усилия, необходимые для исправления ошибки, и, соответственно, ее стоимостьвозрастают в зависимости от этапа проекта, на котором она обнаружена. Изэмпирических данных известно, что каждый раз при переходе через границу междуфазами (при использовании водопадной модели разработки) подготовка требований– проектирование – кодирование – тестирование – эксплуатация трудозатраты наисправление найденных на данном этапе ошибок возрастают в 3-5 раз. Прииспользовании итеративных моделей затраты возрастают меньше, но не намного.Поэтому, чем раньше ошибки будут обнаруживаться, тем эффективней будетразработка в целом.• Членам команды разработчиков надо понимать, над чем работает каждый из них икакие решения он использует.
Это помогает значительно повысить эффективностьсобственной работы.• Каждый артефакт — требования, проектные документы, код, тестовые планы —должен быть подготовлен на нужном уровне качества, прежде чем он будетиспользован для дальнейшей работы.• Знания о найденных ошибках позволяют членам команды избегать их повторения, атакже обращать больше внимания на компоненты, которые оказались наиболееподвержены ошибкам на предыдущих этапах.Решение.
Несколько членов команды разработчиков проводят тщательную инспекциюрезультатов работы одного из них. Такие инспекции основываются на первичныхдокументах, чтобы проверить соответствие им вторичных документов. Первичные ивторичные документы для каждого вида деятельности в ходе разработки, для которыхпроведение инспекций эффективно, представлены в Таблице 8.Выделяются следующие роли участвующих в процессе инспекции лиц.• Ведущий (moderator). Он руководит проведением инспекции, руководит собраниями,фиксирует обнаруженные ошибки, назначает время проведения собраний, срокиподготовки отчетов, следит за исправлением найденных ошибок.В качестве ведущего должен использоваться компетентный разработчик илиархитектор, не вовлеченный в проект, материалы которого инспектируются.• Автор (author).
Это автор первичного документа или человек, имеющий достаточнополное представление о нем. Его обязанности — подготовить рассказ об основных116••положениях первичного документа и отвечать на вопросы, возникающие у членовинспектирующей команды по его поводу.Интерпретатор (reader). Это автор вторичного документа, который разработан всоответствии с первичным. Его обязанности — объяснить участникам инспекцииосновные идеи, лежащие в основе его интерпретации первичного документа, иотвечать на их вопросы по поводу вторичного документа.Инспектор (tester).
В ходе всей инспекции он анализирует вторичный документ,проверяя его на соответствие первичному.Вид деятельностиАнализ требованийПроектированиеПервичные документыМодели предметной области,составленные заказчиками ипользователями требованияТребования к ПОКодированиеПроектная документацияТестированиеТребования к ПО, проектнаядокументация, кодВторичные документыТребования к ПООписание архитектуры, проектнаядокументацияКод, проектная документация наотдельные компонентыТестовые планы и наборытестовых вариантовТаблица 8.
Первичные и вторичные документы на разных этапах разработки.Обычно рекомендуется использовать не более 4-х человек в команде, проводящейинспекцию. Расширение ее возможно в особых случаях и только за счет разработчиков,которым непосредственно придется иметь дело с инспектируемыми вторичнымидокументами.Сам процесс инспекции состоит из следующих шагов.1. Планирование (planning).На этом шаге ведущий должен убедиться в том, что первичный и вторичный документыготовы к проведению инспекции — они существуют, написаны достаточно понятно, сдостаточной степенью детализации.Кроме того, на этом шаге проводиться планирование всего хода инспекции —определяются участники, их роли, назначаются сроки проведения собраний и время,выделяемое на выполнение каждого шага.2.
Обзор (review).Проводится собрание, на котором автор представляет наиболее существенныеположения первичного документа и отвечает на вопросы участников о нем.Первичный и вторичный документы выдаются на руки участникам инспекции длядальнейшей работы.Ведущий объясняет задачи данной инспекции, вопросы и моменты, на которые стоитобратить особое внимание, а также сообщает, какие ошибки были уже обнаружены врассматриваемых документах, чтобы участники группы имели представление об ихпроблемных местах.3. Подготовка (preparation).Каждый из участников тщательно изучает оба документа самостоятельно, пытаясьпонять заложенные в них решения и проследить их реализацию.Часто на этом этапе обнаруживаются ошибки, но гораздо меньше, чем на следующем.4.
Совместная инспекция (inspection meeting).Проводится совместное собрание, на котором интерпретатор рассказывает об основныхидеях и техниках, использованных во вторичном документе, а также объясняет, почемубыли приняты те или иные решения и почему они соответствуют первичномудокументу.117Участники задают вопросы и акцентируют внимание на проблемных местах. Как тольковедущий по ходу собрания замечает ошибку (или кто-то обращает его внимание на нее),он сообщает о ней и убеждается, что все участники согласны с тем, что это именноошибка, т.е. несоответствие между первичным и вторичным документами.
Каждаяошибка фиксируется, описывается ее положение, она классифицируется по некоторойсхеме, например, критическая (приводящая к ошибке в работе системы) илинекритическая (связанная с опечатками, излишней сложностью или неудобствоминтерфейса и пр.).5. Доработка (rework).В ходе доработки интерпретатор исправляет обнаруженные ошибки.6. Контроль результатов (follow-up).Результаты доработки проверяются ведущим. Он проверяет, что все найденные ошибкибыли исправлены и что не было внесено новых ошибок.
Если по результатам инспекциибыло переработано более 5% вторичного документа, следует провести полнуюинспекцию вновь. Иначе ведущий сам определяет, насколько документ подготовлен кдальнейшему использованию.Кроме того, ведущий подготавливает отчет обо всех обнаруженных ошибках дляпоследующего использования в других инспекциях и при оценке качества результатовразработки.Итоговый контекст. В результате проведения инспекций повышается качество проектныхдокументов и кода, разработчики знакомятся ближе с работой друг друга и с задачамипроекта в целом, углубляют понимание проблем проекта и используемых в нем решений.Кроме того, руководитель проекта получает надежные данные о качестве результатовразработки.Руководитель должен понимать, что результаты инспекций не должны использоваться какпоказатель качества работы разработчиков, иначе все положительные эффекты от ихпроведения пропадают — разработчики начинают неохотно участвовать в инспекциях,скрывают детали своей работы, снисходительнее относятся к ошибкам других в расчете навзаимность и пр.При выполнении этого условия инспекции являются эффективным средством обнаруженияошибок на ранних этапах.
Статистика показывает, что они находят до 80% ошибок,обнаруживаемых за весь период разработки ПО.Литература к Лекции 8[1] G. E. Krasner, S. T. Pope. A cookbook for using the Model-View-Controller user interfaceparadigm in Smalltalk-80. Journal of Object-Oriented Programming, 1(3), pp. 26–49, AugustSeptember 1988. SIGS Publications, NY, USA, 1988.[2] CORBA Event Service Specification, version 1.2.
Object Management Group, October 2004.Доступен как http://www.omg.org/cgi-bin/apps/doc?formal/04-10-02.pdf.[3] Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес. Приемы объектно-ориентированногопроектирования. Паттерны проектирования. СПб.: Питер-ДМК, 2001.[4] M. E. Fagan. Design and Code inspections to reduce errors in program development. IBMSystems Journal, vol. 15, No. 3, pp. 258–287, 1976.[5] M.
E. Fagan. Advances in Software Inspections. IEEE Transactions on Software Engineering,vol. 12, No. 7, pp. 744–751, July 1986.[6] S. Ambler. Process Patterns: Building Large-Scale Systems using Object Technology. CambridgeUniversity Press, Cambridge, MA, 1998.[7] М. Фаулер и др.
Архитектура корпоративных программных приложений. М.: Вильямс,2004.[8] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal. Pattern-Oriented SoftwareArchitecture. A System of Patterns. Wiley, 2002.[9] Э. Дж. Брауде. Технология разработки программного обеспечения. СПб.: Питер, 2004.118Лекция 9. Принципы создания удобного пользовательскогоинтерфейсаАннотацияРассматриваются основные факторы удобства использования ПО, а также психо-физиологическиеособенности человека, делающие предметы удобными и неудобными для него. Рассказывается ометодике проектирования, ориентированного на удобство использования.Ключевые словаУдобство использования, удобство обучения, ментальная модель, метафора, наглядность,эвристики удобства использования, проектирование, ориентированное на удобство использования,модель ролей пользователей, модель задач, модель содержимого интерфейса, эвристическоеинспектирование интерфейса, GOMS, тестирование удобства использования.Текст лекцииУдобство использования программного обеспеченияОдним из важных показателей качества программного обеспечения является удобство егоиспользования.
Оно описывается с помощью таких характеристик, как понятностьпользовательского интерфейса, легкость обучения работе с ним, трудоемкость решенияопределенных задач с его помощью, производительность работы пользователя с ПО, частотапоявления ошибок и жалоб на неудобства. Для построения действительно удобных программнужен учет контекста их использования, психологии пользователей, необходимости помогатьначинающим пользователям и предоставлять все нужное для работы опытных. Однако самымзначимым фактором является то, помогает ли данная программа решать действительно значимыедля пользователей задачи.Многие программисты имеют технический или математический склад ума.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
