ИЗВЕЩЕНИЕ О ПРОВЕДЕНИИ ОТКРЫТОГО КОНКУРСА

1. Форма торгов: открытый конкурс. 2.Номер конкурса: № 33-09-11/Развитие АСАВ (НИУ) 3. Наименование заказчика: федеральное государственное автономное образовательное учреждение высшего профессионального образования "Национальный исследовательский университет "Высшая школа экономики" (далее – Заказчик). Адрес заказчика: 101000 г. Москва, ул. Мясницкая, дом 20. Номер тел/факса: (495) 628 47 03 Номера телефонов: (495) 772-95-90*1424, (495) 772-95-90*1422 Адрес электронной почты: zakupki@hse.ru. 4. Предмет договора: Оказание услуг по разработке и внедрению новой функциональности автоматизированной системы (АСАВ), в рамках реализации «Программы развития государственного образовательного бюджетного учреждения высшего профессионального образования «Государственный университет – Высшая школа экономики», в отношении которого установлена категория «национальный исследовательский университет», на 2009 – 2018 годы», передаче Заказчику результатов оказанных услуг, а также предоставлению Заказчику прав на использование результатов, являющихся результатом интеллектуальной деятельности 5. Место оказания услуг: указано в конкурсной документации. 6. Сведения о начальной цене договора: 2 448 000,00 рублей 7. Срок, место и порядок предоставления конкурсной документации: Конкурсная документация предоставляется по адресу: 101000 г. Москва, ул. Мясницкая, дом 20, комната К-308 Сроки предоставления: с «13» сентября 2011 года до 13 ч. 00 мин. (время московское) «13» октября 2011 года. Порядок предоставления конкурсной документации: Конкурсная документация предоставляется лицу на основании его заявления, поданного в письменной форме, в течение трех рабочих дней с момента получения соответствующего заявления. Плата за предоставление документации не взимается. 8. Официальный сайт, на котором размещена Конкурсная документация: http://www.hse.ru/

9. Порядок проведения конкурса: Конкурс будет проведен в соответствии с правилами, установленными конкурсной документацией. Претенденты должны оформить и предоставить заявку на участие в конкурсе в соответствии с требованиями конкурсной документации. Прием заявок в письменном виде осуществляется по адресу: 101000 г. Москва, ул. Мясницкая, дом 20, каб. К-308 ежедневно в рабочие дни с 10 часов 00 минут до 18 часов 00 минут по московскому времени, начиная с «13» сентября 2011 года.

2

Окончание подачи заявок на участие в конкурсе, публичное вскрытие заявок на участие в конкурсе в 13 часов 00 минут по московскому времени «13» октября 2011 года по адресу: 101000 г. Москва, ул. Мясницкая, дом 20 Дата окончания рассмотрения заявок на участие в конкурсе «17» октября 2011 года. Дата подведения итогов конкурса: «20» октября 2011 года. Просьба учитывать пропускной режим Высшей школы экономики. Заказ пропуска осуществляется по телефону: (495) 628-47-03. 10. Сведения о возможности проведения переторжки: нет 11. Порядок определения победителя конкурса: Победитель конкурса будет определен комиссией по размещению заказов на основании результатов оценки и сопоставления заявок на участие в конкурсе, проведенной в соответствии с критериями и в порядке, установленными конкурсной документацией. 12. Порядок оформления и предоставления заявок на участие в конкурсе: Для участия в конкурсе претендент должен подготовить заявку на участие в конкурсе, оформленную в полном соответствии с требованиями конкурсной документации. 13. Сведения о предоставляемых преференциях: нет 14. Сведения о размере и порядке предоставления обеспечения заявки на участие в конкурсе, обеспечения исполнения договора: указано в конкурсной документации. 15. Срок заключения договора: договор может быть заключен не ранее чем через три рабочих дня со дня размещения на официальном сайте Заказчика протокола, составленного по результатам размещения заказа, и не позднее десяти дней после завершения торгов и оформления протокола. 16. Отказ от проведения конкурса:  Заказчик вправе принять решение об отказе от проведения открытого конкурса в любое время до определения победителя конкурса в порядке, установленном конкурсной документацией.

3

Утверждаю: Директор по информационным

технологиям

_________________ О.М. Щербаков

Конкурсная документация открытого конкурса

на оказание услуг по разработке и внедрению новой функциональности автоматизированной системы (АСАВ), в рамках реализации «Программы развития

государственного образовательного бюджетного учреждения высшего профессионального образования «Государственный университет – Высшая школа

экономики», в отношении которого установлена категория «национальный исследовательский университет», на 2009 – 2018 годы», передаче Заказчику результатов оказанных услуг, а также предоставлению Заказчику прав на использование результатов, являющихся результатом интеллектуальной

деятельности

№ 33-09-2011/ Развитие АСАВ (НИУ)

Согласовано: Заместитель Директора по информационным технологиям_______________________________ С.Г. Билевский

г. Москва

4

1. Общие сведения 1.1. Федеральное государственное автономное образовательное учреждение

высшего профессионального образования «Национальный исследовательский университет «Высшая школа экономики» (далее – Заказчик, университет), проводит открытый конкурс (далее – Конкурс) с целью определения в соответствии с процедурами, условиями и положениями, приведенными в настоящей документации [поставщика, исполнителя, подрядчика] с которым будет заключен договор, предмет которого указан в извещении о проведении Конкурса, в информационной карте Конкурса и в разделе 9 «Техническое задание» настоящей документации.

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

1.3. Термины и определения, используемые в настоящей документации. 1.3.1. Договор – соглашение об установлении гражданских прав и обязанностей,

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

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

1.3.3. Извещение о Конкурсе – опубликованные на официальном сайте университета сведения о проведении Конкурса.

1.3.4. Победитель Конкурса - Участник Конкурса, предложивший лучшее сочетание условий исполнения Договора и заявке на участие, в Конкурсе которого при сопоставлении заявок на участие в Конкурсе, производимом по результатам оценки таких заявок согласно системе критериев, установленной настоящей документацией, было присуждено первое место.

1.3.8. Претендент - заинтересованное в участии в Конкурсе юридическое лицо, объединение юридических лиц, индивидуальный предприниматель.

1.3.9. Участник размещения заказа - юридическое лицо, или объединение юридических лиц, или индивидуальный предприниматель, претендующие на участие в Конкурсе на право заключить договор, и представившие заявку на участие в Конкурсе.

1.3.10. Участник Конкурса – юридическое лицо, или объединение юридических лиц, или индивидуальный предприниматель, допущенный конкурсной комиссией по результатам рассмотрения заявок на участие в Конкурсе к участию в Конкурсе.

1.4. Разъяснения положений настоящей документации. 1.4.1. Любой претендент в любое время с момента размещения на официальном

сайте университета извещения о проведении Конкурса вправе направить Заказчику запрос разъяснений положений конкурсной документации в письменной форме в срок не позднее чем за пять рабочих дня до дня окончания подачи заявок на участие в конкурсе.

1.4.2. Заказчик в течение трех рабочих дней со дня поступления запроса на разъяснение положений конкурсной документации направляет разъяснения положений

5

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

1.5. Внесение изменений в извещение о проведении Конкурса. 1.5.1. В любое время до истечения срока представления заявок на участие в

конкурсе Заказчик вправе по собственной инициативе либо в ответ на запрос претендента внести изменения в извещение о проведении открытого конкурса.

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

1.6. Внесение изменений в конкурсную документацию. 1.6.1. В любое время до истечения срока представления заявок на участие в

конкурсе Заказчик вправе по собственной инициативе либо в ответ на запрос какого-либо претендента внести изменения в конкурсную документацию.

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

1.7. Отказ от проведения конкурса 1.7.1. Заказчик вправе принять решение об отказе от проведения открытого

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

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

1.7.3. В случае, если решение об отказе от проведения открытого конкурса принято до вскрытия конвертов с заявками на участие в конкурсе, заявки на участие в конкурсе, полученные до принятия решения об отказе от проведения открытого конкурса, не вскрываются и по письменному запросу участника размещения заказа, подавшего заявку на участие в конкурсе, передаются данному участнику по адресу Заказчика.

6

1.8. Сведения о преференциях Заказчик устанавливает преференции участникам размещения заказа, если это

требование указано в Информационной карте Конкурса, в том числе: 1) поставщикам инновационных и энергосберегающих товаров, работ, услуг; 2) отечественным производителям. 3) для субъектов малого предпринимательства. В этом случае:

a) Участники размещения заказов должны соответствовать требованиям, установленным статьей 4 Федерального закона от 24 июля 2007 г. № 209-ФЗ «О развитии малого и среднего предпринимательства Российской Федерации», в соответствии с которым к субъектам малого предпринимательства относятся внесенные в единый государственный реестр юридических лиц потребительские кооперативы и коммерческие организации (за исключением государственных и муниципальных унитарных предприятий), а также физические лица, внесенные в единый государственный реестр индивидуальных предпринимателей и осуществляющие предпринимательскую деятельность без образования юридического лица (далее - индивидуальные предприниматели), крестьянские (фермерские) хозяйства, соответствующие следующим условиям: - для юридических лиц - суммарная доля участия Российской Федерации, субъектов Российской Федерации, муниципальных образований, иностранных юридических лиц, иностранных граждан, общественных и религиозных организаций (объединений), благотворительных и иных фондов в уставном (складочном) капитале (паевом фонде) указанных юридических лиц не должна превышать двадцать пять процентов (за исключением активов акционерных инвестиционных фондов и закрытых паевых инвестиционных фондов), доля участия, принадлежащая одному или нескольким юридическим лицам, не являющимся субъектами малого предпринимательства, не должна превышать двадцать пять процентов; - средняя численность работников за предшествующий календарный год не должна превышать следующего предельного значения средней численности работников для субъектов малого предпринимательства - сто человек включительно.

б) При размещении заказа путем проведения открытого конкурса, в которых участниками размещения заказа являются субъекты малого предпринимательства, участникам размещения заказа, не являющимся субъектами малого предпринимательства, будет отказано в допуске к участию в конкурсе.

1.9. Переговоры. 1.8.1. При проведении Конкурса не допускаются переговоры Заказчика или

комиссии по размещению заказов с Претендентами, Участниками размещения заказа или Участниками Конкурса.

2. Порядок проведения Конкурса

Прием заявок на участие в Конкурсе 2.1. Со дня размещения извещения на официальном сайте университета и до

окончания срока подачи заявок на участие в конкурсе, установленного в извещении о проведении открытого конкурса, Заказчик осуществляет прием заявок на участие в конкурсе.

2.2. Для участия в конкурсе претендент должен подать в запечатанном конверте заявку на участие в конкурсе по форме и в порядке, установленным конкурсной документацией. Претендент вправе подать одну заявку на участие в конкурсе в отношении нескольких предметов конкурса (лотов). Претендент вправе подать только одну заявку на участие в конкурсе в отношении каждого предмета конкурса (лота).

7

2.3. Все заявки на участие в конкурсе, полученные до истечения срока подачи заявок на участие в конкурсе, регистрируются Заказчиком. По требованию участника размещения заказа Заказчик выдает расписку о получении конверта с заявкой на участие в конкурсе, с указанием даты и времени его получения.

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

2.4. Участник размещения заказа вправе изменить или отозвать ранее поданную заявку на участие в конкурсе в порядке, предусмотренном конкурсной документацией. Изменение и (или) отзыв заявок на участие в конкурсе после истечения срока подачи заявок на участие в конкурсе, установленного конкурсной документацией, не допускается.

2.5. Если по окончании срока подачи заявок на участие в конкурсе, установленного конкурсной документацией, Заказчиком будет получена только одна заявка на участие в конкурсе или не будет получено ни одной заявки на участие в конкурсе, конкурс будет признан несостоявшимся.

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

2.6. Если по окончании срока подачи заявок на участие в конкурсе, установленного конкурсной документацией, Заказчиком будет получена только одна заявка на участие в конкурсе, комиссия по размещению заказов осуществит вскрытие конверта с такой заявкой и рассмотрит ее в порядке, установленном конкурсной документацией. Если рассматриваемая заявка на участие в конкурсе и подавший такую заявку участник размещения заказа соответствуют требованиям и условиям, предусмотренным конкурсной документацией, университет заключит договор с участником размещения заказа, подавшим такую заявку на участие в конкурсе, на условиях конкурсной документации, проекта договора и заявки на участие в конкурсе, поданной участником.

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

Вскрытие конвертов с заявками на участие в Конкурсе 2.8. Публично в день, во время и в месте, указанные в извещении о проведении

открытого конкурса, комиссией по размещению заказов вскрываются конверты с заявками на участие в конкурсе.

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

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

8

поданные ранее заявки таким участником не отозваны, все заявки на участие в конкурсе участника размещения заказа, поданные в отношении данного лота, не рассматриваются и возвращаются участнику.

2.10. Участники размещения заказа, подавшие заявки на участие в конкурсе, или их представители вправе присутствовать при вскрытии конвертов с заявками на участие в конкурсе.

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

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

Рассмотрение заявок на участие в Конкурсе 2.12. Комиссия по размещению заказов в срок не более десяти рабочих дней со дня

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

2.13. Участнику размещения заказа будет отказано в признании его участником конкурса в случаях:

а) непредставления оригиналов и копий документов, а также иных сведений, требование о наличии которых установлено конкурсной документацией либо наличие в таких документах недостоверных сведений об участнике размещения заказа или о товарах, о работах, об услугах, соответственно на поставку, выполнение, оказание, которых размещается заказ;

б) несоответствия участника размещения заказа требованиям к участникам конкурса, установленным конкурсной документацией;

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

2.14. При размещении заказов на выполнение работ по строительству, реконструкции, капитальному ремонту объектов капитального строительства, в случае, если цена договора, предложенная участником размещения заказа снижена более, чем на

9

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

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

2.15. При необходимости в ходе рассмотрения заявок на участие в конкурсе, комиссия по размещению заказов вправе потребовать от участников размещения заказа разъяснения сведений, содержащихся в заявках на участие в конкурсе. Требования университета, направленные на изменение содержания заявки на участие в конкурсе, а также разъяснения участника размещения заказа, изменяющие суть предложения, содержащегося в поданной таким участником заявке на участие в конкурсе, не допускаются. Запрос о разъяснении сведений, содержащихся в заявках на участие в конкурсе, и ответ на такой запрос должны оформляться в письменном виде.

2.16. В случае, если участник размещения заказа, которому был направлен запрос о разъяснении сведений, содержащихся в заявке на участие в конкурсе, или запрос предоставления обоснования возможности исполнения договора по предложенной цене договора, не предоставит соответственно запрашиваемые разъяснения заявки на участие в конкурсе и (или) обоснования цены договора в порядке и в срок, установленные в запросе, заявка на участие в конкурсе такого участника подлежит отклонению.

2.17. Отказ в допуске к участию в конкурсе по основаниям, не указанным в конкурсной документации, не допускается.

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

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

2.20. Если на основании результатов рассмотрения заявок на участие в конкурсе, будет принято решение о несоответствии всех участников размещения заказа требованиям, предъявляемым к участникам размещения заказа, и (или) о несоответствии всех заявок на участие в конкурсе, установленным конкурсной документацией

10

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

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

Оценка и сопоставление заявок на участие в Конкурсе 2.22. Комиссия по размещению заказов в течение десяти дней со дня окончания

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

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

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

2.25. Протокол оценки и сопоставления заявок на участие в конкурсе формируется Заказчиком и подписывается всеми присутствующими членами комиссии по размещению заказов и представителем подразделения-заказчика непосредственно после подведения итогов конкурса. Указанный протокол размещается Заказчиком в течение дня, следующего после дня подписания такого протокола, на официальном сайте университета.

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

Проведение переторжки 2.27. Конкурс с переторжкой проводится в случае, если в извещении указана

возможность ее проведения. 2.28. В течение трех рабочих дней со дня подписания протокола оценки и

сопоставления заявок на участие в конкурсе Заказчик направляет приглашения

11

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

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

2.30. Перед началом проведения переторжки Заказчиком осуществляется проверка документов и полномочий, необходимых для участия в переторжке, присутствующих представителей участников конкурса. Представители участников конкурса должны предоставить удостоверение личности и подтверждение полномочий представлять интересы участника конкурса.

2.31. Участники конкурса или их представители непосредственно перед началом переторжки регистрируются Заказчиком. При регистрации участникам конкурса или их представителям выдаются карточки с номерами (далее – карточки). Каждым участником конкурса может быть получена только одна карточка. Одно и то же лицо не может быть представителем двух и более участников конкурса.

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

Член комиссии по размещению заказов, проводимый переторжку (далее – ведущий переторжки), объявляет начало проведения переторжки. Началом переторжки считается момент объявления ведущим переторжки о начале проведения переторжки, после чего ведущий переторжки предлагает участникам заявлять свои предложения о цене договора.

2.33. Участник конкурса после объявления ведущим переторжки цены договора, предложенной участником конкурса, заявке на участие в конкурсе которого, было присуждено первое место, и цены договора, сниженной в соответствии с «шагом переторжки», поднимает карточку в случае, если он согласен заключить договор по объявленной цене.

2.34. Ведущий переторжки объявляет номер карточки участника конкурса, который первым поднял карточку после объявления председателем цены договора, предложенной участником конкурса, заявке на участие в конкурсе которого было присуждено первое место, и цены договора, сниженной в соответствии с «шагом переторжки», а также новую цену договора, сниженную в соответствии с «шагом переторжки», и «шаг переторжки», в соответствии с которым снижается цена.

2.35. В случае если после троекратного объявления ведущим переторжки последнего предложения о цене договора или о последней поступившей более низкой цене договора ни один из участников конкурса (представителей участника конкурса) не заявит о своем намерении предложить более низкую цену договора, ведущий переторжки должен снизить «шаг переторжки» на 0,5 процента цены договора, но не ниже 0,5 процента цены договора и предложить заявлять предложения о цене договора, сформированной в соответствии со сниженным «шагом переторжки».

2.36. Переторжка прекращается, когда «шаг переторжки» составляет 0,5 процента цены договора и ни один участник конкурса (представитель участника конкурса) после троекратного объявления ведущим переторжки цены договора не поднял карточку.

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

2.38. Завершая переторжку, ведущий переторжки объявляет об окончании проведения переторжки, оглашает номер карточки и наименование участника конкурса, признанного победителем конкурса с переторжкой.

2.39. По результатам переторжки Заказчик формирует протокол проведения переторжки, который подписывается всеми присутствующими членами комиссии по размещению заказов и представителем подразделения-заказчика непосредственно после

12

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

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

3. Порядок участия в Конкурсе и инструкции по оформлению Участниками размещения заказа

заявок на участие в Конкурсе 3.1. Для участия в Конкурсе Претендент должен подготовить заявку на участие в

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

3.2. Заявка на участие в Конкурсе должна быть оформлена по форме, приведенной в настоящей документации. Претендент должен подать заявку на участие в Конкурсе в письменной форме в запечатанном конверте.

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

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

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

3.6. Заявка на участие в Конкурсе подается в запечатанном конверте, маркированном следующим образом:

а) наименование и адрес Участника размещения заказа, представившего заявку на участие в Конкурсе;

б) наименование и адрес Заказчика, указанный в Информационной карте Конкурса;

в) наименование Конкурса, указанное в Информационной карте Конкурса; г) слова «ЗАЯВКА НА УЧАСТИЕ КОНКУРСЕ»; д) слова «НЕ ВСКРЫВАТЬ ДО…» (указать время и дату, указанные в

Информационной карте Конкурса как срок вскрытия конвертов с заявками на участие Конкурсе).

13

3.7. Заказчик не несет никакой ответственности в случае потери или досрочного вскрытия конверта с заявкой на участие в Конкурсе, оформленного с нарушением требований пункта 3.6. настоящей документации.

3.8. Участник размещения заказа вправе подать только одну заявку на участие в Конкурсе.

3.9. Заявка на участие в Конкурсе должна содержать: 3.9.1. для юридического лица: а) заполненную форму заявки на участие в конкурсе в соответствии с требованиями

конкурсной документации (оригинал); б) анкету юридического лица по установленной в конкурсной документации

форме; в) копии учредительных документов с приложением имеющихся изменений

(нотариально заверенные копии); г) выписку из единого государственного реестра юридических лиц или

нотариально заверенную копию такой выписки, полученную не ранее чем за 30 дней до дня размещения на официальном сайте университета извещения о проведении открытого конкурса;

д) решение об одобрении или о совершении крупной сделки (оригинал) либо копия такого решения в случае, если требование о необходимости наличия такого решения для совершения крупной сделки установлено законодательством Российской Федерации, учредительными документами юридического лица и если для участника размещения заказа поставка товаров, выполнение работ, оказание услуг, являющихся предметом договора, или внесение денежных средств в качестве обеспечения заявки на участие в конкурсе, обеспечения исполнения договора является крупной сделкой;

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

ж) справку об исполнении налогоплательщиком обязанности по уплате налогов, сборов, страховых взносов, пеней и налоговых санкций, выданную соответствующими подразделениями Федеральной налоговой службы не ранее чем за 60 дней до срока окончания приема заявок на участие в конкурсе;

з) в случае, если начальная цена договора превышает три миллиона рублей, участник размещения заказа представляет бухгалтерские балансы и отчеты о прибылях и убытках за последний отчетный год и истекшие месяцы текущего года (копии);

и) документы, подтверждающие право участника размещения заказа на поставку товара, производителем которого он не является, и предоставление фирменных гарантий производителя товара (копии);

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

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

14

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

м) документы, подтверждающие соответствие участника размещения заказа установленным требованиям и условиям допуска к участию в конкурсе (оригиналы);

н) документы, подтверждающие внесение участником размещения заказа обеспечения заявки на участие в конкурсе, в случае установления в конкурсной документации требования обеспечения заявки на участие в конкурсе;

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

3.9.2. для индивидуального предпринимателя: а) заполненную форму заявки на участие в конкурсе в соответствии с требованиями

конкурсной документации; б) фамилию, имя, отчество, паспортные данные, сведения о месте жительства,

номер контактного телефона; в) выписку из единого государственного реестра индивидуальных

предпринимателей или нотариально заверенную копию такой выписки, полученную не ранее чем за 30 дней до дня размещения на официальном сайте университета извещения о проведении открытого конкурса;

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

д) справку об исполнении налогоплательщиком обязанности по уплате налогов, сборов, страховых взносов, пеней и налоговых санкций, выданную соответствующими подразделениями Федеральной налоговой службы не ранее чем за 60 дней до срока окончания приема заявок на участие в конкурсе;

е) в случае, если начальная цена договора превышает один миллион рублей, участник размещения заказа представляет бухгалтерские балансы и отчеты о прибылях и убытках за последний отчетный год и истекшие месяцы текущего года (копии);

ж) документы, подтверждающие право участника размещения заказа на поставку товара, производителем которого он не является, и предоставление фирменных гарантий производителя товара (копии);

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

и) документы, подтверждающие соответствие участника размещения заказа установленным требованиям и условиям допуска к участию в конкурсе (оригиналы);

к) документы, подтверждающие внесение участником размещения заказа обеспечения заявки на участие в конкурсе, в случае установления в конкурсной документации требования обеспечения заявки на участие в конкурсе;

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

15

3.9.3. для простого товарищества: а) договор простого товарищества участников; б) документы и сведения в соответствии с пунктом 3.9.1 конкурсной документации

участника размещения заказа, которому в соответствии с договором простого товарищества поручено подать заявку на участие в конкурсе.

3.10. Для участия в Конкурсе Участник размещения заказа заполняет формы, приведенные в настоящей документации, в соответствии с инструкциями по заполнению таких форм, приведенными в настоящей документации.

3.11. Изменение и отзыв заявок на участие в Конкурсе 3.11.1. Участник размещения заказа вправе внести изменения или отозвать

поданную заявку на участие в Конкурсе в любое время до дня окончания срока подачи заявок на участие в Конкурсе, указанного в Информационной карте Конкурса.

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

а) надпись «ИЗМЕНЕНИЕ ЗАЯВКИ НА УЧАСТИЕ В КОНКУРСЕ»; б) регистрационный номер, присвоенный Заказчиком при приеме заявки на

участие в Конкурсе в соответствии с пунктом 3.2. настоящей документации; в) наименование и адрес Участника размещения заказа, представившего изменения

заявки на участие в Конкурсе; г) наименование и адрес Заказчика, указанное в Информационной карте

Конкурса; д) наименование Конкурса, указанное в Информационной карте Конкурса, на

участие в котором была подана заявка; 3.11.3. Отзыв заявки на участие в Конкурсе оформляется в форме письменного

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

а) надпись «ОТЗЫВ ЗАЯВКИ НА УЧАСТИЕ В КОНКУРСЕ»; б) регистрационный номер, присвоенный Заказчиком при приеме заявки на участие

в Конкурсе в соответствии с пунктом 3.2. настоящей документации; в) наименование и адрес Участника размещения заказа, представившего отзыв

заявки на участие в Конкурсе; г) наименование и адрес Заказчика, указанное в Информационной карте

Конкурса; д) наименование Конкурса, указанное в Информационной карте Конкурса, на

участие в котором была подана заявка. 4.Требования к Участникам размещения заказа 4.1. Для участия в Конкурсе Участник размещения заказа должен соответствовать

требованиям к правоспособности, квалификации и репутации, установленным в Информационной карте Конкурса.

5.Обеспечение заявок на участие в конкурсе

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

16

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

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

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

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

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

5.4. Университет удерживает сумму обеспечения заявки на участие в конкурсе в случаях невыполнения участником размещения заказа обязательств, предусмотренных пунктом 5.2 конкурсной документации.

5.6. Обеспечение заявки на участие в конкурсе возвращается: а) участникам размещения заказа, претендентам, внесшим обеспечение заявок на

участие в конкурсе - в течение пяти рабочих дней со дня принятия решения об отказе от проведения конкурса;

б) участнику размещения заказа, подавшему заявку на участие в конкурсе, полученную после окончания приема заявок на участие в конкурсе - в течение пяти рабочих дней со дня получения такой заявки;

в) участнику размещения заказа, подавшему заявку на участие в конкурсе и отозвавшему такую заявку до дня и времени начала процедуры вскрытия конвертов с заявками на участие в конкурсе - в течение пяти рабочих дней со дня поступления в Управление закупок уведомления об отзыве заявки на участие в конкурсе;

г) участнику размещения заказа, подавшему единственную заявку на участие в конкурсе, которая соответствует всем требованиям и условиям, предусмотренным конкурсной документацией - в течение пяти рабочих дней со дня заключения договора с таким участником;

д) участнику размещения заказа, подавшему заявку на участие в конкурсе и не допущенному к участию в конкурсе - в течение пяти рабочих дней со дня подписания протокола рассмотрения заявок на участие в конкурсе;

е) единственному участнику размещения заказа, признанному участником конкурса - в течение пяти рабочих дней со дня заключения договора с таким участником;

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

з) участнику конкурса, заявке на участие в конкурсе которого, был присвоен второй номер - в течение пяти рабочих дней со дня заключения договора с победителем конкурса или с таким участником конкурса;

и) победителю конкурса - в течение пяти рабочих дней со дня заключения с ним договора.

6.Порядок заключения договора 6.1. По результатам размещения заказа на поставки товаров, выполнение работ,

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

17

размещения заказа, с которым заключается договор, в проект договора, являющийся неотъемлемой частью документации о размещении заказа.

6.2. Заказчик заключит Договор: а) с Победителем Конкурса; б) с Участником Конкурса, заявке на участие в Конкурсе которого, присвоен второй

номер – в случае, если Победитель Конкурса будет признан уклонившимся от заключения договора;

в) с Участником Конкурса, заявке на участие в Конкурсе которого, присвоен второй номер – в случае, если Заказчик примет решение об отказе от заключения договора с Победителем Конкурса в соответствии с пунктом 6.9. настоящей документации;

г) с Участником размещения заказа, единственным признанным Участником Конкурса, – в случае, описанном в пункте 2.21. настоящей документации;

д) с Участником размещения заказа, подавшим единственную заявку на участие в Конкурсе, в случае, описанном в пункте 2.6. настоящей документации.

е) с Участником Конкурса, заявке на участие в Конкурсе которого, присвоен второй номер – в случае расторжения договора с Победителем Конкурса в связи с неисполнением или ненадлежащим исполнением Победителем Конкурса, своих обязательств по такому договору.

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

6.4. Заказчик признает уклонившимся от заключения договора Участника размещения заказа, подавшего единственную заявку на участие в Конкурсе, Участника размещения заказа, единственного признанного Участником Конкурса, Участника Конкурса, заявке на участие в Конкурсе которого, было присуждено второе место, Победителя Конкурса в случае непредоставления такими Участниками в срок, предусмотренный пунктом 6.3. настоящей документации, подписанного договора, а также обеспечения исполнения договора (в случае, если требование обеспечения исполнения договора установлено в Информационной карте Конкурса).

6.5. Заказ признается размещенным со дня заключения Договора. 6.6. В случае, если победитель размещения заказа или участник размещения заказа,

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

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

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

18

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

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

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

б) приостановления деятельности участников размещения заказа в порядке, предусмотренном Кодексом Российской Федерации об административных правонарушениях;

в) предоставления участниками размещения заказа заведомо ложных сведений, содержащихся в представленных ими документах;

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

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

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

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

19

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

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

7. Обеспечение исполнения договора

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

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

7.3. В случае, если обеспечением исполнения договора является договор поручительства, поручителем выступает юридическое лицо, государственная регистрация которого осуществлена в установленном порядке на территории Российской Федерации и которое соответствует следующим требованиям:

1) капитал и резервы поручителя, указанные в соответствующем разделе бухгалтерской отчетности, должны составлять не менее чем триста миллионов рублей и превышать размер поручительства не менее чем в десять раз;

2) чистая прибыль поручителя, указанная в соответствующем разделе бухгалтерской отчетности, должна превышать не менее чем в три раза размер поручительства или размер чистой прибыли поручителя должен составлять более чем сто миллионов рублей;

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

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

20

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

21

8. Информационная карта Конкурса

Следующая информация и данные дополняют положения Разделов 1-7 настоящей документации.

Положения Информационной карты Конкурса Заказчик: федеральное государственное автономное образовательное учреждение высшего профессионального образования «Национальный исследовательский университет «Высшая школа экономики» Адрес заказчика: 101000 г. Москва, ул. Мясницкая, дом 20. Номер тел/факса: (495) 628 47 03 Номера телефонов: (495) 772-95-90*1424, (495) 772-95-90*1422 Адрес электронной почты: zakupki@hse.ru. Наименование Конкурса: Оказание услуг по разработке и внедрению новой функциональности автоматизированной системы (АСАВ), в рамках реализации «Программы развития государственного образовательного бюджетного учреждения высшего профессионального образования «Государственный университет – Высшая школа экономики», в отношении которого установлена категория «национальный исследовательский университет», на 2009 – 2018 годы», передаче Заказчику результатов оказанных услуг, а также предоставлению Заказчику прав на использование результатов, являющихся результатом интеллектуальной деятельности Требования, предъявляемые к предмету закупки, приведены в разделе «Техническое задание» настоящей документации. Место, время и дата начала и окончания подачи заявок на участие в конкурсе: Заявки будут приниматься по адресу: 101000 г. Москва, ул. Мясницкая, дом 20, комната К-308 в срок с «13» сентября 2011 года до 13 ч. 00 мин. (время московское) «13» октября 2011 года Время и дата окончания срока подачи заявок на участие в Конкурсе 13 ч. 00 мин. (время московское) «13» октября 2011 года Время, дата и место вскрытия конвертов с заявками на участие в Конкурсе 13 ч. 00 мин. (время московское) «13» октября 2011 года по адресу: 101000 г. Москва, ул. Мясницкая, дом 20 Начальная цена договора: 2 448 000,00 рублей Источник финансирования: Средства программы развития государственного образовательного бюджетного учреждения высшего профессионального образования «Государственный университет – Высшая школа экономики», в отношении которого установлена категория «национальный исследовательский университет», на 2009-2018 годы. Мероприятие 5.2 «Развитие информационной инфраструктуры университета». Порядок формирования цены договора: Указан в «Техническом задании» настоящей документации. Форма срок и порядок оплаты: Указаны в «Техническом задании» настоящей документации. Преференции: нет Сведения о возможности изменения количества оказываемых услуг: Заказчик по согласованию с Исполнителем в ходе исполнения договора вправе изменить не

22

более чем на десять процентов объем предусмотренных услуг при изменении потребности в услугах, на оказание которых заключен договор. Срок, по окончании которого не принимаются запросы на разъяснение конкурсной документации: не позднее, чем за пять рабочих дней до дня окончания подачи заявок на участие в конкурсе. Форма подачи заявки на участие в конкурсе: Участник размещения заказа подает заявку на участие в конкурсе в письменной форме в запечатанном конверте (один оригинал и одна копия заявки на участие в конкурсе запечатываются в два отдельных внутренних конверта). Требования, предъявляемые Заказчиком к Участникам размещения заказа: -к правоспособности участника размещения заказа:

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

б) неприостановление деятельности участника размещения заказа в порядке, предусмотренном Кодексом Российской Федерации об административных правонарушениях, на день подачи заявки в целях участия в размещении заказа для нужд университета;

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

-к репутации участника размещения заказа: а) наличие за последние два года, предшествующие размещению информации о

размещении заказа на официальном сайте университета, опыта оказания не менее двух аналогичных услуг, стоимостью не менее пятидесяти процентов начальной цены договора, установленной конкурсной документацией (предоставляется по указанной в конкурсной документации Форме 5 и подтверждается копиями актов сдачи-приемки услуг по договорам). Под аналогичными услугами понимаются услуги по созданию и развитию информационных систем на базе платформы «Мельница данных».

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

для юридического лица: а) заполненную форму заявки на участие в конкурсе в соответствии с требованиями

конкурсной документации (предоставляется по форме 1 конкурсной документации); б) анкету юридического лица по установленной в конкурсной документации форме 2; в) нотариально заверенные копии учредительных документов с приложением имеющихся

изменений; г) выписку из единого государственного реестра юридических лиц (или нотариально

23

заверенную копию такой выписки), полученную не ранее чем за 30 дней до дня размещения на официальном сайте Заказчика извещения о проведении открытого конкурса;

д) решение об одобрении или о совершении крупной сделки либо копия такого решения в случае, если требование о необходимости наличия такого решения для совершения крупной сделки установлено законодательством Российской Федерации, учредительными документами юридического лица и если для участника размещения заказа оказание услуг, являющихся предметом договора, или внесение денежных средств в качестве обеспечения заявки на участие в конкурсе, обеспечения исполнения договора является крупной сделкой;

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

ж) справку об исполнении налогоплательщиком обязанности по уплате налогов, сборов, страховых взносов, пеней и налоговых санкций, выданную соответствующими подразделениями Федеральной налоговой службы не ранее чем за 60 дней до срока окончания приема заявок на участие в конкурсе;

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

и) сведения о качественных характеристиках услуг и условиях исполнения договора (предоставляется по форме 4 конкурсной документации).

к) документы, подтверждающие соответствие участника размещения заказа установленным требованиям и условиям допуска к участию в конкурсе;

л) документы, подтверждающие внесение участником размещения заказа обеспечения заявки на участие в конкурсе;

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

для индивидуального предпринимателя: а) заполненную форму заявки на участие в конкурсе в соответствии с требованиями

