Проектирование информационной системы «Менеджер музыкальной группы»

Размещено на http://www.allbest.ru/

Введение

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

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

В компании ОАО "Просто Музыка" действует информационная система, в которую входят следующие модули: "Cведений о группах", "Сведения о каждой песне из репертуара группы", "данные о последней гастрольной поездке каждой группы" поэтому для данной организации возникает необходимость разработки автоматизированной системы по контролю всех сведений от ОАО "Просто Музыка"

Описание предметной области

Пусть требуется создать программную систему, предназначенную для менеджера музыкальных групп. Такая система должна обеспечивать хранение сведений о группах, включающих название группы, год образования и страну, состав исполнителей, положение в последнем хит-параде; репертуар группы. Сведения о каждой песне из репертуара группы - это ее название, композитор, автор текста. Необходимо также хранить данные о последней гастрольной поездке каждой группы: название гастрольной программы, названия населенных пунктов, дата начала и окончания выступлений, средняя цена билета (зависит от места выступления и положения группы в хит-параде). Возможно появление новой группы и изменение состава исполнителей. Каждая песня может быть в репертуаре только одной группы.

Менеджеру могут потребоваться следующие сведения:

- Автор текста, композитор и дата создания песни с данным названием? В репертуар какой группы она входит?

- Репертуар наиболее популярной группы?

- Цена билета на последний концерт указанной группы?

- Состав исполнителей группы с заданным названием, их возраст и амплуа?

- Место и продолжительность гастролей группы с заданным названием?

- Какие группы в текущем году отмечают юбилей

- Самый молодой вокалист? Какую группу он представляет?

- В каких группах средний возраст исполнителей не превышает 20 лет?

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

Статическое описание компании

Ход работы

Шаблон разработки миссии:

Зачем: Для хранений, данных о группах

Что: Ведется запись о всех группах (Ф.И.О , жанр исполнения , количество человек в группе)

Где: В офисе менеджера.

Кто: Менеджер.

Как: Осуществляет хранение сведений о группах, включающих название группы, год образования и страну, состав исполнителей, положение в последнем хит-параде; репертуар группы.

Когда: В рабочее время.

Кому: Потребителям.

Миссия менеджера музыкальной группы: Пусть требуется создать программную систему, предназначенную для менеджера музыкальных групп. Такая система должна обеспечивать хранение сведений о группах, включающих название группы, год образования и страну, состав исполнителей, положение в последнем хит-параде; репертуар группы. Сведения о каждой песне из репертуара группы - это ее название, композитор, автор текста. Необходимо также хранить данные о последней гастрольной поездке каждой группы: название гастрольной программы, названия населенных пунктов, дата начала и окончания выступлений, средняя цена билета (зависит от места выступления и положения группы в хит-параде). Возможно появление новой группы и изменение состава исполнителей. Каждая песня может быть в репертуаре только одной группы

Шаблон формирования функционала компании

Менеджер: следит за коммерческой стороной деятельности своего клиента, помогает ему.

Композитор: автор музыкальных произведений; человек, пишущий музыку и имеющий соответствующую квалификацию.

Группа: некое количество человек исполняющие песни.

Динамическое описание компании.

Шаблон формирования зон ответственности за функционал компании:

Менеджер: следит за коммерческой стороной деятельности своего клиента, помогает ему принимать решения и даёт советы по вопросам, которые могут повлиять на ход карьеры.

Композитор: автор музыкальных произведений; человек, пишущий музыку и имеющий соответствующую квалификацию.

Группа: некое количество человек исполняющие песни.

Ресурсы:

Данные о группах в БД.

Сведения о песне.

Группа.

Ответственные лица:

Менеджер.

Композитор.

Группа.

Результаты:

Оформление групп в БД.

Создание БД.

Функциональная область	Написание слов и музыки	Исполнение песен	Затраты	Прибыль
Менеджер			+	+
Композитор	+
Группа		+

План

1.Изучение документов всех исполнителей.

2.Провести анкетирование всего состава группы.

3.Изучить доход/расход группы за месяц.

Список документов

1.Прайс-лист

2. Список исполнителей

3. Список групп

5. Копия документов, подтверждающая личность

Список вопросов

Цели проведения предпроектного обследования.

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

