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

Прецеденты на стадии развития

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

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

На каждом семинаре список задач пользователей и прецедентов постепенно уточняется. По окончании фазы развития большинство прецедентов должны быть описаны или переписаны в развернутом формате (примерно 80-90%). Если для POS-системы выделено 20 прецедентов, то как минимум 15 наиболее слож­ных и рискованных из них должны быть определены полностью.

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

Прецеденты на стадии конструирования

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

Пример: прецеденты начальной фазы проекта Алтын

На начальной стадии не все прецеденты описываются детально. Модель прецедентов на этом этапе может быть разрабо­тана на следующем уровне детализации.

В развернутом формате	В свободном формате	Краткое описание
Оформление продажи Возврат товара	Вычисление арендной платы Анализ торговой деятельности	Регистрация выручки Управление пользователями Запуск системы Завершение работы Управление системными таблицами

---

Определение остальных требований

Введение

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

В словарь терминов (glossary) включаются термины и определения. Он также может служить словарем данных.

Документ "Видение" определяет видение проекта. В нем кратко описывают­ся основные цели проекта, проблемы, указывается круг заинтересованных лиц, их потребности, а также основные идеи предложенного решения.

"Документ "Видение" определяет точку зрения заинтересованных лиц на разрабатываемый продукт в терминах их основных потребностей и свойств продукта. Этот документ содержит описание неочевидных ос­новных требований и составляет основу для более детального описания технических требований".

Примеры для системы Алтын

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

Пример Алтын: фрагмент дополнительной спецификации

Дополнительная спецификация

Введение

В этом документе описаны все требования к POS-системе Алтын, не вошедшие в описание прецедентов.

Функциональность

(Имеющая отношение ко многим прецедентам)

Регистрация событий и обработка ошибок

Все ошибки регистрируются на постоянном носителе.

Подключаемые бизнес-правила

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

Безопасность

Необходимо выполнять аутентификацию всех пользователей.

Удобство использования

Человеческие факторы

Пользователь POS-системы будет работать с большим монитором, поэтому необходимо следующее.

• Текст должен быть виден с расстояния 1 м

• Нужно избегать мерцающих цветов

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

---

Надежность

Возможность восстановления информации

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

Производительность

Покупатель хочет сделать покупку как можно скорее. Задержка этого процесса мо­жет быть связана с внешней службой авторизации. Наша задача — выполнить авторизацию не более чем за 1 минуту в 90% случаев.

Возможности поддержки

Адаптация системы

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

Конфигурирование

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

Ограничения

Руководство проекта Алтын настаивает на применении технологии Java, поскольку это улучшит возможности по поддержке системы и ее переходу на различные платформы, а также обеспечит простоту разработки,

Приобретаемые компоненты

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

Бесплатные компоненты на основе открытого кода

В целом, рекомендуется максимальное использование в этом проекте компонентов на основе открытого кода в рамках Java-технологии.

Несмотря на то, что пока преждевременно определять проектные решения, предлагаются следующие варианты.

• Контур регистрации Jlog

Интерфейсы

Важные интерфейсы и аппаратные средства

• Сенсорный монитор (воспринимаемый операционной системой как обычный монитор; прикоснове­ния обрабатываются как события мыши).

• Лазерный сканер для считывания штрих-кодон (ои«чмп подключаемый к специальной клавиатуре; считанный код оЬраЬатывается как последовательность нажатия клавиш).

• Устройство для печати чеков.

• Устройство считывания данных с кредитной/дебитной карточки.

• Устройство считывания подписи (не в первой версии системы).

Бизнес-правила

Имя	Правило	Возможность изменения
ПРАВ1	Для платежей по кредитной кар­точке требуется подпись	Подпись покупателя будет нужна, но через 2 года большинство пользователей захотят применять цифровое устройство для ввода подписи, з, через пять лет может понадобиться поддержка уникаль­ной цифровой закодированной подписи, введенной в настоящее время в США
ПРАВ2	Правила вычисления налоговых платежей. С продаж отчисляют­ся налоги. Правила налогообло­жения изложены в официальных документах
ПРАВЗ	При возврате товара, купленного по кредитной карточке, возврат денег осуществляется не налич­ными, а путем перевода на кредитную карточку

---

Вопросы законодательства

Рекомендуется использование бесплатных компонентов на основе открытых систем.

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

Информация из предметной области

Ценовая политика

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

Обработка платежей по кредитной и дебитной карточке

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

Вычисление налогов

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

Дополнительная спецификация (комментарии)

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

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

• Отчеты.

• Ограничения на аппаратные и программные средства (операционные и сете­вые системы и т.д.).

• Ограничения, накладываемые на процесс разработки (например, процесс или средства разработки).

• Другие ограничения проектирования или реализации.

• Международные соглашения (единицы измерения, языки и т.д.). В Документация (пользовательская, руководство по установке и администри­рованию) и справочная информация.

---

• Соглашения о лицензировании или другие юридические соглашения.

• Разбиение на пакеты.

• Стандарты (технические, обеспечения качества и безопасности).

• Физические требования к окружению (например, температурный режим эксплуатации или ограничения на вибрацию).

• Операционные требования (например, способ обработки ошибок, частота ар­хивации).

• Информация из предметной области (например, о полном цикле обработки платежа по кредитной карточке).

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

Необходимо использовать продукты Oracle (поскольку с этой компанией сущест­вует лицензионное соглашение).

Система должна работать в операционной системе Linux (она бесплатна).

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

Атрибуты качества

Некоторые требования называются атрибутами качества (quality attributes) системы. К ним относятся удобство использования, надежность и т.д. Заметим, что это качественные характеристики системы, однако не все они должны обеспечи­вать высокое качество соответствующего процесса (слово "качество" имеет два раз­ных значения). Например, возможности поддержки (качественная характеристика) могут быть низкими, если данный программный продукт не предназначен для долгосрочной эксплуатации.

Атрибуты качества делятся на два типа.

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

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

Функциональность системы определяется в описании прецедентов (например, требования к производительности указываются при описании прецедента Оформление продажи).

Другие атрибуты качества, согласно модели FURPS+, определяются в до­полнительной спецификации.

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

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

---

Смотрите также файлы

• Курсовая работа Управление проектами.docx

• Лабораторная ПРИС управление мероприятиями.docx

• КИС Контрольная работа.doc

• Технические измерения и приборы курсовой.pdf

• Курсовая.doc