конкурсной документации (предоставляется по форме 1 конкурсной документации); б) фамилию, имя, отчество, паспортные данные, сведения о месте жительства, номер

контактного телефона; в) выписку из единого государственного реестра индивидуальных предпринимателей (или

нотариально заверенную копию такой выписки), полученную не ранее чем за 30 дней до дня размещения на официальном сайте Заказчика извещения о проведении открытого конкурса;

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

д) справку об исполнении налогоплательщиком обязанности по уплате налогов, сборов, страховых взносов, пеней и налоговых санкций, выданную соответствующими подразделениями Федеральной налоговой службы не ранее чем за 60 дней до срока окончания приема заявок на участие в конкурсе;

е) сведения о качественных характеристиках услуг и условиях исполнения договора

24

(предоставляется по форме 4 конкурсной документации); ж) документы, подтверждающие соответствие участника размещения заказа установленным

требованиям и условиям допуска к участию в конкурсе; з) документы, подтверждающие внесение участником размещения заказа обеспечения

заявки на участие в конкурсе; и) иные документы или копии документов, перечень которых определен конкурсной

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

для простого товарищества: а) договор простого товарищества участников; б) а также документы необходимые для представления юридическим лицам.

Порядок и критерии оценки и сопоставления заявок на участие в Конкурсе: Критерии оценки заявок на участие в конкурсе и их значимость:

1) цена договора (Kai = 20%); 2) качество услуг и квалификация участника конкурса (Kci = 60%) 3) сроки предоставления гарантий качества услуг (Kfi = 20%)

Совокупная значимость критериев составляет 100%. Порядок оценки и сопоставления заявок на участие в конкурсе:

Оценка и сопоставление заявок на участие в конкурсе осуществляется комиссией в целях выявления лучших условий исполнения договора в соответствии с вышеуказанными критериями.

Оценка по критерию «Цена договора»

Рейтинг, присуждаемый заявке по критерию "Цена договора", определяется по формуле:

100A

AARa

maх

maх ii ×

−= ,

где:

iRa - рейтинг, присуждаемый i-й заявке по указанному критерию;

Amax - начальная цена договора, установленная в конкурсной документации; Ai - предложение i-го участника конкурса по цене. Для расчета итогового рейтинга по заявке рейтинг, присуждаемый этой заявке по критерию

"Цена договора", умножается на значимость критерия - 0,2.

Оценка по критерию «Качество услуг и квалификация участника конкурса» Оценка по критерию «Качество услуг и квалификация участника конкурса» производится

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

Количество баллов по критерию «Качество услуг и квалификация участника конкурса» по каждой заявке рассчитывается путем экспертной оценки, представленной в заявках участников размещения заказа информации с учетом следующих показателей:

25

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

Предлагаемое участником описание технических решений должно быть описано в заявке

участника, и содержать проект спецификации сервисов SOAР, предоставляемых системой АСАВ.

Максимальная сумма баллов по данному показателю устанавливается равной 40 баллам.

2. Опыт оказания услуг по созданию и развитию информационных систем на базе платформы «Мельница данных». Опыт оказания услуг оценивается на основании выполненных участником договоров по оказанию аналогичных услуг. Для этого в конкурсной заявке участника должна быть представлена информация о выполненных договорах за последние 5 лет (предоставляется по форме 6 конкурсной документации)

Аналогичными признаются услуги по созданию и развитию информационных систем на базе платформы «Мельница данных».

По каждому договору должна быть представлена следующая информация:

a. Предмет договора; b. Наименования заказчика; c. Срок оказания услуг по договору; d. Дата заключения договора; e. Дата завершения договора;

Принимаются к рассмотрению только та информация, которая подтверждается копиями

актов сдачи-приемки по договорам. В представленных копиях допускается сокрытие финансовых условий договора.

Максимальная сумма баллов по данному показателю устанавливается равной 40

баллам.

3. Наличие положительных отзывов и благодарностей от Заказчиков (предоставляется по форме 7 конкурсной документации) Отзыв подтверждается путем включения в конкурсную заявку участника копий документов-отзывов. В расчете рейтинга участвуют отзывы, имеющие:

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

• Подпись представителя организации-заказчика. • Печать организации-заказчика.

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

Максимальная сумма баллов по данному показателю устанавливается равной 20

26

баллам. Рейтинг, присуждаемый заявке по критерию «Качество услуг и квалификация участника

конкурса», определяется как среднее арифметическое оценок в баллах всех членов конкурсной комиссии, присуждаемых этой заявке по указанному критерию. Рейтинг, присуждаемый i-й заявке по критерию «Качество услуг и квалификация участника конкурса», определяется по формуле:

ikC...i

2Ci1CiRc +++= ,

где:

iRc - рейтинг, присуждаемый i-й заявке по указанному критерию;

ikC - значение в баллах (среднее арифметическое оценок в баллах всех членов конкурсной

комиссии), присуждаемое комиссией i-й заявке на участие в конкурсе по k-му показателю, где k - количество установленных показателей.

Для получения оценки (значения в баллах) по критерию (показателю) для каждой заявки вычисляется среднее арифметическое оценок в баллах, присвоенных всеми членами конкурсной комиссии по критерию (показателю).

Для расчета итогового рейтинга по заявке рейтинг, присуждаемый этой заявке по критерию «Качество услуг и квалификация участника конкурса», умножается на значимость критерия - 0,6.

По каждой заявке комиссия оценивает качество услуг и квалификацию участника конкурса

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

Более высокий балл соответствует более высокому качеству услуг и (или) квалификации участника конкурса.

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

Показатель «качество предлагаемых услуг» оценивается с учетом соответствия или превышения предложенных участником конкурса показателей в сравнении с показателями, заданными в Техническом задании.

Оценка по критерию «Срок предоставления гарантий качества услуг»

В рамках указанного критерия оценивается срок предоставления гарантии качества услуг, на который участник конкурса, в случае заключения с ним договора, принимает на себя обязательство по гарантии качества услуг. При этом данный срок должен превышать минимальный срок гарантии качества услуг, установленный в пункте 8 настоящего ТЗ (в течение 6 (шести) месяцев с даты подписания акта сдачи-приемки услуг (Gmin = 6)). Рейтинг, присуждаемый i-й заявке по критерию "срок предоставления гарантии качества услуг", определяется по формуле:

100G

GGRgmin

minii ×

−= ,

где:

27

Rgi - рейтинг, присуждаемый i-й заявке по указанному критерию; Gmin - минимальный срок предоставления гарантии качества услуг, установленный п. 8 настоящего ТЗ; Gi - предложение i-го участника по сроку гарантии качества услуг. Максимальное количество баллов, присваиваемое по данному критерию – 100. В целях оценки и сопоставления предложений в заявках со сроком предоставления гарантии качества услуг, превышающим более чем на половину минимальный срок предоставления гарантии качества услуг, установленный в конкурсной документации, таким заявкам присваивается рейтинг по указанному критерию, равный 50. Для расчета итогового рейтинга по заявке рейтинг, присуждаемый этой заявке по критерию «Сроки предоставления гарантии качества услуг» (Rgi ), умножается на значимость критерия (Кg) - 0,2.

Итоговый рейтинг Присуждение каждой заявке порядкового номера по мере уменьшения степени выгодности

содержащихся в ней условий исполнения договора производится по результатам расчета итогового рейтинга по каждой заявке.

Итоговый рейтинг заявки = Rai*Kai /100 + Rci*Kci /100 + Rgi*Kgi /100

Заявке, набравшей наибольший итоговый рейтинг, присваивается первый порядковый номер. Требование обеспечения заявки на участие в Конкурсе: Размер обеспечения: 5% начальной цены договора Порядок предоставления: Исполнение обязательств участника размещения заказа, в связи с подачей заявки на участие в конкурсе, может быть обеспечено перечислением денежных средств в качестве обеспечения заявки на участие в конкурсе на расчетный счет, указанный в конкурсной документации, или путем предоставления в составе заявки на участие в конкурсе безотзывной банковской гарантии. Сумма обеспечения заявки на участие в конкурсе должна составлять: 122 400,00 руб. (Сто двадцать две тысячи четыреста рублей 00 копеек). Реквизиты счета: Реквизиты счета для перечисления денежных средств: Место нахождения: 101000, г. Москва ул. Мясницкая, дом 20 ИНН 7714030726 КПП 770101001 Получатель УФК по г. Москве (Национальный исследовательский университет “Высшая школа экономики” л/с № 30736U27000) Банк получателя Отделение 1 Московского ГТУ Банка России г. Москва 705 БИК 044583001 Р/счет 40501810600002000079 Требование обеспечения исполнения договора: Вид и размер обеспечения: 10% начальной цены договора.

28

244 800,00 руб. (Двести сорок четыре тысячи восемьсот рублей 00 копеек). Обеспечение исполнения договора может быть представлено в виде безотзывной банковской гарантии или перечислением денежных средств. Реквизиты счета в случае перечисления денежных средств: Реквизиты счета для перечисления денежных средств: Место нахождения: 101000 г. Москва ул. Мясницкая, дом 20 ИНН 7714030726 КПП 770101001 Получатель УФК по г. Москве (Национальный исследовательский университет “Высшая школа экономики” л/с 30736U27000) Банк получателя Отделение 1 Московского ГТУ Банка России г. Москва 705 БИК 044583001 Р/счет 40501810600002000079 Срок заключения договора с Участником, которому Заказчик предложит заключить договор по результатам проведения Конкурса: договор может быть заключен не ранее, чем через три рабочих дня со дня размещения на официальном сайте Заказчика протокола, составленного по результатам размещения заказа, и не позднее десяти дней после завершения торгов и оформления протокола.

29

9. Техническое задание на оказание услуг по разработке и внедрению новой функциональности

автоматизированной системы (АСАВ), в рамках реализации «Программы развития государственного образовательного бюджетного учреждения высшего

профессионального образования «Государственный университет – Высшая школа экономики», в отношении которого установлена категория «национальный исследовательский университет», на 2009 – 2018 годы», передаче Заказчику результатов оказанных услуг, а также предоставлению Заказчику прав на использование результатов, являющихся результатом интеллектуальной

деятельности 1. Предмет договора: Оказание услуг по разработке и внедрению новой функциональности автоматизированной системы (АСАВ), в рамках реализации «Программы развития государственного образовательного бюджетного учреждения высшего профессионального образования «Государственный университет – Высшая школа экономики», в отношении которого установлена категория «национальный исследовательский университет», на 2009 – 2018 годы», передаче Заказчику результатов оказанных услуг, а также предоставлению Заказчику прав на использование результатов, являющихся результатом интеллектуальной деятельности 2. Начальная цена договора: 2 448 000,00 рублей. 3. Источник финансирования заказа: Средства программы развития государственного образовательного бюджетного учреждения высшего профессионального образования «Государственный университет – Высшая школа экономики», в отношении которого установлена категория «национальный исследовательский университет», на 2009-2018 годы. Мероприятие 5.2 «Развитие информационной инфраструктуры университета». 4. Порядок формирования цены договора: В цену договора входят все расходы Исполнителя, связанные с исполнением договора, в том числе оплата НДС и других обязательных платежей в соответствии с законодательством РФ. Валюта формирования цены договора и расчетов с Исполнителем – рубль РФ. 5. Форма, сроки и порядок оплаты услуг: Безналичный расчет. Оплата по договору осуществляется по факту оказания услуг в течение 10 (десяти) банковских дней, на основании акта сдачи-приемки услуг, подписанного Исполнителем и Заказчиком, и оригинала счета Исполнителя. По факту оказания услуг Исполнитель предоставляет Заказчику счет-фактуру. Акт, счет и счет-фактура должны предоставляться Исполнителем в офис Заказчика лично сотруднику, осуществляющему контроль исполнения договора.

6. Требования, установленные заказчиком, к качеству, техническим характеристикам услуг, требования к результатам услуг: Система Абитуриент – Студент – Аспирант – Выпускник существует в Высшей школе экономики (далее НИУ ВШЭ) с 2005 года, и состоит из модулей, каждый из которых реализует функциональность по учету контингента: абитуриенты, студенты, аспиранты и выпускники, слушатели программ дополнительного профессионального образования. Система реализована на базе технологической платформы «Мельница данных» (http://www.techmill.ru).

30

Исполнителем должны быть оказаны следующие услуги по развитию и внедрению системы АСАВ: 1. Реализация функциональности автоматизированного рабочего места (АРМ) работника Управления международной академической мобильности (УМАМ). 2. Реализация функциональности web-регистрации поступающих на программы дополнительного профессионального образования (ДПО). 3. Реализация функциональности Личного кабинета слушателя программ дополнительного профессионального образования (ДПО). 4. Реализация функциональности участка системы «Дополнительное образование» на подготовительном отделении для поступающих в магистратуру. 5. Реализация функциональности участка «Аспирант» в целях учета аспирантов, обучающихся по программам академической аспирантуры. 6. Реализация функциональности интеграции системы АСАВ с Системой контроля и управления доступом (СКУД) в части передачи в систему АСАВ фотографий студентов и преподавателей. 7. Развитие функциональности интеграции системы АСАВ с сервисом Microsoft Live@Edu далее LiveEdu. 8. Реализация функциональности интеграции системы АСАВ с корпоративным порталом НИУ ВШЭ в части публикации на портале утвержденных рабочих учебных планов. 9. Реализация возможности доступа к данным и механизмам системы АСАВ по протоколу SOAP (Simple Object Access Protocol). 10. Доработка архитектуры системы с целью обеспечения возможностей учета данных в филиальной структуре с применением единой базы данных. 11. Объединение справочных и оперативных данных из баз данных систем работающих в Москве и трех филиалах ВШЭ в единую базу данных

6.1. Реализация функциональности автоматизированного рабочего места (АРМ) работника Управления международной академической мобильности (УМАМ). Требования к составу услуг: № п.п. Состав Форма результата 1 Доработка функциональности

системы АСАВ для выделения рабочего места работника УМАМ.

Доработанная функциональность установлена в рабочую конфигурацию Системы.

2 Доработка документации: -инструкции пользователя – работника УМАМ;

Доработанная документация согласованна с исполнителем.

3 Проведение предварительных испытаний

Согласованный акт готовности к опытной эксплуатации

4 Обучение пользователей и сопровождение на этапе опытной эксплуатации.

Журнал замечаний по эксплуатации.

5 Проведение испытаний Согласованный акт готовности к промышленной эксплуатации

6.1.1. Требования к доработке функциональности.

31

Общее назначение функциональности Управление международной академической мобильности (УМАМ) создано в НИУ ВШЭ с целью организационного и консультационного сопровождения обменов, стажировок, иных форм академической мобильности студентов и аспирантов, а также студентов, аспирантов и преподавателей университетов – партнеров НИУ ВШЭ по программам обменов. В системе АСАВ в настоящее время ведется учет студентов факультетов и отделений, обучающихся по основным образовательным программам высшего профессионального образования, аспирантов, зачисляемых для обучения в аспирантуре, студентов и слушателей программ дополнительного профессионального образования. Задачей данной разработки является выделение новой категории обучающихся в университете – иностранных студентов, зачисляемых в НИУ ВШЭ для прохождения обучения различной продолжительности. Иностранные студенты, в отличие от студентов, учитываемых в системе, не обязательно должны принадлежать к одному из факультетов, их учебный план всегда является индивидуальным и может формироваться из дисциплин и других видов нагрузки, преподаваемых на разных факультетах и отделениях университета в рамках различных учебных планов. В учебный план иностранных студентов также могут входить летние и зимние школы, другие мероприятия, не входящие в рабочие учебные планы факультетов и отделений НИУ ВШЭ. Работники УМАМ должны получить возможность учитывать иностранных студентов, проходящих обучение в НИУ ВШЭ, средствами системы АСАВ, формировать для них учебные планы, ведомости на сдачу испытаний. Оценки, полученные иностранными студентами должны заноситься в систему АСАВ и в дальнейшем могут включаться в массивы данных, по которым выполняется анализ успеваемости. По окончании обучения иностранного студента в НИУ ВШЭ работники УМАМ должны иметь возможность сформировать «транскрипт» - документ о прохождении обучения, выдаваемый иностранному студенту. Документ должен содержать перечень сданных иностранным студентом дисциплин и выполнения других видов учебной нагрузки, полученные оценки и количество набранных кредитов.

Перечень автоматизируемых задач Разработка функциональности рабочего места Управления международной академической мобильности должна позволить автоматизировать следующие учетные задачи: 1) Формирование в системе АСАВ записей об иностранных студентах, проходящих обучение разной продолжительности в рамках стажировок, программ обмена, а также на других основаниях. 2) Предоставление работникам УМАМ доступа к информации о студентах факультетов и отделений, имеющих иностранное гражданство, учет которых осуществляют пользователи учебных частей. 3) Составление индивидуальных учебных планов иностранных студентов. 4) Формирование ведомостей на сдачу испытаний иностранных студентов. 5) Учет успеваемости иностранных студентов по различным дисциплинам. 6) Формирование документов о прохождении иностранными студентами обучения в НИУ ВШЭ («транскриптов»). 7) Формирование статистических и аналитических отчетов по численности и структуре контингента иностранных студентов, их успеваемости.

32

Требования к разработке новых или расширения функциональности существующих классов «статусов» учащихся для целей учета иностранных студентов С целью учета в системе иностранных студентов, проходящих обучение по индивидуальным учебным планам, в системе должен быть разработан новый класс «Слушатель», являющийся дочерним по отношению к классу «Студент». Использование наследования класса «Слушатель» от класса «Студент» позволит использовать в классе «Слушатель» все поля, свойства и методы, существующие у класса «Студент», дополнив их полями, свойствами и методами, специфичными для класса «Слушатель». Наряду с изменениями, вносимыми в классы статусов студентов, должен быть реализован новый класс - справочник «Программы стажировок и обменов», который позволит вести учет иностранных студентов в рамках программ, по которым они проходят подготовку в НИУ ВШЭ.

Требование к атрибутивному составу информации, необходимой для работы Управления международной академической мобильности Объекты нового класса «Слушатель» должны иметь следующий атрибутивный состав: • Фамилия на русском языке • Фамилия на английском языке • Имя на русском языке • Имя на английском языке • Дата рождения • Гражданство (страна) • Дата начала статуса • Дата окончания статуса • № приглашения • № паспорта • Направление обучения в НИУ ВШЭ • Программа, по которой проходит обучение • Тип программы (обмен, стажировка, …) • Вуз, в котором проходит основное обучение («материнский вуз») • Страна принадлежности вуза • Номер приказа о зачислении в НИУ ВШЭ • Дата приказа о зачислении в НИУ ВШЭ • Номер студенческого билета • Вид выданного документа об образовании • Серия выданного документа об образовании • Номер выданного документа об образовании • Дата выдачи документа об образовании • Регистрационный номер выданного документа об образовании Объекты нового класса – справочника «Программы стажировок и обменов» должны иметь следующий атрибутивный состав: • Краткое наименование программы (на русском языке) • Краткое наименование программы (на английском языке) • Полное наименование программы (на русском языке) • Полное наименование программы (на английском языке) • Дата открытия программы • Дата закрытия программы • Вуз-партнер

33

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

Требование к функциональности разработки индивидуальных учебных планов (ИУП) иностранных студентов При формировании индивидуального учебного плана иностранного студента необходимо реализовать возможность использования процедуры «Назначить дисциплину любого плана», и обеспечить возможность выбирать и назначать любую дисциплину из любого РУП, а также назначать общеуниверситетский факультатив. Применение процедуры «Назначить дисциплину любого плана» должно быть доступно для каждой из дисциплин, планируемых к изучению иностранным студентом. Для включения в ИУП иностранного студента летних или зимних школ, других научных или учебных мероприятий, не входящих в РУПы НИУ ВШЭ, должна быть реализована возможность воспользоваться существующей функциональностью по работе с общеуниверситетскими факультативами.

Требования к сценарию работы с новой функциональностью Работа пользователя Управления международной академической мобильности по учету иностранных студентов и их успеваемости должна выполняться по следующему сценарию: 1) Формирование справочника «Программы стажировок и обменов». 2) Добавление иностранного студента – кандидата на зачисление. В системе должна быть реализована единая процедура добавления иностранного студента, позволяющая вводить личные данные, контактную информацию студента, информацию направлении его обучения, материнском вузе, и проч. 3) Зачисление иностранного студента в НИУ ВШЭ на основании приказа. 4) Формирование индивидуального учебного плана иностранного студента. 5) Формирование ведомостей для сдачи испытаний иностранным студентом. 6) Занесение результатов испытаний, сданных иностранным студентом. 7) Формирование печатной формы документа (транскрипта), выдаваемого иностранному студенту по итогам обучения в НИУ ВШЭ. 8) Отчисление иностранного студента.

ГЛАВА 1. ТРЕБОВАНИЯ К ЭКРАННЫМ ФОРМАМ ПОЛЬЗОВАТЕЛЬСКИХ ИНТЕРФЕЙСОВ СИСТЕМЫ. Экранные формы должны быть реализованы в соответствии с представленными макетами:

Рис. 1 Таблица данных «Иностранные студенты»

35

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

Рис. 2 Таблица данных «Рубежный контроль по периодам»

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

Требования к макетам отчетных форм и правилам их формирования 1) Отчет Список иностранных студентов программы Отчет должен формироваться из таблицы данных, отображающей иностранных студентов. Параметрами формирования отчета должны быть: • Программа стажировок и обменов • Дата начала периода • Дата окончания периода Отчет должен формироваться в табличной форме в виде файла MS Excel. В таблицу, отображаемую в отчете, должны попасть все иностранные студенты, проходившие обучение по выбранной программе, дата начала обучения которых попадает в период, заданный пользователем. 2) Отчет Ведомость сдачи испытания иностранным студентом Отчет должен формироваться для одного выбранного испытания. В зависимости от вида испытания отчет должен иметь заголовок «Экзаменационная ведомость» или «Зачетная ведомость». Отчет должен формироваться в виде файла MS Excel. 3) Отчет Результаты успеваемости иностранного студента Отчет должен формироваться для выбранного студента. В отчете должны быть отображены все испытания, назначенные иностранному студенту согласно его индивидуальному учебному плану. По сданным испытаниям должны быть отображены полученные оценки. Отчет должен формироваться в виде файла MS Excel. 4) Отчет Численность иностранных студентов по программам Отчет должен отображать данные о численности иностранных студентов, прошедших обучение в НИУ ВШЭ по различным программам обмена и стажировок за заданный период времени. Параметрами отчета должны быть даты начала и окончания периода. Отчет должен формироваться в виде файла MS Excel. 5) Транскипт Отчет «Транскрипт» должен формироваться на английском языке в виде файла MS Word в формате, представленном на рис. 3. Отчет должен состоять из двух страниц. На первой странице должна отображаться информация о НИУ ВШЭ и данные студента (ФИО, пол, дата рождения, гражданство, паспортные данные, «материнский» вуз и проч.), описание принципов организации учебного процесса в НИУ ВШЭ. На второй странице документа должен быть отображен перечень сданных студентом в НИУ ВШЭ дисциплин, дополненный следующими атрибутами: - Полное наименование дисциплины на английском языке; - ФИО и ученая степень преподавателя; - Факультет, подразделение, на котором прослушан курс; - Язык, на котором преподавался курс; - Число общих и аудиторных часов;

37

- Число кредитов за курс; - Оценка студентов (полученный балл и максимальное число баллов, например, «7 out of 10)

Рис. 3 Отчет «Транскипт, выдаваемый иностранному студенту»

38

6.1.2. Требования к сопровождению на этапе опытной эксплуатации. В ходе опытной эксплуатации исполнитель должен: • консультировать пользователей по вопросам использования функциональности системы; • фиксировать в специальной системе учета замечаний Заказчика: суть замечаний, дату возникновения замечаний, дату устранения. Длительность этапа опытной эксплуатации не менее двух недель.

39

Сроки проведения опытной эксплуатации должны быть предварительно согласованы с Заказчиком.

6.2 Реализация функциональности web-регистрации поступающих на программы дополнительного профессионального образования (ДПО). Требования к составу услуг: № п.п. Состав Форма результата 1 Доработка функциональности

системы АСАВ. Доработанная функциональность установлена в рабочую конфигурацию Системы.

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

Доработанная документация согласованна с исполнителем.

3 Проведение предварительных испытаний

Согласованный акт готовности к опытной эксплуатации

4 Обучение пользователей и сопровождение на этапе опытной эксплуатации.

Журнал замечаний по эксплуатации.

5 Проведение испытаний Согласованный акт готовности к промышленной эксплуатации

6.2.1. Требования к доработке функциональности.

Общее назначение функциональности Разрабатываемая в рамках настоящего технического задания новая функциональность системы АСАВ предназначена для организации взаимодействия пользователей системы, являющихся работниками институтов и центров дополнительного профессионального образования (ДПО) или работниками Управления дополнительного образования (пользователи участка «Дополнительное образование»), с лицами, желающими поступить на программы ДПО. Создаваемая подсистема должна позволить удаленному пользователю (поступающему) получить учетную запись в системе, после чего подать заявку на регистрацию в качестве поступающего на одну из предлагаемых программ. По результатам рассмотрения заявки удаленный пользователь должен быть проинформирован о результате ее рассмотрения – регистрации поступающего или отклонении заявки. После регистрации поступающий должен иметь возможность корректировать введенные им личные данные, информацию об образовании, изменять выбор программы. Все действия удаленного пользователя в личном кабинете должны осуществляться на основе заявок – специальных записей базы данных, содержащих введенную удаленным пользователем информацию, предназначенную для предварительного просмотра модератором с последующим «приемом» (применением сделанных изменений) или отклонением. Пользователи участка «Дополнительное образование» должны получить доступ к информации обо всех заявках удаленных пользователей, поданных на программы институтов и центров ДПО, возможность предварительного рассмотрения, принятия или отклонения заявок, возможность обмена с удаленными пользователями дополнительной информацией.

40

Перечень автоматизируемых задач В рамках разрабатываемой подсистемы автоматизации подлежат следующие задачи: 1) Регистрация в системе АСАВ удаленного пользователя как поступающего на программы ДПО. 2) Создание и отправка удаленным пользователем заявки на регистрацию в качестве поступающего, включающую заданный набор его личных данных, контактную информацию, информацию о предыдущем образовании, месте работы выбранную программу обучения. 3) Рассмотрение поступивших заявок пользователями – модераторами от подразделений ДПО; прием или отклонение заявок; возможность корректировки данных, введенных удаленным пользователем. 4) Создание на основе принятых заявок записей о поступающих на программы ДПО. 5) Корректировка удаленными пользователями своих данных о поступлении на этапе после подачи заявки до зачисления на программу ДПО в качестве студента или слушателя. 6) Обмен сообщениями системы и письмами электронной почты между удаленными пользователями (поступающими) и пользователями системы АСАВ, отвечающими за набор студентов и слушателей. 7) Сбор данных для формирования отчетных форм по поступающим на программы ДПО.

Требования к атрибутивному составу информации, необходимой для регистрации поступающего В справочнике системы АСАВ «Форматы программ ДПО» / «Продолжительности программ ДПО» существует признак «Допустима краткая форма регистрации». В зависимости от наличия или отсутствия этого признака при регистрации на программу у удаленного пользователя должен запрашиваться разный набор атрибутов. Полная процедура регистрации должна требовать заполнение пользователем следующего набора полей (поля объединяются в группы полей): Группа полей «Персональные данные» • Фамилия • Имя • Отчество • Дата рождения • Пол Группа полей «Документ, удостоверяющий личность» • Вид документа • Гражданство • Серия • Номер • Кем выдан • Дата выдачи Группа полей «Информация о месте постоянной регистрации» • Почтовый индекс • Регион проживания • Тип населенного пункта • Населенный пункт • Населенный пункт • Адрес регистрации Группа полей «Контактная информация» • Адрес фактического проживания • Домашний телефон

41

• Рабочий телефон • Контактный телефон • E-mail Группа полей «Информация о предыдущем образовании» • Вид документа об образовании • Направление/специальность • Наименование направления/специальности • Степень/квалификация • Наименование степени/квалификации • Серия • Номер • Дата выдачи • С отличием • Сдан подлинник Группа полей «ВУЗ» • Выпускник нашего ВУЗа • Регион • Тип населенного пункта • Населенный пункт • Город • Полное наименование вуза Группа полей «Ученая степень» • Степень • Отрасль науки Группа полей «Место работы» • Место работы • Должность • Категория должности • Адрес • Является госслужащим • Категория ГГС • Стаж работы на госслужбе Группа полей «Выбор программы ДПО» • Институт, центр ДПО • Формат программы • Продолжительность программы • Программа • Специализация (для программ ВПО) Краткая процедура регистрации, применяемая для отдельных видов программ должна также запрашивать указанный выше набор полей за исключением группы полей «Информация о предыдущем образовании». Вместо набора полей данной группы, предусмотренного в полной процедуре, пользователь должен заполнить одно поле – «Уровень образования».

Требования к типам данных и обязательности их указания поступающим

Наименование поля Тип данных Обязательность,

особенности заполнения Персональные данные

Фамилия Строковый Обязательно

42

Имя Строковый Обязательно Отчество Строковый Обязательно Дата рождения Дата Обязательно

Пол Логический (Муж. / Жен.) Обязательно

Документ, удостоверяющий личность Вид документа Выбор из справочника Обязательно Гражданство Выбор из справочника Обязательно Серия Строковый Необязательно Номер Строковый Обязательно Кем выдан Строковый Обязательно Дата выдачи Дата Обязательно

Информация о месте постоянной регистрации Почтовый индекс Числовой Необязательно Регион проживания Выбор из справочника Обязательно Тип населенного пункта Выбор из справочника Обязательно Населенный пункт Строковый Обязательно Адрес регистрации Строковый Обязательно

Контактная информация Адрес фактического проживания Строковый Обязательно Домашний телефон Строковый Обязательно Рабочий телефон Строковый Обязательно Контактный телефон Строковый Обязательно E-mail Строковый Обязательно

Информация о предыдущем образовании

Уровень образования Выбор из справочника Обязательно (только в краткой процедуре регистрации)

Вид документа Выбор из справочника Обязательно Наименование направления/специальности Строковый Обязательно Наименование степени/квалификации Строковый Обязательно Серия Строковый Необязательно Номер Строковый Обязательно Дата выдачи Дата Обязательно С отличием Логический (Да / Нет) Обязательно

ВУЗ Выпускник нашего ВУЗа Логический (Да / Нет) Обязательно

Регион Выбор из справочника Обязательно (для «нашего» вуза заполняется автоматически)

Тип населенного пункта Выбор из справочника Обязательно (для «нашего» вуза заполняется автоматически)

Населенный пункт Выбор из справочника Обязательно (для «нашего» вуза заполняется автоматически)

Город Строковый Обязательно (для «нашего» вуза заполняется автоматически)

Полное наименование Строковый Обязательно (для «нашего» вуза заполняется автоматически)

Ученая степень Степень Выбор из справочника Необязательно

43

Отрасль науки Выбор из справочника Необязательно Место работы

Место работы Строковый Обязательно Должность Строковый Обязательно Категория должности Выбор из справочника Необязательно Адрес организации Строковый Обязательно Является госслужащим Логический (Да / Нет) Обязательно Категория ГГС Выбор из справочника Необязательно Стаж работы на госслужбе Числовой Необязательно

Выбор программы Институт, центр ДПО Выбор из справочника Обязательно Программа Выбор из справочника Обязательно Специализация (для программ ВПО) Выбор из справочника Необязательно

Формат программы Выбор из справочника

Обязательно (подставляется автоматически для выбранной программы)

Продолжительность программы Выбор из справочника

Обязательно (подставляется автоматически для выбранной программы)

Требования к этапности работы удаленного пользователя (получение логина, пароля, регистрация в качестве поступающего, подтверждение регистрации) Работа уделанного пользователя, желающего зарегистрироваться в качестве поступающего на одну из программ ДПО, должна состоять из следующих этапов: 1) Регистрация как пользователя web-ресурса (получение логина, пароля для доступа в личный кабинет). 2) Регистрация в качестве поступающего (заполнение формы регистрации). После получения логина и пароля удаленный пользователь должен ввести их в соответствующие поля на первой странице web-сервиса и перейти по ссылке «Войти в личный кабинет». 3) Изменение введенных при регистрации данных (в случае необходимости). 4) В случае возникновения сложностей при первичной регистрации, при входе в личный кабинет, пользователь должен иметь возможность направить модератору «анонимное сообщение». Ссылка, позволяющая направить такое сообщение, должна быть расположена на первой общедоступной странице сервиса. Ответ на сообщение удаленный пользователь должен получать от модератора по электронной почте. 5) После входа в личный кабинет пользователь также должен иметь возможность написать сообщение модератору. Такое сообщение будет предоставлять модератору информацию о создавшем его пользователе системы. Ответ на сообщение удаленный пользователь должен получать от модератора по электронной почте.

Требования к предварительной модерации данных, направленных удаленным пользователем Вся информация, формируемая удаленным пользователем, должна в обязательном порядке проходить модерацию. Модерация должна осуществляться пользователями институтов и центров ДПО, ответственными за работу с данными о поступающих. Модерация должна заключаться в рассмотрении «заявок» удаленных пользователей. Каждая заявка должна представлять собой запись базы данных системы с атрибутами, характерными для вида заявки. Атрибутами заявки должны быть значения полей, заполненных пользователем.

44

Все поступившие заявки должны отображаться в отдельной форме работы с данными «Обслуживание удаленных пользователей». Форма должна содержать набор таблиц данных, отображающих как все поступившие заявки, так и отдельно заявки каждого вида. Заявки должны иметь атрибут «Статус заявки», принимающий одно из следующих значений: • Ожидает рассмотрения – заявка сформирована как результат действия удаленного пользователя, но еще не рассмотрена модератором; • Принята – модератором выполнено действие по принятию заявки, в системе успешно выполнены все операции над данными, предусмотренные процедурой принятия заявки данного вида (создана запись о поступающем на программу, произведено изменение данных о поступающем и т.п.) • Отклонена – модератор отклонил заявку; причина отклонения излагается в тексте письма, направляемом удаленному пользователю; • Отклонена автоматически – отклонение заявки выполнено системой автоматически (например, удаленный пользователь получил отказ в смене пароля); • Оставлена без рассмотрения – модератор принял решение о том, чтобы оставить заявку без рассмотрения; такой вариант действий может использоваться при направлении удаленным пользователем нескольких одинаковых заявок, неинформативных заявок. По каждой заявке пользователь-модератор должен видеть информацию, введенную пользователем при создании заявки, а также дополнительную информацию о данном пользователе, сформированную на основе существующих в системе данных (Рис. 7). По каждой заявке пользователь-модератор должен иметь возможность выполнить одно из действий: • Принять заявку • Отклонить заявку После принятия или отклонения у заявки должно измениться значение поля «Статус заявки». Это поле позволит пользователю-модератору отбирать для просмотра и отработки заявки, находящиеся в каждом из статусов. Пользователи - модераторы должны быть разделены на две категории: 1) Модераторы web-ресурса. Модераторы этой категории должны рассматривать заявки на регистрацию пользователей на ресурсе (получение логина, пароля), заявки о смене пароля, рассматривать анонимные (не привязанные к пользователю) сообщения и отвечать на них. 2) Модераторы от подразделения ДПО. Модераторы этой категории должны иметь возможность работать с заявками, имеющими отношение к конкретному подразделению (институту или центру дополнительного образования). Эти модераторы должны рассматривать заявки о регистрации удаленных пользователей в качестве поступающих, заявки об изменении данных, смене выбранной программы и проч. Подразделение ДПО, с которым работает каждый из модераторов должно задавать путем выставления пользовательской настройки «Подразделение ДПО». В качестве модераторов каждой из категорий может работать несколько пользователей. Для распределения нагрузки между модераторами в системе должен быть реализован следующий принцип маршрутизации заявок: 1. Заявка поступает к пользователю нужной категории (заявка, не относящаяся к подразделению – модератору web-ресурса, заявка зарегистрированного пользователя подразделения – к модератору от подразделения), имеющими в текущий момент, наименьшее число заявок, находящихся в статусе «Ожидает рассмотрения». 2. Каждый из модераторов должен иметь возможность выполнить действие «Передать другому модератору». Действие должно позволить выбрать одного из модераторов нужной категории и передать ему заявку.

