|
|
@@ -1,83 +0,0 @@
|
|
|
-# Сессия 1. Создание БД. Импорт данных. Окно авторизации
|
|
|
-
|
|
|
->Ресурсы к первой сессии находятся в файле `data/Session1.zip` этого репозитория
|
|
|
-
|
|
|
-## База данных и импорт
|
|
|
-
|
|
|
->Создайте базу данных, используя предпочтительную платформу (MySQL / Microsoft SQL Server), на сервере баз данных, который вам предоставлен.
|
|
|
->
|
|
|
->Создайте таблицы основных сущностей, атрибуты, отношения и необходимые ограничения. После создания базы данных требуется импортировать предоставленные данные (см. ресурсы к первой сессии). Возможно, вам понадобится отформатировать данные, прежде чем загрузить их в таблицы, которые вы только что создали. В любом случае созданные таблицы должны содержать начальные тестовые данные.
|
|
|
->
|
|
|
->Порядок работы лаборатории: на каждую единицу принятого биоматериала создается заказ, который может содержать в себе услуги (одну или несколько) – исследования биоматериала. У одного пациента может быть несколько заказов. Хранение данных о всех пациентах и заказах позволит формировать все необходимые отчеты, отслеживать динамику показателей и состояние здоровья пациента, а так же автоматизировать работу сотрудников лаборатории.
|
|
|
->
|
|
|
->Обеспечьте хранение в базе данных:
|
|
|
->
|
|
|
->* услуги лаборатории (наименование, стоимость, код услуги, срок выполнения, среднее отклонение)
|
|
|
->* данные пациентов (логин, пароль, ФИО, дата рождения, серия и номер паспорта, телефон, e-mail, номер страхового полиса, тип страхового полиса, страховая компания)
|
|
|
->* данные о страховых компаниях (название страховой компании, адрес, ИНН, р/с, БИК)
|
|
|
->* заказ (дата создания, которые входят в заказ, услуги, статус заказа, статус услуги в заказе, время выполнения заказа (в днях))
|
|
|
->* оказанная услуга (услуга, когда и кем была и на каком анализаторе)
|
|
|
->* данные о работе анализатора (дата и время поступления заказа на анализатор, дата и время выполнения (в секундах) услуг на анализаторе)
|
|
|
->* данные лаборантов (логин, пароль, ФИО, последняя дата и время входа, набор услуг, которые он может оказывать)
|
|
|
->* бухгалтер (логин, пароль, ФИО, последняя дата и время входа, набор услуг, выставленные счета страховым компаниям)
|
|
|
->* администратор (логин и пароль)
|
|
|
->
|
|
|
->При организации хранения данных вам необходимо учесть запрет на полное удаление данных, реализовав возможность отправки данных в архив. Кроме того, необходимо учесть, что данные о заказе не могут быть отправлены в архив, если не выполнена хотя-бы одна услуга в заказе.
|
|
|
->
|
|
|
->Разработанная вами база данных должна быть в 3 НФ.
|
|
|
->
|
|
|
->К разработанной баз данных создайте словарь данных (пример словаря данных в папке с ресурсами).
|
|
|
->По окончании сессии разработанная вами база данных будет оценена экспертной группой. В последующих сессиях возможно вам понадобится добавить какие-либо сущности в ходе работы над проектом.
|
|
|
-
|
|
|
-Часть данных для импорта предоставлена в XML формате. Причём формат может быть не совместим с MS-парсером (Excel не может разобрать). MS-парсер не поддерживает пробелы в названиях тегов и знак `/`.
|
|
|
-
|
|
|
-```xml
|
|
|
-<bad tag name>
|
|
|
-</bad tag name>
|
|
|
-
|
|
|
-<also_bad/tag>
|
|
|
-</also_bad/tag>
|
|
|
-```
|
|
|
-
|
|
|
-Можно заранее найти такие теги с помощью регулярных выражений (например, в VSCode):
|
|
|
-
|
|
|
-```regexp
|
|
|
-<\w+?[\s\/]\w+?>
|
|
|
-```
|
|
|
-
|
|
|
-Находит все теги, в которых есть пробел (`\s`) или слеш (`/`)
|
|
|
-
|
|
|
-## Окно входа
|
|
|
-
|
|
|
->При запуске приложения окно входа – первое, что видит пользователь. На ней пользователю предлагается ввести свой логин и пароль. Только после удачной авторизации пользователь получает доступ к остальным модулям системы.
|
|
|
->
|
|
|
->При вводе пароль должен быть скрыт маской ввода, но так же должна быть реализована возможность просмотра введенного пароля.
|
|
|
->
|
|
|
->При входе система выводит фото пользователя, фамилию и имя пользователя, его роль.
|
|
|
->
|
|
|
->После авторизации пользователь получает доступ к нужному функционалу:
|
|
|
->
|
|
|
->* лаборант может принять биоматериал, сформировать отчеты;
|
|
|
->* лаборант-исследователь может работать с анализатором;
|
|
|
->* бухгалтер может просмотреть отчеты, сформировать счет страховой компании;
|
|
|
->* администратор может сформировать отчеты, проконтролировать всех пользователей по истории входа, работать с данными о расходных материалах, используемых в лаборатории.
|
|
|
->
|
|
|
->Реализуйте необходимые интерфейсы для всех пользователей системы. После входа в любую учетную запись должна быть реализована возможность выхода на главный экран – окно входа.
|
|
|
->
|
|
|
->При входе в учетную запись лаборанта и лаборанта-исследователя должен быть виден таймер (часы:минуты), который фиксирует время сеанса пользователя. Сеанс пользователя не должен превышать 2 ч 30 минут, так как через каждые 2 ч 30 минут необходимо выполнить кварцевание помещений. За 15 минут до окончания времени сеанса должно появиться сообщение об окончании времени сеанса. По окончании времени сеанса реализуйте выход из учетной записи и блокировку входа на 30 минут.
|
|
|
->
|
|
|
->Для удобства проверки экспертной группой - укажите время сеанса – 10 минут, появление сообщения – за 5 минут до окончания времени сеанса, блокировка входа – 1 минута.
|
|
|
->
|
|
|
->После первой попытки неуспешной авторизации система выдает сообщение о неуспешной авторизации, а затем помимо ввода логина и пароля просит ввести **captcha**, состоящую из 4 символов (цифры и буквы латинского алфавита) и графического шума.
|
|
|
->
|
|
|
->CAPTCHA - должна содержать минимум 4 символа (буква или цифра), которые выведены не в одной линии. Символы должны быть либо перечеркнуты либо наложены друг на друга.
|
|
|
->
|
|
|
->Реализуйте возможность повторной генерации **captcha**, если пользователю непонятны символы из-за шума.
|
|
|
-После попытки неудачной авторизации с вводом **captcha**, система блокирует возможность входа на 10 секунд.
|
|
|
-
|
|
|
-## История входа
|
|
|
-
|
|
|
->Приложение должно хранить историю входа в систему, так как в системе будут храниться медицинские данные пациентов. Окно для просмотра истории должно быть доступно администратору системы. В этом окне необходимо реализовать просмотр всей истории входа, а также фильтрацию по логину пользователя. Кроме этого, необходимо добавить сортировку по дате попытки входа. Каждая запись истории должна содержать следующие данные: время, логин пользователя, успешная или ошибочная попытка входа.
|
|
|
-# Сессии 2-6.
|
|
|
-
|
|
|
->Ресурсы к остальным сессиям находятся в файле `data/09_sessions2_6.zip` этого репозитория
|
Евгений Колесников