Собираемая и регистрируемая информация.

Данные о исполнителях, данные о песнях и гастрольных поездок.

Организация отчетов о финансах.

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

Показатели качества	Коэффициент весомости, Вj	Проект
		Xj	ВjxXj
1. Удобство работы (пользовательский ин-терфейс)	0,1	3	0,3
2.Новизна (соответствие современным требованиям)	0,06	4	0,24
3.Соответствие профилю деятельности заказчика	0,15	5	0,75
4.Операционная система (многозадачность, графика)	0,05	5	0,25
5. Надежность (защита данных)	0,13	5	0,65
6.Скорость доступа к данным	0,09	5	0,45
7.Гибкость	0,05	4	0,2
8.Функции обработки информации	0,13	5	0,65
9.Соотношение стоимость/возможности	0,09	5	0,45
10. Время обучения персонала	0,15	3	0,45
Обобщенный показатель качества JЭТУ	3,45

Таблица 1. Расчет показателя качества балльно-индексным методом

Виды работ	Оптимистическая оценка, tmin	Реалистическая оценка, tнв	Пессимистическая оценка, tmax	Ожидаемая продолжительность работы, tож
1.1	9	14	21	14
1.2	3	5	9	5
1.3	10	15	20	15
2.1	2	3	4	3
2.2	15	17	20	17
3.1	10	15	20	15
3.2	19	21	22	21
3.3	5	9	14	9
3.4	7	11	15	11
4.1	2	4	6	4
4.2	10	5	20	8
4.3	8	16	24	16

Содержание работы	Исполнители	Длительность, дни	График работы
1 Постановка задачи	Программист	1	10.03.14-11.03.14
2 Сбор исходных данных	Программист	2	12.03.14-13.03.14
3 Анализ существующих методов решения задачи и программных средств	Программист	1	14. 03.14-15.03.14
4 Обоснование принципиальной необходимости разработки	Программист	1	16.14-17.03.14
5 Определение и анализ требований к программе	Программист	3	18.03.14-20.03.14
6 Определение структуры входных и выходных данных	Программист	3	21.03.14-23.03.14
7 Выбор технических средств и программных средств реализации	Программист	1	24.03.14-24.03.14
8 Согласование и утверждение технического задания	Программист	1	25.03.14-26.03.14
9 Проектирование программной архитектуры	Программист	2	27.03.14-29.03.14
10 Техническое проектирование компонентов программы	Программист	2	30.03.14-01.04.14
11 Программирование модулей в выбранной среде программирования	Программист	6	01.04.14-07.04.14
12 Тестирование программных модулей	Программист	6	07.04.14-13.04.14
13 Сборка и испытание программы	Программист	2	13.04.14-14.04.14
14 Анализ результатов испытаний	Программист	2	15.04.14-16.04.14
15 Проведение расчетов показателей безопасности жизнедеятельности	Программист	1	16.04.14-17.04.14
16 Проведение экономических расчетов	Программист	1	17.04.14

Таблица 3. Зарплата

Материалы	Единица измерения	Требуемое количество	Цена за единицу Руб.	Сумма Руб.
Тетрадь общая	шт.	1	10	10
Компакт-диск CD-RW	шт.	2	35	70
Тонер для лазерного принтера	шт.	1	1000	1000
Бумага офисная	пачка	1	120	120
Итого	1200

1. Общие сведения:

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

2. Назначение и цели создания (развития) системы:

Для хранение всех данных и выдача отчета.

3. Требования к системе:

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

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

Техническое задание

1. Назначение и цели создания (развития) системы.

Назначение: Система, предназначена для повышения оперативности качества хранения данных. Основным назначением является автоматизация деятельности обработки данных и их хранения.

Цели создания: Сократить время и повысить качество хранение данных путем автоматизации системы.

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

* Повысить качество хранения данных с помощью автоматизации системы.

2. Требования к системе: Система должна быть удобной, т.е. все требования менеджера музыкальной группы должны быть обговорены и прописаны в договоре. Для обеспечения высокой надежности функционирования, как системы в целом, так и её отдельных компонентов должно обеспечиваться выполнение требований по диагностированию ее состояния.

Требования к структуре и функционированию системы.