45

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

Требования к общему числу участников регистрации и числу одновременно работающих пользователей Указанные ниже параметры быстродействия должны обеспечиваться системой при условии выполнения требований к серверным мощностям и системному программному обеспечению, описанных ниже в разделе «Требования к серверам БД и системному программному обеспечению, необходимым для обеспечения заданных параметров нагрузки и быстродействия». Подсистема удаленной регистрации поступающих на программы ДПО должна обеспечивать следующие параметры быстродействия: • Время отклика системы (любая операция, связанная с обращением клиента к веб-серверу) должна составлять не более 5 секунд. • Операция проверки регистрационных данных (входа пользователя в личный кабинет) – не более 10 секунд. При этом пользователю должно выдаваться соответствующее предупреждение, например, «Подождите, пожалуйста, идет проверка данных». Данные параметры быстродействия должны быть обеспечены при следующих значениях нагрузки:

46

• общее число записей о поступающих на программы ДПО в течение одного учебного года – до 15 000; • среднесуточная нагрузка в период регистрации поступающих – до 500 зарегистрированных; • количество одновременных сессий удаленных пользователей – до 500; Количество одновременных сессий удаленных пользователей складывается из числа сессий пользователей - поступающих и из числа сессий пользователей – слушателей (студентов) программ ДПО, работающих с подсистемой личного кабинета студента (слушателя). В случае выделения для задачи регистрации поступающего отдельного web-сервера с характеристиками, описанными в п. 5, система должна обеспечить указанные параметры быстродействия при 500 одновременных сессий пользователей – поступающих.

Требования к экранным формам web-страниц, используемых при регистрации участников Экранные формы должны быть реализованы в соответствии с представленными макетами:

Рис. 4 Макет главной страницы сервиса

48

Рис. 5 Макет формы регистрации удаленного пользователя подсистемы (получение логина, пароля)

49

Рис. 6 Макет заявки на регистрацию поступающего:

50Рис. 7. Макет формы работы модератора с заявками удаленных пользователей

Требования к серверам БД и системному программному обеспечению, необходимым для обеспечения заданных параметров нагрузки и быстродействия Подсистема удаленной регистрации поступающих на программы ДПО должна быть развернута на серверах, предоставляемых Заказчиком. Сервера должны соответствовать следующим техническим требованиям и требованиям к программному обеспечению:

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

СУБД Oracle 10.2.0.4 или выше; все вышедшие обновления для СУБД и ОС

Системные требования: 150 Гб дискового пространства; RAID 50(WriteBack); Оперативная память 3 Гб для 32-х битной ОС; 16 Гб для 64-х битной ОС Процессоры 2 и более Intel Xeon 2 GHz 4 Core

Требования к web-серверу Работа всей системы должна быть обеспечена на сервере, удовлетворяющем требованиями. Требования к программному обеспечению:

ОС Windows 2003 server или выше (32 бит) Системные требования:

Процессор Intel Xeon 2 GHz 4 Core 10 Гб дискового пространства 3 Гб оперативной памяти

Подсистема также должна позволять разделять web-сервер с другими подсистемами системы АСАВ. В этом случае требуемые параметры быстродействия должны быть обеспечены при числе одновременных работающих пользователей (п. 2.3.), которое складывается из числа удаленных пользователей всех подсистем.

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

текущая версия одного из web-браузеров • InternetExplorer 8.0 или выше; • Firefox Mozilla 3.6 или выше; • Opera 11.0 или выше; • Chrome 11.0 или выше; • Safari 5.0 или выше

Поддержка Java script со стороны web-браузера Поддержка Cookies со стороны web-браузера

Системные требования: Оперативная память 512 МБ 50 МБ дискового пространства

6.2.2. Требования к сопровождению на этапе опытной эксплуатации. В ходе опытной эксплуатации исполнитель должен: • консультировать пользователей по вопросам использования функциональности системы;

52

• фиксировать в специальной системе учета замечаний Заказчика: суть замечаний, дату возникновения замечаний, дату устранения. Длительность этапа опытной эксплуатации не менее двух недель. Сроки проведения опытной эксплуатации должны быть предварительно согласованы с Заказчиком.

6.3. Реализация функциональности Личного кабинета слушателя программ дополнительного профессионального образования (ДПО). Требования к составу: № п.п. Состав Форма результата 1 Доработка функциональности

системы АСАВ. Доработанная функциональность установлена в рабочую конфигурацию Системы.

2 Разработка документации: -инструкции удаленных пользователей; - инструкция модераторов участка ДПО;

Доработанная документация согласованна с исполнителем.

3 Проведение предварительных испытаний и нагрузочного тестирования.

Согласованный акт готовности к опытной эксплуатации

4 Сопровождение на этапе опытной эксплуатации.

Журнал замечаний по эксплуатации.

5 Проведение испытаний Согласованный акт готовности к промышленной эксплуатации

6.3.1. Требования к доработке функциональности. Разрабатываемая в рамках настоящего технического задания новая функциональность системы АСАВ предназначена для организации взаимодействия пользователей системы, являющихся работниками институтов и центров дополнительного профессионального образования (ДПО) или работниками Управления дополнительного образования (пользователи участка «Дополнительное образование»), с лицами, являющимися студентами и слушателями программ ДПО. Создаваемая подсистема должна позволить удаленному пользователю (студенту или слушателю) получить учетную запись в системе, после чего получить доступ к своему Личному кабинету – системе web-страниц, позволяющих слушателю работать со своими личными данными, информацией о ходе обучения, получать информацию о событиях, происходящих в ходе его обучения. После регистрации поступающий должен иметь возможность корректировать введенные им личные данные, информацию об образовании, и проч. Все действия удаленного пользователя в личном кабинете должны осуществляться на основе заявок – специальных записей базы данных, содержащих введенную удаленным пользователем информацию, предназначенную для предварительного просмотра модератором с последующим «приемом» (применением сделанных изменений) или отклонением. Пользователи участка «Дополнительное образование» должны получить доступ к информации обо всех заявках удаленных пользователей, поданных на программы институтов и центров ДПО, возможность предварительного рассмотрения, принятия или отклонения заявок, обмен с удаленными пользователями дополнительной информацией.

53

Перечень автоматизируемых задач В рамках разрабатываемой подсистемы автоматизации подлежат следующие задачи: 1) Регистрация в системе АСАВ удаленного пользователя являющегося студентом или слушателем программы ДПО. 2) Создание и отправка удаленным пользователем заявки на изменение его личных данных, контактной информации, информации о предыдущем образовании, месте работы и проч. 3) Рассмотрение поступивших заявок пользователями – модераторами от подразделений ДПО; прием или отклонение заявок; возможность корректировки данных, введенных удаленным пользователем. 4) Корректировка и актуализация данных системы на основе заявок удаленных пользователей. 5) Предоставление удаленному пользователю информации о его индивидуальном учебном плане и ходе его выполнения. 5) Информирование удаленного пользователя о происходящих событиях с его учетной записью (выставление оценок за испытания, перевод с одной программы не другую, отчисление, выпуск и проч.) 6) Обмен сообщениями системы и письмами электронной почты между удаленными пользователями (студентами и слушателями) и пользователями системы АСАВ, отвечающими работу с контингентом слушателей ДПО.

Требования к атрибутивному составу информации, доступной студенту (слушателю) в личном кабинете Для просмотра студентом (слушателем) программы ДПО должна быть доступна вся информация о его личных данных, контактных данных и ходе обучения, собираемая и обрабатываемая системой АСАВ. Группа атрибутов «Личные и контактные данные» • Фамилия • Имя • Отчество • Дата рождения • Адрес электронной почты • Контактный телефон • Домашний телефон • Рабочий телефон Группа атрибутов «Программа» • Номер студенческого билета (только для студентов программ ВПО) • Программа ДПО • Подразделение ДПО • Направление подготовки • Направление/специальность ВПО • Специализация (для программ ВПО) • Продолжительность обучения • Формат программы • Вид документа об образовании • Новая профессиональная область в РП (для программ переподготовки) • Новая квалификация (для программ переподготовки) Группа атрибутов «Предыдущее образование» • Уровень предыдущего образования • Документ о предыдущем образовании • Вид документа

54

• Номер документа • Дата документа • Серия документа • Сдан подлинник • ВУЗ • Диплом с отличием • Предыдущее направление/специальность • Предыдущая степень/квалификация Группа атрибутов «Условия обучения» • Группа слушателей • Дата начала обучения • Дата окончания обучения • Форма обучения • Стоимость обучения слушателя • Всего часов по учебному плану • Число лет обучения Группа атрибутов «Место работы» • Текущее место работы • Дата начала работы • Дата окончания работы • Место работы • Должность • Категория должности • Адрес места работы • Является госслужащим • Категория государственной гражданской службы • Стаж работы на госслужбе Группа атрибутов «Ученая степень» • Ученая степень • Отрасль науки Группа атрибутов «Зачисление» • Номер приказа • Дата приказа Группа атрибутов «Итоговая аттестация» • Номер приказа о допуске к итоговым госэкзаменам • Дата приказа о допуске к итоговым госэкзаменам • Номер приказа о допуске к ВКР • Дата приказа о допуске к ВКР • Дата утверждения темы ВКР • Номер приказа об утверждении тем ВКР • Дата приказа об утверждении тем ВКР • Номер приказа о допуске к государственной аттестации • Дата приказа о допуске к государственной аттестации Группа атрибутов «Документ о полученном образовании» • Вид документа • Номер документа • Дата документа • Серия документа • Диплом с отличием • Степень/квалификация

55

• Дата протокола ГАК • Номер протокола ГАК • Регистрационный номер Наряду с информацией о студенте (слушателе) и его статусе обучения по программе, ему должна быть доступна для просмотра информация о его индивидуальном учебном плане и ходе его выполнения. Эта информация должна иметь следующий атрибутивный состав: • Наименование дисциплины в учебном плане • Число аудиторных часов • Общее число часов • Дата сдачи испытания • Вид испытания (экзамен, зачет) • Оценка по 10-балльной шкале • Оценка по 5-балльной шкале • Оценка зачет/незачет • Неявка • Число недель (для курсовых работ, ВКР) • Тема работы • ВУЗ, в котором сдано испытание (в предложном падеже) – для случая перезачета испытаний, сданных в других вузах • Номер ведомости

Требования к составу учетных данных студента (слушателя), доступных для изменения самим слушателем Среди всех данных, доступных студенту (слушателю) программы ДПО для просмотра должна быть выделена категория данных, доступных для изменения самим слушателем. Любые изменения данных, выполняемые слушателем, должны в обязательном порядке проходить процедуру модерации пользователем системы АСАВ, отвечающим за работу с данными о контингенте слушателей ДПО. Изменению самим студентом (слушателем) подлежать следующие данные: Группа атрибутов «Личные и контактные данные» • Фамилия • Имя • Отчество • Дата рождения • Адрес электронной почты • Контактный телефон • Домашний телефон • Рабочий телефон Группа атрибутов «Предыдущее образование» • Уровень предыдущего образования • Документ о предыдущем образовании • Вид документа • Номер документа • Дата документа • Серия документа • Сдан подлинник • ВУЗ • Диплом с отличием • Предыдущее направление/специальность

56

• Предыдущая степень/квалификация Группа атрибутов «Место работы» • Текущее место работы • Дата начала работы • Дата окончания работы • Место работы • Должность • Категория должности • Адрес места работы • Является госслужащим • Категория государственной гражданской службы • Стаж работы на госслужбе Группа атрибутов «Ученая степень» • Ученая степень • Отрасль науки При изменении слушателем какой-либо из групп атрибутов в системе должна формироваться заявка на изменение данных определенного вида. В период с момента рассмотрения заявки до ее рассмотрения модератором повторное изменение данных этой группы должно быть невозможным. При приеме или отклонении заявки модератором удаленный пользователь должен получать подтверждающее письмо по электронной почте. Сценарии работы пользователя по выполнению автоматизируемых задач. Работа удаленного пользователя, являющегося студентом или слушателем программы дополнительного профессионального должны состоять из следующих этапов работы: 1) Регистрация в качестве пользователя web-ресурса (получение логина, пароля для доступа в личный кабинет) на общедоступной странице сервиса (Рис. 4). 2) Работа в личном кабинете (просмотр и уточнение своих учетных данных, получение информации о ходе обучения). 3) Обмен сообщениями с работниками, администрирующими программу ДПО. Работа модератора должна заключаться в рассмотрении поступивших от удаленных пользователей заявок, их принятии или отклонении. Модератор должен действовать по следующему сценарию: 1) В форме «Обслуживание удаленных пользователей» отобрать заявки, находящиеся в статусе «Ожидает рассмотрения». 2) По каждой из заявок просмотреть введенную удаленным пользователем информацию. 3) В случае, если введенная информация признана модератором приемлемой, выполнить действие «Принять заявку». Если информация признана неприемлемой, выполнить действие «Отклонить заявку» с указанием причины отклонения. В отдельных случаях модератор может также выполнить действия «Отметить как принятую» или «Оставить без рассмотрения».

Требования к предварительной модерации данных, направленных удаленным пользователем Требования по модерации данных аналогичны требованиям, описанным выше в разделе 6.2.

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

57

Требования к экранным формам веб-страниц личного кабинета Экранные формы должны быть реализованы в соответствии с представленными макетами:

Рис. 8 Страница личного кабинета слушателя ДПО, раздел корректировки личных данных

58

Рис. 9 Отображение в личном кабинете перечня испытаний учебного плана

59

Требования к техническому обеспечению, прикладному и системному программному обеспечению: Требования к серверу базы данных, web-серверам, рабочим местам удаленных пользователей аналогичны требованиям, представленным выше в п. 6.2.

6.3.2. Требования к документированию. В рамках работ по данной задаче должны быть разработаны: - руководство пользователя Личного кабинета в формате html-документа, доступное с первой страницы сервиса (до прохождения авторизации); - руководство модератора как часть существующей справочной системы АСАВ. 6.3.3. Требования к сопровождению на этапе опытной эксплуатации. В ходе опытной эксплуатации исполнитель должен: • консультировать пользователей по вопросам использования функциональности системы; • фиксировать в специальной системе учета замечаний Заказчика: суть замечаний, дату возникновения замечаний, дату устранения. Длительность этапа опытной эксплуатации не менее двух недель. Сроки проведения опытной эксплуатации должны быть предварительно согласованы с Заказчиком.

6.4. Реализация функциональности участка системы «Дополнительное образование» на подготовительном отделении для поступающих в магистратуру. Требования к составу услуг: № п.п. Состав Форма результата 1 Сбор информации о

необходимых доработках Перечень доработок участка ДПО для учета слушателей ПО в магистратуру.

2 Выполнение доработок участка ДПО

Доработанная функциональность установлена в рабочую конфигурацию системы.

3 Обучение пользователей ПО в магистратуру

Перечень пользователей, прошедших обучение.

4 Поддержка процесса первичного наполнения справочных данных, регистрации поступающих 2011 года, зачисления поступающих

В системе сформированы справочные данные по программам ПО в магистратуру, зарегистрированы поступающие, поступающие зачислены в состав слушателей.

5 Доработка руководства пользователя участка ДПО

Доработанная документация согласованна с исполнителем.

6 Сопровождение на этапе опытной эксплуатации.

Журнал замечаний по эксплуатации.

7 Проведение испытаний Согласованный акт готовности к промышленной эксплуатации

6.4.1. Требования к доработкам функциональности В ходе работы должна быть выявлена необходимость в доработках участка ДПО, обусловленная рядом отличий программ подготовки на Подготовительном отделении в магистратуру от других программ дополнительного профессионального образования: - реализация программ на бюджетной основе; - особенности учебных планов по программам ПО в магистратуру;

60- необходимость связи с участком «Абитуриент» в части функциональности проведения олимпиады студентов и проведения приемной кампании в магистратуру Перечень доработок должен быть реализован и установлен в рабочие конфигурации системы в Москве и филиалах.

6.4.2. Требования к консультационному сопровождению внедрения Исполнитель должен обеспечить консультационное сопровождение работы пользователей Подготовительного отделения на всех этапах работы: - Формирование справочных данных по программам ПО в магистратуру - Занесение учебных планов ПО в магистратуру на 2011/2012 учебный год - Регистрация поступающих 2011 года; - Отражение результатов входного тестирования поступающих; - Зачисление поступающих в состав слушателей; - Назначение слушателям обязательной и вариативной частей учебных планов - Формирование ведомостей на сдачу испытаний - Занесение результатов испытаний - Выполнение действий по перемещению слушателей (переводы, отчисление и т.д.); - Формирование и учет документов о полученном образовании; - Выпуск слушателей На всех этапах работы Исполнителем должен вестись сбор и фиксация в Журнале выявленных ошибок, необходимости доработок, пожеланий по развитию функциональности. Доработки, необходимость которых будет выявлена, должны быть выполнены Исполнителем в рамках внедрения.

6.4.3. Требования к документированию Выполненные доработки функциональности, необходимые для организации учета слушателей Подготовительного отделения в магистратуру, должны быть описаны в Руководстве пользователя участка «Дополнительное образование», входящем в состав единой справочной системы по системе АСАВ. 6.4.4. Требования к сопровождению на этапе опытной эксплуатации. В ходе опытной эксплуатации исполнитель должен: • консультировать пользователей по вопросам использования функциональности системы; • фиксировать в специальной системе учета замечаний Заказчика: суть замечаний, дату возникновения замечаний, дату устранения. Длительность этапа опытной эксплуатации не менее двух недель. Сроки проведения опытной эксплуатации должны быть предварительно согласованы с Заказчиком.

6.5. Реализация функциональности участка «Аспирант» в целях учета аспирантов, обучающихся по программам академической аспирантуры. Требования к составу услуг: № п.п. Состав Форма результата 1 Выполнение доработок участка

«Аспирантура» Доработанная функциональность установлена в рабочую конфигурацию системы.

2 Доработка руководства пользователя участка «Аспирантура»

Доработанная документация согласованна с исполнителем.

3 Сопровождение на этапе опытной эксплуатации.

Журнал замечаний по эксплуатации.

614 Проведение испытаний Согласованный акт готовности к

промышленной эксплуатации

6.5.1. Требования к доработкам функциональности В связи с выделением из числа аспирантов очной формы обучения категории аспирантов, обучающихся по программам академической аспирантуры, на участке «Аспирант» системы АСАВ должны быть выполнены следующие доработки функциональности: 1) Выделение аспирантов, обучающихся по программам академической аспирантуры, в отдельную категорию. 2) Реализация возможности отдельного планирования контрольных этапов обучения для программ академической аспирантуры. 3) Реализация возможности назначения академическим аспирантам со-руководителей - представителей зарубежных вузов. 4) Реализация функциональности формирования и назначения академическим аспирантам учебных планов. 5) Разработка функциональности учета успеваемости аспирантов по дисциплинам учебных планов. 6) Отображение назначенных учебных дисциплин и полученных по ним оценок в Личных кабинетах аспирантов. Возможность отдельного планирования контрольных этапов для академических аспирантов должна позволить в обязательном порядке назначать им стажировки в зарубежных университетах и другие виды работ, не обязательные для аспирантов очной формы обучения. Учебные планы аспирантуры должны формироваться по каждой из научных специальностей на определенный учебный год. Записи о дисциплинах, входящие в состав учебных планов должны иметь следующий атрибутивный состав: • Дисциплина (ссылка на дисциплину из общевузовского справочника дисциплин); • Кафедра / Факультет / Научное подразделение, читающее дисциплину; • Признак Обязательная / По выбору • Общее число часов • Число аудиторных часов • Число кредитов Для назначения учебных планов аспирантам должна быть разработана процедура «Назначить учебный план». Данная процедура должна выполнять назначение аспиранту обязательной части учебного плана. Также должна быть разработана процедура «Назначить дисциплину плана», при помощи которой должно быть возможным назначить выбранному аспиранту одну из необязательных дисциплин плана. Функциональность создания учебных планов и их назначения аспирантам должна быть доступна для всех категорий аспирантов. Успеваемость аспирантов по дисциплинам плана должна заноситься в систему в 5-ти балльной шкале. 6.5.2. Требования к сопровождению на этапе опытной эксплуатации. В ходе опытной эксплуатации исполнитель должен: • консультировать пользователей по вопросам использования функциональности системы; • фиксировать в специальной системе учета замечаний Заказчика: суть замечаний, дату возникновения замечаний, дату устранения. Длительность этапа опытной эксплуатации не менее двух недель.

62Сроки проведения опытной эксплуатации должны быть предварительно согласованы с Заказчиком.

6.6. Реализация функциональности интеграции системы АСАВ с Системой контроля и управления доступом (СКУД) в части передачи в систему АСАВ фотографий студентов и преподавателей.

Общее назначение функциональности Разрабатываемая функциональность предназначена для автоматизации загрузки фотографий учащихся и работников НИУ ВШЭ, присутствующих в базе данных системы контроля доступа (СКУД), в систему АСАВ. Автоматизированная загрузка фотографий должна осуществляться только для тех учащихся и работников, для которых и на стороне БД СКУД, и на стороне БД АСАВ существует единственная запись с сочетанием значений фамилии, имени и отчества. Для учащихся, по которым в БД СКУД или в БД АСАВ существует более одной записи с одинаковым сочетанием фамилии, имени и отчества, загрузка фотографии должна осуществлять индивидуально уполномоченным на выполнение этой процедуры пользователем.

Перечень автоматизируемых задач Разрабатываемая функциональность предназначена для автоматизации следующих задач: 1. Автоматизированная загрузка фотографий для всех студентов и работников или для выбранного списка должна производиться по алгоритму, описанному ниже. По результатам автоматизированной загрузки фотографий должен формироваться протокол загрузки, в котором должно быть указано: – количество фотографий, успешно загруженных по однозначной идентификации; – список ФИО из системы СКУД, которые не соответствуют однозначной идентификации; – список ФИО из ИС АСАВ, которые не соответствуют однозначной идентификации. 2. Предоставление интерфейса для ручного выбора и загрузки фотографии для тех людей, у которых возникла неоднозначность при синхронизации. 3. Формирование отчетов для определения перечня учащихся и работников, у которых отсутствуют персональные фотографии.

Требования к источнику данных (используемая СУБД, ее таблицы и представления, атрибутивный состав доступных данных) Для выполнения процедур автоматизированной загрузки фотографий должна быть обеспечена возможность подключения к базе данных, находящейся под управлением СУБД MS SQL Server. Параметры подключения к СУБД (имя или адрес базы данных, логин и пароль пользователя) должны храниться в текстовом файле, который в свою очередь должен быть загружен в БД системы АСАВ в разделе «Доступные файлы». Доступ к файлу, содержащему параметры подключения к БД с фотографиями, должен быть только у пользователей – администраторов системы АСАВ. При этом возможность подключения к БД и получения фотографий должна быть предоставлена, в том числе, и другим категориям пользователей системы АСАВ. В СУБД, содержащей фотографии, должна существовать таблица с именем «person», в которую регулярно должны загружаться фотографии из системы СКУД. Таблица «person», должна иметь следующую структуру: Наименование Описание pers_id Уникальный идентификатор человека first_name Имя middle_name Отчество last_name Фамилия

63photo Фотография Для успешной идентификации человека необходимо, чтобы поля first_name, middle_name и last_name были обязательно заполнены.

Сценарии работы пользователя по выполнению автоматизируемых задач. Автоматизированная загрузка фотографий для всех студентов и работников вуза должна осуществляться пользователем системы АСАВ, имеющим права администратора или бизнес-администратора. Пользователям этих категорий доступна для работы форма работы с данными «Служебная форма», в которой можно осуществлять работу со всеми существующими в системе АСАВ людьми, учащимися, работниками вуза. Действия для вызова процедур загрузки фотографий должны быть доступны в каждом из представлений «Все учащиеся», «Все работники», «Все люди». Загрузка фотографий студентов одного из факультетов должна быть доступна пользователям ролей «Учебная часть факультета». Также пользователям учебных частей должна быть доступна процедура индивидуального загрузки фотографии для одного или нескольких выбранных студентов. Работа пользователей по загрузке фотографий должна осуществляться по следующему сценарию: 1) Пользователь, имеющий права администратора системы, должен занести параметры подключения к базе данных с фотографиями в текстовый файл и загрузить этот файл в систему на вкладке «Доступные файлы» Системной формы. 2) Пользователь, имеющий права администратора, должен вызвать действие «Загрузить фотографии для всех людей». Параметры подключения к БД СКУД должны быть получены системой из текстового файла из таблицы «Доступные файлы». После подключения к базе данных должен быть начат процесс загрузки. Ход процесса должен отражаться путем отображения окна «прогресса», показывающего процент выполнения загрузки во времени. 3) Пользователь, входящий в роль «Учебная часть факультета» в доступном ему разделе «Студенты - личные данные» должен иметь возможность просмотра фактов наличия или отсутствия в системе АСАВ фотографий студентов своего факультета. По каждому студенту пользователь учебной части должен иметь возможность просмотреть фотографию. 4) Для студентов факультета, у которых нет фотографий, пользователь учебной части должен иметь возможность вызвать действие «Загрузить фотографии для выделенных людей». При выполнении этого действия должно быть установлено соединение с базой данных фотографий (параметры подсоединения должны быть получены из файла, сформированного администратором), для выбора пользователю должна быть предложена таблица с ФИО людей из БД СКУД и фотографиями. Пользователь должен иметь возможность выбрать нужную фотографию и загрузить ее в БД АСАВ для выбранного студента. 5) По результатам загрузки пользователь должен оценить количество учащихся или работников, для которых фотографии остались незагруженными. Сделать это он может путем изучения полученного протокола загрузки, а также путем формирования отчетов: • Список студентов без фотографий; • Список работников без фотографий. Пользователь учебной части должен получить отчет только по студентам своего факультета. Пользователь-администратор должен иметь возможность получить отчет как по любому из факультетов, так и по всем студентам. 6) Для учащихся или работников, для которых фотографии не были загружены по причине неоднозначной идентификации на стороне системы СКУД, пользователь (администратор или пользователь учебной части) должен выполнить действие «Загрузить фотографии для выделенных людей». При выполнении этого действия должно быть установлено подключение к БД СКУД, после чего пользователю должен быть показан перечень

64фотографий, найденных в БД СКУД по строгому соответствию полей Фамилия, Имя и Отчество. Пользователь сможет выбрать нужную фотографию и выполнить загрузку. Этап 6 должен быть повторен пользователем для всех неоднозначно идентифицированных людей.

Требования к алгоритмам автоматизированной загрузки фотографий Сопоставление людей из ИС АСАВ и из системы учета пропусков должна производиться по полям «Фамилия», «Имя» и «Отчество» по следующему алгоритму: 1. Из базы данных, содержащей фотографии, необходимо выбрать записи, у которых сочетание полей, по которым производится идентификация, является уникальным в системе СКУД; 2. Из ИС АСАВ отобрать всех людей, которые имеют категорию учащийся или работник ВУЗа, и сочетание полей, по которым производится идентификация, является уникальным в ИС АСАВ. 3. Осуществить сопоставление записей отобранных на предыдущих этапах. 4. Из полученного в результате списка загрузить фотографии в ИС АСАВ.

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

Требования к процедуре обновления ранее загруженных фотографий В разрабатываемом модуле необходимо так же предусмотреть не только полную синхронизацию, а также и синхронизацию по выбранному списку студентов или работников. При синхронизации записей ИС АСАВ уже имеющих фотографию необходимо обеспечить, чтобы имеющиеся фотографии были в актуальном состоянии по отношению к базе данных СКУД. Для этого можно определять факт наличия новой версии в базе данных СКУД тем или иным путем, либо всегда перезаписывать имеющиеся фотографии данными из промежуточной базы.

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

Требования к составу функций модуля интеграции В состав функций разрабатываемого модуля необходимо включить следующие пункты: – загрузка и обновление фотографий для всех студентов и работников, вызываемая пользователем; - автоматическая загрузка фотографий для всех студентов и работников, не имеющих фотографий в БД АСАВ по расписанию; – загрузка и обновление фотографий для выбранного списка студентов и работников; – предоставление интерфейса для ручного выбора фотографии из списка для тех людей, у которых возникла неоднозначность при синхронизации;

65– формирование отчета, содержащего список учащихся, у которых отсутствуют фотографии; – формирование отчета, содержащего список работников, у которых отсутствуют фотографии.

Требования к формату и составу отчетности по наличию в системе АСАВ фото студентов, аспирантов, преподавателей в разрезе факультетов, групп, кафедр По результатам загрузки в систему АСАВ фотографий пользователь должен иметь возможность сформировать следующие отчеты: 1. Список студентов без фотографий Отчет должен находить и выгружать в файл MS Excel список студентов, у которых отсутствуют фотографии, с возможностью задания критериев отбора по факультету, курсу и группе. Список студентов должен содержать следующие данные: Фамилия, Имя, Отчество, Дата рождения, Пол, Факультет, Курс, Группа. 2. Список работников без фотографий Данный отчет не должен запрашивать у пользователя параметры отбора. Результатом работы отчета должен быть файл MS Excel, содержащий список все работников, у которых в БД АСАВ отсутствует фотография.

6.7. Развитие функциональности интеграции системы АСАВ с сервисом Microsoft LiveEdu.

Общее назначение функциональности Разрабатываемый функционал предназначен для автоматизации функций управления учетными записями сервиса LiveEdu в рамках интеграции с ИС АСАВ. Под управлением учетными записями подразумевается создание и привязывание почтовых адресов системы LiveEdu к студентам ИС АСАВ и синхронизация необходимых атрибутов. Сформированные для студентов адреса электронной почты в системе LiveEdu могут использоваться для автоматизированной рассылки почтовых сообщений студентам НИУ ВШЭ пользователями системы АСАВ. В 2010 году была разработана пилотная версия функциональности, решающая задачи автоматического формирования учетных записей студентов в системе LiveEdu и управления этими учетными записями. По итогам использования пилотной версии функциональности возникла необходимость в изменении алгоритмов работы ряда процедура, расширении атрибутивного состава информации, задействованной в интеграции, предоставление доступа к функциональности новым категориям пользователей.

Перечень автоматизируемых задач Уточнению и дополнительной разработке подлежат следующие задачи: 1. Модификация алгоритмов генерации логина и пароля при создании учетной записи студента. 2. Предоставление возможности создания и синхронизации учетных записей пользователям учебных частей факультетов и отделений. 3. Доработка процедуры отправки почтового сообщения студенту, формирования имени файла приложения. 4. Автоматизация создания адресов учебных групп. 5. Автоматизация заполнения дополнительных атрибутов учетной записи в LiveEdu на основе данных системы АСАВ. 6. Ограничение возможностей студента по изменению данных своего профиля в LiveEdu. 7. Защита информации об адресе электронной почты в LiveEdu в системе АСАВ от случайного изменения и удаления.

66Требования к атрибутивному составу информации, передаваемой в сервис LiveEdu из системы АСАВ Для создания и других операций с почтовой учетной записью студента в системе LiveEdu должны использоваться существующие атрибуты записи о студенте. Добавления новых атрибутов записей о студентах не требуется. Для успешного выполнения операций создания и управления учетной записью студента в АСАВ обязательно должны быть заданы значения ее следующих атрибутов: − Фамилия − Имя − Отчество − Номер студенческого билета − Филиал (на стороне LiveEdu соответствует атрибуту «Город») − Факультет − Курс − Направление / специальность подготовки − Учебная группа Значение атрибута «Краткое имя» учетной записи LiveEdu должно формироваться путем слияния фамилии, имени и отчества (при наличии) и быть недоступным для самостоятельного изменения студентом.

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

Требования к алгоритмам автоматизированного формирования учетных данных (логин, пароль) студента для сервиса LiveEdu В существующем варианте функциональности логин учетной записи системы LiveEdu, формируется в транслитерированном виде по правилу: [первая буква имени] + [первая буква отчества] + [фамилия] + @edu.hse.ru. Если сформированное имя учетной записи уже занято, то система должна попытаться создавать другое имя учетной записи, формируемое на основе изначального, путем добавления к нему номера попытки через символ «_», до тех пор, пока почтовый ящик не будет создан или не произойдет иная ошибка. В новой версии данной функции необходимо модифицировать данный алгоритм, добавив игнорирование всех встречающихся в фамилии, имени или отчестве пробелов (в начале, в конце, в середине слова), а также других небуквенных символов. В существующем варианте функциональности пароль для первой авторизации в созданной учетной записи устанавливается в соответствии с номером студенческого билета выбранного студента. В новой версии данной процедуры при формировании пароля должны использоваться только цифры, входящие в номер студенческого билета. Все нецифровые символы должны игнорироваться.

67Предоставление возможности создания и синхронизации учетных записей пользователям учебных частей факультетов и отделений Для решения данной задачи необходимо реализовать следующие дополнительные возможности: - хранение логина и пароля администратора сервиса LiveEdu в текстовом файле, загружаемом в БД АСАВ в таблице «Доступные файлы»; доступ к загрузке, просмотру и изменению этого текстового файла в АСАВ должны иметь только пользователи АСАВ, входящие в роль «Администраторы»; - реализация возможности обращения к ПО PowerShell, (с помощью которого обеспечивается взаимодействие с установленному сервисом LiveEdu) установленному на сервере приложений системы АСАВ (asav.hse.ru). Необходимость установки ПО PowerShell на рабочем месте пользователя АСАВ должна быть исключена. Реализация данных дополнительных возможностей должна позволить пользователю учебной части факультета вызывать функции управления учетными записями сервиса LiveEdu не зная логин и пароль администратора и без установки на своем рабочем месте дополнительного программного обеспечения.

Доработка процедуры отправки почтового сообщения студенту, формирования имени файла приложения В существующей версии функциональности была реализована возможность отправки письма только с использованием одного из существующих шаблонов почтовых сообщений. В новой версии в процедуру отправки почтового сообщения необходимо внести следующие изменения: - добавить возможность ввода произвольного текста сообщения (длина текста сообщения до 2000 символов); - при выборе прилагаемого файла отображать в форме создания сообщения полный путь к файлу; - в дополнительном поле формы рядом с именем файла отображать размер приложенного файла.

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

Автоматизация заполнения дополнительных атрибутов учетной записи в LiveEdu на основе данных системы АСАВ Процедуры создания и синхронизации учетных записей, разработанные на пилотном этапе, должны быть дополнены возможностями использования дополнительных атрибутов учетных записей LiveEdu. В качестве значений дополнительных атрибутов при создании и синхронизации учетных записей, должны использоваться значения следующих атрибутов записи о студенте в системе АСАВ: • Факультет • Курс • Направление / специальность подготовки • Учебная группа

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

