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

Стилевая гибкость – возможность использовать различные интерфейсы с одним и тем же приложением, на практике реализуется в виде набора “skins”, для web-интерфейсов – с помощью таблицы стилей, в том числе возможность в выборе пользователем собственных установок ПИ (цвет, иконы, подсказки и пр.).

Совместное наращивание функциональности – возможность развивать приложение без разрушения (т.е. оставаясь в рамках) существующего интерфейса.

Масштабируемость – возможность легко настраивать и расширять как интерфейс, так и само приложение при увеличении числа пользователей, рабочих мест, объема и характеристик данных.

Адаптивность к действиям пользователя – приложение должно допускать возможность ввода данных и команд множеством разных способов (клавиатура, мышь, другие устройства) и многовариативность доступа к прикладным функциям (иконы, «горячие клавиши», меню …), кроме того программа должна учитывать возможность перехода и возврат от окна к окну, от режима к режиму, и правильно обрабатывать такие ситуации.

Независимость в ресурсах – для создания пользовательского интерфейса должны предоставляться отдельные ресурсы, направленные на хранение и обработку данных, необходимых для поддержки пользователя (пользовательские словари, контекстно-зависимые списки, наборы данных по умолчанию или по последнему запросу, истории запросов и пр.)

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

Вопросы

1) Что такое понятие Usability?

2) Какие проблемы возникают при разработки ПО?

3) С чем связана удовлетворенность пользователя от работы?

4) Какие существуют принципы реализации пользовательского интерфейса?

5) Что отражает функциональная полнота?

Дополнительная информация

1)http://www.usability.ru/Articles/software-ergonomics.htm

2)http://www.cntd.ru/assets/files/upload/250713/55241.1-2012.pdf

3) http://psychlib.ru/mgppu/MZE-2001/MEC-001.HTM

 

Лекция №8. Управление требованиями к программному продукту. CASE-средство RequisitePro.

План лекции

- Внедрение системы управления требованиями.

- Определение принципов создания хранилищ и политики доступа к ним.

- Фиксация инструментария, рабочей среды, средств разработки и внешних интерфейсов.

- Определение идентификации требований.

- Определение трассировки требований.

- Определение группы, видов, атрибутов требований.

- Определение метрик и отчетов.

- Определение принципов управления требованиями, формирование группы управления изменениями.

- Определение контрольных точек проекта.

- Внедрение разработанной системы УТ на проекте.

- Подсистема управления требованиями на основе IBM RationalRequisitePro.

 

Введение

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

Цель данного документа - продемонстрировать общую последовательность действий, которые обычно выполняются при работе с RequisitePro, и рассказать о некоторых его технических особенностях. Здесь не описываются назначение и все возможности продукта. Также не раскрывается смысл многих терминов, что достаточно подробно выполнено в RationalUnifiedProcess (рубрика “Glossary”)

Нормативная основа

В качестве нормативной основы при разработке лекции использован стандарт:

IEEE Std 830-1993 «IEEE Recommended Practice for Software Requirements Specifications».

В таблице 5 приведены основные термины и определения.

 

Таблица 5 – Термины, сокращения и определения