В системе нужно выделить функциональные подсистемы:

* подсистема сбора, обработки и хранения личных данных клиента.

* подсистема хранения данных о клиентах

* подсистема формирования отчетов и отправки их в бухгалтерию.

* подсистема по зачислению оплаты.

Система должна иметь функцию обновления и модернизации.

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

Система должна поддерживать следующие режимы функционирования:

- Основной режим, в котором подсистемы выполняют все свои основные функции.

- Профилактический режим, в котором одна или все подсистемы не выполняют своих функций.

В основном режиме функционирования Система должна обеспечивать:

- Работу пользователей в режиме - 10 часов в день, 6 дней в неделю (10х6);

- Выполнение своих функций - сбор, обработка и загрузка данных; хранение данных, предоставление отчетности.

В профилактическом режиме Система должна обеспечивать возможность проведения следующих работ:

- техническое обслуживание;

- модернизацию аппаратно-программного комплекса;

- устранение аварийных ситуаций.

Общее время проведения профилактических работ не должно превышать 5% от общего времени работы системы в основном режиме (12 часов в месяц).

Требования к численности и квалификации персонала системы и режиму его работы.

К квалификации персонала, эксплуатирующего систему почтового отделения, предъявляются следующие требования.

- Конечный пользователь - знание соответствующей предметной области;

- Администратор по обучению персонала для новой системы - знание и навыки по работе с данной системой.

- Администратор за слежением работы всех подсистем - глубокие знания по данной системе, ее подсистемам, фиксирование работ подсистем.

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

- Руководитель эксплуатации системы - 1 человек.

- Администратор по обучению персонала для новой системы - 2 человека.

- Администратор за слежением работы всех подсистем - 1 человек

Требования к режимам работы персонала:

Персонал, работающий с Системой и выполняющий функции её сопровождения и обслуживания, должен работать в следующих режимах:

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

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

- Администратор за слежением работы всех подсистем - в соответствии с основным рабочим графиком подразделений почтового отделения.

Требования к надежности:

Состав показателей надежности для системы в целом.

Надежность должна обеспечиваться за счет:

- применения технических средств, системного и базового программного обеспечения, соответствующих классу решаемых задач;

- своевременного выполнения процессов администрирования Системы;

- предварительного обучения пользователей и обслуживающего персонала.

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

Под аварийной ситуацией понимается аварийное завершение процесса, выполняемого той или иной подсистемой, а также "зависание" этого процесса.

При работе системы возможны следующие аварийные ситуации, которые влияют на надежность работы системы:

- сбой в электроснабжении рабочей станции пользователей системы;

- сбой в электроснабжении обеспечения локальной сети (поломка сети);

- ошибки Системы, не выявленные при отладке и испытании системы;

Требования к надежности технических средств и программного обеспечения:

К надежности оборудования предъявляются следующие требования:

- в качестве аппаратных платформ должны использоваться средства с повышенной надежностью;

- применение технических средств соответствующих классу решаемых задач;

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

К надежности электроснабжения предъявляются следующие требования:

- должно быть обеспечено бесперебойное питание активного сетевого оборудования.

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

- предварительного обучения пользователей и обслуживающего персонала;

- своевременного выполнения процессов администрирования;

- соблюдения правил эксплуатации и технического обслуживания программно-аппаратных средств;

- своевременное выполнение процедур резервного копирования данных.

Надежность программного обеспечения подсистем должна обеспечиваться за счет:

- надежности общесистемного ПО и ПО, разрабатываемого Разработчиком;

- проведением комплекса мероприятий отладки, поиска и исключения ошибок.

- ведением журналов системных сообщений и ошибок по подсистемам для последующего анализа и изменения конфигурации.

Требования к приспособляемости системы к изменениям.

Обеспечение приспособляемости системы должно выполняться за счет:

- своевременности администрирования;

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

Требования к эргономике и технической эстетике.

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

В части внешнего оформления:

- интерфейсы подсистем должен быть типизированы;

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

- должен использоваться шрифт: Times New Roman

- размер шрифта должен быть: 12

- цветовая палитра должна быть: черная

- в шапке отчетов должен использоваться данные о клиентах.

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

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

Требования к информационной безопасности.

