А чему вообще студентов учим? Специальность "Информационные системы и технологии" - это слишком общее название. На какую деятельность ориентировано обучение по этой специальности, какие знания и навыки им нужно приобрести в ходе практикума, какие знания у них уже есть к концу третьего курса?
Вопрос интересный и непраздный. Однако точно я на него ответить не могу, я лично вижу направление такое: специалисты в базах данных, специалистов в области построения ИС, причем без явного направления в предметной области. Хотя все-таки можно сказать, что это скорее системы для бизнеса. Т.е. не критические системы, не системы реального времени. Вообще этим должен заниматься заведующий кафедрой. Я не зав. Хотя я и многое ему советую, но он как начальник вовсе не обязан ко мне прислушиваться.
Анализ предметов может подсказать, что мы разваиваемся в области проектной деятельности в первую очередь. Такие вопросы как программирование(реализация), тестирование - остаются за рамками. К сожалению нет выделения по архитектурным решениям.
Я свою миссию вижу в развитии аналитических способностей и навыков, анализ требования, приложения, баз данных.
Здесь ведь тоже возможны разные подходы. Можно сконцентрировать внимание именно на приёмах управления требованиями (что-то вроде рисования палочек в прописи), а можно рассматривать управление требованиями в рамках всего жизненного цикла проекта (если они уже знакомы с моделями ЖЦ). Соответственно, и задачи практикума разные.
Согласен, но одного без другого не бывает. Нет занятия по рисованию палочками, откуда же научиться чисто писать?
Сопровождается ли этот набор требований описанием концепции разрабатываемой системы (что именно автоматизируем и с какой целью).
Или студенты должны додумать (задавать уточняющие вопросы) самостоятельно, в процессе работы с требованиями?
Гриша, еще раз напомню, задание не придумано мною. Я не знаю как его проводить, я не знаю буду ли его проводить. Я хочу выяснить а как надо его проводить. Gevorg предложил набор требований из воздуха - мне это кажется сомнительным. Скорее всего требования должны сопровождаться описанием общей концепции. Но я боюсь, что и в этом случае - это мало поможет. Судя по собственному опыту студент либо слишком ленив, либо просто не хватает жизненного опыта.
Исходя из некоторых систем классификации, которые им уже знакомы из теоретического курса?
Да это предположение. Я буду читать курс по анализу требований и собираю под него материал и ищу способ его подачи.
Или из системы классификации, предлагаемой используемым инструментом?
Вообще RaQuest не предлагает никакой классификации. CaliberRM - предлагет. Здесь можно основываться на SWEBOK.
Или выбрать классификационные признаки самостоятельно, исходя из каких-то особенностей создаваемой системы?
Вероятно - это было бы лучшим способом, но мне неизвестна классификация требований, контекстно зависящая от конкретики задачи. Существуют разные признаки для классификации: по статусу, по стабильности, по сложности - это управляемые классификации, есть классификация FRUPS+ - которая мне понятна и близка. Есть классификация вигерса, лиффенгуэлла и им подобным. Разница на мой взгляд не принципиальная, можно оттолкнуться от той которую
мы выработаем.
Имеется в виду трассировка требований на тесты?
Ну не обязательно. Матрица трассировки требований между собой, между требованиями и UC, между требованиями и проектными решениями, между требованиями и тестами. Последнее конечно самое важное.
У меня вызывает опаску как раз "управление требованиями" без корректного видения. У студента может сложиться впечатление, что "управлять требованиями" можно и без чёткого понимания того, что именно разрабатывается.
У меня тоже, кажется, именно это я в свой фразе и подчеркивал.
Кстати, такой подход тоже можно использовать в качестве учебной задачи - дать студентам самостоятельно "додумать" концепцию, а потом предъявить им свою, заранее подготовленную. И проанализировать ошибки и их причины - такие "разборы полётов", по моему опыту, в обучении очень эффективны. Собственные ошибки запоминаются надолго, намного дольше, чем правильно выполненные задания.
Да - это интересное предложение, имеет смысл подумать, этакий реинжиниринг концепции, по отрывкам требований :-)
Более того, это может быть доказательством многовариантности ответов. Вообще - задача сложная, но благородная. И очень похожа на ситуацию. Текст на русском - первеод на китайский - перевод на русский - сравнение :-)
Или даже скорее текст на китайском - перевод на руссский - перевод на китайский.
Идея практикума по управлению, возникла у меня под впечатлением дискуссий в этой теме. Ясно что сложно выделить управление требованиями без управления процессом и без самого процесса.
Скорее всего нужно будет дать описание такого процесса.
Но с другой стороны, можно поступить и так вот:
поскольку я все-таки буду более или менее знаком с ребятами, то могу выделить сильных и им поручить одну роль, более слабым можно поручить менее отвественную, но и более регламентированную роль.
Таким образом разделив студентов по группам, внутри каждой из которых определить ролевое распределение обязанностей, предоставить процесс взаимодействия таких ролей и далее разыгрывать эту деловую игру.
Поскольку практика фактически не оценивается, у студентов не будет прессинга оценки. Правда задача должна быть интересная и результативная, тогда будет стимул заниматься без понукания.
Как это организовать пока не знаю. Работу в команде пока внедрить не удается, хотя и пытаюсь.
В частности, в следующем году планирую для каждой группы создать собственный вики-репозиторий, в котором они накапливают артефакты своей деятельности, поскольку вход в репзиторий авторизован будет критерий для оценки активности и общего вклада в работу проекта. Итоговая оценка всем ставится на основании успешности проекта с учетом к.т.у.
Просмотр сообщений
