close

Вход

Забыли?

вход по аккаунту

?

Brzsovskiy2

код для вставкиСкачать
1
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
Федеральное государственное автономное образовательное учреждение высшего
профессионального образования "Санкт-Петербургский государственный университет аэрокосмического приборостроения"
___________________________________________________________________________
РАЗРАБОТКА И АНАЛИЗ ТРЕБОВАНИЙ
Методические указания к лабораторному практикуму
Санкт-Петербург
2015 г.
2
Составитель: Бржезовский А. В.
Рецензент:
В методические указания включены описания основных понятий, работ, моделей и
способов извлечения, спецификации, проверки требований к программному обеспечению, в
том числе:
— понятие требования, роли участников проекта по отношению к работе с требованиями, источники требований и задачи, решаемые системными аналитиками;
— виды требований, шаблоны для их описания;
— извлечение требований с помощью диаграмм потоков данных;
— извлечение требований посредством моделирования бизнес-процессов;
— извлечение требований посредством написания сценариев пользователей.
Методические указания предназначены для студентов, обучающихся по направлению
23100062Ф и 23100062Ф Программная инженерия.
Методические указания подготовлены кафедрой компьютерной математики и программирования и рекомендованы к изданию редакционно-издательским советом СанктПетербургского государственного университета аэрокосмического приборостроения.
3
Лабораторная работа 1. Разработка модели требований
(RQM)
1. Разработка и анализ требований
Разработка и анализ требований является одним из важных начальных этапов создания
программного обеспечения (ПО). Вместе с тем, работа с требованиями не прекращается в
течение всего жизненного цикла (ЖЦ) ПО (рис. 1.1).
Планирование
проекта
Границы проекта
Конструирование
Связи трассирования
Инциденты
Пользовательские требования
Функциональные требования
Требоавания
Разработка и анализ
требований
Связи трассирования
Тестирование
Требования
Требования
Изменения
Трассирование и
контроль
Пользовательские требования
Функциональные требования
Документация
Документирование
Управление
изменениями
Запрос изменения
Рис. 1.1
Требования к системе являются источником для выполнения таких работ как:
— планирование проекта: выбор варианта ЖЦ, разработка смет на ресурсы, разработка
графика проекта;
— конструирование: проверка и тестирование блоков на удовлетворение требованиям,
трассирование для документирования — какие блоки были разработаны для удовлетворения
конкретных требований;
4
— тестирование: пользовательские и функциональные требования являются важнейшими источниками для разработки тестов, проверки соответствия реализованных функций
системы потребностям пользователей;
— документирование: требования к системе в значительной степени определяют структуру и содержание пользовательской документации;
— управление изменениями: требования уточняются и расширяются в ходе эксплуатации и подготовки следующих выпусков системы;
— трассирование и контроль проекта: требования и их связи с объектами в моделях
проектирования позволяют осуществлять контроль хода выполнения проекта и, при необходимости, инициировать изменения, корректирующие границы проекта.
В настоящее время работа с требованиями поддерживается в таких распространенных
программных
продуктах,
как
IBM
Rational
DOORS
(http://www-
01.ibm.com/support/knowledgecenter/SSYQBZ_9.6.0/com.ibm.doors.homepage.doc/helpindex_do
ors.html)1,
IBM
Rational
RequisitePro
(http://www-
01.ibm.com/support/knowledgecenter/SSSHCT/welcome), SAP Sybase PowerDesigner (PD)
(http://infocenter.sybase.com/help/topic/com.sybase.infocenter.help.pd.16.5/doc/html/title.html)
и
др.
2. Создание модели требований
Для создания модели требований в PD необходимо выполнить команды меню File \
New
Model…
\
Requirements
and
Planning
\
Requirements
\
OK
(http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc00121.1650/doc/html/rad1232637
368684.html).
Модель требований имеет древовидную структуру, которая отображается в окне Object
Browser, и в виде документа в окне Document View, в этом же окне находится панель инструментов
для
редактирования
модели
(http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc00121.1650/doc/html/rad1232637
424717.html). Редактирование модели можно осуществлять также с помощью команд контекстного меню, относящегося к узлам в окне Object Browser.
Структура модели требований зависит от специфики выполняемого проекта.
Один из вариантов структуры модели можно найти в примере, поставляемом вместе с
PD — файл CyberFridge.rqm, расположенный в папке C: \ Program Files \ Sybase \ PowerDe-
1
ПО и лицензия может быть получена по академической программе IBM
5
signer 16 \ Examples (зависит от места установки PD). Для открытия файла выполните команды главного меню File \ Open, после чего выберите файл.
Другие примеры модели можно встретить в литературе, например [1] (рис. 1.2).
1. Введение
1.1 Назначение
1.2 Соглашения, принятые документах
1.3 Предполагаемая аудитория и рекомендации по чтению
1.4 Границы проекта
1.5 Ссылки
2. Общее описание
2.1 Общий взгляд на продукт
2.2 Особенности продукта
2.3 Классы и характеристики пользователей
2.4 Операционная среда
2.5 Ограничения дизайна и реализации
2.6 Документация для пользователей
2.7 Предположения и зависимости
3. Функции системы
3.x Функция системы X
3.x. 1 Описание и приоритеты
З.х.2 Последовательности ≪воздействие - реакция≫
З.х.3 Функциональные требования
4. Требования к внешнему интерфейсу
4.1 Интерфейсы пользователя
4.2 Интерфейсы оборудования
4.3 Интерфейсы ПО
4.4 Интерфейсы передачи информации
5. Другие нефункциональные требования
5.1 Требования к производительности
5.2 Требования к охране труда
5.3 Требования к безопасности
5.4 Атрибуты качества
6. Остальные требования
Приложение А. Словарь терминов
Приложение Б. Модели анализа
Приложение Г. Список вопросов
Рис. 1.2
В модели требований можно создавать следующие виды объектов (таблица 1.1):
Таблица 1.1
Объекты модели требований
Наименование
Описание
Requirement
Требование — некоторое свойство системы, позволяющее пользователю решать свои задачи и достигать своих целей, которое мо-
6
жет быть назначено пользователю или группе для реализации
(http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc00121
.1650/doc/html/rad1232637501142.html).
User
Пользователь — участник проекта, задействованный в реализации
одного или нескольких требований
(http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc00121
.1650/doc/html/rad1232637516017.html).
Group
Группа — группа пользователей, задействованных в реализации
одного или нескольких требований
(http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc00121
.1650/doc/html/rad1232637516017.html).
Glossary term
Элемент словаря данных — понятие, используемое в модели требований, которое должно быть определено максимально точно,
насколько это возможно, для однозначного восприятия всеми
участниками проекта
(http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc00121
.1650/doc/html/rad1232637519502.html).
Business rule
Бизнес правило — правило, определяемое корпоративными политиками, государственными и др. регулирующими органами, законами, нормами, стандартами
(http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc00121
.1650/doc/html/rad1232637543456.html).
Создание объектов модели осуществляется вызовом команды New из контекстных меню узлов в дереве в окне Object Browser. Для удаления объекта модели иcпользуйте клавишу
Del.
Для отображения объектов модели используются три основных представления (табл.
1.2), которые могут быть созданы кнопками в панели инструментов.
Таблица 1.2
Представления модели требований
Пиктограмма
Представление
Иерархический список требований.
Матрица трассирования — отображает связи требований с объектами моделей проектирования
(http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc00121
.1650/doc/html/rad1232637471078.html).
7
Матрица распределения — отображает связи требований с реализующими их пользователями
(http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc00121
.1650/doc/html/rad1232637494517.html).
Для переключения между представлениями используются узлы дерева в окне Object
Browser или вкладки в окне Document View. Модель может содержать несколько представлений каждого вида и может быть разделена на пакеты (создаются командами New \ Package,
вызываемыми из контекстного меню в окне Object Browser).
С
каждым
из
требований
может
быть
связан
набор
свойств
(http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc00121.1650/doc/html/rad1232637
504283.html) (таблица 1.3):
Таблица 1.3.
Свойства требований
Наименование
Описание
Вкладка General
Parent
Родительский узел — узел дерева, которому подчинено требование.
Title ID
Номер требования в иерархии.
Title
Наименование требования.
Code
Автоматически генерируемый или задаваемый код (системное
имя) требования.
Description
Детальное описание требования.
Keywords
Ключевые слова, разделяемые запятыми, позволяющие группировать требования и настраивать фильтры.
Вкладка Detail
Comment
Текстовое поле для комментирования требований.
Stereotype
Стереотипы позволяют расширить семантику модели требований.
Type
Тип требования, выбираемый из предопределенного списка. Список видов требований может расширяться разработчиком модели.
Status
Состояние требования, выбираемое из предопределенного списка.
Список состояний может расширяться разработчиком модели.
8
Priority
Приоритет реализации требования.
Selected
Показывает, что требование выбрано для реализации в текущем
проекте.
Risk
Задает уровень риска, связанного с реализацией требования.
Verification
Вид тестирования требования, выбираемый из предопределенного
списка. Список видов тестирования может расширяться разработчиком модели.
Workload 1-4
Распределяет загрузку по четырем пользователям или группам.
Свойства требований задаются в диалоговом окне, вызываемом кнопкой панели инструментов или командой Properties из контекстного меню в окне Object Browser или с помощью двойного щелчка мышью на требовании.
3. Пример модели требований
В соответствии с одним из подходов различают:
(i) Бизнес-требования — высокоуровневые цели, отражающие эффект от использования
системы: финансовый, социальный и др.
(ii) Требования пользователя — задачи, позволяющие пользователю достигать некоторого результата в ходе своей повседневной деятельности, например «оформить заказ».
(iii) Функциональные требования — набор функций, обеспечивающих решение задач
пользователя, например: «зарегистрировать заказчика», «создать заказ», «создать позицию
заказа», «закрыть заказ».
(iv) Бизнес – правила — корпоративные и государственные стандарты, нормы, правила,
которые должна учитывать система, например: «ставка НДС – 18%», «с договоров НИОКР
НДС не взимается».
(v) Атрибуты качества — свойства системы не связанные с ее функциональными возможностями, отражающие те или иные аспекты качества ее функционирования, например:
время восстановления после сбоя, наличие всплывающих подсказок, синтаксическая проверка вводимой пользователем информации и др.
Сформулируем примеры требований для предметной области, связанной с работой информационной
системы
контакт-центра
(Contact
(http://docs.genesys.com/Documentation/IW/latest/User/Welcome)
(http://docs.genesys.com/Documentation/FR/latest/Dep/Welcome).
Center
—
CC)
9
Пример бизнес требований приведен на рис. 1.3, классификации пользователей — на
рис. 1.4, требований пользователей и функциональных требований — на рис. 1.5, бизнесправил и атрибутов качества — на рис. 1.6.
10
Рис. 1.3
11
Рис. 1.4
12
Рис. 1.5
13
Рис. 1.6
14
4. Выполнение лабораторной работы
По аналогии с примерами, приведенным в п. 3 и лекционном курсе, разработать модель
требований для системы, определенной вариантом задания.
5. Содержание отчета
Текстовый отчет не разрабатывается, модель защищается в электронном виде.
6. Варианты заданий
Варианты заданий приведены в ПРИЛОЖЕНИИ.
15
Лабораторная работа 2. Разработка диаграмм потоков данных, уточнение RQM
1. Диаграммы потоков данных
Диаграммы потоков данных (ДПД) или Data Flow Diagram (DFD) первоначально были
предложены в методологии системного структурного анализа [10] [11], где рассматривались
как средство, используемое при проектировании программных систем. В настоящее время
эта техника утратила актуальность в связи с повсеместным использованием при проектировании программных систем нотаций UML. Вместе с тем, как отмечается в [1] [12], данный
подход может быть полезен при обсуждении с пользователями границ и задач автоматизации, выявления требований к проектируемой системе.
2. Создание диаграмм потоков данных
Для создания модели DFD в PD необходимо выполнить команды меню File \ New Model…
\
Information
\
Data
Flow
Diagram
\
OK
(http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc00121.1650/doc/html/rad1232637
368684.html).
DFD
строится
из
следующих
основных
элементов
(рис.
2.1)
(http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc38088.1650/doc/html/rad1232026
266129.html):
(i) Внешняя сущность — представляет на диаграмме внешние источники и приемники
данных, в роли внешних сущностей могут выступать люди, организации, программные системы, находящиеся вне границ автоматизации (за рамками проекта).
(ii) Процесс — подсистема, задача, функция, выполняемая рассматриваемой системой.
(iii) Накопитель данных — данные сохраненные в системе для выполнения последующей обработки, в роли накопителей данных могут выступать базы данных, файлы, картотеки, хранилища документов и др.
(iv) Поток данных — данные, находящиеся в движении, передаваемые между:
— внешней сущностью и процессом:
— двумя процессами;
— процессом и накопителем данных.
16
Рис. 2.1
Диаграммы потоков данных являются иерархическими, на верхнем уровне создается
так называемая контекстная диаграмма, на которой вся система показывается как один процесс (рис. 2.2).
17
Основным источником и приемником данных для рассматриваемой системы является
клиент контакт-центра (Клиент). Система реализует так же обмен данными об агентах с
ERP (Enterprise Resource Planning) и данными об обращениях клиентов с CRM (Customer Relation Management) системами. Состав передаваемой информации на диаграмме представлен
потоками данных. По умолчанию имя потока данных на диаграмме не отображается, изменение параметров отображения элементов диаграмм осуществляется с помощью меню Tools
/
Display
Preferences…
(http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc38093.1650/doc/html/rad1232024
629503.html).
Для создания диаграммы следующего уровня необходимо выполнить команду Decompose Process и Open Diagram из контекстного меню процесса. На диаграмме (рис. 2.3) в АИС
CC выделены подсистемы, отвечающие за обслуживание обращений клиентов (Обслуживание обращений), взаимодействие с ERP и администрирование агентов (Администрирование
агентов), взаимодействие с CRM и (Администрирование клиентов) и организацию работы
контакт-центра (Планирование работы).
При выполнении декомпозиции те элементы, с которыми был связан процесс отображаются на диаграмме следующего уровня, после выявления подпроцессов можно уточнить,
какие процессы должны обслуживать потоки данных, показанные уровнем выше, для этого
необходимо:
— скопировать поток данных на диаграмме или в дереве объектов (Edit / Copy в контекстном меню потока);
— вставить поток данных на новой диаграмме или в дереве объектов (Edit / Paste в
контекстном меню потока);
— изменить источник и приемник в свойствах потока (Properties в контекстном меню
потока);
— удалить лишние символы (Edit / Delete в контекстном меню элемента).
При необходимости можно создать/удалить точку изгиба потока щелчком левой кнопки мышки при нажатой клавише Ctrl.
18
Рис. 2.2
19
Рис. 2.3
20
3. Выполнение лабораторной работы
По аналогии с примерами, приведенными в п. 2 и лекционном курсе, разработать DFD
для системы, определенной вариантом задания:
— контекстную диаграмму;
— декомпозицию контекстной диаграммы (1-й уровень);
— декомпозицию для каждого процесса диаграммы 1-го уровня.
По результатам разработки DFD уточнить RQM вновь выявленными требованиями.
4. Содержание отчета
Текстовый отчет не разрабатывается, модель защищается в электронном виде.
5. Варианты заданий
Варианты заданий приведены в ПРИЛОЖЕНИИ.
21
Лабораторная работа 3. Разработка диаграмм BPMN, уточнение RQM
1. Моделирование бизнес-процессов
Часто перед созданием автоматизированных информационных систем в организациях
проводится реинжиниринг бизнес-процессов:
(i) строится описание бизнес-процесса «как есть»;
(ii) разрабатывается бизнес-процесс «как надо»;
после этого под улучшенный бизнес-процесс разрабатывается или приобретается и
конфигурируется автоматизированная система класса ERP (Enterprise Resource Planning).
Для спецификации бизнес-процессов были предложены формальные модели, поддерживаемые в таких системах проектирования как:
(i)
SAP
Sybase
PowerDesigner
(http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc38088.1610/doc/html/title.html);
(ii) ARIS (http://www.softwareag.com/ru/product/aris_alfabet/bpa/overview/default.asp);
и др., в настоящее время все большее распространение получает нотация BPMN 2.0
(http://www.omg.org/spec/BPMN/2.0/), принятая в качестве стандарта OMG (www.omg.org).
Данная нотация поддерживается также в последних версиях SAP Sybase PowerDesigner
(http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc38088.1650/doc/html/rad1232026
070106.html).
2. Нотация BPMN
Краткая сводка BPMN приведена в BPMN2_0_Poster_RU.pdf.
Использование нотации рассмотрено в уроках Урок 1.pdf, Урок 2.pdf, Урок 3.pdf, Урок
4.pdf, Урок 5.pdf, Урок 6.pdf.
Полная спецификация приведена в 11-01-03.pdf, ее перевод на сайте Elma
(http://www.elma-bpm.ru/bpmn2), неформальное введение в 10-06-02.pdf.
Примеры моделей BPMN поставляются вместе с PD в файлах BPMN20.bpm, BPMN202.bpm, расположенных в папке C: \ Program Files \ Sybase \ PowerDesigner 16 \ Examples (зависит от места установки PD). Для открытия файла выполните команды главного меню File \
Open, после чего выберите файл.
22
3. Создание модели BPMN
Для создания модели BPMN в PD необходимо выполнить команды меню File \ New
Model…
\
Model
types
\
Business
Process
Diagram
\
BPMN
2.0
\
OK
(http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc38088.1650/doc/html/rad1232025
406127.html).
Элементы и инструменты для разработки модели BPMN приведены в материалах по
PD
(http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc38088.1650/doc/html/rad1232026
070106.html).
4. Выполнение лабораторной работы
По аналогии с примерами, приведенными в материалах п. 2 и лекционном курсе, разработать BPMN для системы, определенной вариантом задания:
— бизнес процесс верхнего уровня, содержащий составные процессы;
— бизнес-процессы, описывающие реализацию составных процессов верхнего уровня.
По результатам разработки модели BPMN уточнить RQM вновь выявленными требованиями.
5. Содержание отчета
Текстовый отчет не разрабатывается, модель защищается в электронном виде.
6. Варианты заданий
Варианты заданий приведены в ПРИЛОЖЕНИИ.
23
Лабораторная работа 4. Разработка сценариев пользователей,
уточнение RQM
1. Сценарии пользователей
Сценарии пользователей (варианты использования), наряду с DFD и BPMN могут рассматриваться как инструмент извлечения требований. Разработке сценариев пользователей
полностью посвящены книги [4] [5]. Как в них отмечается можно ввести понятие уровня варианта использования:
(i) Уровень ++ — вариант использования очень высокого уровня обобщения, отражающий цели высокого уровня, шаги такого сценария соответствуют не задачам пользователя,
а целям, стоящим перед бизнесом/организацией/системой;
(ii) Уровень + — обобщенные варианты использования, отражающие цели системы,
шаги такого сценария состоят из задач (целей) пользователей;
(iii) Уровень ~ — уровень, соответствующий задачам/целям пользователя;
(iv) Уровень – — варианты использования, сопоставленные подфункциям, которые являются шагами на «Уровне ~»;
(v) Уровень = — варианты использования для подфункций нижнего уровня, являющихся шагами на «Уровне –».
Уровень (iii) в терминах BPM является «элементарным» бизнес процессом, соответствующим некоторому мотивированному действию пользователя, совершаемому без значительных временных перерывов.
2. Шаблон описания сценария пользователя
Как отмечается в [4] [5] степень детализации описания сценария пользователя может в
существенной степени варьироваться от краткой характеристике ситуации в стиле использованном в модели CyberFridge.rqm, до детальных [1] [2] и весьма подробных [4] [5], и определяется стилем/дисциплиной разработки, установленной для проекта/команды разработчиков.
Как отмечается в [1] [2] [4] [5] сценарий пользователя может включать:
(i) уникальный идентификатор;
(ii) имя, образованное из словосочетания <действие> + <объект>;
(iii) краткое текстовое описание/характеристику сценария;
(iv) список <действующие лица> — <цели>;
24
(v) список предварительных условий, отражающих состояние системы до начала варианта использования, делающих возможным «запуск» его выполнения;
(vi) список выходных (постусловий), отражающих состояние системы после успешного
выполнения варианта использования;
(vii) триггер (событие, запускающее выполнение сценария);
(viii) пронумерованным списком действий (шагов), переводящим систему от предварительных условий к выходным;
(ix) пронумерованными списками действий (шагов), соответствующих альтернативным
сценариям, запускаемым в случае исключительных/ошибочных ситуаций;
(x) автора сценария;
(xi) автора последнего изменения;
(xii) дату создания;
(xiii) дату последнего изменения;
(xiv) версию;
(xv) статус (проанализирован, утвержден …);
(xvi) приоритет;
(xvii) частоту использования;
(xviii) бизнес-правила.
В [4] [5] приводится пример, предложенный разработчиками Rational:
Сценарий: UC1.
Наименование: Записаться на курсы.
Краткое описание: В начале семестра студент (действующее лицо) записывается на
курсы, которые он будет изучать. ИС университета (действующее лицо) предоставляет
студенту перечень доступных курсов. Студент может изменить перечень курсов до истечения 1-ой недели семестра.
Триггер: Студент выбирает функцию «Работа с графиком».
Предусловия: Студент вошел в систему записи на курсы. Список курсов сформирован и
открыт для записи.
Постусловия: График студента зафиксирован. Студент попал в списки слушателей соответствующих курсов.
Основной поток событий ОП:
1) Студент выбирает функцию «Работа с графиком».
2) Система выводит пустую форму графика.
25
3) Система выводит список предлагаемых курсов.
4) Студент выбирает 4 основных и 2 альтернативных курса, после чего фиксирует
график.
5) Система сохраняет график.
Альтернативный поток АП1 — «Модифицировать график»:
1) Студент выбирает функцию «Модифицировать график».
2) Система отображает график на текущий семестр.
3) Система отображает список доступных курсов не включенных в график.
4) Студент добавляет/удаляет курсы, после чего фиксирует график.
5) Система сохраняет график.
Альтернативный поток АП2 — «Удалить график»:
1) Студент выбирает функцию «Удалить график».
2) Система отображает график на текущий семестр и запрашивает подтверждение
операции удаления.
3) Студент подтверждает удаление графика.
4) Система удаляет график.
Расширение 1 ОП и АП1:
*a1 В любой момент времени студент может сохранить текущее состояние графика.
3. Выполнение лабораторной работы
По аналогии с примерами, приведенными в материалах п. 2 и лекционном курсе, разработать 5..7 сценариев пользователей различного уровня.
По результатам разработки сценариев уточнить RQM вновь выявленными требованиями.
4. Содержание отчета
Текстовый отчет с описанием сценариев предоставляется в электронном виде в формате офисного приложения.
5. Варианты заданий
Варианты заданий приведены в ПРИЛОЖЕНИИ.
1
* показывает, что данное расширение может возникнуть на любом шаге ОП и АП1.
26
Библиографический список
1. Вигерс К., Битти Д. Разработка требований к программному обеспечению/Пер. с
англ. – М.: Издательство "БХВ-Петербург", 2014. – 736 с.: ил.
2. Вигерс К. Разработка требований к программному обеспечению/Пер. с англ. – М.:
Издательско-торговый дом "Русская Редакция", 2004. – 576 с.: ил.
3. Леффингуэлл Д., Уидриг Д. Принципы работы с требованиями к программному
обеспечению/Пер. с англ. – Киев: Издательский дом "Вильямс", 2002. – 448 с.: ил.
4. Коберн А. Современные методы описания функциональных требований к системам/Пер. с англ. – М.: Издательство "Лори", 2012. – 264 с.: ил.
5. Коберн А. Современные методы описания функциональных требований к системам/Пер. с англ. – М.: Издательство "Лори", 2002. – 288 с.: ил.
6. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения/Пер. с англ. – СПб.: Издательский дом "Питер", 2002. – 496 с.: ил.
7. Халл Э., Джексон К., Дик Дж. Разработка и управление требованиями/Пер. с англ. –
Электр. ресурс, 2005. – 229 с.: ил.
8. Йордон Э. Путь камикадзе. Как разработчику программного обеспечения выжить в
безнадежном проекте/Пер. с англ. – М.: Издательство "Лори", 2012. – 256 с.: ил.
9. Брукс Ф. Мифический человеко-месяц, или Как создаются программные системы/Пер. с англ. – М.: Издательство "Символ-Плюс", 2010. – 304 с.: ил.
10. Гейн К., Сарсон Т. Системный структурный анализ: средства и методы/Пер. с англ.
– М.: "Эйтекс", 1992.
11. Калянов Г.Н. Консалтинг при автоматизации предприятий: подходы, методы, средства [http://www.interface.ru/fset.asp?Url=/case/defs91.htm]
12. Beatty J. Chen A. Visual Models for Software Requirements – Washington: Microsoft
Press, 2012.
27
Содержание
Лабораторная работа 1. Разработка модели требований (RQM) ________________ 3
1.
Разработка и анализ требований _____________________________________________ 3
2.
Создание модели требований ________________________________________________ 4
3.
Пример модели требований _________________________________________________ 8
4.
Выполнение лабораторной работы __________________________________________ 14
5.
Содержание отчета ________________________________________________________ 14
6.
Варианты заданий ________________________________________________________ 14
Лабораторная работа 2. Разработка диаграмм потоков данных, уточнение RQM 15
1.
Диаграммы потоков данных _______________________________________________ 15
2.
Создание диаграмм потоков данных ________________________________________ 15
3.
Выполнение лабораторной работы __________________________________________ 20
4.
Содержание отчета ________________________________________________________ 20
5.
Варианты заданий ________________________________________________________ 20
Лабораторная работа 3. Разработка диаграмм BPMN, уточнение RQM ________ 21
1.
Моделирование бизнес-процессов ___________________________________________ 21
2.
Нотация BPMN ___________________________________________________________ 21
3.
Создание модели BPMN____________________________________________________ 22
4.
Выполнение лабораторной работы __________________________________________ 22
5.
Содержание отчета ________________________________________________________ 22
6.
Варианты заданий ________________________________________________________ 22
Лабораторная работа 4. Разработка сценариев пользователей, уточнение RQM 23
1.
Сценарии пользователей ___________________________________________________ 23
2.
Шаблон описания сценария пользователя ___________________________________ 23
3.
Выполнение лабораторной работы __________________________________________ 25
4.
Содержание отчета ________________________________________________________ 25
5.
Варианты заданий ________________________________________________________ 25
Библиографический список ________________________________________________ 26
Варианты заданий ____________________________________________________________ 28
28
ПРИЛОЖЕНИЕ
Варианты заданий
1. Автоматизированная система железной дороги.
2. Автоматизированная система авиакомпании.
3. Автоматизированная система аэропорта.
4. Автоматизированная система морского порта.
5. Автоматизированная система автобусного вокзала.
6. Автоматизированная система школы.
7. Автоматизированная система библиотеки.
8. Автоматизированная система университета.
9. Автоматизированная система службы занятости.
10. Автоматизированная система службы социальной защиты.
11. Автоматизированная система поликлиники.
12. Автоматизированная система обязательного медицинского страхования.
13. Автоматизированная система пенсионного фонда.
14. Автоматизированная система выставочного комплекса.
15. Автоматизированная система для организации НИОКР.
16. Автоматизированная система издательства.
17. Автоматизированная система редакции газеты.
18. Автоматизированная система типографии.
19. Автоматизированная система гостиницы.
20. Автоматизированная система киноцентра.
21. Автоматизированная система фирмы по прокату автомобилей.
22. Автоматизированная система букмекерской фирмы.
23. Автоматизированная система фондовой биржи.
24. Автоматизированная система банка.
25. Автоматизированная система лизинговой компании.
26. Автоматизированная система туристического агентства.
27. Автоматизированная система фильмотеки.
28. Автоматизированная система агентства недвижимости.
29. Автоматизированная система страховой организации.
30. Автоматизированная система автошколы.
31. Автоматизированная система оператора связи.
29
32. Автоматизированная система автосервиса.
33. Автоматизированная система для оказания госуслуг.
34. Автоматизированная система фирмы по сборке и продаже компьютеров и комплектующих.
35. Автоматизированная система транспортной фирмы.
36. Автоматизированная система супермаркета.
37. Автоматизированная система книжного магазина.
38. Автоматизированная система ломбарда.
39. Автоматизированная система ГИБДД.
40. Автоматизированная система спортивного клуба.
41. Автоматизированная система интернет-провайдера.
42. Автоматизированная система интернет-магазина.
43. Автоматизированная система интернет-аукциона.
44. Автоматизированная система почтовой службы.
45. Автоматизированная система предприятия ЖКХ.
46. Автоматизированная система рекламного агентства.
47. Автоматизированная система курьерской фирмы.
48. Автоматизированная система ресторанного комплекса.
49. Автоматизированная система службы такси.
50. Автоматизированная система службы технической поддержки.
51. Автоматизированная система <свой вариант> (необходимо сформулировать тему).
Документ
Категория
Без категории
Просмотров
4
Размер файла
1 330 Кб
Теги
brzsovskiy2
1/--страниц
Пожаловаться на содержимое документа