лекция. Сборник лекций по МДК _Технология разработки программного обеспе. Курс лекций для специальности спо базовой подготовки
 Скачать 4.41 Mb.
|
Использование глобалов (GUS)Использование глобальных переменных (Global Usage - GUS). При вычислении этой метрики подсчитывается количество глобальных переменных, в том числе глобальных переменных для всей системы, а также количество переменных класса, глобальных для этого класса. Ситуация с использованием глобальных переменных в программах на языке C++ часто возникает, если эти программы используют старые программы написанные на языке С. Метрика GUS позволяет выявить такие зависимости. Излишняя взаимосвязь через глобалы (UCGU)Излишняя взаимосвязь через глобальные переменные (Unnesessary Coupling through Global Usage - UCGU). При вычислении этой метрики подсчитывается сколько раз глобальные переменные, определенные метрикой GUS, были использованы. Метрика UCGU позволяет оценить степень влияния глобальных переменных на систему в целом. Возможно зависимость от глобальных переменных локализована в каком либо одном классе, и такое влияние не велико. Однако возможна и обратная ситуация, когда глобальные переменные используются часто и в большом количестве классов. Степень взаимосвязи между классами (DCBO)Степень взаимосвязи между классами (Degree of Coupling between Classes - DCBO). Эта метрика используется как дополнение к метрике DCO. Метрика DCO подсчитывает количество классов, с которыми данный класс разделяет атрибуты и методы. Метрика DCBO подсчитывает только методы данного класса, используемые из других классов. Если методы данного класса никому не нужны, то DCBO=0. Количество скрытых методов экземпляра (PrIM)Количество скрытых (private) методов экземпляра (Number of Private Instance Methods - PrIM) позволяет степень скрытия информации классом. Мера Мак-Клура (MMK)Мера Мак-Клура предназначена для управления сложностью структурированных программ в процессе проектирования. Она применяется к иерархическим схемам разбиения программ на модули, что позволяет выбрать схему разбиения с меньшей сложностью задолго до написания программы. Метрикой выступает зависимость сложности программы от числа возможных путей исполнения, числа управляющих конструкций и числа переменных (от которых зависит выбор пути). Методика расчета сложности по Мак-Клуру четко ориентирована на хорошо структурированные программы. Тестирующей мерой М называется мера сложности, удовлетворяющая следующим условиям: 1.Мера сложности простого оператора равна 1; 2.М ({F1; F2; ┘;Fn}) = еin M(Fi); 3.М (IF P THEN F1 ELSE F2) = 2 MAX (M (F1), M (F2)); 4. М (WHILE P DO F) = 2 M(F). Мера возрастает с глубиной вложенности и учитывает протяженность программы. К тестирующей мере близко примыкает мера на основе регулярных вложений. Идея этой меры сложности программ состоит в подсчете суммарного числа символов (операндов, операторов, скобок) в регулярном выражении с минимально необходимым числом скобок, описывающим управляющий граф программы. Все меры этой группы чувствительны к вложенности управляющих конструкций и к протяженности программы. Однако возрастает уровень трудоемкости вычислений. Оценка интерфейса пользователя В процессе проектировании программного обеспечения (ПО) для большинства современных операционных систем (ОС) с графическим интерфейсом пользователя (таких как Microsoft Windows, MacOS, различные варианты оболочек над XWindow в unix-системах) и создании информационных систем на базе таких ОС, неизбежно встает вопрос о проектировании и разработки качественного пользовательского интерфейса. Очевидно, что пользовательский интерфейс напрямую зависит от решаемых программным обеспечением задач, входных и выходных данных; однако при этом существуют значительная свобода в том, в каком виде все эти данные будут представлены пользователю. От того, насколько пользовательский интерфейс будет функционален, понятен и удобен конечному пользователю, во многом зависит успешность решения поставленной при проектировании ПО. На процесс проектирования пользовательского интерфейса, пожалуй, набольшее влияние оказывают субъективные представления проектировщика о понятности, удобстве и красоте. Поэтому, большое значение имеет проблема оценки качества пользовательского интерфейса. Проводя такие оценки на ранних этапах процесса проектирования можно избежать большого числа ошибок, просчетов, неприятия ПО конечными пользователями. Существует целый ряд подходов позволяющих оценить качество пользовательского интерфейса. В целом все методы можно разбить на две большие группы: методы непосредственно тестирования интерфейса группой пользователей и методы без такового тестирования, основанные на формальных расчетах. И те, и другие методы одинаково применимы как для оценки интерфейса традиционного ПО, так и Web-приложений. Выбор группы методов зависит, главным образом, от того, насколько осуществимо непосредственное тестирование на той или иной стадии выполнение проекта и отведенного на такое тестирование времени и бюджета. Важно учитывать не только стоимость самого проектирования и разработки качественного и удобного пользовательского интерфейса, но и возможных финансовых потерь, которые неизбежны, если интерфейс недостаточно проработан или неудобен в использовании. Хотя оценка качества пользовательского интерфейса процесс достаточно субъективный и трудно формализуемый [1], можно с уверенностью утверждать, что хороший интерфейс должен обеспечивать эффективную и производительную работу пользователя. Существует также и ряд критериев, которым должен удовлетворять качественный интерфейс [5, 6, 7, 8, 4]: · лучше тот интерфейс, при котором время выполнения задачи меньше; · лучше тот интерфейс, в котором число непроизвольных ошибок пользователя меньше; · неоднозначность в понимании интерфейса должна быть минимальна (это способствует самообучению пользователей и делает их поведение предсказуемым); · необходима высокая стандартизация интерфейса (она облегчает обучение пользователей); · объем вводимой пользователем информации должен стремиться к минимуму (одни и те же данные не должны вводиться несколько раз) · простота и визуальная привлекательность (удобство использования не менее важно, чем функциональность). Как правило, интерфейс строится для выполнения какой-то конкретной задачи, и в силу этого можно заранее определить минимальное количество информации, которое пользователь должен ввести, чтобы эту задачу решить. Этот объем информации является свойством самой задачи и не зависит от выбора варианта реализации интерфейса, с этой точки зрения лучше тот вариант интерфейса, который не требует ввода лишней информации, с другой стороны понятно и то, что если ничего лишнего вводить не требуется, то для улучшения интерфейса нужно искать другие пути, нежели сокращение объема вводимых данных. Можно выделить ряд наиболее распространенных методов оценки качества пользовательского интерфейса (рис. 1):  Рис. 1. Методы оценки интерфейса Методфокус-групп В основе этого метода лежит специальная форма интервью, проводимого в группе. Фокус-группа представляет собой группу пользователей или специалистов (обычно 7-10 человек), не знакомых с предлагаемым им для оценки интерфейсом и, как правило, являющиеся потенциальными или заинтересованными пользователями. Работа фокус-группы может как предварять количественные исследования, так и проводиться после них. В первом случае, на тестирование и обсуждение прелагается прототип интерфейса подлежащего оценке, при этом основная задача фокус-группы – собрать первоначальные мнения об интерфейсе, проверить, насколько он соответствует ожиданиям, выяснить, что вызывает вопросы. Такое исследование позволяет сузить круг проблем и выдвинуть гипотезы для их дальнейшего решения. Во втором случае, фокус-группы, как правило, направлены на уточнение данных количественного исследования, его дополнения за счет более подробной проработки полученной ранее информации. На тестирование и обсуждение прелагается рабочий вариант информационной системы с интерфейсом, подлежащим оценке. Такое тестирование позволяет выявить то, что было упущено на ранних этапах проектирования пользовательского интерфейса и получить предложения по улучшению интерфейса. Работа фокус-группы ведется по составленному заранее сценарию, при этом вся беседа должна быть записана на видео или аудио носители для дальней расшифровки и анализа. С помощью метода фокус-групп можно получить достаточно глубинную информацию об особенностях поведения конечных пользователей, которую просто невозможно выяснить другими методами. Этот метод позволяет и лучше понять пользователей – выявить волнующие их проблемы и пожелания. Обычно анализ проводят несколько небольших и независимых фокус-групп (важно чтобы группы различались по своему составу, например это могут быть группы опытных пользователей (технических специалистов), новичков и средних пользователей) такой подход позволяет выявить наиболее проблемные участки в интерфейсе и вместе с тем он позволяет провести оценку в очень короткий срок, не прибегая к масштабному тестированию:  Рис. 2. Типичное соотношение между числом проблемам (пожеланий) в различных группах пользователей При этом вполне понятно, что в первую очередь нужно решать проблемы средних пользователей (так их абсолютное большинство) – рис. 2. Полезно произвести несколько повторных оценок интерфейса (итераций) теми же фокус-группами уже после внесения в него изменений. Качество пользовательского интерфейса можно косвенно оценить через следующие формальные соотношения:  ,где :  – количество найденных ошибок, проблем и т.п. в интерфейсе – количество проблем для которых предложено подходящее решение – фактор продуктивности работы фокус группы – номер итерации ,где:  – общее количество проблем, для которых предложено подходящее решение (за все итерации) – общее количество проблем, для которых предлагалось повторное решение (за все итерации), т.е. таких, первоначальное решение для которых оказалось ошибочным или недостаточным – общая оценка неудовлетворенности качеством интерфейса (ясно, что при большом числе повторных изменений она стремится к 100%, что говорит о плохой проработанности интерфейса, его противоречивости).Опыт показывает [10], что в успешных проектах наиболее типична зависимость рис. 3.  Рис. 3. Типичная зависимость числа ошибок по итерациям Недостатком метода является то, что пользователи обычно не замечают удачных интерфейсных решений, так как таковые воспринимаются как естественные и не привлекают к себе внимания; поэтому важно с большой осторожностью относиться к изменениям в тех частях интерфейса относительно которых не было никаких комментариев пользователей. Прототипирование Прототипирование [11] заключается в создании широкого набора макетов (прототипов) будущего пользовательского интерфейса, которые подвергаются сопоставительному анализу. Как правило, прототип содержит реализацию лишь самого интерфейса, без его функционального наполнения. Цель прототипирования заключается определении, насколько то или иное решение перспективно, и последующей реализации лучшего из возможного. Этот подход позволяет сэкономить время и ресурсы затрачиваемые на проектирование и разработку. Наиболее целесообразно применять этот подход на ранних этапах проектирования, что помогает выбрать правильное направление разработки, однако возможно и создание “локальных” прототипов для отдельных элементов пользовательского интерфейса. Таким образом данных подход охватывает как проектирование интерфейса как целого, так и проектирование его частей. Для создания прототипов привлекают не только специалистов, но и конечных пользователей, при этом полезны любые мнения, предложения и графические наброски; основная задача – создать 5-7 вариантов интерфейса решающего одну и туже задачу. При создании прототипов нужно исходить из разумного баланса между следующими ключевыми факторами: · необходимый объем ресурсов для создания прототипа; · планируемое время жизни прототипа (предназначен ли он для решения краткосрочной, локальной проблемы или для длительного, глубокого анализа); · риск смены целей проектирования (сосредоточения внимания не на решении проблемы с помощью прототипов, а на создании самих прототипов). Созданные прототипы подвергаются сопоставительному анализу, в связи с чем необходимо определить критерии оценки. Отправной точкой в определении таких критериев служит та проблема, ради решения которой были созданы прототипы. Ей может быть время ввода данных пользователем, время принятие пользователем решения на основе предоставленной информации, субъективная оценка качества интерфейса по некоторой шкале и т.п. Как правило, наиболее эффективен сопоставительный анализ прототипов по нескольким методам: GOMS, Фокус-группы, Экспертная оценка. Анализ задач Данный анализ состоит из двух аспектов – в выявлении, какие конкретно задачи пытается выполнить пользователь с помощью предлагаемого интерфейса, а также в выявлении насколько эффективно пользователь выполняет поставленную перед ним руководителем тестирования задачу. Для проведения тестирования нужно иметь несколько человек представляющих предполагаемый круг будущих пользователей системы [9], которые незнакомы с интерфейсом [4]. Исследования показывают, что нет необходимости проводить тестированием с большим числом пользователей, оптимальным число является 7-12 субъектов [9]. При таком небольшом числе пользователей можно обнаружить около 80% ошибок и неточностей в интерфейсе (неудачное расположение интерфейсных элементов, неудобное меню, непонятные надписи и т.п.) и получить при этом достоверный результат. Тестирование начинается с предварительного анкетирования пользователей, цель которого – выявить, насколько пользователи знакомы с теми или иными аспектами предметной области, типовыми задачами, есть ли у них опыт работы с подобным программным обеспечением. Пользователям предлагается выполнить простую задачу в соответствии с подготовленным сценарием (который содержит необходимые исходные данные и действия необходимые для его выполнения). Если пользователи хорошо знакомы с предметной областью, то им предлагается самостоятельно выполнить задачу, которую, по их мнению, должно решать приложение. В ходе этого процесса измеряется затраченное пользователем время, количество обращений за помощью, ошибки пользователя, вопросы и комментарии пользователя. Проводится анкетирование пользователей с целью выявить степень удовлетворенности пользователя: насколько полно приложением выполняется задача, предоставлена ли вся необходимая информация, а лишняя скрыта и т.п. На основе полученных данных формируется отчетность: · Анализ портрета типичного пользователя. · Анализ продуктивности работы пользователя. · Оценка общего уровня удовлетворенности пользователей. · Наиболее часто встречающиеся замечания и жалобы пользователей. · Список приоритетных проблем (по числу жалоб пользователей и времени выполнения задачи). Далее в рамках полученных данных идет работа по улучшению интерфейса. Метод GOMS GOMS это семейство методов позволяющих провести моделирование выполнения той или иной задачи пользователем и на основе такой модели оценить качество интерфейса (точнее говоря оценить время выполнения задачи как основной критерий качества) [2]. GOMS это сокращение от английского Goals, Operators, Methods, and Selection Rules – Цели, Операторы, Методы и Правила выбора. Данный способ был предложен S. K. Card, T. P. Moran и A. Newell в 1983 году. Идея метода заключается в том, что все действия пользователя можно представить как набор типовых составляющих составляющие (например, нажать ту или иную кнопку на клавиатуре, передвинуть мышь, и т.п.). Для этих типовых составляющих можно провести измерения времени их выполнения (на большом числе пользователей) и получить статистические оценки времени выполнения того или иного элементарного действия. Оценка качества интерфейса заключается в разложение выполняемой задачи на типовые составляющие, и вычисление времени, которое будет в среднем затрачиваться пользователем на выполнение этой задачи. В данном методе каждая цель или задача (Goal), которую хочет достичь пользователь с помощью интерфейса, состоит их набора методов (Methods) которые в свою очередь построены из операторов (Operators). Если цель может быть достигнута несколькими способами, то выбор осуществляться по правилам выбора (Selection Rules). Простым примером может служить выбор пользователем пиктограммы на рабочем столе в графическом интерфейсе ОС Windows: Операторы: М – передвинуть указатель мыши в нужную точку (1.1сек); П – перенос руки между мышью на клавиатурой (0.4сек); К – нажать клавишу на клавиатуре (0.28сек); Л – щелчок левой кнопкой мыши (0.1сек); А – анализ дальнейших действий (1.2сек); Задача: Выбрать пиктограмму. Метод: Выбор с помощью мыши. К: нажать Win-D для перехода на рабочий стол; А: поиск пиктограммы находится на рабочем столе; П: перенести руку на мышь; М: переместить курсор в нужную точку; Л: выбор пиктограммы. Формально метод GOMS может быть описан следующим способом:  – множество операторов – оператор есть некое действие пользователя  и среднее время  , затрачиваемое пользователем на это действие – множество целей (задач) которые пользователь выполняет с помощью имеющегося интерфейса , где: – множество методов достижения цели   – множество критериев выбора метода достижения цели  – метод есть упорядоченный набор операторов, применяя которые достигается цель Применение метода заключается в определении множества  (оно, как правило, определяется устройством взаимодействующих с пользователем аппаратных средств и функциями операционной системы), выявлении множества  и построении всевозможных последовательностей действий  приводящих к цели и определении критериев выбора  между ними. Затем для каждой последовательности производится расчет времени  которое будет затрачено на достижении цели, его минимум и является главным критерием выбора того или иного варианта пользовательского интерфейса.Данный метод, как и любой другой, имеет свои преимущества и недостатки. Преимущества метода: · простота и удобство расчетов; · отсутствие параметров в модели позволяет проводить оценочные сравнение двух разных вариантов интерфейса; · дает прогноз времени работы пользователя с данным вариантом интерфейса; · модель не требует создания рабочего прототипа; · анализ по этой модели может быть автоматизирован. Наиболее заметными являются следующие ограничения: · метод ориентирован на средних пользователей, и не учитывает особенностей работы новичков и специалистов, а также индивидуальных различий пользователей; · метод не учитывает возникновение случайных ошибок в работе; · модель не учитывает, что в процессе работы происходит научение, а при простое – забывание; · модель не учитывает насколько представляемая интерфейсом информация сложна для понимания пользователем; · модель не учитывает насколько интерфейс отвечает требованиям пользователей и их ожиданиям. |