Защита информации об адресе электронной почты в системе АСАВ от случайного изменения и удаления. В целях предотвращения случайного изменения или удаления информации об электронном адресе LiveEdu как одной из записей таблицы «Контактная информация», доступной пользователям учебных частей, необходимо при создании записей данного вида устанавливать значения поля «Роль для записи», равного роли «Администраторы» и позволить предоставить доступ к этой информации на изменение только администраторам системы. Пользователи других категорий должны иметь возможность создавать такие записи только с использованием процедур взаимодействия с LiveEdu. Изменение и удаление электронного адреса студента в системе для этих пользователь будет недоступно.

Требования к механизмам и алгоритмам синхронизации информации о студенте, хранящейся в системе АСАВ и в профиле пользователя LiveEdu Выполнение операции синхронизации должно быть возможным для тех студентов, у которых есть созданная и ассоциированная с ними учетная запись в системе LiveEdu. Синхронизации подлежат следующие атрибуты студента: − Фамилия, имя и отчество; − Город обучения (филиал) − Факультет − Курс − Направление / специальность подготовки − Учебная группа Синхронизация первых двух атрибутов реализована в пилотной версии функциональности. В рамках новой разработки должна быть реализована синхронизация дополнительных 4-х атрибутов. Все записи студентов должны иметь признак синхронизации с LiveEdu, который будет указывать на состояние синхронизации учетной записи.

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

Требования к механизмам синхронизации прав студента на использование сервиса LiveEdu с изменениями статуса студента в системе АСАВ (отчисление, перевод с одного факультета на другой, выпуск и т.д.) При выполнении пользователями участка «Студент» процедур по перемещениям студентов (отчисление, восстановление, переводы, предоставление академического отпуска и проч.) в системе формируются записи о событиях перемещений. Записи о событиях имеют атрибуты студента, по которому произошло событие, даты события, вида события и приказа на основании которого произошло событие. Пользователь, наделенный правами администратора системы LiveEdu, должен иметь доступ к таблицам данных, отображающим события по перемещению студентов. В соответствии с действующим в университете регламентом работы с учетными записями LiveEdu администратор должен иметь возможность вызвать для студента, по которому

69произошло событие, одной из процедур синхронизации с LiveEdu (создание, блокирование, удаление учетной записи).

6.8. Реализация функциональности интеграции системы АСАВ с корпоративным порталом НИУ ВШЭ в части публикации на портале утвержденных рабочих учебных планов. Реализуемый функционал предназначен для организации доступа к данным об учебных планах, формируемых и актуализируемых в системе АСАВ, для посетителей портала НИУ ВШЭ http://www.hse.ru/. Данные об утвержденных рабочих учебных планах (РУП) факультетов и отделений должны быть доступны посредством web-страницы, генерируемой системой АСАВ. Информация об учебных планах должна быть доступна всем посетителям портала без прохождения авторизации.

Перечень автоматизируемых задач Разрабатываемая функциональность должна автоматизировать задачу публикации на корпоративном портале утвержденных рабочих учебных планов. Задача должна быть решена путем создания механизма генерации и предоставления web-страниц, отображающих структурированный в табличном виде перечень утвержденных рабочих учебных планов (РУП) факультетов и отделений университета. Просмотреть каждый учебный план должно быть возможно при переходе по ссылке в колке «Наименование плана». РУП должен предоставляться для просмотра и сохранения в виде файла рабочей книги MS Excel.

Требования к механизмам передачи данных, формату и структуре передаваемых данных Для передачи данных об учебных планах должен использоваться механизм генерации сервером приложений, входящим в состав платформы «Мельница данных», web-страницы, отображающей набор ссылок, соответствующих наименованиям факультетов и отделений, при переходе по которым на странице должен отображаться перечень утвержденных РУП выбранного факультета (отделения). Формат передаваемых данных – HTML-документ с внедренным сценарием javascript. Web-страница, предоставляющая доступ к РУП, должна быть доступна по ссылке следующего вида: http://asav.hse.ru/plans.html?login=lll&password=ppp Строка адреса (URI) должна иметь следующую структуру: • http://asav.hse.ru – адрес web-ресурса системы АСАВ (доменное имя для ресурса должно быть выделено Заказчиком); • plans.html – имя html-документа, отображающего перечень РУП; • login=lll&password=ppp – параметры подсоединения web-сервера к базе данных системы АСАВ для получения данных об учебных планах (в базе данных системы АСАВ должен быть создан специальный пользователь lll с паролем ppp, которому доступны на просмотр только данные, подлежащие публикации); Также должна быть реализована возможность генерации web-страницы отдельно для каждого факультета. Для этого строка адреса должна дополняться параметром faculty. В качестве значения этого параметра должно быть передано Краткое наименование факультета из справочника «Факультеты и отделения» системы АСАВ с заменой пробелов символом «+» (плюс) или символами «%20». Например, по адресу http://asav.hse.ru/plans.html?login=web&password=web&faculty=прикладной+политологии или http://asav.hse.ru/plans.html?login=web&password=web&faculty=прикладной%20политологии должна отобразится web-страница, содержащая утвержденные учебные планы факультета прикладной политологии.

70Доступными для публикации должны быть рабочие учебные планы, находящиеся в статусе «утвержден первым проректором» и «отозван для переутверждения» (значения статусов при этом на web-странице отображаться не должны). Внесение изменений в утвержденный план должно производиться по следующему алгоритму: - пользователь выполняет над планом действие «отозвать для переутверждения»; в этот момент в системе АСАВ существующий план должен перейти в статус «на утверждении» и стать недоступным для отображения на web-странице; одновременно должна создаваться копия утвержденного плана в статусе «отозван для переутверждения», эта копия должна стать доступной вместо ранее утвержденного плана; исходный экземпляр плана и его копия должны быть связаны ссылочной связью; - при повторном утверждении отозванного плана за счет ссылочной связи должна быть найдена созданная ранее копия; копия должна перейти в статус «отозванная версия» и перестать видимой на web-странице, а утвержденный план должен снова получить статус «утвержден первым проректором» и стать снова видимым на web-странице. При подключении программных средств портала к БД системы АСАВ для получения данных о студентах должен использоваться механизм SQL-запросов к СУБД Oracle. Программные средства, осуществляющие подключение, должны самостоятельно управлять форматом и структурой получаемых данных.

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

6.9. Реализация возможности доступа к данным и механизмам системы АСАВ по протоколу SOAP. В связи с расширением состава решаемых задач по интеграции информационных системы ВШЭ возникает потребность предоставлении доступа к системе АСАВ с использованием стандартных протоколов взаимодействия информационных систем. Для моделирования объектов реального мира, их состояния и поведения в системе АСАВ используется объектно-ориентированный подход. Объектная модель системного слоя платформы хранится в системе по тем же принципам, что и модель бизнес-данных, т.е. объекты классов, описывающих метаданные системы (классы, поля, свойства, методы, параметры методов, пользовательские формы и проч.) хранятся в базе данных и доступны для клиентских систем по тем же принципам, что и бизнес-данные. Для организации доступа к объектам объектной модели АСАВ предлагается использовать подсистему доступа к данным, метаданным и механизмам системы по протоколу SOAP, являющуюся расширением платформы «Мельница данных». В рамках решения данной задачи Исполнителем должно быть выполнено: • Разработка и согласование спецификации сервисов, описывающей: набор классов, свойств и методов, к которым предоставляется доступ; правил вызова методов; требуемых параметров быстродействия. • Реализация возможность доступа к указанным в Спецификации классам, свойствам и методам по протоколу SOAP. • Установка и настройка, расширений платформы «Мельница данных» позволяющих обеспечить доступ к системе АСАВ по протоколу SOAP в соответствии со Спецификацией. • Разработаны примеры использования сервисов SOAР в виде сценариев на языке JavaScript.

71 Услуги по реализации средств предоставления доступа по протоколу SOAP должны оказываться Исполнителем в отношении следующих клиентов сервиса: • системы сопровождения учебного процесса построенной на платформе eFront. • портала выпускников, построенного на платформе eFront. Механизмы доступа по протоколу SOAP должны содержать в своем составе средства предоставления клиентам сервиса актуального формального описания сервисов в формате WSDL. В спецификации сервисов для каждого сервиса должно быть представлено: • Назначение сервиса. • Перечень операций сервиса (наименование операций, описание выполняемых действий) • Описание типов сообщений (наименование типа, наименование и назначение элементов комплексных типов). • Входные параметры операции (наименование, описание) • Возвращаемые операцией значения (наименование, описание) • Пример входящего SOAP сообщения; • Пример возвращаемого SOAP сообщения; Образец описания сервиса приведен в разделе 6.9.1. Состав примеров использования сервисов SOAР должен быть согласован с Заказчиком и охватывать основные сервисы и операции. Примеры использования должны быть представлены в виде сценариев на языке JavaScript. При создании текстов примеров необходимо принять за основу реализацию Microsoft JScript в составе Windows Scripting Host. Примеры должны быть представлены в виде текстовых запускаемых файлов с расширением «js» 6.9.1. Пример описания сервиса Сервис для доступа к объектам системы АСАВ класса TContact (Контактная информация) Назначение сервиса. Получение доступа к объектам системы АСАВ класса TContact (Контактная информация) для получения выборки объектов, получения значений свойств объектов, установки значений свойств, а также создания в системе АСАВ новых объектов класса TContact. Перечень операций сервиса: TContact.Properties TContact.Properties.Set TConact.Create Описание типов сообщений. Тип TContact.Properties.Input Состоит из элементов: Имя элемента Тип данных Назначение

ID Строковый, необязательный

Критерий отбора по идентификатору объекта

Name Строковый, необязательный

Критерий отбора по свойству «Имя»

72

Description Строковый, необязательный

Критерий отбора по свойству «Наименование»

ContactType Строковый, необязательный

Критерий отбора по свойству «Вид контакта»

Class Строковый, необязательный

Критерий отбора по свойству «Класс»

ReplicationStatus Строковый, необязательный

Критерий отбора по свойству «Статус репликации»

ContactInfo Строковый, необязательный

Критерий отбора по свойству «Контактная информация»

Master Строковый, необязательный

Критерий отбора по свойству «Мастер»

SourceDataBase Строковый, необязательный

Критерий отбора по свойству «База данных-источник»

SourceDataBaseGUID Строковый, необязательный

Критерий отбора по свойству «GUID базы даных-источника»

SourceDataBaseIsCurrent

Строковый, необязательный

Критерий отбора по свойству «База данных-источник является текущей»

OldID Строковый, необязательный

Критерий отбора по свойству «Идентификатор при создании»

Creator Строковый, необязательный

Критерий отбора по свойству «Создано пользователем»

Created Строковый, необязательный

Критерий отбора по свойству «Создано»

Modifier Строковый, необязательный

Критерий отбора по свойству «Изменено пользователем»

Modified Строковый, необязательный

Критерий отбора по свойству «Изменено»

Reader Строковый, необязательный

Критерий отбора по свойству «Роль для чтения»

Writer Строковый, необязательный

Критерий отбора по свойству «Роль для записи»

Тип TContact.Properties Состоит из элементов: Имя элемента Тип данных Назначение

ID Строковый, обязательный Идентификатор объекта

Name Строковый, обязательный Имя объекта. Не используется.

Description Строковый, обязательный

Наименование объекта. Не используется.

ContactType

Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Элементы перечислений», обязательный

Вид контакта. Определяет вид контакта

Class

Текстовое значение, представляющее собой идентификатор Класс. Фактический класс объекта,

73некоторого объекта класса «Классы», обязательный

ReplicationStatus

Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Элементы перечислений», обязательный

Статус репликации. Определяет порядок репликации объекта.

ContactInfo

Строковый, обязательный

Контактная информация. Содержимое контактной информации

Master

Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Люди», обязательный

Мастер. Ссылается на объект класса «Люди», контакт которого моделируется этим объектом.

SourceDataBase

Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Базы данных», обязательный

База данных-источник. Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Базы данных», который представлял собой текущую базу данных в момент создания объекта.

SourceDataBaseGUID

Строковый, обязательный

GUID базы даных-источника. Глобально уникальный идентификатор объекта класса «Базы данных», который представлял собой текущую базу данных в момент создания объекта.

SourceDataBaseIsCurrent

Логический, обязательный

База данных-источник является текущей. Признак, определяющий, является ли база данных, в которой этот объект был создан, текущей в данный момент.

OldID

Строковый, обязательный

Идентификатор при создании. Идентификатор, присвоенный объекту в той базе данных, в которой он был создан.

Creator

Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Пользователи», обязательный

Создано пользователем. Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Пользователи», который создал объект.

Created Дата со временем, обязательный

Создано. Момент времени создания объекта.

Modifier

Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Пользователи»,

Изменено пользователем. Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Пользователи», который

74обязательный последним модифицировал

состояние объекта.

Modified

Дата со временем, обязательный

Изменено. Момент времени последнего изменения состояния объекта.

Reader

Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Роли безопасности», необязательный

Роль для чтения. Роль безопасности, прямым или опосредованным членам которой объект доступен для чтения.

Writer

Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Роли безопасности», необязательный

Роль для записи. Роль безопасности, прямым или опосредованным членам которой объект доступен для модификации.

Тип TContact.Properties.Set Состоит из элементов: Имя элемента Тип данных Назначение

ID Строковый, обязательный Идентификатор объекта, значения

свойств которого будут изменены.

Name Строковый, необязательный Имя объекта. Не используется.

Description Строковый, необязательный

Наименование объекта. Не используется.

ContactType

Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Элементы перечислений», необязательный

Вид контакта. Если задан, то определяет новое значение свойства «вид контакта»

ContactInfo

Строковый, необязательный

Контактная информация. Если задан, то определяет новое значение содержимого контактной информации

Reader

Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Роли безопасности», необязательный

Роль для чтения. Если задан, то определяет новое значение роли безопасности, прямым или опосредованным членам которой объект доступен для чтения.

Writer

Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Роли безопасности», необязательный

Роль для записи. Если задан, то определяет новое значение роли безопасности, прямым или опосредованным членам которой объект доступен для модификации.

Тип TContact.Create Состоит из элементов:

75Имя элемента Тип данных Назначение

Name Строковый, необязательный Имя объекта. Не используется.

Description Строковый, необязательный

Наименование объекта. Не используется.

Class

Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Классы», необязательный Класс. Не используется.

Master

Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Люди», обязательный

Мастер. Ссылка на тот объект класса «Люди», контакт которого моделируется создаваемым объектом.

Accessor

Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Роли безопасности», необязательный

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

ContactType

Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Элементы перечислений», обязательный

Вид контакта. Определяет вид создаваемого контакта

ContactInfo

Строковый, обязательный

Контактная информация. Определяет содержимое контактной информации

Тип TContact.Create.Result Состоит из элементов: Имя элемента Тип данных Назначение Текстовый узел Строковый, обязательный Идентификатор созданного объекта Ниже следует перечень операций сервиса. Операция TContact.Properties Операция принимает на вход сообщение типа TContact.Properties.Input Операция возвращает сообщение типа TContact.Properties В возвращаемую посылку попадают значения свойств объектов класса «Контактная информация», отобранных в соответствии с заданными в элементах входного сообщения критериях. Пример входящего сообщения: <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soap:Body> <TContact.Properties.Input xmlns="http://????"> <ContactInfo>(095)*</ContactInfo> <ID/>

76 <ContactType/> </TContact.Properties.Input > </soap:Body> </soap:Envelope> Пример исходящего сообщения: <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <TContact.Properties xmlns="http://????"> <object> <ID>37416</ID> <ContactInfo>(095)-876-75-77</ContactInfo> <ContactType>67678</ContactType> </object> <object> <ID>33443</ID> <ContactInfo>(095)-234-44-87</ContactInfo> <ContactType>67678</ContactType> </object> <object> <ID>2314322</ID> <ContactInfo>(095)-122-43-83</ContactInfo> <ContactType>67678</ContactType> </object> </TContact.Properties> </soap:Body> </soap:Envelope> Пример использования сервиса на языке JavaScript: var serviceRootUrl = "http://????" var inputEnvelop = new ActiveXObject("Msxml2.DOMDocument"); inputEnvelop.documentElement = inputEnvelop.createElement("soap:Envelope"); inputEnvelop.documentElement.setAttribute("xmlns:soap", "http://schemas.xmlsoap.org/soap/envelope/"); var bodyNode = inputEnvelop.documentElement. appendChild(inputEnvelop.createElement("soap:Body")); var messageNode = bodyNode. appendChild(inputEnvelop.createElement("TContact.Properties.Input")); messageNode.setAttribute("xmlns", serviceRootUrl); messageNode.appendChild(inputEnvelop.createElement("ContactInfo")). appendChild(inputEnvelop.createTextNode("(095)*")); messageNode.appendChild(inputEnvelop.createElement("ID")); messageNode.appendChild(inputEnvelop.createElement("ContactType")); WScript.StdOut.WriteLine(inputEnvelop.xml); var request = new ActiveXObject("Msxml2.XMLHTTP"); request.open("POST", serviceRootUrl, false); request.setRequestHeader("Content-Type", "text/xml"); request.send(inputEnvelop.xml); WScript.StdOut.WriteLine(request.responseXML.xml); Операция TContact.Properties.Set Операция принимает на вход сообщение типа TContact.Properties.Set

77Операция возвращает сообщение фиктивного пустого типа nodata. Значения свойств, переданные в элементах входной посылки присваиваются объекту, идентификатор которого передан в элементе входной посылки с именем «ID». Пример входящего сообщения: <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soap:Body> <TContact.Properties.Set xmlns="http://????"> <ID>2314322</ID> <ContactInfo>(095)-123-456-78</ContactInfo> </TContact.Properties.Set > </soap:Body> </soap:Envelope> Пример исходящего сообщения: <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <nodata xmlns="http://????" /> </soap:Body> </soap:Envelope> Пример использования сервиса на языке JavaScript: var serviceRootUrl = "http://????" var inputEnvelop = new ActiveXObject("Msxml2.DOMDocument"); inputEnvelop.documentElement = inputEnvelop.createElement("soap:Envelope"); inputEnvelop.documentElement.setAttribute("xmlns:soap", "http://schemas.xmlsoap.org/soap/envelope/"); var bodyNode = inputEnvelop.documentElement. appendChild(inputEnvelop.createElement("soap:Body")); var messageNode = bodyNode. appendChild(inputEnvelop.createElement("TContact.Properties.Set")); messageNode.setAttribute("xmlns", serviceRootUrl); messageNode.appendChild(inputEnvelop.createElement("ContactInfo")). appendChild(inputEnvelop.createTextNode("(095)-123-456-78")); messageNode.appendChild(inputEnvelop.createElement("ID")). appendChild(inputEnvelop.createTextNode("2314322")); WScript.StdOut.WriteLine(inputEnvelop.xml); var request = new ActiveXObject("Msxml2.XMLHTTP"); request.open("POST", serviceRootUrl, false); request.setRequestHeader("Content-Type", "text/xml"); request.send(inputEnvelop.xml); WScript.StdOut.WriteLine(request.responseXML.xml); Операция TConact.Create Операция принимает на вход сообщение типа TContact.Create Операция возвращает сообщение типа TContact.Create.Result

78 Операция производит создание экземпляра объекта «Контактная информация», в качестве параметров вызова конструктора используются значения, переданные в переданные в элементах входной посылки. В ответной посылке возвращается идентификатор созданного объекта. Пример входящего сообщения: <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soap:Body> <TContact.Create xmlns="http://????"> <Master>1212313</Master> <ContactInfo>(095)-122-43-83</ContactInfo> <ContactType>67678</ContactType> </TContact.Create> </soap:Body> </soap:Envelope> Пример исходящего сообщения: <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <TContact.Create.Result xmlns="http://????"> 731264234 </TContact.Create.Result> </soap:Body> </soap:Envelope> Пример использования сервиса на языке JavaScript: var serviceRootUrl = "http://????" var inputEnvelop = new ActiveXObject("Msxml2.DOMDocument"); inputEnvelop.documentElement = inputEnvelop.createElement("soap:Envelope"); inputEnvelop.documentElement.setAttribute("xmlns:soap", "http://schemas.xmlsoap.org/soap/envelope/"); var bodyNode = inputEnvelop.documentElement. appendChild(inputEnvelop.createElement("soap:Body")); var messageNode = bodyNode. appendChild(inputEnvelop.createElement("TContact.Create")); messageNode.setAttribute("xmlns", serviceRootUrl); messageNode.appendChild(inputEnvelop.createElement("Master")). appendChild(inputEnvelop.createTextNode("1212313")); messageNode.appendChild(inputEnvelop.createElement("ContactInfo")). appendChild(inputEnvelop.createTextNode("(095)-123-456-78")); messageNode.appendChild(inputEnvelop.createElement("ContactType")). appendChild(inputEnvelop.createTextNode("67678")); WScript.StdOut.WriteLine(inputEnvelop.xml); var request = new ActiveXObject("Msxml2.XMLHTTP"); request.open("POST", serviceRootUrl, false); request.setRequestHeader("Content-Type", "text/xml"); request.send(inputEnvelop.xml);

79WScript.StdOut.WriteLine(request.responseXML.xml);

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

6.10.1. Описание существующей конфигурации работы системы. В настоящее время эксплуатируется четыре независимых конфигурации системы АСАВ, одна из которых развернута в Москве, и три в филиалах НИУ ВШЭ в Санкт-Петербурге, Нижнем Новгороде и Перми. В Москве система функционирует на основе СУБД Oracle 10.2.0.4. В филиалах система функционирует на основе СУБД Firebird 2.5. Синхронизация метаданных этих баз данных и синхронизация файлов исполняемых модулей платформы обеспечивается «механизмом автоообновления», разработанным специально для решения этой задачи. Синхронизация данных не производится. Большинство пользователей системы Москвы работают в локальной сети НИУ ВШЭ, их подключение к базе данных осуществляется по протоколу TCP/IP. Также в Москве настроена подсистема удаленной работы, использующая сервер приложений (asav.hse.ru). Также в Москве эксплуатируются ряд подсистем web-доступа (Личные кабинеты аспирантов, Личные кабинеты участников олимпиад школьников и студентов, Личные кабинеты абитуриентов магистратуры). Все пользователи систем, развернутых в филиалах, работают в локальной сети филиалов. Текущая конфигурация системы представлена на рис. 10.

6.10.2. Описание целевой архитектуры системы В целевой конфигурации все данные системы должны быть объединены в единой базе данных. Часть пользователи Москвы должна продолжить работать с системой в локальной сети по протоколу TCP/IP. Пользователи филиалов, а также часть пользователей Москвы должны получить возможность работать с системой удаленно (по протоколу HTTP) с использованием приложения «Обозреватель данных» входящего в состав платформы «Мельница данных». Для удаленной работы пользователей должна быть проведена установка ПО и настройка сервера приложений. После перехода к целевой конфигурации пользователи филиалов также должны получить возможность использовать web-приложения системы, которые в настоящее время используются только в Москве. Также необходимо реализовать: - механизм доступа удаленных пользователей к документации (в виде общедоступного web-ресурса на сервере приложений, просмотр и навигацию по документации осуществлять с помощью internet-браузера); - механизм автообновления исполняемых модулей платформы, размещаемых на рабочих местах удаленных клиентов. Схема целевой конфигурации системы представлена на рис. 11.

Требования к рабочим местам удаленных пользователей Система должна обеспечивать необходимое быстродействие при использовании удаленными пользователями компьютеров, соответствующих следующим требованиям: Требования к программному обеспечению: o OC Microsoft Windows XP sp3 или выше o Microsoft Office 2003 или выше Системные требования:

Оперативная память 1 GB 1GB свободного дискового пространства

80

Рис. 10 Текущая конфигурация системы

81

Рис. 11 Целевая конфигурация системы

82

6.10.3. Принципы разграничения прав доступа различных категорий пользователей к данным системы Все пользователи новой конфигурации системы должны разделяться на пользователей, имеющих доступ к данным системы как по Москве, так и по филиалам и на пользователей, имеющих доступ к данным только Москвы или одного филиала. Для каждого из режимов доступа в системе должны быть созданы соответствующие роли. Вхождение пользователя в роль должно определять, какой перечень объектов доступен ему для просмотра, правки, удаления. Роли должны различаться по задачам, решаемым пользователям (например, «разработка учебных планов», «работа со студентами факультета», «работа с выпускниками» и проч.). Принадлежность пользователя к роли должно задаваться путем включения пользователя в эту роль, Также путем установки для пользователей значений настроек «Филиал», «Факультет», «Подразделение ДПО» должен ограничиваться доступ пользователя к объектам в рамках каждой роли. Пустое значение настройки означает, что пользователь имеет доступ к данным всех филиалов (факультетов, подразделений ДПО). В новой конфигурации системы должны быть выделены следующие категории пользователей: • Администраторы системы – осуществляют централизованное администрирование системы, заключающееся в заведении новых пользователей и ролей, включение пользователей в роли, осуществляют администрирование базы данных, настраивают и эксплуатируют систему резервного копирования данных, обеспечивают соблюдение регламентов технического обслуживания системы; имеют доступ ко всем данным системы как по Москве, так и по филиалам, как на чтение, так и на запись • Бизнес-администраторы системы – формируют и поддерживают справочные данные системы, ведущиеся централизовано; имеют доступ ко всем данным системы как по Москве, так и по филиалам на чтение и на запись. • Бизнес-администраторы филиалов – имеют настройку «Филиал»; формируют и поддерживают справочные данные системы, ведущиеся централизовано на уровне филиала; имеют доступ ко всем данным системы одного филиала как на чтение, так и на запись; имеют доступ к справочникам системы, ведущимся централизовано, в режиме «только для чтения». • Менеджеры приемной кампании – формируют и поддерживают справочные данные о каждой приемной кампании, ведущиеся централизовано; работают с данными обо всех абитуриентах университета, включая филиалы как на чтение, так и на запись. • Менеджеры приемной кампании филиала - имеют настройку «Филиал»; формируют и поддерживают справочные данные о каждой приемной кампании, ведущиеся централизовано на уровне филиала; имеют доступ к данным обо всех абитуриентах одного филиала как на чтение, так и на запись. • Пользователи участка «Абитуриент» - работают с данными об абитуриентах Москвы или одного из филиалов; имеют доступ к данным об абитуриентах как на чтение, так и на запись; имеют доступ к справочникам участка «Абитуриент» в режиме «только для чтения». • Операторы участка «Абитуриент» - имеют настройку «Филиал»; осуществляют регистрации абитуриентов Москвы или одного из филиалов; имеют ограниченный доступ к данным об абитуриентах на чтение и на запись; имеют доступ в режиме «только для чтения» к ограниченному набору справочных данных, задействованных в процедуре регистрации. • Менеджеры факультета – имеют настройки «Филиал» и «Факультет»; формируют и поддерживают справочные данные уровня факультета Москвы или факультета филиала; имеют доступ ко всем студентам своего факультета как на чтение, так и на запись; имеют доступ к справочникам, ведущимся централизованно, в режиме «только для чтения». • Пользователи участка «Студент» - имеют настройки «Филиал» и «Факультет»; работают с данными о студентах одного факультета Москвы или филиала в режимах чтения и записи;

83

• Менеджеры аспирантуры – формируют и поддерживают справочные данные участка «Аспирант», ведущиеся централизовано; имеют доступ к данным обо всех аспирантах как Москвы, так и филиалов как на чтение, так и на запись. • Менеджеры аспирантуры филиала – имеют настройку «Филиал»; формируют и поддерживают справочные данные участка «Аспирант», ведущиеся на уровне филиала; имеют доступ к данным обо всех аспирантах либо Москвы, либо одного из филиалов как на чтение, так и на запись. • Пользователи участка «Аспирант» - имеют настройку «Филиал»; работают с данными об аспирантах либо Москвы, либо одного из филиалов в режимах чтения и записи; • Менеджеры участка ДПО – формируют и поддерживают справочные данные участка ДПО, ведущиеся централизованно; имеют доступ к данным обо всех слушателях и студентах ДПО как Москвы, так и филиалов как на чтение, так и на запись; • Менеджеры участка ДПО филиала - имеют настройку «Филиал»; формируют и поддерживают справочные данные участка ДПО, ведущиеся на уровне филиала; имеют доступ к данным обо всех слушателях и студентах ДПО либо Москвы, либо одного из филиалов как на чтение, так и на запись; • Пользователи участка ДПО – имеют настройки «Филиал» и «Подразделение ДПО»; работают с данными о слушателях ДПО одного подразделения ДПО, принадлежащего либо к Москве, либо к одному из филиалов в режимах чтения и записи; • Пользователи участка «Выпускник» - имеют доступ к информации обо всех выпускниках, как Москвы, так и филиалов; имеют доступ к ряду атрибутов выпускника на запись и ко всем атрибутам в режиме чтения. • Пользователи участка «Выпускник» филиала – имеют настройку «Филиал»; имеют доступ к информации о выпускниках либо Москвы, либо одного из филиалов; ряд атрибутов доступен для записи, все атрибуты выпускников доступны на чтение.

6.10.5. Требования к доработкам программного обеспечения Системы Для реализации возможностей разграничения доступа к данным отдельных филиалов должны быть выполнены следующие доработки ПО системы: 1) Разработка справочника «Филиалы», наследующего все атрибуты справочника «Подразделения вуза» (наименование в падежах, дата создания, дата расформирования, индекс подразделения, код в ИС-ПРО и проч.). 2) Добавление настройки «Филиал», значение которой должно задаваться ссылкой на запись справочника «Филиалы». 3) Модификация представлений справочных данных, относящихся к уровню филиала, в целью отбора данных только по тому филиалу, который задан настройкой пользователя. 4) Модификация представлений данных об абитуриентах, студентах, аспирантах, выпускниках с целью отбора данных только по тому филиалу, который задан настройкой пользователя. 5) Добавление параметра «Филиал» в условия выборки и значения в формы отчетов во все статистические и аналитические отчеты по контингенту абитуриентов, студентов, слушателей ДПО, выпускников.

6.11. Объединение справочных и оперативных данных из баз данных систем работающих в Москве и трех филиалах ВШЭ в единую базу данных.

6.11.1. Перечень настроек системы, которые должны вестись централизовано Централизовано должно осуществляться изменение значений следующих настроек: • Наименование вуза (в именительном и других падежах); • Ректор вуза

84

• Текущий набор • Текущий поток набора • Проректор, курирующий аспирантуру • Проректор (директор), курирующий ДПО • Норматив площади в общежитии Пользователи, имеющие настройку «Филиал», должны утратить право доступа к данным настройкам в режиме записи, но должны сохранить возможность доступа в режиме чтения.

6.11.2. Требования к механизмам ведения справочников Все справочники системы должны быть разделены на три категории: - справочники, ведущиеся централизовано на уровне вуза (Ц); - справочники, ведущиеся централизовано на уровне филиала (Ф); - справочники, ведущиеся на уровне подразделения (факультета, кафедры, подразделения ДПО) (П) № п/п

Наименование справочника

Категория справочника**

Категория пользователей

Ответственное подразделение*

Общевузовские справочники 1 Филиалы Ц Бизенс-

администраторы Управление организации учебного процесса (УОУП)

2 Факультеты и отделения Ц Бизенс-администраторы

УОУП

3 Подразделения вуза Ц Бизенс-администраторы

УОУП

4 Переименования вуза Ц Бизенс-администраторы

УОУП

5 Учебные здания Ц Бизенс-администраторы

УОУП

6 Наборы в вуз Ц Менеджеры приемной кампании

Управление по работе с абитуриентами

7 Формы обучения Ц Бизенс-администраторы

УОУП

8 Образовательные программы

Ц Бизенс-администраторы

Методическое управление (МУ)

9 Направления и специальности

Ц Бизенс-администраторы

МУ

10 Степени и квалификации Ц Бизенс-администраторы

МУ

11 Степени по направлениям / Квалификации по специальностям

Ц Бизенс-администраторы

МУ

12 Магистерские программы Ц Бизенс-администраторы

МУ

13 Магистерские специализации

Ц Бизенс-администраторы

МУ

14 Группы стран Ц Бизенс-администраторы

УОУП

85

15 Страны и регионы Ц Бизенс-администраторы

УОУП

16 Приоритетные направления развития

Ц Бизенс-администраторы

УОУП

17 Виды документов Ц Бизенс-администраторы

УОУП

18 Причины перемещений студентов

Ц Бизенс-администраторы

УОУП

19 Категории персонала Ц Бизенс-администраторы

УОУП

Участок «Студент» 20 Календарные периоды

обучения студентов Ц Бизенс-

администраторы МУ

21 Соответствие оценок (шкалы пересчета)

Ц Бизенс-администраторы

УОУП

22 Виды стипендий Ц Бизенс-администраторы

УОУП

23 Основание перехода на индивидуальный учебный план

Ц Бизенс-администраторы

УОУП

24 Основания выплат материальной помощи

Ц Бизенс-администраторы

УОУП

25 Типы образовательных стандартов

Ц Бизенс-администраторы

МУ

26 Образовательные стандарты Ц Бизенс-администраторы

МУ

27 Кафедры факультетов Ф Бизнес-администраторы филиала

Учебное управление филиала

28 Структура курсов и групп факультета

П Менеджеры факультета

Учебные части факультетов

29 Направления и специальности на факультетах

П Менеджеры факультета

Учебные части факультетов

30 Специализации на факультетах

П Менеджеры факультета

Учебные части факультетов

31 Магистерские программы на факультетах

П Менеджеры факультета

Учебные части факультетов

Участок «Абитуриент» 32 Конкурсы в бакалавриат

(включая предметы на конкурс, скидки и проч.)

Ф Менеджеры приемной кампании филиала

Приемная комиссия Москвы (филиала)

33 Конкурсы в магистратуру (включая предметы на конкурс, соответствие олимпиад и проч.)

Ф Менеджеры приемной кампании филиала

Приемная комиссия Москвы (филиала)

34 Олимпиады школьников Ц Менеджеры приемной кампании

Управление по работе с абитуриентами

35 Виды льгот и привилегий для абитуриентов

Ц Менеджеры приемной

Управление по работе с

86

бакалавриата (включая правила рекомендации, правила зачета оценок)

кампании абитуриентами

36 Виды льгот и привилегий для абитуриентов магистратуры (включая правила рекомендации, правила зачета оценок)

Ц Менеджеры приемной кампании

Управление по работе с абитуриентами

Участок «Аспирант» 37 Календарные периоды

обучения аспирантов Ц Менеджеры

аспирантуры Управление аспирантуры и докторантуры

38 Отрасли науки Ц Менеджеры аспирантуры

Управление аспирантуры и докторантуры

39 Научные специальности Ц Менеджеры аспирантуры

Управление аспирантуры и докторантуры

40 Вхождение научных специальностей в отрасли науки

Ц Менеджеры аспирантуры

Управление аспирантуры и докторантуры

41 Структура аспирантуры Ц Менеджеры аспирантуры

Управление аспирантуры и докторантуры

42 Диссертационные советы Ц Менеджеры аспирантуры

Управление аспирантуры и докторантуры

43 Контрольные этапы аспирантов

Ц Менеджеры аспирантуры

Управление аспирантуры и докторантуры

44 Кафедры, реализующие научные специальности

Ф Менеджеры аспирантуры филиала

Отделы аспирантуры филиалов

Участок «Дополнительное образование» 45 Направления

дополнительного образования

