Оценивание интерфейса

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

В идеале оценивание должно про водиться в соответствии с показателями удобства использования интерфейса, перечисленными в табл. 15.5. Каждый из этих показателей можно оценить численно.

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

Однако чаще удобство использования интерфейса оценивается качественно, а не через числовые показатели.

Таблица 15.5. Показатели удобства использования интерфейса

Показатель	Описание
Изучаемость	Количество времени обучения, необходимое для начала продуктивной работы с системой
Скорость работы	Скорость реакции системы на действия пользователя
Устойчивость	Устойчивость системы к ошибкам пользователя
Восстанавливаемость	Способность системы восстанавливаться после ошибок пользователя
Адаптируемость	Способность системы "подстраиваться" к разным стилям работы пользователей

 

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

Проектирование с повторным использованием компонентов

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

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

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

2. Повторно используемые компоненты. Можно повторно использовать компоненты приложений - от подсистем до отдельных объектов. Например, система распознавания текста, разработанная как часть системы обработки текстов, может повторно использоваться в системах управления базами данных..

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

Очевидным преимуществом повторного использования ПО является снижение общей стоимости проекта, так как в целом требуется специфицировать, спроектировать, реализовать и проверить меньшее количество системных компонентов. Но снижение стоимости проекта - это только потенциальное преимущество повторного использования. Как видно из табл. 14.1, повторное использование ПО имеет ряд других преимуществ.

Таблица 14.1. Преимущества повторного использования ПО

Преимущество	Описание
Повышение надежности	Компоненты, повторно используемые в других системах, оказываются значительно надежнее новых компонентов. Они протестированы и проверены в разных условиях работы. Ошибки, допущенные при их проектировании и реализации, обнаружены и устранены еще при первом их применении. Поэтому повторное использование компонентов сокращает общее количество ошибок в системе
Уменьшение проектных рисков	Для уже существующих компонентов можно более точно прогнозировать расходы, связанные с их повторным использованием, чем расходы, необходимые на их разработку. Такой прогноз - важный фактор администрирования проекта, так как позволяет уменьшить неточности при предварительной оценке сметы проекта.
Эффективное использование специалистов	Часть специалистов, выполняющих одинаковую работу в разных проектах, может заниматься разработкой компонентов для их дальнейшего повторного использования, эффективно применяя накопленные ранее знания
Соблюдение стандартов	Некоторые стандарты, такие как стандарты интерфейса пользователя, можно реализовать в виде набора стандартных компонентов. Например, можно разработать повторно используемые компоненты для реализации различных меню пользовательского интерфейса. Все приложения предоставляют меню пользователям в одном формате. Использование стандартного пользовательского интерфейса повышает надежность систем, так как, работая со знакомым интерфейсом, пользователи совершают меньше ошибок
Ускорение разработки	Часто для успешного продвижения системы на рынке необходимо как можно более раннее ее появление, причем независимо от полной стоимости ее создания. Повторное использование компонентов ускоряет создание систем, так как сокращается время на их разработку и тестирование

Таблица 14.2. Проблемы повторного использования

Проблема	Описание
Повышение стоимости сопровождения системы	Недоступность исходного кода компонента может привести к увеличению расходов на сопровождение системы, так как повторно используемые системные элементы могут со временем оказаться не совместимыми с изменениями, производимыми в системе
Недостаточная инструментальная поддержка	CASE-средства не поддерживают разработку ПО с повторным использованием компонентов. Интегрирование этих средств с системой библиотек компонентов затруднительно или даже невозможно. Если процесс разработки ПО осуществляется с помощью CASE-средств, повторное использование компонентов можно полностью исключить
Синдром "изобретения велосипеда"	Некоторые разработчики ПО предпочитают переписать компоненты, так как полагают, что смогут при этом их усовершенствовать. Кроме того, многие считают, что создание программ "с нуля" перспективнее и "благороднее" повторного использования написанных другими программ
Содержание библиотеки компонентов	Заполнение библиотеки компонентов и ее сопровождение может стоить дорого. В настоящее время еще недостаточно хорошо продуманы методы классификации, каталогизации и извлечения информации о программных компонентах
Поиск и адаптация компонентов	Компоненты ПО нужно найти в библиотеке, изучить и адаптировать к работе в новых условиях, что "не укладывается" в обычный процесс разработки ПО

 

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

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

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