ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ
ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ
ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
«ВЯТСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»
СОЦИАЛЬНО-ЭКОНОМИЧЕСКИЙ ФАКУЛЬТЕТ
КАФЕДРА ПРИКЛАДНОЙ ИНФОРМАТИКИ
Пояснительная записка
Курсовой проект по дисциплине
«Разработка и стандартизация
программных средств и информационных технологий»
ТПЖА. 080801. 056 ПЗ
Разработала студентка гр. ПИЭ_____________________ /Гурдина Л.В./
(подпись)
Проверил фффффффффф ввв_____________________/Голованов А.А./
(подпись)
Проект защищен с оценкой «(__________)» «___» _______2009 год
Киров 2009
Содержание:
1. Цель курсовой работы……………………………………………….………3
2. Функциональные возможности BPWin…………………………………….4
3. Построение модели IDEF0…………………………………………………..5
4. Построение модели IDEF3…………………………………………………..8
5. Построение модели DFD……………………………………………………11
6. Техническое задание………………………………………………………..13
7. Список литературы…………………………………………………………28
Цель курсовой работы:
1 Построить контекст системы – взаимодействие моделируемого объекта с внешним миром (IDEF0).
2 На втором уровне модели отразить основные деятельности объекта и их взаимосвязи (IDEF0).
3 Детализировать каждую из деятельностей на бизнес-процессы, желательно, единственного уровня (IDEF3).
4 Детализировать бизнес-процессы посредством бизнес-функций на не более 2-3 уровней детализации(IDEF3, DFD).
5. Разработать техническое задание техническое задание на создание автоматизированной системы в соответствии с ГОСТ 34.602-89.
2. Функциональные возможности
BPWin
BPwin - инструмент для моделирования, анализа, документирования и оптимизации бизнес-процессов. Его можно использовать для графического представления бизнес-процессов. Графически представленная схема выполнения работ, обмена информацией, документооборота визуализирует модель бизнес-процесса. Графическое изложение этой информации позволяет перевести задачи управления организацией из области сложного ремесла в сферу инженерных технологий.
BPwin помогает четко документировать важные аспекты любых бизнес-процессов: действия, которые необходимо предпринять, способы их осуществления и контроля, требующиеся для этого ресурсы, а также визуализировать получаемые от этих действий результаты. Так же он повышает бизнес-эффективность ИТ-решений, позволяя аналитикам и проектировщикам моделей соотносить корпоративные инициативы и задачи с бизнес-требованиями и процессами информационной архитектуры и проектирования приложений. Таким образом, формируется целостная картина деятельности предприятия: от потоков работ в небольших подразделениях до сложных организационных функций.
BPwin эффективен в проектах, связанных с описанием действующих баз предприятий, реорганизацией бизнес-процессов, внедрением корпоративной информационной системы. Продукт позволяет оптимизировать деятельность предприятия и проверить ее на соответствие стандартам ISO 9000, спроектировать оргструктуру, снизить издержки, исключить ненужные операции и повысить эффективность.
3.Построение модели
IDEF
0
Методология функционального моделирования IDEF0 — это технология описания системы в целом как множества взаимозависимых действий или функций. Важно отметить функциональную направленность: IDEF0-функции системы исследуются независимо от объектов, которые обеспечивают их выполнение.
Первый шаг при построении модели IDEF0 заключается в определенииназначения модели — набора вопросов, на которые должна отвечатьмодель.
Контекстная диаграмма IDEF0 – «Деятельность
стоматологического кабинета».
Декомпозиция контекстной диаграммы - «Деятельность стоматологического кабинета»
Декомпозиция контекстной диаграммы – «Проведение
маркетинговых исследований»
Декомпозиция контекстной диаграммы –
«Организация работы с пациентами»
Декомпозиция контекстной диаграммы – «Учет и оценка деятельности»
4. Построение модели
IDEF
3
IDEF3 - способ описания процессов с использованием структурированного метода, позволяющего эксперту в предметной области представить положение вещей, как упорядоченную последовательность событий с одновременным описанием объектов, имеющих непосредственное отношение к процессу.
IDEF3 является технологией, хорошо приспособленной для сбора данных, требующихся для проведения структурного анализа системы.
Диаграмма IDEF3 работы «Изучение структуры рынка»
Диаграмма IDEF3 работы «Прием пациента»
Диаграмма IDEF3 работы «Оплата»
Диаграмма IDEF3 работы «Финансовая отчетность»5. Построение модели
DFD
Так же, как и диаграммы IDEF0, диаграммы потоков данных (DataFlowDiagrams — DFD) моделируют систему как набор действий, соединенных друг с другом стрелками. Диаграммы потоков данных могут содержать два новых типа объектов: объекты, собирающие и хранящие информацию, — хранилища данных
и внешние сущности
— объекты, моделирующие взаимодействие с теми частями системы (или другими системами), которые выходят за границы моделирования
DFD диаграмма декомпозиции работы «Запись пациента»
DFD диаграмма декомпозиции работы «Учет лекарственных средств и расходных материалов»
__________________
ПБОЮЛ Гурдина Л.В. ______________________
наименование организации - разработчика ТЗ на АС УТВЕРЖДАЮРуководитель (директор стоматологического кабинета) Гурдин Михаил МихайловичЛичная подпись Расшифровка подписи Гурдин М.М.Печать Дата 21.11.2008 УТВЕРЖДАЮРуководитель (организатор-разработчик) Гурдина Людмила ВалерьевнаЛичная подпись Расшифровка подписи Гурдина Л.В.Печать Дата 21.11.2008 Автоматизированная информационная система «Система управления деятельностью стоматологического кабинета»
наименование вида АС_____________Стоматологический кабинет
_________________ наименование объекта автоматизации__________Стоматологический кабинат______________
ТЕХНИЧЕСКОЕ ЗАДАНИЕ На 16листах Действует с 21.11.2008 СОГЛАСОВАНО Руководитель (директор, наименование согласующей организации) Гурдин Михаил МихайловичЛичная подпись Расшифровка подписи Гурдин М.М. ПечатьДата 21.11.2008
1) Общие сведения
1.1
Полное наименование системы и ее условное обозначение
Полное наименование системы: автоматизированная информационная система «Система управления деятельностью стоматологического кабинета»
Условное обозначение: Стоматология
1.2
Шифр темы или шифр (номер) договора
Шифр темы: АС-ДСК-2008
Шифр договора: №1/12345 от 21.11.2008
1.3 Наименование предприятий (объединений) разработчика и
заказчика (пользователя) системы и их реквизиты:
Наименование предприятия разработчика: ПБОЮЛ Гурдина ЛВ
Адрес: г.Киров
Наименование предприятия заказчика: ПБОЮЛ Гурдин ММ
Адрес: г.Киров
1.4 Перечень документов, на основании которых создается система, кем и когда утверждены эти документы
Документ, на основании которого создается система – договор №1/12345, утвержденнный Гурдиным М.М. от 21 декабря 2008 г.
1.5 Плановые сроки начала и окончания работы по созданию системы
Плановые сроки начала работ по созданию системы – 01.11.2008
Плановые сроки окончания работ по созданию системы – 08.01.2009
1.6 Сведения об источниках и порядке финансирования работ:
Источником финансирования является предприятие заказчика,
Порядок финансирования определяется договором с заказчиком.
1.7
Порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы
Результаты работ по проекту передаются Заказчику в сроки, установленные Договором, в двух экземплярах в виде программного комплекса и технической документации. Исходные коды передаются на электронном носителе (компакт-диск), а техническая документация – на электронном и бумажном.
Состав разрабатываемого Исполнителем комплекта документации приведен в разделе «Требования к документированию» настоящего технического задания.
Приемка комплекса осуществляется комиссией в составе уполномоченных представителей Заказчика и Исполнителя. Порядок предоставления комплекса, проведения его испытаний и приемки определен в разделе 6 настоящего технического задания.
2) Назначение и цели создания (развития) системы
2.1 Назначение системы:
Система предназначена для сбора, хранения и обработки данных о пациентах, их истории лечения и используемых лекарственных прапаратах, а так же врачей назначавших и проводящих это лечение.
2.2 Цели создания системы:
Целью создания системы является:
· снижение рутинной работы администратора за счет быстрого поиска необходимой информации.
3) Характеристика объектов автоматизации
3.1 Краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию.
Объектом автоматизации является организация ООО «ГММ»
3.2 Сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды.
Характеристики окружающей среды и условия эксплуатации определяются в соответствии с Гигиеническими требованиями к видеодисплейным терминалам, персональным электронно-вычислительным машинам и организации работы (Санитарные правила и нормы. СанПиН 2.2.2.542-96 (утв. постановлением Госкомсанэпиднадзора России от 14.07.96 г. N 14).
4) Требования к системе
4.1 Требования к системе в целом:
4.1.1 Требования к структуре и функционированию системы
4.1.1.1 Перечень подсистем, их назначение и основные характеристики, требования к числу уровней иерархии и степени централизации системы.
В состав системы должны быть включены следующие подсистемы:
Подсистема хранения данных (о пациентах, лекарственных препаратах, и врачах) предназначенная для хранения данных системы;
Подсистема управления справочной информацией предназначена для ведения справочников.
Так же система должна обладать иерархической структурой и включать в себя перечисленные ниже уровни иерархии:
1-й уровень - уровень сбора данных;
2-й уровень - уровень консолидации данных (централизованная обработка, хранение и пр.);
4.1.1.2 Требования к составу выполняемых функций
.
Программа должна обеспечивать возможность выполнения перечисленных ниже функций:
1) добавления записей в таблицы базы данных
2) удаления записей из таблиц базы данных
3) сортировки записей в таблицах базы данных.
4.1.1.3 Перспективы развития, модернизации системы
АС должна реализовывать возможность дальнейшей модернизации как программного обеспечения, так комплекса технических средств. Также необходимо предусмотреть возможность увеличения производительности системы путем её масштабирования.
4.1.2 Требования к численности и квалификации персонала системы и режиму его работы.
Численность персонала должна удовлетворять требованиям:
1) быть достаточной для реализации автоматизированных функций системы во всех режимах работы системы;
2) обеспечивать полную занятость персонала при реализации автоматизированных функций системы.
4.1.3 Показатели назначения.
Система должна обеспечивать возможность хранения данных до 15 лет, а так же возможность работы в системе всем имеющимся автоматизируем рабочим местам в организации (до 20).
4.1.4 Требования к надежности.
Необходимо, чтобы система обладала устойчивостью к отказам оборудования и программных систем, а также электропитания. Для надежной работы комплекса необходимы высоконадежные аппаратные и программные системы. Требования надежности должны быть регламентированы для следующих аварийных ситуаций:- выход из строя аппаратных средств системы;- отсутствие электроэнергии;- выход из строя программных средств системы;- неверные действия персонала компании;- пожар, взрыв и т.п. Методы оценки и контроля показателей надежности на разных стадиях создания системы должны отвечать следующим особенностям:· многофункциональность;· сложные формы взаимосвязи систем комплекса;· существенная роль временных соотношений отказов отдельных систем комплекса;· разнообразные законы распределения среднего времени безотказной работы и восстановления.
4.1.5 Требования безопасности.
Все технические решения, использованные при создании АИС, а также при определении требований к аппаратному обеспечению, должны соответствовать действующим нормам и правилам техники безопасности, пожаробезопасности и взрывобезопасности, а также охраны окружающей среды при эксплуатации.
Факторы, оказывающие вредные воздействия на здоровье со стороны всех элементов системы (в том числе инфракрасное, ультрафиолетовое, рентгеновское и электромагнитное излучения, вибрация, шум, электростатические поля, ультразвук строчной частоты и т.д.), не должны превышать действующих норм (СанПиН 2.2.2./2.4.1340-03 от 03.06.2003 г.).
Более детальные требования по безопасности эксплуатации и обслуживания технических средств, входящих в состав системы, описываются в поставляемой с ними эксплуатационной документации.
4.1.6 Требования к эргономике и технической эстетике.
Взаимодействие пользователей с прикладным программным обеспечением, входящим в состав системы должно осуществляться посредством визуального графического интерфейса (GUI). Интерфейс системы должен быть понятным и удобным, не должен быть перегружен графически
Система должна обеспечивать корректную обработку аварийных ситуаций, вызванных неверными действиями пользователей, неверным форматом или недопустимыми значениями входных данных. В указанных случаях система должна выдавать пользователю соответствующие сообщения, после чего возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или некорректному вводу данных.
Экранные формы должны проектироваться с учетом требований унификации: – все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации; – для обозначения сходных операций должны использоваться сходные графические значки, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций (добавление информационной сущности, редактирование поля данных), а также последовательности действий пользователя при их выполнении, должны быть унифицированы; – внешнее поведение сходных элементов интерфейса (реакция на наведение указателя «мыши», переключение фокуса, нажатие кнопки) должны реализовываться одинаково для однотипных элементов. Система должна соответствовать требованиям эргономики и профессиональной медицины при условии комплектования высококачественным оборудованием (ПЭВМ, монитор и прочее оборудование), имеющим необходимые сертификаты соответствия и безопасности Росстандарта.
4.1.7 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы.
Требования не оговариваются.
4.1.8 Требования к защите информации от несанкционированного доступа.
Информационная система должна обеспечивать защиту от несанкционированного доступа на уровне не ниже установленного требованиями, предъявляемыми к категории 1Д по классификации действующего руководящего документа Гостехкомиссии России «Автоматизированные системы.
4.1.9 Требования по сохранности информации при авариях.
Программное обеспечение должно восстанавливать свое функционирование при корректном перезапуске аппаратных средств. Должна быть предусмотрена возможность организации автоматического и (или) ручного резервного копирования данных системы средствами системного и базового программного обеспечения (ОС, СУБД), входящего в состав программно технического комплекса Заказчика. Приведенные выше требования не распространяются на компоненты системы, разработанные третьими сторонами и действительны только при соблюдении правил эксплуатации этих компонентов, включая своевременную установку обновлений, рекомендованных производителями покупного программного обеспечения.
.
4.1.10 Требования к защите от влияния внешних воздействий.
Защита от влияния внешних воздействий должна обеспечиваться средствами программно технического комплекса Заказчика.
4.1.11 Требования к патентной чистоте.
Установка системы в целом, как и установка отдельных частей системы не должна предъявлять дополнительных требований к покупке лицензий на программное обеспечение сторонних производителей, кроме программного обеспечения.
4.1.12 Требования по стандартизации и унификации.
В процессе функционирования системы должны использоваться программные и аппаратные средства с учетом удобства их применения в рамках комплекса.
База данных хранится в формате MicrosoftAccess (mdb-файл). После внесения изменений все данные сохранять в том же файле.
Интерфейс системы построить на основе стандартных для операционной системы Windows элементов. Для изображения различных объектов базы данных использовать пиктограммы, принятые в MicrosoftAccess.
4.1.13Дополнительные требования
Дополнительные требования не предъявляются.
4.2 Требования к функциям (задачам), выполняемым системой
4.2.1
Подсистема хранения данных
Подсистема хранения данных должна осуществлять хранение оперативных данных системы, данных для формирования аналитических отчетов, документов системы, сформированных в процессе работы отчетов. Подсистема должна обеспечивать периодическое резервное копирование и сохранение данных на дополнительных носителях информации.
4.2.2. Подсистема управления нормативно-справочной информацией
Подсистема должна решать задачу обеспечения информационной совместимости данных, которыми обмениваются отдельные компоненты Системы между собой, а также со смежными системами в процессе функционирования. В число функций подсистемы должны быть включены функции ведения справочной информации. Справочники и классификаторы, входящие в состав подсистемы, должны проектироваться и разрабатываться в соответствии с действующими общероссийскими и международными справочниками и классификаторами, где это представляется возможным. Подсистема должна предоставлять пользователю удобные инструменты для поиска и применения необходимой справочной информации. Все справочники, входящие в состав АИС системы, должны обладать следующей основной функциональностью: - Постоянное хранение данных справочников; - Добавление новых элементов; - Редактирование элементов; - Удаление (удаление элементов возможно лишь в том случае, если другие существующие объекты системы не ссылаются на удаляемый элемент); - Просмотр элементов; - Просмотр списка элементов; - Фильтрация и сортировка списка элементов; - Поиск элементов; - Экспорт и импорт элементов. Перечень функций справочников должен быть уточнен на стадиях технического проектирования и опытной эксплуатации.
4.2.3 Подсистема анализа
Подсистема анализа должна формировать и предоставлять аналитические данные о деятельности организации с возможностью оперативного отслеживания ключевых показателей. Подсистема анализа должна быть построена на основе современных OLAP-технологий, позволяющих строить многомерные аналитические отчеты произвольного вида, включая графическое и текстовое представление данных.
4.3 Требования к видам обеспечения
4.3.1 Требования к информационному обеспечению
.
В состав информационного обеспечения программы входит база данных (внутримашинное обеспечение), входная, внутренняя и выходная документация.· В качестве входной информации выступает:БД учета и контроля (mdb-файла);· Выходной информацией служат:a. Изменения в объектах БДb. mdb-файл с внесенными в него изменениямиc. отчет о введенной информации
4.3.2. Требования к лингвистическому обеспечению.
- Шрифт ввода-вывода данных - кириллица; - Пользовательский интерфейс должен соответствовать следующим требованиям: 1. Эффективные интерфейсы должны быть очевидными и внушать своему пользователю чувство контроля. Необходимо, чтобы пользователь мог одним взглядом окинуть весь спектр своих возможностей, понять, как достичь своих целей и выполнить работу. 2. Эффективные интерфейсы не должны беспокоить пользователя внутренним взаимодействием с системой. Необходимо бережное и непрерывное сохранение работы, с предоставлением пользователю возможности отменять любые действия в любое время.
4.3.3. Требования к программному обеспечению.
ИС учета и контроля ТВКР требует для своей работы установки следующего ПО:
1. На сервере ИС учета и контроля ТВКР должны быть установлены:
· Операционная система: MicrosoftWindows 2000/2003 Server,
· СУБД MicrosoftAccess 2000/XP (БД учета и контроля ТВКР)
2. На рабочей станции пользователя необходимо установить:
· Операционная система: Microsoft Windows 2000/XP/Vista
· ИС учета и контроля ТВКР.
4.3.4. Требования к техническому обеспечению.
Для функционирования ИС необходимо:
-локальная вычислительная сеть на основе протокола TCP/IP с пропускной способностью 10/100 Мбит/с.Сервер должен удовлетворять следующим минимальным требованиям:
-процессор Celeron-500MHz или аналогичный,
-1Gb и более оперативной памяти;
-80 Gb – жесткий диск
-Монитор – SVGA;
-Клавиатура - 101/102 клавиши;
-Манипулятор типа «мышь».
Требования, предъявляемые к конфигурации клиентских станций:
· процессор, с тактовой частотой не менее 400 MHz,
· 256 Mb оперативной памяти;
· Монитор – SVGA;
· Клавиатура - 101/102 клавиши;
· Манипулятор типа «мышь».
4.3.5 Требования к методическому обеспечению.
Требования к метрологическому обеспечению не предъявляются 5) Состав и содержание работ по созданию системы
Работа по проекту должна проводится в 2 этапа:
· разработка концепции и технических заданий
· разработка программного обеспечения
Сроки выполнения этапов работ определяются календарным планом.
| Стадии
|
Этапы работ
|
Представляемые документы
|
Срок исполнения
|
Предпроектная
|
Обследование объекта автоматизации
|
03.01.09
|
|
| Составление отчета
|
Отчет
Доклад
|
09.01.09
|
|
Проектная
|
Разработка информационной базы
|
Отчет
|
01.02.09
|
| Разработка экранных форм для ввода данных
|
Отчет
Эскизы форм
|
10.02.09
|
|
| Разработка запросов к базе данных
|
Отчет
|
20.02.09
|
|
| Разработка интерфейсов системы
|
Отчет
|
26.02.09
|
|
Опытная эксплуатация и внедрение системы
|
Опытная эксплуатация системы.
Корректировка документации
|
Отчет
|
28.02.09
|
| Сдача системы в эксплуатацию
|
Отчет
Руководство для пользователя и администратора
|
31.02.09
|
6) Порядок контроля и приемки системы
6.1 Виды, состав, объем и методы испытаний системы
Виды, состав, объем, и методы испытаний подсистемы должны быть изложены в программе и методике испытаний АС Кадры, разрабатываемой в составе рабочей документации.
6.2 Общие требования к приемке работ по стадиям
Сдача-приёмка работ производится поэтапно, в соответствии с рабочей программой и календарным планом
Сдача-приемка осуществляется комиссией, в состав которой входят представители Заказчика и Исполнителя. По результатам приемки подписывается акт приемочной комиссии. Все создаваемые в рамках настоящей работы программные изделия (за исключением покупных) передаются Заказчику, как в виде готовых модулей, так и в виде исходных кодов, представляемых в электронной форме на стандартном машинном носителе (например, на компакт-диске).
6.3 Статус приемочной комиссии
Статус приемочной комиссии определяется Заказчиком до проведения испытаний.
7) требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
Для обеспечения готовности объекта к вводу системы в действие провести комплекс мероприятий:
· приобрести компоненты технического и программного обеспечения, заключить договора на их лицензионное использование;
· завершить работы по установке технических средств;
· провести обучение пользователей.
8) требования к документированию
Проектная документация должна быть разработана в соответствии с ГОСТ 34.201-89 и ГОСТ ЕСПД. Отчетные материалы должны включать в себя текстовые материалы (представленные в виде бумажной копии и на цифровом носителе в формате MS Word) и графические материалы. Предоставить документы:
1. Описание автоматизируемых функций;
2. Схема функциональной структуры автоматизируемой деятельности;
3. Описание технологического процесса обработки данных;
4. Описание информационного обеспечения;
5. Описание программного обеспечения АС;
6. Схема логической структуры БД;
7. Описание комплекса технических средств;
8. Чертёж формы документа (видеокадра);
9. Руководство пользователя;
10. Описание контрольного примера (по ГОСТ 24.102);
11. Протокол испытаний (по ГОСТ 24.102).
9. Источники разработки.
Документы и информационные материалы, на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы:
- ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы;
- ГОСТ 34.201-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированной системы.
- Материалы курса РиСПСиИТ
7.
Список литературы:
1. Вендров А. М. Проектирование программного обеспечения экономических информационных систем: Учебник. – М.: Финансы и статистика, 2002. – 352 с.: ил.
2. С.В. Маклаков Моделирование бизнес – процессов с AllfusionProcessModeler.
3. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++, 2-е изд./Пер. с англ. – М.: «Издательство Бином».