Обеспечение информационной безопасности Системы должно удовлетворять следующим требованиям:

- Защита Системы должна обеспечиваться комплексом программно-технических средств и поддерживающих их организационных мер.

- Защита Системы должна обеспечиваться на всех технологических этапах обработки информации и во всех режимах функционирования, в том числе при проведении ремонтных и регламентных работ.

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

Требования к антивирусной защите.

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

- централизованное управление сканированием, удалением вирусов и протоколированием вирусной активности на рабочих местах пользователей;

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

- ведение журналов вирусной активности;

- администрирование всех антивирусных продуктов.

Требования по сохранности информации при авариях.

В Системе должно быть обеспечено резервное копирование данных.

Требования по стандартизации и унификации.

Для работы с БД должнен использоваться язык запросов SQL в рамках стандарта ANSI SQL-92.

В системе должны использоваться (при необходимости) общероссийские классификаторы и единые классификаторы и словари для различных видов алфавитно-цифровой и текстовой информации.

Требования безопасности.

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

Аппаратное обеспечение системы должно соответствовать требованиям пожарной безопасности в производственных помещениях по ГОСТ 12.1.004-91. "ССБТ. Пожарная безопасность. Общие требования".

Должно быть обеспечено соблюдение общих требований безопасности в соответствии с ГОСТ 12.2.003-91. "ССБТ. Оборудование производственное. Общие требования безопасности" при обслуживании системы в процессе эксплуатации.

Аппаратная часть системы должна быть заземлена в соответствии с требованиями ГОСТ Р 50571.22-2000. "Электроустановки зданий. Часть 7. Требования к специальным электроустановкам. Раздел 707. Заземление оборудования обработки информации".

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

Для реализации подсистемы хранения данных должна использоваться промышленная СУБД < Access 2009>.

Требования к защите данных от разрушений при авариях и сбоях в электропитании системы.

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

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

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

Требования к контролю, хранению, обновлению и восстановлению данных.

К хранению данных предъявляются следующие требования:

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

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

К обновлению и восстановлению данных предъявляются следующие требования:

Требования к организационному обеспечению.

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

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

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

К защите от ошибочных действий персонала предъявляются следующие требования:

- для всех пользователей должна быть запрещена возможность удаления преднастроенных объектов и отчетности;

- для снижения ошибочных действий пользователей должно быть разработано полное и доступное руководство пользователя.

Эскизный проект

1. Общие положения

1.1. Наименование системы

1.1.1. Полное наименование системы

Полное наименование: Автоматизированная информационная система "Менеджер музыкальной ".

1.1.2. Краткое наименование системы

Краткое наименование: АИС "Просто Музыка"

1.2. Основания для проведения работ

Работа выполняется на основании приказ № 85С ОТ 28.02.2014 Г

1.3. Наименование организаций - Заказчика и Разработчика

1.3.1. Заказчик

Заказчик: КГБОУ СПО "Канский технологический колледж"

Адрес фактический: Красноярский край, г.Канск , ул.Кайтымская ,57

Телефон: +7 (39161) 20651

1.3.2. Разработчик

Разработчик: Шуняев М.Ю.

Адрес фактический: г. Канск

Телефон: 8-923-287-55-95

1.4 Цели, назначение и область использования системы

Система, предназначена для повышения оперативности качества хранения данных. Основным назначением является автоматизация деятельности обработки данных и их хранения.

АИС "Просто Музыка" создается с целью:

Сократить время обработки данных о студенте за счет автоматизации системы;

Повысить качество хранения данных с помощью автоматизации системы.

1.5. Нормативные ссылки

При эскизном проектировании использовались следующие нормативно-технические документы: 1. Техническое задание на создание автоматизированной информационной системы "Просто Музыка" 2. ГОСТ 34 .201 3. ГОСТ 19.101.

4. ГОСТ 34.201-89

1.6 Очередность создания системы

Очередность создания системы:

- Производится разработка модели АИС "Просто Музыка"

- Проектируются процессы сбора данных в область хранения данных.

- Проектируются процессы загрузки данных в область хранения данных.

- Проектируются типовые отчеты.

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

- Производится настройка активного сетевого оборудования.

2. Основные технические решения

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

2.1.1 Логическая и компонентная архитектура системы

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

