Код пишут люди. Те кто умеет.
Те кто не умеет - преподают.
Те кто не умеют и этого - руководят.
Бернард Шоу (искаж. программистами)
Попытка создать ассоциацию университетов для совместной разработки необходимого всем софта не удалась. Поэтому мы начали эту работу самостоятельно. Проект открытый (в смысле open source или, как недавно начали говорить, СПО-проект). Кто умеет что-то делать и хочет помочь - милости просим. Результаты ваших трудов вы можете сами выкладывать здесь soft4edu.org и/или в других местах на тех условиях, которые сочтете для себя удобными, лично мне нравится лицензия BSD.
Зачем это все?
С софтом в нашем образовании плохо. Богатые вкладываются и что-то делают, но поскольку каждый в отдельности университет по настоящему большие деньги вложить не может, то получается софт кривоват, сыроват и юзеры бедные плачут, но юзают, как кошка, которой наступили каблуком на хвост жрет подсунутую ей под нос сырую неочищенную луковицу.
Каждый может принять участие в разработке, тестировании, распространении, внедрении этих проектов. Каждый может использовать их, как считает нужным.
1. Индивидуальная
2. Коллективная
3. Средства
4. Симбиоз
III. Общественная жизнь
1. Спорт, культура, КВН
2. Жизнь после выпуска
3. Университет в городе, в регионе, в стране
IV. Учебное заведение - корпорация
1. Управление
2. Экономика
3. Чиновники
4. Вышестоящие организации
5. Нижестоящие организации
6. Конкуренты и/или партнеры
7. Безопасность
Зачем нужны пилотные проекты
Единой, монолитной системы Е-Университет типа ERP SAP сразу создать не получится, да и не нужно.
Нужно:
1. Закрыть несколько участков, не покрытых пока автоматизацией, и остро в ней нуждающихся.
2. Создать механизм, позволяющий интегрировать подсистемы между собой (желательно единообразным способом).
Если исходить из того, что ключевыми участниками процесса обучения являются студент и преподаватель, логично начать с двух пилотов, один из которых абсорбирует чаяния учащихся, а второй учителей. Архитектура этих двух систем должна быть построена так, чтобы они могли очень интенсивно взаимодействовать, сохраняя в то же время достаточную автономность.
Вопрос: зачем нужны две системы? Если они так тесно связаны, не лучше ли сразу построить одну?
Ответ: эти системы не зря называются пилотными. На них нужно отработать:
1. Технологию быстрой разработки отдельных подсистем, коих предстоит сделать много. Чем меньше система, тем ее легче сделать.
2. Технологию взаимодействия автономных систем между собой. На одной этого даже начать нельзя - на двух можно.
Когда и если эти две задачи будут решены, можно будет считать созданным механизм решения любых информационных проблем университета (гимназии, школы).
Цель "Создание волшебной палочки" не ставится.
Ставится цель: запуск долговременного процесса создания, постоянного поддержания и совершенствования программных продуктов для решения конкретных проблем образовательных учреждений. При этом каждый отдельный продукт должен в течении своего жизненного цикла повышать качественные и/или количественные параметры существующего процесса или создавать новые возможности (ранее не существующие).
Жизненый цикл каждого продукта проходит стадии:
- осознание потребности (ре)автоматизации или идея нового направления, которое может существовать только в виде (при поддержке) информационной системы;
- исследование предметной области, в том числе конкурентов;
- сбор и анализ требований к системе;
- планирование разработки;
- разработка (по плану и с правильным управлением);
- перенос данных из существующей старой системы или первоначальный ввод данных;
- тестирование, опытная и нормальная эксплуатация (включая постоянную поддержку);
- модернизация;
- вывод из эксплуатации с заменой на новую систему или без таковой.
Облако активно взаимодействующих, но автономно существующих систем, одни из которых вовремя умирают, другие рождаются по мере появления новых задач и потребностей, гораздо живучее одной супер-большой (и супер-дорогой) системы. Совокупная польза от них, как минимум, не меньше. Издержки ниже, да еще рассредоточены во времени и пространстве.
Возвращаясь к пилотам, остается сказать, что каждый из них потенциально может вырасти до полноценной системы (или ее части), а в худшем случае, останется недорогим исследованием тупиковой ветви (с сохранением опыта, методик и кода).
Пилотный проект "Информационная система научного студенческого общества (НСО)"
Введение
Контекст
В университете имеется несколько десятков систем разных поколений, слабо взаимодействующих между собой.
Проектируемая система является одним из двух пилотных проектов, состоящих в облаке автономных, но тесно взаимодействующих систем.
Субъекты системы
Студенты
Кураторы
Научные руководители
Разработчики системы
Инженеры технического сопровождения
Объекты системы
Научные проекты
Документы
События
Собственно информационная система
Назначение системы
Обеспечить эффективное управление проектами НСО
Дать всем субъектам НСО удобный инструмент коммуникации и совместной работы
Сохранять результаты работ в удобном для последующего применения виде
Структура технической документации
Термины и сокращения
Спецификация целей и задач системы
Спецификация ролей пользователей системы, их потребностей, прав и обязанностей
Спецификация функций и сервисов системы, в т.ч.
обслуживающих субъектов необходимых для функционирования самой системы
необходимых для обмена данными между системой и внешним миром (другими системами)
Учет затрат материальных и трудовых ресурсов (только для пилотных проектов - для рядовых здесь календарный план и смета)
Регламенты жизненного цикла системы, в т.ч.
правила формирования и внесения изменений в спецификации
регламент передачи системы в эксплуатацию (точка передачи ответственности)
регламент вывода системы из эксплуатации
учет и управление рисками на разных этапах ЖЦ системы
Термины и сокращения (глосарий)
ИС - информационная система, в портальной ИС университета все ИС - суть сайты, часто, если речь идет о данной/текущей ИС, говоря просто "система".
ЖЦ - жизненный цикл ИС. Цепь сменяющих друг друга периодов зарождения, роста, взрослой жизни и смерти (вывода из эксплуатации) ИС.
НСО - научное студенческое общество.
Документ - единица хранения контента в ИС.Обязан содержать текст, может содержать мультимедийные компоненты (графика, аудио, видео). Всегда имеет атрибуты: номер, титул (заголовок), тело (текст), автор, дата ввода. В Друпале документ - суть нода. Идентификаторы ноды: nid и url - первый определяет содержательную часть- заголовок, текст, etc. второй - точный адрес в интернете вместе с контекстом содержащего данную страницу сайта (в т.ч. стили, меню, рекламу и пр.). Возможны различные типы документов: статья, опрос, книга, etc.
Книга, подшивка - определенный редактором комплект документов (нод), организованный в иерархически связанный список заголовков. Внешне похож на оглавление обычной бумажной книги, но гораздо удобнее и богаче возможностями доступа. Может содержать под одной обложкой разнообразные типы документов. Каждый документ сохраняет самостоятельность и может входить в другие иерархии, меню и таксономии.
Событие - в зависимости от контекста это слово может означать внутреннее формализованное событие фиксируемое системой, например, регистрация нового юзера. Если событие происходит во внешнем по отношению к системе мире - конференция семинар, круглый стол - оно отражается в системе одним или несколькими документами: анонс, прямая трансляция, отчет.
Пользователь, юзер - человек использующий ИС. Распределяются по ролям. Принадлежность к роли дает юзеру те или иные права (читать, вводить и редактировать контент, модерировать и блокировать действия других юзеров, перестраивать структуру сайта). Один юзер может иметь несколько ролей.
Статус, версия, редакция, релиз - фиксация положения на жизненном пути документа, программного модуля, субъекта. Наприме, в друпале есть понятие редакции документа (то есть первая, вторая и т.д. варианты ноды), статуса пользователя (активный, заблокированный), программный модуль может быть альфа (экспериментальная) или бета (тестовая) версии, а переданные в эксплуатацию системы могут иметь номерные версии, релизы и/или сборки (билды).
Общие сведения
Контекст
Как и в любой современной (2012) организации, контекст текущего проекта в наиболее общем виде может быть представлен в виде слоённого пирога (слои снизу вверх):
1. Железо
2. Операционная система
3. Инженерная инфраструктура
4. Прикладной софт
5. Люди, пользователи
Проектируемая ИС опирается на третий слой. Разработка, в основном, является прикладной программой, а источник проблем, как всегда, произрастает в верхнем слое.
В университете наличествует классическая лоскутная автоматизация. Так исторически сложилось.
Проектируемые пилоты должны разместиться в новом объединяющем все сервис-ориентированном слое.
Вывод
В Университете созрело понимание необходимости интеграции информационных систем, улучшения коммуникационных связей между ними и между их пользователями.
Длительный процесс выбора пути решения назревших проблем завершился отказом от внедрения ERP-системы типа SAP в пользу адаптации/доработки open source решений. Выбран основной фреймворк (конструктор) - Drupal. Начаты два первых пилотных проекта: "Информационная система научного студенческого общества (НСО)" и "Информационная система Кафедры математических методов и информационных технологий и Кафедры эконометрики и математических методов анализа экономики".
Спецификации целей и задач системы
Собственно цели и задачи ИС зафиксированы в документах, подчиненных данному.
В целом этот раздел документации должен ответить на следующие ключевые вопросы:
1. Какие проблемы, сегодня мешающие работать, решит проектируемая система (для чего она)?
Проблема учета (событий, вакансий, проектов, участников, затрат)
Проблема планирования и управления деятельностью НСО
Проблема коммуникации участников НСО
2. Границы применимости ИС и данного документа
время начала - 1 апреля 2012; этапы развития - пока не ясно; срок действия - не определен
кто будет использовать, непосредственно или косвенно (для кого система?) - студенты, преподы, руководство
место использования - МГИМО, общежития, квартиры и машины (мобильная версия) студентов МГИМО
данный документ в процессе создания системы должен организовать процесс принятия решений
после окончания разработки данный документ - суть источник достоверной информации: кто, когда и почему принял то или иное решение по ходу создания ИС
3. Данный документ составлен по следующим источникам:
Приказ о создании НСО
Устав НСО
Руководитель НСО МГИМО - Чернолецкий Владимир Борисович
Председатель НСО МГИМО - (девочка Катя?)
Опрос активистов-студентов
Планы работ
Отчеты о мероприятиях
др...
Все сведено в реестр исходных данных/источников информации.
4. Разделы спецификаций
Диаграмма логических связей и информационных потоков
Собственно спецификация (таблица) содержащая колонки
уникальный номер параметра
имя параметра
описание параметра
единица измерения
начальная количественная оценка параметра (план)
конечная количественная оценка параметра (факт)
автор/источник данных
дата начала исследования параметра
дата окончания исследования параметра
исполнитель
Пояснения и примечания
5. Требования к данному документу
Необходимость и достаточность для разработки
Для оценки сроков и стоимости
Документ должен быть отрецензирован всеми заинтересованными лицами:
инициатором
представителями рядовых пользователей
руководством
Даты начала и окончания срока действия документа
6. Планы реализации и фиксация фактических контрольных точек
Календарный план-график работ
План управления качеством
План управления рисками
7. Статус и версия документа
Во избежания выдачи черновика за окончательный вариант документа и последующих тяжелых управленческих ошибок, статус, версия и редакция документа должны быть явно обозначены в начале или в конце документа.
Документ составлен с учетом требований (к сожалению, не всех) ГОСТ серий 19 и 34
Перечень целей и задач пилотного проекта
1. Исследование подходов к разработке портальной системы университета.
2. Исследование влияния расширения коммуникационных возможность на количественные и качественные показатели студенческих научных работ.
Технология проектных работ
В IT-индустрии есть две конкурирующие технологии производства софта. Легче всего их идентифицировать по типу конечной продукции: проприетарная и с открытым исходным кодом.
Проприетарный софт производится практически также, как хард, с полным циклом предпроектных исследований, обеспечением ресурсами в полном объеме, календарным планом, маркетинговым бюджетом, дале по списку: тираж, упаковка, логистика, etc.
Свободное программное обеспечение (СПО) тоже можно производить на этом конвейере.
Однако open source возник и чаще всего применяется в условиях недостатка всех типов ресурсов. Обычно нет возможности детально планировать разработку (из-за недоисследованности предметной области). У разработчиков в начале нет четкого понимания, что получится в конце. Зато есть сильная мотивация (не материального свойства) решить реально существующую проблему.
В первом варианте процесс разработки планируется, запускается и управляется сверху, во втором он растет снизу, проходит большее число итераций, тупиковых веток. Процесс идет рывками, иногда надолго останавливается или вообще прекращается. Общая статистика успешных и неуспешных проектов, сделанных по этим двум технологиям в количественном выражении сравнима (в мире около 50%, в России не больше 10%). Качество СПО часто выше проприетарных продуктов. Это объясняется доступностью кода для исследования независимым сообществом специалистов и легкостью его исправления.
Нежелание вендоров и системных интеграторов связывать себя долговременной поддержкой своей продукции, либо (что тоже самое), выставление за нее непомерных цен, также заставляет потребителей обращаться к СПО.
Логика проста:
1. Поставщик проприетарного софта меня бросит на произвол судьбы (а это конечно произойдет, ведь он не благотворитель, а занимается бизнесом, т.е. стяжательством) и у меня возникнут трудноразрешимые проблемы.
2. Выбрав СПО, я конечно рискую дольше провозиться с настройкой нужной мне функциональности, но зато я смогу настроить ее точно под мои нужды (не ломая свою оргструктуру под лекала вендора), и в дальнейшем у меня не будет проблем с поддержкой и развитием - на рынке труда всегда найдутся специалисты, которые помогут решить проблемы, которые со временем неизбежно возникнут.
Сказанное выше объясняет, почему вместо технологичных блок-схем и диаграмм Ганта тут текст эссе на тему СПО: денег нет, окладов нет (или они вдвое ниже рыночных), проблемы есть (их количество и сложность незаметно глазу, но быстро растет), конкуренты уходят вперед, сотрудники и студенты пока мирятся (терпят), но самые активные (склонные к перемене мест) понемногу от нас уходят.
Пользователи и роли
домашние, мобильные, офисные (в ассортименте), стационарные, абстрактные.
Систематизируем
По месту, откуда осуществляется доступ к сайту:
Из внутренней локальной сети университета
в т.ч. из читального зала библиотеки
Из интернета за пределами кампуса
возможно таргетировать по странам и регионам
По ролям:
Неавторизованные юзеры
в т.ч. роботы поисковых систем, хакеры, вандалы, боты
Авторизованные пользователи
системные администраторы и разработчики сайта
администраторы сайта, модераторы юзеров и контента
контент-редакторы, т.ч. главный редактор
авторы, журналисты, преподаватели, др. источники контента, в т.ч. роботы (сервисы) из других систем
студенты, комментаторы, авторизованные (паспортизованные) пользователи
руководство (привилегированный доступ к отчетам и срезам, но без функций редактирования)
По статусу:
Активный,т.е. имеющий возможность исполнять свою роль на сайте
Заблокированный,т.е. НЕ имеющий возможностиисполнять свою роль
По принадлежности к группе:
Не входит в группы
Входит в одну или несколько групп
Инициировал создание группы (владелец)
Заключение
Для тех, кто дочитал до этого места, открою секрет. Данный текст не статья и не эссе. И вообще не единый связный документ. Это почти не адаптированная копия начальных разделов ТЗ с сайта soft4edu.org , который (сайт) был создан, как "Репозитарий свободного кода для образования" с лозунгом в шапке: "Здесь образованные люди создают софт для образования новых образованных людей". Назначений и у этого сайта три:
1. Собрать команду разработчиков и создать все условия для их совместной работы.
2. Дать возможность людям, работающим в образовании, бесплатно получить софт и поддержку.
3. Спонсоры могут оценить прозрачность и перспективность работ по проектам.
Упомянутые в тексте пилотные проекты уже доступны (правда, смотреть там пока нечего - работа только началась):
И последнее.
Дабы исключить недоразумения, типа: "да вот же опубликовано - значит это официальный документ", подчеркиваю: Статус данного документа: Черновик.
