Файл: Модели процессов разработки программного обеспечения (Анализ процесса разработки программного обеспечения на примере бибилиотеки).pdf

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

На основе разработанных ранее экранов структуры на этапе проектирования система навигации выбирает наиболее адекватную систему навигации и разработывает подробный интерфейс [6, c. 32].

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

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

Рис. 2.1. Функциональная схема приложения

Рассмотрим интерфейсную часть и модульную связность, изображенную на рисунке 2.2.

Рис. 2.2. Функциональная схема взаимодействия модулей информационной системы библиотеки

Как правило, на данном этапе, не создается отдельный отчет; разработанный интерфейс дополнительно описан в докладе, посвященном разработке низкого уровня.

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

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

Документация является частью интерфейса, а также в сложных системах большей частью.

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

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

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

Для сортировки книг по автору, просто нужно нажать на заголовок столбца «Автор». При этом вокруг элемента появится рамка. Всего доступно 3 группы сортировки: по автору, названию книги и жанру.

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

Форма поиска позволяет искать пользователю, заинтересованного в книге из списке.

Отображение информации о книге. Этот экран содержит краткое изложение книги, такие как: название, автор, издатель и небольшое описание.

В нижней части формы расположена пара кнопок. Кнопка «Читать» откроет содержание книги, а кнопка «Каталог» вернёт пользователя к списку литературы.

Экран содержания книги. Этот экран отображает содержимое книги. Навигация осуществляется на нем с помощью вертикальной полосы прокрутки.

Для более удобной навигации, в этой форме есть поле поиска. Чтобы вернуться к списку литературы следует нажать на «Каталог».

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

Основной экран. Основной экран администратора не сильно отличается от экрана клиента. В дополнение к ранее упомянутых элементов, на нем появляются пара новых. Существует кнопка рядом с полем поиска «Добавить», предназначенная для добавления новых книг в список. Чтобы изменить или удалить существующие записи, есть две кнопки, расположенные слева от названия – «Удалить» и «Редактировать».

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

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

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

После этого нужно улучшить этот список. Сделать следующее:

- уменьшить длину полученных клеток;

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

- убедится в том, что та же концепция не называется в разных местах по-разному;

- проверить совпадение в стиле текста для выбранных платформ;

- уменьшить длину полученных клеток;

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

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

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

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

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

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

Бумажный.

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

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

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

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

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

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

Реальный.

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

3. Тестирование и модификация программного обеспечения

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

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

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

- не имеют всю необходимую информацию о системе;

-  ничего не знают о проектировании интерфейсов;

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

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

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

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