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

580

Аннотация

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

Общая информация

Рубрика издания: Технологии разработки программного обеспечения

Тип материала: научная статья

Для цитаты: Лукин В.В., Панфилова А.С. Реализация интерактивного процесса проведения психолого-медико-педагогического обследования в условиях безнадежных проектов // Моделирование и анализ данных. 2013. Том 3. № 1. С. 116–127.

Полный текст

1.    ВВЕДЕНИЕ

Автоматизация глобального интерактивного процесса в масштабах мегаполиса требует существенных затрат: временных, людских, финансовых и характеризуется существенно продолжительным сроком реализации. Риски подобных проектов в первом приближении оцениваются на основании масштабности и срочности. Они также зависят от множества условий, несоблюдение которых часто на практике переводит проект из категории «рисковых» в категорию «невыполнимых». Сочетание масштабности проекта в рамках мегаполиса, нереальных требований по срокам реализации и отсутствие каких-либо ресурсов переводит его в категорию безнадежных.

Участию в одном из безнадежных проектов посвящается эта статья - в двухнедельный срок автоматизировать работу психолого медико педагогических комиссий (ПМПК) города Москвы, как окружных, так и городских, начиная от подачи заявки на проведение обследования родителями в окружной комиссии (ОПМПК) до работы с апелляциями на уровне городской комиссии (ГПМПК). Предполагалось, что результатами этих комиссий будут пользоваться не только заявители, но и все образовательные учреждения Москвы. А вот выделять ресурсы на выполнение этого проекта не предполагалось. Зато условия реализации требовали организацию работы с личными данными, что регламентируется федеральным законом «О персональных данных» (№152-ФЗ).

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

Целью процесса прохождения ПМПК является получение заключение комиссии, согласно которому будет даны рекомендации по выбору образовательного учреждения и об организации процесса инклюзивного образования, т.е. специальных условий, согласно нозологии и психологических особенностей ребенка. В этом случае, задачей автоматизированной системы является реализация процесса подачи заявки, сбор и хранение электронных копий сопроводительных документов, мониторинг исполнения заявки, поддержка принятия решения комиссии и предоставления конечных результатов по требованиям образовательных учреждений (ОУ) и Заявителя (родителей, опекунов, etc.) [4].

Определяем следующие основные реализуемые процессы:

1)     регистрация Заявителя в системе;

2)      подача заявок на проведение обследования ПМПК;

3)      регистрация заявок в ОПМПК;

4)      мониторинг исполнения заявки:

-   передача заявки в ОПМПК по месту жительства (при ошибочном выборе ОПМПК Заявителем);

-       назначение ПМПК;

-       проведение ПМПК;

-       заключение ОПМПК;

5)      апелляция решения в ГПМПК (продвижение заявки со стороны Заявителя);

6)      мониторинг исполнения заявки:

-       назначение ПМПК;

-       проведение ПМПК;

-       заключение ГПМПК;

7)      запрос заявки (заявитель, образовательные учреждения, etc.)

Определим системные вспомогательные процессы:

1)     печать отчетных форм каждого этапа;

2)      осуществление выборки информации по произвольному линейному запросу;

3)      осуществление контекстного поиска информации;

4)      мониторинг прохождения заявки (Заявитель, Департамент образования, Контроль качества процесса, etc.)

Непосредственными пользователями системы являются сотрудники Департамента образования, члены ОПМПК; члены ГПМПК; сотрудники образовательных учреждений, ответственные за поступление и выбытие ребенка.

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

Для обеспечения возможности развития системы в случае:

-       изменения порядка прохождения заявки;

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

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

1.     АРМ администрирования пользователей:

1.1.     регистрацию пользователей системы и определение роли;

1.2.     добавление и корректировку роли пользователя:

-       уровень доступа к заявкам;

-       оступные атрибуты;

-       доступные запросы на изменение заявки;

-       доступные аналитические запросы

 

1.3.     аналитические отчеты о пользователях системы;

1.4.     журнал действий пользователя.

2.     АРМ исполнителей заявки (ОПМПК):

2.1.     выполнение запросов на изменение статуса заявки;

2.2.     рассылку уведомлений в случае изменения статуса заявки;

2.3.     поиск информации;

2.4. возможность корректировки личных данных и получение справок по их актуальному состоянию;

2.5.     обеспечение поддержки принятия решения ОПМПК:

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

-    рекомендации по обеспечению инклюзивного образования;

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

3.     АРМ контролера (ГПМПК):

3.1.     мониторинг исполнения заявки;

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

4.     АРМ администратора контента:

4.1.     возможность линейной корректировки атрибутов основных сущностей системы;

4.2.     внесение изменение в отчетные формы;

4.3.     формирование блока поисковых запросов.

ТЕХНОЛОГИЯ РАБОТЫ

