ВУЗ: Оренбургский государственный университет
Категория: Методичка
Дисциплина: Проектирование информационных систем
Добавлен: 25.10.2018
Просмотров: 2976
Скачиваний: 5
16
Разбивая требования на отдельные элементы, основным критерием долж-
на быть возможность реализации этих требований отдельно друг от друга (реа-
лизовать первое и не реализовать второе). Если требования сильно зависят друг
от друга, то должны быть реализованы вместе и их лучше объединить. Цель
разделения требований на составные части – получение возможности прини-
мать решения о целесообразности реализации каждого требования в отдельно-
сти и назначать им различные приоритеты, что в дальнейшем обеспечит гиб-
кость в определении списка требований для первой и всех последующих итера-
ций продукта или исключении из текущей версии продукта. Это критично для
продуктов, бюджет и сроки которых строго определены и не могут быть пере-
смотрены.
Создание образа продукта
На протяжении всего жизненного цикла разработки «Образ продукта»
должен являться дорожной картой, которой нужно пользоваться, чтобы не
сбиться с пути. В силу этого он должен содержать самые главные данные и его
описание не должно быть больше половины страницы. Для достижения этой
цели лучше всего подходит следующий шаблон, который содержит все необхо-
димые ключевые вопросы и тезисы:
• «для» – целевая аудитория покупателей;
• «который» – положение о потребностях или возможностях;
• «этот» – имя продукта;
• «является» – категория продукта;
• «который» – ключевое преимущество, основная причина для покупки
или использования;
• «в отличие от» – основной конкурирующий продукт, текущая система
или текущий бизнес-процесс;
• «наш продукт» – положение об основном отличии и преимуществе
нового продукта.
17
Список возможностей должен полностью соответствовать образу реше-
ния. Если между образом решения и списком возможностей есть расхождения,
вы должны это исправить (модернизировать список возможностей или образ
решения).
18
Практическое задание №3. Определение основных профилей пользо-
вателей
1. На основании пользовательских профилей разработать черновой вари-
ант пользовательского интерфейса.
2. Составить план работы после анализа С-требований.
Методические рекомендации для выполнения практической работы
Для того чтобы продукт был удобен пользователям и делал «то, что
надо», сначала надо определить, кто же им будет пользоваться.
На практике, даже для домашних продуктов очень сложно определить
«среднего пользователя», чтобы на основе его потребностей проектировать
продукт. Для корпоративных продуктов это попросту невозможно: директор
будет пользоваться одной функциональностью, его секретарь другой, а бухгал-
тер третьей. По этой причине перед началом сбора требований должны быть
определены основные профили пользователей (рис.1).
Рисунок 1 – Пример диаграммы профилей пользователей продукта
19
Профили пользователей явно или неявно уже должны содержаться в сце-
нариях, поэтому все, что нужно сделать – это выделить их. Для домашних про-
дуктов разделение обычно производится, исходя из уровня подготовленности
пользователя и его интересов, для корпоративных продуктов основным крите-
рием является специализация работника и круг его обязанностей.
Шаги разработки пользовательских интерфейсов
Предлагается 11 этапов разработки пользовательских интерфейсов.
1. Узнайте своего пользователя (С) (обработка С-требований).
2. Поймите назначение проектируемой системы (С).
3. Примените принципы хорошего экранного дизайна (С, D).
4. Подберите подходящий тип окон (С, D).
5. Разработайте системные меню (С, D).
6. Выберите соответствующие аппаратные устройства управления (С).
7. Выберите соответствующие экранные элементы управления (С).
8. Организуйте и создайте раскладку окон (С, D).
9. Выберите подходящие цвета (D).
10. Создайте осмысленные значки (С, D).
11. Предоставьте эффективные сообщения, обратную связь и руководство
(D).
Шаг 1 (знакомство с пользователем). На этом шаге рекомендуется оце-
нить общество конечных пользователей программы. В общих чертах основные
факторы намечены в табл.1.
Шаг 2 (понимание назначения). На этом шаге от дизайнера требуется по-
нимать цель конкретного предлагаемого пользовательского интерфейса в свете
общего назначения программы. Например, если целью является инвентариза-
ция склада, то пользовательский интерфейс может отражать план склада. По-
следовательность экранов может отражать способ, которым обычно пользова-
тели выполняют свои задания вручную.
20
Таблица 1 – Критерии, по которым оцениваются потенциальные пользо-
ватели программы
Характеристика
Градации
Уровень знаний и опыт
Компьютерная грамотность
Высокий
Средний
Низкий → объяснить каждый термин
Системный опыт
Высокий
Средний
Низкий → представить примеры и
анимацию
Опыт работы с подобными програм-
мами
Высокий
Средний
Низкий → представить примеры и
анимацию
Образование
Ученая степень
Колледж
Школа → использовать термины 12-го
класса
Уровень чтения
>12 лет в школе/5-12/
<5 → использовать очень простой
язык
Машинопись
135 слов в минуту / 55/ [10 → пред-
ставить небольшие поля для ввода
текста, примеры, уделить особое вни-
мание формам для заполнения]
Физические характеристики пользователя
Возраст
Молодой/ среднего возраста/ пожилой
Пол
Мужской / женский
Развитие рук
/Левша/ Правша / владеющий одина-
ково oбеими руками
Физические недостатки
Слепой / дефекты зрения / глухой / мо-
торные недостатки
Продолжение таблицы 1