Перечень используемых для создания системы программных средств приведен ниже:

- СУБД (Microsoft Office Access 2007);

-приложение (название, версия);

В состав разрабатываемой системы будут включены следующие технологические компоненты:

- программное обеспечение поддержки модели данных;

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

2.2. Решения по взаимосвязям АС со смежными системами, обеспечению ее совместимости

Определяются решения по взаимосвязям системы "БГ" со смежными системами, обеспечению ее совместимости (описание используемых протоколов обмена данными и средства и методы обмена данными). За основу берутся данные из пункта "Требования к характеристикам взаимосвязей со смежными системами" технического задания.

Ниже представлена общая схема взаимодействия системы "БГ" и смежных систем.

2.3 Решения по режимам функционирования, диагностированию работы системы

На основании пункта "Требования к режимам функционирования" технического задания приводятся режим работы системы. В основном режиме функционирования система обеспечивает: - работу пользователей в режиме - 12 часа в день,5 дней в неделю (12х5); - выполнение своих функций - сбор, обработка и загрузка данных; хранение данных, предоставление отчетности.

2.4. Решения по персоналу и режимам его работы

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

2.8. Решения по составу информации, объему, способам ее организации, видам машинных носителей, входным и выходным документам и сообщениям, последовательности обработки информации и другим компонентам

2.8.1 Описание информационной базы

В табличном виде приводится перечень и описание предметных областей модели данных хранилища данных.

Например:

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

После чего в табличной форме приводится наименование и описание каждой сущности предметной области модели данных.

Например:

Сущность модели данных	Описание сущности
Договора на оказание услуг	Договора на оказание услуг, заключенные между исполнителем и заказчиком.

2.8.2. Решения по пользовательскому интерфейсу

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

2.9 Методы и средства разработки

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

Данный раздел формируется на основе раздела "Требования к программному обеспечению" технического задания. -СУБД Microsoft office Access.

- Borland Delphi 7

3. Мероприятия по подготовке объекта автоматизации к вводу системы в действие

3.1 Мероприятия по подготовке информационной базы

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

Согласование интерфейса системы с заказчиком.

3.2 Мероприятия по подготовке персонала

Составление расписания по обучению персонала для работа по системе.

4. Требования к надежности

4.1.4.1. Состав показателей надежности для системы в целом

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

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

Время устранения отказа должно быть следующим:

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

Система должна соответствовать следующим параметрам:

- среднее время восстановления 48 часов - определяется как сумма всех времен восстановления за заданный календарный период, поделенные на продолжительность этого периода;

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

Нет требований.

4.1.4.3. Требования к надежности технических средств и программного обеспечения

К надежности оборудования предъявляются следующие требования:

- в качестве аппаратных платформ должны использоваться средства с повышенной надежностью;

- применение технических средств соответствующих классу решаемых задач;

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

4.1.4.4. Требования к методам оценки и контроля показателей надежности на разных стадиях создания системы в соответствии с действующими нормативно-техническими документами.

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

4.1.5. Требования к эргономике и технической эстетике

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

В части внешнего оформления:

- интерфейсы подсистем должен быть типизированы;

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

- должен использоваться шрифт: Franklin Gothic Demi Cond

- размер шрифта должен быть: 13-15

- цветовая палитра должна быть: чёрная, белая, тёмно-синяя

В части процедур ввода-вывода данных:

- должна быть возможность многомерного анализа данных в табличном и графическом видах.

К другим подсистемам предъявляются следующие требования к эргономике и технической эстетике.

В части внешнего оформления:

- интерфейсы по подсистемам должен быть типизированы.

В части процедур ввода-вывода данных:

- должна быть возможность получения отчетности по мониторингу работы подсистем.

4.1.6. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы

Условия эксплуатации, а также виды и периодичность обслуживания технических средств Системы должны соответствовать требованиям по эксплуатации, техническому обслуживанию, ремонту и хранению.

4.1.7. Требования к защите информации от несанкционированного доступа база данные автоматизированный информационный

4.1.7.1. Требования к информационной безопасности

Обеспечение информационное безопасности Системы СК должно удовлетворять следующим требованиям:

- Защита Системы должна обеспечиваться комплексом программно-технических средств и поддерживающих их организационных мер.

