Смекни!
smekni.com

Разработка программного обеспечения виртуальной библиотеки (стр. 1 из 5)

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

1. Анализ предметной области

1.1 Оценка и изучение предметной области

1.2 Определение необходимой функциональности системы

1.2.1 Анализ целей пользователей

1.2.2 Анализ действий пользователей

1.3 Создание пользовательских сценариев

2. Высокоуровневое проектирование

2.1 Проектирование структуры экранов системы

2.2 Проектирование навигационной системы

2.3 Проектирование структуры справочной системы

3. Низкоуровневое проектирование

3.1 Проектирование экранов клиентской части

3.2 Проектирование экранов администраторской части

3.3 Тестирование

3.4 Экспертная оценка

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

4.1 Этапы построения прототипа

4.1.1 Бумажный

4.1.2 Презентационный

4.1.3 Псевдореальный

4.1.4 Реальный

5. Тестирование и модификация прототипа

ЗАКЛЮЧЕНИЕ

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ


ВВЕДЕНИЕ

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

Сохранение и использование рукописных и печатных документов достаточно хорошо освоено. Здесь имеется богатый опыт, результаты исследовательской и практической работы многих поколений специалистов. Но очевидно, что с постоянным увеличением объёмов информации, работа с ней (такая как хранение, поиск, учёт и т.д.) становится всё сложнее. Развитие вычислительной техники позволило сохранять и распространять информацию в электронной форме. Это играет революционную роль в истории человечества, сравнимую с изобретением книгопечати.

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

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

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

Основные задачи виртуальной библиотеки:

- интеграция разнородных информационных ресурсов;

- регистрация (публикация) новых данных;

- хранение и предоставление доступа к таким данным;

- координация других электронных коллекций по профилю данной библиотеки.

Под интеграцией информационных ресурсов понимается их объединение с целью использования (с помощью удобных и унифицированных пользовательских интерфейсов) различной информации с сохранением её свойств, особенностей представления и пользовательских возможностей манипулирования с ней. При этом объединение ресурсов не обязательно должно осуществляться физически, оно может быть виртуальным. Главное, чтобы оно обеспечивало пользователя возможностью воспринимать доступную информацию как единое целое. Новые технологии, разрабатываемые в этой области, прежде всего и ориентированы на решение этой важнейшей задачи. В частности, цифровые библиотеки принесли с собой новый, более высокий уровень семантического описания.

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

На сегодня, печатная информация является основным источником формирования цифровых библиотек.


1. Анализ предметной области

Предметная область - это материальная система или система, характеризующая элементы материального мира, информация о которой хранится и обрабатывается. Предметная область рассматривается как некоторая совокупность реальных объектов и связей между ними. Каждый объект обладает определённым набором свойств (атрибутов).

1.1 Оценка и изучение предметной области

Для того чтобы адекватно оценить ресурсы (время, деньги, количество экспертов), которые будет необходимо потратить на разработку (переработку) интерфейса, необходимо четко представлять себе объем информации, с которой следует ознакомиться.

Чтобы предлагать адекватные интерфейсные решения заказчику, необходимо иметь четкое представление о предметной области системы. Предметная область изучается по литературе. Наряду с этим, как правило, проводится серия интервью с экспертами для выяснения основных аспектов и характеристик предметной области.

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

1.2 Определение необходимой функциональности системы

На первом этапе необходимо определить функциональность будущей системы. Это исключительно важный этап, поскольку именно функциональность будет определять весь интерфейс. Очень важно сознавать, что практически невозможно убрать из уже продающейся системы какие-либо функции. Во-первых, программы до сих пор продаются по функциям, т.е. чем больше список функций на коробке с программой, тем легче её продать, даже если большинство функций либо не работает, либо не нужно пользователям. Происходит это потому, что существенную часть тиража программы покупают новые пользователи, которые ничего не знают про истинное положение вещей. Во-вторых, имеющиеся пользователи обычно с исключительной неохотой переучиваются для использования новых функций взамен прежних (при этом еще и обижаются из-за того, что их инвестиции в обучение оказались выброшенными на ветер). Это значит, что ненужная функция системы будет кочевать из версии в версию, раздувая размеры программы, снижая надежность и быстродействие, и, что для нас более важно, портя интерфейс (при этом и длительность разработки возрастает). Несколько лучшая ситуация с сайтами - никого пока не удивляет, когда сайт после изменения дизайна почти не напоминает прежний. Так что оптимальным вариантом работы почти всегда является проектирование функциональности сразу на несколько версий вперед.

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

Всегда может оказаться, что желание клиента получить новую функцию, обусловлено не реальной потребностью в ней, а собственно концептуальными проблемами системы. Системы же конкурентов страдают как от такого же непонимания проблемы, так и от множества других причин. Это значит, что прислушиваться к сторонним требованиям к системе, безусловно, следует, но рассматривать эти требования нужно не как директивы, но как признаки общего неблагополучия. Некой фирмой было разработано техническое задание к системе каталогизации изображений, рассчитанной на домашних пользователей, которая состояла из сведенного в таблицу списка всех функциональных возможностей всех конкурентов. В результате система получила огромное количество никому не нужных возможностей, что не только никак не помогло ей на рынке, но и безмерно удлинило срок её разработки.

Существует два принципиально разных подхода к определению функциональности системы. При первом подходе система снабжается максимальным количеством функций, при этом результаты многих из них являются суммой результатов других функций. При другом подходе все составные функции (метафункции) из системы изымаются. Ярким представителем первого подхода является CorelPhotoPaint, не менее ярким представителем другого - AdobePhotoShop.

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

Судя по всему, людям больше нравится пользоваться низкоуровневыми функциями, поскольку это позволяет добиваться более тонких и предсказуемых результатов. С другой стороны, доказательств этого не так уж много (сам факт того, что PhotoShop продается лучше, чем PhotoPaint, говорит не так уж о многом). Таким образом, выбор подхода не слишком прост. С другой стороны, остается возможность компромисса: всегда можно включить в систему средства автоматизации, чтобы пользователи получали возможность создавать (и распространять) свои метафункции, каковой подход как раз и применен в PhotoShop.