Сокращение, термин	Расшифровка сокращения или термина	Категория на английском языке
ГОК	Группа обеспечения качества	Quality Assurance Group
ГТР	Группа технологии разработки	Engineering Process Group
Заказчик	Организация, в интересах которой разрабатывается программный продукт, имеющая полномочия утверждать требования к программному продукту и принимать результат разработок. В качестве заказчика может выступать сторонняя фирма, департамент компании, руководитель комплексного проекта, группа маркетинга и пр. В контексте настоящего Положения под Заказчиком понимаются ответственные сотрудники, имеющие полномочия согласовывать и утверждать технические и организационные документы проекта от имени Заказчика.	Customer
Ключевая роль	Роль, которая должна быть заполнена в течение всего жизненного цикла проекта, причем, как правило, одним и тем же специалистом. Если роль в проекте заполнена несколькими специалистами, ключевую роль будет играть специалист, назначенный ведущим за данное направление.	Кеуrole
Аналитик	Ключевая роль в рабочей группе проекта разработки программного обеспечения, отвечающая за управление требованиями	Analyst
Менеджерпроекта	Ключевая роль в рабочей группе проекта разработки программного обеспечения, отвечающая за организацию работ и координацию действий участников проекта	ProjectManager
Нетехническое требование	Требование, относящееся к организации разработки продукта	Non technical Requirement
Нефункциональное требование	Техническое требование, описывающее условие или ограничение, которому должен удовлетворять программный продукт	Non functional requirement
ПО	Программное Обеспечение	Software
Проект	Ограниченная во времени деятельность, направленная на разработку уникального продукта	Project
Проектировщик	Ключевая роль в рабочей группе проекта разработки программного обеспечения, отвечающая за разработку технического проекта	Designer
Разработчик	Ключевая роль в рабочей группе проекта разработки программного обеспечения, отвечающая за кодирование и отладку ПО	Developer
Роль	Множество обязанностей, которое возлагается на сотрудника на время выполнения проекта. Один сотрудник может совмещать несколько ролей в проекте. Одну роль в проекте могут выполнять несколько специалистов. В последнем случае группа специалистов, выполняющая одну роль, должна быть структурирована с выделением ведущего члена рабочей группы, ответственного за организацию работ по данному направлению.	Role
Тестировщик	Ключевая роль в рабочей группе проекта разработки программного обеспечения, отвечающая за тестирование разрабатываемого программного продукта	Tester
Технический проект	Документ с описанием технических решений, положенных в основу разработки, архитектуры разрабатываемой программной системы и методики разработки.	Design
Техническое требование	Требование, относящееся к характеристикам разрабатываемого продукта	Technical Requirement
ТЗ	ТехническоеЗадание	Requirement Specification
ТЗПО	Техническое Задание на Программное Обеспечение	Software Requirement Specification
Требование	Описание способности или ограничения	Requirement
Функциональное требование	Техническое требование, описывающее способность выполнения программным продуктом определенной функции	Functional Requirement

Основные положения

 

8.2.1 Цели управления требованиями

Целями управления требованиями являются:

1) Обеспечение контроля над процессами управления требованиями с целью обеспечения разработки программного продукта в точном соответствии с требованиями заказчика;

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

8.2.2 Участники управления требованиями

Для описания процессов управления требованиями выделяются следующие ключевые роли, должности и группы[17]:

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

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

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

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

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

6. ГОК – группа обеспечения качества. Специалисты группы в соответствии с планом работы группы осуществляют необходимые проверки и аудит процессов управления требований.

7. ГТР – группа технологии разработки. Группа несет ответственность за поддержку и совершенствование процессов управления требованиями в проектах разработки программного обеспечения.

8. Заказчик – организация, имеющая полномочия утверждать требования и вести приемку разработанного программного продукта.

8.2.3 Политика в области управления требованиями

В данном разделе приведены принципы, которые положены в основу управления требованиями в компании.

1. Координация работ по управлению требованиями в проекте возлагается на одного члена рабочей группы – Аналитика, на протяжении всего жизненного цикла проекта.

2. Требования к разрабатываемому программному обеспечению должны быть документированы.

3. Документ, содержащий требования к разрабатываемому продукту, должен быть письменно утвержден Заказчиком[1]. После утверждения требований Заказчиком технические риски, связанные с формулировкой требований принимает на себя Заказчик.

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

5. Требования должны быть согласованы со всеми ключевыми членами рабочей группы проекта.

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

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

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

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

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

11. Документ, описывающий требования к ПО – Техническое Задание должен находиться под конфигурационным контролем.

12. Группа обеспечения качества в соответствии со своим планом проводит проверки и аудит процедур управления требований.

 

 

8.3 Обеспечение процессов управления требований