Учебное пособие ТОАУ Ч.3 (1021725), страница 7

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

Текст из файла (страница 7)

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

Эволюционный прототип.

Эволюционный прототип (evolutionary prototype) создается, как первое приближение системы, призванное стать впоследствии самой системой.

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

В таблице приведено соотношение между рассмотренными выше 4 видами прототипов [10.2].

Таблица

Бумажный прототип.

Бумажный прототип (paper prototype) - отличная альтернатива рассмотренным выше разновидностям электронных прототипов в случае, когда Разработчик ограничен в ресурсах. Наброски интерфейсов на бумаге, конечно, не заменят интерфейс, созданный в среде разработки. Однако, при всех недостатках, у таких прототипов есть два существенных достоинства.

Заказчик не станет акцентировать внимание на цветовом решении, форме кнопок и т.п., отвлекаясь от анализа функциональности.

Заказчик никогда не скажет, глядя на бумажный интерфейс: "Да вы, я вижу, уже создали систему на 85%! Давайте закончим ее в течении недели".

Раскадровка.

Решением промежуточного между электронным и бумажным вариантами прототипов UI класса являются презентации, изготовленные при помощи средств электронного офиса (например, комбинации Microsoft Visio и Microsoft PowerPoint). В этом случае пользователь лишен свободы выбора, предоставляемой ему поведенческим прототипом. Но идею пошаговой смены экранов в процессе реализации сценария варианта использования вполне можно реализовать. Данный вид решения определяется в [10.3], как пассивная раскадровка. Активная раскадровка является дальнейшим развитием понятия пассивной раскадровки, с применением средств анимации и т.п. Третий вид раскадровки, вводимый в [10.3] - интерактивная представляет собой электронный одноразовый горизонтальный прототип.

Иллюстрированные сценарии прецедентов

Иллюстрированные сценарии прецедентов, ИСП [10.4], наряду с прототипами позволяют достичь лучшего понимания между Заказчиком и Разработчиком. Но если прототипы адресованы скорее Заказчику, нежели Разработчику, то с ИСП ситуация обстоит наоборот: они содержат дополнительные сведения, помогающие Разработчику лучше понять специфику проблемной области и, тем самым, лучше отразить ее в интерфейсе пользователя.

Основная идея ИСП - "разбавить" текст описания сценария варианта использования аспектами применимости.

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

Различают [10.4] 3 разновидности аспектов применимости:

• ориентиры,

• средние значения атрибутов и объемы объектов,

• средняя интенсивность использования.

Ориентиры

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

Пример. Описание потока событий ИСП для прецедента "Оформить заказ", расширенного ориентирами (текст в квадратных скобках).

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

Средние значения атрибутов и объемы объектов

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

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

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

В процессе выполнения прецедента менеджер по приему заказов выбирает заказчика из клиентской базы {до 10000 клиентов}, определяет товарные позиции из справочника {товары разбиты на 10 категорий, количество позиций в категории не превышает 500} и указывает их количество {до 100 позиций, средняя закупка - 8 позиций}. Система отображает на мониторе наименование позиций, цену, сумму и количество на складе. Менеджер назначает скидку и определяет порядок оплаты {на данный момент существуют 3 варианта порядка оплаты}. Система рассчитывает итоговую сумму.

Средняя интенсивность использования

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

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

В процессе выполнения прецедента менеджер по приему заказов выбирает заказчика из клиентской базы (в 95% случаев), либо вызывается интерфейс регистрации нового клиента (в 5% случаев).

Документирование требований

Документирование требований в соответствие с ГОСТ РФ

Документирование требований регламентировано российскими ГОСТ 19.201-78 "Техническое задание, требования к содержанию и оформлению" и ГОСТ 34.602-89 "Техническое задание на создание автоматизированной системы" (ТЗ на АС) [11.4-11.5].

Второй документ, по сути, является более проработанной версией первого, адаптированной к созданию автоматизированных информационных систем, поэтому далее рассмотрена структура ТЗ в соответствие с ГОСТ 34.602-89.

Несмотря на то, что для сферы IT 17 лет - это целая эпоха, данный документ практически не устарел: его авторам удалось разработать сбалансированные рекомендации, абстрагируясь от конкретных технических и технологических решений. Кроме того, он по-прежнему играет роль государственного стандарта РФ и при заключении контрактов с государственными предприятиями Разработчика могут обязать оформить ТЗ в соответствии с духом и буквой этого документа.

Структура ТЗ в соответствие с ГОСТ 34.602-89:

1. Общие сведения - в этом разделе, помимо юридических реквизитов сторон и прочей деловой информации ГОСТ рекомендует указать источники и порядок финансирования работ.

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

3. Характеристика объектов автоматизации - достаточно важный раздел. Его основные "разрезы" - организационная структура, структура управления, структура расположения предприятия и его филиалов. Хорошее описание объекта автоматизации позволяет сэкономить время на определение классов пользователей, для крупных территориально-распределенных систем - заложить структуру и топологию сетевых коммуникаций.

4. Требования к системе - ключевой раздел настоящего документа, поэтому он будет рассмотрен ниже, более подробно.

5. Раздел "Состав и содержание работ по созданию системы", говоря современным языком, описывает процесс создания системы, включая выбор методологии, определяющий содержание стадий, этапов и фаз и его конкретизацию для проекта (количество этапов и итераций, их основное содержание).

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

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

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

В качестве приложений ГОСТ рекомендует использовать расчет ожидаемой эффективности системы и оценку научно-технического уровня системы.

Описание требований к системе в соответствие с ГОСТ 34.602-89

ГОСТ разделяет все требования к системе на три класса:

1. требования к системе в целом;

2. требования к функциям (задачам), выполняемым системой;

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

Среди требований к системе в целом (системные требования) указываются требования к:

• структуре системы (здесь закладываются высокоуровневые архитектурные решения, либо структурные ограничения, вводится деление на подсистемы, комплексы и модули, решаются вопросы коммуникации компонент системы и системы с внешним миром),

• режимам функционирования системы;

• персоналу (указывается численность, требуемая квалификация и режим работы);

• надежности;

• безопасности;

• эргономике и технической эстетике;

• транспортабельности для подвижных АС;

• эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы;

• защите информации от несанкционированного доступа;

• сохранности информации при авариях;

• защите от влияния внешних воздействий;

• патентной чистоте;

• стандартизации и унификации,

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

Требования ГОСТ к функциям (задачам), в переводе на современный язык, подразделяются на:

• перечень функциональных требований в привязке к подсистемам и очередям автоматизации;

• временной регламент реализации функциональных требований;

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

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

Требования к видам обеспечения. Среди видов обеспечения ГОСТ указывает математическое, информационное, лингвистическое, программное, техническое, метрологическое, организационное, методическое.

Документирование требований в RUP

Характеристики

Список файлов книги