|
Содержание работы или список заданий
|
ПРОЕКТИРОВАНИЕ АРХИТЕКТУР
ИНФОРМАЦИОННЫХ СИСТЕМ
Методические указания к контрольной работе
по дисциплине «Архитектура информационных систем»
Введение
Разработка информационной системы состоит из трех этапов:
анализа, проектирования и реализации, в результате итеративного выполнения которых происходит пошаговое «наращивание» системы.
На этапах анализа и проектирования происходит построение архитектуры будущей информационной системы. Архитектура программного обеспечения системы или набора систем состоит из всех важных проектных решений по поводу структур программы и взаимодействий между этими структурами, которые составляют системы. Проектные решения обеспечивают желаемый набор свойств, которые должна поддерживать система, чтобы быть успешной. Проектные решения предоставляют концептуальную основу для
разработки системы, ее поддержки и обслуживания.
Цель данных методических указаний – изучение на практике
применения в проектировании подходов и методов, позволяющих
получать успешные архитектуры информационных систем. Методические
указания построены по принципу выдачи заданий на контрольные
работы и приведения комментариев и примеров к их выполнению.
Контрольные работы взаимосвязаны между собой и предполагают
последовательное выполнение.
Контрольная работа №1 «Установление требований»
Задание
Предложить для разработки информационную систему (ИС). ИС
должна представлять собой программный комплекс, наделенный
функциональностью, автоматизирующей конкретную деятельность в
рамках предметной области, для которой разрабатывается система. Примером
таких систем могут служить:
• автоматизированные системы управления (АСУ)
• электронные магазины, аукционы
• веб-порталы
• сервисы
Что надо сделать?
Составить документ описания требований к разрабатываемой ИС
согласно шаблону (см. рис.1).
Изучить, выбрать и обосновать выбор архитектуры ИС по варианту предметной области!
1.1 Установление требований
1.1.1 Документ описания требований
Документ, описывающий требования, является осязаемым
результатом этапа установления требований. Большинство организаций
вырабатывает документ описания требований в соответствии с заранее
определенным шаблоном. Шаблон определяет структуру (содержание) и
стиль документа.
Ядро документа описания требований состоит из формулировок
(изложения) требований. Требования могут быть сгруппированы в виде
формулировок сервисов (зачастую называемых функциональными
требованиями) и формулировок ограничений. Формулировки сути
сервисов могут быть затем разделены на требования к функциям (function
requirements) и требования к данным (data requirements). (В литературе
термин «функциональные требования» (functional requirements) в
широком и в узком смысле используется как взаимозаменяемый. При
использовании в узком смысле он соответствует тому, что мы называем
требованиями к функциям).
Не говоря уже о самих требованиях, документ описания требований
должен обращаться к проектным вопросам. Обычно проектные вопросы
рассматриваются в начале документа, а затем в конце документа.
Во вводной части документа рассматривается бизнес-контекст
проекта, включая цель проекта, участников проекта и основные
ограничения. Ближе к заключительной части документа поднимаются
другие проектные вопросы, включая план-график выполнения проектных
работ, бюджет, риски, документацию и т. д.
1.1.2 Шаблоны документа
Шаблоны для документов описания требований широко доступны.
Их можно найти в учебниках, стандартах, выпускаемых такими
организациями как ISO, IEEE и т. д., на Web-страницах консалтинговых
фирм, программных средствах разработки и т. д. Со временем каждая
организация разрабатывает свои собственные стандарты, которые
соответствуют принятой в организации практике, корпоративной
культуре, кругу читателей, типам разрабатываемых систем и т. д.
Шаблон документа описания требований определяет структуру
документа и содержит подробные указания о содержании каждого из
разделов документа. Указания могут включать содержание вопросов,
мотивацию, примеры и дополнительные соображения.
На рис. 1 показано типичное оглавление документа описания
требований. Последующие разделы включают объяснение к приведенному
оглавлению.
1.1.3 Предварительные замечания к проекту
Часть документа описания требований, содержащая
предварительные замечания к проекту, преимущественно дает ориентиры
тем руководителям и участникам проекта, ответственным за принятие
решений, которые, вероятно, не станут подробно изучать документ
целиком. В начале документа необходимо ясно обозначить цели и рамки
проекта, а затем описать деловой контекст системы.
Документ описания требований должен создать прецедент для
системы. В частности, необходимо упомянуть обо всех усилиях,
приложенных для обоснования необходимости системы на этапе
планирования системы. Документ описания требований должен прояснить
вопрос о том, каким образом предлагаемая система может способствовать
достижению деловых целей и решению задач организацией.
Необходимо обозначить участников проекта системы. Важно, чтобы
заказчик выступал не в виде безликого подразделения или офиса —
необходимо привести конкретные имена. К концу дня человек должен
быть в состоянии решить, приемлемо ли поставляемое программное
обеспечение (ПО) для организации.
Документ описания требований
Содержание документа
1. Предварительные замечания к проекту
1.1. Цели и рамки проекта
1.2. Деловой контекст
1.3. Участники проекта
1.4. Идеи в отношении решений
1.5. Обзор документа
2. Системные сервисы
2.1. Рамки системы
2.2. Функциональные требования
2.3. Требования к данным
3. Системные ограничения
3.1. Требования к интерфейсу
3.2. Требования к производительности
3.3. Требования к безопасности
3.4. Эксплуатационные требования
3.5. Политические и юридические требования
3.6. Другие ограничения
4. Проектные вопросы
4.1. Открытые вопросы
4.2. Предварительный план-график
4.3. Предварительный бюджет
Приложения
Глоссарий
Деловые документы и формы
Ссылки
Рис.1 Содержание документа описаний требований
Хотя документ описания требований может быть как угодно далек
от технических решений, все же важно обсудить идеи, касающиеся
решения на самых ранних этапах жизненного цикла (ЖЦ) разработки.
Особый интерес представляют готовые решения. Всегда неплохо
рассмотреть вариант приобретения готового продукта вместо его
разработки «с нуля».
Документ описания требований должен предоставлять перечень
существующих программных пакетов и компонент, которые должны быть
в дальнейшем изучены в качестве вариантов возможных решений.
Обратите внимание, что приобретение готового решения изменяет
процесс разработки, однако это не избавляет от необходимости
проведения анализа требований и проектирования системы!
Наконец, неплохо в заключение раздела предварительных замечаний
к проекту документа описания требований привести обзор оставшейся
части документа. Это может подтолкнуть к тому, чтобы изучить остальные части документа, а также способствует лучшему пониманию содержания документа. Обзор также может содержать пояснения в отношении методологии анализа проектирования, выбранной разработчиками.
1.1.4 Системные сервисы
Основная часть документа описания требований посвящена
определению системных сервисов. Эта часть может занимать до половины
всего объема документа. Это также, пожалуй, единственная часть
документа, которая может содержать обобщенные модели — модели
бизнес-требований.
Рамки системы можно моделировать с помощью диаграммы
контекста. В пояснениях к диаграмме контекста должны быть четко
определены рамки системы. Без подобного определения проект не может
быть застрахован от попыток «растянуть» его рамки.
Функциональные требования можно моделировать с помощью
диаграммы бизнес-прецедентов. Однако диаграмма охватывает перечень
функциональных требований только в самом общем виде. Все требования
необходимо обозначить, классифицировать и определить.
Требования к данным можно моделировать с помощью диаграммы
бизнес-классов. Так же, как и в случае функциональных требований,
диаграмма бизнес-классов не дает полного определения структур данных
для бизнес-процессов. Каждый бизнес-класс требует дальнейших
пояснений. Необходимо описать атрибутное наполнение классов и
определить идентифицирующие атрибуты классов. В противном случае
невозможно правильно представить ассоциации.
1.1.5 Системные ограничения
Системные сервисы определяют, что должна делать система.
Системные ограничения определяют, насколько система ограничена при
выполнении обслуживания. Системные ограничения связаны со
следующими видами требований.
• Требования к интерфейсу.
• Требования к производительности.
• Требования к безопасности.
• Эксплуатационные требования.
• Политические и юридические требования.
Требования к интерфейсу определяют, как система взаимодействует
с пользователями. В документе описания требований определяется только
«впечатление и ощущение» от GUI-интерфейса.
Начальное проектирование (закрашивание экрана) GUI-интерфейса
проводится во время спецификации требований и позже во время
системного проектирования.
В зависимости от области приложения требования к
производительности могут играть довольно значительную роль в успехе
проекта. В узком смысле они задают скорость (время отклика системы), с
которой должны выполняться различные задания. В широком смысле,
требования к производительности включают другие ограничения —
в отношении надежности, готовности, пропускной способности и т. д.
Требования к безопасности описывают пользовательские права
доступа к информации, контролируемые системой. Пользователям может
быть предоставлен ограниченный доступ к данным или ограниченные
права на выполнение определенных операций с данными.
Эксплуатационные требования определяют программно-
техническую среду, если она известна на этапе проектирования, в которой
должна функционировать система. Эти требования могут оказывать
влияние на другие стороны проекта, такие как подготовка пользователей и
сопровождение системы.
Политические требования и юридические требования скорее
подразумеваются, чем явно формулируются в документе описания
требований. Подобная ошибка может обойтись очень дорого. Пока эти
требования не выведены явно, программный продукт может быть трудно
развернуть по политическим или юридическим причинам.
Возможны и другие виды ограничений. Например, в отношении
некоторых систем могут предъявляться повышенные требования к
легкости их использования (требования в отношении пригодности к
использованию) или легкости их сопровождения (требования в отношении
пригодности к сопровождению).
Значение выработки недвусмысленных определений для системных
ограничений трудно переоценить. Существует немало примеров проектов,
которые провалились из-за упущенных или неверно понятых
ограничений. Эта проблема в равной мере относится как к заказчикам, так
и к разработчикам. Недобросовестные или нерассудительные
разработчики могут разыграть «карту системных ограничений», чтобы
получить преимущество в своем стремлении уклониться от
ответственности.
1.1.6 Проектные вопросы
Заключительная часть документа описания требований обращается к
другим проектным вопросам. Один из важных разделов этой части
называется «Открытые вопросы».
Здесь поднимаются все вопросы, которые могут сказаться на успехе
проекта и которые не рассматривались в других разделах документа.
Сюда относится ожидаемое возрастание значения некоторых требований,
которые в текущий момент выходят за рамки проекта. Сюда можно
отнести также любые потенциальные проблемы и отклонения в поведении
системы, которые могут начаться в связи с развертыванием системы.
В этой же части необходимо представить предварительный план-
график выполнения основных проектных заданий. Сюда же относится
предварительное распределение людских и других ресурсов. Для
выработки стандартных плановых графиков можно использовать
программные средства управления проектами, например, такие как
система PERT (program evaluation_and_review technique — метод оценки и
пересмотра планов) или карты Ганта. Прямым результатом составления план-графика может быть разработка предварительного бюджета. Стоимость проекта может быть выражена скорее в виде диапазона значений затрат, а не конкретного значения. При наличии надлежащим образом документированных требований для оценки затрат можно использовать один из подходящих методов.
1.1.7 Приложения
Приложения содержат остальную, полезную для понимания
требований, информацию. Основным добавлением здесь служит
глоссарий. Глоссарий определяет термины, сокращения и аббревиатуры,
используемые в документе описания требований. Значение толкового
глоссария трудно переоценить. Неверное истолкование терминологии
таит в себе большую опасность для проекта.
Одна из особенностей, которую часто упускают из виду при
составлении документа описания требований, состоит в том, что в
проблемной области, определяемой документом, можно довольно неплохо
разобраться с помощью изучения документов и форм, используемых в
процессах делопроизводства. При возможности следует включать в
документ заполненные формы — «пустые» формы не дают такого же
уровня понимания бизнес-процессов.
Раздел ссылок содержит перечень документов, которые
упоминаются или используются при подготовке документа описания
требований. К ним могут относиться книги и другие опубликованные
источники информации, но — что, пожалуй, даже более важно —
необходимо также упомянуть протоколы совещаний, служебные записки
и внутренние документы.
1.2 Пример документа описания требований
Документ описания требований ИС «Домашняя бухгалтерия»
1. Предварительные замечания к проекту
1.1. Цели и рамки проекта
Целью данного проекта является разработка информационной
системы для ведения и оптимизации семейного бюджета.
ИС «Домашняя бухгалтерия» должна быть проста в использовании
и не требовать от пользователя знаний бухгалтерского учета.
1.2. Деловой контекст
Многие семьи в наше время планируют семейный бюджет. Ведение
семейного бюджета при помощи подручных средств – карандаш,
бумага – не всегда удобно и всегда трудоемко. Использование для
этих целей компьютерных программ для ведения бухгалтерии не
оправдано с точки зрения сложности их освоения и избыточного
функционала для ведения домашней бухгалтерии. В связи с этим
возникает необходимость создания специализированной программы
ведения домашней бухгалтерии.
1.3. Участники проекта
Заказчик –
Разработчик –
1.4. Идеи в отношении решений
Программа должна быть реализована в виде настольного приложения для операционных систем семейств MS Windows.
1.5. Обзор документа
В разделе «Системные сервисы» описывается, что должна делать
система. В разделе «Системные ограничения» определяется,
насколько система ограничена при выполнении обслуживания.
В разделе «Проектные вопросы» освещаются прочие проектные
вопросы.
2. Системные сервисы
2.1. Рамки системы
Рамки системы можно моделировать с помощью диаграммы
контекста.
Рис.2 Контекстная диаграмма ИС «Домашняя Бухгалтерия»
ИС «Домашняя Бухгалтерия» получает данные о доходах и
расходах от внешней сущности «Домохозяин». Для передачи этих
данных сущности «Домохозяин» должен авторизоваться. В своей
работе сущность «Домашняя Бухгалтерия» использует информацию
о ценах на товары и тарифах и курсах валют, получаемую от
внешних сущностей «База тарифов и цен на товары» и «База курса
валют». Результаты своей работы ИС «Домашняя Бухгалтерия»
может отображать как внешней сущности «Домохозяин», так и
генерировать в виде отчетов формата MS Excel для внешней
сущности «MS Excel».
2.2. Функциональные требования
ИС должна обеспечивать следующие функциональные
возможности:
• учет расходов;
• учет доходов;
• учет денег, отданных и взятых в долг;
• погашение долгов частями;
• проценты по долгам;
• контроль возврата долгов;
• система напоминания по долгам;
• составление бюджета расходов и доходов;
• планирование расходов;
• планирование доходов;
• система счетов;
• возможность использовать до пяти валют включительно;
• получение курсов валют из интернет;
• обмен валют;
• импорт данных из файлов Microsoft Excel;
• поиск по базе данных;
• фильтры и быстрый поиск по базе данных;
• экспорт данных в Excel, XML, текстовый файл;
• перенос данных;
• резервное копирование;
• печать данных;
• построение отчетов и диаграмм;
• настройка пользовательского интерфейса.
2.3. Требования к данным
ИС должна хранить свои данные в специализированных XML-
файлах.
3. Системные ограничения
3.1. Требования к интерфейсу
ИС должна иметь стандартный интерфейс приложений,
разработанных для ОС MS Windows.
3.2. Требования к производительности
Особых требований к производительности ИС нет.
3.3. Требования к безопасности
С программой могут работать несколько человек, входя в
программу под своими именами. Для обеспечения
конфиденциальности каждое имя можно защитить паролем.
Добавление, изменение и удаление пользователей осуществляется в
администраторе пользователей.
3.4. Эксплуатационные требования
ИС должна функционировать на ОС Windows XP, OC Windows
Vista, ОС Windows 7, ОС Windows 8. Минимальные аппаратные требования
определяются минимальными аппаратными требованиями к выше-
перечисленным ОС.
3.5. Политические и юридические требования
Нет.
3.6. Другие ограничения
Нет.
4. Проектные вопросы
4.1. Открытые вопросы
Нет.
4.2. Предварительный план-график
1. Анализ и установление требований к ИС
2. Спецификация требований к ИС
3. Кодирование ИС
4. Тестовая эксплуатация ИС
Ввод в эксплуатацию
5. Приложения
Глоссарий
ИС – информационная система
ОС – операционная система
Деловые документы и формы
Нет.
Ссылки
Нет.
1.2.1 Варианты заданий
1. АСУ деятельностью отдела кадров предприятия
2. АСУ складского хранения
3. АСУ деятельностью библиотеки
4. Веб-магазин по продаже часов
5. Веб-магазин по продаже фотоаппаратов
6. АСУ деятельностью аптечной сети
7. Веб-сайт букмекерской конторы
8. ИС учета успеваемости студентов
9. Веб-магазин по продаже компьютерных комплектующих
10. Программный RSS-агрегатор
11. Веб RSS-агрегатор
12. ИС «Ежедневник»
13. АСУ деятельностью магазина видеопроката
14. АСУ деятельностью автосалона
15. Веб-магазин по продаже одежды
16. ИС «Почтовый коллектор»
17. АСУ деятельностью магазина бензозаправки
18. АСУ учетом пациентов в поликлинике
19. АСУ учетом коммунальных платежей
20. АСУ деятельностью службы такси
21. ИС сбора и обработки ошибок (багтрекер)
22. Веб-сайт кафедры
23. Веб-сайт факультета
24. ИС хранения и каталогизации фотографий
25. ИС «Каталог недвижимости».
|