- Защита Системы должна обеспечиваться на всех технологических этапах обработки информации и во всех режимах функционирования, в том числе при проведении ремонтных и регламентных работ.

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

4.1.7.2. Требования к антивирусной защите

Средства антивирусной защиты должны быть установлены на всех рабочих местах пользователей и администраторов Системы СК.

4.1.7.3. Разграничения ответственности ролей при доступе.

Требования по разграничению доступа приводятся в виде матрицы разграничения прав.

Матрица должна раскрывать следующую информацию:

- код ответственности: Ф - формирует, О - отвечает, И - использует и т.п.;

- наименование объекта системы, на который накладываются ограничения;

- роль сотрудника/единица организационной структуры, для которых накладываются ограничения.

4.1.8. Требования по сохранности информации при авариях

В Системе должно быть обеспечено резервное копирование данных.

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

4.1.9. Требования к защите от влияния внешних воздействий

Нет требований.

4.1.10. Требования по стандартизации и унификации

Разработка системы должна осуществляться с использованием стандартных методологий функционального моделирования: IDEF0, DFD и информационного моделирования IE и IDEF1Х в рамках рекомендаций по стандартизации Р50.1.028-2001 "Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования".

Моделирование должно выполняться в рамках стандартов, поддерживаемых программными средствами моделирования ERWin 4.х и BPWin 4.х.

Для работы с БД должнен использоваться язык запросов SQL в рамках стандарта ANSI SQL-92.

Для разработки пользовательских интерфейсов и средств генерации отчетов (любых твердых копий) должны использоваться встроенные возможности ПО Borland Delphi 7.

В системе должны использоваться (при необходимости) общероссийские классификаторы и единые классификаторы и словари для различных видов алфавитно-цифровой и текстовой информации.

4.1.11. Дополнительные требования

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

Требования к системе, связанные с особыми условиями эксплуатации.

Специальные требования по усмотрению разработчика или заказчика системы.

СК должно разрабатываться и эксплуатироваться на уже имеющемся у Заказчика аппаратно-техническом комплексе.

Необходимо создать отдельные самостоятельные зоны разработки и тестирования системы СК.

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

4.1.12. Требования безопасности

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

4.1.13. Требования к транспортабельности для подвижных АИС

Нет требований

4.2. Требования к функциям, выполняемым системой

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

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

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

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

4) перечень и критерии отказов для каждой функции, по которой задаются требования по надежности.

4.2.1. Подсистема сбора, обработки и загрузки данных

4.2.1.1 Перечень функций, задач подлежащей автоматизации

Таблица 10 - Перечень функций, задач подлежащей автоматизации

Функция	Задача
Управляет процессами сбора, обработки и загрузки данных	Создание, редактирование и удаление процессов сбора, обработки и загрузки данных
	Формирование последовательности выполнения процессов сбора, обработки и загрузки данных (регламентов загрузки данных)
	Определение и изменение расписания процессов сбора, обработки и загрузки данных
Выполнение процессов сбора, обработки и загрузки данных из источников в ХД	Запуск процедур сбора данных из систем источников, загрузка данных в область временного, постоянного хранения
	Обработка и преобразование извлечённых данных
	Поддержка медленно меняющихся измерений
Протоколирует результаты сбора, обработки и загрузки данных	Ведение журналов результатов сбора, обработки и загрузки данных
	Оперативное извещение пользователей о всех нештатных ситуациях в процессе работы подсистемы

4.2.1.2 Временной регламент реализации каждой функции, задачи

Нет требований.

4.2.1.3 Требования к качеству реализации функций, задач

Нет требований.

4.2.1.4 Перечень критериев отказа для каждой функции

Нет требований

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

Нет требований.

4.3.1 Требования к математическому обеспечению

Нет требований.

4.3.2. Требования к информационному обеспечению

Нет требований.

4.3.2.1. Требования к составу, структуре и способам организации данных в системе

Структура хранения данных в СК должна состоять из следующих основных областей:

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

- область постоянного хранения данных;

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

4.3.2.3. Требования к информационной совместимости со смежными системами

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

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

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

Система, по возможности, должна использовать классификаторы и справочники, которые ведутся в системах-источниках данных.

