Выводы по проектированию пользовательского интерфейса
Хотя ни одно ухищрение не гарантирует создания удачного интерфейса пользователя, плохой интерфейс гарантирует отсутствие пользователей вашей программы. Однако при стремительном появлении новшеств, в сфере пользовательских интерфейсов, понятие "хорошего" интерфейса очень быстро изменяется. Возьмем, например, процесс настройки часов видеомагнитофона. Раньше часы программировали "вслепую" кнопками и переключателями, потом стали применяться дисплеи, для которых использовался экран телевизора, а теперь в некоторых моделях этот процесс выполняется автоматически по радиосигналу. Так и интерфейс пользователя программ будет "эволюционировать" по мере того как индустрия будет устанавливать новые стандарты, и вы, в свою очередь, должны быть всегда в курсе, как в наибольшей степени удовлетворить ожидания пользователя.
Требования к программному обеспечению, как исходные данные для проектирования
Процесс проектирования программных продуктов начинается с определения требований к разрабатываемому программному обеспечению и его исходных данных. В результате анализа требований получают спецификации программного обеспечения в виде текстовых описаний, структурных схем и диаграмм. В процессе определения спецификаций строят общую модель предметной области и конкретизируют основные функции программного продукта и его поведение при взаимодействии с окружающей средой
|
|
|
Этап постановки задачи - один из наиболее ответственных этапов создания программного продукта. На этом этапе формулируют основные требования к разрабатываемому программному обеспечению. Оттого, насколько полно определены функции и эксплуатационные требования, насколько правильно приняты принципиальные решения, определяющие процесс проектирования, во многом зависит стоимость разработки и ее качество.
Функциональные требования регламентируют функционирование или поведение системы (behavioralrequirements). Функциональные требования отвечают на вопрос «что должна делать система» в тех или иных ситуациях. Функциональные требования определяют основной «фронт работ» Разработчика, и устанавливают цели, задачи и сервисы, предоставляемые системой Заказчику.
Нефункциональные требования, соответственно, регламентируют внутренние и внешние условия или атрибуты функционирования системы. К. Вигерс [2] выделяет следующие основные группы нефункциональных требований:
· Внешние интерфейсы (ExternalInterfaces),
· Атрибутыкачества (Quality Attributes),
· Ограничения (Constraints).
Среди внешних интерфейсов в большинстве современных АИС наиболее важным является интерфейс пользователя (UserInterface, UI). Кроме того, выделяются интерфейсы с внешними устройствами (аппаратные интерфейсы), программные интерфейсы и интерфейсы передачи информации (коммуникационные интерфейсы).
|
|
|
Основные атрибуты качества:
· Применимость,
· Надежность,
· Производительность,
· Эксплуатационная пригодность,
Ограничения [2] - формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации. выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных, ...), которые, в свою очередь, могут относиться, например, к внешним интерфейсам (конец цитаты).
Свойства требований:
· полнота,
· ясность,
· корректность,
· согласованность,
· верифицируемость,
· необходимость,
· полезность при эксплуатации,
· осуществимость,
· модифицируемость,
· трассируемость,
· упорядоченность по важности и стабильности,
· наличие количественной метрики.
Полнота. Идея о том, что необходимо сформулировать все требования полностью, т.е. исчерпывающим образом, до начала проектирования, а тем более – реализации системы, изжила себя вместе с так называемым каскадным подходом [2], который поддерживал последовательную модель реализации системы. Спиральный [2] подход, на котором базируется большинство современных методологий, предусматривает поэтапное выделение и детализацию требований на всём протяжении цикла разработки системы.
|
|
|
Требование полноты можно рассматривать в двух аспектах: полнота отдельного требования и полнота системы требований.
Полнота отдельного требования – свойство, означающее, что текст требования не требует дополнительной детализации, то есть в нём предусмотрены все необходимые нюансы, особенности и детали данного требования.
Полнота системы требований – свойство, означающее, что совокупность артефактов, описывающих требования, исчерпывающим образом описывает всё то, что требуется от разрабатываемой системы.
Дата добавления: 2018-02-15; просмотров: 742; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!