Ц Менеджеры участка ДПО

Управление дополнительного образования

46 Форматы программ ДПО Ц Менеджеры участка ДПО

Управление дополнительного образования

47 Продолжительности программ ДПО

Ц Менеджеры участка ДПО

Управление дополнительного образования

48 Институты и центры ДПО Ц Менеджеры участка ДПО

Управление дополнительного образования

49 Категории государственной гражданской службы

Ц Менеджеры участка ДПО

Управление дополнительного образования

50 Программы ДПО Ф Менеджеры участка ДПО филиала

Отдел дополнительного образования

87

филиала (Москвы)

51 Специализации по программам ДПО

Ф Менеджеры участка ДПО филиала

Отдел дополнительного образования филиала (Москвы)

52 Группы слушателей по программам ДПО

П Пользователи участка ДПО

Подразделение ДПО филиала (Москвы)

53 Работники подразделения ДПО

П Пользователи участка ДПО

Подразделение ДПО филиала (Москвы)

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

6.11.3. Принципы объединения справочников и данных Систем, функционирующих в Москве и филиалах в единую базу данных. Должно быть проведено первичное слияние баз данных филиалов в базу данных Москвы. Процедура объединения в ходе загрузки данных должна выполнять идентификацию данных источника на предмет существования в базе-приемнике. Идентификация выполняется в два этапа: - сопоставление по сочетанию значений полей «База данных–источник» и «Идентификатор при создании»; - сопоставление по сочетанию значений полей «Класс», «Мастер», «Родитель», «Имя». Процедура импорта данных должна обрабатывать каждую из записей реплики-источника по следующему алгоритму: 1. Первый этап поиска объекта в базе-приемнике (по значениям полей «База данных–источник» и «Идентификатор при создании»). Если объект найден в базе-приемнике, для него обновляются значения всех свойств, значения которых содержатся в реплике-источнике. В дальнейшем все ссылочные связи других объектов из реплики-источника будут перенаправлены на найденный объект в базе-приемнике. 2. Если объект не найден на предыдущем шаге, выполняется второй этап поиска объекта (по значениям полей «Класс», «Мастер», «Родитель», «Имя»). Если объект найден в базе-приемнике, для него выполняются действия, описанные в п. 1. 3. Если объект не найден на этапе 2, то выполняется добавление объекта в базу-приемник. Новый объект получает значения всех свойств, содержащихся в реплике-источнике. В ходе добавления объекта для всех полей-ссылок выполняется поиск существующих или создание новых объектов по принципам, описанным в п.п. 1 и 2. При этом объекты базы-приемника можно защитить от изменения. При использовании данной опции объекты будут идентифицированы, ссылки на них будут перенаправлены, однако обновления значений свойств этих объектов не произойдет. Для защиты от изменения только отдельных свойств объектов отдельных классов до выполнения экспорта этим свойствам можно установить признак «Для экспорта» равным значению «Нет». В этом случае объекты также будут идентифицированы, значения свойств с признаком «Для экспорта» равным значению «Да» будут обновлены, а значения свойств с признаком «Для экспорта» равным значению «Нет» останутся такими, какими они были в базе-приемнике.

88

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

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

№ этапа

Этап Ответственный

1. Доработки функциональности системы (добавление новых справочников, настроек, модификация представлений), описанные в п. 6.9.5. Выполнение обновлений баз данных в Москве и филиалах с целью приведения их к единой версии

Исполнитель

2. Выполнение «пилотного» этапа объединения баз данных 2.1. Подготовка данных баз филиалов к экспорту

(выполнение процедур аудита данных на предмет наличия ошибок дублирования, «потерянных» ссылок, неиспользуемых записей справочников).

Исполнитель

2.2. Выполнение экспорта данных из БД филиалов Исполнитель 2.3. Развертывание копии базы данных Москвы на

резервном сервере. ДИТ НИУ ВШЭ

2.4. Подготовка базы данных Москвы к импорту (защита базы-приемника, аудит данных).

Исполнитель

89

2.5. Выполнение импорта данных по филиалам Исполнитель 2.6. Анализ технических ошибок импорта, их

исправление в базе-приемнике и базе-источнике Исполнитель

2.7. Выполнение импорта данных из реплик всех филиалов

Исполнитель

2.8. Доработка руководства пользователя в части работы с единой базой данных

Исполнитель

3. Анализ результатов объединения данных (проверка полноты переноса данных путем анализа статистических отчетов, анализ корректности отбора данных, отображаемых для пользователей Москвы и филиалов)

Исполнитель, пользователи Москвы, пользователи филиалов, ДИТ НИУ ВШЭ.

4. Устранение ошибок и противоречий, выявленных на «пилотном» этапе

Исполнитель

5. Установка и настройка оборудования и каналов связи ДИТ НИУ ВШЭ 7. Разработка методики испытаний целевой

конфигурации Исполнитель

8. Выполнение объединения баз данных в рабочем режиме с учетом замечаний по результатам предварительного импорта.

Исполнитель

9. Опытно-промышленная эксплуатация (Длительность не менее одного месяца)

Пользователи Москвы, филиалов, ДИТ

10. Сопровождение и администрирование системы, консультирование пользователей на этапе Опытно-промышленной эксплуатации. (Длительность не менее одного месяц)

Исполнитель.

11. Проведение приемо-сдаточных испытаний Исполнитель, ДИТ В течение 10 рабочих дней с даты заключения договора должно быть проведено уточнение и согласование сроков выполнения пунктов плана.

6.12. Общие требования к доработкам функциональности В рамках оказания услуг по развитию функциональности по п.п. 6.1.- 6.9. Исполнитель разрабатывает действующий макет решения, устанавливает его на тестовом сервере Заказчика, проводит демонстрацию ключевым пользователям Системы, осуществляет сбор замечаний по разработанной функциональности, устраняет замечания, осуществляет установку обновлений на рабочую версию Системы. 6.13. Прочие требования. При разработке должны использоваться следующие средства/языки программирования и библиотеки: • Средства разработки прикладных решений платформы «Мельница данных», в том числе встроенный язык Pascal-script • Для реализации WEB интерфейсов должны использоваться HTML, JScript • Отчеты должны быть разработаны средствами платформы «Мельница данных», шаблоны отчетов должны быть разработаны на основе документов MS Word, рабочих книг MS Excel, XSLT-преобразований; Предварительные испытания, первичная демонстрация функциональности должны выполняться на тестовой конфигурации развертываемой Исполнителем на технических средствах Заказчика.

90

Все программное обеспечение, разработанное в рамках данного технического задания, должно быть установлено и настроено на программно-аппаратной базе Заказчика, а также передано в виде единого пакета обновления системы «АСАВ» в формате подсистемы установки обновлений в электронном виде и инструкции по его установке, в случае если порядок установки отличатся от установки стандартных пакетов обновлений. Услуги по установке обновлений в рабочую конфигурацию системы должны выполняться в нерабочее время, по предварительному согласованию с Заказчиком. Исполнитель должен самостоятельно ознакомиться с технологическими возможностями платформы «Мельница данных» по материалам поставляемым производителем платформы и материалам, представленным на WEB-сейте производителя платформы (http://www.techmill.ru). Заказчик не оказывает консультаций по использованию платформы «Мельница данных». 7. Место, условия и сроки оказания услуг: Срок оказания услуг по договору – с даты заключения договора до 30 ноября 2011 года. Результаты оказания услуг должны быть представлены по адресу Заказчика: г. Москва, ул. Мясницкая, д. 20, комната 222. 8. Требования к сроку и объему предоставления гарантий качества услуг В срок, являющийся критерием оценки, - в течение 6 (шести) месяцев с даты подписания акта сдачи-приемки услуг (Gmin = 6) Исполнитель должен безвозмездно устранять ошибки, выявленные Заказчиком в сопроводительной документации и работе функциональности системы, реализованной или измененной в ходе оказания услуг в соответствии с данным Техническим заданием. 9. Размер обеспечения заявки на участие в конкурсе: 5% начальной цены договора. 10. Размер обеспечения исполнения договора: 10% начальной цены договора. 11. Руководство (контроль выполнения договора). Контроль выполнения Договора осуществляет: заместитель директора по ИТ, Билевский Сергей Георгиевич, тел./факс (495) 772-95-90, доб. 1637. Адрес: Москва, ул. Мясницкая, д. 20, комната 222.

91

Формы заявки Форма 1

На бланке Участника размещения заказа ________________№ ______________

ЗАЯВКА

на участие в конкурсе на оказание услуг по разработке и внедрению новой функциональности автоматизированной

системы (АСАВ), в рамках реализации «Программы развития государственного образовательного бюджетного учреждения высшего профессионального образования «Государственный университет – Высшая школа экономики», в отношении которого установлена категория

«национальный исследовательский университет», на 2009 – 2018 годы», передаче Заказчику результатов оказанных услуг, а также предоставлению Заказчику прав на использование

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

организации и проведения открытого конкурса, мы ________________________________________________________________________________

(наименование организации и почтовый адрес участника размещения заказа) согласны оказать предусмотренные конкурсом услуги в соответствии с условиями и требованиями, установленными в конкурсной документации, и на условиях, которые мы представили в настоящем предложении. Предлагаем заключить договор на оказание услуг по разработке и внедрению новой функциональности автоматизированной системы (АСАВ), в рамках реализации «Программы развития государственного образовательного бюджетного учреждения высшего профессионального образования «Государственный университет – Высшая школа экономики», в отношении которого установлена категория «национальный исследовательский университет», на 2009 – 2018 годы», передаче Заказчику результатов оказанных услуг, а также предоставлению Заказчику прав на использование результатов, являющихся результатом интеллектуальной деятельности, на условиях и в соответствии с документами, входящими в настоящую заявку на участие в конкурсе, на общую сумму: ____________________________________________________________________________________. (сумма в рублях цифрами и прописью)

Настоящим гарантируем достоверность представленной нами в заявке информации и

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

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

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

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

92

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

Данная заявка на участие в конкурсе представлена с пониманием того, что: - Заказчик оставляет за собой право отклонить или принять заявку на участие в конкурсе,

отклонить все заявки на участие в конкурсе; - Заказчик не несет ответственности за такие действия и не берет на себя обязательство

информировать Участника размещения заказа об их причинах без соответствующего запроса с нашей стороны.

Сообщаем, что для оперативного уведомления нас по вопросам организационного характера и взаимодействия с Заказчиком нами уполномочен ___________________________________________________________________________________

(Ф.И.О., телефон представителя Участника размещения заказа) Все сведения о конкурсе просим сообщать уполномоченному лицу. Настоящей заявкой гарантируем достоверность представленной нами информации. Телефон: _____________________; Факс: ________________________; Корреспонденцию в наш адрес просим направлять по адресу:

__________________________________________________________________. К настоящей заявке прилагаются документы согласно описи – на ___ стр. Форма должна быть подписана уполномоченным лицом Участника размещения заказа и

скреплена печатью Участника размещения заказа.

(подпись) (фамилия, имя, отчество подписавшего лица, должность)

М.П.

(подпись) (фамилия, имя, отчество главного бухгалтера)

93

Форма 2 Приложение 1

к заявке на участие в конкурса от «____»_____________ г. № __________

Анкета Участника размещения заказа

На бланке организации Дата, исх. номер

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

2. Регистрационные данные: Дата, место и орган регистрации юридического лица, (на основании свидетельства о государственной регистрации или иного документа, выдаваемого иностранным компаниям при регистрации)

3. Участники (перечислить наименования и организационно-правовую форму всех участников, чья доля в уставном капитале превышает 10%) и доля их участия (для акционерных обществ – на основании выписки из реестра акционеров) (на основании учредительных документов)

3.1. Срок деятельности организации (с учетом правопреемства)

3.2. Размер уставного капитала 3.3. Почтовый адрес инспекции ФНС РФ по месту регистрации Участника, контактные лица (налоговые инспекторы) и их телефоны.

3.4. Почтовый адрес арбитражного суда по месту регистрации участника, контактные лица и их телефоны, или соответствующая справка об отсутствии дела о банкротстве (с датой выдачи не ранее, чем 30 дней до даты окончания приема заявок на участие в конкурсе).

ИНН, КПП, ОГРН, ОКПО Участника размещения заказа Примечание: Вышеуказанные данные могут быть по усмотрению Участника размещения заказа подтверждены путем предоставления следующих документов: – Учредительные документы участника предварительного отбора; – Свидетельство о государственной регистрации; – Информационное письмо об учете в ЕГРПО; – Свидетельство о постановке на учет в налоговом органе.

Страна 4. Место нахождения Участника размещения заказа Адрес Страна Адрес Телефон

5. Почтовый адрес Участника размещения заказа

Факс 6. Банковские реквизиты (может быть несколько): 6.1. Наименование обслуживающего банка 6.2. Расчетный счет 6.3. Корреспондентский счет

94

6.4. Код БИК Примечание: Представляется информация обо всех открытых счетах. Вышеуказанные данные могут быть подтверждены путем предоставления письма из банка об открытии расчетного счета. 7. Сведения о выданных Участнику размещения заказа лицензиях, необходимых для выполнения обязательств по договору (указывается лицензируемый вид деятельности, реквизиты действующей лицензии, наименование территории на которой действует лицензия)

8. Сведения о дочерних и зависимых предприятиях 9. Балансовая стоимость активов

Форма должна быть подписана уполномоченным лицом Участника размещения заказа и

скреплена печатью Участника размещения заказа.

(подпись) (фамилия, имя, отчество подписавшего лица, должность)

М.П.

(подпись) (фамилия, имя, отчество главного бухгалтера)

95

Форма 3 Приложение 2

к заявке на участие в конкурсе от «____»_____________ г. № __________

СВЕДЕНИЯ ОБ УЧАСТИИ УЧАСТНИКА РАЗМЕЩЕНИЯ ЗАКАЗА В СУДЕБНЫХ РАЗБИРАТЕЛЬСТВАХ

п/п

Год начала и окончания судебного разбирательства

Наименование и адрес истца

Судебный акт (решение, постановление, определение).

2 3 4

Инструкции по заполнению В этой форме Участник указывает все судебные разбирательства, по которым Участник выступал в качестве

ответчика. Форма должна быть подписана уполномоченным лицом Участника размещения

заказа и скреплена печатью Участника размещения заказа.

(подпись) (фамилия, имя, отчество подписавшего лица, должность)

М.П.

(подпись) (фамилия, имя, отчество главного бухгалтера)

96

Форма 4 Приложение 3

к заявке на участие в конкурсе от «____»_____________ г. № __________

СВЕДЕНИЯ О ФУНКЦИОНАЛЬНЫХ ХАРАКТЕРИСТИКАХ УСЛУГ И

УСЛОВИЯХ ИСПОЛНЕНИЯ ДОГОВОРА

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

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

№ п/п Требования Заказчика

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

1 2 3 1. Оказание услуг по разработке и внедрению новой

функциональности автоматизированной системы (АСАВ), в рамках реализации «Программы развития государственного образовательного бюджетного учреждения высшего профессионального образования «Государственный университет – Высшая школа экономики», в отношении которого установлена категория «национальный исследовательский университет», на 2009 – 2018 годы», передаче Заказчику результатов оказанных услуг, а также предоставлению Заказчику прав на использование результатов, являющихся результатом интеллектуальной деятельности. В данном пункте в графе 3 участник размещения заказа должен описать предлагаемую концепцию оказания услуг в соответствии с требованиями заказчика, указанными в настоящей конкурсной документации Требования, установленные заказчиком, к качеству, техническим характеристикам услуг, требования к результатам услуг: Система Абитуриент – Студент – Аспирант – Выпускник существует в Высшей школе экономики (далее НИУ ВШЭ) с 2005 года, и состоит из модулей, каждый из которых реализует функциональность по учету контингента: абитуриенты, студенты, аспиранты и выпускники, слушатели программ дополнительного профессионального образования. Система реализована на базе технологической платформы «Мельница данных» (http://www.techmill.ru). Исполнителем должны быть оказаны следующие услуги по развитию и внедрению системы АСАВ: 1. Реализация функциональности автоматизированного рабочего места (АРМ) работника Управления международной академической мобильности (УМАМ). 2. Реализация функциональности web-регистрации поступающих на программы дополнительного профессионального образования (ДПО). 3.Реализация функциональности Личного кабинета слушателя программ дополнительного

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

97

профессионального образования (ДПО). 4.Реализация функциональности участка системы «Дополнительное образование» на подготовительном отделении для поступающих в магистратуру. 5.Реализация функциональности участка «Аспирант» в целях учета аспирантов, обучающихся по программам академической аспирантуры. 6.Реализация функциональности интеграции системы АСАВ с Системой контроля и управления доступом (СКУД) в части передачи в систему АСАВ фотографий студентов и преподавателей. 7.Развитие функциональности интеграции системы АСАВ с сервисом Microsoft Live@Edu далее LiveEdu. 8.Реализация функциональности интеграции системы АСАВ с корпоративным порталом НИУ ВШЭ в части публикации на портале утвержденных рабочих учебных планов. 9.Реализация возможности доступа к данным и механизмам системы АСАВ по протоколу SOAP (Simple Object Access Protocol). 10.Доработка архитектуры системы с целью обеспечения возможностей учета данных в филиальной структуре с применением единой базы данных. 11.Объединение справочных и оперативных данных из баз данных систем работающих в Москве и трех филиалах ВШЭ в единую базу данных 1. Реализация функциональности автоматизированного рабочего места (АРМ) работника Управления международной академической мобильности (УМАМ). Требования к составу услуг: № п.п.

Состав Форма результата

1 Доработка функциональности системы АСАВ для выделения рабочего места работника УМАМ.

Доработанная функциональность установлена в рабочую конфигурацию Системы.

2 Доработка документации: -инструкции пользователя – работника УМАМ;

Доработанная документация согласованна с исполнителем.

3 Проведение предварительных испытаний

Согласованный акт готовности к опытной эксплуатации

4 Обучение пользователей и сопровождение на этапе опытной эксплуатации.

Журнал замечаний по эксплуатации.

5 Проведение испытаний Согласованный акт готовности к промышленной эксплуатации

1.1.1. Требования к доработке функциональности. Общее назначение функциональности

98

Управление международной академической мобильности (УМАМ) создано в НИУ ВШЭ с целью организационного и консультационного сопровождения обменов, стажировок, иных форм академической мобильности студентов и аспирантов, а также студентов, аспирантов и преподавателей университетов – партнеров НИУ ВШЭ по программам обменов. В системе АСАВ в настоящее время ведется учет студентов факультетов и отделений, обучающихся по основным образовательным программам высшего профессионального образования, аспирантов, зачисляемых для обучения в аспирантуре, студентов и слушателей программ дополнительного профессионального образования. Задачей данной разработки является выделение новой категории обучающихся в университете – иностранных студентов, зачисляемых в НИУ ВШЭ для прохождения обучения различной продолжительности. Иностранные студенты, в отличие от студентов, учитываемых в системе, не обязательно должны принадлежать к одному из факультетов, их учебный план всегда является индивидуальным и может формироваться из дисциплин и других видов нагрузки, преподаваемых на разных факультетах и отделениях университета в рамках различных учебных планов. В учебный план иностранных студентов также могут входить летние и зимние школы, другие мероприятия, не входящие в рабочие учебные планы факультетов и отделений НИУ ВШЭ. Работники УМАМ должны получить возможность учитывать иностранных студентов, проходящих обучение в НИУ ВШЭ, средствами системы АСАВ, формировать для них учебные планы, ведомости на сдачу испытаний. Оценки, полученные иностранными студентами должны заноситься в систему АСАВ и в дальнейшем могут включаться в массивы данных, по которым выполняется анализ успеваемости. По окончании обучения иностранного студента в НИУ ВШЭ работники УМАМ должны иметь возможность сформировать «транскрипт» - документ о прохождении обучения, выдаваемый иностранному студенту. Документ должен содержать перечень сданных иностранным студентом дисциплин и выполнения других видов учебной нагрузки, полученные оценки и количество набранных кредитов. Перечень автоматизируемых задач Разработка функциональности рабочего места Управления международной академической мобильности должна позволить автоматизировать следующие учетные задачи: 1) Формирование в системе АСАВ записей об иностранных студентах, проходящих обучение разной продолжительности в рамках стажировок, программ обмена, а также на других основаниях. 2) Предоставление работникам УМАМ доступа к информации о студентах факультетов и отделений, имеющих иностранное гражданство, учет которых осуществляют пользователи учебных частей. 3) Составление индивидуальных учебных планов иностранных студентов. 4) Формирование ведомостей на сдачу испытаний иностранных студентов.

99

5) Учет успеваемости иностранных студентов по различным дисциплинам. 6) Формирование документов о прохождении иностранными студентами обучения в НИУ ВШЭ («транскриптов»). 7) Формирование статистических и аналитических отчетов по численности и структуре контингента иностранных студентов, их успеваемости. Требования к разработке новых или расширения функциональности существующих классов «статусов» учащихся для целей учета иностранных студентов С целью учета в системе иностранных студентов, проходящих обучение по индивидуальным учебным планам, в системе должен быть разработан новый класс «Слушатель», являющийся дочерним по отношению к классу «Студент». Использование наследования класса «Слушатель» от класса «Студент» позволит использовать в классе «Слушатель» все поля, свойства и методы, существующие у класса «Студент», дополнив их полями, свойствами и методами, специфичными для класса «Слушатель». Наряду с изменениями, вносимыми в классы статусов студентов, должен быть реализован новый класс - справочник «Программы стажировок и обменов», который позволит вести учет иностранных студентов в рамках программ, по которым они проходят подготовку в НИУ ВШЭ. Требование к атрибутивному составу информации, необходимой для работы Управления международной академической мобильности Объекты нового класса «Слушатель» должны иметь следующий атрибутивный состав: • Фамилия на русском языке • Фамилия на английском языке • Имя на русском языке • Имя на английском языке • Дата рождения • Гражданство (страна) • Дата начала статуса • Дата окончания статуса • № приглашения • № паспорта • Направление обучения в НИУ ВШЭ • Программа, по которой проходит обучение • Тип программы (обмен, стажировка, …) • Вуз, в котором проходит основное обучение («материнский вуз») • Страна принадлежности вуза • Номер приказа о зачислении в НИУ ВШЭ • Дата приказа о зачислении в НИУ ВШЭ • Номер студенческого билета • Вид выданного документа об образовании • Серия выданного документа об образовании • Номер выданного документа об образовании • Дата выдачи документа об образовании • Регистрационный номер выданного документа об образовании Объекты нового класса – справочника «Программы

100

стажировок и обменов» должны иметь следующий атрибутивный состав: • Краткое наименование программы (на русском языке) • Краткое наименование программы (на английском языке) • Полное наименование программы (на русском языке) • Полное наименование программы (на английском языке) • Дата открытия программы • Дата закрытия программы • Вуз-партнер • Страна принадлежности вуза-партнера Также в функциональности учета иностранных студентов должен использоваться существующий класс «Испытания по учебному плану», набор атрибутов которого не меняется. Требование к функциональности разработки индивидуальных учебных планов (ИУП) иностранных студентов При формировании индивидуального учебного плана иностранного студента необходимо реализовать возможность использования процедуры «Назначить дисциплину любого плана», и обеспечить возможность выбирать и назначать любую дисциплину из любого РУП, а также назначать общеуниверситетский факультатив. Применение процедуры «Назначить дисциплину любого плана» должно быть доступно для каждой из дисциплин, планируемых к изучению иностранным студентом. Для включения в ИУП иностранного студента летних или зимних школ, других научных или учебных мероприятий, не входящих в РУПы НИУ ВШЭ, должна быть реализована возможность воспользоваться существующей функциональностью по работе с общеуниверситетскими факультативами. Требования к сценарию работы с новой функциональностью Работа пользователя Управления международной академической мобильности по учету иностранных студентов и их успеваемости должна выполняться по следующему сценарию: 1) Формирование справочника «Программы стажировок и обменов». 2) Добавление иностранного студента – кандидата на зачисление. В системе должна быть реализована единая процедура добавления иностранного студента, позволяющая вводить личные данные, контактную информацию студента, информацию направлении его обучения, материнском вузе, и проч. 3) Зачисление иностранного студента в НИУ ВШЭ на основании приказа. 4) Формирование индивидуального учебного плана иностранного студента. 5) Формирование ведомостей для сдачи испытаний иностранным студентом. 6) Занесение результатов испытаний, сданных иностранным студентом. 7) Формирование печатной формы документа (транскрипта), выдаваемого иностранному студенту по

101

итогам обучения в НИУ ВШЭ. 8) Отчисление иностранного студента. Экранные формы должны быть реализованы в соответствии с представленными макетами в Техническом задании. Работа с испытаниями иностранных студентов и их результатами должна осуществляться в таблице «Рубежный контроль по периодам». В подчиненной таблице «Сдачи испытания студентами» должны быть доступны действия контекстного меню по формированию ведомостей (в соответствии с Техническим заданием) Требования к составу отчетной информации Функциональность учета иностранных студентов, предназначенная для пользователей Управления международной академической мобильности, должна позволять формировать следующие отчетные формы: • Список иностранных студентов по программе за заданный период времени • Ведомость сдачи испытания иностранным студентом • Результаты успеваемости иностранного студента • Численность иностранных студентов по программам за заданный период времени • Транскрипт Требования к макетам отчетных форм и правилам их формирования 1) Отчет Список иностранных студентов программы Отчет должен формироваться из таблицы данных, отображающей иностранных студентов. Параметрами формирования отчета должны быть: • Программа стажировок и обменов • Дата начала периода • Дата окончания периода Отчет должен формироваться в табличной форме в виде файла MS Excel. В таблицу, отображаемую в отчете, должны попасть все иностранные студенты, проходившие обучение по выбранной программе, дата начала обучения которых попадает в период, заданный пользователем. 2) Отчет Ведомость сдачи испытания иностранным студентом Отчет должен формироваться для одного выбранного испытания. В зависимости от вида испытания отчет должен иметь заголовок «Экзаменационная ведомость» или «Зачетная ведомость». Отчет должен формироваться в виде файла MS Excel. 3) Отчет Результаты успеваемости иностранного студента Отчет должен формироваться для выбранного студента. В отчете должны быть отображены все испытания, назначенные иностранному студенту согласно его индивидуальному учебному плану. По сданным испытаниям должны быть отображены полученные оценки. Отчет должен формироваться в виде файла MS Excel. 4) Отчет Численность иностранных студентов по программам Отчет должен отображать данные о численности иностранных студентов, прошедших обучение в НИУ ВШЭ по различным программам обмена и стажировок за заданный период времени. Параметрами отчета должны быть даты начала и окончания периода. Отчет должен

102

формироваться в виде файла MS Excel. 5) Транскипт Отчет «Транскрипт» должен формироваться на английском языке в виде файла MS Word в формате, представленном на рис. 3 Технического задания. Отчет должен состоять из двух страниц. На первой странице должна отображаться информация о НИУ ВШЭ и данные студента (ФИО, пол, дата рождения, гражданство, паспортные данные, «материнский» вуз и проч.), описание принципов организации учебного процесса в НИУ ВШЭ. На второй странице документа должен быть отображен перечень сданных студентом в НИУ ВШЭ дисциплин, дополненный следующими атрибутами: - Полное наименование дисциплины на английском языке; - ФИО и ученая степень преподавателя; - Факультет, подразделение, на котором прослушан курс; - Язык, на котором преподавался курс; - Число общих и аудиторных часов; - Число кредитов за курс; - Оценка студентов (полученный балл и максимальное число баллов, например, «7 out of 10) 1.1.2. Требования к сопровождению на этапе опытной эксплуатации. В ходе опытной эксплуатации исполнитель должен: • консультировать пользователей по вопросам использования функциональности системы; • фиксировать в специальной системе учета замечаний Заказчика: суть замечаний, дату возникновения замечаний, дату устранения. Длительность этапа опытной эксплуатации не менее двух недель. Сроки проведения опытной эксплуатации должны быть предварительно согласованы с Заказчиком. 1.2 Реализация функциональности web-регистрации поступающих на программы дополнительного профессионального образования (ДПО). Требования к составу услуг: № п.п.

Состав Форма результата

1 Доработка функциональности системы АСАВ.

Доработанная функциональность установлена в рабочую конфигурацию Системы.

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

Доработанная документация согласованна с исполнителем.

3 Проведение предварительных испытаний

Согласованный акт готовности к опытной эксплуатации

103

4 Обучение пользователей и сопровождение на этапе опытной эксплуатации.

Журнал замечаний по эксплуатации.

5 Проведение испытаний Согласованный акт готовности к промышленной эксплуатации

1.2.1. Требования к доработке функциональности. Общее назначение функциональности Разрабатываемая в рамках настоящего технического задания новая функциональность системы АСАВ предназначена для организации взаимодействия пользователей системы, являющихся работниками институтов и центров дополнительного профессионального образования (ДПО) или работниками Управления дополнительного образования (пользователи участка «Дополнительное образование»), с лицами, желающими поступить на программы ДПО. Создаваемая подсистема должна позволить удаленному пользователю (поступающему) получить учетную запись в системе, после чего подать заявку на регистрацию в качестве поступающего на одну из предлагаемых программ. По результатам рассмотрения заявки удаленный пользователь должен быть проинформирован о результате ее рассмотрения – регистрации поступающего или отклонении заявки. После регистрации поступающий должен иметь возможность корректировать введенные им личные данные, информацию об образовании, изменять выбор программы. Все действия удаленного пользователя в личном кабинете должны осуществляться на основе заявок – специальных записей базы данных, содержащих введенную удаленным пользователем информацию, предназначенную для предварительного просмотра модератором с последующим «приемом» (применением сделанных изменений) или отклонением. Пользователи участка «Дополнительное образование» должны получить доступ к информации обо всех заявках удаленных пользователей, поданных на программы институтов и центров ДПО, возможность предварительного рассмотрения, принятия или отклонения заявок, возможность обмена с удаленными пользователями дополнительной информацией. Перечень автоматизируемых задач В рамках разрабатываемой подсистемы автоматизации подлежат следующие задачи: 1) Регистрация в системе АСАВ удаленного пользователя как поступающего на программы ДПО. 2) Создание и отправка удаленным пользователем заявки на регистрацию в качестве поступающего, включающую заданный набор его личных данных, контактную информацию, информацию о предыдущем образовании, месте работы выбранную программу обучения. 3) Рассмотрение поступивших заявок пользователями – модераторами от подразделений ДПО; прием или отклонение заявок; возможность корректировки данных, введенных удаленным пользователем. 4) Создание на основе принятых заявок записей о

104

поступающих на программы ДПО. 5) Корректировка удаленными пользователями своих данных о поступлении на этапе после подачи заявки до зачисления на программу ДПО в качестве студента или слушателя. 6) Обмен сообщениями системы и письмами электронной почты между удаленными пользователями (поступающими) и пользователями системы АСАВ, отвечающими за набор студентов и слушателей. 7) Сбор данных для формирования отчетных форм по поступающим на программы ДПО. Требования к атрибутивному составу информации, необходимой для регистрации поступающего В справочнике системы АСАВ «Форматы программ ДПО» / «Продолжительности программ ДПО» существует признак «Допустима краткая форма регистрации». В зависимости от наличия или отсутствия этого признака при регистрации на программу у удаленного пользователя должен запрашиваться разный набор атрибутов. Полная процедура регистрации должна требовать заполнение пользователем следующего набора полей (поля объединяются в группы полей): Группа полей «Персональные данные» • Фамилия • Имя • Отчество • Дата рождения • Пол Группа полей «Документ, удостоверяющий личность» • Вид документа • Гражданство • Серия • Номер • Кем выдан • Дата выдачи Группа полей «Информация о месте постоянной регистрации» • Почтовый индекс • Регион проживания • Тип населенного пункта • Населенный пункт • Населенный пункт • Адрес регистрации Группа полей «Контактная информация» • Адрес фактического проживания • Домашний телефон • Рабочий телефон • Контактный телефон • E-mail Группа полей «Информация о предыдущем образовании» • Вид документа об образовании • Направление/специальность • Наименование направления/специальности • Степень/квалификация • Наименование степени/квалификации • Серия • Номер • Дата выдачи

105

• С отличием • Сдан подлинник Группа полей «ВУЗ» • Выпускник нашего ВУЗа • Регион • Тип населенного пункта • Населенный пункт • Город • Полное наименование вуза Группа полей «Ученая степень» • Степень • Отрасль науки Группа полей «Место работы» • Место работы • Должность • Категория должности • Адрес • Является госслужащим • Категория ГГС • Стаж работы на госслужбе Группа полей «Выбор программы ДПО» • Институт, центр ДПО • Формат программы • Продолжительность программы • Программа • Специализация (для программ ВПО) Краткая процедура регистрации, применяемая для отдельных видов программ должна также запрашивать указанный выше набор полей за исключением группы полей «Информация о предыдущем образовании». Вместо набора полей данной группы, предусмотренного в полной процедуре, пользователь должен заполнить одно поле – «Уровень образования». Требования к типам данных и обязательности их указания поступающим

Наименование поля Тип данных

Обязательность, особенности заполнения

Персональные данные Фамилия Строковый Обязательно Имя Строковый Обязательно Отчество Строковый Обязательно Дата рождения Дата Обязательно

Пол Логический (Муж. / Жен.) Обязательно

Документ, удостоверяющий личность

Вид документа Выбор из справочника Обязательно

Гражданство Выбор из справочника Обязательно

Серия Строковый Необязательно Номер Строковый Обязательно Кем выдан Строковый Обязательно Дата выдачи Дата Обязательно Информация о месте постоянной регистрации

Почтовый индекс Числовой Необязательно

106

Регион проживания

Выбор из справочника Обязательно

Тип населенного пункта

Выбор из справочника Обязательно

Населенный пункт Строковый Обязательно Адрес регистрации Строковый Обязательно

Контактная информация Адрес фактического проживания Строковый Обязательно Домашний телефон Строковый Обязательно Рабочий телефон Строковый Обязательно Контактный телефон Строковый Обязательно E-mail Строковый Обязательно

Информация о предыдущем образовании

Уровень образования

Выбор из справочника

Обязательно (только в краткой процедуре регистрации)

Вид документа Выбор из справочника Обязательно

Наименование направления/специальности Строковый Обязательно Наименование степени/квалификации Строковый Обязательно Серия Строковый Необязательно Номер Строковый Обязательно Дата выдачи Дата Обязательно

С отличием Логический (Да / Нет) Обязательно

ВУЗ Выпускник нашего ВУЗа

Логический (Да / Нет) Обязательно

Регион Выбор из справочника

Обязательно (для «нашего» вуза заполняется автоматически)

Тип населенного пункта

Выбор из справочника

Обязательно (для «нашего» вуза заполняется автоматически)

Населенный пункт

Выбор из справочника

Обязательно (для «нашего» вуза заполняется автоматически)

Город Строковый

Обязательно (для «нашего» вуза заполняется автоматически)

Полное наименование Строковый

Обязательно (для «нашего» вуза заполняется

107

автоматически) Ученая степень

Степень Выбор из справочника Необязательно

Отрасль науки Выбор из справочника Необязательно Место работы

Место работы Строковый Обязательно Должность Строковый Обязательно Категория должности

Выбор из справочника Необязательно

Адрес организации Строковый Обязательно Является госслужащим

Логический (Да / Нет) Обязательно

Категория ГГС Выбор из справочника Необязательно

Стаж работы на госслужбе Числовой Необязательно