Основные классификаторы и справочники в системе (клиенты, абоненты, бухгалтерские статьи и т.д.) должны быть едиными.

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

4.3.2.5. Требования по применению систем управления базами данных

Для реализации подсистемы хранения данных должна использоваться промышленная СУБД Microsoft Office Access 2003-2013

4.3.2.6. Требования к структуре процесса сбора, обработки, передачи данных в системе и представлению данных

Процесс сбора, обработки данных в системе определяется регламентом процессов сбора, преобразования и загрузки данных, разрабатываемом на этапе "Проектирование. Разработка эскизного проекта. Разработка технического проекта".

4.3.2.7. Требования к защите данных от разрушений при авариях и сбоях в электропитании системы

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

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

4.3.2.8. Требования к контролю, хранению, обновлению и восстановлению данных

К контролю данных предъявляются следующие требования:

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

К хранению данных предъявляются следующие требования:

- хранение исторических данных в системе должно производиться не более чем за 1 месяц. По истечению данного срока данные можно удалить;

4.3.2.9. Требования к процедуре придания юридической силы документам, продуцируемым техническими средствами системы

Требования не предъявляются.

4.3.3. Требования к лингвистическому обеспечению

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

При реализации системы должны применяться следующие языки высокого уровня: SQL.

При реализации системы должны применяться следующие языки и стандарты взаимодействия СК со смежными системами и пользователей с СК.

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

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

Для описания предметной области (объекта автоматизации) должен использоваться Erwin.

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

4.3.4. Требования к программному обеспечению

Для программного обеспечения системы приводят перечень покупных программных средств, а также требования:

к независимости программных средств от используемых СВТ и операционной среды;

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

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

Перечень покупных программных средств:

- Microsoft Office 2013;

- Borland Delphi 7;

- Rational Rose Enterprise;

- ERwin Data Modeler;

- CASE-средство BPwin;

К обеспечению качества ПС предъявляются следующие требования:

- функциональность должна обеспечиваться выполнением подсистемами всех их функций.

- надежность должна обеспечиваться за счет предупреждения ошибок - не допущения ошибок в готовых ПС;

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

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

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

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

4.3.5. Требования к техническому обеспечению

Требования не предъявляются.

4.3.6. Требования к метрологическому обеспечению

Требования не предъявляются.

4.3.7. Требования к организационному обеспечению

К защите от ошибочных действий персонала предъявляются следующие требования:

- для всех пользователей должна быть запрещена возможность удаления преднастроенных объектов и отчетности;

- для снижения ошибочных действий пользователей должно быть разработано полное и доступное руководство пользователя.

4.3.8. Требования к методическому обеспечению

Требования не предъявляются.

4.3.9. Требования к патентной чистоте

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

5. Состав и содержание работ по созданию системы

Данный раздел должен содержать перечень стадий и этапов работ по созданию системы в соответствии с ГОСТ 24.601, сроки их выполнения, перечень организаций - исполнителей работ, ссылки на документы, подтверждающие согласие этих организаций на участие в создании системы, или запись, определяющую ответственного (заказчик или разработчик) за проведение этих работ.

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

6. Технический проект

Первым делом на данном этапе была построена логическая модель в Erwin (Рисунок 4). После чего провёл сведение данной диаграммы и диаграммы в BPwin .

Рисунок 4 - Логическая модель в ERwin.

Следующим этапом послужило создание базы данных в Microsoft Office Access, где были смоделированы четыре таблицы, которые исходят из логическом модели в ERwin.



Рисунок 5. - Главное окно программы

Рисунок 6. - Окно "Группы"

Рисунок 7. - Окно "Песни"



Рисунок 8. - Окно "Гастрольные поездки"

Рисунок 9. - Окно "Контракты"

Рисунок 10. - Окно "Гастроли"

Заключение

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

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

В данной работе была проанализирована литература, ознакомился с предметной областью, построил ER-модель базы данной, охарактеризовал СУБД для реализации базы данных, была построена логическая модель базы данных, разработан проект и база данных, созданы объекты базы данных (таблицы, формы, отчеты), определены условия целостности базы данной и создана справочная служба, а также спроектировано меню приложения и создан инсталляционный пакет.

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

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

Размещено на Allbest.ru