3. Принципы проектирования пользовательского интерфейса

Интерфейс – это диалог между ПК и пользователем, который происходит по определенным правилам, т.е. интерфейс – это набор приемов взаимодействия с ПК.

На теоретическом уровне интерфейс включает в себя три основных понятия:

-общение ПК с пользователем,

-общение пользователя с ПК,

-представление пользовательского интерфейса.

Способ общения ПК с пользователем определяется приложением, т.е. прикладной программой или программной системой, которая управляет доступом к информации и ее обработкой, а также представлением интерфейса в доступом для пользователя виде.

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

Это достигается через согласованность. Существует три аспекта согласованности интерфейса:

-физическая,

-синтаксическая,

- семантическая.

Физическая согласованность относится к техническим средствам реализации интерфейса. Это схема клавиатуры, задание значения кнопок на манипуляторе мышь и т.д.

Синтаксическая согласованность определяет последовательность и порядку появления элементов интерфейса на экране (язык представления) и последовательность запросов (язык действий).

Семантическая согласованность относится к значению элементов, составляющих интерфейс.

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

3. Жц по в соответствии со стандартом iso-iec 12207.

В данном стандарте ПП определяется, как набор компьютерных программ, процедур и, возможно, связанных с ними документов и данных. Весь ЖЦПО разбивается на процессы.

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

Каждый процесс разделяется на набор действий, а действия на задачи. В соответствии со стандартом ISO/IEC-12207 все процессы ЖЦПО разделяются на три группы:

-основные: приобретение, поставка, разработка, эксплуатация, сопровождение;

-вспомогательные: документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, совместная оценка, аудит, Разрешение проблемм;

-организационные: управление, усовершенствование, создание инфраструктуры, обучение.

Каждый процесс, действие или задача инициируется другими процессами, причем, нельзя заранее точно установить последовательность выполнения (при сохранении связей по входным данным).

3. Управление требованиями к системе

Затем за работу принимается аналитик. Ему необходимо из этой кучи хлама создать документ, в котором четко сформулированы все требования, предъявляемые к разрабатываемой программной системе. Результатом этой работы является ТЗ, один из основных документов, которыми руководствуется разработчик ПП.

Требование – это условие или характеристика, которым должна удовлетворять система. Каждое требование может быть описано любым удобным набором атрибутов. Компоновать требования можно по любому удобному критерию.

Требования бывают функциональные и нефункциональные.

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

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

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

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

-требования к реализации, предписывающие применение определенных стандартов, я/п, операционной системы и т.д.

-требования к надежности, определяющие частоту возможных сбоев и возможность восстановления,

-требования к интерфейсу, определяющие внешние сущности и регламент взаимодействия с ними.

Управление требованиями представляет собой:

-во-первых, систематический подход к выявлению, организации, документированию требований к ПП,

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

Одной из основных целей управления требованиями является улучшение понимания требований со стороны разработчика и достижение соглашения с заказчиком.

Во многих проектах устанавливаются приоритеты, разделяя все требования к ПП на три категории:

-необходимо выполнить,

-желательно выполнить,

-можно выполнить.

Требования, предъявляемые к разработке, могут быть смоделированы при помощи различного рода диаграмм, но они, как правило, служат для понимания требований, а не для управления ими в динамике. Именно динамическая составляющая управления требованиями вызывает наибольшие трудности, т.к. в процессе разработки могут измениться не только требования к ПП, но и их приоритеты. В настоящее время появились специальные программные системы управления требованиями (Requirements Management Systems, RequisitePro, DOORS). Кроме того, полезно для каждого требования хранить его историю, которая помогает отследить: какие изменения были внесены в требования, кем, когда и почему.