Выбор программы Институт, центр ДПО

Выбор из справочника Обязательно

Программа Выбор из справочника Обязательно

Специализация (для программ ВПО)

Выбор из справочника Необязательно

Формат программы

Выбор из справочника

Обязательно (подставляется автоматически для выбранной программы)

Продолжительность программы

Выбор из справочника

Обязательно (подставляется автоматически для выбранной программы)

Требования к этапности работы удаленного пользователя (получение логина, пароля, регистрация в качестве поступающего, подтверждение регистрации) Работа уделанного пользователя, желающего зарегистрироваться в качестве поступающего на одну из программ ДПО, должна состоять из следующих этапов: 1.Регистрация как пользователя web-ресурса (получение логина, пароля для доступа в личный кабинет). 2.Регистрация в качестве поступающего (заполнение формы регистрации). После получения логина и пароля удаленный пользователь должен ввести их в соответствующие поля на первой странице web-сервиса и перейти по ссылке «Войти в личный кабинет». 3.Изменение введенных при регистрации данных (в случае необходимости). 4.В случае возникновения сложностей при первичной регистрации, при входе в личный кабинет, пользователь должен иметь возможность направить модератору «анонимное сообщение». Ссылка, позволяющая направить такое сообщение, должна быть расположена на первой общедоступной странице сервиса. Ответ на

108

сообщение удаленный пользователь должен получать от модератора по электронной почте. 5.После входа в личный кабинет пользователь также должен иметь возможность написать сообщение модератору. Такое сообщение будет предоставлять модератору информацию о создавшем его пользователе системы. Ответ на сообщение удаленный пользователь должен получать от модератора по электронной почте. Требования к предварительной модерации данных, направленных удаленным пользователем Вся информация, формируемая удаленным пользователем, должна в обязательном порядке проходить модерацию. Модерация должна осуществляться пользователями институтов и центров ДПО, ответственными за работу с данными о поступающих. Модерация должна заключаться в рассмотрении «заявок» удаленных пользователей. Каждая заявка должна представлять собой запись базы данных системы с атрибутами, характерными для вида заявки. Атрибутами заявки должны быть значения полей, заполненных пользователем. Все поступившие заявки должны отображаться в отдельной форме работы с данными «Обслуживание удаленных пользователей». Форма должна содержать набор таблиц данных, отображающих как все поступившие заявки, так и отдельно заявки каждого вида. Заявки должны иметь атрибут «Статус заявки», принимающий одно из следующих значений: • Ожидает рассмотрения – заявка сформирована как результат действия удаленного пользователя, но еще не рассмотрена модератором; • Принята – модератором выполнено действие по принятию заявки, в системе успешно выполнены все операции над данными, предусмотренные процедурой принятия заявки данного вида (создана запись о поступающем на программу, произведено изменение данных о поступающем и т.п.) • Отклонена – модератор отклонил заявку; причина отклонения излагается в тексте письма, направляемом удаленному пользователю; • Отклонена автоматически – отклонение заявки выполнено системой автоматически (например, удаленный пользователь получил отказ в смене пароля); • Оставлена без рассмотрения – модератор принял решение о том, чтобы оставить заявку без рассмотрения; такой вариант действий может использоваться при направлении удаленным пользователем нескольких одинаковых заявок, неинформативных заявок. По каждой заявке пользователь-модератор должен видеть информацию, введенную пользователем при создании заявки, а также дополнительную информацию о данном пользователе, сформированную на основе существующих в системе данных (Рис. 7 Технического задания). По каждой заявке пользователь-модератор должен иметь возможность выполнить одно из действий: • Принять заявку • Отклонить заявку После принятия или отклонения у заявки должно измениться значение поля «Статус заявки». Это поле позволит пользователю-модератору отбирать для просмотра и отработки заявки, находящиеся в каждом из

109

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

110

использованию, модератор должен выполнить действие «Отклонить заявку». При этом обязательным для ввода модератором должен быть текст, объясняющий причину отклонения. После выполнения этого действия заявка должна перейти в статус «Отклонена». Никаких операций по изменению данных системы производиться при этом не должно. 3.3. В случае, если по заявке не нужно выполнять никаких действий над данными (например, изменения, о которых просит удаленный пользователь, уже выполнены в системе) модератор может выполнить над заявкой действие «Отметить как принятую». После выполнения этого действия заявка должна перейти в статус «Принята», однако никаких действий над данными системы выполняться не должно. 3.4. В случае, если модератор сочтет не нужным рассматривать заявку (например, заявка направлена повторно), он должен выполнить действие «Оставить без рассмотрения». В этом случае заявка должна изменить свой статус на «Оставлена без рассмотрения», никаких операций по обработке данных выполняться при этом не должно. Требования к общему числу участников регистрации и числу одновременно работающих пользователей Указанные ниже параметры быстродействия должны обеспечиваться системой при условии выполнения требований к серверным мощностям и системному программному обеспечению, описанных ниже в разделе «Требования к серверам БД и системному программному обеспечению, необходимым для обеспечения заданных параметров нагрузки и быстродействия». Подсистема удаленной регистрации поступающих на программы ДПО должна обеспечивать следующие параметры быстродействия: • Время отклика системы (любая операция, связанная с обращением клиента к веб-серверу) должна составлять не более 5 секунд. • Операция проверки регистрационных данных (входа пользователя в личный кабинет) – не более 10 секунд. При этом пользователю должно выдаваться соответствующее предупреждение, например, «Подождите, пожалуйста, идет проверка данных». Данные параметры быстродействия должны быть обеспечены при следующих значениях нагрузки: • общее число записей о поступающих на программы ДПО в течение одного учебного года – до 15 000; • среднесуточная нагрузка в период регистрации поступающих – до 500 зарегистрированных; • количество одновременных сессий удаленных пользователей – до 500; Количество одновременных сессий удаленных пользователей складывается из числа сессий пользователей - поступающих и из числа сессий пользователей – слушателей (студентов) программ ДПО, работающих с подсистемой личного кабинета студента (слушателя). В случае выделения для задачи регистрации поступающего отдельного web-сервера с характеристиками, описанными в п. 5, система должна обеспечить указанные параметры быстродействия при 500 одновременных сессий пользователей – поступающих.

111

Требования к экранным формам web-страниц, используемых при регистрации участников Экранные формы должны быть реализованы в соответствии с представленными макетами, представленными в Техническом задании. Требования к серверам БД и системному программному обеспечению, необходимым для обеспечения заданных параметров нагрузки и быстродействия Подсистема удаленной регистрации поступающих на программы ДПО должна быть развернута на серверах, предоставляемых Заказчиком. Сервера должны соответствовать следующим техническим требованиям и требованиям к программному обеспечению: Требования к серверу базы данных Подсистема должна работать на основе единой базы данных системы АСАВ. Работа всей системы должна быть обеспечена на сервере, удовлетворяющем требованиями. Требования к программному обеспечению:

СУБД Oracle 10.2.0.4 или выше; все вышедшие обновления для СУБД и ОС

Системные требования: 150 Гб дискового пространства; RAID 50(WriteBack); Оперативная память 3 Гб для 32-х битной ОС; 16 Гб

для 64-х битной ОС Процессоры 2 и более Intel Xeon 2 GHz 4 Core

Требования к web-серверу Работа всей системы должна быть обеспечена на сервере, удовлетворяющем требованиями. Требования к программному обеспечению:

ОС Windows 2003 server или выше (32 бит) Системные требования:

Процессор Intel Xeon 2 GHz 4 Core 10 Гб дискового пространства 3 Гб оперативной памяти

Подсистема также должна позволять разделять web-сервер с другими подсистемами системы АСАВ. В этом случае требуемые параметры быстродействия должны быть обеспечены при числе одновременных работающих пользователей (п. 2.3.), которое складывается из числа удаленных пользователей всех подсистем. Требования к рабочим местам удаленных пользователей Система должна обеспечивать необходимое быстродействие при использовании удаленными пользователями компьютеров, соответствующих следующим требованиям: Требования к программному обеспечению:

текущая версия одного из web-браузеров • InternetExplorer 8.0 или выше; • Firefox Mozilla 3.6 или выше; • Opera 11.0 или выше; • Chrome 11.0 или выше; • Safari 5.0 или выше

Поддержка Java script со стороны web-браузера Поддержка Cookies со стороны web-браузера

Системные требования: Оперативная память 512 МБ

112

50 МБ дискового пространства 1.2.2. Требования к сопровождению на этапе опытной эксплуатации. В ходе опытной эксплуатации исполнитель должен: • консультировать пользователей по вопросам использования функциональности системы; • фиксировать в специальной системе учета замечаний Заказчика: суть замечаний, дату возникновения замечаний, дату устранения. Длительность этапа опытной эксплуатации не менее двух недель. Сроки проведения опытной эксплуатации должны быть предварительно согласованы с Заказчиком. 1.3. Реализация функциональности Личного кабинета слушателя программ дополнительного профессионального образования (ДПО). Требования к составу: № п.п.

Состав Форма результата

1 Доработка функциональности системы АСАВ.

Доработанная функциональность установлена в рабочую конфигурацию Системы.

2 Разработка документации: -инструкции удаленных пользователей; - инструкция модераторов участка ДПО;

Доработанная документация согласованна с исполнителем.

3 Проведение предварительных испытаний и нагрузочного тестирования.

Согласованный акт готовности к опытной эксплуатации

4 Сопровождение на этапе опытной эксплуатации.

Журнал замечаний по эксплуатации.

5 Проведение испытаний Согласованный акт готовности к промышленной эксплуатации

1.3.1. Требования к доработке функциональности. Разрабатываемая в рамках настоящего технического задания новая функциональность системы АСАВ предназначена для организации взаимодействия пользователей системы, являющихся работниками институтов и центров дополнительного профессионального образования (ДПО) или работниками Управления дополнительного образования (пользователи участка «Дополнительное образование»), с лицами, являющимися студентами и слушателями программ ДПО. Создаваемая подсистема должна позволить удаленному пользователю (студенту или слушателю) получить учетную запись в системе, после чего получить доступ к своему Личному кабинету – системе web-страниц,

113

позволяющих слушателю работать со своими личными данными, информацией о ходе обучения, получать информацию о событиях, происходящих в ходе его обучения. После регистрации поступающий должен иметь возможность корректировать введенные им личные данные, информацию об образовании, и проч. Все действия удаленного пользователя в личном кабинете должны осуществляться на основе заявок – специальных записей базы данных, содержащих введенную удаленным пользователем информацию, предназначенную для предварительного просмотра модератором с последующим «приемом» (применением сделанных изменений) или отклонением. Пользователи участка «Дополнительное образование» должны получить доступ к информации обо всех заявках удаленных пользователей, поданных на программы институтов и центров ДПО, возможность предварительного рассмотрения, принятия или отклонения заявок, обмен с удаленными пользователями дополнительной информацией. Перечень автоматизируемых задач В рамках разрабатываемой подсистемы автоматизации подлежат следующие задачи: 1) Регистрация в системе АСАВ удаленного пользователя являющегося студентом или слушателем программы ДПО. 2) Создание и отправка удаленным пользователем заявки на изменение его личных данных, контактной информации, информации о предыдущем образовании, месте работы и проч. 3) Рассмотрение поступивших заявок пользователями – модераторами от подразделений ДПО; прием или отклонение заявок; возможность корректировки данных, введенных удаленным пользователем. 4) Корректировка и актуализация данных системы на основе заявок удаленных пользователей. 5) Предоставление удаленному пользователю информации о его индивидуальном учебном плане и ходе его выполнения. 6) Информирование удаленного пользователя о происходящих событиях с его учетной записью (выставление оценок за испытания, перевод с одной программы не другую, отчисление, выпуск и проч.) 7) Обмен сообщениями системы и письмами электронной почты между удаленными пользователями (студентами и слушателями) и пользователями системы АСАВ, отвечающими работу с контингентом слушателей ДПО. Требования к атрибутивному составу информации, доступной студенту (слушателю) в личном кабинете Для просмотра студентом (слушателем) программы ДПО должна быть доступна вся информация о его личных данных, контактных данных и ходе обучения, собираемая и обрабатываемая системой АСАВ. Группа атрибутов «Личные и контактные данные» • Фамилия • Имя • Отчество • Дата рождения • Адрес электронной почты • Контактный телефон

114

• Домашний телефон • Рабочий телефон Группа атрибутов «Программа» • Номер студенческого билета (только для студентов программ ВПО) • Программа ДПО • Подразделение ДПО • Направление подготовки • Направление/специальность ВПО • Специализация (для программ ВПО) • Продолжительность обучения • Формат программы • Вид документа об образовании • Новая профессиональная область в РП (для программ переподготовки) • Новая квалификация (для программ переподготовки) Группа атрибутов «Предыдущее образование» • Уровень предыдущего образования • Документ о предыдущем образовании • Вид документа • Номер документа • Дата документа • Серия документа • Сдан подлинник • ВУЗ • Диплом с отличием • Предыдущее направление/специальность • Предыдущая степень/квалификация Группа атрибутов «Условия обучения» • Группа слушателей • Дата начала обучения • Дата окончания обучения • Форма обучения • Стоимость обучения слушателя • Всего часов по учебному плану • Число лет обучения Группа атрибутов «Место работы» • Текущее место работы • Дата начала работы • Дата окончания работы • Место работы • Должность • Категория должности • Адрес места работы • Является госслужащим • Категория государственной гражданской службы • Стаж работы на госслужбе Группа атрибутов «Ученая степень» • Ученая степень • Отрасль науки Группа атрибутов «Зачисление» • Номер приказа • Дата приказа Группа атрибутов «Итоговая аттестация» • Номер приказа о допуске к итоговым госэкзаменам • Дата приказа о допуске к итоговым госэкзаменам • Номер приказа о допуске к ВКР • Дата приказа о допуске к ВКР • Дата утверждения темы ВКР

115

• Номер приказа об утверждении тем ВКР • Дата приказа об утверждении тем ВКР • Номер приказа о допуске к государственной аттестации • Дата приказа о допуске к государственной аттестации Группа атрибутов «Документ о полученном образовании» • Вид документа • Номер документа • Дата документа • Серия документа • Диплом с отличием • Степень/квалификация • Дата протокола ГАК • Номер протокола ГАК • Регистрационный номер Наряду с информацией о студенте (слушателе) и его статусе обучения по программе, ему должна быть доступна для просмотра информация о его индивидуальном учебном плане и ходе его выполнения. Эта информация должна иметь следующий атрибутивный состав: • Наименование дисциплины в учебном плане • Число аудиторных часов • Общее число часов • Дата сдачи испытания • Вид испытания (экзамен, зачет) • Оценка по 10-балльной шкале • Оценка по 5-балльной шкале • Оценка зачет/незачет • Неявка • Число недель (для курсовых работ, ВКР) • Тема работы • ВУЗ, в котором сдано испытание (в предложном падеже) – для случая перезачета испытаний, сданных в других вузах • Номер ведомости Требования к составу учетных данных студента (слушателя), доступных для изменения самим слушателем Среди всех данных, доступных студенту (слушателю) программы ДПО для просмотра должна быть выделена категория данных, доступных для изменения самим слушателем. Любые изменения данных, выполняемые слушателем, должны в обязательном порядке проходить процедуру модерации пользователем системы АСАВ, отвечающим за работу с данными о контингенте слушателей ДПО. Изменению самим студентом (слушателем) подлежать следующие данные: Группа атрибутов «Личные и контактные данные» • Фамилия • Имя • Отчество • Дата рождения • Адрес электронной почты • Контактный телефон • Домашний телефон • Рабочий телефон

116

Группа атрибутов «Предыдущее образование» • Уровень предыдущего образования • Документ о предыдущем образовании • Вид документа • Номер документа • Дата документа • Серия документа • Сдан подлинник • ВУЗ • Диплом с отличием • Предыдущее направление/специальность • Предыдущая степень/квалификация Группа атрибутов «Место работы» • Текущее место работы • Дата начала работы • Дата окончания работы • Место работы • Должность • Категория должности • Адрес места работы • Является госслужащим • Категория государственной гражданской службы • Стаж работы на госслужбе Группа атрибутов «Ученая степень» • Ученая степень • Отрасль науки При изменении слушателем какой-либо из групп атрибутов в системе должна формироваться заявка на изменение данных определенного вида. В период с момента рассмотрения заявки до ее рассмотрения модератором повторное изменение данных этой группы должно быть невозможным. При приеме или отклонении заявки модератором удаленный пользователь должен получать подтверждающее письмо по электронной почте. Сценарии работы пользователя по выполнению автоматизируемых задач. Работа удаленного пользователя, являющегося студентом или слушателем программы дополнительного профессионального должны состоять из следующих этапов работы: 1) Регистрация в качестве пользователя web-ресурса (получение логина, пароля для доступа в личный кабинет) на общедоступной странице сервиса (Рис. 4 Технического задания). 2) Работа в личном кабинете (просмотр и уточнение своих учетных данных, получение информации о ходе обучения). 3) Обмен сообщениями с работниками, администрирующими программу ДПО. Работа модератора должна заключаться в рассмотрении поступивших от удаленных пользователей заявок, их принятии или отклонении. Модератор должен действовать по следующему сценарию: 1) В форме «Обслуживание удаленных пользователей» отобрать заявки, находящиеся в статусе «Ожидает рассмотрения». 2) По каждой из заявок просмотреть введенную удаленным пользователем информацию.

117

3) В случае, если введенная информация признана модератором приемлемой, выполнить действие «Принять заявку». Если информация признана неприемлемой, выполнить действие «Отклонить заявку» с указанием причины отклонения. В отдельных случаях модератор может также выполнить действия «Отметить как принятую» или «Оставить без рассмотрения». Требования к предварительной модерации данных, направленных удаленным пользователем Требования по модерации данных аналогичны требованиям, описанным выше в разделе 1.2. Требования к общему числу слушателей, получающих возможность использования личного кабинета и числу одновременно работающих пользователей Требования аналогичны описанным выше в п. 1.2. Требования к экранным формам веб-страниц личного кабинета Экранные формы должны быть реализованы в соответствии с представленными макетами в Техническом задании. Требования к техническому обеспечению, прикладному и системному программному обеспечению: Требования к серверу базы данных, web-серверам, рабочим местам удаленных пользователей аналогичны требованиям, представленным выше в п. 1.2. 1.3.2. Требования к документированию. В рамках работ по данной задаче должны быть разработаны: - руководство пользователя Личного кабинета в формате html-документа, доступное с первой страницы сервиса (до прохождения авторизации); - руководство модератора как часть существующей справочной системы АСАВ. 1.3.3. Требования к сопровождению на этапе опытной эксплуатации. В ходе опытной эксплуатации исполнитель должен: • консультировать пользователей по вопросам использования функциональности системы; • фиксировать в специальной системе учета замечаний Заказчика: суть замечаний, дату возникновения замечаний, дату устранения. Длительность этапа опытной эксплуатации не менее двух недель. Сроки проведения опытной эксплуатации должны быть предварительно согласованы с Заказчиком. 1.4. Реализация функциональности участка системы «Дополнительное образование» на подготовительном отделении для поступающих в магистратуру. Требования к составу услуг: № п.п.

Состав Форма результата

1 Сбор информации о необходимых

Перечень доработок участка ДПО для

118

доработках учета слушателей ПО в магистратуру.

2 Выполнение доработок участка ДПО

Доработанная функциональность установлена в рабочую конфигурацию системы.

3 Обучение пользователей ПО в магистратуру

Перечень пользователей, прошедших обучение.

4 Поддержка процесса первичного наполнения справочных данных, регистрации поступающих 2011 года, зачисления поступающих

В системе сформированы справочные данные по программам ПО в магистратуру, зарегистрированы поступающие, поступающие зачислены в состав слушателей.

5 Доработка руководства пользователя участка ДПО

Доработанная документация согласованна с исполнителем.

6 Сопровождение на этапе опытной эксплуатации.

Журнал замечаний по эксплуатации.

7 Проведение испытаний Согласованный акт готовности к промышленной эксплуатации

1.4.1. Требования к доработкам функциональности В ходе работы должна быть выявлена необходимость в доработках участка ДПО, обусловленная рядом отличий программ подготовки на Подготовительном отделении в магистратуру от других программ дополнительного профессионального образования: - реализация программ на бюджетной основе; - особенности учебных планов по программам ПО в магистратуру; - необходимость связи с участком «Абитуриент» в части функциональности проведения олимпиады студентов и проведения приемной кампании в магистратуру Перечень доработок должен быть реализован и установлен в рабочие конфигурации системы в Москве и филиалах. 1.4.2. Требования к консультационному сопровождению внедрения Исполнитель должен обеспечить консультационное сопровождение работы пользователей Подготовительного отделения на всех этапах работы: - Формирование справочных данных по программам ПО в магистратуру - Занесение учебных планов ПО в магистратуру на 2011/2012 учебный год - Регистрация поступающих 2011 года; - Отражение результатов входного тестирования поступающих; - Зачисление поступающих в состав слушателей; - Назначение слушателям обязательной и вариативной

119

частей учебных планов - Формирование ведомостей на сдачу испытаний - Занесение результатов испытаний - Выполнение действий по перемещению слушателей (переводы, отчисление и т.д.); - Формирование и учет документов о полученном образовании; - Выпуск слушателей На всех этапах работы Исполнителем должен вестись сбор и фиксация в Журнале выявленных ошибок, необходимости доработок, пожеланий по развитию функциональности. Доработки, необходимость которых будет выявлена, должны быть выполнены Исполнителем в рамках внедрения. 1.4.3. Требования к документированию Выполненные доработки функциональности, необходимые для организации учета слушателей Подготовительного отделения в магистратуру, должны быть описаны в Руководстве пользователя участка «Дополнительное образование», входящем в состав единой справочной системы по системе АСАВ. 1.4.4. Требования к сопровождению на этапе опытной эксплуатации. В ходе опытной эксплуатации исполнитель должен: • консультировать пользователей по вопросам использования функциональности системы; • фиксировать в специальной системе учета замечаний Заказчика: суть замечаний, дату возникновения замечаний, дату устранения. Длительность этапа опытной эксплуатации не менее двух недель. Сроки проведения опытной эксплуатации должны быть предварительно согласованы с Заказчиком. 1.5. Реализация функциональности участка «Аспирант» в целях учета аспирантов, обучающихся по программам академической аспирантуры. Требования к составу услуг: № п.п.

Состав Форма результата

1 Выполнение доработок участка «Аспирантура»

Доработанная функциональность установлена в рабочую конфигурацию системы.

2 Доработка руководства пользователя участка «Аспирантура»

Доработанная документация согласованна с исполнителем.

3 Сопровождение на этапе опытной эксплуатации.

Журнал замечаний по эксплуатации.

4 Проведение испытаний Согласованный акт готовности к промышленной эксплуатации

1.5.1. Требования к доработкам функциональности

120

В связи с выделением из числа аспирантов очной формы обучения категории аспирантов, обучающихся по программам академической аспирантуры, на участке «Аспирант» системы АСАВ должны быть выполнены следующие доработки функциональности: 1) Выделение аспирантов, обучающихся по программам академической аспирантуры, в отдельную категорию. 2) Реализация возможности отдельного планирования контрольных этапов обучения для программ академической аспирантуры. 3) Реализация возможности назначения академическим аспирантам со-руководителей - представителей зарубежных вузов. 4) Реализация функциональности формирования и назначения академическим аспирантам учебных планов. 5) Разработка функциональности учета успеваемости аспирантов по дисциплинам учебных планов. 6) Отображение назначенных учебных дисциплин и полученных по ним оценок в Личных кабинетах аспирантов. Возможность отдельного планирования контрольных этапов для академических аспирантов должна позволить в обязательном порядке назначать им стажировки в зарубежных университетах и другие виды работ, не обязательные для аспирантов очной формы обучения. Учебные планы аспирантуры должны формироваться по каждой из научных специальностей на определенный учебный год. Записи о дисциплинах, входящие в состав учебных планов должны иметь следующий атрибутивный состав: • Дисциплина (ссылка на дисциплину из общевузовского справочника дисциплин); • Кафедра / Факультет / Научное подразделение, читающее дисциплину; • Признак Обязательная / По выбору • Общее число часов • Число аудиторных часов • Число кредитов Для назначения учебных планов аспирантам должна быть разработана процедура «Назначить учебный план». Данная процедура должна выполнять назначение аспиранту обязательной части учебного плана. Также должна быть разработана процедура «Назначить дисциплину плана», при помощи которой должно быть возможным назначить выбранному аспиранту одну из необязательных дисциплин плана. Функциональность создания учебных планов и их назначения аспирантам должна быть доступна для всех категорий аспирантов. Успеваемость аспирантов по дисциплинам плана должна заноситься в систему в 5-ти балльной шкале. 1.5.2. Требования к сопровождению на этапе опытной эксплуатации. В ходе опытной эксплуатации исполнитель должен: • консультировать пользователей по вопросам использования функциональности системы; • фиксировать в специальной системе учета замечаний Заказчика: суть замечаний, дату возникновения замечаний, дату устранения. Длительность этапа опытной эксплуатации не менее двух

121

недель. Сроки проведения опытной эксплуатации должны быть предварительно согласованы с Заказчиком. 1.6. Реализация функциональности интеграции системы АСАВ с Системой контроля и управления доступом (СКУД) в части передачи в систему АСАВ фотографий студентов и преподавателей. Общее назначение функциональности Разрабатываемая функциональность предназначена для автоматизации загрузки фотографий учащихся и работников НИУ ВШЭ, присутствующих в базе данных системы контроля доступа (СКУД), в систему АСАВ. Автоматизированная загрузка фотографий должна осуществляться только для тех учащихся и работников, для которых и на стороне БД СКУД, и на стороне БД АСАВ существует единственная запись с сочетанием значений фамилии, имени и отчества. Для учащихся, по которым в БД СКУД или в БД АСАВ существует более одной записи с одинаковым сочетанием фамилии, имени и отчества, загрузка фотографии должна осуществлять индивидуально уполномоченным на выполнение этой процедуры пользователем. Перечень автоматизируемых задач Разрабатываемая функциональность предназначена для автоматизации следующих задач: 1. Автоматизированная загрузка фотографий для всех студентов и работников или для выбранного списка должна производиться по алгоритму, описанному ниже. По результатам автоматизированной загрузки фотографий должен формироваться протокол загрузки, в котором должно быть указано: – количество фотографий, успешно загруженных по однозначной идентификации; – список ФИО из системы СКУД, которые не соответствуют однозначной идентификации; – список ФИО из ИС АСАВ, которые не соответствуют однозначной идентификации. 2. Предоставление интерфейса для ручного выбора и загрузки фотографии для тех людей, у которых возникла неоднозначность при синхронизации. 3. Формирование отчетов для определения перечня учащихся и работников, у которых отсутствуют персональные фотографии. Требования к источнику данных (используемая СУБД, ее таблицы и представления, атрибутивный состав доступных данных) Для выполнения процедур автоматизированной загрузки фотографий должна быть обеспечена возможность подключения к базе данных, находящейся под управлением СУБД MS SQL Server. Параметры подключения к СУБД (имя или адрес базы данных, логин и пароль пользователя) должны храниться в текстовом файле, который в свою очередь должен быть загружен в БД системы АСАВ в разделе «Доступные файлы». Доступ к файлу, содержащему параметры подключения к БД с фотографиями, должен быть только у пользователей – администраторов системы АСАВ. При этом возможность подключения к БД и получения фотографий должна быть предоставлена, в том числе, и другим категориям пользователей системы АСАВ.

122

В СУБД, содержащей фотографии, должна существовать таблица с именем «person», в которую регулярно должны загружаться фотографии из системы СКУД. Таблица «person», должна иметь следующую структуру: Наименование Описание pers_id Уникальный идентификатор

человека first_name Имя middle_name Отчество last_name Фамилия photo Фотография

Для успешной идентификации человека необходимо, чтобы поля first_name, middle_name и last_name были обязательно заполнены. Сценарии работы пользователя по выполнению автоматизируемых задач. Автоматизированная загрузка фотографий для всех студентов и работников вуза должна осуществляться пользователем системы АСАВ, имеющим права администратора или бизнес-администратора. Пользователям этих категорий доступна для работы форма работы с данными «Служебная форма», в которой можно осуществлять работу со всеми существующими в системе АСАВ людьми, учащимися, работниками вуза. Действия для вызова процедур загрузки фотографий должны быть доступны в каждом из представлений «Все учащиеся», «Все работники», «Все люди». Загрузка фотографий студентов одного из факультетов должна быть доступна пользователям ролей «Учебная часть факультета». Также пользователям учебных частей должна быть доступна процедура индивидуального загрузки фотографии для одного или нескольких выбранных студентов. Работа пользователей по загрузке фотографий должна осуществляться по следующему сценарию: 1) Пользователь, имеющий права администратора системы, должен занести параметры подключения к базе данных с фотографиями в текстовый файл и загрузить этот файл в систему на вкладке «Доступные файлы» Системной формы. 2) Пользователь, имеющий права администратора, должен вызвать действие «Загрузить фотографии для всех людей». Параметры подключения к БД СКУД должны быть получены системой из текстового файла из таблицы «Доступные файлы». После подключения к базе данных должен быть начат процесс загрузки. Ход процесса должен отражаться путем отображения окна «прогресса», показывающего процент выполнения загрузки во времени. 3) Пользователь, входящий в роль «Учебная часть факультета» в доступном ему разделе «Студенты - личные данные» должен иметь возможность просмотра фактов наличия или отсутствия в системе АСАВ фотографий студентов своего факультета. По каждому студенту пользователь учебной части должен иметь возможность просмотреть фотографию. 4) Для студентов факультета, у которых нет фотографий, пользователь учебной части должен иметь возможность вызвать действие «Загрузить фотографии для выделенных

123

людей». При выполнении этого действия должно быть установлено соединение с базой данных фотографий (параметры подсоединения должны быть получены из файла, сформированного администратором), для выбора пользователю должна быть предложена таблица с ФИО людей из БД СКУД и фотографиями. Пользователь должен иметь возможность выбрать нужную фотографию и загрузить ее в БД АСАВ для выбранного студента. 5) По результатам загрузки пользователь должен оценить количество учащихся или работников, для которых фотографии остались незагруженными. Сделать это он может путем изучения полученного протокола загрузки, а также путем формирования отчетов: • Список студентов без фотографий; • Список работников без фотографий. Пользователь учебной части должен получить отчет только по студентам своего факультета. Пользователь-администратор должен иметь возможность получить отчет как по любому из факультетов, так и по всем студентам. 6) Для учащихся или работников, для которых фотографии не были загружены по причине неоднозначной идентификации на стороне системы СКУД, пользователь (администратор или пользователь учебной части) должен выполнить действие «Загрузить фотографии для выделенных людей». При выполнении этого действия должно быть установлено подключение к БД СКУД, после чего пользователю должен быть показан перечень фотографий, найденных в БД СКУД по строгому соответствию полей Фамилия, Имя и Отчество. Пользователь сможет выбрать нужную фотографию и выполнить загрузку. Этап 6 должен быть повторен пользователем для всех неоднозначно идентифицированных людей. Требования к алгоритмам автоматизированной загрузки фотографий Сопоставление людей из ИС АСАВ и из системы учета пропусков должна производиться по полям «Фамилия», «Имя» и «Отчество» по следующему алгоритму: 1.Из базы данных, содержащей фотографии, необходимо выбрать записи, у которых сочетание полей, по которым производится идентификация, является уникальным в системе СКУД; 2.Из ИС АСАВ отобрать всех людей, которые имеют категорию учащийся или работник ВУЗа, и сочетание полей, по которым производится идентификация, является уникальным в ИС АСАВ. 3.Осуществить сопоставление записей отобранных на предыдущих этапах. 4.Из полученного в результате списка загрузить фотографии в ИС АСАВ. Требования к процедуре первичной загрузки фотографий студентов, аспирантов, преподавателей В разрабатываемом модуле необходимо предусмотреть функцию загрузки всех фотографий, удовлетворяющих критерию однозначной идентификации, в целях первичного автоматизированного заполнения фотографиями студентов и работников поля «Фото» в ИС АСАВ. Требования к процедуре обновления ранее загруженных фотографий

124

В разрабатываемом модуле необходимо так же предусмотреть не только полную синхронизацию, а также и синхронизацию по выбранному списку студентов или работников. При синхронизации записей ИС АСАВ уже имеющих фотографию необходимо обеспечить, чтобы имеющиеся фотографии были в актуальном состоянии по отношению к базе данных СКУД. Для этого можно определять факт наличия новой версии в базе данных СКУД тем или иным путем, либо всегда перезаписывать имеющиеся фотографии данными из промежуточной базы. Требования к регламенту работы по синхронизации данных между системами Предполагается, что база данных, содержащая фотографии, системы учета пропусков будет предоставлена, и находиться в актуальном состоянии, которое должно обеспечиться за счет регулярной синхронизации с первоисточником. Периодичность выполнения полной или частичной загрузки фотографий должна определяться действующим регламентом, принятым в университете. Разрабатываемая функциональность системы АСАВ должна позволять выполнять автоматизированную загрузку фотографий для тех студентов и работников, у которых в БД АСАВ нет фотографий, по задаваемому администратором расписанию. Требования к составу функций модуля интеграции В состав функций разрабатываемого модуля необходимо включить следующие пункты: – загрузка и обновление фотографий для всех студентов и работников, вызываемая пользователем; - автоматическая загрузка фотографий для всех студентов и работников, не имеющих фотографий в БД АСАВ по расписанию; – загрузка и обновление фотографий для выбранного списка студентов и работников; – предоставление интерфейса для ручного выбора фотографии из списка для тех людей, у которых возникла неоднозначность при синхронизации; – формирование отчета, содержащего список учащихся, у которых отсутствуют фотографии; – формирование отчета, содержащего список работников, у которых отсутствуют фотографии. Требования к формату и составу отчетности по наличию в системе АСАВ фото студентов, аспирантов, преподавателей в разрезе факультетов, групп, кафедр По результатам загрузки в систему АСАВ фотографий пользователь должен иметь возможность сформировать следующие отчеты: 1. Список студентов без фотографий Отчет должен находить и выгружать в файл MS Excel список студентов, у которых отсутствуют фотографии, с возможностью задания критериев отбора по факультету, курсу и группе. Список студентов должен содержать следующие данные: Фамилия, Имя, Отчество, Дата рождения, Пол, Факультет, Курс, Группа. 2. Список работников без фотографий Данный отчет не должен запрашивать у пользователя параметры отбора. Результатом работы отчета должен быть файл MS Excel, содержащий список все работников,

125

