Автоматизация процессов, протекающих в общежитии. Установление требований
1.1 Предварительные замечания к проекту
В результате изучения предметной области и поиска аналогичных проектов было выявлено, что по ряду причин системы учета проживающих в общежитии либо не созданы, либо разрабатываются в настоящее время. Аналогами таких ИС могут выступать системы автоматизации объектов размещения, так называемые Property Management Systems (PMS), уже давно применяемые на отечественном гостиничном рынке. Однако из 3,5 тысяч отечественных гостиниц пока что автоматизировано менее десяти процентов. Речь в основном идет о крупных гостиничных комплексах имеющих возможность привлекать высококвалифицированных специалистов. В более трудном положении находятся небольшие гостиницы, для которых подобные возможности не доступны по разным причинам и подобное программное обеспечение до сих пор не стало повседневным инструментом их работы.
Основной причиной вышеперечисленных проблем является то что, рассматриваемые системы, несомненно, является инновационными. Еще не сформирована база, от аксиом которой отталкивались бы проектировщики. В образовательном прочесе помимо новизны системы просматривается еще одно препятствие, которое должно быть преодолено. Дело в том, что массовая компьютеризация учебных заведений в России начата относительно недавно. Далеко не у всех отечественных вузов есть возможность компьютеризировать корпуса общежития и объединить их общей информационной сетью. В связи с этим проектирование таких узко специальных систем не достигло своей вершины и будет только продолжаться.
Главной целью реализуемого проекта является автоматизация многих процессов протекающих в общежитии: поселение и выселение жильцов, регистрация гостей общежития, поиск проживаемого жильца, учет выдаваемой мебели и постельного белья и многое другое. Несмотря на то, что реализовано и применяется не так много рассматриваемых ИС, их потребность и актуальность трудно переоценить. Действительно, автоматизация информации о проживающих в общежитии не только полезна и удобна для менеджмента со стороны руководства, она повышает уровень учебного заведения, подчеркивая его информатизацию во всех сферах, дает полную информацию о жильцах проживаемых в общежитии.
Исходя из вышесказанного, можно определить основных участников разрабатываемого проекта. Под термином "участник проекта", подразумевается любое заинтересованное лицо. Человек, интересы которого так или иначе затрагиваются системой либо сам оказывающий влияние на разработку системы, является участником проекта. Как правило, участники проекта делятся на две группы: заказчики и разработчики. Заказчиком разрабатываемой ИС является Южно-Российский государственный университет экономики и сервиса (ЮРГУЭС), в лице ректора Сапронова Анатолия Георгиевича. Также со стороны заказчиков могут выступать руководители и сотрудники общежитий ЮРГУЭС, деканы факультетов, работники бухгалтерии и планово-финансового отдела (ПФО). Разработчиком данной РИС является студент механико-радиотехнического факультета (МРТФ), группы ПИ-Р51, обучающийся по специальности 080801 "Прикладная информатика в сфере сервиса" Щегров Роман Викторович, под контролем дипломного руководителя Примачик С.К.
1.2 Системные сервисы
1.2.1 Рамки системы
Система разрабатывается для ЮРГУЭС и большей частью будет ориентирована на те принципы и правила, которые установлены в общежитиях ВУЗа. Несмотря на то, что заказчиком является конкретное учебное заведение, разработка системы будет вестись на основе динамического построения всех основных объектов общежития. Прежде всего, такой подход делает систему открытой, простой в применении, оставляя возможность использовать ее в управленческом процессе других учебных заведений.
Необходимо сказать, что в ЮРГУЭС широко используется ИС учета образовательного процесса студентов ЮРГУЭС - "Деканат". Эта система охватывает широкий спектр вопросов касающихся студентов университета и их обучения. Разрабатываемая система будет являться приложением к системе "Деканат", отвечающей за размещение и проживание студентов в стенах общежития. Она будет использовать данные о студентах, которыми располагает ИС "Деканат". В функционирование системы не подразумевает ведение вопросов связанных с оплатой жильцов за проживание в общежитии.
1.2.2 Функциональные требования
Для выявления принципов работы разрабатываемой ИС и определения ее основных функциональных блоков выделим основные требования, предъявляемые к системе. При выявлении требований были изучены документы и формы, использующиеся в делопроизводстве общежитий ЮРГУЭС. Они приведены в приложении Б.
а) Система должна предоставлять инструмент для регистрации корпусов общежития с перечислением всех атрибутов: название, адрес, руководитель, количество жилых мест, количество этажей, количество жилых блоков, примечание.
б) У системы должен быть инструмент для регистрации комнат в общежитии со следующими атрибутами: номер комнаты, количество мест в комнате, состояние (ремонт, готова к проживанию), принадлежность (студенческая, гостиная, комната для сотрудников), примечание.
1) При создании комнаты система должна предлагать закрепить за созданной комнатой мебель. В случае отказа от закрепления мебели, это будет произведено при поселении в комнату жильца.
в) Система должна предоставлять возможность формирования фонда мебели и постельного белья
1) Фонд мебели формируется по следующим атрибутам: наименование, состояние, количество, примечание.
2) Фонд постельного белья: наименование, количество, примечание.
г) У система должен быть механизм заселение жильца.
1) Поиск комнаты по заданным критериям: принадлежность комнаты, количество мест, количество свободных мест, состояние. Может использоваться один или несколько атрибутов комнаты.
2) Системой должна предоставляться возможность выбора комнаты из списка найденных комнат.
3) Если выбрана комната, за которой еще не закреплена мебель, система предлагает это сделать. В данной ситуации эта операция не может быть пропущена.
4) Заселение жильца. Осуществляется либо выбором жильца из имеющегося списка, либо добавлением информации о нем вручную.
д) У система должен быть механизм выселения жильца.
1) Поиск жильца по заданным критериям: ФИО жильца, номер комнаты. Может использоваться один или несколько атрибутов комнат.
2) Выселение жильца. Осуществляется выбором жильца из имеющегося списка жильцов комнаты.
3) Если выселен последний жилец комнаты, система предлагает удалить мебель, закрепленную за комнатой. Возможен как положительный, так и отрицательный ответ на данное предложение.
е) Система предоставляет возможность контроля выдачи\сдачи постельного белья.
1) Поиск жильца по заданным критериям: ФИО жильца, номер комнаты.
2) Ведение данных выдачи\сдачи постельного белья по следующей форме: дата выдачи, наименование, количество, дата сдачи.
ж) У системы должен быть механизм учета гостей общежития.
1) Поиск жильца, к которому пришел гость.
2) Оформление пропуска. Фиксируется данные пропуска: ФИО гостя, жильца и вахтёра, дату посещение, время до истечения срока пропуска.
3) Фиксирует, когда гость выходит из общежития.
4) Ведется контроль времени окончания пропуска, напоминая вахтёру об опоздании.
з) У системы должен быть инструмент контроля долговременного отсутствия жильца в общежитии по форме: дата убытия, ФИО, номер комнаты, дата прибытия, примечание.
1.2.3 Требования к данным
Основываясь на изучении предметной области и установлении требований (п. 1.2.2), были выявлены основные объекты предметной области, а так же их атрибуты.
а) Корпус общежития: название, адрес, руководитель, количество жилых мест, количество этажей, количество жилых блоков, примечание.
б) Комната общежития: номер комнаты, количество мест, состояние, принадлежность, примечание.
2) Сотрудник ВУЗа, его атрибуты: ФИО, должность, подразделение, примечание.
3) Гость, его атрибуты: ФИО, паспортные данные, примечание
1.3 Системные ограничения
1.3.1 Требования к интерфейсу
Разрабатываемая ИС должна взаимодействует с пользователем по средствам оконного Windows GUI интерфейса, который будет содержать главное окно приложения и набор вторичных окон. В приложении может быть использованы стандарты построения окон для Windows: кнопки, вкладки, переключатели, строки меню и другое.
1.3.2 Требования к производительности
Разрабатываемая система будет построена на основе клиент-серверной архитектуры. Возможны ситуации что клиентская и серверная части приложения будут значительно удалены друг от друга. В этой связи аппаратные требования к клиентским машинам следующие: чистота работы процессора должна быть не менее 1 ГГ, объем оперативной памяти не менее 256 МБ. Пропускная способность сети должна быть в пределах 2 Мбит в секунду.
1.3.3 Требования к безопасности
Права доступа к данным в разрабатываемой ИС разделены. Предполагаемые пользователи системы делятся на группы. Каждая группа обладает своим набором прав на пользование ресурсами. В разрабатываемой системе будет использоваться пять групп пользователей:
а) Администратор системы
б) Комендант
в) Вахтёр
г) Кастелянша
д) Сотрудник ВУЗа
Наивысший приоритет имеет администратор, пользователь с правами администратора имеет возможность проводить любые действия в отношении системы. Комендант,- администратор корпуса, имеет право на любые действия в отношении системы в рамках определенного общежития. У пользователя с правами коменданта есть так же возможность найти и просмотреть информацию о интересующем жильце зарегистрированном с системе. Сотрудник ВУЗа имеет право только на просмотр информации о жильцах и комнатах всей системы. Вахтер имеет право на поиск жильца и регистрации его временного убытия и прибытия. Кастелянша владеет информацией о постельном белье определенного корпуса. Пользователю из этой группы доступна функция закрепления белья фонда белья общежития за выбранным жильцом.
1.3.4 Эксплуатационные требования
Данная ИС должна работать на персональных ЭВМ. Предполагается, что заказчик будет использовать ПК под управлением операционной системы семейства Windows не ниже 2000 версии. После завершающего этапа программирования системы, создается установочный фаил, содержащий всю необходимую информацию. Исполняемый exe-фаил установленной клиентская часть системы не требует наличия среды разработки. Для разработки серверной части приложения возможно использования программных пакетов таких как: Microsoft SQL Server 2000, Microsoft SQL Server 2005 и другие.
