ВУЗ: Оренбургский государственный университет
Категория: Методичка
Дисциплина: Проектирование информационных систем
Добавлен: 25.10.2018
Просмотров: 2712
Скачиваний: 5
21
Характеристики заданий и работы пользователя
Способ использования этой про-
граммы
По усмотрению/[обязательная → сде-
лать программу интересной в исполь-
зовании]
Частота использования
Постоянная / частая / случайная / [ра-
зовая → предоставить всю справоч-
ную информацию с каждым экраном]
Коэффициент текучести кадров Низкий/ средний/[высокий → предста-
вить всю справочную информацию с
каждым экраном]
Важность задания
Высокая / средняя / [низкая → сделать
интересной в использовании]
Повторяемость задания
Низкая / средняя / [высокая → автома-
тизировать как можно больше шагов,
предоставить разнообразие в пред-
ставляемых данных, предоставить
возможности обучения]
Предварительное обучение
Нет/самостоятельное
изучение
по
справочникам / [интенсивное →
предоставить интерактивную систему
обучения]
Категория работы
Администратор/менеджер/ профессио-
нал / секретарь / [клерк и т. д. → ис-
пользовать язык, примеры и описания,
знакомые обычному клерку]
Психологические характеристики пользователя
Вероятное отношение
к работе
Положительное / безразличное / отри-
цательное
Вероятные мотивации
Высокие /средние / [низкие → сделать
приложение особенно привлекатель-
ным]
Стиль процесса познания
Словесный или [пространственный →
подчеркнуть геометрический вид]
Аналитический или [интуитивный →
подчеркнуть символы в тексте]
Конкретный или [абстрактный →
разработать обобщения]
Шаг 3 (понимание принципов хорошего экранного дизайна). Перечислим
некоторые основные элементы хорошего экранного дизайна.
1. Убедитесь в единообразии экранов приложения, а также в логично-
сти каждого отдельно.
• Соглашения; процедуры; местоположение.
22
2. Сделайте предположение о том, откуда, обычно пользователь будет
начинать работу.
• Часто «первый» элемент размещают в верхнем левом углу.
• 3. Сделайте навигацию как можно более простой:
• выровняйте похожие элементы;
• сгруппируйте похожие элементы;
• учтите границы вокруг похожих элементов.
4. Примените иерархию для подчеркивания порядка важности.
5. Примените принципы приятных визуальных эффектов:
• баланс, симметрия, регулярность, предсказуемость;
• простота, единообразие, пропорциональность, экономия.
6.
Предоставьте подписи.
Шаг 4 (выбор подходящего типа окна). Цели каждого пользовательского
интерфейса могут обслуживаться наиболее эффективно одним или двумя кон-
кретными типами окон.
Шаг 5 (разработка системного меню). Ниже перечислены некоторые пра-
вила для создания главных меню.
• Сделать главное меню.
• Показать все уместные альтернативы (но только их).
• Привести структуру меню в соответствие со структурой задачи при-
ложения.
• Минимизировать число уровней меню.
Шаг 6 (выбор подходящих устройств управления). Под устройствами
управления здесь понимаются физические устройства, с помощью которых
пользователи сообщают свои пожелания приложению. Сюда относятся
джойстики, трекболы, графические планшеты, сенсорные экраны, мыши, мик-
рофоны и клавиатуры.
Шаг 7 (выбор подходящих экранных элементов управления). Экранные
элементы управления – это символы, появляющиеся на мониторе, с помощью
которых пользователь передает программе вводимые данные и свои намерения.
23
Сюда относятся значки, кнопки, текстовые окна, списки и др. Правила органи-
зации экранных элементов управления в окне практически те же, что и для: ди-
зайна экрана в общем. Их число также обычно варьируется: от пяти до девяти.
Это число, однако, может быть увеличено в случае использования иерархии.
Шаг 8 (организация и планирование окон). Правила для компоновки мно-
гочисленных окон аналогичны правилам для дизайна одиночных окон (в том
числе симметрия, пропорциональность и т.д.), но сюда включена также и орга-
низация окон – соприкасающиеся или каскадные.
Шаг 9 (выбор подходящих цветов). При использовании с умением и со
вкусом цвет может обогатить экран. Использование цвета не делает автомати-
чески пользовательский интерфейс более полезным или привлекательным, од-
нако может легко испортить его. По выражению знаменитого дизайнера Поля
Рэнда «цвет – это воплощение сложности». Инженеры-программисты, не со-
трудничающие с профессиональными дизайнерами, должны быть очень уме-
ренными и консервативными в использовании цветов. Сначала попробуйте
черно-белую схему. Если есть очевидная потребность в этом, добавьте один
цвет. Убедитесь, что это помогает пользователю. Серьезно подумайте перед
тем, как добавлять больше цветов.
Результирующее расписание по работе над проектом может быть таким
как показано в таблице 2.
24
Таблица 2 –Типичный план после анализа С-требований
1
7 мая
3
1 мая
13июн
2
7июн
1
1июл
2
25июл
1
1 авг
2
5 авг
8
8 сен
Вехи
Законченная версия 0.1Х
Разработка версии 0.1
С-требования
D-требования
Архитектура
Детальное проек-
тирование
Реализация
Тестирование
Разработка версии 0.2
С-требования
D-требования
Архитектура
Детальное проек-
тирование
Реализация
Тестирование ком-
понентов
Интеграция
Системное тести-
рование
25
Практическое задание №4. Разработка детальных требований (D-
требования)
1. На основании данных полученных от заказчика и сборе пользователь-
ских историй провести:
• структурирование пользовательских историй;
• спецификацию требований.
2. Провести контроль функциональных требований и нефункциональных
требований
3. На диаграмме последовательности показать реализации вариантов ис-
пользования.
4. Разработать пользовательский интерфейс, на котором показать реали-
зацию функциональных требований и эргономичность интерфейса.
Методические рекомендации для выполнения практической работы
Разработчикам программного обеспечения нужна база для проектирова-
ния и разработки. Эта база состоит из детальных требований. Их также назы-
вают конкретными требованиями, функциональными спецификациями, требо-
ваниями разработчика или D-требованиями. D-требования состоят из полного
списка конкретных свойств и функциональности, которую должна иметь про-
грамма, сформулированных в подробностях. Каждое из этих требований про-
нумеровано, помечено и отслеживается по ходу разработки. D-требования
должны быть согласованы с С-требованиями. Предполагается, что D-
требования будут читать преимущественно разработчики.
Основной целью анализа требований является их систематизация и из-
бавление от дублируемых данных. Это достигается за счет разделения пользо-
вательских историй на отдельные пакеты по функциональному признаку и их
иерархической структуризации.