Опишем общую технологию работы, детализируя процесс проведения ПМПК до элементарных функций.

1.     Регистрация в системе

Регистрация Заявителя в системе осуществляется двумя путями: 1.1. или 1.2.

1.1. Родитель или лицо, его замещающее (далее «Родитель») самостоятельно регистрируется в системе, перейдя в раздел регистрации по соответствующему адресу (URL).

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

1.1.2.  При повторном входе в систему, указывается пароль и пользователю автоматически присваивается роль «Заявитель».

1.2.     Родителя регистрируют в ресурсном центре округа.

1.2.1.     Родитель заполняет бумажный бланк регистрационной формы.

1.2.2.  На основании заполненного бланка и документа, удостоверяющего личность, сотрудник центра создает нового пользователя (имя и пароль для авторизации в системе и присваивает ему роль «Заявитель».

2.    Регистрация заявки на первичное проведение ПМПК.

2.1. Заявитель самостоятельно или с помощью сотрудника ресурсного центра создает заявку на проведение ПМПК.

2.2.     Округ выбирается автоматически, согласно регистрационным данным.

2.3.     Заявитель выбирает основание для проведения ПМПК из предложенного списка.

2.4. Заявитель регистрирует идентификационные данные ребенка (ФИО, дата рождения, номер свидетельства о рождении).

2.5. После подтверждения отправки, создается заявка, которой автоматически присваивается статус «Регистрируется».

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

3.      Регистрация заявки на повторное проведение ПМПК.

3.1.     Заявитель создает заявку на проведение ПМПК.

3.2.     Выполняется поиск возможных объектов (детей заявителя).

3.3.     Заявитель выбирает объект для создания заявки.

3.4.     Заявитель подтверждает или корректирует данные ребенка.

3.5.     Заявитель выбирает основание для проведения ПМПК из предложенного списка.

3.6.  После подтверждения отправки, создается заявка, которой автоматически присваивается статус «Регистрируется».

3.7.     Пользователю высылается уведомление, об успешном создании заявки.

4.      Рассмотрение заявки.

4.1.  Согласно расписанию проведения ПМПК, текущей загруженности ОПМПК и нормативу времени, определяется дата/время рассмотрения заявки, которые могут быть скорректирована вручную секретарем ОПМПК.

4.2.  Секретарь ОПМПК подтверждает дату рассмотрения заявки и ее статус автоматически изменяется на «Рассматривается».

4.3.  Высылается автоматическое уведомление председателю ОПМПК и «Заявителю» о дате и времени рассмотрения заявки и о возможном изменении даты и времени.

4.4.  В зависимости от изменения расписания ОПМПК дата и время рассмотрения заявки могут быть скорректированы.

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

4.6.     Заявка рассматривается ПМПК.

4.6.1.     Определяется, первичность проведения ПМПК:

4.6.1.1.  Выполняется автоматический запрос в Базе данных системы по ключевым атрибутам сущности «Заявка»;

4.6.1.2.  Формируется соответствующее визуальное представление и ссылка на результаты предыдущих ПМПК.

4.6.2. Секретарь вносит в БД системы решение ПМПК, при этом использует данные системы поддержки принятия решения по выбору ОУ и рекомендациям по обеспечению инклюзивного образования.

4.6.3.     При изменении ОУ:

4.6.3.1.  Выбирается тип ОУ.

4.6.3.2.  Выбирается номер ОУ списка доступных (определяется принципами шаговой доступности и текущей загруженностью ОУ из специальной БД по округам).

4.6.3.3.  Определяется класс и программа обучения, прочие условия (путем изменения соответствующих атрибутов заявки).

4.6.4. Секретарь сканирует Карту ребенка, протокол, заключение, пакует, используя пароль шифрования, и размещает его в системе, связывая с заявкой

4.6.5. Секретарь вводит решения ПМПК и основание для принятия решения, при этом статус заявки может принять одно из двух значений: «Выданы рекомендации» или «Передано на рассмотрение вышестоящей комиссии».

4.6.6. Участникам процесса (Председателю ПМПК, секретарю ПМПК, Заявителю) высылается уведомление об изменении статуса заявки.

4.6.7. Заявителю по результатам рассмотрения ПМПК в случае согласия с решением ПМПК выдается документ «Путевка в ОУ».

 

4.7. Рассмотрение заявки вышестоящей ПМПК проводится полностью аналогично общему процессу, за исключением п. 4.6.5.

3.    РОЛИ ПОЛЬЗОВАТЕЛЕЙ СИСТЕМЫ

Доступ к АРМам определяется в соответствии с основными ролями пользователей системы:

1. Заявители: регистрируются в системе, регистрируют заявки, корректируют личную информацию.

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

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

4. Аналитики Департамента Образования: вносят изменения в структуру БД в соответствии с требованиями управления процессом, корректируют регистрационные формы ввода информации и отчетные формы, доступны функции Администраторов контента.

5. Председатели ПМПК: получают отчетную информацию в соответствии со списком отчетов, доступна функциональность модуля секретарей.

4.    РЕШЕНИЕ ЗАДАЧ АВТОМАТИЗАЦИИ

На основании формальной постановки задачи, описания процессов создана информационная модель предполагающая возможность использования системы в двух режимах тестовый и рабочий. Объект исследования ПМПК - ребенок характеризуется набором личной информации, в частности ФИО, возраст, нозология, etc. В рабочем режиме система функционирует с соблюдением всех необходимых требований обеспечения безопасности информации [2]. В тестовом режиме, некоторые требования можно не соблюдать, т.к. в тестовом режиме не используются реальные данные об объектах исследования, зато необходимо быстро и четко идентифицировать заявки визуально для отработки процесса мониторинга.

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

1.   Процесс прохождения заявки

2.    Обеспечение требований системы безопасности.

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

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

Третий шаг. Осуществление мер информационной безопасности. Выполнение этих требований [2] привело бы к необходимости существенно увеличивать срок проекта. Есть только один способ их избежать - обезличить передаваемую информацию, воспользовавшись уникальностью заявки и реализацией второго шага. Действительно, при мониторинге исполнения заявки важен сам факт ее наличия, а не объект исследования. Заявитель знает номер заявки, так как он является единственным заинтересованным лицом, согласно новой технологии проведения ПМПК (согласно старой технологии Заявителю выдавалась «Путевка» в соответствующее коррекционное ОУ, следовательно появлялись заинтересованные лица: «Департамент образования» и указанное в путевке коррекционное ОУ). Таким образом, третий шаг решения приводит систему в соответствие требованиям информационной безопасности. Если в дополнении к этому обезличить пакет документов, можно осуществлять запрос к личной информации из базы данных системы.

В тестовом режиме можно осуществлять мониторинг заявки с выводом ФИО объекта исследования.

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

5.    РЕАЛИЗАЦИЯ ИНФОРМАЦИОННОЙ МОДЕЛИ

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

 

Заявители

 

 

Код родителя

Число

Идентификатор

Фамилия

Текст

Имя

Текст

Отчество

Текст

Дата рождения

Дата

Документ

Тип

Текст

Серия

Текст

Номер

Число

Округ

Текст

Степень родства

Текст

Роль

Текст

 

Атрибуты: Округ, Степень родства, Роль - выбираются из списка, определяемого одноименными сущностями. Атрибуты и сущности, необходимые для осуществления авторизации заявителя рассматриваются вне данной статьи.

Объекты исследования

Код объекта

Число

Идентификатор

Фамилия

Текст

Имя

Текст

Отчество

Текст

Дата рождения

Дата

 

Документ

Тип

Текст

Идентификатор

Серия

Текст

Номер

Число

ОУ

Тип

Текст

Номер

Число

 

Атрибуты: ОУ: Тип и Номер выбираются из списка, определяемого одноименными сущ­ностями.

Заявка

Уникальный номер заявки

Пароль

Идентификатор

Дата заявки

Дата

Заявитель

Число

Объект

Число

Основание

Текст

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

 

Исполнение

Номер заявки

Число

Идентификатор

Дата изменения

Дата

Действие

Текст

Статус

Логическое

 

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

Сопроводительные документы

Номер заявки

Число

Идентификатор

Название документа

Текст

Тип документа

Текст

Документ

Текст

Атрибут: Тип документа выбирается из списка, определяемого одноименной сущностью.

 

Информационные объекты системы поддержки принятия решения и связи сущностей системы приводятся в Приложении 1

Атрибуты: «Статусы», «Округа», «Роли», «Образовательные учреждения», «Типы ОУ», «Типы документов» представляют собой простейшие классификаторы, которые также нет особого смысла рассматривать в контексте данной задачи.

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

6.     ПЕРЕЧЕНЬ РАБОЧИХ ФОРМ И ОТЧЕТОВ

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

1.     Формы ввода

Форма «Регистрации пользователей системы» соответствует заполнению сущности «Заявитель». Данная структура определена из соображений возможного соответствия роли родитель и роли исполнителя (члена ПМПК).

Форма «Вход в систему» предполагает определение кортежа «Заявитель».

Форма «Ввод Заявки» позволяет определить пару Заявитель-Ребенок (сущность «Объекты исследования»), создать уникальный номер заявки, выбрав основание для ее создания из соответствующего справочника и предъявить его заявителю.

Форма «Исполнение» позволяет изменять ее статус и добавлять или корректировать пакет документов (Сущности «Исполнение» и «Сопроводительные документы»).

Примеры форм для реализации тестового и основного режима см. в Приложении 2.

2.     Запросы и отчеты

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

3.     Мониторинг исполнения заявки

Отчет о состоянии заявки (информация о статусе и основании для его изменения).

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

4.1.     Электронная копия пакета документов.

4.2.     Заключение ПМПК.

5.     Аналитические отчеты.

5.1.     Журнал предварительной записи детей на обследование.

5.2.     Журнал учета детей, прошедших обследование.

5.3.     Отчеты ПМПК.

5.4.  Заключение системы поддержки принятия решений о рекомендуемом коррекционном ОУ и требованиях для обеспечении инклюзивного образования.

7.     ЖУРНАЛ ПРОЕКТА

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

28 февраля Перед руководством факультета ИТ МГППУ поставлена задача создания технического задания для автоматизации процесса проведения ПМПК. Срок для подготовки ультракороткий - 2 дня. Начинаем буквально «с нуля» (с изучения бизнес процессов существующих ПМПК и знакомства с методической литературой).

29 марта Подготовлен проект технического задания.

30   марта Проект ТЗ представлен на совещании Департамента Образования совместно с представителями Департамента информационных технологий, руководителями ПМПК и руководством МГППУ. Согласно протоколу совещания, реализация ТЗ возлагается на Департамент информационных технологий.

31  марта На совещании, организованным первым проректором МГППУ, с участием представителей ГПМПК и ОПМПК центрального округа уточнены и окончательно определены бизнес-процессы ПМПК, включая взаимодействие городской и окружных комиссий, родителей и представителей образовательных учреждений г. Москвы. Техническое задание передано представителю Департамента информационных технологий

Комментарий: казалось, что проект на этом завершен, о проекте потихоньку забыли.

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

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

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

35      марта Начало тестирования.

36      марта Реализована система поддержки принятия решения ПМПК.

37    марта На совещании Департамента Образования, перед руководителями окружных и городского ПМПК представлен работающий прототип системы. Начался процесс передачи программного обеспечения в эксплуатацию в Департамент образования.

Комментарий: Особым достижением можно считать, что разработанные сотрудниками МГППУ новые бизнес-процессы для проведения ПМПК, согласно изменениям в законодательстве РФ, были приняты практически безоговорочно.

38     марта На базе МГППУ было проведено обучение представителей ОПМПК и ГПМПК новым технологиям проведения ПМПК с использованием информационной системы

39  апреля Согласно приказу приступили к эксплуатации информационной системы. Сотрудники ф-та ИТ МГППУ оказывают консультационную помощь в сопровождении системы и администрировании БД.

8.     ВЫВОДЫ

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

 

Приложение 1. Диаграмма сущность связь БД ИС «ПМПК» Indexes

 

 


Литература

  1. ФЕДЕРАЛЬНЫЙ ЗАКОН “ОБ ОСНОВНЫХ ГАРАНТИЯХ ПРАВ РЕБЕНКА В РОССИЙ- СКОЙ ФЕДЕРАЦИИ” (№124-ФЗ)/ http://base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=126547
  2. ФЕДЕРАЛЬНЫЙ ЗАКОН «О ПЕРСОНАЛЬНЫХ ДАННЫХ» (№152-ФЗ)/ http://base.consultant.ru/cons/cgi/online.cgi?req=doc;base=LAW;n=117587
  3. Приказ об утверждении положения о ПМПК: http://www.edu.ru/db-mon/mo/Data/d_09/m95.html
  4. Положение о ПМПК http://www.edu.ru/db-mon/mo/Data/d_09/prm95-1.htm
  5. Томсон Л., Веллинг Л. Разработка Web-приложений на PHP и MySQL. – К.: «ДиаСофт», 2001. – 672 с.
  6. СУБД MySQL. http://odba.org/
  7. Web-дизайн: Тонкости, хитрости и секреты. Борис Леонтьев/ http://www.xserver.ru/computer/ langprogr/html/1/
  8. 21 ошибка программиста PHP. Стерлинг Хьюз/ http://www.xserver.ru/computer/langprogr/php/38/

Информация об авторах

Лукин Владимир Владимирович, кандидат физико-математических наук, доцент кафедры прикладной математики факультета информационных технологий МГППУ, Москва, Россия, e-mail: vladimirvlukin@gmail.com

Панфилова Анастасия Сергеевна, кандидат технических наук, научный сотрудник, Институт психологии РАН (ФГБУН «ИП РАН»), Москва, Россия, ORCID: https://orcid.org/0000-0003-1892-5901, e-mail: panfilova87@gmail.com

Метрики

Просмотров

Всего: 1062
В прошлом месяце: 3
В текущем месяце: 3

Скачиваний

Всего: 580
В прошлом месяце: 5
В текущем месяце: 8