у которых в БД АСАВ отсутствует фотография. 1.7. Развитие функциональности интеграции системы АСАВ с сервисом Microsoft LiveEdu. Общее назначение функциональности Разрабатываемый функционал предназначен для автоматизации функций управления учетными записями сервиса LiveEdu в рамках интеграции с ИС АСАВ. Под управлением учетными записями подразумевается создание и привязывание почтовых адресов системы LiveEdu к студентам ИС АСАВ и синхронизация необходимых атрибутов. Сформированные для студентов адреса электронной почты в системе LiveEdu могут использоваться для автоматизированной рассылки почтовых сообщений студентам НИУ ВШЭ пользователями системы АСАВ. В 2010 году была разработана пилотная версия функциональности, решающая задачи автоматического формирования учетных записей студентов в системе LiveEdu и управления этими учетными записями. По итогам использования пилотной версии функциональности возникла необходимость в изменении алгоритмов работы ряда процедура, расширении атрибутивного состава информации, задействованной в интеграции, предоставление доступа к функциональности новым категориям пользователей. Перечень автоматизируемых задач Уточнению и дополнительной разработке подлежат следующие задачи: 1.Модификация алгоритмов генерации логина и пароля при создании учетной записи студента. 2.Предоставление возможности создания и синхронизации учетных записей пользователям учебных частей факультетов и отделений. 3.Доработка процедуры отправки почтового сообщения студенту, формирования имени файла приложения. 4.Автоматизация создания адресов учебных групп. 5.Автоматизация заполнения дополнительных атрибутов учетной записи в LiveEdu на основе данных системы АСАВ. 6.Ограничение возможностей студента по изменению данных своего профиля в LiveEdu. 7.Защита информации об адресе электронной почты в LiveEdu в системе АСАВ от случайного изменения и удаления. Требования к атрибутивному составу информации, передаваемой в сервис LiveEdu из системы АСАВ Для создания и других операций с почтовой учетной записью студента в системе LiveEdu должны использоваться существующие атрибуты записи о студенте. Добавления новых атрибутов записей о студентах не требуется. Для успешного выполнения операций создания и управления учетной записью студента в АСАВ обязательно должны быть заданы значения ее следующих атрибутов: − Фамилия − Имя − Отчество − Номер студенческого билета − Филиал (на стороне LiveEdu соответствует атрибуту «Город») − Факультет

126

− Курс − Направление / специальность подготовки − Учебная группа Значение атрибута «Краткое имя» учетной записи LiveEdu должно формироваться путем слияния фамилии, имени и отчества (при наличии) и быть недоступным для самостоятельного изменения студентом. Сценарии работы пользователя по выполнению автоматизируемых задач. Задачи, связанные с созданием, удалением, блокировкой, разблокировкой, изменением атрибутов или восстановлением пароля должны быть доступны в специализированной экранной форме со списком студентов, с учетными записями которых может быть выполнены вышеуказанные операции. Для выполнения требуемой операции пользователь может выбрать список студентов, и в контекстном меню выбрать необходимую ему операцию. Далее, перед выполнением, процедура может запросить параметры, необходимые для выполнения. По результатам выполнения операции должен быть выдан краткий отчет о результатах выполнения (количество созданных, измененных записей, наличие ошибок). Пользователям, входящим в роль администраторов системы АСАВ дополнительно должен быть доступен для просмотра Журнал операций. Требования к алгоритмам автоматизированного формирования учетных данных (логин, пароль) студента для сервиса LiveEdu В существующем варианте функциональности логин учетной записи системы LiveEdu, формируется в транслитерированном виде по правилу: [первая буква имени] + [первая буква отчества] + [фамилия] + @edu.hse.ru. Если сформированное имя учетной записи уже занято, то система должна попытаться создавать другое имя учетной записи, формируемое на основе изначального, путем добавления к нему номера попытки через символ «_», до тех пор, пока почтовый ящик не будет создан или не произойдет иная ошибка. В новой версии данной функции необходимо модифицировать данный алгоритм, добавив игнорирование всех встречающихся в фамилии, имени или отчестве пробелов (в начале, в конце, в середине слова), а также других небуквенных символов. В существующем варианте функциональности пароль для первой авторизации в созданной учетной записи устанавливается в соответствии с номером студенческого билета выбранного студента. В новой версии данной процедуры при формировании пароля должны использоваться только цифры, входящие в номер студенческого билета. Все нецифровые символы должны игнорироваться. Предоставление возможности создания и синхронизации учетных записей пользователям учебных частей факультетов и отделений Для решения данной задачи необходимо реализовать следующие дополнительные возможности: - хранение логина и пароля администратора сервиса LiveEdu в текстовом файле, загружаемом в БД АСАВ в таблице «Доступные файлы»; доступ к загрузке, просмотру и изменению этого текстового файла в АСАВ должны иметь только пользователи АСАВ, входящие в

127

роль «Администраторы»; - реализация возможности обращения к ПО PowerShell, (с помощью которого обеспечивается взаимодействие с установленному сервисом LiveEdu) установленному на сервере приложений системы АСАВ (asav.hse.ru). Необходимость установки ПО PowerShell на рабочем месте пользователя АСАВ должна быть исключена. Реализация данных дополнительных возможностей должна позволить пользователю учебной части факультета вызывать функции управления учетными записями сервиса LiveEdu не зная логин и пароль администратора и без установки на своем рабочем месте дополнительного программного обеспечения. Доработка процедуры отправки почтового сообщения студенту, формирования имени файла приложения В существующей версии функциональности была реализована возможность отправки письма только с использованием одного из существующих шаблонов почтовых сообщений. В новой версии в процедуру отправки почтового сообщения необходимо внести следующие изменения: - добавить возможность ввода произвольного текста сообщения (длина текста сообщения до 2000 символов); - при выборе прилагаемого файла отображать в форме создания сообщения полный путь к файлу; - в дополнительном поле формы рядом с именем файла отображать размер приложенного файла. Автоматизация создания адресов учебных групп Дополнительно к реализованным на пилотном этапе функциям создания и синхронизации учетных записей необходимо разработать функцию создания и синхронизации учетной записи группы. В качестве имени учетной записи группы должно использоваться значение атрибута «Имя» справочника АСАВ «Структура факультета», состоящее из года набора и неизменяемой части наименования группы. В группу должны быть включены учетные записи всех студентов, принадлежащих группе. Процедура синхронизации информации о группе должна заключаться в уточнение списка учетных записей студентов, входящих в группу на момент синхронизации. Автоматизация заполнения дополнительных атрибутов учетной записи в LiveEdu на основе данных системы АСАВ Процедуры создания и синхронизации учетных записей, разработанные на пилотном этапе, должны быть дополнены возможностями использования дополнительных атрибутов учетных записей LiveEdu. В качестве значений дополнительных атрибутов при создании и синхронизации учетных записей, должны использоваться значения следующих атрибутов записи о студенте в системе АСАВ: • Факультет • Курс • Направление / специальность подготовки • Учебная группа Ограничение возможностей студента по изменению данных своего профиля LiveEdu Студент как пользователь системы LiveEdu не должен иметь возможность редактировать информацию в своем профиле, которая синхронизируется с системой АСАВ. Дополнительно должна быть реализована возможность

128

обязательного запроса на изменение пароля при первой авторизации студента в системе LiveEdu. Защита информации об адресе электронной почты в системе АСАВ от случайного изменения и удаления. В целях предотвращения случайного изменения или удаления информации об электронном адресе LiveEdu как одной из записей таблицы «Контактная информация», доступной пользователям учебных частей, необходимо при создании записей данного вида устанавливать значения поля «Роль для записи», равного роли «Администраторы» и позволить предоставить доступ к этой информации на изменение только администраторам системы. Пользователи других категорий должны иметь возможность создавать такие записи только с использованием процедур взаимодействия с LiveEdu. Изменение и удаление электронного адреса студента в системе для этих пользователь будет недоступно. Требования к механизмам и алгоритмам синхронизации информации о студенте, хранящейся в системе АСАВ и в профиле пользователя LiveEdu Выполнение операции синхронизации должно быть возможным для тех студентов, у которых есть созданная и ассоциированная с ними учетная запись в системе LiveEdu. Синхронизации подлежат следующие атрибуты студента: − Фамилия, имя и отчество; − Город обучения (филиал) − Факультет − Курс − Направление / специальность подготовки − Учебная группа Синхронизация первых двух атрибутов реализована в пилотной версии функциональности. В рамках новой разработки должна быть реализована синхронизация дополнительных 4-х атрибутов. Все записи студентов должны иметь признак синхронизации с LiveEdu, который будет указывать на состояние синхронизации учетной записи. Требования к механизмам и алгоритмам синхронизации информации о преподавателе, хранящейся в системе АСАВ и в профиле пользователя LiveEdu В рамках задач по развитию функциональности интеграции, описанных в данном Техническом задании считать нецелесообразным разработку механизма создания и синхронизации учетных данных преподавателей, между системами АСАВ и LiveEdu. Требования к механизмам синхронизации прав студента на использование сервиса LiveEdu с изменениями статуса студента в системе АСАВ (отчисление, перевод с одного факультета на другой, выпуск и т.д.) При выполнении пользователями участка «Студент» процедур по перемещениям студентов (отчисление, восстановление, переводы, предоставление академического отпуска и проч.) в системе формируются записи о событиях перемещений. Записи о событиях имеют атрибуты студента, по которому произошло событие, даты события, вида события и приказа на основании которого произошло событие. Пользователь, наделенный правами администратора системы LiveEdu, должен иметь доступ к таблицам

129

данных, отображающим события по перемещению студентов. В соответствии с действующим в университете регламентом работы с учетными записями LiveEdu администратор должен иметь возможность вызвать для студента, по которому произошло событие, одной из процедур синхронизации с LiveEdu (создание, блокирование, удаление учетной записи). 1.8. Реализация функциональности интеграции системы АСАВ с корпоративным порталом НИУ ВШЭ в части публикации на портале утвержденных рабочих учебных планов. Реализуемый функционал предназначен для организации доступа к данным об учебных планах, формируемых и актуализируемых в системе АСАВ, для посетителей портала НИУ ВШЭ http://www.hse.ru/. Данные об утвержденных рабочих учебных планах (РУП) факультетов и отделений должны быть доступны посредством web-страницы, генерируемой системой АСАВ. Информация об учебных планах должна быть доступна всем посетителям портала без прохождения авторизации. Перечень автоматизируемых задач Разрабатываемая функциональность должна автоматизировать задачу публикации на корпоративном портале утвержденных рабочих учебных планов. Задача должна быть решена путем создания механизма генерации и предоставления web-страниц, отображающих структурированный в табличном виде перечень утвержденных рабочих учебных планов (РУП) факультетов и отделений университета. Просмотреть каждый учебный план должно быть возможно при переходе по ссылке в колке «Наименование плана». РУП должен предоставляться для просмотра и сохранения в виде файла рабочей книги MS Excel. Требования к механизмам передачи данных, формату и структуре передаваемых данных Для передачи данных об учебных планах должен использоваться механизм генерации сервером приложений, входящим в состав платформы «Мельница данных», web-страницы, отображающей набор ссылок, соответствующих наименованиям факультетов и отделений, при переходе по которым на странице должен отображаться перечень утвержденных РУП выбранного факультета (отделения). Формат передаваемых данных – HTML-документ с внедренным сценарием javascript. Web-страница, предоставляющая доступ к РУП, должна быть доступна по ссылке следующего вида: http://asav.hse.ru/plans.html?login=lll&password=ppp Строка адреса (URI) должна иметь следующую структуру: • http://asav.hse.ru – адрес web-ресурса системы АСАВ (доменное имя для ресурса должно быть выделено Заказчиком); • plans.html – имя html-документа, отображающего перечень РУП; • login=lll&password=ppp – параметры подсоединения web-сервера к базе данных системы АСАВ для получения данных об учебных планах (в базе данных системы АСАВ должен быть создан специальный пользователь lll с паролем ppp, которому доступны на просмотр только данные, подлежащие публикации);

130

Также должна быть реализована возможность генерации web-страницы отдельно для каждого факультета. Для этого строка адреса должна дополняться параметром faculty. В качестве значения этого параметра должно быть передано Краткое наименование факультета из справочника «Факультеты и отделения» системы АСАВ с заменой пробелов символом «+» (плюс) или символами «%20». Например, по адресу http://asav.hse.ru/plans.html?login=web&password=web&faculty=прикладной+политологии или http://asav.hse.ru/plans.html?login=web&password=web&faculty=прикладной%20политологии должна отобразится web-страница, содержащая утвержденные учебные планы факультета прикладной политологии. Доступными для публикации должны быть рабочие учебные планы, находящиеся в статусе «утвержден первым проректором» и «отозван для переутверждения» (значения статусов при этом на web-странице отображаться не должны). Внесение изменений в утвержденный план должно производиться по следующему алгоритму: - пользователь выполняет над планом действие «отозвать для переутверждения»; в этот момент в системе АСАВ существующий план должен перейти в статус «на утверждении» и стать недоступным для отображения на web-странице; одновременно должна создаваться копия утвержденного плана в статусе «отозван для переутверждения», эта копия должна стать доступной вместо ранее утвержденного плана; исходный экземпляр плана и его копия должны быть связаны ссылочной связью; - при повторном утверждении отозванного плана за счет ссылочной связи должна быть найдена созданная ранее копия; копия должна перейти в статус «отозванная версия» и перестать видимой на web-странице, а утвержденный план должен снова получить статус «утвержден первым проректором» и стать снова видимым на web-странице. При подключении программных средств портала к БД системы АСАВ для получения данных о студентах должен использоваться механизм SQL-запросов к СУБД Oracle. Программные средства, осуществляющие подключение, должны самостоятельно управлять форматом и структурой получаемых данных. Требования к регламенту предоставления информации Доступ к web-странице, с рабочими учебными планам должен осуществляться по согласованному с Заказчиком адресу в круглосуточном режиме за исключением периода остановки системы АСАВ для резервного копирования или обновления базы данных. Периодичность и продолжительность периода недоступности web-страницы полностью определяется действующим регламентом обслуживания базы данных системы АСАВ. 1.9. Реализация возможности доступа к данным и механизмам системы АСАВ по протоколу SOAP. В связи с расширением состава решаемых задач по интеграции информационных системы ВШЭ возникает

131

потребность предоставлении доступа к системе АСАВ с использованием стандартных протоколов взаимодействия информационных систем. Для моделирования объектов реального мира, их состояния и поведения в системе АСАВ используется объектно-ориентированный подход. Объектная модель системного слоя платформы хранится в системе по тем же принципам, что и модель бизнес-данных, т.е. объекты классов, описывающих метаданные системы (классы, поля, свойства, методы, параметры методов, пользовательские формы и проч.) хранятся в базе данных и доступны для клиентских систем по тем же принципам, что и бизнес-данные. Для организации доступа к объектам объектной модели АСАВ предлагается использовать подсистему доступа к данным, метаданным и механизмам системы по протоколу SOAP, являющуюся расширением платформы «Мельница данных». В рамках решения данной задачи Исполнителем должно быть выполнено: • Разработка и согласование спецификации сервисов, описывающей: набор классов, свойств и методов, к которым предоставляется доступ; правил вызова методов; требуемых параметров быстродействия. • Реализация возможность доступа к указанным в Спецификации классам, свойствам и методам по протоколу SOAP. • Установка и настройка, расширений платформы «Мельница данных» позволяющих обеспечить доступ к системе АСАВ по протоколу SOAP в соответствии со Спецификацией. • Разработаны примеры использования сервисов SOAР в виде сценариев на языке JavaScript. Услуги по реализации средств предоставления доступа по протоколу SOAP должны оказываться Исполнителем в отношении следующих клиентов сервиса: • системы сопровождения учебного процесса построенной на платформе eFront. • портала выпускников, построенного на платформе eFront. Механизмы доступа по протоколу SOAP должны содержать в своем составе средства предоставления клиентам сервиса актуального формального описания сервисов в формате WSDL. В спецификации сервисов для каждого сервиса должно быть представлено: • Назначение сервиса. • Перечень операций сервиса (наименование операций, описание выполняемых действий) • Описание типов сообщений (наименование типа, наименование и назначение элементов комплексных типов). • Входные параметры операции (наименование, описание) • Возвращаемые операцией значения (наименование, описание)

132

• Пример входящего SOAP сообщения; • Пример возвращаемого SOAP сообщения; Образец описания сервиса приведен в разделе 1.9.1. Состав примеров использования сервисов SOAР должен быть согласован с Заказчиком и охватывать основные сервисы и операции. Примеры использования должны быть представлены в виде сценариев на языке JavaScript. При создании текстов примеров необходимо принять за основу реализацию Microsoft JScript в составе Windows Scripting Host. Примеры должны быть представлены в виде текстовых запускаемых файлов с расширением «js» 1.9.1. Пример описания сервиса Сервис для доступа к объектам системы АСАВ класса TContact (Контактная информация) Назначение сервиса. Получение доступа к объектам системы АСАВ класса TContact (Контактная информация) для получения выборки объектов, получения значений свойств объектов, установки значений свойств, а также создания в системе АСАВ новых объектов класса TContact. Перечень операций сервиса: TContact.Properties TContact.Properties.Set TConact.Create Описание типов сообщений. Тип TContact.Properties.Input Состоит из элементов: Имя элемента

Тип данных Назначение

ID

Строковый, необязательный

Критерий отбора по идентификатору объекта

Name

Строковый, необязательный

Критерий отбора по свойству «Имя»

Description

Строковый, необязательный

Критерий отбора по свойству «Наименование»

ContactType

Строковый, необязательный

Критерий отбора по свойству «Вид контакта»

Class

Строковый, необязательный

Критерий отбора по свойству «Класс»

ReplicationStatus

Строковый, необязательный

Критерий отбора по свойству «Статус репликации»

133

ContactInfo

Строковый, необязательный

Критерий отбора по свойству «Контактная информация»

Master

Строковый, необязательный

Критерий отбора по свойству «Мастер»

SourceDataBase

Строковый, необязательный

Критерий отбора по свойству «База данных-источник»

SourceDataBaseGUID

Строковый, необязательный

Критерий отбора по свойству «GUID базы даных-источника»

SourceDataBaseIsCurrent

Строковый, необязательный

Критерий отбора по свойству «База данных-источник является текущей»

OldID

Строковый, необязательный

Критерий отбора по свойству «Идентификатор при создании»

Creator

Строковый, необязательный

Критерий отбора по свойству «Создано пользователем»

Created

Строковый, необязательный

Критерий отбора по свойству «Создано»

Modifier

Строковый, необязательный

Критерий отбора по свойству «Изменено пользователем»

Modified

Строковый, необязательный

Критерий отбора по свойству «Изменено»

Reader

Строковый, необязательный

Критерий отбора по свойству «Роль для чтения»

Writer

Строковый, необязательный

Критерий отбора по свойству «Роль для записи»

Тип TContact.Properties Состоит из элементов: Имя Тип данных Назначение

134

элемента

ID Строковый, обязательный

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

Name

Строковый, обязательный

Имя объекта. Не используется.

Description

Строковый, обязательный

Наименование объекта. Не используется.

ContactType

Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Элементы перечислений», обязательный

Вид контакта. Определяет вид контакта

Class

Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Классы», обязательный

Класс. Фактический класс объекта,

ReplicationStatus

Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Элементы перечислений», обязательный

Статус репликации. Определяет порядок репликации объекта.

ContactInfo

Строковый, обязательный

Контактная информация. Содержимое контактной информации

Master

Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Люди», обязательный

Мастер. Ссылается на объект класса «Люди», контакт которого моделируется этим объектом.

SourceDataBase

Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Базы данных», обязательный

База данных-источник. Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Базы данных», который представлял собой текущую базу данных в момент создания

135

объекта.

SourceDataBaseGUID

Строковый, обязательный

GUID базы даных-источника. Глобально уникальный идентификатор объекта класса «Базы данных», который представлял собой текущую базу данных в момент создания объекта.

SourceDataBaseIsCurrent

Логический, обязательный

База данных-источник является текущей. Признак, определяющий, является ли база данных, в которой этот объект был создан, текущей в данный момент.

OldID

Строковый, обязательный

Идентификатор при создании. Идентификатор, присвоенный объекту в той базе данных, в которой он был создан.

Creator

Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Пользователи», обязательный

Создано пользователем. Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Пользователи», который создал объект.

Created

Дата со временем, обязательный

Создано. Момент времени создания объекта.

Modifier

Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Пользователи», обязательный

Изменено пользователем. Текстовое значение, представляющее собой идентификатор некоторого

136

объекта класса «Пользователи», который последним модифицировал состояние объекта.

Modified

Дата со временем, обязательный

Изменено. Момент времени последнего изменения состояния объекта.

Reader

Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Роли безопасности», необязательный

Роль для чтения. Роль безопасности, прямым или опосредованным членам которой объект доступен для чтения.

Writer

Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Роли безопасности», необязательный

Роль для записи. Роль безопасности, прямым или опосредованным членам которой объект доступен для модификации.

Тип TContact.Properties.Set Состоит из элементов: Имя элемента

Тип данных Назначение

ID

Строковый, обязательный

Идентификатор объекта, значения свойств которого будут изменены.

Name

Строковый, необязательный

Имя объекта. Не используется.

Description

Строковый, необязательный

Наименование объекта. Не используется.

ContactType

Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Элементы перечислений», необязательный

Вид контакта. Если задан, то определяет новое значение свойства «вид контакта»

ContactInfo

Строковый, необязательный

Контактная информация. Если задан, то определяет новое значение

137

содержимого контактной информации

Reader

Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Роли безопасности», необязательный

Роль для чтения. Если задан, то определяет новое значение роли безопасности, прямым или опосредованным членам которой объект доступен для чтения.

Writer

Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Роли безопасности», необязательный

Роль для записи. Если задан, то определяет новое значение роли безопасности, прямым или опосредованным членам которой объект доступен для модификации.

Тип TContact.Create Состоит из элементов: Имя элемента

Тип данных Назначение

Name

Строковый, необязательный

Имя объекта. Не используется.

Description

Строковый, необязательный

Наименование объекта. Не используется.

Class

Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Классы», необязательный

Класс. Не используется.

Master

Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Люди», обязательный

Мастер. Ссылка на тот объект класса «Люди», контакт которого моделируется создаваемым объектом.

Accessor

Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Роли безопасности»,

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

138

необязательный в момент его создания.

ContactType

Текстовое значение, представляющее собой идентификатор некоторого объекта класса «Элементы перечислений», обязательный

Вид контакта. Определяет вид создаваемого контакта

ContactInfo

Строковый, обязательный

Контактная информация. Определяет содержимое контактной информации

Тип TContact.Create.Result Состоит из элементов: Имя элемента

Тип данных Назначение

Текстовый узел

Строковый, обязательный

Идентификатор созданного объекта

Ниже следует перечень операций сервиса. Операция TContact.Properties Операция принимает на вход сообщение типа TContact.Properties.Input Операция возвращает сообщение типа TContact.Properties В возвращаемую посылку попадают значения свойств объектов класса «Контактная информация», отобранных в соответствии с заданными в элементах входного сообщения критериях. Пример входящего сообщения: <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soap:Body> <TContact.Properties.Input xmlns="http://????"> <ContactInfo>(095)*</ContactInfo> <ID/> <ContactType/> </TContact.Properties.Input > </soap:Body> </soap:Envelope> Пример исходящего сообщения: <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <TContact.Properties xmlns="http://????"> <object> <ID>37416</ID> <ContactInfo>(095)-876-75-77</ContactInfo> <ContactType>67678</ContactType>

139

</object> <object> <ID>33443</ID> <ContactInfo>(095)-234-44-87</ContactInfo> <ContactType>67678</ContactType> </object> <object> <ID>2314322</ID> <ContactInfo>(095)-122-43-83</ContactInfo> <ContactType>67678</ContactType> </object> </TContact.Properties> </soap:Body> </soap:Envelope> Пример использования сервиса на языке JavaScript: var serviceRootUrl = "http://????" var inputEnvelop = new ActiveXObject("Msxml2.DOMDocument"); inputEnvelop.documentElement = inputEnvelop.createElement("soap:Envelope"); inputEnvelop.documentElement.setAttribute("xmlns:soap", "http://schemas.xmlsoap.org/soap/envelope/"); var bodyNode = inputEnvelop.documentElement. appendChild(inputEnvelop.createElement("soap:Body")); var messageNode = bodyNode. appendChild(inputEnvelop.createElement("TContact.Properties.Input")); messageNode.setAttribute("xmlns", serviceRootUrl); messageNode.appendChild(inputEnvelop.createElement("ContactInfo")). appendChild(inputEnvelop.createTextNode("(095)*")); messageNode.appendChild(inputEnvelop.createElement("ID")); messageNode.appendChild(inputEnvelop.createElement("ContactType")); WScript.StdOut.WriteLine(inputEnvelop.xml); var request = new ActiveXObject("Msxml2.XMLHTTP"); request.open("POST", serviceRootUrl, false); request.setRequestHeader("Content-Type", "text/xml"); request.send(inputEnvelop.xml); WScript.StdOut.WriteLine(request.responseXML.xml); Операция TContact.Properties.Set Операция принимает на вход сообщение типа TContact.Properties.Set Операция возвращает сообщение фиктивного пустого типа nodata. Значения свойств, переданные в элементах входной посылки присваиваются объекту, идентификатор которого передан в элементе входной посылки с именем «ID». Пример входящего сообщения: <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

140

<soap:Body> <TContact.Properties.Set xmlns="http://????"> <ID>2314322</ID> <ContactInfo>(095)-123-456-78</ContactInfo> </TContact.Properties.Set > </soap:Body> </soap:Envelope> Пример исходящего сообщения: <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <nodata xmlns="http://????" /> </soap:Body> </soap:Envelope> Пример использования сервиса на языке JavaScript: var serviceRootUrl = "http://????" var inputEnvelop = new ActiveXObject("Msxml2.DOMDocument"); inputEnvelop.documentElement = inputEnvelop.createElement("soap:Envelope"); inputEnvelop.documentElement.setAttribute("xmlns:soap", "http://schemas.xmlsoap.org/soap/envelope/"); var bodyNode = inputEnvelop.documentElement. appendChild(inputEnvelop.createElement("soap:Body")); var messageNode = bodyNode. appendChild(inputEnvelop.createElement("TContact.Properties.Set")); messageNode.setAttribute("xmlns", serviceRootUrl); messageNode.appendChild(inputEnvelop.createElement("ContactInfo")). appendChild(inputEnvelop.createTextNode("(095)-123-456-78")); messageNode.appendChild(inputEnvelop.createElement("ID")). appendChild(inputEnvelop.createTextNode("2314322")); WScript.StdOut.WriteLine(inputEnvelop.xml); var request = new ActiveXObject("Msxml2.XMLHTTP"); request.open("POST", serviceRootUrl, false); request.setRequestHeader("Content-Type", "text/xml"); request.send(inputEnvelop.xml); WScript.StdOut.WriteLine(request.responseXML.xml); Операция TConact.Create Операция принимает на вход сообщение типа TContact.Create Операция возвращает сообщение типа TContact.Create.Result Операция производит создание экземпляра объекта «Контактная информация», в качестве параметров вызова конструктора используются значения, переданные в переданные в элементах входной посылки. В ответной посылке возвращается идентификатор созданного объекта.

141

Пример входящего сообщения: <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soap:Body> <TContact.Create xmlns="http://????"> <Master>1212313</Master> <ContactInfo>(095)-122-43-83</ContactInfo> <ContactType>67678</ContactType> </TContact.Create> </soap:Body> </soap:Envelope> Пример исходящего сообщения: <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <TContact.Create.Result xmlns="http://????"> 731264234 </TContact.Create.Result> </soap:Body> </soap:Envelope> Пример использования сервиса на языке JavaScript: var serviceRootUrl = "http://????" var inputEnvelop = new ActiveXObject("Msxml2.DOMDocument"); inputEnvelop.documentElement = inputEnvelop.createElement("soap:Envelope"); inputEnvelop.documentElement.setAttribute("xmlns:soap", "http://schemas.xmlsoap.org/soap/envelope/"); var bodyNode = inputEnvelop.documentElement. appendChild(inputEnvelop.createElement("soap:Body")); var messageNode = bodyNode. appendChild(inputEnvelop.createElement("TContact.Create")); messageNode.setAttribute("xmlns", serviceRootUrl); messageNode.appendChild(inputEnvelop.createElement("Master")). appendChild(inputEnvelop.createTextNode("1212313")); messageNode.appendChild(inputEnvelop.createElement("ContactInfo")). appendChild(inputEnvelop.createTextNode("(095)-123-456-78")); messageNode.appendChild(inputEnvelop.createElement("ContactType")). appendChild(inputEnvelop.createTextNode("67678")); WScript.StdOut.WriteLine(inputEnvelop.xml); var request = new ActiveXObject("Msxml2.XMLHTTP"); request.open("POST", serviceRootUrl, false); request.setRequestHeader("Content-Type", "text/xml"); request.send(inputEnvelop.xml); WScript.StdOut.WriteLine(request.responseXML.xml); 1.10. Доработка архитектуры системы с целью

142

обеспечения возможностей учета данных в филиальной структуре с применением единой базы данных. 1.10.1. Описание существующей конфигурации работы системы. В настоящее время эксплуатируется четыре независимых конфигурации системы АСАВ, одна из которых развернута в Москве, и три в филиалах НИУ ВШЭ в Санкт-Петербурге, Нижнем Новгороде и Перми. В Москве система функционирует на основе СУБД Oracle 10.2.0.4. В филиалах система функционирует на основе СУБД Firebird 2.5. Синхронизация метаданных этих баз данных и синхронизация файлов исполняемых модулей платформы обеспечивается «механизмом автоообновления», разработанным специально для решения этой задачи. Синхронизация данных не производится. Большинство пользователей системы Москвы работают в локальной сети НИУ ВШЭ, их подключение к базе данных осуществляется по протоколу TCP/IP. Также в Москве настроена подсистема удаленной работы, использующая сервер приложений (asav.hse.ru). Также в Москве эксплуатируются ряд подсистем web-доступа (Личные кабинеты аспирантов, Личные кабинеты участников олимпиад школьников и студентов, Личные кабинеты абитуриентов магистратуры). Все пользователи систем, развернутых в филиалах, работают в локальной сети филиалов. Текущая конфигурация системы представлена на рис. 10 Технического задания. 1.10.2. Описание целевой архитектуры системы В целевой конфигурации все данные системы должны быть объединены в единой базе данных. Часть пользователи Москвы должна продолжить работать с системой в локальной сети по протоколу TCP/IP. Пользователи филиалов, а также часть пользователей Москвы должны получить возможность работать с системой удаленно (по протоколу HTTP) с использованием приложения «Обозреватель данных» входящего в состав платформы «Мельница данных». Для удаленной работы пользователей должна быть проведена установка ПО и настройка сервера приложений. После перехода к целевой конфигурации пользователи филиалов также должны получить возможность использовать web-приложения системы, которые в настоящее время используются только в Москве. Также необходимо реализовать: - механизм доступа удаленных пользователей к документации (в виде общедоступного web-ресурса на сервере приложений, просмотр и навигацию по документации осуществлять с помощью internet-браузера); - механизм автообновления исполняемых модулей платформы, размещаемых на рабочих местах удаленных клиентов. Схема целевой конфигурации системы представлена на рис. 11 Технического задания. Требования к рабочим местам удаленных пользователей Система должна обеспечивать необходимое

143

быстродействие при использовании удаленными пользователями компьютеров, соответствующих следующим требованиям: Требования к программному обеспечению: o OC Microsoft Windows XP sp3 или выше o Microsoft Office 2003 или выше Системные требования:

Оперативная память 1 GB 1GB свободного дискового пространства

1.10.3. Принципы разграничения прав доступа различных категорий пользователей к данным системы Все пользователи новой конфигурации системы должны разделяться на пользователей, имеющих доступ к данным системы как по Москве, так и по филиалам и на пользователей, имеющих доступ к данным только Москвы или одного филиала. Для каждого из режимов доступа в системе должны быть созданы соответствующие роли. Вхождение пользователя в роль должно определять, какой перечень объектов доступен ему для просмотра, правки, удаления. Роли должны различаться по задачам, решаемым пользователям (например, «разработка учебных планов», «работа со студентами факультета», «работа с выпускниками» и проч.). Принадлежность пользователя к роли должно задаваться путем включения пользователя в эту роль, Также путем установки для пользователей значений настроек «Филиал», «Факультет», «Подразделение ДПО» должен ограничиваться доступ пользователя к объектам в рамках каждой роли. Пустое значение настройки означает, что пользователь имеет доступ к данным всех филиалов (факультетов, подразделений ДПО). В новой конфигурации системы должны быть выделены следующие категории пользователей: • Администраторы системы – осуществляют централизованное администрирование системы, заключающееся в заведении новых пользователей и ролей, включение пользователей в роли, осуществляют администрирование базы данных, настраивают и эксплуатируют систему резервного копирования данных, обеспечивают соблюдение регламентов технического обслуживания системы; имеют доступ ко всем данным системы как по Москве, так и по филиалам, как на чтение, так и на запись • Бизнес-администраторы системы – формируют и поддерживают справочные данные системы, ведущиеся централизовано; имеют доступ ко всем данным системы как по Москве, так и по филиалам на чтение и на запись. • Бизнес-администраторы филиалов – имеют настройку «Филиал»; формируют и поддерживают справочные данные системы, ведущиеся централизовано на уровне филиала; имеют доступ ко всем данным системы одного филиала как на чтение, так и на запись; имеют доступ к справочникам системы, ведущимся централизовано, в режиме «только для чтения». • Менеджеры приемной кампании – формируют и поддерживают справочные данные о каждой приемной кампании, ведущиеся централизовано; работают с данными обо всех абитуриентах университета, включая филиалы как на чтение, так и на запись.

144

• Менеджеры приемной кампании филиала - имеют настройку «Филиал»; формируют и поддерживают справочные данные о каждой приемной кампании, ведущиеся централизовано на уровне филиала; имеют доступ к данным обо всех абитуриентах одного филиала как на чтение, так и на запись. • Пользователи участка «Абитуриент» - работают с данными об абитуриентах Москвы или одного из филиалов; имеют доступ к данным об абитуриентах как на чтение, так и на запись; имеют доступ к справочникам участка «Абитуриент» в режиме «только для чтения». • Операторы участка «Абитуриент» - имеют настройку «Филиал»; осуществляют регистрации абитуриентов Москвы или одного из филиалов; имеют ограниченный доступ к данным об абитуриентах на чтение и на запись; имеют доступ в режиме «только для чтения» к ограниченному набору справочных данных, задействованных в процедуре регистрации. • Менеджеры факультета – имеют настройки «Филиал» и «Факультет»; формируют и поддерживают справочные данные уровня факультета Москвы или факультета филиала; имеют доступ ко всем студентам своего факультета как на чтение, так и на запись; имеют доступ к справочникам, ведущимся централизованно, в режиме «только для чтения». • Пользователи участка «Студент» - имеют настройки «Филиал» и «Факультет»; работают с данными о студентах одного факультета Москвы или филиала в режимах чтения и записи; • Менеджеры аспирантуры – формируют и поддерживают справочные данные участка «Аспирант», ведущиеся централизовано; имеют доступ к данным обо всех аспирантах как Москвы, так и филиалов как на чтение, так и на запись. • Менеджеры аспирантуры филиала – имеют настройку «Филиал»; формируют и поддерживают справочные данные участка «Аспирант», ведущиеся на уровне филиала; имеют доступ к данным обо всех аспирантах либо Москвы, либо одного из филиалов как на чтение, так и на запись. • Пользователи участка «Аспирант» - имеют настройку «Филиал»; работают с данными об аспирантах либо Москвы, либо одного из филиалов в режимах чтения и записи; • Менеджеры участка ДПО – формируют и поддерживают справочные данные участка ДПО, ведущиеся централизованно; имеют доступ к данным обо всех слушателях и студентах ДПО как Москвы, так и филиалов как на чтение, так и на запись; • Менеджеры участка ДПО филиала - имеют настройку «Филиал»; формируют и поддерживают справочные данные участка ДПО, ведущиеся на уровне филиала; имеют доступ к данным обо всех слушателях и студентах ДПО либо Москвы, либо одного из филиалов как на чтение, так и на запись; • Пользователи участка ДПО – имеют настройки «Филиал» и «Подразделение ДПО»; работают с данными о слушателях ДПО одного подразделения ДПО, принадлежащего либо к Москве, либо к одному из филиалов в режимах чтения и записи; • Пользователи участка «Выпускник» - имеют

