Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
задание
на выпускную квалификационную работу
1. Тема дипломного проекта, дипломной работы __ Разработка подсистема автоматизации учебно-учетной деятельности в спортивной школе__________________________
__________________________________________________________________________________________________________________________________________________________________________
утверждена распоряжением №______ от ________________________ г.
2. Технические условия ____Персональный компьютер IBM, процессор AMD Athlon(tm) XP 2600+ , видеоадаптер NVIDIA GeForce 6200, принтер Samsung SCX-4200 Series,_________ операционная система Windows XP (5.1.2600) Professional____________________________
3. Содержание работы (разделы, графические работы, расчеты и проч.) _Введение. 1. Введение. 1. Анализ методов и средств построения информационной системы автоматизации документооборота в спортивном учреждении. 2. Разработка информационного обеспечения системы автоматизации документооборота в спортивной школе. 3.Разработка программного обеспечения информационной системы автоматизации документооборота в спортивной школе. 4.Организационно-экономическая часть. 5.Безопасность жизнедеятельности. Заключение. Список литературы. Приложения.___________________
_____________________________________________________________________________ _____________________________________________________________________________
____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
4. План выполнения дипломного проекта, дипломной работы
с «_____»__________________201 г. по « »___ 201 _г.
|
Название элементов проектной работы |
% |
Сроки |
% выполнения |
Подпись рук., консультанта |
|
Анализ методов и средств построения информационных системы автоматизации документооборота в спортивном учреждении |
20 |
2.03 – 25.03 |
100 |
|
|
Разработка информационного обеспечения системы автоматизации документооборота в спортивной школе |
25 |
26.03 – 20.04 |
100 |
|
|
Разработка программного обеспечения информационной системы автоматизации документооборота в спортивной школе. |
25 |
21.04 – 11.05 |
100 |
|
|
Организационно-экономическая часть |
15 |
11.05 – 25.05 |
100 |
|
|
Безопасность жизнедеятельности |
10 |
25.05 – 5.06 |
100 |
|
|
Оформление |
5 |
05.06 – 10.06 |
100 |
|
Руководитель дипломного проекта, дипломной работы
________________________________ _______Питолин Андрей Владимирович_________________
(подпись) (Фамилия, имя, отчество)
5. Дипломный проект, дипломная работа закончен (а)
«______»_______________________г.____________________________________________________
(подпись дипломника)
6. Пояснительная записка и все материалы просмотрены.
Оценка руководителя ____________________________________________________
7. Назначить защиту на «______»_______________________г.
Содержание
|
Введение……………………………………………………………………… |
6 |
|
1. Анализ методов и средств построения систем автоматизации учебно-учетной деятельности в спортивном учреждении ……………………. |
8 |
|
1.1 Организационная структура спортивной школы как объекта внедрения средств информатизации ……........................................ |
8 |
|
1.2. Общие принципы разработки и функционирования систем автоматизации учебно-учетной деятельности ……………………. |
14 |
|
1.3. Сравнительный анализ инструментальных средств построения систем автоматизации учебно-учетной деятельности.................... |
24 |
|
1.4 Цель и задачи дипломного проектирования……………………….. |
34 |
|
2. Разработка информационного обеспечения системы автоматизации учебно-учетной деятельности в спортивной школе …………………... |
35 |
|
2.1 Особенности формирования информационных моделей на основе концепции баз данных……………………………………………… |
35 |
|
2.2. Формирование логической и концептуальной моделей структурирования данных с использованием CASE-средств ....... |
48 |
|
3 Разработка программного обеспечения информационной системы автоматизации учебно-учетной деятельности спортивной школе …... |
63 |
|
3.1 Выбор языковых и программных средств реализации программного обеспечения …........................................................... |
63 |
|
3.2 Модульная структура программного обеспечения………………… |
65 |
|
3.3 Организация пользовательского интерфейса информационной системы автоматизации учебно-учетной деятельности в спортивной школе…………………………………………………... |
68 |
|
4 Организационно-экономическая часть…………………………………... |
75 |
|
4.1 Краткая характеристика разрабатываемого программного продукта (ПП) и этапов его разработки…………………………… |
75 |
4.2 Определение трудоемкости разработки ПП………………………... |
76 |
|
|
78 |
|
4.4 Расчет сметной стоимости и договорной цены разработки ПП…... |
80 |
|
4.5 Анализ конкурентоспособности программного продукта………… |
86 |
4.5.1 Анализ технической прогрессивности………………………… |
88 |
4.5.2 Анализ изменения функциональных возможностей…………. |
89 |
4.5.3 Анализ соответствия разрабатываемого ПП нормативам…… |
89 |
4.5.4 Оценка годовых эксплуатационных издержек потребителя… |
89 |
4.5.5 Анализ экономических параметров ПП………………………. |
91 |
4.5.6 Оценка конкурентоспособности……………………………….. |
93 |
4.6 Оценка экономической эффективности…………………………….. |
93 |
|
4.7 Анализ технико-экономических показателей разработки и эксплуатации ПП……………………………………………………. |
95 |
|
5. Безопасность жизнедеятельности………………………………………... |
96 |
|
5.1 Организация рабочего места ………………………………………... |
97 |
|
5.2 Режим освещенности рабочего места ……………………………… |
98 |
|
5.3 Микроклимат помещения………………………………………….... |
99 |
|
5.4 Уровень шума………………………………………………………… |
100 |
|
5.5 Психофизиологические нагрузки…………………………………… |
101 |
|
5.6 Обеспечение электробезопасности ………………………………… |
101 |
|
5.7. Обеспечение пожаробезопасности…………………………………. |
102 |
|
Заключение…………………………………………………………………... |
104 |
|
Список литературы………………………………………………………….. |
105 |
|
Приложение А. Фрагмент листинга программных модулей……………... |
107 |
Возможность своевременного получения достоверной информации является на сегодняшний день одним из важнейших факторов повышения эффективности работы любой организации.
В настоящее время все больше организаций и предприятий используют в процессе своей работы компьютеры, что позволяет автоматизировать некоторые операции и облегчить труд человека.
Одним из важных шагов создания информационной подсистемы является разработка базы данных, которая позволит организовать и упорядочить информацию, а также обеспечит быстрый доступ к данным и выборку необходимой информации. Возможность автоматического создания отчетов на основе базы данных будет способствовать избавлению ответственного лица от кропотливой бумажной работы, связанной с их монотонным написанием. К тому же она предусматривает некоторый механизм защиты от ошибочных действий оператора при пополнении и модификации базы данных и обладает достаточной степенью универсальности.
Разработка информационной подсистемы требует создания соответствующего информационного и программного обеспечения.
1 Анализ методов и средств построения систем автоматизации учебно-учетной деятельности в спортивном учреждении
1.1 Организационная структура спортивной школы как объекта внедрения средств информатизации
Спортивное учреждение – это большая сложная и постоянно развивающаяся структура, от четкой работы которой зависит будущее тех спортсменов, которые в нем тренируются, а также здоровый образ жизни многих жителей города.
Основной целью детско-юношеской спортивной школы (ДЮСШ) является привлечение максимально возможного числа детей и подростков, их родителей к систематическим занятиям спортом, направленным на развитие личности, утверждение здорового образа жизни, воспитание физических, морально - этических и волевых качеств.
Кроме этого, в процессе своей работы ДЮСШ решает ещё ряд задач, к которым относятся:
– пропаганда и агитация систематических занятий физической культурой и спортом;
– организация и проведение спортивно – массовых мероприятий;
– совершенствование спортивного мастерства спортсменов;
– выявление сильнейших спортсменов;
– профилактика безнадзорности и правонарушений среди несовершеннолетних;
– подготовка спортивного резерва и передача спортсменов в высшее звено обучения;
– популяризация видов спорта, культивируемых в его стенах;
– предоставление материальной базы для тренировок любительских и полупрофессиональных команд;
– предоставление услуг для профессиональных команд;
– поощрение спортсменов, добившихся высоких спортивных результатов.
Спорткомбинат предоставляет возможность занятия следующими видами спорта: большой теннис, футбол, баскетбол, волейбол, настольный теннис, плавание, дзюдо, бокс, легкая атлетика, мини-футбол и др.
В состав Спорткомбината входят:
В организационной структуре ДЮСШ № 2 выделяют следующие отделы управления: бухгалтерия, отдел кадров, отдел информационных технологий (ИТ), административно-хозяйственный отдел, отдел снабжения, учебно-спортивный отдел.
Функции отделов представлены в таблице 1.1
Таблица 1.1 – Функции отделов
|
Наименование отдела |
Функции |
|
1 |
2 |
|
Бухгалтерия |
Учет и контроль за движением и использованием материальных и денежных средств. Расчет зарплаты сотрудников, балансов, расходов и доходов. |
|
Отдел кадров |
Прием/увольнение сотрудников. Работа с персоналом. Охрана труда. |
Продолжение таблицы 1
|
1 |
2 |
|
Отдел информационных технологий |
Поддержание работоспособности компьютерного и сетевого оборудования, копировальной техники и оргтехники. Разработка, реализация и внедрение нового ПО. Внедрение современных методов и систем технологического, хозяйственного и административного управления. |
|
Административно-хозяйственный отдел |
Ведение хозяйства. Организационная работа (организация рабочих мест, организация питания сотрудников); эксплуатация здания, помещения, территории (уборка помещений, ремонт помещений, обустройство прилегающих территорий). |
|
Отдел снабжения |
Обеспечение спортивным инвентарем, тренажерами, оборудованием; уточнение номенклатуры и объема поставок; сбор информации о поставщике |
|
Учебно-спортивный отдел |
Запись в спортивные группы. Назначение тренеров для групп. Составление расписания тренировок. |
Во главе Спорткомбината стоит директор. В непосредственном подчинении у директора находятся заместитель директора и главный бухгалтер. Заместителю директора подчиняются начальники отдела кадров, отдела информационных технологий, административно-хозяйственного отдела, отдела снабжения, а также учебно-спортивного отдела. Также заместителю директора подчиняются заведующие спортивными объектами. Сотрудники бухгалтерии подчиняются непосредственно главному бухгалтеру. Схема организационной структуры Спорткомбината показана на рисунке 1.1
Рисунок 1.1 – Организационная структура спортивного учреждения
Директор определяет всю политику ДЮСШ, координирует, контролирует, организовывает работу, принимает самые важные и глобальные решения.
Заместитель директора выполняет функции директора. Курирует вопросы не высокой и средней важности.
Главный бухгалтер осуществляет контроль над материальными и денежными средствами предприятия. Руководит расходами, кассовыми и банковскими операциями. Распределяет денежные средства. Координирует работу сотрудников бухгалтерии и контролирует все вопросы решаемые бухгалтерией.
Начальник отдела кадров непосредственно руководит сотрудниками отдела кадров. Контролирует все вопросы, решаемые отделом кадров. Руководит кадровой работой, принимает решения связанные с персоналом.
Начальник отдела информационных технологий непосредственно руководит сотрудниками отдела ИТ. Контролирует все вопросы, решаемые отделом ИТ, и координирует работу сотрудников. Является связующим звеном между руководством и сотрудниками отдела. Руководит и контролирует выполнение всех работ связанных с обеспечением работоспособности компьютерной и копировальной техники. Руководит поиском и выбором поставщиков техники и программного обеспечения (ПО), заменой техники в соответствии с планами модернизации, разработкой, созданием и внедрением нового ПО, поддержанием его работоспособности и т.д.
Начальник административно-хозяйственного отдела является непосредственным руководителем для всех сотрудников административно-хозяйственного отдела. Является связующим звеном между руководством и сотрудниками отдела. Руководит хозяйством, контролирует чистоту и порядок в помещениях, ремонт помещений, курирует вопросы, связанными с обустройством, интерьером, бытовыми условиями работы персонала.
Начальник отдела снабжения непосредственно руководит сотрудниками отдела снабжения. Руководит и контролирует выполнение работ по обеспечению Спорткомбината необходимым спортинвентарем, тренажерами и оборудованием, организует партнерские отношения с поставщиком.
Начальник учебно-спортивного отдела является непосредственным руководителем для всех сотрудников учебно-спортивного отдела. Руководит работой сотрудников, а также контролирует процесс записи спортсменов в группы, назначение тренеров для групп. Следит за тем, как сотрудники выполняют свои обязанности.
Заведующий стадионом контролирует работу стадиона, контролирует работу персонала, следящего за состоянием газона, беговых дорожек, трибун. Обеспечивает порядок на стадионе.
Заведующий бассейном контролирует работу бассейна, контролирует работу персонала, следящего за температурой воды, температурой и чистотой помещения, своевременной сменой воды в бассейне.
Заведующий универсальным спортивным залом и малым залом руководит персоналом, обслуживающим эти залы. Следит за обеспечением чистоты залов, решает спорные вопросы по поводу расписания тренировок в этих залах. Следит за техническим состоянием помещений.
Заведующий тренажерным залом и залом для настольного тенниса является руководителем персонала, обслуживающего эти помещения. Производит контроль за исправностью тренажеров, столов для настольного тенниса, обеспечивает их сохранность. Следит за техническим состоянием помещений.
При выполнении выпускной квалификационной работы была поставлена задача автоматизации решения задач диспетчерской службы. Диспетчерская служба занимается сбором, обработкой, хранением, а также предоставлением требуемой информации о спортсменах, тренерах, расписании тренировок, месте их проведения и т.д. вышестоящим, подчиненным и взаимодействующим органам управления.
Диспетчерская служба взаимодействует с бухгалтерией, отделом кадров, отделом ИТ, а также с учебно-спортивным отделом.
1.2 Общие принципы разработки и функционирования систем автоматизации учебно-учетной деятельности
Автоматизация документооборота предполагает использование специального программного обеспечения для работы с документами и участие электронных документов в системе информационного обмена. При этом документы, создаваемые в ходе функционирования организации, обязательно регистрируются и хранятся в едином информационном пространстве. Обеспечивается коллективная работа с документами, то есть над каждым из них последовательно работает несколько сотрудников в соответствии со своими функциональными обязанностями. Сокращаются рутинные операции по заполнению документов, минимизируется вероятность ошибок, ускоряется процесс создания и корректировки документов, облегчается поиск, упрощается контроль исполнения, существенно возрастает оперативность работы с документами, налаживается взаимодействие с территориально удаленными подразделениями. Рынок систем электронного документооборота активно развивается, объективной основой этого процесса является широкое повсеместное использование персональных компьютеров и постоянно растущие требования к организации бизнеса.
Документы - это основные информационные ресурсы предприятия, работа с которыми требует правильной организации. Документы обеспечивают информационную поддержку принятия управленческих решений на всех уровнях и сопровождают ведение всех бизнес-процессов. Документооборот - это непрерывный процесс движения документов, объективно отражающий деятельность предприятия и позволяющий оперативно управлять им. Горы макулатуры, длительный поиск нужного документа, потери, дублирующие документы, задержки с отправкой и получением, ошибки персонала составляют не полный перечень проблем, возникающих при плохой организации документооборота. Все это может сильно затормозить, а в исключительных случаях полностью парализовать работу предприятия. Отдельно следует выделить проблемы предприятий, имеющих в своем составе территориально удаленные подразделения. Организовать сквозной документооборот, а значит и централизованное оперативное управление, в данном случае крайне затруднительно[1].
Эффективный документооборот является обязательной составляющей эффективного управления предприятием. Документооборот исключительно важен для правильной организации финансового и управленческого учета, его нельзя рассматривать в отрыве от специфических бизнес-процессов конкретного предприятия.
Упорядочивание документооборота должно начинаться с составления полного реестра используемых на предприятии документов. Для каждого типа документа определяется схема движения по этапам развития от момента его возникновения (создания или получения) до списания и отправки в архив. Каждый этап жизненного цикла документа досконально описывается (определяется сотрудник, ответственный за выполнение этапа, условия перехода к следующему этапу, устанавливаются связи с документом-основанием и дочерними документами). Такой подход позволяет оптимизировать документооборот, исключить дублирующие друг друга документы и операции, ускорить работу над документами.
Программные средства, используемые для автоматизации документооборота, достаточно условно можно разделить на четыре категории [2]:
Очевидной тенденцией развития систем автоматизации делопроизводства и документооборота является интеграция всех перечисленных систем. Основные функциональные возможности типовой системы данного класса можно определить следующим образом [2]:
Задачи, решаемые системами электронного документооборота. В современных условиях важной областью стало информационное обеспечение, которое состоит в сборе и переработке информации, необходимой для принятия обоснованных управленческих решений. Передача информации о положении и деятельности предприятия на высший уровень управления и взаимный обмен информацией между всеми взаимными подразделениями организации осуществляются на базе современной электронно-вычислительной техники и других технических средствах связи.
В деятельности государственных структур, представляющих собой комплексы большого числа повседневно связанных и взаимодействующих подразделений, передача информации является первостепенным и непременным фактором нормального функционирования данной структуры. При этом особое значение приобретает обеспечение оперативности и достоверности информации.
Информация служит основой для подготовки соответствующих докладов, отчетов, предложений для выработки и принятия соответствующих решений. Содержание каждой конкретной информации определяется потребностями управленческих звеньев и вырабатываемых управленческих решений.
Рассмотрим общий спектр задач электронного документооборота. Задачи и, соответственно, необходимая система автоматизации определяются стадией жизненного цикла документа, которую необходимо поддерживать. Жизненный цикл состоит из двух основных стадий. На первой стадии это разработка документа, которая может включать собственно разработку содержания документа, оформление документа, утверждение документа. В том случае если документ находится на стадии разработки, он считается неопубликованным, и права на него определяются правами доступа конкретного пользователя. Вторая стадия – это стадия опубликованного документа, которая может содержать: активный доступ, архивный документ краткосрочного и долгосрочного хранения, уничтожение документа.
Когда документ переходит на вторую стадию, он считается опубликованным, и на него остается только одно право - доступ на чтение. Кроме права доступа на чтение могут существовать права на перевод опубликованного документа в стадию разработки.
Комплекс задач автоматизации документооборота должен обладать следующими функциональными возможностями, поддерживающими основные задачи и функции делопроизводства [3]:
К системам электронного документооборота (СЭД) предъявляются такие требования как масштабируемость, распределенность, модульность и открытость.
Масштабируемость. Желательно, чтобы система документооборота могла поддерживать как пять, так, и пять тысяч пользователей, и ее способность наращивать мощность определялась только мощностью аппаратного обеспечения, на котором она установлена. Выполнение этого требования может быть обеспечено с помощью поддержки индустриальных серверов баз данных, производства, которые существуют практически на всех возможных программно-аппаратных платформах, обеспечивая тем самым максимально широкий спектр производительности.
Распределенность. Основные проблемы при работе с документами возникают в территориально-распределенных организациях, поэтому архитектура системы документооборота должна поддерживать взаимодействие распределенных площадок. Причем они могут быть объединены самыми разнообразными по скорости и качеству каналами связи. Также архитектура системы обязана обеспечивать взаимодействие с удаленными пользователями.
Модульность. Вполне возможно, что заказчику может не потребоваться сразу внедрение всех компонентов системы документооборота, а иногда круг решаемых заказчиком задач меньше всего спектра задач документооборота. Поэтому очевидно, что система должна состоять из отдельных модулей, интегрированных между собой.
Открытость. Система документооборота не может и не должна существовать в отрыве от других приложений, к примеру, часто необходимо интегрировать систему с прикладной бухгалтерской программой. Следовательно, система документооборота должна иметь открытые интерфейсы для возможной доработки и интеграции [3].
Основные принципы внедрения СЭД. Автоматизация документооборота, на сегодняшний день, стала не просто средством оптимизации внутренних процессов организации, а насущной необходимостью в условиях жесткой конкуренции. Именно автоматизация документооборота дает новые возможности любой организации по ускорению работы, позволяет опередить конкурентов при принятии как оперативных, так и стратегических решений. Автоматизация документооборота также необходима, как автоматизация бухгалтерского учета в середине девяностых годов. Причин этому много. Во-первых, информацию необходимо обрабатывать как можно быстрее и качественнее, подчас информационные потоки не менее важны, чем материальные. Во-вторых, утеря информации или ее попадание в чужие руки может обойтись весьма дорого. Можно выделить ряд проблем, общих для тех, организаций, где работа с документами ведется традиционным способом [4]:
В каждой организации сложилась своя практика работы с документами, соглашения об единых правилах организации технологии и управлении. Эффективность – одно из наиболее общих экономических понятий. Эффективность можно определить как вероятность достижения цели. Цели внедрения системы электронного документооборота [5]:
Таким образом, можно определить эффективность использования системы электронного документооборота (СЭД) в узком смысле для отдельных производств и пользователей. В этом случае разумно рассматривать следующие виды эффектов [5]:
Начать процесс автоматизации работы с документами следует с изучения теоретических аспектов автоматизации. Рабочая группа из специалистов по делопроизводству и информационных технологий проводит системный анализ существующего порядка работы с документами, детально изучив все документопотоки в спортивном учреждении, функциональные обязанности работников, связанные с делопроизводством. Рабочими материалами такого анализа являются схемы и таблицы, описывающие документопотоки и виды деятельности на каждом участке делопроизводства. Работа по обследованию завершается итоговым документом, проектом системы делопроизводства и электронного документооборота, в котором прописаны цели, задачи, функции и структура информационной системы, как в целом, так персонально для каждого отдела. В проекте системы делопроизводства и электронного документооборота предполагается единая автоматизация всех рабочих мест работников ответственных за делопроизводство и документооборот. На основе созданного проекта системы делопроизводства и электронного документооборота можно или написать техническое задание на разработку системы автоматизации делопроизводства и документооборота под индивидуальный заказ, или найти уже готовую систему.
В результате внедрения системы электронного документооборота удается достичь:
Экономическая эффективность. В последнее время вопросы экономической эффективности систем автоматизации поднимаются все чаще и чаще. Количественно оценить экономическую эффективность от внедрения системы автоматизации достаточно сложно, так как приходится учитывать большое количество факторов и обрабатывать значительный объем информации. Чем сложнее и масштабнее система, тем сложнее количественно оценить ее экономическую эффективность. На основе эмпирических данных путем экспертного анализа в сочетании с факторным можно достаточно точно оценить экономический эффект, но мы не будет останавливаться на математических выкладках и попробуем выделить основные факторы, влияющие на экономический эффект. При рассмотрении вопросов о необходимости внедрения систем электронного документооборота мы выделили основные выгоды, которые получает организация от внедрения системы. Если система выбрана правильно и процесс внедрения прошел успешно, то за счет сокращения времени на выполнения рутинных операций по работе с документами сотрудники организации могут более эффективно использовать рабочее время и выполнять больший объем работ. Сложные системы позволяют оптимизировать деятельность отдельных подразделений и всей организации в целом. Многие системы позволяют получать аналитическую информацию, которая используется для принятия многих важных управленческих решений. Существуют и другие, не менее важные выгоды, которые даст система автоматизации. Эти выгоды не всегда проявляются в явном виде, но они, безусловно, также влияют на эффективность деятельности организации в целом - повышается уровень профессиональной подготовки персонала, растут амбиции сотрудников, прививается культура использования современных информационных технологий. Отдельного рассмотрения заслуживает стоимость систем. Стоимость системы зависит от нескольких факторов: класса системы, функциональных и технологических возможностей системы-представителя определенного класса, масштаба внедряемой системы. Стоимость системы складывается не только из стоимости лицензий программного обеспечения – работы, проводимые на том или ином этапе процесса внедрения, также потребуют средств, причем сумма, потраченная на внедрение, может значительно превышать суммарную стоимость лицензий необходимого программного обеспечения. Следующим весьма важным фактором, влияющим на конечную стоимость системы, является величина расходов на эксплуатацию, сопровождение и техническую поддержку системы. Таким образом, можно сказать, что внедрение системы электронного документооборота дает значительный экономический эффект, однако количественная его оценка является сложным процессом, так как приходится учитывать множество факторов. Экономический эффект в значительной степени определяется правильностью выбора системы и проведения процесса внедрения [6].
1.3 Сравнительный анализ инструментальных средств построения систем автоматизации учебно-учетной деятельности
Возможный состав программных инструментальных и технологических средств, ориентированных на управление документами и документооборотом, а также средств реализации процедур работы с документами может быть представлен следующим образом:
Программные технологические пакеты, ориентированные на управление документами и документооборотом, должны быть открытыми для интеграции с приложениями, реализующими специфические функции, характерные при работе с документами на предприятии. Инструментальные средства для разработки приложений должны быть такими, чтобы приложения, разработанные с их помощью, интегрировались в программную среду управления документами и документооборотом. Далее рассмотрим несколько базовых систем электронного документооборота, являющимися основными лидерами на российском рынке, которые составят серьезную конкуренцию разработанному программному продукту.
Во-первых, это система DocsVision, которая решает следующие задачи управления документами и процессами:
Система автоматически собирает информацию о текущем состоянии обработки задания. В карточке задания отображается информация о текущем статусе обработки задания, проценте исполнения, комментариях, внесенных исполнителем, добавленных или обновленных файлах. Система позволяет также вносить информацию в карточку задания вручную в том случае, если задание не маршрутизируется. Система обеспечивает возможности автоматизации более сложных процессов обработки документов. Карточка процесса содержит специальный раздел - "Параметры процесса". При разработке шаблона процесса пользователь имеет возможность описать параметры конкретного процесса. При создании карточки экземпляра процесса пользователь может зафиксировать значения конкретных параметров процесса.
Система обеспечивает средства поддержки периодических процедур обработки документов, например, подготовку ежемесячных отчетов. Для реализации этого сценария необходимо указать периодичность выполнения задания при его описании и сохранить карточку задания в папке. Система будет периодически запускать сценарий по обработке указанного документа. Описание периодичности аналогично описанию периодического задания в Microsoft Outlook.
Система может использоваться для организации одноразовой или периодической рассылки широковещательной информации, например прайс-листов компании. Для этого необходимо завести карточку прайс-листа и периодическое задание, указав в качестве исполнителей группу, которой адресована рассылка. При этом указать тип маршрутизации - обычные сообщения. В качестве текста задания указать содержимое сообщения. Для реализации сценария необходимо только своевременно обновлять прайс-лист. Приложение DocsVision «Управление архивом документов» предназначено для автоматизации процессов формирования, учёта выдачи-возврата и хранения дел, содержащих бумажные экземпляры документов, вышедших из оперативного делопроизводства, и может использоваться для решения следующих задач:
Процесс формирования дел и архивирования документов, поддерживаемый приложением «Управление архивом документов», представлен на рисунке 1.2
Рисунок 1.2 - Формирование дел и архивирование документов
Ведение номенклатуры дел (блок 1) (ведение справочника номенклатуры дел) – процесс, заключающийся в составлении систематизированного перечня заголовков (наименований) дел, с указанием сроков их хранения, оформленный в установленном порядке. Формирование дел и томов (блок 2) – процесс формирования дел с вложенными томами и присвоения им порядковых номеров. Списание документов в дела (блок 3) – процесс помещения документа в дело, согласно номенклатуре дел. Передача дел во временное пользование (блок 4) – до закрытия дел документы в составе этих дел могут передаваться во временное пользование. Архивирование дел (блок 5) производится после их закрытия и составления, согласования и утверждения описи дел на передачу в архив. Передача дел в подразделения (блок 6) – процесс передачи и приёма дел, хранящихся в архиве, для работы в подразделениях. Передача дел на постоянное хранение (блок 7) – процесс формирования, согласования и утверждения описей дел для передачи в фонды постоянного хранения. Уничтожение документа в архиве (блок 8) – процесс формирования, согласования и утверждения описей дел на уничтожение.
Наряду с этим, приложение «Управление архивом документов» обеспечивает возможность оперативного поиска дел, томов, документов, переданных в архив.
Во-вторых, DIRECTUM – система электронного документооборота и управления взаимодействием, нацеленная на повышение эффективности работы всех сотрудников организации в разных областях их совместной деятельности.
DIRECTUM является полноценной ECM-системой (Enterprise Content Management) и поддерживает полный жизненный цикл управления документами, при этом традиционное «бумажное» делопроизводство органично вписывается в электронный документооборот. DIRECTUM обеспечивает эффективную организацию и контроль деловых процессов на основе workflow: согласование документов, обработка сложных заказов, подготовка и проведение совещаний, поддержка цикла продаж и других процессов взаимодействия. Развитие системы идет в рамках концепции "Переход на электронный документооборот - легче, быстрее, доступнее".
Решение описанных задач обеспечивают модули системы DIRECTUM. Управление электронными документами. Создание и хранение различных неструктурированных документов (тексты Microsoft Word, таблицы Microsoft Excel, схемы Microsoft Visio, рисунки CorelDraw, видео и пр.); расширенная поддержка версий документов и ЭЦП; структурирование документов по папкам; назначение прав доступа на документы; история работы с документами; полнотекстовый и атрибутивный поиск документов.
Управление деловыми процессами. Поддержка процессов согласования и обработки документов на всех стадиях жизненного цикла (docflow); выдача электронных заданий и контроль их исполнения; взаимодействие между сотрудниками в ходе бизнес-процессов; поддержка свободных и жестких маршрутов; богатые расширяемые библиотеки блоков для формирования маршрутов (workflow).
Управление договорами. Организация процесса согласования и регистрации договоров и сопутствующих документов, а также оперативной работы с ними (поиск, анализ, редактирование и т.д.).
Управление совещаниями. Организация подготовки и проведения совещаний (согласование места и времени, состава участников, повестки); формирование и рассылка протокола; контроль исполнения решений совещания.
Канцелярия. Регистрация бумажных документов в соответствии с требованиями Государственной системы документационного обеспечения управления (ГСДОУ); ведение номенклатуры дел с гибкими правилами нумерации; рассылка и контроль местонахождения бумажных документов; организация обмена электронными документами с ЭЦП с другими организациями.
Управление взаимодействием с клиентами. Ведение единой базы организаций и контактных лиц; ведение истории встреч, звонков и переписки с клиентами; сопровождение процесса продаж в соответствии с регламентированными стадиями; планирование маркетинговых мероприятий; анализ эффективности продаж и маркетинговых воздействий.
Архитектура и технические возможности системы DIRECTUM. Архитектура системы DIRECTUM позволяет создавать масштабируемые, надежные и безопасные корпоративные решения для управления документами, бизнес-процессами, совещаниями, договорами и взаимодействием с клиентами.
Адаптация системы DIRECTUM к специфическим нуждам организации и развитие системы вместе с ростом потребностей бизнеса обеспечивается возможностями инструмента разработки IS-Builder, который предлагает развитые средства быстрого и удобного создания новых справочников, карточек электронных документов, сценариев, экранных форм, типовых маршрутов, их отдельных блоков и других компонентов корпоративной системы электронного документооборота.
Интеграция системы DIRECTUM с ERP-системами, корпоративными порталами и другими составными частями ИТ-инфраструктуры организации возможна по различным направлениям, благодаря развитым интеграционным возможностям платформы DIRECTUM на базе набора средств интеграции DIRECTUM Integration Toolset и открытой архитектуре.
Территориально распределенная работа крупных организаций поддерживается сервером репликации, который обеспечивает прозрачный для пользователей и разработчика обмен данными – документами, задачами, заданиями, справочниками – между подразделениями организации.
Работа с DIRECTUM через Интернет и в Интранет реализована в DIRECTUM по нескольким направлениям. Сервер веб-доступа обеспечивает работу пользователей с документами и задачами DIRECTUM через интерфейс браузера, а Расширения DIRECTUM для SharePoint предлагают специализированный интерфейс доступа к данным системы DIRECTUM через корпоративный портал.
Обмен документами между сторонними организациями возможен благодаря специальным механизмам DIRECTUM, позволяющим передавать и контролировать доставку официальной корреспонденции в электронном виде на основе отраслевого формата обмена электронными документами. Обмен электронными документами между организациями-партнерами, даже в случае отсутствия системы электронного документооборота у любой из сторон, возможен с помощью программы DIRECTUM OverDoc на основе специально разработанного формата структурированного электронного документа.
Инструменты администрирования DIRECTUM позволяют управлять всеми задачами администрирования – от регистрации пользователей до создания политик миграции документов между файловыми хранилищами.
Технические требования к серверам, оборудованию рабочих станций и системному программному обеспечению отличаются гибкостью и позволяют эффективно использовать оборудование для работы DIRECTUM.
В-третьих, это система «ЕВФРАТ-Документооборот», основными функциями которой являются:
Система «ЕВФРАТ-Документооборот» позволяет полностью воспроизвести и оптимизировать процессы прохождения документов и задач в организации за счет гибкого механизма проектирования маршрутов. Система поддерживает технологию workflow и предоставляет следующие возможности:
Расширенные возможности работы с электронной почтой и Интернет облегчают деятельность сотрудников и обеспечивают следующее:
Развитые средства адаптации системы «ЕВФРАТ-Документооборот» позволяют самостоятельно настроить ее с учетом специфики организации и осуществить запуск в эксплуатацию.
«Дизайнер форм» позволяет создавать свои собственные регистрационные карточки для дальнейшего использования их при регистрации и учете документов в системе;
«Графический дизайнер маршрутов» позволяет проектировать типовые процессы обработки документов в организации;
«Менеджер журналов и отчетов» позволяет создавать новые шаблоны журналов и отчетов для осуществления анализа деятельности организации.
Уникальной особенностью системы «ЕВФРАТ-Документооборот» является входящая в комплект поставки встроенная СУБД Ника, поэтому система не требует дополнительных вложений в приобретение лицензий и поддержку сторонней базы данных.
«ЕВФРАТ-Документооборот» не требует особых условий установки и эксплуатации, не нуждается в покупке и внедрении дополнительного программного обеспечения сторонних разработчиков («Генератор отчетов», «Модуль морфологии» и др.). Гибкость и простота настройки позволяют пользователям с помощью средств адаптации и встроенного инструментария своевременно модернизировать систему в зависимости от изменений российского законодательства и деловой практики.
На данный момент, все вышеперечисленные системы являются ведущими системами автоматизированного документооборота, но специалистами так и не достигнуто однозначного соглашения, что делать со старыми бумажными документами, каким образом организовать использование старых данных, чтобы не утратить специфических свойств оригинальных документов. По результатам обследования ДЮСШ, как объекта автоматизации получены следующие выводы. Проблема информатизации ДЮСШ может быть решена путем создания автоматизированной информационной системы. В качестве одной из ее подсистем может выступать система документооборота, автоматизирующая основные процессы по подготовке, обработке, хранению, поиску и обмену документами, циркулирующими в организации. В качестве программной платформы для реализации разработки автоматизированной системы документооборота ДЮСШ, можно использовать вышеупомянутые системы, как наиболее удовлетворяющие требованиям заказчика и разработчика по своим функциональным возможностям, но необходимы доработки, связанные с обеспечением высокой доступности информации и повышением оперативности.
1.4 Цель и задачи дипломного проектирования
Целью дипломного проектирования является разработка элементов информационной системы автоматизации документооборота в спортивной школе. Для достижения поставленной цели необходимо решить следующие задачи:
2 Разработка информационного обеспечения системы автоматизации учебно-учетной деятельности в спортивной школе
В настоящее время существенной проблемой является возрастание объемов взаимосвязанных данных, необходимых для решения коммерческих и административных задач. Взаимосвязанные данные называют информационной системой. Такая система в первую очередь призвана облегчить труд человека, но для этого она должна как можно лучше соответствовать очень сложной модели реального мира.
Ядром информационной системы являются хранимые в ней данные. На любом предприятии данные различных отделов, как правило, пересекаются, то есть используются в нескольких подразделениях или вообще являются общими. Например, для целей управления часто нужна информация по всему предприятию. Хранящиеся в информационной системе данные должны быть легко доступны в том виде, в каком они нужны для конкретной производственной деятельности предприятия [7].
Построение информационных систем основывается на понятиях теории баз данных.
Предметной областью называется часть реальной системы, представляющая интерес для данного исследования.
При проектировании автоматизированных информационных систем предметная область отображается моделями данных нескольких уровней. Число используемых уровней зависит от сложности системы, но в любом случае включает логический и физический уровни. Предметная область может относиться к любому типу организации (например, банк, университет, малое предприятие или завод).
Необходимо различать полную предметную область (предприятие) и организационную единицу этой предметной области. Организационная единица в свою очередь может представлять свою предметную область (отделы).
Информация, необходимая для описания предметной области, зависит от реальной модели и может включать сведения о персонале, заработной плате, товарах, накладных, счетах, отчетах по сбыту, то есть сведения о людях, местах, предметах, событиях и понятиях.
Объектом называется элемент информационной системы, информацию о котором мы сохраняем. В реляционной теории баз данных объект называется сущностью.
Объект может быть реальным (например, человек, какой-либо предмет или населенный пункт) и абстрактным (например, событие, счет покупателя или изучаемый студентами курс). Так, для складского учета примерами объектов могут служить поставщик, товар, получение и т. д. Каждый объект обладает набором определенных свойств, которые запоминаются в информационной системе. При обработке данных часто приходится иметь дело с совокупностью однородных объектов, например служащие, и записывать информацию об одних и тех же свойствах для каждого из них.
Объекты и их свойства являются понятиями реального мира. Для информационного пространства употребляется понятие атрибута объекта.
Атрибут – это информационное отображение свойств объекта. Каждый объект характеризуется рядом основных атрибутов. Например, сотрудник предприятия имеет такие атрибуты, как фамилию, имя, отчество, адрес и возможно идентификационный номер. Каждый атрибут в модели должен иметь уникальное имя – идентификатор. Атрибут при реализации информационной модели на каком-либо носителе информации часто называют элементом данных, полем данных или просто полем. Взаимосвязь между перечисленными выше понятиями проиллюстрирована на рисунке 2.1. Таблица – это некоторая регулярная структура, состоящая из конечного набора однотипных записей. Каждая запись одной таблицы состоит из конечного числа полей, причем конкретное поле каждой записи одной таблицы может содержать данные только одного типа [8].
Рисунок 2.1 – Взаимосвязь
Значение данных представляет собой действительные данные, содержащиеся в каждом элементе данных. В зависимости от того, как элементы данных описывают объект, их значения могут быть количественными, качественными или описательными.
Информацию о некоторой предметной области можно представить с помощью нескольких объектов, каждый из которых описывается несколькими элементами данных. Принимаемые элементами данных значения называются данными. Единичный набор принимаемых элементами данных значений называется экземпляром объекта. Объекты связываются между собой определенным образом. Соответствующая модель объектов с составляющими их элементами данных и взаимосвязями называется концептуальной моделью. Концептуальная модель дает общее представление о потоке данных в предметной области.
Некоторые элементы данных обладают важным для построения информационной модели свойством. Если известно значение, которое принимает такой элемент данных объекта, мы можем идентифицировать значения, которые принимают другие элементы данных этого же объекта.
Ключевым элементом данных называется такой элемент, по которому можно определить значения других элементов данных.
Однозначно идентифицировать объект могут два и более элемента данных. В этом случае их называют «кандидатами» в ключевые элементы данных. Вопрос о том, какой из кандидатов использовать для доступа к объекту, решается разработчиком системы. Выбирать ключевые элементы данных следует тщательно, поскольку правильный выбор способствует созданию достоверной концептуальной модели данных.
Первичные ключ – это атрибут (или группа атрибутов), которые единственным образом идентифицируют каждую строку в таблице.
Понятие первичного ключа является исключительно важным в связи с понятием целостности баз данных.
Внешним ключом называется атрибут или группа атрибутов одного отношения, которым назначена ссылка на первичный ключ другого отношения, для однозначного его применения.
Альтернативный ключ – это атрибут (или группа атрибутов), несовпадающий с первичным ключом и уникально идентифицирующий экземпляр объекта. Например, для объекта «служащий», который имеет атрибуты «ИДЕНТИФИКАТОР», «ФАМИЛИЯ», «ИМЯ», «ОТЧЕСТВО», группа атрибутов «ФАМИЛИЯ», «ИМЯ», «ОТЧЕСТВО» может являться альтернативным ключом по отношению к атрибуту «ИДЕНТИФИКАТОР».
Запись данных – это совокупность значений связанных элементов данных. Записи хранятся на некотором носителе, в качестве которого может выступать человеческий мозг, лист бумаги, память ЭВМ, внешнее запоминающее устройство и т.д. Тип данных характеризует вид хранящихся данных. В современных базах данных допускается хранение символьных, числовых данных, битовых строк, специализированных числовых данных (например, суммы в денежных единицах), а также данных специального формата (дата, время, временной интервал и т.д.). В любом случае при выборе типа данных необходимо учитывать возможности системы управления базами данных (СУБД), с помощью которой реализуется физическая модель информационной системы (рисунок 2.2).
Доменом называется набор значений элементов данных одного типа, отвечающий поставленным условиям.
В самом общем виде домен определяется заданием некоторого базового типа данных, к которому относятся элементы домена, и произвольного логического выражения, применяемого к элементу типа данных, который «забраковывает» недопустимые значения. Если вычисление этого логического выражения дает результат «истина», то элемент данных является элементом домена. Понятие домена может также характеризоваться как потенциальное множество допустимых значений одного типа. Необходимо также помнить о том, что в данном случае данные являются сравнимыми, если они относятся к одному домену [8].
Рисунок.2.2- Типы данных
Представление – это сохраняемый в базе данных именованный запрос на выборку данных (из одной или нескольких таблиц).
Результатом выполнения любого запроса на выборку данных является таблица, и поэтому концептуально можно относиться к любому представлению как к таблице.
Связь – это функциональная зависимость между сущностями. Если между некоторыми сущностями существует связь, то факты из одной сущности ссылаются или некоторым образом связаны с фактами из другой сущности.
Поддержание непротиворечивости функциональных зависимостей между сущностями называется ссылочной целостностью. Поскольку связи содержатся «внутри» реляционной модели, реализация ссылочной целостности может выполняться как приложением, так и самой системой управления базами данных (СУБД) с помощью механизмов декларативной ссылочной целостности и триггеров.
Связи могут быть представлены пятью основными характеристиками [8]:
Связь называется идентифицирующей, если экземпляр дочерней сущности идентифицируется (однозначно определяется) через ее связь с родительской сущностью. Атрибуты, составляющие первичный ключ родительской сущности, при этом входят в первичный ключ дочерней сущности. Дочерняя сущность при идентифицирующей связи всегда является зависимой.
Связь называется не идентифицирующей, если экземпляр дочерней сущности идентифицируется иначе, чем через связь с родительской сущностью. Атрибуты, составляющие первичный ключ родительской сущности, при этом входят в состав не ключевых атрибутов дочерней сущности.
Мощность связи представляет собой отношение количества экземпляров родительской сущности к соответствующему количеству экземпляров дочерней сущности. Для любой связи, кроме неспецифической, эта связь записывается как 1:n.
Сущности, между которыми существуют связи, называются участниками, а число участников связи – размерностью связи. Большинство связей между сущностями – это двойные связи, то есть такие, в которых участвуют две сущности. Встречаются также унарные связи (в которых сущность связана сама с собой) и тройные связи (в которых участвуют три сущности).
Существует три основных типа связей [8].
Нормализация отношений – это процесс построения оптимальной структуры таблиц и связей в реляционной базе данных.
В процессе нормализации элементы данных группируются в таблицы, представляющие объекты и их взаимосвязи. Теория нормализации основана на том, что определенный набор таблиц обладает лучшими свойствами при включении, модификации и удалении данных, чем все остальные наборы таблиц, с помощью которых могут быть представлены те же самые данные.
Словарь данных – это централизованное хранилище сведений об объектах, составляющих их элементах данных, взаимосвязях между объектами, их источниках, значениях, использовании и форматах представления.
При проектировании системы обработки данных именно данные и интересуют нас в первую очередь. Причем больше всего нас интересует организация данных. Для понимания организации данных вводится понятие информационной модели.
Система автоматизированной обработки данных основывается на использовании определенной модели данных или информационной модели. Модель данных отражает взаимосвязи между объектами.
Процесс создания информационной модели начинается с определения концептуальных требований ряда пользователей. Концептуальные требования могут определяться и для некоторых задач (приложений), которые в ближайшее время реализовывать не планируется. Это может несколько повысить трудоемкость работы, однако поможет наиболее полно учесть все нюансы функциональности, требуемой для разрабатываемой системы, и снизит вероятность ее переделки в дальнейшем. Требования отдельных пользователей интегрируются в едином «обобщенном представлении». Последнее называют концептуальной моделью.
Концептуальная модель представляет объекты и их взаимосвязи без указания способов их физического хранения.
Таким образом, концептуальная модель является, по существу, моделью предметной области. При проектировании концептуальной модели все усилия разработчика должны быть направлены в основном на структуризацию данных и выявление взаимосвязей между ними без рассмотрения особенностей реализации и вопросов эффективности обработки. Проектирование концептуальной модели основано на анализе, решаемых на этом предприятии задач по обработке данных. Концептуальная модель включает описания объектов и их взаимосвязей, представляющих интерес в рассматриваемой предметной области и выявляемых в результате анализа данных.
Концептуальная модель транслируется затем в модель данных, совместимую с выбранной СУБД. Возможно, что отраженные в концептуальной модели взаимосвязи между объектами окажутся впоследствии нереализуемыми средствами выбранной СУБД. Это потребует изменения концептуальной модели. Версия концептуальной модели, которая может быть обеспечена конкретной СУБД, называется логической моделью [8].
Логическая модель отражает логические связи между элементами данных вне зависимости от их содержания и среде хранения.
Логическая модель данных может быть реляционной, иерархической или сетевой. Пользователям выделяются подмножества этой логической модели, называемые внешними моделями, отражающие их представления о предметной области. Внешняя модель соответствует представлениям, которые пользователи получают на основе логической модели, в то время как концептуальные требования отражают представления, которые пользователи первоначально желали иметь и которые легли в основу разработки концептуальной модели. Логическая модель отображается в физическую память, такую, как диск, лента или какой-либо другой носитель информации.
Физическая модель, определяющая размещение данных, методы доступа и технику индексирования, называется внутренней моделью системы.
Внешние модели никак не связаны с типом физической памяти, в которой будут храниться данные, и с методами доступа к этим данным. Это положение отражает первый уровень независимости данных. С другой стороны, если концептуальная модель способна учитывать расширение требований к системе в будущем, то вносимые в нее изменения не должны оказывать влияния на существующие внешние модели. Это – второй уровень независимости данных. Построение логической модели обусловлено требованиями используемой СУБД.
Все актуальные требования предметной области и адекватные им «скрытые» требования на стадии проектирования должны найти свое отражение в концептуальной модели. Конечно, нельзя предусмотреть все возможные варианты использования и изменения базы данных. Но в большинстве предметных областей такие основные данные, как объекты и их взаимосвязи, относительно стабильны. Меняются только информационные требования, то есть способы использования данных для получения информации.
Степень независимости данных определяется тщательностью проектирования базы данных. Всесторонний анализ объектов предметной области и их взаимосвязей минимизирует влияние изменения требований к данным в одной программе на другие программы. В этом и состоит всеобъемлющая независимость данных.
Способ, с помощью которого сущности, атрибуты и связи отображаются на структуры, определяется логической моделью данных. Всего выделяют три основных модели: иерархическую, сетевую и реляционную модели данных.
Иерархическая и сетевая модели данных стали применяться в системах управления базами данных в начале 60-х годов. В начале 70-х годов была предложена реляционная модель данных. Эти три модели различаются в основном способами представления взаимосвязей между объектами.
Иерархическая модель данных строится по принципу иерархии типов объектов, то есть один тип объекта является главным, а остальные, находящиеся на низших уровнях иерархии, - подчиненными. Между главным и подчиненными объектами устанавливается взаимосвязь «один ко многим». Иными словами, для данного главного типа объекта существует несколько подчиненных типов объектов. В то же время для каждого экземпляра главного объекта может быть несколько экземпляров подчиненных типов объектов.
Узлы и ветви образуют иерархическую древовидную структуру. Узел является совокупностью атрибутов, описывающих объект. Наивысший в иерархии узел называется корневым (это главный тип объекта). Корневой узел находится на первом уровне. Зависимые узлы (подчиненные типы объектов) находятся на втором, третьем и др. уровнях.
В сетевой модели данных понятия главного и подчиненного объектов несколько расширены. Любой объект может быть и главным и подчиненным (в сетевой модели главный объект обозначается термином «владелец набора», а подчиненный – термином «член набора»). Один и тот же объект может одновременно выступать и в роли владельца и в роли члена набора. Это означает, что каждый объект может участвовать в любом числе взаимосвязей.
В реляционной модели данных объекты и взаимосвязи между ними представляются с помощью таблиц. Взаимосвязи также рассматриваются в качестве объектов. Каждая таблица представляет один объект и состоит из строк и столбцов. В реляционной базе данных каждая таблица должна иметь первичный ключ (ключевой элемент) – поле или комбинацию полей, которые единственным образом идентифицируют каждую строку в таблице. Благодаря своей простоте и естественности представления реляционная модель получила наибольшее распространение в СУБД для персональных компьютеров.
Реляционная модель данных была разработана Коддом еще в 1969-70 годах на основе математической теории отношений и опирается на систему понятий, важнейшими из которых являются таблица (отношение), строка (кортеж), столбец (атрибут), первичный ключ, внешний ключ. Реляционная модель – множественное отношение, которое представляет собой подмножество декартова произведения списка доменов. Домен – это множество значений, из которого извлекаются значения для данного атрибута. Другими словами в основе реляционной модели лежат простые таблицы, которые удовлетворяют определенным ограничениям, а потому могут рассматриваться как математические отношения. Строки таких таблиц называют кортежами, имена столбцов – атрибутами. Значения атрибутов выбираются из множества допустимых значений, которое называется доменом. Следует отметить, что все кортежи различны, а порядок столбцов произволен. В отношении (таблице) выделяются несколько атрибутов, однозначно идентифицирующих кортежи и называемых ключами. Для того чтобы, гарантировать корректность и взаимную непротиворечивость данных, на базу данных накладываются некоторые ограничения, которые называют ограничениями целостности. Существует несколько типов ограничений целостности. Требуется, например, чтобы значения в столбце таблицы выбирались только из соответствующего домена. На практике учитывают и более сложные ограничения целостности, например, целостность по ссылкам. Ее суть заключается в том, что внешний ключ не может быть указателем на несуществующую строку в таблице. Ограничения целостности реализуются с помощью специальных средств, таких как правила, домены [8].
Применение систем управления реляционными базами данных очень эффективно при автоматизации финансового звена малого коммерческого предприятия. Вышеизложенная теория и принципы управления реляционными базами данных могут быть с успехом применены в процессе автоматизации работы любого подразделения предприятия. Основные принципы реляционного подхода к структуре коммерческой базы данных обеспечивают наилучшее ее функционирование. Соблюдение принципов целостности, безопасности и независимости данных, что дает нам реляционная модель, позволяет организовать отказоустойчивую структуру данных, что так необходимо для правильного и непрерывного функционирования финансовых подразделений. Применение принципа нормализации к структуре данных дает высокую гибкость при проектировании пользовательского интерфейса и обеспечивает не избыточность данных, что особенно важно учитывая большой объем информации, обрабатываемый в повседневной работе подразделений.
Концептуальные модели наиболее полно отвечают потребностям проектирования баз данных. Выделяют: семантическую, фреймовую и модель «сущность-связь».
Семантическая модель основывается на построении семантической сети. Под семантической сетью понимают ориентированный граф, состоящий из помеченных вершин и дуг и задающий объекты и отношения предметной области. Семантические сети обладают рядом преимуществ, таких как: описание объектов предметной области происходит естественным языком; все записи, поступающие в БД, накапливаются в относительно однородной структуре. Но, несмотря на эти преимущества, семантическая модель данных обладает рядом недостатков, один из которых и наиболее существенный, заключается в том, что построение реляционной модели данных на основе семантических сетей затруднено.
Во фреймовой модели единицей представления знаний является объект, называемый фреймом. Фрейм – это минимальная структура информации, необходимая для представления класса объектов, явлений и процессов. Некоторые незаполненные подструктуры фрейма называются слотами. Их заполнение приводит к тому, что фрейм ставится в соответствие некоторой ситуации, явлению или объекту. В качестве значения слота может выступать имя другого фрейма, что приводит к образованию сети фреймов. Так же в качестве значения слота может использоваться программа процедурного типа. Присоединенная процедура запускается по сообщению, переданному из другого фрейма. Так же во фреймовой модели реализован механизм наследования фреймов. Механизм управления наследованием является основным механизмом управления выводом, которым оснащаются фреймовые системы. Описание реляционной БД данной моделью невозможно, так как модель не отражает типы связей в реляционной модели данных.
2.2 Формирование логической и концептуальной моделей структурирования данных с использованием CASE-средств
Модель «сущность-связь» описывается в терминах сущность, связь, значение. Сущность – понятие, которое может быть идентифицировано. Связь – соединение сущностей. Для представления связей и сущностей введен специальный метод: ER-диаграмма. Различаются сущности трех основных классов: стержневые, ассоциативные и характеристические. Стержневая сущность – это независимая сущность (ей свойственно независимое существование). Ассоциативная сущность или ассоциация рассматривается как связь между двумя или более сущностями типа «многие ко многим» или подобные им. Характеристическая сущность (или характеристика) представляет собой сущность, единственная цель которой, в рамках рассматриваемой предметной области, состоит в описании или уточнении некоторой другой сущности. ER-диаграмма – графическое представление взаимосвязей сущностей. Каждое множество сущностей представляется прямоугольником, а множество связей – ромбом.
Методология проектирования представляет собой поэтапное руководство, охватывающее три основных этапа проектирования баз данных: концептуальное, логическое и физическое проектирование.
Концептуальное проектирование – создание концептуального представления базы данных, включающее определение типов важнейших сущностей и существующих между ними связей и атрибутов.
Логическое проектирование – преобразование концептуального представления в логическую структуру базы данных, включая проектирование отношений.
Физическое проектирование – принятие решения о том, как логическая модель будет физически реализована (с помощью таблиц) в базе данных, создаваемой с использованием выбранной СУБД.
Прежде чем приступить к рассмотрению методологии, полезно узнать, что она собой представляет, в частности, как методология концептуального и логического проектирования базы данных связана с физическим проектированием.
Методология проектирования предусматривает разбиение всего процесса на несколько стадий, каждая из которых, в свою очередь, состоит из нескольких этапов. На каждом этапе разработчику предлагается набор технических приемов, позволяющих решать задачи, стоящие перед ним на данной стадии разработки. Кроме того, методология предлагает методы планирования, координации, управления, оценки хода разработки проекта, а так же структурированный подход к анализу и моделированию всего набора требований, предъявляемых к базе данных, и позволяет выполнить эти действия стандартизированным и организованным образом.
Концептуальное проектирование базы данных начинается с создания концептуальной модели данных предприятия, полностью независимой от любых деталей реализации. К последним относятся выбранный тип СУБД, состав программ приложения, используемый язык программирования, конкретная аппаратная платформа, вопросы производительности и любые другие физические особенности реализации.
Логическое проектирование базы данных заключается в преобразовании концептуальной модели данных в логическую модель данных предприятия с учетом выбранного типа СУБД. Логическая модель данных является источником информации для этапа физического проектирования. Она предоставляет разработчику физической модели данных средства проведения всестороннего анализа различных аспектов работы с данными, что имеет исключительно важное значение для выбора действительно эффективного проектного решения.
Физическое проектирование базы данных предусматривает принятие разработчиком окончательного решения о способах реализации создаваемой базы. Поэтому физическое проектирование обязательно производится с учетом всех особенностей СУБД. Между этапами физического и логического проектирования всегда имеется определенная обратная связь, поскольку решения, принятые на этапе физического проектирования с целью повышения производительности разрабатываемой системы, могут потребовать определенной корректировки логической модели данных.
Концептуальное и логическое проектирование базы данных включает три основных этапа. Задачей первого этапа является разбиение проекта на группу относительно небольших (и более простых) задач исходя из представлений о предметной области приложения, свойственных каждому из типов конечных пользователей. Результатом выполнения этого этапа является создание локальных концептуальных моделей данных, представляющих собой полное и точное отражение представлений о предметной области приложения отдельных типов пользователей. На втором этапе локальные концептуальные модели данных преобразуются в локальные логические модели данных (для реляционной модели данных), состоящие из ER-диаграммы, реляционной схемы и сопроводительной документации.
Затем корректность логических моделей данных проверяется с помощью правил нормализации. Нормализация представляет собой эффективное средство, позволяющее убедиться в структурной согласованности, логической целостности и минимальной избыточности принятой модели данных. Эти проверки позволяют получить необходимую уверенность в том, что принятая модель данных является вполне приемлемой.
По завершении второго этапа каждая локальная логическая модель данных при необходимости может применяться для подготовки прототипов реализаций базы данных, предназначенных для отдельных типов пользователей приложения.
На третьем этапе выполняется объединение локальных логических моделей данных (отражающих представление о предметной области отдельных типов пользователей) в единую глобальную логическую модель данных всего предприятия (обобщающую представления о предметной области всех типов пользователей).
При использовании методологии концептуального проектирования базы должна быть разработана концептуальная модель данных для каждого представления, охватывающего предметную область данного предприятия; такая модель данных называется локальной концептуальной моделью данных для рассматриваемого представления. В процессе анализа необходимо выявить все пользовательские представления, которые требуются для разрабатываемого приложения, и предусмотреть возможность объединения некоторых представлений для создания обобщенного представления, обозначенного соответствующим идентификатором, в зависимости от степени перекрытия отдельных представлений.
Первый этап создания локальной концептуальной модели данных состоит в определении основных объектов, которые могут интересовать пользователя. Эти объекты являются типами сущностей, входящих в модель. Один из методов идентификации сущностей состоит в изучении спецификаций по выполнению конкретных функций пользователя на данном предприятии. Из этих спецификаций следует извлечь все используемые в них существительные или сочетания существительного или прилагательного. Затем среди них выбираются самые значимые объекты или важные концепции и исключаются все существительные, которые просто определяют другие объекты.
В некоторых случаях выделение сущностей бывает затруднено из-за неудовлетворительного способа представления в спецификациях. Пользователи, излагая свои мысли, часто используют не однозначные определения, а примеры или аналогии.
После выделения сущностей следующим этапом разработки становится установление всех существующих между ними связей. Одним из методов определения сущностей является выборка всех существительных, присутствующих в спецификациях требований пользователей. И в этом случае для выявления связей необходимо провести грамматический анализ спецификации требований. Проектировщиков интересуют только те связи между сущностями, которые необходимы для удовлетворения требований к проекту.
В большинстве случаев связи являются двух сторонними, другими словами, связи существуют только между двумя сущностями. Однако следует проявлять особое внимание и тщательно проверять наличие в проекте сложных связей, объединяющих более двух сущностей различных типов, а так же рекурсивных связей, существующих между сущностями одного и того же типа.
Работа проектировщика существенно упрощается, если есть возможность изучить структуру сложной системы с помощью схемы, а не анализировать подробные текстовые описания спецификаций требований пользователей. Для представления сущностей и связей между ними обычно используются диаграммы «сущность-связь» (ER-диаграммы). Это позволяет всегда иметь под рукой наглядный образ моделируемой части предприятия [8].
На следующем этапе предлагаемой методологии необходимо выявить все данные, описывающие сущности и связи, выделенные в создаваемой модели базы данных.
Поскольку обычно количество атрибутов на много превышает количество сущностей и связей, может оказаться полезным сначала подготовить список всех атрибутов, используемых в спецификациях требований пользователей. По мере связывания очередного атрибута с некоторой сущностью или связью он вычеркивается из списка. Подобный метод позволяет гарантировать, что каждый из атрибутов будет связан с сущностью или связью только одного типа. Когда из списка будет вычеркнут последний атрибут, все идентифицированные в модели атрибуты окажутся связанными с некоторой сущностью или связью.
Следующий этап – это определение доменов атрибутов. Задача этого типа создание локальной концептуальной модели данных состоит в определении доменов атрибутов для всех атрибутов, присутствующих в модели. Доменом называется некоторое множество значений, элементы которого выбираются для присвоения значений одному или нескольким атрибутам.
Затем необходимо определить атрибуты, являющиеся потенциальными и первичными ключами. На этом этапе каждой сущности устанавливается потенциальный ключ (или ключи), после чего осуществляется выбор первичного ключа. Потенциальным ключом называется атрибут или минимальный набор атрибутов заданной сущности, позволяющий однозначно идентифицировать каждый ее экземпляр. Для некоторых сущностей возможно наличие нескольких потенциальных ключей. В этом случае среди них нужно выбрать один ключ, который будет называться первичным ключом. Все остальные потенциальные ключи будут называться альтернативными ключами.
На следующем этапе локальная концептуальная модель данных проверяется с конкретной целью: выявить наличие в ней избыточных данных и устранить этот недостаток, если он будет обнаружен. На этом этапе проводится исследование «один к одному» и удаление избыточных связей.
Целью применения методологии логического проектирования является создание локальной логической модели данных на основе локальной концептуальной модели данных, отражающей конкретное пользовательское представление о предметной области приложения, и проверка полученной модели с помощью методов нормализации и контроля выполнения транзакции.
На этом этапе каждая локальная концептуальная модель данных, созданная на первом этапе, преобразуется в локальную логическую модель данных, состоящую из ER-диаграммы, реляционной схемы и сопроводительной документации. Для упрощения этого процесса предусмотрен необязательный первый этап, на котором происходит устранение особенностей, которые не могут быть представлены непосредственно в реляционной модели (таких как связи «многие ко многим»).
Полученная реляционная схема проверяется с использованием правил нормализации для определения того, является ли ее структура правильной. Нормализация – это разбиение таблицы на две или более, обладающих лучшими свойствами при включении, удалении и изменении данных. Окончательная цель нормализации сводится к получению такого проекта базы данных, в котором каждый факт появляется лишь в одном месте, т.е. исключена избыточность информации. Выделяют три основных нормальных формы: 1НФ, 2НФ и 3НФ. Таблица находится в 1НФ тогда и только тогда, когда ни одна из ее строк не содержит в любом своем поле более одного значения и ни одно из ее ключевых полей не пусто. Таблица находится во 2НФ, если она удовлетворяет определению 1НФ и все ее поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом. Таблица находится в 3НФ, если она удовлетворяет определению 2Ф и не одно из ее не ключевых полей не зависит функционально от любого другого не ключевого поля.
Проверенная локальная логическая модель данных может применяться в качестве основы для разработки прототипов, если в этом есть необходимость.
При завершении этого типа должна быть получена правильная, полная и непротиворечивая модель представления. Если в приложении применяется только одно представление, то на этом стадия логического проектирования базы данных, предусмотренная в методологии, заканчивается. А если имеется несколько представлений, то должен быть выполнен еще один этап, на котором отдельные локальные логические модели данных объединяются в глобальную логическую модель данных организации.
Далее необходимо определить отношения исходя из структуры локальной логической модели данных. На данном этапе предстоит определить наборы отношений, необходимые для представления сущностей, связей и атрибутов, входящих в представления отдельных пользователей о предметной области приложения.
Связь между двумя сущностями отображается с использованием механизма «первичный ключ/внешний ключ». При определении того, в каком отношении должен находиться атрибут (атрибуты) внешнего ключа, необходимо вначале выяснить, какая из сущностей, участвующих в связи, является родительской, а какая дочерней. Родительской называется сущность, которая передает копию своего первичного ключа в отношение, представляющее дочернюю сущность, для использования в качестве внешнего ключа [8].
На следующем этапе моделирования необходимо проверить отношения с помощью правил нормализации. Нормализация используется для улучшения модели данных, чтобы она удовлетворяла различным ограничениям, позволяющим исключить нежелательное дублирование данных. Нормализация гарантирует, что полученная в результате ее применения, модель данных будет наилучшим образом отображать особенности использования информации в организации, не содержать противоречий, иметь минимальную избыточность и максимальную устойчивость.
Стадия, предшествующая физическому проектированию, называется стадией логического проектирования. Результаты ее выполнения в значительной степени зависимы от особенностей физической реализации проекта. При логическом проектировании не принимаются во внимание конкретные функциональные возможности целевой базы данных и прикладных программ, однако учитываются возможности выбранной модели данных.
Результатом логического проектирования являются глобальная логическая модель данных, состоящая из ER-диаграммы и диаграммы отношений, а так же реляционной схемы, и комплектописывающей ее сопроводительной документации, включающей, в частности, словарь данных. В совокупности эти результаты являются исходной информацией для стадии физического проектирования базы данных и представляет ее разработчику все необходимое для принятия решений, направленных на достижение максимальной эффективности создаваемого проекта. Образно говоря, при логическом проектировании разработчик в основном рассматривает, что должно быть сделано, а при физическом проектировании он ищет способ, как это сделать. В каждом случае требуется наличие различных навыков, которыми обладают разные специалисты. Так, специалист по физическому проектированию баз данных должен ясно представлять, как функционирует в компьютерной системе та или иная СУБД. Поскольку функциональные возможности различных СУБД достаточно сильно отличаются друг от друга, физическое проектирование всегда тесно связано с особенностями конкретной выбранной системы.
Однако этап физического проектирования базы данных не является совершенно изолированным от других. Как правило, между физическим, логическим проектированием и разработкой приложений всегда имеется обратная связь. Например, решение, принятое на этапе физического проектирования с целью повышения производительности системы (в частности, по объединению отношений), могут повлиять на структуру логической модели данных, а это может отразиться на проектах приложений.
Самым первым заданием на этапе физического проектирования баз данных является преобразование отношений, созданных на основе глобальной логической модели данных, в такую форму, которая может быть реализована в среде целевой СУБД. Первая часть этого процесса предусматривает проверку информации, собранной на этапе логического проектирования базы данных и помещенной в словарь данных. Вторая часть процесса заключается в использовании этой информации для разработки проекта основных отношений. Этот процесс требует наличия глубоких знаний о функциональных возможностях, предоставляемых целевой СУБД.
Одной из важнейших целей физического проектирования базы данных является организация эффективного хранения данных [8]. Например, если выборка строк с данными о сотрудниках компании должна выполняться по именам в алфавитном порядке, то наиболее подходящей структурой для хранения этих данных является файл, отсортированный по именам сотрудников. А если должна выполняться выборка данных обо всех сотрудниках, зарплата которых находится в определенном диапазоне, файл, отсортированный по именам сотрудников, не подходит для выполнения такой задачи. Положение еще более усложняется в связи с тем, что некоторые способы организации файлов хорошо подходят для массовой загрузки данных в базу данных, но их применение в дальнейшем становится не эффективным. Иными словами, задача состоит в использовании эффективной структуры хранения данных на внешнем устройстве, которая обеспечивает быструю загрузку базы данных, а затем ее преобразование в структуру, более подходящую для повседневной эксплуатации.
База данных представляет собой исключительно важный корпоративный ресурс и поэтому защита этого ресурса имеет исключительное значение. На стадии сбора и анализа требований, составляющей часть жизненного цикла приложения базы данных, должны быть учтены и отражены в спецификации требований к системе конкретные требования к защите. Назначение этого этапа состоит в определении способов реализации требований к защите. Состав средств защиты зависит от конкретной системы.
Среди многообразия средств моделирования систем в методологиях структурного анализа наиболее часто и эффективно применяются следующие диаграммы:
Все они содержат графические и текстовые средства моделирования системы: первые – для обеспечения точного определения ее компонентов и связей, вторые – для удобства демонстрирования функционирования основных компонентов модели.
DFD показывает внешние по отношению к системе источники и стоки (адресаты) данных, идентифицирует логические функции (процессы) и группы элементов данных, связывающих одну функцию с другой (потоки), а так же идентифицирует хранилища (накопители) данных, к которым осуществляется доступ. Структуры потоков данных и определения их компонентов хранятся и анализируются в базе данных. Каждая логическая функция (процесс) может быть детализирована с помощью DFD нижнего уровня. Содержимое каждого хранилища так же сохраняют в базе данных, модель которой раскрывается с помощью ERD.
Таким образом, строится логическая функциональная спецификация – подробное описание того, что должна делать система, освобожденная, насколько это возможно, от рассмотрения путей реализации, что дает проектировщику четкое представление о конечных результатах, которых нужно достигнуть.
Для проектирования описанных выше диаграмм используются CASE – средства (Computer Aided Software Engineering).
Для проектирования ERD используют программное средство ERwin, которое представляет собой набор средств концептуального моделирования данных. ERwin реализует проектирование схемы базы данных и генерацию ее описания на языке целевой СУБД.
Для проектирования DFD используется программное средство BPwin, которое является ведущим инструментом визуального моделирования бизнес-процессов. BPwin дает возможность наглядно представить любую деятельность или структуру в виде модели.
Для построения логической модели базы данных прежде всего, необходимо определить набор сущностей и задать связи между ними. Проведенный анализ поставленных перед комплексом задач, процессов, протекающих при выполнении этих задач и данных, необходимых для осуществления этих процессов, позволил составить структуры таблиц и связей между ними.
На основании анализа ниже приведены описания назначения каждой из таблиц, а так же их структуру.
Учебная группа – таблица, содержащая сведения о группе, обучающейся в спортивной школе (таблицу 2.1).
Тренера – преподаватели – таблица, содержащая данные о преподавателях (таблицу 2.2).
Ученики – таблица, содержащая индивидуальные данные об учащихся (таблицу 2.3).
Зачисление – таблица, содержащая информацию об состоянии учащегося школы (таблицу 2.4).
В таблицах заведомо указаны имена полей, которые будут использоваться при построении физической модели.
Таблица 2.1 – Сущность «Учебная группа»
|
Ключ |
Атрибут |
Имя в таблице «GROUP» |
Тип данных |
|
1 |
2 |
3 |
4 |
|
|
Код Вид Спорта Тренер Этап Подготовки Код Этапа Наименование |
ID VID_SPORTA TRENER ETAP_PODGOTOVKI ID_ETAPA NAIMENOVANIE |
Числовой Текстовый Текстовый Текстовый Числовой Счетчик |
Таблица 2.2 – Сущность «Тренеры»
|
Ключ |
Атрибут |
Имя в таблице «TRENERA» |
Тип данных |
|
1 |
2 |
3 |
4 |
|
|
Код ФИО Образование Специальность Вид Спорта |
ID_TRENERA FIO OBRAZOVANIE SPECIALNOST VID_SPORTA |
Счетчик Текстовый Текстовый Текстовый Текстовый |
Таблица 2.3 – Сущность «Ученики»
|
Ключ |
Атрибут |
Имя в таблице «UCHENIKI» |
Тип данных |
|
1 |
2 |
3 |
4 |
|
|
Код ученика Группа Вид спорта Тренер Этап Подготовки Состояние Код Этапа ФИО Адрес Контактный телефон Дата Рождения Школа Класс Приказ Дата Изменения |
ID_UCHENIKA GROUP VID_SPORTA TRENER ETAP_PODGOTOVKI SOSTOYANIE ID_ETAPA FIO ADDRESS PHONE DATE_ROZHDENIYA SCHOOL CLASS PRIKAZ DATE_IZMENENIYA |
Счетчик Текстовой Текстовой Текстовый Числовой Текстовый Счетчик Текстовый Текстовый Числовой Дата/время Числовой Числовой Текстовый Дата/время |
Таблица 2.4 – Сущность «Зачисление»
|
Ключ |
Атрибут |
Имя в таблице «ZACHISLENIE» |
Тип данных |
|
1 |
2 |
3 |
4 |
|
|
Номер Код Вид Спорта Тренер Этап Подготовки Код Этапа Дата Проведен Наименование Группа |
NOMBER ID VID_SPORTA TRENER ETAP_PODGOTOVKI ID_ETAPA DATE PROVEDEN NAIMENOVANIE GROUP |
Числовой Счетчик Текстовый Текстовый Числовой Счетчик Дата/время Текстовый Текстовый Числовой |
Структура разрабатываемой системы представлена на рисунке 2.3.
Рисунок 2.3 - Структурная схема базы данных.
Разработка контекстных диаграмм решает проблему строгого определения функциональной структуры базы данных на самой ранней стадии ее проектирования, что особенно важно для сложных многофункциональных систем.
Контекстная диаграмма с единственным процессом «Обучение» приведена на рисунке 2.4
Рисунок 2.4 – Контекстная диаграмма
Данные об учащихся включают в себя подробную информацию о будущем ученике спортивной школы. Она включает его фамилию, имя и отчество, контактные данные и какую-либо дополнительную информацию, если это необходимо. Нормативные документы определяют порядок составления и заключения договора.
Тренера - преподаватели осуществляют сам процесс обучения.
Документы о сдаче контрольно-переводных нормативов является выходным документом и выводится на печать.
После того, как построена контекстная диаграмма, строится полная модель системы, с отображением всех процессов и потоков данных, участвующих в основном процессе. DF-диаграмма первого уровня представлена на рисунке 2.5.
Рисунок 2.5 – DF-диаграмма первого уровня
3. Разработка программного обеспечения информационной системы автоматизации учебно-учетной деятельности в спортивной школе
3.1 Выбор языковых и программных средств реализации программного обеспечения
Для реализации дипломного проекта была выбрана система программирования Delphi, относящаяся к классу инструментальных средств ускоренной разработки программ (RAD).
Сокращение времени на разработку программ достигается за счет визуального конструирования форм и использования библиотеки визуальных компонентов (VCL).
Визуальное конструирование форм избавляет программиста от многих аспектов разработки интерфейса программы. Delphi создает специальное окно, называемое окном формы, которое является прототипом окна будущей программы. Программист наполняет это окно необходимыми ему компонентами.
Библиотека визуальных компонентов содержит большое количество компонентов, готовых к использованию. Компоненты уже содержат в себе необходимый программный код и данные.
Таким образом, использование компонентов позволяет сократить время разработки программы и снижает вероятность ошибок.
Язык программирования Delphi был создан на базе языка Паскаль. Delphi отличает мощность и гибкость, имеется возможность делать вставки на Assembler. При этом язык имеет очень простой и ясный синтаксис.
Система Delphi является эффективным средством разработки приложений баз данных. Delphi поддерживает большое количество технологий доступа к базам данных различных форматов.
Структурной единицей визуального программирования, основным «строительным элементом» для программы является компонент.
Компонент – это разновидность класса, который представлен пиктограммой на палитре компонентов Delphi, может быть визуально перенесен в программу и имеет набор свойств, которые можно определять, не изменяя текста программ. В этом суть визуального программирования. (В отличие от языка Turbo-Pascal, классом в Delphi называется объектовый тип переменных, а объектом называется экземпляр класса. Например, тип Student – это класс, а студент Иванов – конкретный объект, экземпляр класса).
Как и любой класс, компонент характеризуется полями, свойствами и методами. В Delphi вместо полей обычно используются свойства. Свойство можно рассматривать как разновидность поля класса, обращение к которому автоматически приводит к вызову метода чтения/записи поля.
Кроме того, компонент имеет перечень событий, на которые он способен реагировать (например, нажатие клавиши, щелчок кнопкой мыши и др.). Задача программиста – написать обработчики событий, отвечающие за реакцию компонента на определенное событие.
Компоненты бывают визуальными и невизуальными. Первые предназначены для организации интерфейса с пользователем (кнопки, строки редактирования, переключатели, списки и т.д.). Они видны на экране во время выполнения программы. Невизуальные компоненты служат для доступа к системным ресурсам, например, драйверам баз данных. Во время работы приложения они, как правило, не видны.
Формой называется визуальный компонент, имеющий свойства окна Windows (или просто окно Windows). На форме размещаются другие визуальные компоненты – кнопки, строки редактирования и др. Форм в приложении может быть несколько. Одна из них – главная. Закрытие главной формы означает завершение программы.
Каждая форма представлена двумя файлами – файлом визуального описания формы (бинарный файл с расширением .dfm) и модулем с исходным текстом на языке Pascal (текстовый файл с расширением .pas), содержащим обработчики событий для компонентов этой формы.
Формы и модули объединены в проект. Проект – это совокупность файлов, из которых Delphi создает приложение. Проект оформляется в виде головной программы на Паскале, содержащей ссылки на файлы всех форм и модулей. Файл проекта имеет расширение .dpr.
В качестве средств разработки специального программного обеспечения была выбрана система Delphi 7. Выбор обуславливается тем, что с ее помощью можно в кратчайшие сроки разработать быстрое, компактное и полноценное Windows-приложение, работающее с базами данных и приложениями электронной почты. На сегодня Delphi является одним из самых распространенных средств создания приложений баз данных для корпоративных применений. Эти средства позволяют создавать прикладные программы, предназначенные для работы на ПЭВМ IBM PC AT под управлением оболочки Windows XP и других версий, а так же операционной системы Windows NT и использующие общепринятые для Windows элементы пользовательского интерфейса. Предпочтение было отдано системе Borland Delphi 7 Enterprise благодаря тому, что она позволяет программисту очень быстро и удобно разрабатывать пользовательский интерфейс [9]. Это свойство особенно ценно из-за того, что, как показывает практика, работа над интерфейсом занимает большую часть времени создания программного продукта. Еще одним преимуществом выбранной системы является высокая (по сравнению со многими другими средствами программирования) эффективность генерируемого компилятором кода, что весьма существенно для данного проекта.
3.2 Модульная структура программного обеспечения
Программное обеспечение имеет модульную структуру, которая представлена на рисунке 3.1.
Рисунок 3.1 – Модульная структура программного обеспечения
Главным модулем является управляющая программа, которая передает управление подсистемам более низкого уровня иерархии.
В подсистеме ввода данных осуществляется ввод информации о спортивных группах, спортсменах, тренерах, а также расписании занятий групп.
В подсистеме анализа осуществляется сортировка и фильтрация информации, вносимой в базу данных.
В подсистеме вывода данных осуществляется вывод информации для просмотра на экран, а также при необходимости, вывод на печать.
При помощи справочной подсистемы можно получить подробное руководство пользователю, в котором описано предназначение всех окон программы, всех кнопок и переключателей, а также рассмотрены все возможные операции с данными.
Схема функционирования программного обеспечения изображена на рисунке 3.2. в виде алгоритма.
Рисунок 3.2 – Схема функционирования программного обеспечения
3.3 Организация пользовательского интерфейса информационной системы автоматизации документооборота в спортивной школе
Графический интерфейс пользователя создавался в системе Delphi с помощью визуального конструирования форм. Этот метод заключается в том, что программист выбирает в библиотеке необходимые ему компоненты. Затем они размещаются на форме, при необходимости корректируются их свойства. После этого пишутся процедуры-обработчики для некоторых событий (например – щелчка мыши на кнопке). В этих процедурах программируется работа приложения при конкретном действии пользователя.
Пользовательский интерфейс созданной программы содержит четыре формы (т.е. стандартных окна системы Windows).
Главное окно программы изображено на рисунке 3.3. Окно служит для доступа к другим окнам и управления приложением. Для этой цели на форме были размещены 7 кнопок (компонентов Delphi BitBtn). Три из них открывают соответственно окно форм, окно запросов, окно отчетов. Кнопка «Помощь» открывает справочную систему. Кнопка «Защита» позволяет сменить пароль доступа к программе. Кнопка «Свернуть» сворачивает все приложение. После нажатия на «Выход» закроются все окна программы, и она завершит работу.
Рисунок 3.3 – Главное окно программы
Окно «Формы» (рисунок 3.4) служит для редактирования таблиц базы данных. Пользователю не очень удобно работать с приложением, которое открывает большое количество окон. Поэтому для редактирования каждой из четырех таблиц не создавалось отдельное окно. Вместо этого окно «Формы» содержит четыре вкладки (Группы, Тренеры, Спортсмены и Расписание)
Рисунок 3.4 – Окно «Формы»
Вкладки были созданы путем размещения на форме компонента PageControl. На каждой из вкладок имеются кнопки перехода на другие окна, а также кнопка закрытия окна.
Визуализация данных осуществляется с помощью компонентов DBGrid, DBEdit и DBComboBox. DBGrid – это сетка (таблица), в которой отображаются все данные. Для нее было установлено свойство ReadOnly, тем самым редактирование записей стало возможно только через другие компоненты. DBEdit – это поле редактирования, которое настраивается на конкретное поле таблицы базы данных. DBComboBox – раскрывающийся список. Он заполняется значениями из другой таблицы, поэтому например, в поле «Тренер» можно указать только того тренера, который присутствует в соответствующей таблице. Для навигации, вставки и удаления записей базы данных служит компонент DBNavigator, представляющий панель кнопок.
Вкладки «Спортсмены» и «Расписание» имеют отличия от двух других (рисунок 3.5).
Рисунок 3.5 – Вкладка «Группы – Расписание»
Это вызвано тем, что таблицы «Спортсмены» и «Расписание» являются подчиненными таблице «Группы». Поэтому вверху окна расположены дополнительные компоненты отображения и компонент DBNavigator, управляющий выбором записи в главной таблице (таблице «Группы»), причем изменение данных здесь невозможно. В остальном набор компонентов вкладок идентичен и зависит от количества и типа полей в соответствующей таблице.
Окно «Запросы» (рисунок 3.6.) предназначено для вывода определенных данных из БД. В окне имеются кнопки перехода на другие окна и кнопка закрытия. Вывод данных производится компонентом DBGrid, а навигация по записям – DBNavigator. Вывод необходимых данных происходит по нажатию нужной кнопки. Для параметрических запросов сначала необходимо выбрать в раскрывающемся списке (компонент ComboBox) значение. Заполняются списки данными из таблиц БД, поэтому указать несуществующее значение не удастся.
Рисунок 3.6 – Окно «Запросы»
Существует возможность вывода данных обо всех спортсменах, также можно вывести информацию о заслуженных тренерах, количестве спортсменов в каждой из групп. Кроме этого, выбрав в раскрывающемся списке один из видов спорта, получаем сведения обо всех группах, занимающихся этим видом спорта. И наконец, выбрав из второго раскрывающегося списка одно из значений номера группы, мы получаем возможность узнать расписание занятий для данной группы, а также список спортсменов, занимающихся в этой группе.
В качестве примера осуществим выборку из базы данных сведений обо всех группах, занимающихся футболом (рисунок 3.7.). Для этого в раскрывающемся списке выберем вид спорта футбол и нажмем на кнопку «Сведения о группах».
Результат выполнения запроса представлен на рисунке 3.8
Рисунок 3.7 – Пример выполнения запроса
Рисунок 3.8 – Результат выполнения запроса
В окне «Отчеты» (рисунок 3.9.) кроме кнопок для перехода и выхода имеются кнопки «Расписание», «Списки групп» и «Тренеры», открывающие соответствующий отчет.
Рисунок 3.9 – Окно «Отчеты»
На рисунке 3.10 приведен пример отчета «Тренеры», который представляет собой ведомость, в которой показана информация о заработной плате каждого из тренеров без учета и с учетом процентной надбавки, а также указана общая денежная сумма, выплачиваемая всем тренерам.
Рисунок 3.10 – Отчет «Тренеры»
Одной из функций разработанного программного обеспечения является вычисление нагрузки и формирование отчетов комплектования, в который включаются все представленные в спортивном учреждении виды спорта, учебно-тренировочные группы, тренеры – преподаватели отделений, а так же их рассчитанная нагрузка.
После выполнения всех вычислений, в Microsoft Excel формируется документ «Комплектования», представленный на рисунке 3.11.
4. Организационно-экономическая часть
4.1. Краткая характеристика разрабатываемого программного продукта (ПП) и этапов разработки
В дипломной работе рассматривается разрабатываемый программный продукт автоматизации документооборота в спортивной школе. Данный продукт представляет собой базу данных, содержащую списки спортсменов, тренеров, данные по составлению расписания занятий и загруженности спортивных объектов, а так же документацию, необходимую для сдачи спортивных нормативов и проведения соревнований.
Данный программный продукт обладает некоторыми обязательными характеристиками:
- объем программного продукта в тысячах условных единиц составляет единицу;
- группа сложности определяется в зависимости от наличия некоторых характеристик (например, наличие мощного языкового интерфейса высокого уровня, реализация особо сложных инженерных и научных расчетов и т.д.). Но так как рассматриваемый ПП не обладает ни одним из этих свойств, то группа сложности – 3 (коэффициент сложности 1);
- ПП, является развитием определенного параметрического ряда программных продуктов, в соответствии с этим его степень новизны 3 (коэффициент новизны 0.7).
Разработка программных средств осуществляется в несколько этапов, содержание и выполнение которых регламентирует ГОСТ 19102 – 77.
Перечень этапов и работ выполняемого исследования приведен в таблице 4.1.
Таблица 4.1 – Расчет общей трудоемкости разработки ПП
|
Наименование этапов |
Удельный вес, к-т |
Трудоемкость, чел.-мес. |
|
1 Техническое задание 2 Эскизный проект 3 Технический проект 4 Рабочий проект 5 Внедрение |
0,09 0,07 0,07 0,61 0,16 |
1,7 1,3 1,3 12,03 3,1 |
|
Всего |
1 |
19,43 |
4.2 Определение трудоемкости разработки ПП
В дипломной работе используется модель оценки трудоемкости по системе «фактор-рейтинг».
Полная трудоемкость разработки ПП (ТПП) определяется по формуле
, (4.1)
где Кур – коэффициент уровня программной разработки; tн – номинальная трудоемкость, чел.-мес.
Так как программный продукт является независимым, то номинальная трудоемкость разработки определяется по формуле
(4.2)
(nтик – число тысяч исходных команд в тексте программы), продолжительность разработки - (мес.). Номинальная трудоемкость разработки t н =3.2*11,05=6.6256 чел.-мес.
Коэффициент уровня программной разработки определяется по 15 факторам, приведенным в таблице 4.2 и объединенным по содержанию в 4 группы.
Таблица 4.2- Оценка коэффициента уровня программной разработки
|
Факторы, определяющие уровень программной разработки |
Коэффициент рейтинга, (к) |
|
1 группа - Требования к программному изделию 1 Надежность 2 Сложность программы 3 Размер базы данных |
1 1 1,5 |
|
2 группа – Характеристика ЭВМ 4 Ограничение по быстродействию 5 Ограничение по оперативной памяти |
1 1,2 |
|
6 Изменяемость виртуальной машины (комплекс аппаратуры и ПО – ОС, СУБД) 7 Число обращений к ЭВМ |
1 1,5 |
|
3 группа – Требования к исполнителям 8 Квалификация аналитика 9 Опыт работы в данной области 10 Квалификация программиста 11 Опыт работы с языком программирования 12 Опыт работы с виртуальной машиной |
1 1 1,5 1 0,7 |
|
4 группа – Требования к проекту программной разработки 13 Применение современного программирования 14 Использование инструментальных средств 15 Ограничение сроков разработки |
1 1 1,5 |
Коэффициент уровня программной разработки определяется по формуле
, (4.3)
где kj – коэффициент рейтинга j-го фактора. Кур=4, 2525.
Полная трудоемкость разработки ПП равна Тпп=4,2525*6,6256=28,175364 чел.-мес., продолжительность разработки Р=2,5*28,1753640,38=8,89 месяцев.
4.3 Распределение трудоемкости по этапам разработки и определение состава исполнителей
Трудоемкость каждого этапа разработки (ti) определяется по формуле
, (4.4)
где ТПП – полная трудоемкость разработки ПП (чел.-мес.); yi – удельный вес трудоемкости i-го этапа в общей трудоемкости темы, к-т.; Кн – поправочный коэффициент, учитывающий степень новизны ПП. ТПП=28,175364, Кн =0,7.
На основании рассчитанной трудоемкости соответствующих этапов определяется уточненная общая трудоемкость разработки ПП (Тут) по формуле
. (4.5)
Результаты расчетов приведены в таблице 4.1.
Среднее число исполнителей (Чи), участвующих в разработке ПП, рассчитывается по формуле
, (4.6)
где Тут – полная трудоемкость разработки ПП, чел.-мес.; Р – продолжительность разработки.
Чи= 2,1. Следовательно, в разработке участвует 2 человека.
Распределение исполнителей темы по профессиям и работам производится экспертно. Каждому исполнителю устанавливается квалификационный разряд, в соответствии с которым рассчитывается его месячный оклад
, (4.7)
где ЗMIN - норматив минимальной заработной платы в РФ (1200 руб.); кБ - бюджетный коэффициент соответствующего бюджетного разряда.
Данные о составе исполнителей занесены в таблицу 4.3.
Таблица 4.3 – Состав исполнителей разработки ПП
|
Профессия исполнителя |
Кол-во |
Месячный оклад, р. |
|
1 Научный руководитель 2 Программист 2-ой категории |
1 1 |
8000 4800 |
|
Всего |
2 |
- |
4.4 Расчет сметной стоимости и договорной цены разработки ПП
Цена на научно-техническую продукцию устанавливается на этапе технического задания до начала проведения исследований. При этом она должна соответствовать ряду требований: возмещать издержки разработчику, регулировать спрос и предложение такого вида продукции, заинтересовывать разработчика и заказчика в проведении более эффективных разработок. В основе договорной цены заложена сметная стоимость разработки, определяемая в калькуляционном разрезе и включающая в себя группу статей затрат, представленных в таблице 4.8.
Материалы и покупные изделия рассчитываются по нормам расхода материалов методом прямого счета:
, (4.8)
где qMj - -норма расхода j-го материала на разработку ПП, шт; ЦMj – цена единицы j-го материала, р.; j=1…J – виды материалов, необходимые для разработки Пп; НТР – норма транспортных расходов (10 %).
Стоимость материалов и покупных изделий взята из прайс-листа компьютерного салона «POLARIS» (электронный адрес http://www.polaris.ru) за 2011 год. Результаты расчетов занесены в таблицу 4.4.
Специальное оборудование для научных и экспериментальных работ рассчитывается по формуле
, (4.9)
где SЧn – стоимость часа эксплуатации n-го вида оборудования, р.; LЧn - количество отработанных часов n-ым оборудованием, ч; n=1…N – виды спецоборудования, используемые для разработки ПП.
Таблица 4.4 – Расчет затрат на материалы и покупные изделия
|
Наименование материала |
Цена за единицу, р. |
Норма расхода, шт. |
Стоимость, р. |
|
1 Дискета 2 Бумага “Снегурочка” A4 500 л. 80 |
13 110 |
10 1 |
130 110 |
|
Итого |
- |
- |
240 |
|
Транспортно-заготовительные Расходы |
- |
- |
24 |
|
Всего |
- |
- |
264 |
, (4.10)
где SAn – амортизационные отчисления с n-го вида оборудования, р./ч;
SЭn - затраты на электроэнергию, расходуемую n-ым видом оборудования, р./ч;
Количество отработанных часов оборудованием т-го вида определяется экспертно, исходя из рассчитанной продолжительности разработки ПП:
, (4.11)
где Р – продолжительность разработки, мес.; D – количество дней использования оборудования в месяце, дн.; tЧ – количество часов использования оборудования в день, ч.
, (4.12)
где ЦОБn – балансовая стоимость единицы оборудования n-го вида, р.; ТН - нормативный срок эксплуатации оборудования n-го вида, лет; ДРАБ – количество рабочих дней в году, дн; ЧРАБ – количество часов работы оборудования в день, ч.
, (4.13)
где Mn – мощность оборудования n-го вида, кВт; ЦЭ – стоимость электроэнергии, р./ кВт.
Результаты расчетов занесены в таблицу 4.5.
Таблица 4.5 – Расчет затрат на эксплуатацию специального оборудования
|
Показатель |
Значения по видам оборудования |
|
|
Компьютер AMD DURON 2100 МГц |
Принтер HP Deskjet 3940 |
|
|
Месячный оклад лаборанта, р./мес Количество рабочих дней лаборанта в месяц, дн. Количество часов работы лаборанта в день, ч Количество единиц оборудования, шт |
4300 8 4 |
4300 22 8 2 |
|
Стоимость обслуживания оборудования |
1,32 |
1,32 |
|
Балансовая стоимость единицы оборудования, р. Нормативный срок эксплуатации оборудования, лет Количество рабочих дней в году, дн. Количество часов работы оборудования в день, ч |
27000 4 249 8 |
4500 3 249 2 |
|
Амортизационные отчисления с оборудования, р. |
3,322 |
0,553 |
|
Мощность оборудования, кВт Стоимость электроэнергии, р./кВт |
0,17 1,76 |
0,2 1,76 |
|
Затраты на электроэнергию, р. |
0,2992 |
0,352 |
|
Итого стоимость часа эксплуатации оборудования, р. |
5,0072 |
4,684 |
|
Количество отработанных оборудованием часов, ч |
1564,4 |
391,116 |
|
Количество единиц эксплуатируемого оборудования, шт. |
1 |
1 |
|
Итого затраты на эксплуатацию оборудования, р. (по видам оборудования) |
7833,26 |
1831,9 |
|
Всего затраты на эксплуатацию специального оборудования, р. |
9665,25 |
Основная заработная плата рассчитывается для каждого исполнителя, исходя из его месячного оклада и срока разработки ПП. Стоимость работы 1 ч
, (4.14)
где ОМЕСi – месячный оклад i-го работника в соответствии с квалификационным разрядом, р.; дн - количество рабочих дней в месяце; ч – количество рабочих часов в дне. Заработная плата исполнителей рассчитывается по формуле
, (4.15)
где р – продолжительность разработки, мес.; ni – количество работников i-ой квалификации, принимающих участие в разработке ПП; i=1..I – должности исполнителей, участвующих в создании ПП.
Заработная плата рассчитывается для двух исполнителей. Стоимость работы 1 ч научного руководителя Рч=19,5р. и программиста 2-ой категории Рч=12,9р. Заработная плата исполнителей равна
Розп=19,5*22*8*8,889+12,9*22*8*8,889=50688,63р.
Дополнительная заработная плата исполнителей рассчитывается по формуле
, (4.16)
где НДОП – норматив дополнительной заработной платы (17%).
Единый социальный налог равен 26%.
Результаты расчетов представлены в таблице 4.6.
Таблица 4.6 – Расчет затрат на оплату труда и социальные отчисления
|
Профессия исполнителя |
Количество исполнителей, чел. |
Месячный оклад, р. |
Заработная плата за период разработки ПП, р. |
|
Научный руководитель Программист 2-ой категории Итого |
1 1 |
8000 4800 12800 |
30507,048 20181,5 50688,63 |
|
Дополнительная заработная плата |
- |
- |
8633,085 |
|
Единый социальный налог |
- |
- |
15448,14 |
Накладные расходы рассчитываются по формуле
, (4.17)
где ННАК – норматив накладных расходов (15 %).
Сметная стоимость разработки равна
. (4.18)
Нормативная прибыль рассчитывается по формуле
, (4.19)
где СПП – сметная стоимость разработки, р.; RН – норматив рентабельности (15%).
Договорная цена разработки
. (4.20)
Договорная цена разработки ПП с учетом НДС
, (4.21)
где ННДС – ставка налога на добавленную стоимость (18%).
Результаты расчетов представлены в таблице 4.7.
Таблица 4.7 – Расчет сметной стоимости и договорной цены разработки ПП
|
Наименование статьи затрат |
Сумма, р. |
|
1 Материалы и покупные изделия 2 Специальное оборудование для научных и экспериментальных работ 3 Основная заработная плата исполнителей 4 Дополнительная заработная плата исполнителей |
264 9665,25 50688,63 8633,085 |
|
5 Отчисления на социальные нужды 6 Накладные расходы 7 Сметная стоимость разработки ПП 8 Нормативная прибыль 9 Договорная цена разработки ПП 10 Договорная цена разработки ПП с учетом НДС |
15448,14 7617,428 92410,76 9241,07 101651,84 119949,17 |
4.5 Анализ конкурентоспособности программного продукта
Конкурентоспособность – сравнительная характеристика товара, содержащая комплексную оценку всей совокупности рассматриваемых параметров относительно выявленных требований рынка или свойств другого товара. Одним из ключевых факторов конкурентоспособности является рыночная новизна. К товарам рыночной новизны могут быть отнесены товары, удовлетворяющие совершенно новые потребности и формирующие новые рынки, а также товары, удовлетворяющие на более высоком уровне уже известные потребности. Конкурентоспособность определяется с точки зрения потребителя при сравнении товаров-конкурентов как на внутреннем так и на внешнем рынках.
За базовое изделие – товар-конкурент принят аналог, то есть ПП того же назначения, отличающийся от разрабатываемого количеством выполняемых функций, скоростью поиска информации и принципами вывода конечных результатов. Товар-конкурент называется Documentum, год создания 2000, продажная цена 133000 р. Сравниваемые ПП имеют похожие функции и одинаковые принципы действия, используется единый методический подход при обработке информации.
Разрабатываемый программный продукт и товар-конкурент сравниваются с идеальным товаром (эталоном), который полностью удовлетворил бы желания потребителя.
4.5.1 Анализ технической прогрессивности
Техническая прогрессивность измеряемых показателей характеризуется коэффициентом технической прогрессивности (кТП). Расчет этого коэффициента осуществляется путем сравнения технического уровня товара-конкурента и разрабатываемого ПП по отношению к эталонному уровню ПП данного направления.
Расчет коэффициента технической прогрессивности осуществляется по формуле
, (4.22)
где kТН, kТБ – коэффициенты технического уровня соответственно нового и базового ПП.
,
при прямой зависимости
,
при обратной зависимости
где kТН, kТБ – коэффициенты технического уровня соответственно нового и базового ПП; Bi – коэффициент весомости i-го технического параметра (устанавливается экспертным путем); i=1..I – количество измеряемых параметров; ПI(Б,Н) – численное значение i-го параметра базового и нового ПП.
Анализируемый ПП технически прогрессивен, т.к. коэффициент технической прогрессивности kТП >1.
Таблица 4.8 – Расчет коэффициента технической прогрессивности разрабатываемого ПП
|
Наименование параметра |
Вес параметра, Β |
Значение параметра |
||||||
|
Пэ |
Пб |
Пн |
||||||
|
1 Объем занимаемого места на жестком диске, Мбайт 2 Количество запросов к базе данных, шт. 3 Объем ОЗУ, Мбайт 4 Загрузка ЦП, % |
0,15 0,3 0,15 0,4 |
40 6 20 10 |
50 10 28 18 |
45 8 25 15 |
0,8 0,6 0,71 0,55 |
0,88 0,75 0,8 0,66 |
0,12 0,18 0,106 0,22 |
0,132 0,225 0,12 0,264 |
|
1 |
- |
- |
- |
- |
- |
kТБ= 0,6265 |
kТН= 0,741 |
|
|
kТП=1,182 |
4.5.2 Анализ изменения функциональных возможностей
В этом разделе анализируются эстетические, эргономические параметры, характеризующие функциональные возможности ПП, не имеющие количественного выражения, трудно поддающиеся непосредственной количественной оценке. Оценка каждого параметра ведется в баллах. Общая сумма балов ПП принимается равной количеству оцениваемых функциональных возможностей ПП. Коэффициент изменения функциональных возможностей рассчитывается по формуле
, (4.23)
где АН, АБ – бальная оценка неизмеряемых параметров соответственно разрабатываемого и базового ПП.
Результаты расчетов занесены в таблицу 4.9.
Таблица 4.9 – расчет коэффициента изменения функциональных возможностей разрабатываемого ПП.
|
Перечень неизмеряемых параметров |
Балльная оценка |
|
|
АБ |
АН |
|
|
1 Надежность 2 Понятность интерфейса 3 Функциональность |
1,1 1,0 0,9 |
1,3 1,5 1,2 |
|
Итого |
3 |
4 |
|
kФВ=1,33 |
Функциональные возможности нового ПП лучше чем у базового, т.к. коэффициент изменения функциональных возможностей kФВ>1.
4.5.3 Анализ соответствия разрабатываемого ПП нормативам
Нормативные параметры характеризуют соответствие разрабатываемого ПП международным и национальным стандартам, нормативам, законодательным актам и др. ПП организации документооборота в автошколе удовлетворяет национальному стандарту по разработке программных продуктов. Следовательно показатель kНОРМ=1.
4.5.4 Оценка годовых эксплуатационных издержек потребителя
С целью всестороннего обоснования разработки ПП будет проведена сравнительная характеристика организационно-экономических условий эксплуатации базового ПП и нового ПП. Перечень текущих расходов потребителя, которые непосредственно связаны с эксплуатацией разрабатываемого ПП, занесен в таблицу 4.12.
Таблица 4.10 – Виды работ и единиц измерения годового объема работ, выполняемых с использованием функций ПП.
|
Виды работ |
Базовый ПП |
Новый ПП |
|
1 Ввод данных, операции 2 Вывод данных, операции 3 Осуществление запросов к базе данных, операции |
6325 2490 8815 |
4121 2490 6817 |
|
Всего |
17540 |
13428 |
Затраты на оплату труда работников, занятых подготовкой и обработкой информации с использованием ПП рассчитываются по формуле
, (4.24)
где ФЗПКгод – годовой фонд заработной платы работника к-й квалификации по подготовке и переработке данных, р.; FК - годовой фонд рабочего времени одного работника к-й квалификации по подготовке и переработке данных, ч; t – время выполнения одной операции работником к-й квалификации, ч; АПД – годовой объем работ по подготовке и переработке данных с использованием ПП, нат. ед.; n – численность обслуживающего персонала, чел.
Подготовкой и переработкой данных занимается 3 человека 8 разряда с месячным окладом 2074 р. Время выполнения одной операции с помощью базового ПП и нового ПП – 0,06 ч.
Затраты на оплату машинного времени определяются по формуле
, (4.25)
где Tj – время выполнения j-ой операции на ЭВМ, ч; Aj – количество j-ых операций, выполняемых в течение года в результате использования ПП, ед.; ЦМВ – стоимость одного часа работы ЭВМ, р./ч.
Таблица 4.11 – Расчет годовых эксплуатационных издержек потребителя ПП.
|
Наименование расходов |
Сумма,р |
|
|
Базовый ПП |
НовыйПП |
|
|
1 Оплата труда работников 2 Оплата машинного времени |
39559,7 10199,01 |
30285,51 7808,006 |
|
Всего |
49758,71 |
38093,51 |
По результатам расчетов видно, что экономически выгодно использовать новый ПП взамен базового ПП.
4.5.5 Анализ экономических параметров ПП
Анализу подвергается набор экономических (стоимостных) параметров ПП, характеризующих его экономические основные свойства (затраты покупателя на приобретение и использование ПП на протяжении всего срока эксплуатации). В совокупности эти расходы составляют цену потребления, которая определяется по формуле
, (4.26)
где ЦПР – продажная цена ПП – цена приобретения ПП покупателем, р.; ИЭКС – годовые эксплуатационные издержки потребителя, р.; РСТР – годовые расходы на страхование ПП (0,5% от продажной цены), р.; РНАЛ – годовые налоговые платежи (1% от продажной цены), р.; ТН – нормативный срок эксплуатации ПП (4 года); РДОР – расход на доработку ПП и приведение его в работоспособное состояние, р.
Расходы на доработку ПП определяются по формуле
, (4.27)
где ЗПЛ – среднемесячная заработная плата программиста, р.; ТРАБ – количество рабочих дней в месяце (22 дн.); tДОР – продолжительность доработки ПП, дн.; kНР – коэффициент накладных расходов (0,15); n – количество программистов, принимающих участие в доработке ПП, чел; SЧ – стоимость часа эксплуатации оборудования, р.
В доработке принимает участие 1 программист 9 разряда с месячным окладом 2278 р. Продолжительность доработки базового ПП 26 дн., нового – 14 дн.
Рдорб=5111,609р.
Рдорн=2752,404р.
Результаты расчетов занесены в таблицу 4.12.
Таблица 4.12 – Расчет цены потребления ПП.
|
Наименование расходов |
Сумма,р |
|
|
Базовый ПП |
Новый ПП |
|
|
1 Продажная цена ПП 2 Расходы на доработку 3 Эксплуатационные издержки потребителя за весь период эксплуатации 4 Страховые платежи за весь период эксплуатации 5 Налоговые платежи за весь период эксплуатации |
133075,06 5111,609 199034,84 665,375 1330,75 |
119949,17 2752,404 152374,04 33418,32 1199,49 |
|
Цена потребления |
339217,634 |
309693,424 |
Коэффициент цены потребления рассчитывается по формуле
, (4.28)
где ЦПНОВ, ЦПБАЗ – цена потребления соответственно разрабатываемого и базового ПП. Так как KЦП < 1 (KЦП=0,91), экономические параметры разрабатываемого ПП лучше, чем у базового.
4.5.6 Оценка конкурентоспособности
В целом конкурентоспособность нового ПП по отношению к базовому можно оценить с помощью интегрального коэффициента конкурентоспособности, учитывающего все ранее рассчитанные параметры
. (4.29)
Ки=1,72. Т.к. Ки>1, то разрабатываемый ПП будет конкурентоспособным.
4.6 Оценка экономической эффективности
Годовой экономический эффект определяется по формуле
, (4.30)
где АН – годовой объем выполненных с помощью нового ПП работ, ед.; ЗБ, ЗН – приведенные затраты на единицу работ, выполняемых с помощью базового и нового ПП, р.
, (4.31)
где Иi – текущие эксплуатационные затраты потребителя, приходящиеся на единицу работ, производимых ПП, р.; Кi – капитальные вложения на единицу работ, связанные с использованием ПП, р.
ЗБ=3,13355р.
ЗН=2,72481р.
Э=(3,13355-2,72481)*13428=5488,5р.
Расчетный коэффициент экономической эффективности показывает величину годовой экономии эксплуатационных издержек потребителя, образующуюся в результате применения нового ПП, приходящуюся на 1 рубль единовременных капитальных вложений
, , (4.32)
где К – сопутствующие капитальные вложения потребителя за срок эксплуатации нового ПП, р.; ИiБ, ИiН – эксплуатационные издержки потребителя на единицу работ ПП при эксплуатации базового и нового ПП, р.
∆И=(2,92687-2,63546)*13428=4047,33р.; ЕР=0,5
Внедрение нового ПП можно считать эффективным, т.к. ЕР>ЕН.
Расчетный срок окупаемости капвложений определяется как величина, обратная расчетному коэффициенту эффективности , ТР = 2 года.
Нормативный срок окупаемости , ТН =6,6 лет.
Так как , использование капвложений можно считать эффективным.
4.7 Анализ технико-экономических показателей разработки и эксплуатации ПП
Таблица 4.13 – Технико-экономические показатели разработки и эксплуатации ПП.
|
Показатели |
Значение |
|
|
Базовый ПП |
Новый ПП |
|
|
Продажная цена, р. Годовые эксплуатационные издержки потребителя, р. Цена потребления, р. Интегральный коэффициент конкурентоспособности ПП |
133075,1 49758,71 339217,6 - |
119949,172 38093,51 309693,4 1,72 |
|
Годовой экономический эффект, р. Расчетная экономическая эффективность, к-т Расчетный срок окупаемости капвложений, лет |
- - - |
5488,5 0,5 2 |
Разрабатываемый ПП является конкурентоспособным на современном рынке. Срок окупаемости капвложений 2 года. По результатам видно, что капитальные вложения в новый ПП эффективны и окупятся через два года. Годовой экономический эффект составляет 5488,5р.
5. Безопасность жизнедеятельности
Важным моментом в комплексе мероприятий направленных на совершенствование условий труда являются мероприятия по охране труда. Этим вопросам с каждым годом уделяется все большее внимание, т.к. забота о здоровье человека стала не только делом государственной важности, но и элементом конкуренции работодателей в вопросе привлечения кадров. Для успешного воплощения в жизнь всех мероприятий по охране труда необходимы знания в области физиологии труда, которые позволяют правильно организовать процесс трудовой деятельности человека.
На рабочем месте должны быть предусмотрены меры защиты от возможного воз действия опасных и вредных факторов производства. Уровни этих факторов не дол жны превышать предельных значений, оговоренных правовыми, техническими и са нитарно-техническими нормами. Эти нормативные документы обязывают к созданию на рабочем месте условий труда, при которых влияние опасных и вредных факторов на работающих либо устранено совсем, либо находится в допустимых пределах.
В данном разделе дипломного проекта освещаются основные вопросы техники безопасности труда:
5.1 Организация рабочего места
При организации рабочего места оператора ЭВМ следует обратить внимание на обеспечение следующих параметров:
1) достаточное рабочее пространство, позволяющее работающему человеку осуществлять необходимые движения и перемещения при эксплуатации;
2) достаточные физические, зрительные и слуховые связи между работающим человеком и ЭВМ;
3) безопасный и достаточный проход к рабочему месту;
4) наличие естественного и искусственного освещения в достаточной степени;
5) отсутствие уровня шума и вибраций, осуществляющих вредное воздействие на человека;
6) обеспечение достаточной защищенности человека от электромагнитного излучения, оказывающего вредное воздействие на зрительную систему оператора.
При работе за компьютером лучше использовать кресло с высотой сиденья 45 см. Эта величина попадает в диапазон 40-50 см, который физиологи определили как оптимальный для людей среднего роста. Наиболее удобным считается сиденье, имеющее выемку, соответству ющее форме бедер, и наклон назад. Спинка стула должна быть изогнутой формы, обнимающей поясницу, радиус изгиба 0.3 – 0.35 м. Поверхность сиденья, спинки и других элементов стула должна быть полумягкой, с нескользящим, неэлектризующимся и воздухо проница емым покрытием. Рабочее место должно обеспечивать оператору возможность сидеть, не сгибая ноги на угол менее 110 градусов.
Конструкция клавиатуры, используемой оператором, должна предусматривать исполнение в виде отдельного устройства с возможностью свободного перемещения (обычно крепление посредством гибкого шнура) и опорное приспособление, позволяющее изменять угол наклона поверхности клавиатуры в пределах от 5 до 15 градусов. Экран видеомонитора должен находиться от глаз пользователя на оптимальном расстоянии 600-700 мм, но не ближе 500 мм с учетом размеров алфавитно-цифровых знаков и символов.
5.2. Режим освещенности рабочего места
Важнейшим аспектом в работе оператора является зрение. Около 80 % всей информации человек получает в результате реакции на визуальное раздражение, а именно это и есть важнейший критерий при работе с ЭВМ.
Общие рабочие комнаты и кабинеты должны иметь естественное освещение. В остальных помещениях допускается искусственное освещение. Наряду с общим освещением в помещениях должно предусматриваться ава рий ное освещение, которое должно иметь независимый источник питания.
Естественное освещение осуществляется через светопроемы, минимальный размер которых должен быть равен не менее 25-35 % площади пола. Следует ограничивать неравномерность распределения яркости в поле зрения пользователей ПЭВМ. Соотношение яркости между рабочими поверхностями не должно превышать 3:1-5:1, а между рабочими поверхностями и поверхностями стен и оборудования 10:1.
Искусственное освещение в производственных помещения должно осуществляться с соблюдением следующих требований: освещенность на поверхности стола в зоне разме ще ния рабочего документа должна быть 300-500 лк. Осветительные установки должны обеспечивать равномерную освещен ность рабочей зоны и не создавать слепящих бликов на экране монитора в направлении глаз оператора. Для устранения бликов на экране видеотерминала необходимо применять антибликовые сетки, специальные фильтры для экранов, а также располагать источники света параллельно направлению взгляда с обеих сторон от видеотерминала. Рекомендуется также применение специальных козырьков, укрепляемых сверху монитора.
Восприятие цвета в большой степени зависит от качества освещения. Освещение помещения и оборудования должно быть мягким, без бликов, окраска интерьера помещений вычислительного центра должна быть спокойной для визуального восприятия. Последние исследования ученых показали, что некоторые цвета обладают следующими свойствами:
- голубой ослабляет мускульное напряжение;
- желтый стимулирует зрение и нервную систему;
- зеленый успокаивает;
- красный цвет увеличивает мускульное напряжение;
- фиолетовый создает ощущение спокойствия.
- оранжевый стимулирует деятельность;
Наиболее распространенные цвета – серый, черный и белый. Рекомендуется комбинированное применение этих цветов.
5.3. Микроклимат помещения
Оказывается, на работоспособность сотрудников влияют и такие, на первый взгляд, мелочи, как температура и влажность воздуха в офисе.
Требования для оптимального микроклимата помещения:
Для поддержания микроклимата в помещении должны быть предусмотрены вентиляция и отопление в теплое и холодное время года . В теплое время года вентиляция в помещении осуществляется бытовыми кондиционерами. При полной загруженности оборудования температура воздуха в офисе не должна превышать +25°С. В холодный период помещение отапливается батареями радиаторов. Зимой температура воздуха в помещении офиса не должна опускаться ниже +19 °С.
5.4. Уровень шума
Нормы шума на рабочих местах при действии их источников определены ГОСТ 12.1.003-83 «Шум. Общие требования безопасности», согласно которому шум должен не превышать уровня 40 Дб. Данный тип шума оказывает отрицательное воздействие на человека еще и тем, что он является монотонным. Так же необходимо отметить, что наряду с компьютером используются принтеры, что так же увеличивает уровень шума. Шум нарушает нервную систему; шумовые явления обладают свойством кумуляции: последствием их является угнетение нервной системы. В условиях длительного шумового воздействия человек испытывает раздражительность, головные боли, головокружение, снижение памяти, повышенную утомляемость, понижение аппетита, боли в ушах и т.д. Такие нарушения в работе ряда органов и систем организма человека могут вызвать негативные изменения в эмоциональном состоянии человека вплоть до стрессовых. Под воздействием шума снижается концентрация внимания, нарушаются физиологические функции, появляется усталость в связи с повышенными энергетическими затратами и нервно-психическим напряжением, ухудшается речевая коммутация. Все это снижает работоспособность человека и его производительность, качество и безопасность труда.
При работе с компьютером уровень шума редко превышает уровень в 40 Дб, что удовлетворяет нормам ГОСТа 12.1.003-83. Поэтому применять какие-либо меры по его устранению и нормализации не имеет смысла.
5.5. Психофизиологические нагрузки
Психофизиологические опасные и вредные факторы по характеру действия подразделяются на физические и нервно-психические. Первые подразделяются на статические и динамические. Ко вторым относят умственное перенапряжение глаз, монотонность труда и эмоциональные перегрузки. Причем оператор компьютера наиболее подвержен воздействию статических вредных факторов (неизменное положение тела) и перенапряжению глаз (долгое времяпровождение перед экраном). Чтобы не перенапрягать глаза оператор должен проводить у монитора не более четырех часов в сутки, производить набор не более 30000 символов.
Уменьшение влияния психофизиологических нагрузок на организм человека достигается путем следующих мероприятий:
- правильного оформления рабочего места (согласно ГОСТ Р 50948-96 «Дисплеи. Средства отображения информации индивидуального пользования. Общие эргономические требования и требования безопасности» и СанПиН 2.2.2.542-96 «Гигиенические требования к видеодисплейным терминалам, персональным ЭВМ и организации работы»);
- рационального распределения рабочего времени (через каждые 2 часа проведенные за ПК необходимо обеспечивать 10-15 минут отдыха);
- обеспечением соответствующей настройки параметров терминального оборудования (контрастность изображения знака не менее 0,8; разрешение экрана 640×480 и более; частота регенерации изображения не менее 72 МГц).
5.6. Обеспечение электробезопасности
В каждых рабочих помещениях находятся применяемые в работе компьютеры, принтеры, сканеры, бесперебойные источники питания, которые могут быть причиной поражения людей электрическим током. Хотя во всех этих приборах применены современные меры защиты, все же проводится постоянный контроль со стороны электроотдела в отношении состояния электропроводки, выключателей, штепсельных розеток и шнуров, с помощью которых включаются в сеть электроприборы.
5.7. Обеспечение пожаробезопасности
Первичные средства пожаротушения
К средствам тушения пожара, предназначенных для локализации небольших загораний, относятся пожарные стволы, внутренние пожарные водопроводы, огнетушители, сухой песок, асбестовые одеяла и т.п. В офисных зданиях пожарные краны устанавливаются в коридорах, на площадках лестничных клеток и входов. Вода используется для тушения пожаров в помещениях программистов, библиотеках, вспомогательных и служебных помещениях. Применение воды в хранилищах носителей информации, помещениях контрольно-измерительных приборов ввиду опасности повреждения или полного выхода из строя дорогостоящего оборудования возможно в исключительных случаях, когда пожар принимает угрожающе крупные размеры. При этом количество воды должно быть минимальным, а устройства ЭВМ необходимо защитить от попадания воды, накрывая их брезентом или полотном.
Для тушения пожаров на начальных стадиях широко применяются огнетушители. По виду используемого огнетушащего вещества огнетушители подразделяются на следующие основные группы.
Пенные огнетушители, применяются для тушения горящих жидкостей, различных материалов, конструктивных элементов и оборудования, кроме электрооборудования, находящегося под напряжением.
Газовые огнетушители применяются для тушения жидких и твердых веществ, а также электроустановок, находящихся под напряжением.
В офисных помещениях применяются главным образом углекислотные огнетушители (углекислотные ОУ-8, должны быть размещены в количестве не менее 2 штук), достоинством которых является высокая эффективность тушения пожара, сохранность электронного оборудования, диэлектрические свойства углекислого газа, что позволяет использовать эти огнетушители даже в том случае, когда не удается обесточить электроустановку сразу.
Система оповещения
Для обнаружения начальной стадии загорания и оповещения службы пожарной охраны используют системы автоматической пожарной сигнализации (АПС). Системы АПС состоят из пожарных извещателей, линий связи и приемных пультов (станций).
Эффективность применения систем АПС определяется правильным выбором типа извещателей и мест их установки. При выборе пожарных извещателей необходимо учитывать конкретные условия их эксплуатации: особенности помещения и воздушной среды, наличие пожарных материалов, характер возможного горения, специфику технологического процесса и т.п.
Помещения для внешних запоминающих устройств, подготовки данных, сервисной аппаратуры, архивов, копировально-множительного оборудования и т.п. необходимо оборудовать дымовыми пожарными извещателями. В этих помещениях в начале пожара при горении различных пластмассовых, изоляционных материалов и бумажных изделий выделяется значительное количество дыма и мало теплоты.
Заключение
Для автоматизации процессов электронного документооборота в спортивной школе была поставлена задача разработки программного комплекса, который бы обеспечивал решение проблемы сокращения объемов передаваемых данных между структурными подразделениями ДЮСШ
Целью данной дипломной работы являлось проектирование и разработка информационной системы автоматизации документооборота в спортивном учреждении.
Для достижения цели в работе были решены следующие задачи: определение организационной структуры спортивной школы как объекта внедрения средств автоматизации документооборота; разработка структуры базы данных; разработка структуры программного комплекса и программная реализация информационных моделей.
В работе было дано экономическое обоснование разработки программного комплекса. По результатам анализа товаров конкурентов и рынков сбыта экономические показатели разработанного программного средства превосходят аналоги, из чего следует, что разработка перспективна.
Так же в работе были рассмотрены вопросы безопасности и экологичности разрабатываемого программного комплекса. На основе результатов рассмотрения был сделан вывод, что никаких специальных мер по защите жизнедеятельности человека и окружающей среды не требуется.
unit UnitMain;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, jpeg, ExtCtrls, StdCtrls, Buttons, DB, ADODB, XPMan;
type
TFormMain = class(TForm)
XPManifest1: TXPManifest;
ADOConnection1: TADOConnection;
BitBtn1: TBitBtn;
BitBtn2: TBitBtn;
BitBtn3: TBitBtn;
BitBtn4: TBitBtn;
BitBtn5: TBitBtn;
Image1: TImage;
Image2: TImage;
Image3: TImage;
Image4: TImage;
Image5: TImage;
BitBtn6: TBitBtn;
Image6: TImage;
Bevel1: TBevel;
Bevel2: TBevel;
Bevel3: TBevel;
Bevel4: TBevel;
BitBtn7: TBitBtn;
Label2: TLabel;
procedure BitBtn5Click(Sender: TObject);
procedure BitBtn4Click(Sender: TObject);
procedure BitBtn1Click(Sender: TObject);
procedure BitBtn2Click(Sender: TObject);
procedure BitBtn3Click(Sender: TObject);
procedure BitBtn6Click(Sender: TObject);
procedure BitBtn7Click(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
FormMain: TFormMain;
implementation
uses UnitF, UnitO, UnitZ, UnitP;
{$R *.dfm}
procedure TFormMain.BitBtn5Click(Sender: TObject);
begin
close;
end;
procedure TFormMain.BitBtn4Click(Sender: TObject);
begin
Application.Minimize;
end;
procedure TFormMain.BitBtn1Click(Sender: TObject);
begin
FormF.Show;
end;
procedure TFormMain.BitBtn2Click(Sender: TObject);
begin
FormZ.Show;
end;
procedure TFormMain.BitBtn3Click(Sender: TObject);
begin
FormO.Show;
end;
procedure TFormMain.BitBtn6Click(Sender: TObject);
begin
winhelp(FormMain.Handle,'HPROJECT.HLP',HELP_CONTEXT,1);
end;
procedure TFormMain.BitBtn7Click(Sender: TObject);
begin
aut:=false;
FormP.Button1.Visible:=false;
FormP.Button2.Visible:=true;
FormP.Button3.Visible:=true;
FormP.GroupBox2.Visible:=true;
FormP.GroupBox3.Visible:=true;
FormP.Edit1.Text:='';
FormP.Edit2.Text:='';
FormP.Edit3.Text:='';
FormP.ShowModal;
end;
end.
unit UnitF;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, DBCtrls, StdCtrls, Mask, Buttons, ExtCtrls, Grids, DBGrids, DB,
ADODB, ComCtrls;
type
TFormF = class(TForm)
PageControl1: TPageControl;
TabSheet1: TTabSheet;
TabSheet2: TTabSheet;
TabSheet3: TTabSheet;
TabSheet4: TTabSheet;
ADOTable1: TADOTable;
DataSource1: TDataSource;
DBGrid1: TDBGrid;
DBNavigator1: TDBNavigator;
BitBtn1: TBitBtn;
BitBtn2: TBitBtn;
Label1: TLabel;
Label2: TLabel;
Label3: TLabel;
DBEdit1: TDBEdit;
DBEdit2: TDBEdit;
DBLookupComboBox1: TDBLookupComboBox;
ADOTable1N_tren: TIntegerField;
ADOTable1V_sport: TWideStringField;
ADOTable1N_gr: TIntegerField;
DBGrid2: TDBGrid;
DBNavigator2: TDBNavigator;
ADOTable2: TADOTable;
DataSource2: TDataSource;
Label4: TLabel;
Label5: TLabel;
Label7: TLabel;
Label8: TLabel;
DBEdit3: TDBEdit;
DBEdit4: TDBEdit;
DBCheckBox1: TDBCheckBox;
DBEdit5: TDBEdit;
DBEdit6: TDBEdit;
ADOTable2FIO: TWideStringField;
ADOTable2N_tren: TIntegerField;
ADOTable2Nadb: TSmallintField;
ADOTable2Oklad: TBCDField;
ADOTable2Zaslug: TBooleanField;
Label6: TLabel;
Label9: TLabel;
Label10: TLabel;
DBNavigator01: TDBNavigator;
DBText1: TDBText;
DBText2: TDBText;
DBLookupComboBox2: TDBLookupComboBox;
DBGrid3: TDBGrid;
DBNavigator3: TDBNavigator;
ADOTable3: TADOTable;
DataSource3: TDataSource;
ADOTable3Master: TWideStringField;
ADOTable3N_gr: TIntegerField;
ADOTable3Adres: TWideStringField;
ADOTable3DatR: TDateTimeField;
ADOTable3FIO: TWideStringField;
ADOTable3N: TIntegerField;
Label11: TLabel;
Label12: TLabel;
Label13: TLabel;
Label14: TLabel;
Label16: TLabel;
Label17: TLabel;
pst1: TBitBtn;
pst2: TBitBtn;
Label18: TLabel;
Label19: TLabel;
Label20: TLabel;
Label21: TLabel;
Label22: TLabel;
DBEdit7: TDBEdit;
DBEdit8: TDBEdit;
DBEdit9: TDBEdit;
DBEdit11: TDBEdit;
DBEdit12: TDBEdit;
DBComboBox1: TDBComboBox;
ADOTable01: TADOTable;
pst3: TBitBtn;
Label23: TLabel;
Label24: TLabel;
DBText3: TDBText;
DBNavigator001: TDBNavigator;
Label25: TLabel;
DBGrid4: TDBGrid;
ADOTable4: TADOTable;
DataSource4: TDataSource;
DBNavigator4: TDBNavigator;
ADOTable4Mesto: TWideStringField;
ADOTable4EndT: TDateTimeField;
ADOTable4BeginT: TDateTimeField;
ADOTable4N_gr: TIntegerField;
DBComboBox2: TDBComboBox;
DBEdit13: TDBEdit;
DBEdit14: TDBEdit;
DBEdit15: TDBEdit;
Label26: TLabel;
Label27: TLabel;
Label28: TLabel;
pst4: TBitBtn;
DBText4: TDBText;
Label29: TLabel;
Label30: TLabel;
DBLookupComboBox3: TDBLookupComboBox;
BitBtn4: TBitBtn;
BitBtn3: TBitBtn;
ADOTable4Day: TWideStringField;
ADOTable4N_day: TIntegerField;
procedure BitBtn2Click(Sender: TObject);
procedure BitBtn1Click(Sender: TObject);
procedure FormCreate(Sender: TObject);
procedure PageControl1Change(Sender: TObject);
procedure DBNavigator1Click(Sender: TObject; Button: TNavigateBtn);
procedure DBNavigator2Click(Sender: TObject; Button: TNavigateBtn);
procedure pst1Click(Sender: TObject);
procedure ADOTable1AfterEdit(DataSet: TDataSet);
procedure ADOTable1AfterPost(DataSet: TDataSet);
procedure ADOTable1AfterCancel(DataSet: TDataSet);
procedure ADOTable1AfterInsert(DataSet: TDataSet);
procedure pst2Click(Sender: TObject);
procedure ADOTable2AfterEdit(DataSet: TDataSet);
procedure ADOTable2AfterInsert(DataSet: TDataSet);
procedure ADOTable2AfterCancel(DataSet: TDataSet);
procedure ADOTable2AfterPost(DataSet: TDataSet);
procedure DBComboBox1DropDown(Sender: TObject);
procedure DBNavigator3Click(Sender: TObject; Button: TNavigateBtn);
procedure pst3Click(Sender: TObject);
procedure ADOTable3AfterEdit(DataSet: TDataSet);
procedure ADOTable3AfterInsert(DataSet: TDataSet);
procedure ADOTable3AfterCancel(DataSet: TDataSet);
procedure ADOTable3AfterPost(DataSet: TDataSet);
procedure DBNavigator4Click(Sender: TObject; Button: TNavigateBtn);
procedure pst4Click(Sender: TObject);
procedure ADOTable4AfterEdit(DataSet: TDataSet);
procedure ADOTable4AfterInsert(DataSet: TDataSet);
procedure ADOTable4AfterCancel(DataSet: TDataSet);
procedure ADOTable4AfterPost(DataSet: TDataSet);
procedure BitBtn3Click(Sender: TObject);
procedure BitBtn4Click(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
FormF: TFormF;
implementation
uses UnitMain, UnitZ, UnitO;
{$R *.dfm}
procedure CreateSpGr;
{заполняет список ComboBox номерами групп из таблицы группы}
var i:integer;
begin
FormF.ADOTable01.Open;
FormF.ADOTable01.Sort:='N_gr';
FormF.DBComboBox1.Items.Clear;
FormF.ADOTable01.First;
for i:=1 to FormF.ADOTable01.RecordCount do
begin
FormF.DBComboBox1.Items.Append(FormF.ADOTable01.FieldValues['N_gr']);
FormF.ADOTable01.Next;
end;
FormF.ADOTable01.Close;
end;
procedure TFormF.BitBtn2Click(Sender: TObject);
begin
close;
end;
procedure TFormF.BitBtn1Click(Sender: TObject);
begin
FormMain.Show;
end;
procedure TFormF.BitBtn3Click(Sender: TObject);
begin
FormZ.Show;
end;
procedure TFormF.BitBtn4Click(Sender: TObject);
begin
FormO.Show;
end;
procedure TFormF.FormCreate(Sender: TObject);
begin
FormF.Caption:='Форма '+'"'+ PageControl1.ActivePage.Caption +'"';
ADOTable1.Sort:='N_gr';
ADOTable2.Sort:='N_tren';
//ADOTable3.Sort:='N'; Вместе с сортировкой начинает глючить
// ADOTable4.Sort:='N_day';
CreateSpGr;
ADOTable3.Refresh;
end;
procedure TFormF.PageControl1Change(Sender: TObject);
begin
FormF.Caption:='Форма '+'"'+ PageControl1.ActivePage.Caption +'"';
end;
procedure TFormF.DBNavigator1Click(Sender: TObject; Button: TNavigateBtn);
begin
case Button of
nbInsert:
begin
DBEdit1.SetFocus;
ADOTable1.Insert;
end;
end;
end;
procedure TFormF.DBNavigator2Click(Sender: TObject; Button: TNavigateBtn);
begin
case Button of
nbInsert:
begin
DBEdit3.SetFocus;
ADOTable2.Insert;
end;
end;
end;
procedure TFormF.DBNavigator3Click(Sender: TObject; Button: TNavigateBtn);
begin
case Button of
nbInsert:
begin
DBEdit7.SetFocus;
ADOTable3.Insert;
end;
end;
end;
procedure TFormF.DBNavigator4Click(Sender: TObject; Button: TNavigateBtn);
begin
case Button of
nbInsert:
begin
DBComboBox2.SetFocus;
ADOTable4.Insert;
end;
end;
end;
procedure TFormF.DBComboBox1DropDown(Sender: TObject);
begin
CreateSpGr;
end;
procedure TFormF.pst1Click(Sender: TObject); //
begin //
if (ADOTable1.FieldValues['N_tren']=null) or (ADOTable1.FieldValues['N_gr']=null) or (ADOTable1.FieldValues['V_sport']=null) then
begin //
ShowMessage('Не все обязательные поля заполнены'); //
end //
else //
begin //
ADOTable1.Post; //
ADOTable1.Refresh; //
end; //кнопка pst1 выполняет функцию
end; //кнопки Post DBNavigator1
//
procedure TFormF.ADOTable1AfterEdit(DataSet: TDataSet); //
begin //
pst1.Enabled:=true; //
end; //
//
procedure TFormF.ADOTable1AfterInsert(DataSet: TDataSet); //
begin //
pst1.Enabled:=true; //
end; //
//
procedure TFormF.ADOTable1AfterPost(DataSet: TDataSet); //
begin //
pst1.Enabled:=false; //
end; //
//
procedure TFormF.ADOTable1AfterCancel(DataSet: TDataSet); //
begin //
pst1.Enabled:=false; //
end; //
procedure TFormF.pst2Click(Sender: TObject); //
begin //
if (ADOTable2.FieldValues['N_tren']=null) or (ADOTable2.FieldValues['FIO']=null) or (ADOTable2.FieldValues['Oklad']=null) then
begin //
ShowMessage('Не все обязательные поля заполнены'); //
end // кнопка pst2 выполняет функцию
else // кнопки Post DBNavigator2
begin //
if ADOTable2.FieldValues['Nadb']=null then ADOTable2.FieldValues['Nadb']:=0;
ADOTable2.Post; //
ADOTable2.Refresh; //
end; //
end; //
//
procedure TFormF.ADOTable2AfterEdit(DataSet: TDataSet); //
begin //
pst2.Enabled:=true; //
end; //
//
procedure TFormF.ADOTable2AfterInsert(DataSet: TDataSet); //
begin //
pst2.Enabled:=true; //
end; //
//
procedure TFormF.ADOTable2AfterCancel(DataSet: TDataSet); //
begin //
pst2.Enabled:=false; //
end; //
//
procedure TFormF.ADOTable2AfterPost(DataSet: TDataSet); //
begin //
pst2.Enabled:=false; //
end; //
procedure TFormF.pst3Click(Sender: TObject); //
begin //
if (ADOTable3.FieldValues['N']=null) or (ADOTable3.FieldValues['FIO']=null) or (ADOTable3.FieldValues['N_gr']=null){ or (ADOTable3.FieldValues['Oklad']=null)} then
begin //
ShowMessage('Не все обязательные поля заполнены'); //
end // кнопка pst3 выполняет функцию
else // кнопки Post DBNavigator3
begin //
ADOTable3.Post; //
ADOTable3.Refresh; //
end; //
end; //
//
procedure TFormF.ADOTable3AfterEdit(DataSet: TDataSet); //
begin //
pst3.Enabled:=true; //
end; //
//
procedure TFormF.ADOTable3AfterInsert(DataSet: TDataSet); //
begin //
pst3.Enabled:=true; //
end; //
//
procedure TFormF.ADOTable3AfterCancel(DataSet: TDataSet); //
begin //
pst3.Enabled:=false; //
end; //
//
procedure TFormF.ADOTable3AfterPost(DataSet: TDataSet); //
begin //
pst3.Enabled:=false; //
end; //
procedure TFormF.pst4Click(Sender: TObject); //
begin //
if (ADOTable4.FieldValues['Day']=null) or (ADOTable4.FieldValues['BeginT']=null) or (ADOTable4.FieldValues['Mesto']=null) then
begin //
ShowMessage('Не все обязательные поля заполнены'); //
end // кнопка pst4 выполняет функцию
else // кнопки Post DBNavigator4
begin
if ADOTable4.FieldValues['Day'] = 'понедельник' then ADOTable4.FieldValues['N_Day'] := 1 else
if ADOTable4.FieldValues['Day'] = 'вторник' then ADOTable4.FieldValues['N_Day'] := 2 else
if ADOTable4.FieldValues['Day'] = 'среда' then ADOTable4.FieldValues['N_Day'] := 3 else
if ADOTable4.FieldValues['Day'] = 'четверг' then ADOTable4.FieldValues['N_Day'] := 4 else
if ADOTable4.FieldValues['Day'] = 'пятница' then ADOTable4.FieldValues['N_Day'] := 5 else
if ADOTable4.FieldValues['Day'] = 'суббота' then ADOTable4.FieldValues['N_Day'] := 6 else
if ADOTable4.FieldValues['Day'] = 'воскресение' then ADOTable4.FieldValues['N_Day'] := 7;
//
ADOTable4.Post; //
ADOTable4.Refresh; //
end; //
end; //
//
procedure TFormF.ADOTable4AfterEdit(DataSet: TDataSet); //
begin //
pst4.Enabled:=true; //
end; //
//
procedure TFormF.ADOTable4AfterInsert(DataSet: TDataSet); //
begin //
pst4.Enabled:=true; //
end; //
//
procedure TFormF.ADOTable4AfterCancel(DataSet: TDataSet); //
begin //
pst4.Enabled:=false; //
end; //
//
procedure TFormF.ADOTable4AfterPost(DataSet: TDataSet); //
begin //
pst4.Enabled:=false; //
end; //
end.
unit UnitZ;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls, ExtCtrls, DBCtrls, Grids, DBGrids, DB, ADODB, Buttons, math;
type
TFormZ = class(TForm)
DBGrid1: TDBGrid;
DBNavigator1: TDBNavigator;
GroupBox1: TGroupBox;
GroupBox2: TGroupBox;
GroupBox3: TGroupBox;
GroupBox4: TGroupBox;
BitBtn1: TBitBtn;
BitBtn2: TBitBtn;
BitBtn3: TBitBtn;
ADOQuery1: TADOQuery;
ADOQuery2: TADOQuery;
ADOQuery3: TADOQuery;
ADOQuery4: TADOQuery;
ADOQuery5: TADOQuery;
ADOQuery6: TADOQuery;
DataSource1: TDataSource;
BitBtn4: TBitBtn;
BitBtn5: TBitBtn;
BitBtn6: TBitBtn;
Label1: TLabel;
BitBtn7: TBitBtn;
ComboBox1: TComboBox;
Label2: TLabel;
ComboBox2: TComboBox;
BitBtn8: TBitBtn;
BitBtn9: TBitBtn;
Bevel1: TBevel;
BitBtn10: TBitBtn;
BitBtn11: TBitBtn;
ADOQuery5DSDesigner: TWideStringField;
ADOQuery5DSDesigner2: TDateTimeField;
ADOQuery5DSDesigner3: TDateTimeField;
ADOQuery5DSDesigner4: TWideStringField;
ADOQuery5N_Day: TIntegerField;
ADOQuery2DSDesigner: TWideStringField;
ADOQuery2DSDesigner2: TBooleanField;
ADOQuery2DSDesigner3: TBCDField;
ADOQuery2DSDesigner4: TSmallintField;
QTotDel: TFloatField;
procedure BitBtn5Click(Sender: TObject);
procedure BitBtn6Click(Sender: TObject);
procedure BitBtn1Click(Sender: TObject);
procedure BitBtn4Click(Sender: TObject);
procedure BitBtn3Click(Sender: TObject);
procedure ComboBox1DropDown(Sender: TObject);
procedure ComboBox2DropDown(Sender: TObject);
procedure BitBtn10Click(Sender: TObject);
procedure BitBtn11Click(Sender: TObject);
procedure BitBtn7Click(Sender: TObject);
procedure BitBtn8Click(Sender: TObject);
procedure BitBtn9Click(Sender: TObject);
procedure BitBtn2Click(Sender: TObject);
procedure FormClose(Sender: TObject; var Action: TCloseAction);
procedure ADOQuery2CalcFields(DataSet: TDataSet);
private
{ Private declarations }
public
{ Public declarations }
end;
var
FormZ: TFormZ;
implementation
uses UnitMain, UnitF, UnitO;
{$R *.dfm}
procedure TFormZ.BitBtn5Click(Sender: TObject);
begin
FormMain.Show;
end;
procedure TFormZ.BitBtn6Click(Sender: TObject);
begin
close;
end;
procedure TFormZ.BitBtn10Click(Sender: TObject);
begin
FormF.Show;
end;
procedure TFormZ.BitBtn11Click(Sender: TObject);
begin
FormO.Show;
end;
procedure TFormZ.ComboBox1DropDown(Sender: TObject);
{заполняет список ComboBox видами спорта из таблицы группы}
var i,code:integer;
S:string;
begin
S:='';
FormF.ADOTable01.Open;
FormF.ADOTable01.Sort:='V_sport';
FormZ.ComboBox1.Items.Clear;
FormF.ADOTable01.First;
for i:=1 to FormF.ADOTable01.RecordCount do
begin
code:=pos(FormF.ADOTable01.FieldValues['V_sport'],S);
if code=0 then FormZ.ComboBox1.Items.Append(FormF.ADOTable01.FieldValues['V_sport']);
S:=S+FormF.ADOTable01.FieldValues['V_sport'];
FormF.ADOTable01.Next;
end;
FormF.ADOTable01.Close;
end;
procedure TFormZ.ComboBox2DropDown(Sender: TObject);
{заполняет список ComboBox номерами групп из таблицы группы}
var i:integer;
begin
FormF.ADOTable01.Open;
FormF.ADOTable01.Sort:='N_gr';
FormZ.ComboBox2.Items.Clear;
FormF.ADOTable01.First;
for i:=1 to FormF.ADOTable01.RecordCount do
begin
FormZ.ComboBox2.Items.Append(FormF.ADOTable01.FieldValues['N_gr']);
FormF.ADOTable01.Next;
end;
FormF.ADOTable01.Close;
end;
procedure TFormZ.BitBtn4Click(Sender: TObject);
begin
ADOQuery1.Close;
ADOQuery2.Close;
ADOQuery3.Close;
ADOQuery4.Close;
ADOQuery5.Close;
ADOQuery6.Close;
FormZ.Caption:='Запросы';
end;
procedure TFormZ.BitBtn1Click(Sender: TObject);
begin
ADOQuery1.Close;
ADOQuery2.Close;
ADOQuery3.Close;
ADOQuery4.Close;
ADOQuery5.Close;
ADOQuery6.Close;
DataSource1.DataSet:=ADOQuery1;
ADOQuery1.Open;
FormZ.Caption:='Запрос "Список спортсменов"';
end;
procedure TFormZ.BitBtn2Click(Sender: TObject);
begin
ADOQuery1.Close;
ADOQuery2.Close;
ADOQuery3.Close;
ADOQuery4.Close;
ADOQuery5.Close;
ADOQuery6.Close;
DataSource1.DataSet:=ADOQuery2;
ADOQuery2.Open;
FormZ.Caption:='Запрос "Заслуженные тренеры"';
end;
procedure TFormZ.BitBtn3Click(Sender: TObject);
begin
ADOQuery1.Close;
ADOQuery2.Close;
ADOQuery3.Close;
ADOQuery4.Close;
ADOQuery5.Close;
ADOQuery6.Close;
DataSource1.DataSet:=ADOQuery3;
ADOQuery3.Open;
FormZ.Caption:='Запрос "Количество в группах"';
end;
procedure TFormZ.BitBtn7Click(Sender: TObject);
begin
ADOQuery1.Close;
ADOQuery2.Close;
ADOQuery3.Close;
ADOQuery4.Close;
ADOQuery5.Close;
ADOQuery6.Close;
DataSource1.DataSet:=ADOQuery4;
ADOQuery4.Parameters.ParamValues['ParamSPORT']:=ComboBox1.Text;
ADOQuery4.Open;
FormZ.Caption:='Запрос "Сведения о группах"';
end;
procedure TFormZ.BitBtn8Click(Sender: TObject);
begin
ADOQuery1.Close;
ADOQuery2.Close;
ADOQuery3.Close;
ADOQuery4.Close;
ADOQuery5.Close;
ADOQuery6.Close;
DataSource1.DataSet:=ADOQuery5;
ADOQuery5.Parameters.ParamValues['ParamNGR']:=ComboBox2.Text;
ADOQuery5.Open;
FormZ.Caption:='Запрос "Расписание группы № '+ComboBox2.Text+'"';
//ADOQuery5.Sort:='nDay';
end;
procedure TFormZ.BitBtn9Click(Sender: TObject);
begin
ADOQuery1.Close;
ADOQuery2.Close;
ADOQuery3.Close;
ADOQuery4.Close;
ADOQuery5.Close;
ADOQuery6.Close;
DataSource1.DataSet:=ADOQuery6;
ADOQuery6.Parameters.ParamValues['ParamNGR']:=ComboBox2.Text;
ADOQuery6.Open;
FormZ.Caption:='Запрос "Список спортсменов группы № '+ComboBox2.Text+'"';
end;
procedure TFormZ.FormClose(Sender: TObject; var Action: TCloseAction);
begin
ADOQuery1.Close;
ADOQuery2.Close;
ADOQuery3.Close;
ADOQuery4.Close;
ADOQuery5.Close;
ADOQuery6.Close;
FormZ.Caption:='Запросы';
end;
procedure TFormZ.ADOQuery2CalcFields(DataSet: TDataSet);
begin
QTotDel.Value:=roundto((ADOQUERY2DSDesigner3.Value*(1+(ADOQUERY2DSDesigner4.Value/100))),-2);
end;
end.
unit UnitO;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls, Buttons, RpCon, RpConDS, RpBase, RpSystem, RpDefine,
RpRave, RpRender, RpRenderHTML, jpeg, ExtCtrls, DB, ADODB, RpRenderPDF,
Grids, DBGrids, math;
type
TFormO = class(TForm)
RvProject1: TRvProject;
RvSystem1: TRvSystem;
RvDataSetConnection1: TRvDataSetConnection;
BitBtn1: TBitBtn;
BitBtn2: TBitBtn;
BitBtn3: TBitBtn;
RvRenderHTML1: TRvRenderHTML;
Image1: TImage;
BitBtn4: TBitBtn;
BitBtn5: TBitBtn;
BitBtn6: TBitBtn;
BitBtn7: TBitBtn;
ADOQuery1: TADOQuery;
ADOQuery2: TADOQuery;
ADOQuery3: TADOQuery;
RvDataSetConnection2: TRvDataSetConnection;
RvDataSetConnection3: TRvDataSetConnection;
Image2: TImage;
ADOQuery3N_tren: TIntegerField;
ADOQuery3FIO: TWideStringField;
ADOQuery3Oklad: TBCDField;
ADOQuery3Nadb: TSmallintField;
QtotalDELF: TFloatField;
procedure BitBtn4Click(Sender: TObject);
procedure BitBtn5Click(Sender: TObject);
procedure BitBtn6Click(Sender: TObject);
procedure BitBtn7Click(Sender: TObject);
procedure BitBtn3Click(Sender: TObject);
procedure BitBtn1Click(Sender: TObject);
procedure BitBtn2Click(Sender: TObject);
procedure ADOQuery3CalcFields(DataSet: TDataSet);
private
{ Private declarations }
public
{ Public declarations }
end;
var
FormO: TFormO;
implementation
uses UnitMain, UnitF, UnitZ;
{$R *.dfm}
procedure TFormO.BitBtn4Click(Sender: TObject);
begin
FormMain.Show;
end;
procedure TFormO.BitBtn5Click(Sender: TObject);
begin
FormF.Show;
end;
procedure TFormO.BitBtn6Click(Sender: TObject);
begin
FormZ.Show;
end;
procedure TFormO.BitBtn7Click(Sender: TObject);
begin
close;
end;
procedure TFormO.BitBtn3Click(Sender: TObject);
begin
RvProject1.ExecuteReport('ReportTren');
end;
procedure TFormO.BitBtn1Click(Sender: TObject);
begin
RvProject1.ExecuteReport('ReportRasp');
end;
procedure TFormO.BitBtn2Click(Sender: TObject);
begin
RvProject1.ExecuteReport('ReportSpis');
end;
procedure TFormO.ADOQuery3CalcFields(DataSet: TDataSet);
begin
QTotalDelf.Value:=roundto((ADOQUERY3OKLAD.Value*(1+(ADOQUERY3nadb.Value/100))),-2);
end;
end.
unit UnitA;
interface
uses Windows, SysUtils, Classes, Graphics, Forms, Controls, StdCtrls,
Buttons, ExtCtrls;
type
TAboutBox = class(TForm)
Timer1: TTimer;
Shape1: TShape;
Image7: TImage;
Image8: TImage;
Image5: TImage;
Image4: TImage;
Image2: TImage;
Image3: TImage;
Image6: TImage;
Image1: TImage;
Label2: TLabel;
Label1: TLabel;
Label3: TLabel;
procedure FormShow(Sender: TObject);
procedure FormClose(Sender: TObject; var Action: TCloseAction);
procedure Timer1Timer(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
AboutBox: TAboutBox;
implementation
{$R *.dfm}
procedure Delay(dwMilliseconds: Word);
var
iStart, iStop: DWORD;
begin
iStart := GetTickCount;
repeat
iStop := GetTickCount;
Application.ProcessMessages;
until ((iStop - iStart) >= dwMilliseconds);
end;
procedure TAboutBox.FormShow(Sender: TObject);
begin
Timer1.Enabled:=true;
end;
procedure TAboutBox.FormClose(Sender: TObject; var Action: TCloseAction);
var i:integer;
begin
for i:=60 downto 1 do
begin
AboutBox.AlphaBlendValue:=AboutBox.AlphaBlendValue-4;
Delay(10);
end;
end;
procedure TAboutBox.Timer1Timer(Sender: TObject);
begin
Timer1.Enabled:=false;
close;
end;
end.
unit UnitP;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls;
type
TFormP = class(TForm)
GroupBox1: TGroupBox;
GroupBox2: TGroupBox;
GroupBox3: TGroupBox;
Button1: TButton;
Button2: TButton;
Button3: TButton;
Edit1: TEdit;
Edit2: TEdit;
Edit3: TEdit;
procedure Button1Click(Sender: TObject);
procedure Button2Click(Sender: TObject);
procedure Button3Click(Sender: TObject);
procedure FormCreate(Sender: TObject);
procedure Edit2Change(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
FormP: TFormP;
aut:boolean = true;
implementation
uses UnitMain, UnitA;
{$R *.dfm}
function test(a:string):boolean;
var f:file of char;
m:array of char;
m1:array of char;
b:char;
i:integer;
s:integer;
j:integer;
// p:string;
c:string[3];
// r:integer;
// rc:string[1];
begin
AssignFile(f,'hdrdata.base');
reset(f);
s:=0;
while not EOF(f) do
begin
inc(s);
setLength(m,(s));
setLength(m1,(s));
read(f,b);
m[s-1]:=b;
m1[s-1]:=b;
end;
closefile(f);
if s<>131+Length(a)*3 then
begin
result:=false;
exit;
end;
for i:=1 to Length(a) do
begin
c:=inttostr(758-ord(a[i]));
for j:=1 to 3 do
m1[j+3*(i-1)+130]:=c[j]; //blockwrite(f,c[j],1);
end;
result:=true;
for i:=0 to s-1 do
if m[i]<>m1[i] then result:=false;
end;
procedure setp(p:string);
var f:file{ of string[3]};
i:integer;
j:integer;
// p:string;
c:string[3];
r:integer;
rc:string[1];
begin
AssignFile(f,'hdrdata.base');
rewrite(f,1);
//showmessage(p[1]);
randomize;
for i:=1 to 131 do
begin
r:=random(10);
//showmessage(inttostr(r));
rc:=inttostr(r);
blockwrite(f,rc[1],1);
end;
for i:=1 to Length(p) do
begin
c:=inttostr(758-ord(p[i]));
for j:=1 to 3 do
blockwrite(f,c[j],1);
end;
CloseFile(f);
end;
procedure TFormP.Button1Click(Sender: TObject);
begin
if test(Edit1.Text) then close else showmessage('access denied ;-)');
end;
procedure TFormP.Button2Click(Sender: TObject);
begin
if aut then FormMain.Close else close;
end;
procedure TFormP.Button3Click(Sender: TObject);
begin
if not test(Edit1.Text) then showmessage('access denied ;-)')
else
if Edit2.Text<>Edit3.Text then showmessage('Новый пароль не совпадает с подтверждением!')
else
begin
setp(Edit2.Text);
Showmessage('Пароль изменен');
close;
end;
end;
procedure TFormP.FormCreate(Sender: TObject);
begin
Button1.Visible:=true;
Button2.Visible:=true;
Button3.Visible:=false;
GroupBox2.Visible:=false;
GroupBox3.Visible:=false;
Edit1.Text:='';
end;
procedure TFormP.Edit2Change(Sender: TObject);
begin
if length(Edit2.Text)<6 then Button3.Enabled:=false else Button3.Enabled:=true;
end;
end.
Директор
Бухгалтерия
Заместитель директора
Главный бухгалтер
Начальники отделов
дминистративно-хозяйственный отдел
Отдел информационных технологий (ИТ)
Отдел снабжения
Учебно-спортивный отдел
Заведующие спортивными объектами
Стадион
Бассейн
Универсальный спортивный зал и малый зал
Тренажерный зал и зал для настольного тенниса
Тренеры
Группы спортсменов
Отдел кадров
Диспетчерская
служба
Обучение
Перевод в сл. группу
Тренеры - преподаватели
Данные об учащихся
Учебно-тренировочные занятия и нормативные документы
Зачисление в спортивную школу
Учащиеся
Проведение учебно-тренировочных занятий
Сдача контрольно-переводных нормативов
Формирование документации о переводе
Тренеры - преподаватели
Распределение тренеров
Информация о группе
Данные об учащихся
Формирование учебно-тренировочных групп
Подтверждение зачисления
Документация