145

доступ к информации обо всех выпускниках, как Москвы, так и филиалов; имеют доступ к ряду атрибутов выпускника на запись и ко всем атрибутам в режиме чтения. • Пользователи участка «Выпускник» филиала – имеют настройку «Филиал»; имеют доступ к информации о выпускниках либо Москвы, либо одного из филиалов; ряд атрибутов доступен для записи, все атрибуты выпускников доступны на чтение. 1.10.5. Требования к доработкам программного обеспечения Системы Для реализации возможностей разграничения доступа к данным отдельных филиалов должны быть выполнены следующие доработки ПО системы: 1.Разработка справочника «Филиалы», наследующего все атрибуты справочника «Подразделения вуза» (наименование в падежах, дата создания, дата расформирования, индекс подразделения, код в ИС-ПРО и проч.). 2.Добавление настройки «Филиал», значение которой должно задаваться ссылкой на запись справочника «Филиалы». 3.Модификация представлений справочных данных, относящихся к уровню филиала, в целью отбора данных только по тому филиалу, который задан настройкой пользователя. 4.Модификация представлений данных об абитуриентах, студентах, аспирантах, выпускниках с целью отбора данных только по тому филиалу, который задан настройкой пользователя. 5.Добавление параметра «Филиал» в условия выборки и значения в формы отчетов во все статистические и аналитические отчеты по контингенту абитуриентов, студентов, слушателей ДПО, выпускников. 1.11. Объединение справочных и оперативных данных из баз данных систем работающих в Москве и трех филиалах ВШЭ в единую базу данных. 1.11.1. Перечень настроек системы, которые должны вестись централизовано Централизовано должно осуществляться изменение значений следующих настроек: • Наименование вуза (в именительном и других падежах); • Ректор вуза • Текущий набор • Текущий поток набора • Проректор, курирующий аспирантуру • Проректор (директор), курирующий ДПО • Норматив площади в общежитии Пользователи, имеющие настройку «Филиал», должны утратить право доступа к данным настройкам в режиме записи, но должны сохранить возможность доступа в режиме чтения. 1.11.2. Требования к механизмам ведения справочников Все справочники системы должны быть разделены на три категории: - справочники, ведущиеся централизовано на уровне вуза

146

(Ц); - справочники, ведущиеся централизовано на уровне филиала (Ф); - справочники, ведущиеся на уровне подразделения (факультета, кафедры, подразделения ДПО) (П) № п/п

Наименование

справочника

Категория

справочника*

*

Категория пользовате

лей

Ответственное подразделение

* Общевузовские справочники

1 Филиалы Ц Бизенс-администраторы

Управление организации учебного процесса (УОУП)

2 Факультеты и отделения

Ц Бизенс-администраторы

УОУП

3 Подразделения вуза

Ц Бизенс-администраторы

УОУП

4 Переименования вуза

Ц Бизенс-администраторы

УОУП

5 Учебные здания

Ц Бизенс-администраторы

УОУП

6 Наборы в вуз

Ц Менеджеры приемной кампании

Управление по работе с абитуриентами

7 Формы обучения

Ц Бизенс-администраторы

УОУП

8 Образовательные программы

Ц Бизенс-администраторы

Методическое управление (МУ)

9 Направления и специальности

Ц Бизенс-администраторы

МУ

10 Степени и квалификации

Ц Бизенс-администраторы

МУ

11 Степени Ц Бизенс- МУ

147

по направлениям / Квалификации по специальностям

администраторы

12 Магистерские программы

Ц Бизенс-администраторы

МУ

13 Магистерские специализации

Ц Бизенс-администраторы

МУ

14 Группы стран

Ц Бизенс-администраторы

УОУП

15 Страны и регионы

Ц Бизенс-администраторы

УОУП

16 Приоритетные направления развития

Ц Бизенс-администраторы

УОУП

17 Виды документов

Ц Бизенс-администраторы

УОУП

18 Причины перемещений студентов

Ц Бизенс-администраторы

УОУП

19 Категории персонала

Ц Бизенс-администраторы

УОУП

Участок «Студент» 20 Календар

ные периоды обучения студентов

Ц Бизенс-администраторы

МУ

21 Соответствие оценок (шкалы пересчета)

Ц Бизенс-администраторы

УОУП

22 Виды стипендий

Ц Бизенс-администраторы

УОУП

23 Основание перехода на индивидуальный учебный план

Ц Бизенс-администраторы

УОУП

24 Основания выплат материаль

Ц Бизенс-администраторы

УОУП

148

ной помощи

25 Типы образовательных стандартов

Ц Бизенс-администраторы

МУ

26 Образовательные стандарты

Ц Бизенс-администраторы

МУ

27 Кафедры факультетов

Ф Бизнес-администраторы филиала

Учебное управление филиала

28 Структура курсов и групп факультета

П Менеджеры факультета

Учебные части факультетов

29 Направления и специальности на факультетах

П Менеджеры факультета

Учебные части факультетов

30 Специализации на факультетах

П Менеджеры факультета

Учебные части факультетов

31 Магистерские программы на факультетах

П Менеджеры факультета

Учебные части факультетов

Участок «Абитуриент» 32 Конкурсы

в бакалавриат (включая предметы на конкурс, скидки и проч.)

Ф Менеджеры приемной кампании филиала

Приемная комиссия Москвы (филиала)

33 Конкурсы в магистратуру (включая предметы на конкурс, соответствие

Ф Менеджеры приемной кампании филиала

Приемная комиссия Москвы (филиала)

149

олимпиад и проч.)

34 Олимпиады школьников

Ц Менеджеры приемной кампании

Управление по работе с абитуриентами

35 Виды льгот и привилегий для абитуриентов бакалавриата (включая правила рекомендации, правила зачета оценок)

Ц Менеджеры приемной кампании

Управление по работе с абитуриентами

36 Виды льгот и привилегий для абитуриентов магистратуры (включая правила рекомендации, правила зачета оценок)

Ц Менеджеры приемной кампании

Управление по работе с абитуриентами

Участок «Аспирант» 37 Календар

ные периоды обучения аспирантов

Ц Менеджеры аспирантуры

Управление аспирантуры и докторантуры

38 Отрасли науки

Ц Менеджеры аспирантуры

Управление аспирантуры и докторантуры

39 Научные специальности

Ц Менеджеры аспирантуры

Управление

150

аспирантуры и докторантуры

40 Вхождение научных специальностей в отрасли науки

Ц Менеджеры аспирантуры

Управление аспирантуры и докторантуры

41 Структура аспирантуры

Ц Менеджеры аспирантуры

Управление аспирантуры и докторантуры

42 Диссертационные советы

Ц Менеджеры аспирантуры

Управление аспирантуры и докторантуры

43 Контрольные этапы аспирантов

Ц Менеджеры аспирантуры

Управление аспирантуры и докторантуры

44 Кафедры, реализующие научные специальности

Ф Менеджеры аспирантуры филиала

Отделы аспирантуры филиалов

Участок «Дополнительное образование» 45 Направле

ния дополнительного образования

Ц Менеджеры участка ДПО

Управление дополнительного образования

46 Форматы программ

Ц Менеджеры участка

Управлени

151

ДПО ДПО е дополнительного образования

47 Продолжительности программ ДПО

Ц Менеджеры участка ДПО

Управление дополнительного образования

48 Институты и центры ДПО

Ц Менеджеры участка ДПО

Управление дополнительного образования

49 Категории государственной гражданской службы

Ц Менеджеры участка ДПО

Управление дополнительного образования

50 Программы ДПО

Ф Менеджеры участка ДПО филиала

Отдел дополнительного образования филиала (Москвы)

51 Специализации по программам ДПО

Ф Менеджеры участка ДПО филиала

Отдел дополнительного образования филиала

152

(Москвы)

52 Группы слушателей по программам ДПО

П Пользователи участка ДПО

Подразделение ДПО филиала (Москвы)

53 Работники подразделения ДПО

П Пользователи участка ДПО

Подразделение ДПО филиала (Москвы)

* Подразделения, ответственные за сопровождение каждого из справочников, могут изменяться при изменении распределения обязанностей между подразделениями. Назначение круга пользователей, ответственных за сопровождение справочников каждой из категорий, должно производиться администратором системы при помощи механизма ролей пользователей и включения пользователей в роли. ** Отношение справочника к категории должно быть утонено на этапе доработки функциональности. 1.11.3. Принципы объединения справочников и данных Систем, функционирующих в Москве и филиалах в единую базу данных. Должно быть проведено первичное слияние баз данных филиалов в базу данных Москвы. Процедура объединения в ходе загрузки данных должна выполнять идентификацию данных источника на предмет существования в базе-приемнике. Идентификация выполняется в два этапа: - сопоставление по сочетанию значений полей «База данных–источник» и «Идентификатор при создании»; - сопоставление по сочетанию значений полей «Класс», «Мастер», «Родитель», «Имя». Процедура импорта данных должна обрабатывать каждую из записей реплики-источника по следующему алгоритму: 1. Первый этап поиска объекта в базе-приемнике (по значениям полей «База данных–источник» и «Идентификатор при создании»). Если объект найден в базе-приемнике, для него обновляются значения всех свойств, значения которых содержатся в реплике-источнике. В дальнейшем все ссылочные связи других объектов из реплики-источника будут перенаправлены на найденный объект в базе-приемнике. 2. Если объект не найден на предыдущем шаге, выполняется второй этап поиска объекта (по значениям полей «Класс», «Мастер», «Родитель», «Имя»). Если объект найден в базе-приемнике, для него выполняются действия, описанные в п. 1. 3. Если объект не найден на этапе 2, то выполняется добавление объекта в базу-приемник. Новый объект получает значения всех свойств, содержащихся в реплике-источнике. В ходе добавления объекта для всех полей-ссылок выполняется поиск существующих или

153

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

154

действие «Объединить объекты». Исполнителем должны быть разработаны инструкции, содержащие методики поиска повторяющихся записей и сценарии выполнения операций объединения. 1.11.4. План мероприятий по переводу системы из текущей в целевую конфигурацию. Мероприятия по объединению баз данных системы АСАВ, функционирующих в Москве и филиалах должны выполняться по следующему плану:

№ этапа

Этап Ответственный

1. Доработки функциональности системы (добавление новых справочников, настроек, модификация представлений), описанные в п. 1.9.5. Выполнение обновлений баз данных в Москве и филиалах с целью приведения их к единой версии

Исполнитель

2. Выполнение «пилотного» этапа объединения баз данных

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

Исполнитель

2.2. Выполнение экспорта данных из БД филиалов

Исполнитель

2.3. Развертывание копии базы данных Москвы на резервном сервере.

ДИТ НИУ ВШЭ

2.4. Подготовка базы данных Москвы к импорту (защита базы-приемника, аудит данных).

Исполнитель

2.5. Выполнение импорта данных по филиалам

Исполнитель

2.6. Анализ технических ошибок импорта, их исправление в базе-приемнике и базе-источнике

Исполнитель

2.7. Выполнение импорта данных из реплик всех филиалов

Исполнитель

2.8. Доработка руководства пользователя в части работы с единой базой данных

Исполнитель

3. Анализ результатов объединения данных (проверка полноты переноса данных путем анализа статистических отчетов, анализ корректности отбора данных, отображаемых для пользователей Москвы и филиалов)

Исполнитель, пользователи Москвы, пользователи филиалов, ДИТ НИУ ВШЭ.

4. Устранение ошибок и противоречий, выявленных на «пилотном» этапе

Исполнитель

155

5. Установка и настройка оборудования и каналов связи

ДИТ НИУ ВШЭ

7. Разработка методики испытаний целевой конфигурации

Исполнитель

8. Выполнение объединения баз данных в рабочем режиме с учетом замечаний по результатам предварительного импорта.

Исполнитель

9. Опытно-промышленная эксплуатация (Длительность не менее одного месяца)

Пользователи Москвы, филиалов, ДИТ

10. Сопровождение и администрирование системы, консультирование пользователей на этапе Опытно-промышленной эксплуатации. (Длительность не менее одного месяц)

Исполнитель.

11. Проведение приемо-сдаточных испытаний

Исполнитель, ДИТ

В течение 10 рабочих дней с даты заключения договора должно быть проведено уточнение и согласование сроков выполнения пунктов плана. 1.12. Общие требования к доработкам функциональности В рамках оказания услуг по развитию функциональности по п.п. 1.1.- 1.9. Исполнитель разрабатывает действующий макет решения, устанавливает его на тестовом сервере Заказчика, проводит демонстрацию ключевым пользователям Системы, осуществляет сбор замечаний по разработанной функциональности, устраняет замечания, осуществляет установку обновлений на рабочую версию Системы. 1.13. Прочие требования. При разработке должны использоваться следующие средства/языки программирования и библиотеки: • Средства разработки прикладных решений платформы «Мельница данных», в том числе встроенный язык Pascal-script • Для реализации WEB интерфейсов должны использоваться HTML, JScript • Отчеты должны быть разработаны средствами платформы «Мельница данных», шаблоны отчетов должны быть разработаны на основе документов MS Word, рабочих книг MS Excel, XSLT-преобразований; Предварительные испытания, первичная демонстрация функциональности должны выполняться на тестовой конфигурации развертываемой Исполнителем на технических средствах Заказчика. Все программное обеспечение, разработанное в рамках данного технического задания, должно быть установлено и настроено на программно-аппаратной базе Заказчика, а также передано в виде единого пакета обновления системы «АСАВ» в формате подсистемы установки обновлений в электронном виде и инструкции по его установке, в случае если порядок установки отличатся от

156

установки стандартных пакетов обновлений. Услуги по установке обновлений в рабочую конфигурацию системы должны выполняться в нерабочее время, по предварительному согласованию с Заказчиком. Исполнитель должен самостоятельно ознакомиться с технологическими возможностями платформы «Мельница данных» по материалам поставляемым производителем платформы и материалам, представленным на WEB-сейте производителя платформы (http://www.techmill.ru). Заказчик не оказывает консультаций по использованию платформы «Мельница данных». 2. Место, условия и сроки оказания услуг: Срок оказания услуг по договору – с даты заключения договора до 30 ноября 2011 года. Результаты оказания услуг должны быть представлены по адресу Заказчика: г. Москва, ул. Мясницкая, д. 20, комната 222.

2. Требования к сроку и (или) объему предоставления гарантий качества услуг: В срок, являющийся критерием оценки, - в течение 6 (шести) месяцев с даты подписания акта сдачи-приемки услуг (Gmin = 6) Исполнитель должен безвозмездно устранять ошибки, выявленные Заказчиком в сопроводительной документации и работе функциональности системы, реализованной или измененной в ходе оказания услуг в соответствии с Техническим заданием.

Форма должна быть подписана уполномоченным лицом Участника

размещения заказа и скреплена печатью Участника размещения заказа.

(подпись) (фамилия, имя, отчество подписавшего лица, должность)

М.П.

(подпись) (фамилия, имя, отчество главного бухгалтера)

157

Форма 5 Приложение 4

к заявке на участие в конкурсе от «____»_____________ г. № __________

Информация о наличии за последние два года, предшествующие

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

стоимостью не менее пятидесяти процентов начальной цены договора, установленной конкурсной документацией. Под аналогичными

услугами понимаются услуги по созданию и развитию информационных систем на базе платформы «Мельница данных».

(является условием допуска к участию в конкурсе)1

№ п/п

Номер контракта (договора)

Предмет контракта (договора)

Краткое описание оказанных услуг

Наименование заказчика, ФИО, должность и контактный телефон представителя заказчика

Даты заключения и завершения контракта (договора)

1 2 3 4 5 6 1. 2. 3. ….

Форма должна быть подписана уполномоченным лицом Участника размещения

заказа и скреплена печатью Участника размещения заказа

1 В подтверждение информации участник размещения заказа представляет копии актов сдачи-приемки по договорам. Принимается к рассмотрению только та информация, которая подтверждается копиями актов сдачи-приемки.

(подпись) (фамилия, имя, отчество подписавшего лица, должность)

М.П.

(подпись) (фамилия, имя, отчество главного бухгалтера)

158

Форма 6 Приложение 5

к заявке на участие в конкурсе от «____»_____________ г. № __________

Информация об опыте оказания аналогичных услуг за последние 5 лет.

Аналогичными признаются услуги по созданию и развитию информационных систем на базе платформы «Мельница данных».

(является критерием оценки заявок на участие в конкурсе)2

№ п/п

Номер контракта (договора)

Предмет контракта (договора)

Краткое описание оказанных услуг

Наименование заказчика, ФИО, должность и контактный телефон представителя заказчика

Даты заключения и завершения контракта (договора)

1 2 3 4 5 6 1. 2. 3. ….

Форма должна быть подписана уполномоченным лицом Участника размещения

заказа и скреплена печатью Участника размещения заказа

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

(подпись) (фамилия, имя, отчество подписавшего лица, должность)

М.П.

(подпись) (фамилия, имя, отчество главного бухгалтера)

159

Форма 7 Приложение 6

к заявке на участие в конкурсе от «____»_____________ г. № __________

Информация о положительных отзывах заказчиков о качестве

оказанных Участником услуг (является критерием оценки заявок на участие в конкурсе)3

№ п/п

Предмет контракта (договора)

Наименование заказчика

Краткое описание оказанных услуг

Дата заключения контракта (договора)

Даты завершения контракта (договора)

Отзыв заказчика о качестве оказанной услуги по контракту (договору)

1 2 3 4 5 6 7 1. 2. 3. ….

Форма должна быть подписана уполномоченным лицом Участника размещения заказа и скреплена печатью Участника размещения заказа

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

(подпись) (фамилия, имя, отчество подписавшего лица, должность)

М.П.

(подпись) (фамилия, имя, отчество главного бухгалтера)

160

10.ПРОЕКТ ДОГОВОРА

ДОГОВОР № ___________________

г. Москва «___»__________2011 г. Настоящий Договор заключен в целях обеспечения нужд автономного учреждения в порядке, предусмотренном Гражданским кодексом Российской Федерации и иными федеральными законами между федеральным государственным автономным образовательным учреждением высшего профессионального образования «Национальный исследовательский университет «Высшая школа экономики», именуемым в дальнейшем «Заказчик», в лице ______________, действующего на основании доверенности от _____ № ________, с одной стороны, и __________________________________, именуемым в дальнейшем «Исполнитель», в лице _____________, действующего на основании _______________, с другой стороны, совместно именуемыми "Стороны", на основании Протокола __________ № _______ от ______ о нижеследующем:

1. ПРЕДМЕТ ДОГОВОРА 1.1. Исполнитель по заданию Заказчика обязуется оказать Услуги по разработке и внедрению новой функциональности автоматизированной системы (АСАВ), в рамках реализации «Программы развития государственного образовательного бюджетного учреждения высшего профессионального образования «Государственный университет – Высшая школа экономики», в отношении которого установлена категория «национальный исследовательский университет», на 2009 – 2018 годы» (далее - Услуги) на условиях, в порядке и в сроки, определяемые Сторонами в настоящем Договоре, передать Заказчику результаты оказанных Услуг (далее – Результаты), а также предоставить Заказчику права на использование Результатов, являющихся результатом интеллектуальной деятельности, а Заказчик обязуется принять и оплатить оказанные Услуги и Результаты. Результаты оказанных Услуг указаны в п. 6 Технического задания (Приложение А). 1.2. Место, условия и сроки оказания Услуг: 1.2.1. Результаты оказания Услуг должны быть представлены по адресу Заказчика: г. Москва, ул. Мясницкая, д. 20, комната 222. 1.2.2. Срок оказания Услуг: с даты заключения договора до 30 ноября 2011 года. 1.3. Наименование, объем и характеристики Услуг и Результатов, осуществляемых по Договору, указаны в Техническом задании (Приложение А), являющемся неотъемлемой частью настоящего Договора. 1.4. Исполнитель гарантирует, что он обладает достаточным объемом прав для создания Результата, что заключение настоящего Договора не приведет к нарушению прав интеллектуальной собственности третьих лиц. Исполнитель также гарантирует, что им не заключались, и не будут заключаться в дальнейшем какие-либо договоры, противоречащие настоящему Договору или делающие невозможным его выполнение.

2. ЦЕНА ПО ДОГОВОРУ И ПОРЯДОК РАСЧЁТОВ 2.1. Общая цена Договора, указанная в Таблице цен, (Приложение Б), являющейся неотъемлемой частью настоящего Договора, составляет ______________ (_______________), в том числе НДС 18% __________ (_______________).

161

Источник финансирования - средства Программы развития государственного образовательного бюджетного учреждения высшего профессионального образования «Государственный университет – Высшая школа экономики», в отношении которого установлена категория «национальный исследовательский университет», на 2009-2018 годы, мероприятие 5.2 «Развитие информационной инфраструктуры университета». 2.2. Цена Договора включает в себя все расходы Исполнителя, связанные с исполнением Договора, в том числе оплата обязательных платежей в соответствии с законодательством РФ. 2.3. Исполнитель не вправе в одностороннем порядке увеличивать стоимость Услуг в течение срока действия настоящего Договора. 2.4. По настоящему Договору Заказчик производит оплату безналичным расчетом. Оплата производится по факту оказания Услуг в течение 10 (десяти) банковских дней на основании акта сдачи-приемки услуг, подписанного Исполнителем и Заказчиком, и оригинала счета Исполнителя. Акт и счет должны представляться Исполнителем в офис Заказчика лично сотруднику, осуществляющему контроль исполнения Договора. 2.5. Обязательство Заказчика по оплате оказанных Услуг считается исполненным после списания денежных средств со счета Заказчика. 2.6. Исполнитель вправе потребовать у Заказчика в подтверждение оплаты Услуг копию платежного поручения с отметкой банка об исполнении. 2.7. Заказчик по согласованию с Исполнителем в ходе исполнения Договора вправе изменить не более чем на десять процентов объем Услуг при изменении потребности в таких Услугах. При выполнении дополнительного объема таких Услуг, Заказчик по согласованию с Исполнителем вправе изменить первоначальную цену Договора, указанную в п. 2.1. пропорционально объему таких Услуг, но не более чем на десять процентов такой цены Договора. 2.8. Изменение Сторонами Договора объема оказываемых Услуг и первоначальной цены Договора более чем на десять процентов допускается исключительно в порядке, предусмотренном локальными актами Заказчика.

3. КАЧЕСТВО УСЛУГ 3.1. Услуги должны отвечать требованиям качества, безопасности жизни и здоровья, а также иным требованиям сертификации, безопасности (санитарным нормам и правилам, государственным стандартам и т.п.), лицензирования, если такие требования предъявляются действующим законодательством Российской Федерации или настоящим Договором. 3.2. Заказчик вправе проверять ход и качество оказываемых Услуг в период действия настоящего Договора, не вмешиваясь в деятельность Исполнителя. В случае выявления Заказчиком нарушений в ходе оказания Услуг со стороны Исполнителя Сторонами составляется двусторонний акт с указанием недостатков Услуг и сроков их устранения. 3.3.В случае существенного нарушения требований к качеству Услуг Заказчик вправе по своему выбору: 3.3.1. Инициировать расторжение настоящего Договора и потребовать возврата уплаченной суммы, в случае ее оплаты; 3.3.2. Потребовать устранения недостатков оказанных Услуг.

4. ПОРЯДОК СДАЧИ-ПРИЕМКИ УСЛУГ 4.1. В день окончания оказания Услуг Исполнитель обязан передать Заказчику двусторонний акт сдачи-приемки Услуг, составленный в двух оригинальных экземплярах и подписанных со своей стороны.

162

4.2. Заказчик в течение 5 (пяти) рабочих дней со дня получения акта сдачи-приемки Услуг от Исполнителя обязан подписать акт сдачи-приемки Услуг со своей стороны и передать один экземпляр акта сдачи-приемки Услуг Исполнителю. 4.3. Заказчик, в случае отступления от условий настоящего Договора при приемке оказанных Услуг составляет мотивированный отказ и направляет его Исполнителю в течение 5 (пяти) рабочих дней, с указанием сроков устранения недостатков. Обнаруженные недостатки устраняются Исполнителем за свой счет. При устранении недостатков Сторонами подписывается акт устранения недостатков. 4.4. Услуги считаются принятыми после подписания акта сдачи-приемки Услуг. 4.5. При обнаружении недостатков оказанных Услуг после их приемки, Заказчик незамедлительно уведомляет об этом Исполнителя и приглашает для подписания двухстороннего акта о выявленных недостатках оказанных Услуг и сроках их устранения. Если Исполнитель не явится для подписания акта в течение 2 (двух) дней со дня получения уведомления Заказчика, Заказчик имеет право составить односторонний акт и направить его Исполнителю, с требованием устранить недостатки оказанных Услуг.

5. ОБЯЗАТЕЛЬСТВА СТОРОН 5.1. Исполнитель обязан: 5.1.1. Оказать Услуги лично. Исполнитель вправе привлечь для оказания Услуг третье лицо с согласия Заказчика, оставаясь ответственным перед Заказчиком за действия третьего лица. 5.1.2. Подписывать акт сдачи-приемки Услуг в порядке и в сроки, установленные настоящим Договором. 5.1.3. Результаты оказанных Услуг согласно условиям Технического задания должны быть переданы по адресу Заказчика: г. Москва, ул. Мясницкая, д. 20, комната 222. 5.1.4. Передать Заказчику следующие права на Результаты: - право на воспроизведение. Действие передаваемых прав на Результаты не ограничивается территориальными пределами. Права по настоящему Договору передаются на весь срок действия исключительного права на Результаты оказанных Услуг. 5.2. Исполнитель вправе: 5.2.1. Получать от Заказчика любую информацию, необходимую для выполнения своих обязательств по настоящему Договору; 5.2.2. Самостоятельно определять методы проведения Услуг в рамках настоящего Договора. 5.3. Заказчик обязуется: 5.3.1. Оплатить оказанные Услуги Исполнителя в соответствии с настоящим Договором. 5.3.2. Предоставлять Исполнителю исходные материалы и информацию. 5.3.3. Подписывать своевременно акт сдачи-приемки Услуг. 5.3.4. Давать необходимые Исполнителю разъяснения по интересующим его вопросам в ходе оказания Услуг в рамках настоящего Договора. 5.4. Результат оказанных Услуг, передаваемый Исполнителем в рамках настоящего Договора, принадлежит Заказчику в полном объеме.

6. ОТВЕТСТВЕННОСТЬ СТОРОН 6.1. За неисполнение или ненадлежащее исполнение обязательств по настоящему Договору Стороны несут ответственность в соответствии с законодательством Российской Федерации. 6.2. За нарушение сроков оказания Услуг Заказчик имеет право начислить Исполнителю неустойку в размере 0,1% от цены Договора за каждый день просрочки. 6.3. В случае нарушения Исполнителем качества оказанных Услуг Заказчик имеет право потребовать, уплаты штрафа Исполнителем в размере 10% от цены Договора, а также

163

возмещения убытков, причиненных Исполнителем вследствие ненадлежащего исполнения Договора. 6.4. В случае нарушения Заказчиком сроков оплаты Исполнитель имеет право начислить Заказчику неустойку в размере одной трехсотой ставки рефинансирования, установленной Центральным Банком РФ на день оплаты неустойки за каждый день просрочки. 6.5. Уплата неустойки (штрафа, пени) и возмещение убытков, причинённых ненадлежащим исполнением обязательств, не освобождает Стороны Договора от исполнения обязательств по Договору в полном объёме. 6.6. В случае существенного нарушения Исполнителем условий настоящего Договора Заказчик вправе инициировать расторжение настоящего Договора. При расторжении Договора по решению суда сведения об Исполнителе подлежат внесению в реестр недобросовестных поставщиков, в порядке и на условиях, установленных законодательством Российской Федерации.

7. ОБЕСПЕЧЕНИЕ ИСПОЛНЕНИЯ ДОГОВОРА 7.1. По настоящему Договору устанавливается обеспечение исполнения Договора. Размер обеспечения исполнения Договора составляет 244 800,00 рублей (Двести сорок четыре тысячи восемьсот рублей 00 копеек). 7.2. Обеспечение исполнения Договора представляется Исполнителем в виде _____________. 7.3. Обеспечение исполнения Договора подтверждено Исполнителем следующим документом: _____________________. 7.4. Размер обеспечения исполнения Договора подлежит выплате Заказчику в качестве компенсации за любые убытки, которые последний может понести вследствие невыполнения в полном объеме или ненадлежащего выполнения Исполнителем своих обязательств по настоящему Договору. 7.5. В случае если по каким-либо причинам обеспечение исполнения Договора перестало быть действительным, закончило свое действие или иным образом перестало обеспечивать выполнение Исполнителем своих обязательств по Договору, Исполнитель обязуется в течение 10 (десяти) банковских дней предоставить Заказчику новое надлежащее обеспечение исполнения Договора на тех же условиях и в том же размере, что указаны в данном разделе

8. ПОРЯДОК РАССМОТРЕНИЯ СПОРОВ 8.1. Споры и/или разногласия, возникшие между Сторонами при исполнении условий настоящего Договора, решаются путём переговоров. В случае невозможности разрешения разногласий путем переговоров они подлежат рассмотрению в Арбитражном суде города Москвы в установленном порядке. 8.2. По всем вопросам, не урегулированным настоящим Договором, но прямо или косвенно вытекающим из отношений Сторон по нему, затрагивающих имущественные интересы и деловую репутацию Сторон настоящего Договора, Стороны будут руководствоваться законодательством Российской Федерации.

9.ОБСТОЯТЕЛЬСТВА НЕПРЕОДОЛИМОЙ СИЛЫ 9.1. Стороны освобождаются от ответственности за частичное или полное неисполнение обязательств по настоящему Договору, если ненадлежащее исполнение Сторонами обязательств вызвано непреодолимой силой, т.е. чрезвычайными и непредотвратимыми обстоятельствами, возникшими помимо воли и желания Сторон и которые нельзя предвидеть или избежать. К таким обстоятельствам не относятся, в частности, нарушение обязанностей со стороны третьих лиц, отсутствие на рынке нужных для исполнения Договора товаров.

164

9.2. Сторона, которая не в состоянии выполнить свои обязательства, незамедлительно письменно информирует другую Сторону о начале и прекращении указанных выше обстоятельств, но в любом случае не позднее 3 (трех) дней после начала их действия и прекращении соответственно. 9.3. Несвоевременное уведомление либо не уведомление об обстоятельствах непреодолимой силы лишает соответствующую Сторону права на освобождение от ответственности за невыполнение обязательств по причине указанных обстоятельств. 9.4. Если обстоятельство непреодолимой силы непосредственно повлияло на исполнение обязательств в срок, установленный в настоящем Договоре, срок исполнения обязательств отодвигается соразмерно времени действия соответствующего обстоятельства, но не более чем на 3 (три) месяца. 9.5. Если обстоятельства непреодолимой силы будут действовать свыше 3 (трех) месяцев, то каждая из Сторон вправе расторгнуть настоящий Договор и в этом случае ни одна из Сторон не вправе требовать возмещения убытков. 9.6. Доказательством наличия обстоятельств непреодолимой силы и их продолжительности является соответствующее письменное свидетельство органов государственной власти Российской Федерации.

10. СРОК ДЕЙСТВИЯ ДОГОВОРА 10.1. Договор вступает в силу с момента его подписания и действует до «___» _________ 2011 года. 10.2. Прекращение действия Договора не освобождает Стороны от обязанности возмещения убытков и уплаты штрафных санкций и иной ответственности, установленной настоящим Договором и законодательством Российской Федерации.

11. ЗАКЛЮЧИТЕЛЬНЫЕ ПОЛОЖЕНИЯ 11.1. Настоящий Договор составлен в двух экземплярах, имеющих одинаковую юридическую силу, по одному экземпляру для каждой из Сторон. 11.2. Ни одна из Сторон не вправе передавать свои обязательства по настоящему Договору третьим лицам без письменного согласия на то другой Стороны. 11.3. При исполнении Договора изменение его условий и расторжение Договора допускается по соглашению Сторон исключительно в случае существенного изменения обстоятельств, из которых Стороны исходили при заключении Договора, в порядке, предусмотренном законодательством Российской Федерации. При не достижении Сторонами соглашения об изменении условий Договора в соответствии с существенно изменившимися обстоятельствами или о его расторжении, Договор может быть изменен или расторгнут судом в порядке и по основаниям, предусмотренным Гражданским кодексом Российской Федерации. 11.4. Все сообщения, предупреждения, уведомления и заявления Сторон в ходе исполнения настоящего Договора направляются в письменной форме посредством факсимильной или электронной почты, либо почтой, заказным письмом с уведомление, с последующим направлением оригинала. При этом Сторона-отправитель должна удостовериться в получении Стороной-адресатом направленного сообщения, предупреждения или заявления.

12. БАНКОВСКИЕ РЕКВИЗИТЫ И АДРЕСА СТОРОН 12.1. В случае изменения юридического адреса или обслуживающего банка Стороны обязаны в течение двух рабочих дней уведомить об этом друг друга. Приложения: Приложение А (Техническое задание) Приложение Б (Таблица цен)

165

ИСПОЛНИТЕЛЬ:

ЗАКАЗЧИК: федеральное государственное автономное образовательное учреждение высшего профессионального образования "Национальный исследовательский университет "Высшая школа экономики" Место нахождения: 101000, г. Москва, ул. Мясницкая, дом 20 ИНН 7714030726 КПП 770101001 Получатель: УФК по г. Москве (Национальный исследовательский университет «Высшая школа экономики» л/с 30736U27000) Банк получателя: Отделение 1 Московского ГТУ Банка России г. Москва 705 БИК 044583001 Р/счет 40501810600002000079 Тел.: +7 (495) 628-47-03

166

Приложение А к Договору _____________

от «___» ___________ 2011 г.

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

ИСПОЛНИТЕЛЬ: _______________________

ЗАКАЗЧИК: федеральное государственное автономное образовательное учреждение высшего профессионального образования "Национальный исследовательский университет "Высшая школа экономики"

167

Приложение Б к Договору_____________

от «___» ___________ 2011 г.

ТАБЛИЦА ЦЕН №№

Наименование оказываемых Услуг Общая цена, руб.

1 Оказание услуг по разработке и внедрению новой функциональности автоматизированной системы (АСАВ), в рамках реализации «Программы развития государственного образовательного бюджетного учреждения высшего профессионального образования «Государственный университет – Высшая школа экономики», в отношении которого установлена категория «национальный исследовательский университет», на 2009 – 2018 годы», передаче Заказчику результатов оказанных услуг, а также предоставлению Заказчику прав на использование результатов, являющихся результатом интеллектуальной деятельности

ВСЕГО, в руб. Всего: _____________(_______________), в том числе НДС 18% __________ (_______________). В цену договора входят все расходы Исполнителя, связанные с исполнением договора, в том числе оплата обязательных платежей в соответствии с законодательством РФ.

ИСПОЛНИТЕЛЬ:

ЗАКАЗЧИК: федеральное государственное автономное образовательное учреждение высшего профессионального образования "Национальный исследовательский университет "Высшая школа экономики"