Форум Сообщества Аналитиков
Общий раздел => Примеры => Тема начата: Galogen от 04 Января 2009, 19:26:36
-
А почему бы нам не сделать аналогичную игру (http://www.uml2.ru/forum/index.php?topic=1101.0). Я могу быть поставщиком требований :)
Т.к. топик будет большой, то здесь будем давать ссылки на основные сообщения:
1. Команда проекта:
http://www.uml2.ru/forum/index.php?topic=1106.msg11617#msg11617
2. План действий:
http://www.uml2.ru/forum/index.php?topic=1106.msg11611#msg11611
2.1. Подробный план по работе над пп. 2.1-2.3
http://www.uml2.ru/forum/index.php?topic=1106.msg11693#msg11693
3. Шаблоны Документов:
http://www.uml2.ru/forum/index.php?topic=1106.msg11645#msg11645
4. Постановка Задачи:
http://www.uml2.ru/forum/index.php?topic=1106.msg11612#msg11612
http://www.uml2.ru/forum/index.php?topic=1106.msg11613#msg11613
http://www.uml2.ru/forum/index.php?topic=1106.msg11614#msg11614
5. Концепция от veta, StUtk, bustor (последнее обновление - 01.03.2009)
http://www.uml2.ru/forum/index.php?topic=1106.msg12632#msg12632
ДБО см. в п. 6
6. Диаграмма Бизнес Объектов (последнее обновление - 28.04.2009)
http://www.uml2.ru/forum/index.php?topic=1106.msg13782#msg13782
-
Можно. Я (да и ты) бы мог проверять и наставлять народ на путь истинный. Осталось найти народ, который хотел бы учится и проделать работу по выявлению, анализу и документированию требований к ИС.
-
Мне бы было интересно. Посмотреть, поучиться...))
-
StUtk,
Отлично. Нужен еще хотя бы один доброволец для описания требований, чтобы было веселее и быстрее.
Пока можно определиться с темой задания:
1. ИС приема платежей
2. ИС аттестации студентов
3. ИС учета кандидатов на работу или ИС Биржи труда
4. ИС заказа продукции
5. ИС покупки\продажи товаров из рук в руки
-
Какая загрузка планируется при этом?
-
Хотел написать, что загрузка по мере возможности, но если так написать, то это значит никуда у нас дело не сдвинется.
Загрузка примерно - 2-4 часа в неделю, чтобы мы успевали за неделю что-то заделивиреть :)
-
Отлично. Нужен еще хотя бы один доброволец для описания требований, чтобы было веселее и быстрее.
Кто будет играть роль заказчика? В идеале хотелось бы иметь реального заказчика.
"Cбор требований" в его отсутствие - это самая страшная аналитическая ересь. :)
-
Господа, а не хотите написать требования к рельному, но очень маленькому продукту? У меня руки так и не дошли, а тот, продукт что получился при кодировании без требований - без слез на него не взглянешь.
Размер продукта. Если бы десть лет назад я писал его на знакомом мне языке (бейсике, например), то уложился бы в день-два (если без графики). Соответственно, там пара юзкейсов, и немного остальных.
Тип продукта. Казуальная игра типа "Филера".
-
2-4 часа в неделю меня вполне устраивает.
Я с вами. :)
-
Я с вами.
-
Гриша,
Согласен с тобой, что описание абстрактного примера - это не есть гуд. Но это учебный пример, который призван сформировать навыки Анализа и Описания Требований в необходимой форме.
Сергей,
Это скорее Людям решать, кто будет делать пример - хотят они игру описывать или нет.
-
StUtk, bustor и mouse,
Что будем описывать из выше обозначенного, в то числе и то, что указал SALar?
Если нет особенных предложений, то предлагаю взять пример "ИС аттестации студентов".
-
Для меня тема "3. ИС учета кандидатов на работу или ИС Биржи труда" наименее прозрачна. Может стоит описывать ее? Своего рода моделтрование ситуации, когда аналитику поручено исследовать новую для него предметную область.
-
Гриша,
Согласен с тобой, что описание абстрактного примера - это не есть гуд. Но это учебный пример, который призван сформировать навыки Анализа и Описания Требований в необходимой форме.
Я понимаю, что это учебный пример. Но кто-то обязательно должен играть роль заказчика. Иначе этот пример научит совсем не тому, чему нужно.
-
Я вот не могу обещать уделять проекту два-четыре часа в неделю. Могу пообещать час в неделю и "постараться найти дополнительное время".
Готов выступить в роли заказчика по тем темам, которые мне более-менее знакомы или интересны. Например:
ИС продажи электронных ваучеров для оплаты сотовой связи (сам такую разрабатывал, имел дело с не вполне адекватным заказчиком и могу его смоделировать).
ИС программы лояльности клиентов интернет-магазина (эта тема мне интересна в данный момент).
-
По "ИС аттестация студентов" я бы мог быть источником информации, все-таки преподаватель и представляю о чем идет речь.
Единственно , что хотел уточнить, что автор предложения понимает под аттестацией студентов: контроль успеваемости или более объемно?
-
StUtk, bustor и mouse,
Что будем описывать из выше обозначенного, в то числе и то, что указал SALar?
Если нет особенных предложений, то предлагаю взять пример "ИС аттестации студентов".
У меня возражений нет. Равно как и предпочтений. Однако, не очень хотелось бы связываться с игрой.
-
Хорошо. Давайте тогда возмем пример "ИС аттестации студентов". Тем более у нас есть эксперт :)
План действий у нас тогда такой:
0. Формирование Команды:
0.1. Формирование Команды на описание Концепции - до 25 января 2009 г.
0.2. Формирование Команды на описание Тр. к ИС - до 25 февраля 2009 г.
1. Описание задачи от Заказчика (я + Эд + ...) - до 15 января 2009 г. - сделано
2. Описание Концепции - до 15 февраля 2009 г.
2.1. Выявление ЗЛ
2.2. Выявление проблем
2.3. Выявление целей
2.4. Выявление потребностей
2.5. Описание фичей ИС
2.6. Контекстная Диаграмма ИС
2.7. Описание рисков
2.8. Составление плана реализации ИС
3. Описание требований к ИС - до 15 марта 2009 г.
3.1. Выявление Пользователей ИС
3.2. Описание ПТ (ДВИ+Сценари ВИ)
3.3. Описание ФТ (если нужно)
3.4. Описание НФТ
4. Окончательная проверка Документов и сдача этапа - до 01 апреля 2009г.
Далее если сил хватит до добавим:
4. Проектирование ИС
5. Описание тест-сценариев и плана Тестирования
-
Начинаю постановку.
Мне как преподавателю необходимо оценивать работу студентов и учитывать их посещаемость в течение семестра.
У меня обычно несколько предметов и несколько групп. Я могу выступать как лектор и как ведущий практические занятия.
Как у лектора у меня может быть 1 группа или несколько групп (поток) на одной лекции. Лекции я могу читать по одному предмету, а могу и по нескольким в семестре.
Обычно (но это строго не требуется) я веду учет посещения студентами лекций. В принципе эту работу должны выполнять старосты групп, т.к. в конце каждого занятия преподаватель подписывает колонку посещения студентами данного занятия. Староста отчитывается в деканате по посещениям занятий. Не знаю еженедельно или раз в месяц?
Для усета посещения и учета выставляемых оценок я веду журнал. В журнале указывается дисциплина, группа, преподаватель. Далее список студентов (обычно полгруппы). В шапке таблицы я указываю дату занятия, отмечаю отсутствующих, выставляю оценку если необходимо.
Обычно количество отчетных занятий (т.е. занятий с оценокй) фиксировано и меньше чем общее число занятий (пар). Ну скажем я веду базы данных и у меня всего 18 пар (36 часов лабораторных), количество заданий скажем 8. Общая стоимость дисциплины в семестре 50 баллов. Я раскидываю их на 8 занятий, исходя из собственных соображений.
В течение семестра есть 3 контрольные точки. Эти контрольные точки я получю путем суммировния выставленных оценок и записываю в Контрольный лист успеваемости, где указываю балл и количество часов пропусков, число и подпись
В конце семестра в Экзаменационной ведомости я указываю также рейтинг за семестр (не более 50 баллов). При этом может быть просто допуск, зачет (тогда я должен записать зачтено или не зачтено дату и подпись), дифзачет (т.е. почти то же самое что и зачет но с оценкой, которая равна рейтингу в семестре + балл за зачет, всего до 100 баллов)
у нас принято
52-69 удовлетворительно
70-84 хорошо
85 -100 отлично
Ну для начала достаточно?
-
Еще наверное Эдуард принимает экзамены в конце каждого семестра по отдельным Дисциплинам, результатом которого ставится:
1. Оценка от 2 до 5
2. Явка - явился или нет
Экзамен и Зачет могут сдавать только допущенные Студенты по результатам семестра.
Также мне бы как Преподавателю хотелось иметь возможность выкладывать Лекции, Книги, Ресурсы и другие Документы, которые необходимы для обучения Студентов. А Студенты должны иметь возможность пользоваться этими Документами.
Мне бы НЕ хотелось отмечать посещение Студентов вручную. Хочется чтобы сам Студент приходя на Лекцию отмечался около стола Преподавателя.
У нас в Институте есть КИС, которая хранит данные по всем поступившим Студентам. Хочется иметь возможность импорта Студентов по необходимым группам в ИС "Учета успеваемости".
Также необходима возможность составления проверочных заданий в ИС. Чтобы Студент мог проходить эти тестовые задания и по результатам этих тестов выставлялась оценка. Тесты могут быть итоговыми (зачет, экзамен) или в качестве ДЗ несколько раз в семестр.
Необходима возможность ведения списка необходимых Заданий (ДЗ, Курсовые, Зачет, Экзамен и т.д.) по каждому предмету в каждом семестре, чтобы была возможность Студентам либо их проходить самим (тесты), либо загружать сделанные задания, либо выставлять оценки Преподавателю вручную. Необходимо в любой момент вычислить задолжников по предметам.
Вот теперь все :)
-
Еще наверное Эдуард принимает экзамены в конце каждого семестра по отдельным Дисциплинам, результатом которого ставится:
1. Оценка от 2 до 5
2. Явка - явился или нет
Экзамен и Зачет могут сдавать только допущенные Студенты по результатам семестра.
Да это так. Я могу принимать экзамены. При этом экзамены принимает лектор. Практику может вести и другой преподаватель. Именно этот преподаватель и выставляет семестровую оценку в баллах
оценка ставится действительно в виде неудовлетворительно, удовлетворительно, хорошо и отлично. Однако ставится балл за экзамен исходя из 50.
Тут следует учесть что разные вузы могут иметь разные системы оценивания
Также мне бы как Преподавателю хотелось иметь возможность выкладывать Лекции, Книги, Ресурсы и другие Документы, которые необходимы для обучения Студентов. А Студенты должны иметь возможность пользоваться этими Документами.
Мне думается это имеет мало отношения к ИС аттестации студентов
Мне бы НЕ хотелось отмечать посещение Студентов вручную. Хочется чтобы сам Студент приходя на Лекцию отмечался около стола Преподавателя.
Это скорее из области фантастики и усложняет задачу, мало чего внося в нее
У нас в Институте есть КИС, которая хранит данные по всем поступившим Студентам. Хочется иметь возможность импорта Студентов по необходимым группам в ИС "Учета успеваемости".
Вопрос чем будет отличаться ИС "Учета успеваемости" от ИС "Аттестация студента"
Также необходима возможность составления проверочных заданий в ИС. Чтобы Студент мог проходить эти тестовые задания и по результатам этих тестов выставлялась оценка. Тесты могут быть итоговыми (зачет, экзамен) или в качестве ДЗ несколько раз в семестр.
Такое пожелание можно рассматривать в качестве возможного требования
Необходима возможность ведения списка необходимых Заданий (ДЗ, Курсовые, Зачет, Экзамен и т.д.) по каждому предмету в каждом семестре, чтобы была возможность Студентам либо их проходить самим (тесты), либо загружать сделанные задания, либо выставлять оценки Преподавателю вручную. Необходимо в любой момент вычислить задолжников по предметам.
Это предполагает уже подключение подсистемы учебно-методического комплекса УМК, который разрабатывается преподавателем и вводится в виде некоторого плана-графика.
Следует также отметить следующие:
Преподаватель будет использовать систему, чтобы выставлять оценки в течение семестра и во время экзаменационной сессии. Возможно размещать программу УМК, определять нужен тест по заданию, будет ли проходить зачет или экзамен в виде тестовой программы. Если тесты будут, то желательно, чтобы система автоматом проставляла оценки в нужные места, а преподаватель мог получать итоговые ведомости
Работник деканата - должен иметь возможность определять итоговые данные по студентам группы, по группам, по факультету в целом. Проставлять допуски на сессию по данным, которые будет предоставлять преподаватель
учебо-методический отдел - получал бы различные срезы данных по итогам успеваемости на текущий момент, на контрольную точку, на конец сессии
-
Сорри, я оговорился, конечно же мы делаем ИС "Аттестации Студентов". И поэтому не достаточно только учитывать успеваемость.
Господа Аналитик, теперь шаг за Вами. Мы хотим такую вот ИС через 3 месяца и чтобы она ВСЕ могла что нам надо :)
-
Итак, на роль заказчиков определились мы с Сашей. Наша задача предоставлять информацию и быть заинтересованными в результате труда. Нам не следует пытаться быть аналитиками и экспертами в области ИТ, хотя как я полагаю, наличие таких знаний не возбраняется и часто присутствует у заказчика.
Но для чистоты эксперимента - мы только поставщики сырья.
Итак, кто будет Аналитиком, постановщиком?
Также неплохо бы иметь некоторого Рецензента
-
Коллеги,
Давайте так:
1. Эдуард (Galogen) - главный заказчик, бизнес-эксперт
2. Саша (bas) - менеджер проекта со стороны Исполнителя, я же буду рецензентом и буду наставлять на путь истинный.
3. Ира (Irr), 474 - рецензенты. Так же рецензентом м.б. любой участник.
4. StUtk, bustor, mouse и veta- Аналитики со стороны исполнителя. Аналитиками могут быть любые другие участники, но они нужны на постоянной основе.
План действий здесь:
http://www.uml2.ru/forum/index.php?topic=1106.msg11611#msg11611
Начинаем!!!
Первый шаг был сделан, т.е. Задача со стороны Заказчика была поставлена.
Следующий шаг - это выявление ЗЛ (Заинтересованных Лиц), Проблем Заказчика и Целей разработки ИС.
-
А обязанности Рецензента - это проанализировать входные данные и результат с т.з. соответствия, полноты и т.п.? Если да, то возьмете меня рецензентом?
-
Ира,
Именно таки обязанности рецензента. Записал тебя.
-
Я считаю, что желательно все-таки точно определиться с тем, кто имеет право уточнять требования. Кого слушать и принимать во внимание?
На мой взгляд уже сейчас видно, что главный Заказчик и менеджер со стороны Заказчика имеют разные пожелания к будущей ИС. С моей точки зрения требования Эдуарда более практичны, тогда как у Саши некий "наполеоновкий размах" в требованиях присутствует.
И еще. Если уж основная цели эксперимента - тренировка аналитиков Исполнителя, то правильно ли менеджеру Заказчика предлагать им план действий? В реальной жизни я такого не встречал, обычно "поставщики сырья" мало что понимают в работе аналитика и словосочетание "Заинтересованные лица" слышат чуть ли не в первый раз в жизни.
-
474,
Окончательным голосом в выставлении Требований владеет Эдуард. Я могу только предлагать, а Эдуарду решать - нужно это или нет. Так что слушать надо его.
На счет цели эксперимента. Да действительно - это тренировка Аналитиков + получения качественных требований в конце.
Посему кто-то должен сказать что делать и в какой последовательности + проверять результаты работы.
А у нас как у Заказчиков есть своя методология ведения фазы Анализа и мы хотим чтобы эта фаза проекта была сделана в соответствии с ним :P
-
474
а это просто реальная ситуация
заказчик озвучил требования 1 раз и больше до сдачи продукта у вас нет к нему доступа, а все общение идет через менеджера.
И вот теперь сдайте продукт заказчику :)
-
Саша,
Ну не будем уж так затруднять задачу :)
-
Добрый день! Как начинающий аналитик, не могу пройти мимо. Очень интересно поучаствовать.
Мои соображения на тему целей и заинтересованных лиц во вложенном файле.
По ходу чтения постановки возникло несоклько вопросов:
1. А как определяется факт аттестации? Студент аттестован если у него в совокупности имеются посещаемость, некоторый балл за весь семестр+баллы за зачет/экзамен? Или каким-то другим образом?
2. Что подразумевается под заданиями? Это самостоятельные работы, которые надо выполнить в течение пары или задания, выполнение которых по факту нужны для получения допуска до сдачи экзамена?
3. Карается ли минусовкой баллов не в срок сданное задание?
жду ваших замечаний, дополнений, критики :)
-
Спасибо за Ваш интерес.
По ходу чтения постановки возникло несоклько вопросов:
1. А как определяется факт аттестации? Студент аттестован если у него в совокупности имеются посещаемость, некоторый балл за весь семестр+баллы за зачет/экзамен? Или каким-то другим образом?
1 уровень: допуск. Студент допускается к сессии, если он имеет все зачеты, определенные в учебном плане. Могут существовать студенты, которым сессия продлевается по той или иной причине (это уже определяет декан)
К моменту начала сессии все ведомости по зачетам должны быть проставлены.
Если студент не получил к этому моменту зачет - ставиться незачтено.
Студент все-таки может получить зачет,но уже по квитку (разрешению получать зачет). Основание следует хранить, так как оно подкрепляется к ведомости в будущем.
У нас в вузе считается что зачет получен если студент набрал не менее 26 баллов, а в случае дифзачета - 52 балла.
2 уровень экзамены.
Студент допускается к экзамену только при наличии допуска к сессии.
Если по этому предмету нет зачета, а только экзамен, то допускает к экзамену преподаватель, который ведет этот предмет
Если студент не сдает 2 или 3 экзамена - то есть основание к отчислению (хотя обычно студенту продлевается сессия и дается возможность пересдать вне сессии в оговоренный срок)
Посещаемость в целом, а также факт сдачи экзаменов вне сессии учитывается при расчете совокупного рейтинга за семестр, который влияет на назначение или не назначение стипендии
2. Что подразумевается под заданиями? Это самостоятельные работы, которые надо выполнить в течение пары или задания, выполнение которых по факту нужны для получения допуска до сдачи экзамена?
Пример. предмет Информатика. Есть скажем 9 лабораторных работ. Необходимо выполнить каждую работу и возможно сдать коллоквиум (тест) по ней (зависит от преподавателя и предмета). Общее число пар - 18, получаем 1 задание на 2 занятия. Разбалловка определяется исходя из 50 баллов за семестр, т.е. примерно 50/9 за задание
В принципе для поулчения зачета или допуска можно набрать 26 баллов, т.е. при этом часть заданий может быть не выполнено.
Для определенности примем, что среди 9 заданий назначается скажем 6 строго обязательных, а остальные дополнительные для получения максимального балла. Т.е. 6 заданий студент должен выполнить обязательно, чтобы получить допуск
3. Карается ли минусовкой баллов не в срок сданное задание?
Я обычно делаю так. Сроком сдачи считается момент контрольной точки. Их у нас 3 в течение семестра. Т.е. если студент сдает работу до контрольной точки получает максимум возможного, если после, то производим уменьшение балла (если в период от 1 до 2 контрольной точки 0.8 от возможной оценки, если между 2 и 3 контрольной точкой 0.6 от возможной точки).
Т.е. вероятно нужно хранение настраиваемого правила снижения оценки в зависимости от срока сдачи (простановки оценки). Правда делать это жестко не стоит, причины сдачи не вовремя могут быть и объективные
-
Проблематично будет конечно, когда все будут писать в форум свои сообщения. То есть я, планируя начать на выходных, уже имею перед глазами чей-то ответ (хотя, конечно, постараюсь его не читать).
Может быть будем выкладывать файлы Word (а вы будете в них комментарии ставить)? Так у нас и готовые документы на выходе получатся.
И надо что-то придумать со сроками.
-
В общем что я хотел сказать предыдущим сообщением.
Идея выполнения примера описания требований отличная, но надо продумать как ее реализовать, с учетом того, что одновременно одно и то же задание выполняют несколько человек. :)
-
veta, на мой взгляд смысл этапа "выявление ЗЛ" состоит в выявлении этих самых лиц, путем опроса представителей Заказчика, а не в том, что бы с помощью "откровения свыше" аналитик сам составил список ЗЛ. Имхо, вам надо задавать вопросы Саше и Эдуарду, и уже по их ответам судить - кто же должен быть в списке ЗЛ.
bustor, согласен с замечанием. Я бы не хотел участвовать как аналитик, но как рецензент - вполне.
Саша, Эдуард, как вы смотрите на то, чтобы установить временные рамки: а) до какого времени формируется команда, б) с какого времени команда начинает действовать, в) возможно воставить календарный план проекта? В противном случае будут присоединяться новые члены и вносить некоторый дисбаланс в планы тех, кто уже что-то делает.
-
Добрый день! Как начинающий аналитик, не могу пройти мимо. Очень интересно поучаствовать.
Отлично, запишем Вас как Аналитика на проект.
Следуя плану, выявляем цели системы:
Это Задачи, а не Цели "автоматизации учета и контроля успеваемости студентов в течение семестра". Целю не может быть автоматизация, т.к. автоматизировать можно так, что народ будет в 10 раз больше работы делать. Целями может быть:
1. Уменьшение затрат времени,ресурсов и т.д.
2. Увеличение чего-то
3. Получение новой возможности или избежание чего-то вообще.
Читаем про Цели на страничке Boatman:
http://boatmanshome.ru/cgi-bin/page.pl?1goal.page
Так же прежде чем ставить цели желательно выявить проблемы, которые сейчас есть, и потом уже для чего (ПОЧЕМУ - этот вопрос задается когда выявляются Цели) Эд захотел ИС "Аттестации студентов"
выявляем заинтересованных лиц.
Вы скорее описали Пользовательские Группы, т.е. тех людей, которые будут пользоваться будущей ИС. Я же здесь больше говорил про ЗЛ, т.е. описание всех тех, кто так или иначе заинтересован в проекте или на него влияет, включая меня и рецензентов :)
-
Проблематично будет конечно, когда все будут писать в форум свои сообщения. То есть я, планируя начать на выходных, уже имею перед глазами чей-то ответ (хотя, конечно, постараюсь его не читать).
Может быть будем выкладывать файлы Word (а вы будете в них комментарии ставить)? Так у нас и готовые документы на выходе получатся.
ИМХО дел хватит всем. Файл бум формировать чуть позже - как накопиться информация - а что же туда писать.
Нужно распределить зоны ответственности Аналитиков, т.е. кто за какой п. хочет отвечать (пока по Концепции)? Также все Аналитики могут вносить предложения и в чужие п., но отвественный будет за каждый п. один человек.
Так же нужно определить - кто готов формировать конечные файлы Концепцией и Спецификацией Тр., компилируя вместе все подтвержденные изменения Аналитиков?
И надо что-то придумать со сроками.
Да, сроки в такой ситуации сложно определить :) Но попробую:
1. до 25 января 2009 г. - формируем команду
2. до 15 февраля 2009 г. - пишем Концепцию
3. до 25 февраля 2009 г. - доформировываем команду на этап описания Спецификации Тр., если будут еще желающие
4. до 15 марта 2009 г. - пишем Спецификацию Тр.
5. до 1 апреля 2009 г. - вылизываем документы.
-
Обновил план, добавил даты:
http://www.uml2.ru/forum/index.php?topic=1106.msg11611#msg11611
Обновил участников:
http://www.uml2.ru/forum/index.php?topic=1106.msg11617#msg11617
-
ИМХО Шаблоны Документов нужно взять у Вигерса:
http://processimpact.com/goodies.shtml
1. Концепция (Vision and Scope Document)
Так же немного урезанный мой вариант на русском языке можно увидеть здесь:
http://www.uml2.ru/forum/index.php?topic=381.msg7336#msg7336
2. Глоссарий (у Вигерса в явном виде нет)
Можно посмотреть здесь:
http://www.uml2.ru/forum/index.php?topic=381.msg7336#msg7336
3. Спецификация Тр. к ПО (Software Requirements Specification - SRS)
Свой вариант выложу чуть позже.
Мы наверное скомбинируем документы Вигерса (SRS, Business Rules and Use Case Document) в один Документ
-
Кратко и лаконично про Концепцию написано здесь:
http://users.jyu.fi/~akataso/itks451/Lecture4.pdf
-
Я со своей позиции заказчика сделал многое имхо. Я обратился в фирму разработки uml.2 к ее менеджеру bas'у. Я предложил свои пожелания в некоторой вольной форме.
Теперь менеджер пытается организовать команду и запустить проект в производство.
Я как очень заинтересованное лицо ожидаю прогресса в этом деле и готов всячески сотрудничать, отвечать на вопросы и предоставлять необходимый материал.
Что, когда и как - в этом я не искушен, я ожидаю профессиональных действий с фирмы. Как ведется этот процесс мне не ведомо, я лишь догадываюсь. Я не владею терминалогией клиент-сервер, базы данных, СУБД и т.п. Но я, как мне кажется (что может быть и не так), сведущь в том как мы аттестуем студентов, как ставим им оценки. И готов этот материал предоставить.
Поскольку это игра и он-лайн игра, то я ожидаю каких-то вопросов на форуме, на которые буду отвечать в меру своей компетентности.
За процессом должны следить некие Наблюдатели, они мне неведомы, и хотя их комментарии я могу читать, но буду делать вид, что их я не знаю и не понимаю.
Предложения не от заказчика: Саша может организовать подраздел игры, в котором сделать ряд веток - исходные материалы, работа с заказчиком, собственно проект?
-
Во ты отмазался Эд :)
Я кстати был на твоей стороне, т.е. МП на стороне Заказчика, но похоже меня послали в другой лагерь :) Я в принципе не против и наверное так логичнее.
На счет разных подтем - ИМХО все так плотно переплетается (исходные данные, уточнения, результаты, их ревью, планы и т.д.), что разделять не имеет смысла, а то не будет полной картины у читателей. Я кстати в первом сообщении темы сделал ссылки на основные сообщения и буду их поддерживать:
http://www.uml2.ru/forum/index.php?topic=1106.msg11560#msg11560
-
Следующий шаг - это выявление ЗЛ (Заинтересованных Лиц), Проблем Заказчика и Целей разработки ИС.
Коллеги, на выходных попытался завершить данный этап. То, что получилось - во вложении.
По перечню ЗЛ - попытался выявить максимально большое их количество, может даже переборщил. :)
По проблемам - первая встреча с Заказчиком была очень непродолжительная по времени, и на ней, к сожалению, мне не удалось однозначно идентифицировать проблемы. По ним - вопрос.
Цели - выявил ряд целей исходя из информации, полученой на первой встрече. Думаю, остальные появятся после выявления оставшихся ЗЛ и определения проблем.
Жду ваши комментарии и корректировки.
-
По проблемам - первая встреча с Заказчиком была очень непродолжительная по времени
А когда была встреча и как она проводилась?
-
В моем понимании "первая встреча" с Заказчиком была
здесь - http://www.uml2.ru/forum/index.php?topic=1106.msg11612#msg11612 (http://www.uml2.ru/forum/index.php?topic=1106.msg11612#msg11612),
здесь - http://www.uml2.ru/forum/index.php?topic=1106.msg11613#msg11613 (http://www.uml2.ru/forum/index.php?topic=1106.msg11613#msg11613)
и здесь - http://www.uml2.ru/forum/index.php?topic=1106.msg11614#msg11614 (http://www.uml2.ru/forum/index.php?topic=1106.msg11614#msg11614).
:)
-
Вот у меня тоже вызывает большие непонятки ситуация с проблемами. Вроде все жили раньше без создаваемой ИС, даже весьма успешно справлялись, а сейчас надо выявить проблему.
А может быть не проблема повлияла на желание создать ИС? А, к примеру, желание снизить затраты, в данном случае с помощью экономии времени. Но как это увязать с проблемой?
-
По перечню ЗЛ - попытался выявить максимально большое их количество, может даже переборщил. :)
Вопросы, связанные с коректностью и правильностью анализа, я оставлю за рамками обсуждения, поскольку по моей роли это не свойственно.
Однако замечу, что вопросы прибыли могут, конечно, рассматриваться, но следует все-таки учесть, что получение прибыли или снижение затрат в рамках бюджетного вуза, довольно сложная цель и задача.
Если рассмотреть более широко с позиции министерства или агентства, в том смысле, что подобное решение внедряемое по всем бюджетным вузам в целом может сократить расходы, а значит уменьшить бюджетное бремя, то да это интересно.
Либо постановку нужно рассматривать с позиции коммерческого вуза.
Для бюджетного вуза, вероятно, более интересным является снижение трудоемкости на получение результатов, своевременность и актуальность получаемых результатов. Своевременность может быть тем аспектом, который позволяет получать требуемую информацию и оперативно реагировать на нее в борьбе за повышение качества образование, показателей вуза. Понимать, где возникают проблемы, пытаться понять почему.
1. Какова организационная структура ВУЗа, для которого разрабатывается данная Система?
Чаще линейная.
Если мы ориентируемся на учебный процесс то примерно такая:
1. Ректор
2. Проректор по учебной работе
3. Учебно-методическое управление (со своей структурой)
4. Отдел кадров студентов
5. Деканаты факультетов и институтов
6. Кафедры, возглавляемые заведующим
7. Преподаватели
Это вертикаль исполнительной власти
Помимо нее можно выделить также законодательную власть:
Ученый совет вуза - возглавляет ректор
Ученый совет факультета - возглавляет декан
3. Какое подразделение ВУЗа является Заказчиком Системы?
Учебно методическое управление
На остальное попытаюсь ответить позже
-
В любом случае, будь ВУЗ коммерческим или бюджетным всё равно, лицо принимающее решение должно будет понимать зачем вкладываются деньги именно в разработку ИС, а не в закупку новых компов для оборудовния дополнительных помещений. Показатели ВУЗа, качество образования - это показатели, которые трудно измерить, соответственно, будет практически невозможно дать оценку приносимых бизнес-эффектов внедрённой ИС. ИМХО. Но, наверное, это уже совсем другая история, не касаемая данной ветки форума...))
Ну а что касается интересов и целей для заказчика, то помимо эффектов от использования ИС, ещё надо учесть активы и права собственности.
Для подрядчика - это создание команды сопровождения, создание референса (постконтрактная фаза сотрудничества, позволяющая при необходимости показать ИС в деле потенциальным заказчикам).
-
У меня небольшая проблема... ::) В реальной жизни я не участвовал ни в одном подобном проекте, поэтому, для меня данный форум практически как обучение. В связи с чем, прошу снисхождения, если я где буду неправ или буду заблуждаться. На данный момент я в процессе обучения на одних курсах и пока, в условиях дефицита времени, могу опираться только на получаемые знания.
Моё имхо по поводу заинтересованных лиц в файле "Материал для Концепции.doc" от buster'a.
Спонсор в проекте должен быть один - заказчик. Ни какого спонсора со стороны исполнителя быть не должно.
Так же и менеджер должен быть один - руководитель проекта, как правило, имхо, это человек со стороны исполнителя, обеспечивающих выполнение работ.
Интересы менеджера проекта со стороны исполнителя - "Уговорить Заказчика на максимально приемлемый срок, на постановку более простой задачи.Выполнить и сдать проект, уложившись в срок и бюджет." Я считаю, что интерес один - получить прибыль, путём достижения поставленной цели. А согласование деталей проекта, бюджета, сроков - это наверное уже не руководство проектом, а процесс переговоров до подписания контракта.
Управляющий комитет - "Лица, обладающие правами и возможностями принимать ключевые для проекта решения" По-моему, это и есть спонсор, кто платит - тот и решает.
-
В качестве реплики, не как Заказчик, но как просто проходящий.
Знаете ли Вы, что В любом случае, будь ВУЗ коммерческим или бюджетным всё равно, лицо принимающее решение должно будет понимать зачем вкладываются деньги именно в разработку ИС, а не в закупку новых компов для оборудовния дополнительных помещений. Показатели ВУЗа, качество образования - это показатели, которые трудно измерить, соответственно, будет практически невозможно дать оценку приносимых бизнес-эффектов внедрённой ИС.
это далеко не так. Знаете ли Вы, что финансирование вуза целиком зависит от его показателей. Одним из таких показателей может быть и качество образование, которое в частности складывается из успеваемости студентов. Умение упраялть этим показателем - значительная причина на интерес к подобного рода программе. Компы сами по себе прибыли не дают.
Но я согласен, что мы можем пренебречь таким фактором, хотя я вам скажу откровенно. Если полагать ректора таким лицом, то я вам скажу, что ректор, это самое последнее лицо, которое реально заинтересовано в системе. Не заинтересованы в этом и проректоры, и даже деканы. Все начинается с того, что кто-то из преподавателей (передовых) в силу своей креативной природы начинает что-то создавать и внедрять в своем окружении. Иногда по счастливой случайности рядом вдруг оказывается кто-то из проректоров, которые видят - ба да это хорошо. И тогда вот начинается !! Понимаете, ни прибыль, ни снижение затрат. Движущимся фактором становится нечто иное, иногда как это так в соседнем вузе есть, а мы что? Или мы что - передовой рубеж цивилизации или арьегард? Как вы полагает такое может быть важным мотивом?
Потому в данном конкретном случае игра продолжается, но пытаться определить некие бизнес-цели может оказаться и надуманной задачей
-
2. Какие подразделения ВУЗа, помимо перечисленных в таблице, и какие внешние по отношению к ВУЗу лица затронет (решит/создаст проблемы, предоставит/ликвидирует возможности) создание Системы? В чем будет выражено это влияние?
Я как Заказчик, да и просто человек в расстерянности от вопроса.
Хотя...
интерес может быть у родителей
Один раз в 5 лет каждый вуз проходит аттестацию. Потому проведение самоаттестации - в нашем случае учет успеваемости и внедрение широкой системы тестов, может быть полезным
Но на мой взгляд, пока говорить о чем-то из вне, сложно. Или стоит более просто сформулировать вопрос
1. Что послужило причиной для создания данной Системы?
Интерес к информационным технологиям
Престиж обладания оными
Желание снизить рутинность работы связанной с учетом успеваемости
Желание снизить сроки получения итоговой информации, повысить достоверность
Унифицировать систему документооборота, перейти на безбумажную технологию (бумаги тратится море)
ээ не могу пока придумать, просто вот захотелось и все...
2. Какие проблемы призвана решить разрабатываемая Система?
унифицировать систему оценки знаний
сделать эту систему более прозрачной для преподавателей, студентов и их родителей и своевременной (т.е. обеспечить уникальность информации в пределах 1 недели)
повысить степень самоконтроля знаний студентами через систему автоматизированных тестовых заданий
может еще что придумаю если поможите
-
Начну немного критиковать:
1. ЗЛ
1.1. Я бы всех со стороны Исполнителя объединил в один юнит - проектная команда со стороны Исполнителя, т.к. вряд ли у них (у нас) может возникнуть конфликт интересов, во всяком случае относительно этого проекта. Следовательно и интересы д.б. общие.
1.1. Интерес "Уговорить ..." - очень сомнительный это скорее подзадача задачи "Выполнить и сдать проект, уложившись в срок и бюджет"
1.2. Спонсор проекта со стороны Заказчика - это для нас скорее всего "Учебно методическое управление", т.е. непосредственный Заказчик
1.3. Менеджер проекта со стороны Заказчика, Управляющий комитет - таких ролей вроде у нас нет
1.4. ИМХО Учебно-методический отдел = Учебно методическое управление, так Эд?
1.5. У Учебно-методического отдела, Деканата, Преподавателя и т.д. нет интереса получить ИС, у них есть интерес просто Сократить, Уменьшить, Получить ...
1.6. В Интересах скорее нужно обозначить задачи, т.е. зону интересов ЗЛ, а с п. 7 идет попытка выявить Цели. Или везде пишем Цели ЗЛ или везде их Задачи
1.7. Как я понял Эда, то в данной ИС заинтересован еще Проректор по уч. работе. Что он хочет?? Какие его функции в описанном Эдом БП? "А также их (Студентов) Родители" (с)
1.8. Так же не понятно в чем заинтересованы и как задействованы у нас:
* Отдел кадров студентов
* Кафедры, возглавляемые заведующим
* А может еще затронуть Минобразование?
2. Проблемы
2.1. Эд дал не мало пищи для размышления нужно зафиксировать его проблемы.
2.2. Эд, у меня еще к тебе вопрос - Какие сейчас возникают проблемы в описанном тобой процессе?
* М.б. где-то тратится много времени??
* Какая-то информация не фиксируется или не может быть получена??
* Не известны допущенные\штрафники\отчисленные
* Что-то требуется для предоставления выше а у Вас нет или трудно получить??
* Да и просто с какими проблемами сталкиваетесь когда аттестуете Студента в течении сессии и в конце??
* Какие есть самые рутинные операции у тебя и других ЗЛ?
* М.б. что-то нужно предоставлять Студентам?
* Что бы хотели улучить в существующем процессе? Чего не хватает сейчас?
2.3. Эд ,что ты понимаешь под "унифицировать систему оценки знаний". Что это такое в твоем понимании и для чего нужна она Вам?
2.4. Эд, для чего нужно "повысить степень самоконтроля знаний студентами через систему автоматизированных тестовых заданий"? Самоконтроль - это же не самоцель?!
2.5. Эд, что Вам даст "Престиж обладания оными"?
2.6. Почему или для чего м.б. полезным "проведение самоаттестации - в нашем случае учет успеваемости и внедрение широкой системы тестов"??
3. Цели
3.1. Если мы говрим о Целях, то очень желательно указать качественные или количественные показатели улучшения. Например - "Снизить время фиксации результатов работы группы Студентов до 5 минут"
3.2. Эд, каким образом может данная ИС повысить качество образования?
3.3. Эд, чтобы Вы хотели такое получить (или ИС делала бы), чтобы сделать Вас (тебя в частности) абсолютно счастливым в рамках описанного тобой процесса?
-
я вам скажу, что ректор, это самое последнее лицо, которое реально заинтересовано в системе. Не заинтересованы в этом и проректоры, и даже деканы. Все начинается с того, что кто-то из преподавателей (передовых) в силу своей креативной природы начинает что-то создавать и внедрять в своем окружении.
Абсолютно логично, это примерно то, о чём я говорил. Как говорится, нафига козе баян, в смысле зачем ректору тратиться на эту ИС. И как доказать ректору, что ИС нужна ВУЗу. И всё же, при этом вполне реальна "инициатива снизу" и какие-то свои подходы окружения лиц принимающих решения для получения финансирования. :)
-
2. Проблемы
* М.б. где-то тратится много времени??
Ну в принципе да - 35 кафедр, более 200 учебных групп (разных курсов), в каждой группе до 30 человек, но в среднем возьмем 23. Преподаватель в течение до контрольной точки ставить результат в журнал, потом подсчитывает суммируя, выставляет в Контрольный лист, Кнтрольный лист передается в деканат, деканат суммирует все это, передает в УМУ там вновь суммируют по деканатам - т.е. при ручной обработке тратися масса времени от недели и более. А следует заметить, что сейчас у деканатов масса и другой работы, а про летнюю сессию уже и говорить не имеет смылса - все на ушах стоят: два потока бакалавры, дипломники - - естественно если данные от преподавателя сразу попадают в нужные места, где их просто использую а не подситывают контролирую и учитываю - это облегчение. И очень серьезно
А обработка тестов - это тоже серьезно, в налаженной системе конечно будет существенная экономия времени, бумаги, да и не требуется предельное внимание и концентрация, ошибаться буду реже и воновника легче определить, ведь данные вводит преподаватель
* Какая-то информация не фиксируется или не может быть получена??
например посещение лекций - никак не фиксируется сейчас только через журнал старосты, но преподаватель или вынужден сам это контролировать или вообще не имеет этойинформации, но представьте контроль за потоком из 5 -10 групп - не перекличку же устраивать
* Не известны допущенные\штрафники\отчисленные
Да здесь есть проблема - например были случая когда студенты вписывали в зачеткизачеты и шли получали допуск, а потом шли на экзамены были скандалы и прочее, а у деканата пока он не получит обратно ведомость после экзамена совершенно нет уверенности что все окей
* Что-то требуется для предоставления выше а у Вас нет или трудно получить??
все есть, просто получать эти цифры долго
в частности есть форма 3НК предоставляемая в министерство и там же может быть обнаружена. У кого есть системы автоматизации тратя день на составление отчета, а вот мы напрример месяц и не уверены в достоверности каждой цифры
* Да и просто с какими проблемами сталкиваетесь когда аттестуете Студента в течении сессии и в конце??
ну тут вроде особых проблем нет, скорее проблемы истории данных: например студент восстановился и не ходит на занятия а в списке есть? потом узнаешь что ему перезачли, а почему бы преподавателю не получить эту информацию сразу или просто сразу чтобы такого студента в списке не было, а то часто приходится тянуть такую мертвую душу
* Какие есть самые рутинные операции у тебя и других ЗЛ?
ну я вообще вся свою деятельность автоматизирую, и часто рад этому. Потерялся журнал посещений, оценки или еще что, а уменя все под рукой, пришел студент после академа и утверждает что сдал экзамен ждо хрипоты - востонавливаю историю и говорю врешь братец не было такого , в оббщем я такой вот передовой мне трудно ответит, но вообще есть преподаватели за автоматизацию и категорически против
* М.б. что-то нужно предоставлять Студентам?
Да студенты с удовольствием смотрят свой рейтинг, котролируют преподавателя, напоминают ему если он забыл выставить или требуют объяснений почему вот столько а не столько и каков прогресс в целом
* Что бы хотели улучить в существующем процессе? Чего не хватает сейчас?
мне сложно ответить, процесс в целом нормальный улучшать что-то не надо, просто переходим на новые технологии вот все - это же нормально время такое
2.3. Эд ,что ты понимаешь под "унифицировать систему оценки знаний". Что это такое в твоем понимании и для чего нужна она Вам?
Это означает, что по предмету информатика у всех единое количество заданий и каждое задание одинаково оценивается
Это также означает единую систему по сосбтвенно оценки (пусть как рекомендации но все-таки доступную для изучения) Студент должен знать почему ему поставили скажем 32 балла и снизила почему на каком основании.
2.4. Эд, для чего нужно "повысить степень самоконтроля знаний студентами через систему автоматизированных тестовых заданий"? Самоконтроль - это же не самоцель?!
А чтобы студент мог видеть за что ему ставят оценки и как, и видел за счет чего он может повлиять на свою оценку
2.5. Эд, что Вам даст "Престиж обладания оными"?
Очень много, если в вузе используют информационные технологии в управлении - это и престижно и повышает рейтинг и повышает благосклонность власть имущих
2.6. Почему или для чего м.б. полезным "проведение самоаттестации - в нашем случае учет успеваемости и внедрение широкой системы тестов"??
см выше все по тем же причинам - повышение показателей
3. Цели
3.1. Если мы говрим о Целях, то очень желательно указать качественные или количественные показатели улучшения. Например - "Снизить время фиксации результатов работы группы Студентов до 5 минут"
Я бы не стал говорить стол категорично, как проверить достижение цели можно указать и в критерии
3.2. Эд, каким образом может данная ИС повысить качество образования?
Это мое мнение, но
1. анализ статистики и тенденций
2. анализ причин снижения или повышения качества (хотя бы по оценкам)
3. анализ этого опыта и широкое его распространение
Мне кажется это самая важная миссия вуза - давать качественное образование, а что же оно есть - вот сстема и можетпомочь ответить на вопросы
3.3. Эд, чтобы Вы хотели такое получить (или ИС делала бы), чтобы сделать Вас (тебя в частности) абсолютно счастливым в рамках описанного тобой процесса?
Понимаешь тут нужно смотреть с разных точек зрения - со стороны руководства разного звена - это снижение рутинности получения отчетов, быстрота их получения, разные формы представления отчетов, актуальность и достоверность
У преподавателя пока особых счастьев нет, но возможно - тестирование или всякие системы самоконтроля снимут бремя с преподавател, дадут ему больше возможности для творчества
Также возможность получения информации по студенту в общем историческом срезе тоже позволяет более гибко с ним работать и т.д.
Например мне говорят вот этот студент хорош ой как хорош, окей, я вынужден идти в деканат, например чтобы узнать о нем все, в деканате этого не любят время тратить еще, а тут я залез в систему на правах препода я могу например посмотреть список дисциплин и оценки и сделать СВОЙ вывод, или узнать кто им читал предмет такой-то и придти и сказать этому другому чтобы он мне студентов не портил, а то жалобу напишу :) ну в таком духе
Вообще как не странно преподавательская среда очень на самом деле закрыта и консервативна, и разобщена до ужаса :(
-
Мне кажется я слишком много работаю как Заказчик - надо взять отпуск
-
Эд,
Спасибо за детальные объяснения, немного стал просматриваться свет в окошке. Все же ИС нужна не только для престижа, но и для достижения конкретного результата :) А уходить на покой рано еще рано, у Аналитиков должны возникнуть ИМХО уточняющие вопросы по твоему последнему посту + нужно оформить результаты последних уточнений.
С одной стороны сложно в таком формате выуживать Требования, а с другой все остается на века :)
Господа Аналитики,
1. Как-то не увидел в работе mouse, да и StUtk и veta не очень активны :) Моя аська всегда открыта - задавайте вопросы если что-то не понятно.
2. ИМХО нужно оформлять первую часть Концепции (ЗЛ, Проблемы, Цели)
3. Кажется у нас наклевывается также:
* Возможность Анализа истории Студента по допускам\предметам\Преподавателям\академам\т.д.
* Возможность предоставления Отчетности для Деканата\Кафедры\Руководства ВУЗа и для для Минобразования
* Возможность учета защиты Диплома\гос. экзаменов\Бакалавров, кстати а что-то нужно для Аспирантов?
-
bas, 474, Эдуард, спасибо за комментарии, развернутые ответы и советы и ссылки.
в крайнем случае завтра утром выложу свои мысли на тему ЗЛ, проблем и целей.
Вопрос: в каком виде это будет удобнее это выкладывать? чтобы никого не сбивать с мыслей истинных... :)
-
Т.к. разделение труда (кто-то отвечает за ЗЛ, кто-то за Цели и т.д.) народ не воспринял, то имеет смысл каждому выкладывать свой вариант мыслей по поводу ЗЛ, Проблем, Целей и т.д. в виде приложенного файла.
Как накопим достаточно обработанной информации то нужно ее агрегировать и записывать в шаблон Концепции от Карла Вигерса (http://www.uml2.ru/forum/index.php?topic=1106.msg11645#msg11645), естественно, переводя попутно разделы.
-
Честно говоря, не вполне представляю, как на данном этапе можно распараллелить работы. Ведь сейчас каждая работа вытекает из следующей.
Но и в том виде, в каком мы работаем сейчас, тоже получается не очень удобно. Заказчик отвечает сразу на вопросы ото всех и очень часто (потому и устал). Думаю, надо определить промежуточный milestone, к которому мы на основе имеющейся информации сформируем какое-то общее видение и зададим окончательные вопросы. Одним письмом. До milestone рецензенты должны будут минимум один раз дать свое экспертное мнение.
-
Согласен.
Давайте так:
1. До выходных, т.е. до 23 января включительно, каждый описывает свой вариант ЗЛ, Проблем и Целей проекта, выкладывает их на форуме в виде прикрепленного файла + формулирует свои вопросы прямо внутри прикрепляемого файла
2. До среды, т.е. до 28 января, рецензенты смотрят варианты и говорят что оставить, а что убрать или подкорректировать.
3. До след. выходных, т.е. до 30 вкл., я задаю сформулированные Аналитиками вопросы Эду и Эд отвечает.
4. До 2 февраля, все Аналитики правят свои записи и выкладывают.
5. До 8 февраля, кто-то из Аналитиков агрегирует все записи Аналитиков в документ Концепция
6. Далее смотрим что делать дальше.
Так пойдет?
-
Весьма логично :)
-
договорились =)
-
Я пока вижу одну несостыковку.
Для того, чтобы
5. До 8 февраля, кто-то из Аналитиков агрегирует все записи Аналитиков в документ Концепция
надо еще
2.4. Выявление потребностей
2.5. Описание фичей ИС
2.6. Контекстная Диаграмма ИС
2.7. Описание рисков
2.8. Составление плана реализации ИС
-
Да сроки, как мне кажется, не жёсткие, при необходимости можно сдвинуть.
А агрегрировать можно хотя бы пункты, а наличие всех пунктов - это практически и будет уже полный документ.
-
bustor,
Пока речь идет только о ЗЛ, Проблемах и Целях и их агрегации в Концепцию.
Дальше составим план на остальные пункты. Причем никто не мешает писать свои мысли по остальным пунктам Концепции, но они пока никак не будут контролироваться и проверяться.
-
Понял. Не умничаю. :)
-
Если с подробным планом (http://www.uml2.ru/forum/index.php?topic=1106.msg11693#msg11693) на пп. 2.1-2.3 основного плана (http://www.uml2.ru/forum/index.php?topic=1106.msg11611#msg11611) все согласны, то так и действуем.
Ждем от Аналитиков первого релиза Документа по описанию ЗЛ, Проблем и Целей к 23 января 09.
-
Уважаемые разработчики, не сочтите за нотацию, но ... с точки зрения Заказчика важным является лишь конечный продукт, удовлетворяющий потребности собственно Заказчика. Естественно, что разработчик стремится получить прибыль от своей деятельности. Однако в конечном итоге все будет определяться качеством готового продукта.
Я понимаю, что в нашем случае готового продукта вероятнее всего не будет, но будет некое модельное его представление максимально понятное окружающими и приемлемое для Заазчика (с учётом того, что Заазчик тоже персонаж игры не обделенный толикой нужных для понимания знания).
Я надеюсь, что итогом нашей игры может быть действительно интересное проектное решение. И Заказчику придется хорошо потрудится в свою очередь (и я к этому готов).
-
Пишу в отдельном посте дополнительную информацию к размышлению. Как вы возможно знаете, а если нет, то узнайте. Россия присоединилась к болонской конвенции. К сожалению от болонской конвенции больше вреда, чем пользы. Вред заключается в том, что конвенция эта ориентирована на интересы Европейского союза и совершенно не затрагивает (она даже ими не интересуется) интересы России. Тем не менее это реальность.
Реальность заключается в двухуровневой системе образования: балакавриат и магистратура. Система ориентирована на кредиты, которые впрочем не вызывают никаких проблем и легко транспонируются на наши учебные часы.
Насколько мне известно многие вузы используют так называемую рейтинговую систему, которую не следует смешивать с понятиями кредитов. Еще раз подчеркну понятие кредита больше пересекается с понятием часы, хотя включает в себя и понятие оценки.
Уже сейчас рейтинговая система снижает влияние экзаменационной оценки, хотя она и остается высока. В моем случае 50% от общей оценки по дисциплине в семестр.
Также все энергичнее внедряются так называемые тестовые экзамены первой ступени. Т.е. студент сдает экзамен в виде тестов, получает некий балл скажем 30. Но для получения высокой оценки (отличной или хорошо) он идет на второй этап экзаменов. Правда это скорее не узаконенная процедура.
Также в течение семестра преподавателей мотивируют использовать тестовые задания для контроля знаний и успеваемости.
Кроме того есть тенденция, по которой количество часов для самостоятельной работы увеличивается, а аудиторной снижается, в том числе и за счет внедрения новейших информационных технологий.
Еще возможный аспект - это возможность выбора индивидуальной траектории обучения, которая в некотором роде и сейчас имеет место быть, но скажем для группы в целом и по выбору со стороны преподавательского персонала. Однако уже есть такие вузы, в том числе и дистанционные, которые позволяют студентам в определенных рамках определять список предметов для изучения, график их изучения, способ зарабатывания тех самых кредитов (читай необходимое число часов)
Если представить себе некий университет подобного вида в идеальной его реализации, то фактически существующее планирование занятий, подготовка расписаний должна уже ориентироваться не на понятие группа, поток, курс, а ориентироваться на каждого человека. Это возможно только в том смысле, если принимать во внимание лозунг Болонской конвенции: "Обучение всю жизнь". По сути Болонская конвенция напрямую рассматривает образование как отличный и серьезный бизнес и определяет для него жесткие и честкие условия игры...
-
В прилагаемом файле моя версия.
-
мой вариант
-
мой вариант
-
Спасибо господа Аналитики, что выполнили все в соответствии с планом ;) Я как МП очень доволен :)
На выходных посмотрю и выставлю свои замечания. Также к процессу ревью прошу присоединиться господ рецензентов и Заказчику.
-
Спасибо уважаемые аналитики.
Думаю я могу сказать, что в целом вы понимаете нужды заказчика, мы, думаю, вполне пришли к единому понимаю.
Я взял на себя смелость добавить некоторые комментарии в ваших работах.
-
Сорри, на выхах не было времени посмотреть - сегодня-завтра посмотрю и прокомментирую.
З.Ы. просьба в файлах писать имя\ник, кто его сделал, а то когда печатаешь не понятно ...
-
Прошу прощения, неожиданная болезнь временно выбила меня из стройных рядов рецензентов. Как только оживу - сразу вернусь
-
Я высказал свои замечания.
Еще общие пожелания:
1. Нумеруйте все цифрами плиз, чтобы было возможно ссылаться
2. В документе ведите историю изменений (кто, что сделал и когда)
3. Хорошо бы написать количественные показатели у каждой цели
4. Хорошо бы чтобы Вы сами себя проверили и протрассировали все эти разделы между собой. Т.е. из каких интересов ЗЛ вытекают какие проблемы, и из каких проблем вытекают какие цели. Чтобы понять что мы выявили все проблемы из интересов ЗЛ и что все цели разработки ИС покрывают наши (вернее Заказчика) проблемы.
Далее по планам:
Эд уже ответил на вопросы. Нужно исправлять Концепцию у каждого (до конца этой недели) и потом формировать общую Концепцию (до след. среды).
-
3. Хорошо бы написать количественные показатели у каждой цели
Правильно ли я понимаю, что количественные показатели мы должны выявить на основе общения с Заказчиком?
-
Ну а как по другому? :)
-
Выкладываю два файла -
1. поправленная Концепция по ЗЛ, проблемам, целям с историей изменений.
2. аналогичный файл с "принятыми" изменениями, для удобства чтения
-
Добрый вечер! Мои исправления концепции, история и несколько вопросов.
-
29, у нас в университете проходила научно-методическая конференция. И что интересно, на пленарном заседании один из вузов делился своим опытом в области построения системы качества. Так вот, следуя естественно западным влияниям, где все хотят поставить на поток, конвеер, и финансовую основу, нас ориентируют на практически CMMI. Т.е. каждый вуз по идее должен стремится к повышению качества даваемого образования. При этом согласно модели ИСО 9000, а также ENQM которая сильно смахивает на CMMI, для прехода от так называемого неконтролируемого качества к контролируемому, управляемому и воспроизводимому, следует выполнить ряд мероприятий. Не последнее место в этом отдается
1. сбору сведений об успеваемости
2. проведение постоянной самоаттестации
3. разработка сертифицированных тестов (а она требует прокатки на стедентах)
4. подготовка к внешней аттестации
и т.п.
Что это дает?
1. бизнес получает нечто понимаемое и измеримое. Т.е. если университет имеет скажем сертификат что у него по модели CMMI такой-то уровень, то работодатель будет стремится купить студента из этого вуза
2. родитель будет стремится чадо устроить в этот вуз
3. ну продолжать можно ...
Мысль понятна? Цель виднеется? :)
-
Прошу прощения за задержку. Болезнь подкралась незаметно.
В прилагаемом файле моя версия.
-
Коллеги,
Если никто не против, то девушки в соседней ветке (http://www.uml2.ru/forum/index.php?topic=1124.0) будут формировать модель нашего текстового описания требований к ИС "Аттестация студентов".
Пока мне не совсем понятно какие модели они будут использовать, но звучит хорошо :)
З.Ы. сегодня-завтра посмотрю описание ЗЛ, Проблем и Целей и можно двигаться дальше.
З.З.Ы. Эд, нужно бы ответить на вопросы Аналитиков!
-
Конечно не против...)
-
З.З.Ы. Эд, нужно бы ответить на вопросы Аналитиков!
А вопросы нельзя поместить здесь на форуме?
-
А можно мне тоже с Вами, как аналитику включиться в данный проект, Сорри за опоздание :(
-
LeX,
Мне кажется Вам лучше присоединиться на след. этапе - написании ТЗ.
-
Я не против
-
Не могу открыть посмотреть файлы Veta и bustor. Opera распознает их как index.php
-
Не могу открыть посмотреть файлы Veta и bustor. Opera распознает их как index.php
У меня тоже бывали с оперой такие проблемы, я при сохранении (правая кнопка мышки по ссылке, потом "Save linked content as...") сам писал имя файла и расширение .doc
вроде помогало
-
У меня тоже бывали с оперой такие проблемы, я при сохранении (правая кнопка мышки по ссылке, потом "Save linked content as...") сам писал имя файла и расширение .doc
вроде помогало
Помогло.
Вопросы Veta:
Уменьшить объем работы преподавателей по проведению и проверке тестов.
Каким образом может быть оценено уменьшение объемов?
Преподаватель должен подготовить на группу тестовые задания. Пусть они готовы, но ему нужно их распечатать и выдать студентам. Студентов в группе 25 человек групп 5. Тестовый контроль производится скажем 6 раз в семестре по 6 модулям.
Вот и считаем: 25х5Х6 = 750 листов бумаги (при условии что тест уберется на лист формата А4)
На проверку каждого теста нужно затратить скажем минут 5 при использовании готовых шпаргалок, а ведь вопросы могут формироваться случайным образом, потому может потребоваться больше времени. Итого в семестр только на проверку потратим 750х5 = 3750 минут или 62,5 часа - это немало.
К тому же следует анализировать тесты на измеряемость, т.е. составялть сводные отчеты по прохождению тестов и т.п.
Если будет система - тогда подсчет результатов осуществялется автоматом, статистика, выборка и т.п. тоже будет осуществлена быстро. Т.е. преподаватель потратит меньше времени и не на просто рутинную проверку, а на творческий анализ и улучшения качества тестов.
Тем более если преподаватель зхочет сертифицировать тесты, то ему очень нужна статистика, получение которой более трудоемко, чем сама проверка
Улучшить качество собираемых статистических и аналитических (по успеваемости, по рейтингам студентом, по предметам и т.п.)данных; каких данных?
Ну неочень понятно, что такое качество данных. Достоверность и своевременность другой разговор. Что собираем: оценки за занятие, посещаемость студентов, оценки за тесты. Что получаем: рейтинг на милстоун и в конце семестра, количество пропусков для принятия мер, результаты тестирования включаемые в общий рейтинг и использующиесядля принятия решения по успеваемости студента
-
Коллеги, мне кажется активность в этой ветке идет на спад. Что нас держит и не дает идти дальше?
-
Да-да, это я виноват, сорри :(
Предлагаю идти дальше:
* Описать основные функции (фичи, features) ИС
* Нарисовать контекстную Д ИС
* Нарисовать Д бизнес-объектов или сущностей предметной области
Замечания есть, но небольшие, попозже выложу, ща времени совсем нет :(
ИМХО сейчас имеет смысл всем идти своим путем, т.е. писать каждому свой документ Концепция, а потом посмотрим - сливать вместе или нет. Прошу также уже Концепцию оформить в соответствии с шаблоном, кто этого еще не сделал.
-
Предлагаю идти дальше:
* Описать основные функции (фичи, features) ИС
* Нарисовать контекстную Д ИС
А есть ли примеры? Как по сути, так и по форме, просто для меня это всё впервые.
-
Ну про контекстную Д написано немного здесь:
http://en.wikipedia.org/wiki/System_context_diagram
Про фичи немного тут:
http://www.ibm.com/developerworks/rational/library/4166.html
и в предоставленных шаблонах
И еще поиск в инете вроде работает ...
-
Добавил еще в наши следующие шаги по Концепции еще один пункт. Теперь дальнейший план выглядит так:
* Описать основные функции (фичи, features) ИС - до 13 фев 2009 (проверка на выходных)
* Нарисовать контекстную Д ИС - до 13 фев 2009 (проверка на выходных)
* Нарисовать Д бизнес-объектов или сущностей предметной области - до 20 фев 2009 (проверка на выходных)
-
А временные рамки?
-
добавил дату сдачи в пред. пост
-
У меня вопрос по поводу границ нашей системы: мы будем реализовывать все, что описано в проблемах/целях? Мне кажется, это затянется надолго.
Документооборот, Автоматизированные тесты, Система критериев оценки успеваемости - все это нам нужно?
-
МЫ можем в концепции описать всё. Но в ней же указать план по реализации и например на первый релиз описать уже подробнее спецификацию требований. Так, например, сделано у Вигерса в Vision.
-
Но вообще вопрос bustor'а был больше к Эду. Эд, разъясни плиз - что делаем, а что убираем?
-
Но вообще вопрос bustor'а был больше к Эду. Эд, разъясни плиз - что делаем, а что убираем?
Для примера, можно оставить систему документооборота между кафедрами деанатами и учебным отделом по вопросам успеваемости, посещения студентами занятий и можно добавить учет педнагрузки преподавателей
-
Вчера вечером решил заняться выявлением features и разработкой контекстной диаграммы. То, что получилось - во вложении. Прошу покритиковать. :)
-
На первый взгляд мне понравилось. Посмотрю позже поподробнее.
-
Вот мои замечания по последним версиям Концепции.
Жду Ваших шагов, уважаемые Аналитики. И хорошо бы начать формировать нормальный Документ Концепция, как сделал bustor.
-
Есть ли вопросы к заказчику? Мне думается они появятся уже на этапе описания требований и постановок на проектирование и разработку. А вот мне хочется посмотреть на инструмент, хотя бы прототип. Тогда пожелания появятся косяком
-
Ребята, признаюсь честно, не читал весь топик с самого начала, но у меня есть небольшая идея.
Напишите вы концепцию, потом Варианты использования и другие требования, а кодировать никто не будет. Так вот, если вы будете писать требования к UI, то вместо кодирования можно сделать кликабельный интерфейс, в котором описать бизнес-логику, те щелкнул туда, появилось то, щелкнул туда - это. Такой прототип можно использовать как фикцию сдачи продукта заказчику, и соответственно, смоделировать процесс управления изменениями. Сейчас есть много программ для создания подобного рода прототипов. Недавно покопал одну - мне очень понравилось. Причем в некоторых из них даже есть что-то типа базы данных :)
Извините за оффтоп, просто мысли в слух.
-
Виталий,
Ты конечно умный, не все же такие :) Ты хоть название сказал бы программки, кот. тебе "очень понравилось" ;)
-
Ты хоть название сказал бы программки, кот. тебе "очень понравилось" ;)
Вот список программ.
http://c2.com/cgi/wiki?GuiPrototypingTools
Я себе поставил триалку GUI Design Studio и посмотрел демку iRise Application Simulator, тоже понравилось. Если покопать поглубже, то можно наверное что-нибудь бесплатное найти
-
Поправил замечания,
добавил функциональные возможности, контекстную диаграмму.
-
Поправил замечания,
добавил функциональные возможности, контекстную диаграмму.
УМУ - учебно-методическое управление
2.2.1 Ручное составление большого количества отчётов требует много времени и других ресурсов, повышенной концентрации составителей.
Проблема не в ручном составлении - это причина. Проблема тут скорее большое количество ошибок, вследствии составления отчетов вручную, что вызывает переутомление, требует много времени и ресурсов (бумаги например)
-
поправил
-
StUtk,
Спасибо. Посмотрю.
Коллеги Аналитики,
Будем делать то, что Виталий предложил? Хватит сил? Мне кажется идея очень хорошей!
-
Коллеги Аналитики,
Будем делать то, что Виталий предложил? Хватит сил? Мне кажется идея очень хорошей!
Так как я люблю на досуге порисовать, могу выступить в роли дизайнера и "кодера", и по вашим спекам попытаться сделать такое "кликабельное чудо". Заодно проверим качество спеки. Что скажете?
-
Так как я люблю на досуге порисовать, могу выступить в роли дизайнера и "кодера", и по вашим спекам попытаться сделать такое "кликабельное чудо". Заодно проверим качество спеки. Что скажите?
Я как Заказчик очень рад
-
А я, как МП, еще больше рад, что нам выделили супер Дизайнера с другого проекта, чтобы сдать проект во время ;)
-
А я, как МП, еще больше рад, что нам выделили супер Дизайнера с другого проекта, чтобы сдать проект во время ;)
:) Договорились... Жду спеки и сроки...
-
Добрый вечер! Идея с интерфейсом очень интересна!
Прошу прощения за длительное отсутствие... Выкладываю свою концепцию. Средств для выполнения контекстной диаграммы пока нет, к сожалению.
-
Средств для выполнения контекстной диаграммы пока нет, к сожалению.
Так контекстную Д можно нарисовать и с помощью Ворда. А вообще бесплатных средств ЮМЛ моделирования много, например:
Star UML
Visual Paradigm for UML Community Edition
-
Коллеги Аналитики,
Будем делать то, что Виталий предложил? Хватит сил? Мне кажется идея очень хорошей!
С удовольствием!
-
Так как поступили вопросы по ДБО (Диагармме Бизнес объектов), то примеры можно посмотреть здесь:
1. Раздел "Разработка концептуальной модели данных"
http://www.intuit.ru/department/se/devis/12/3.html
2. Рис. 5.6. Статическая модель процесса закупки товара в магазине
http://www.intuit.ru/department/itmngt/entarc/5/5.html
-
Исправил Концепции veta и StUtk.
-
Жду ДБО и если Заказчик нам подписываем Концепцию, то переходим к Спецификации Требований.
-
Коллеги, мой вариант во вложении.
-
Скажите пожалуйста, коллеги и знающие люди, является ли исполнитель реализации ИС заинтересованным лицом(ЗЛ)? Если да, то какие у этого ЗЛ могут быть потребности? Цели, задачи вроде ясны, а вот потребности...?
-
Скажите пожалуйста, коллеги и знающие люди, является ли исполнитель реализации ИС заинтересованным лицом(ЗЛ)? Если да, то какие у этого ЗЛ могут быть потребности? Цели, задачи вроде ясны, а вот потребности...?
В общем целом является.
Престиж, удовлетворение от внедрения актуальной задачи, причастность, значимость, сопричастность...
Мало?
-
2 Galogen:
Я тоже считаю исполнителей заинтересованными лицами, а вот с потребностями как раз были проблемы при написании концепции ИС "Аттестация студентов". Вот с престижом я согласен, такая потребность может быть, а вот причастность, удовлетворение... мне кажется это романтика...) Может я слишком меркантилен? :)
---
Мой вариант концепции в файле.
-
2 Galogen:
Я тоже считаю исполнителей заинтересованными лицами, а вот с потребностями как раз были проблемы при написании концепции ИС "Аттестация студентов". Вот с престижом я согласен, такая потребность может быть, а вот причастность, удовлетворение... мне кажется это романтика...) Может я слишком меркантилен? :)
Ну смотри. Престиж в чем? Престиж в солидности, узнаваемости, технологичности.
Заинтересован разработчик в причислении себя к солидной узнаваемой конторе?
Может ли разработчик ожидать получение ценного опыта для продвижения куда-то в более рекспектабельные дали?
А изучение новых технологий не может быть мотивом?
-
У исполнителя в данном случае могут быть еще и такие цели:
- Получение прибыли за выполнение проекта,
- Реклама фирмы и получение положительных рекомендаций заказчика,
- Получение новых проектов в будущем от того же заказчика....
Я бы их назвал бизнес-целями
+ то что сказал Эд (доп. цели):
-
2 Galogen:
Да я же не спорю по поводу престижа =) солидности и узнаваемости, получения опыта, навыков, изучение новых технологий. Просто я наверное запутался где потребность, а где цель.
2 Виталий:
Вот как раз с целями то всё ясно...)) а я спрашивал про потребности.
Всё это к тому, что в концепции ИС "Аттестация студентов" составлялась табличка "Заинтересованные лица - потребности". И там у меня случалась иногда подмена потребностей целями...)
-
На сколько я понял из вашей концепции, StUtk, потребности у вас тесно переплетаются с фичами - возможностями.
Не вижу фич системы, которые бы были необходимы только исполнителю. Мое мнение, что исполнитель останавливается на уровне бизнес целей (потребностей). Возможно я не прав.
Можно, конечно, вставить в систему баннер с рекламой исполнителя, или спам какой-нибудь, тогда наверное это можно считать фичей системы :)
-
Добрый день! Извиняюсь за задержку с выполнением. Мой последний вариант.
-
В принципе документы получились очень даже приличные. Только с БО никто не справился :)
По БО предлагаю начать с малого и прямо в этой ветке обсуждать. Т.е. с начала нарисуем основные БО (Справочники) - Студент, Преподаватель, Факультет, Кафедра, Группа, Дисциплина и проименуем связи между ними.
-
Мои исправления, в частности новая БО.
Жду замечаний :)
-
Мои исправления, в частности новая БО.
Жду замечаний :)
На самом деле. УМУ может контролировать кафедры на прямую. Однако это непринципиально.
Факультет как сущность вряд ли существует. Факультет это оргединица. На самом деле мы говорим.
Факультет имеет деканат и кафедры. Деканат возглавляется деканом. кафедра заведующим
Студент изучает дисциплину в рамках своей группы. Групаа имеет специализацию. Специализация предполагает учебных план, учебный план определяет список дисциплин для изучения. Таким образом, связь меду дисциплиной и студентом - не целесообразна.
Кроме того указание направлений следует избегать категорически
-
Кроме того указание направлений следует избегать категорически
Почему?
-
Почему?
1. это не соответствует определяемой нами нотации
2. это в определенном случае затрудняет понимание, почему стрелка в одном направлении? Это что направление чтения? есть другие обозначения
3. стрелка на конце обозначает навигацию. в ДБО она двунаправлена, т.е. граф по сути неориентирован и пути навигации можно выбирать в разных направлениях
4. навигация отношений (ассоциаций) важный аспект проектирования, а не концептуального моделирования.
5. Кратности тут тоже не будут лишними, так как могут характеризовать определенные требования
В целом мне ни одна ДБо не нравится, слишком отвлечена. Многие существенные объекты вообще не отмечены, другие показаны неверно или напрасно.
Например мне как заказчику и эксперту, связь между УМУ и факультетами очевидна, думаю она очевидна и участникам, это записано и отображено ранее, а вот многие важные моменты ни как не отображены
-
По БО предлагаю начать с малого и прямо в этой ветке обсуждать. Т.е. с начала нарисуем основные БО (Справочники) - Студент, Преподаватель, Факультет, Кафедра, Группа, Дисциплина и проименуем связи между ними.
Нарисовал, проставил связи, проименовал. (Факультета нет, поскольку в дальнейшем Заказчик поставил под сомнение существования такой сущности.)
Казалось бы простая задача, однако, такое ощущение, что связать можно всех со всеми... ???
-
Спасибо за комментарии! :)
Студент изучает дисциплину в рамках своей группы. Групаа имеет специализацию. Специализация предполагает учебных план, учебный план определяет список дисциплин для изучения. Таким образом, связь меду дисциплиной и студентом - не целесообразна.
Отсюда вопрос: ВУЗ работает в условиях Болонской конвенции или все-таки нет? И рассчитывает ли заказчик на работу ВУЗа в ее рамках? Если да, то понятие группы здесь формально. А специализация, учебный план и дисциплины напрямую имеют связь со студентом индивидуально. Да и в существующей системе образования, насколько я помню, разрешалось слушать и сдавать дисциплины, не предусмотренные учебным планом, дабы они отразились затем в дипломе.
Со стрелками в ДБО согласна...
В целом мне ни одна ДБо не нравится, слишком отвлечена. Многие существенные объекты вообще не отмечены, другие показаны неверно или напрасно.
Если можно, поподробнее с этого места. Каких основных объектов не хватает, помнению заказчика?
Возможно, объектов не хватает потому что эта ДБО была некой основой, которую будем дальше дополнять, как предложил BAS?
-
Нарисовал, проставил связи, проименовал...
1. Я бы Группу связал с Кафедрой. Над Кафедрой повесил Факультет и Деканат.
2. Преподаватель ставит Оценку Студенту по определенной Дисциплине, а не просто оценивает.
-
Новый вариант ДБО, жду замечаний.
-
Замечания:
1. Я что-то уже забыл - Даканат и Кафедра - это одно и тоже?? :)
2. Кафедра имеет заведующего из ряда Преподавателей
3. Деканат имеет зам деков и Декана
Дальше можно добавлять следующие БО.
-
1. Я что-то уже забыл - Даканат и Кафедра - это одно и тоже??
нет, деканат - структурное подразделение факультета, где контролируются ход учебного процесса, подписываются приказы, куда судентов вызывают за провинности и т.п. :) Там обитают Декан, несколько его замов по разному направлению деятельности и прочие работники канцелярии.
Кафедр на факультете может быть много. У каждой кафедры есть зав.кафедрой из числа преподавателей.
-
Исправленный вариант ДБО. На мой взгляд, лишним получается либо кафедра, либо специальность....
-
На мой взгляд, лишним получается либо кафедра, либо специальность....
Так вот она какая, тёмная сторона в работе аналитика... :)
-
Ждите, я скоро отвечу, что такое деканат :) Удивитесь
-
Коллеги, в аттаче моя версия ДБО. Прошу критиковать. :)
Жаль только, что у меня и моих коллег нет общего видения. Так как на встречах с Заказчиком эта тема не обсуждалась.
-
Факультет, деканат - привычное структурное подразделение, не правда ли? Однако, что забавно, на самом деле в организационной структуре вуза нет такой структурной единицы как факультет, нет и деканата. Нет должности декан, нет штатной единицы декан, зам декана и т.п.
Есть завкафедрой. Однако, это совершенно не мешает нам использовать для структуризации понятие Факультет. Я бы не стал выделять УМУ, хотя и это не проблема.
Чего не хватает на диаграммах: в ходе описания я как заказчик говорил об разного рода документах, как входных, так и результирующих.
Зачетная книжка
Контрольный лист успеваемости
Журнал посещения
Экзаменационная ведомость
и другие.
Преподаватели встречаются со студентами на занятиях: лекциях, лабораторных, практических, курсовых, и т.п.
Занятия студентов формируются на базе учебных планов. Даже если избрать модель болонской конвенции, это не означает, что планирование будет основываться на студенте - как единицы учебного процесса.
-
Товарищи Аналитики!
Что-то все заглохло. Давайте доделаем ДБО и пойдем дальше. Замечания Эд выставил.
Давайте для простоты сдлаем одну ДБО на всех!
-
Такое бывает, когда дел куча наваливается, аврал на работе, учёба и прочее. Я постараюсь до конца недели выложить свой вариант ДБО.
-
Не пинайте сильно, старался...)
Жду критики и замечаний.
В файле DescLinks.txt описание связей.
-
Жду критики и замечаний.
Ну а теперь сделайте это проще, не потеряв замечательного смысла :)
-
Ну а теперь сделайте это проще, не потеряв замечательного смысла :)
А можно поконкретнее? =) Предмет упрощения - это густая сеть "проводов"?
-
Я бы разбил одну Д на несколько, по смыслу. Каждая была бы проще, но связи бы остались все.
-
Не пинайте сильно, старался...)
Жду критики и замечаний.
Введи обобщения и все станет ГОРАЗДО понятнее.
-
Ну а теперь сделайте это проще, не потеряв замечательного смысла :)
Введи обобщения и все станет ГОРАЗДО понятнее.
Трудно, что-то добавить. Аналитик Вы :), а я глупый заказчик. Но мне как заказчику Ваша диаграмма, хотя и понятна в целом, но уж очень запутана.
Мне кажется тут есть такие недостатки:
1. не следует давать ассоциациям номера, а названия их делать отдельно - это плохой стиль
2. не следует добавлять сразу много деталей. Например, достаточно было бы пока рассмотреть понятие Занятие и не конкретизировать его слишком, хотя и так нормально, просто когда много деталей - увеличивается сложность восприятия и уменьшается наглядность и понятность
3. Например между контрольным листом и экщзменаицонной ведомостью - не так уж много различий на данном этапе анализа (хотя конечно можно для начала и так оставить)
4. Объединение линий связей - плохой стиль на мой взгляд. да он позволяет компктно разместить элементы, но исчезает наглядность и повышается трудность чтения диаграммы
-
Новая версия.
-
Новая версия.
- "Занятие" - это класс-ассоциация.
- Нужен ли класс "Оценка"? Если нужен, то почему он так "далеко" от "Зачетной книжки" и "Отчета по успеваемости"?
-
StUtK, неплохо.
Наверное на начальном этапе не следует стремится к идеальности и полной согласованности.
Анализ правда можно уже начинать и по-тихоньку структурировать модель.
Замечания:
Не следует ассоциации писать так буквально. Хотя смотрится великолепно, для заказчика просто то, что надо.
Но все-таки участников ассоциации не рекомендуется включать в имя ассоциации, направление чтение поставить несложно в ЕА.
Далее насчет того, что считать классом-объектом, а что атрибутом.
Оценка вполне может быть классом, но все-таки это скорее атрибут занятия. Другое дело если мы развернем понятие оценки до понятие рейтинга, надо сказать никто почему-то на это не обратил никакого внимания.
А я писал об этом:
есть N баллов за семестр и M баллов за экзамен-зачет, всего в сумме = N+M. N может быть равен M.
N разбивается на К контрольных точек (типично 3): x, y, z. Причем z = N. Контрольная точка характеризуется Датой, Количеством Баллов, Количеством Пропусков. Каждая последующая точка есть сумма предыдущей и того количества баллов которые студент можеет набрать между контрольными точками.
Преподаватель должен загодя определить какие занятия войдут в каждую из контрольных точек и сколько баллов приходится на каждую контрольную точку, т.е. если преподаватель ежедневно выставляет оценки, то контрльная точка формируется автоматом
-
извиняюсь за отсутствие в обсуждении.
мы делаем общую диаграмму или каждый свою?
выкладываю пока свою, с учетом замечаний.
Вопрос к заказчику: кто определяет дату контрольной точки?
-
Мда...
Товарищи аналитики!
Ну почему вы едите кто в лес, кто по дрова?
Менеджера на вас не хватает....
Вот возьмем, например, сущность "Журнал посещений"
Один (StUtk) считает, что "Журнал посещения показывает посещаемость по занятиям" и рисует соответствующую ассоциацию,
другой (veta), что "Группа отмечается в Журнале посещений".
Я могу десяток похожих картинок нарисовать, считая, что
"Журнал посещений заполняет Преподаватель" или
"Журнал посещений лежит на Кафедре в сейфе Декана, который живет в Доме, который построил Джек"
или еще черте что.
Прежде чем рисовать диаграмму, ну определитесь вы с составом сущностей предметной области.
Составьте наконец СЛОВАРЬ ПРЕДМЕТНОЙ ОБЛАСТИ, сколько можно то уже ...
-
Я, я, я ... это ... менеджор :)
Во-первых, давайте построим одну ДБО на троих, за основу возьмем ДБО от StUtk (http://www.uml2.ru/forum/index.php?topic=1106.msg13180#msg13180).
Во-вторых, согласен с Денисом. Нужно составить словарь предметной области (т.е. список БО и их определение) и согласовать его с Эдом.
-
... давайте построим одну ДБО на троих...
:)
-
Вопрос к заказчику: кто определяет дату контрольной точки?
Учебный отдел
-
Учебный отдел занимается только определением контрольных точек?
Имеет ли Учебный отдел отношение к составлению учебного плана?
Учебный отдел один на весь ВУЗ, или имеются учебные отделы по факультетам/деканатам/кафедрам?
-
Учебный отдел занимается только определением контрольных точек?
составляет расписание занятий, экзаменов
подготавливает общую отчетность по вузу по итогам сессии
разрабатывает на основе учебных планов графики прохождения учебного плана: на каждый учебный год определяется количество занятий по дициплине и их кратность
следит за исполнением педагогической нагрузки преподавателей
Имеет ли Учебный отдел отношение к составлению учебного плана?
насколько я помню нет, но входя в состав УМУ получается участвует. Графики делает точно
Учебный отдел один на весь ВУЗ, или имеются учебные отделы по факультетам/деканатам/кафедрам?
у нас 1 учебный отдел. Может в других очень крупных вузах их и несколько
-
Совместными усилиями с Veta составили словарь предметной области:
1. Факультет – структурное подразделение ВУЗа, объединяющее несколько кафедр, осуществляющих обучение студентов по определнному направлению.
2. Деканат — структурное подразделение факультета, выполняющая функции координации и административного обеспечения учебного процесса.
3. Кафедра – подразделение ВУЗа, осуществляющее обучение студентов по одной или нескольким специализациям.
4. Группа – формальное объединение студентов, обучающихся на кафедре по определенной специализации.
5. Студент - учащийся ВУЗа по определённой специальности.
6. Балл - оценка результата работы студента на занятии.
7. Рейтинг - количественная оценка работы студента по дисциплине, учитывающая успеваемость в течение семестра.
8. Зачетна книжка - документ, фиксирующий оценку студента за зачет или экзамен по дисциплине.
9. Дисциплина – предмет, обязательный для изучения в рамках учебного плана для определенной специализации.
10. Занятие - форма обучения по дисциплине.
11. Учебный план - перечень дисциплин, их форма и объём, преподаваемых по специализациям.
12. Журнал посещения – документ, отражающий посещаемость занятий студентом по дисциплинам учебного плана.
13. Преподаватель - специалист, обучающий студентов по определённой дисциплине.
14. Контрольная точка - значение рейтинга и посещаемость студента к определённой дате.
15. Отчёт успеваемости - набор статистических данных, отражающий информацию об результатах обучения студентов.
16. Учебный отдел - структурное подразделение ВУЗа, занимающееся составлением и контролем над исполнением плана учебного процесса.
-
Коллеги, прошу прощения.
Сейчас на проекте очень напряженная ситуация. Так что с вашего позволения временно я не буду выполнять данынй учебный пример.
Надеюсь на ваше понимание.
Спасибо.
-
Кто-нибудь, скажите хоть чё-нибудь...)
В смысле, уважаемые Менеджер, Заказчик, а так же Критики, хотелось бы услышать рекцию на составленный словарь предметной области. =)
-
Кто-нибудь, скажите хоть чё-нибудь...)
Я в свое время предложил составить словарь предметной области, чтобы не было разнобоя в диаграммах. Теперь ждем диаграмму, которая соответствует этому словарю.
-
Во-вторых, согласен с Денисом. Нужно составить словарь предметной области (т.е. список БО и их определение) и согласовать его с Эдом.
Я думал, что сначала словарь согласовывается, а потом строится диаграмма.
Хорошо, буду делать диаграмму.
-
Я думал, что сначала словарь согласовывается, а потом строится диаграмма.
Все молчат. Вроде как согласны.
-
Совместными усилиями с Veta составили словарь предметной области:
Ну раз Эд не хочет давать замечания, то выскажу свое ИМХО по пунктам выше:
1. Нигде не сказано про Направление, что это такое?
2. Нигде нет про Декана, Замдеков и т.д.
3. я бы сказал так: Кафедра – подразделение Факультета, осуществляющее обучение студентов по одной или нескольким специализации.
5. Студент - учащийся ВУЗа на кафедре по определённой специальности.
6. Балл может быть какой?? зачет\незачет - бал, 100% - бал и т.д.
8. Зачетная книжка фиксирует не только оценки, но факт прохождения практики и диплома
13. Преподаватель - специалист, обучающий студентов по одной или нескольким дисциплинам.
-
Ну раз Эд не хочет давать замечания,
Мне как заказчику вовсе не предстало давать замечания. Я хочу получить продукт: реальный или консальтинговый не важно.
Мне кажется надо все-таки понять, а что нужно???
Мне как заказчику конечно нужна система учета успеваемости студентов и посещения занятий. Для того чтобы рассчитывать рейтинги и т.п.
Понимаю, что продукта не получу. Но возможно получить модель продукта. Скажем на уровне MDA, набор требований, постановок на реализацию, рекомендаций по технологиям и продуктам..
Да это я хочу, остальное разве это мое дело?? влезать в тонкости терминалогии и одобрять или нет. В целом мы уже все обсудили, и свои замечания по пониманию фактов я высказал. Я дал как заказчик много материала. Мне как заказчику интересно работать по конкретной а не вообще ситуации. На вопросы я отвечаю, но замечания делать специалистам!!!! пардон увольте...
то выскажу свое ИМХО по пунктам выше:
1. Нигде не сказано про Направление, что это такое?
А зачем? Хотя разумно. Специальность входит в направление. По специальности учатся 1 или более групп.
2. Нигде нет про Декана, Замдеков и т.д.
А смысл? Это некто кто получает отчетность. Какова его роль? утверждать итоги сессии и семестра, да возможно....
3. я бы сказал так: Кафедра – подразделение Факультета, осуществляющее обучение студентов по одной или нескольким специализации.
Не надо забывать про каферы общедисциплинарные: математика физика, химия и т.п они не выпускают. Не надо путать слова специализация и специальность.
5. Студент - учащийся ВУЗа на кафедре по определённой специальности.
разумно
6. Балл может быть какой?? зачет\незачет - бал, 100% - бал и т.д.
Я уже трактат по этому написал смотри выше(ниже)
8. Зачетная книжка фиксирует не только оценки, но факт прохождения практики и диплома
фиксирует причем с оценкой выражаемой в виде классической оценки и количества баллов. Опять же смотри мои тексты...
13. Преподаватель - специалист, обучающий студентов по одной или нескольким дисциплинам.
Это так
-
Эд,
Ну кто кроме тебя даст замечания по определению БИЗНЕС терминов на языке БИЗНЕСА. Был бы ты на интервью, никуда бы не делся :)
Коллеги Аналитики,
Давайте рисуем ДБО на основе определений и правок и переходим к следующему этап, потом итерационно будем добавлять если что-то увидим, а то так можно бесконечно рисовать БО.
-
1. Факультет – структурное подразделение ВУЗа, объединяющее несколько кафедр, осуществляющих обучение студентов по определённому направлению (например, технология, механика, медицина, филология, бриспруденция, история и т.п.)
2. Деканат — структурное подразделение факультета, выполняющая функции координации и административного обеспечения учебного процесса
3. Кафедра – подразделение ВУЗа, осуществляющее обучение студентов по одной или нескольким специальностям. Также выделяют кафедры общедисциплинарного профиля. Такие кафедры не выпускают студентов.
4. Группа – формальное объединение студентов, обучающихся на кафедре по определенной специальности в рамках некоторого направления.
5. Студент - учащийся ВУЗа по определённой специальности.
6. Балл - оценка результата работы студента на занятии.
7. Рейтинг - количественная оценка работы студента по дисциплине, учитывающая успеваемость в течение семестра.
8. Зачетная книжка - документ, фиксирующий результаты обучения в соответствии с учебным планом специальности. ЗК содержит информацию о зачетах, экзаменах, результатах курсовых и квалификационных работы, практик.
9. Дисциплина – предмет, обязательный для изучения в рамках учебного плана для определенной специальности.
10. Занятие - форма обучения по дисциплине. Выделяют аудиторные и самостоятельные занятия. К аудиторным относятся: лекции, практические занятия, лабораторные занятия. К самостоятельным: парктика, курсовые, работа над квалификационными работами
11. Учебный план - перечень дисциплин, их форма и объём, преподаваемых по специальности.
12. График прохождения учебного плана - документ определяющий общую нагрузку студентов в течение семестра, определяет количество и кратность прохождения занятий по каждой дисциплине.
13. Журнал посещения – документ, отражающий посещаемость занятий студентом по дисциплинам учебного плана.
14. Преподаватель - специалист, обучающий студентов по определённой дисциплине.
15. Контрольная точка - значение рейтинга и посещаемость студента к определённой дате.
16. Отчёт успеваемости - набор статистических данных, отражающий информацию об результатах обучения студентов.
17. Учебный отдел - структурное подразделение ВУЗа, занимающееся составлением и контролем над исполнением плана учебного процесса (в данном контексте).
-
Товарищи Аналитики, давайте ДБО и пойдем дальше. Или желание продолжать ушло??
-
Не ушло, просто со временем тяжко очень.
Плюс совместная работа людей, связывающихся по аське, накладывает дополнительные трудности.
К среде будет ДБО.
-
А кто сказал, что будет легко ;) Ждем ждем ...
-
Добрый день! В результате обсуждения ДБО родились поправки к словарю:
14. Преподаватель - специалист, ведущий занятия по одной или нескольким дисциплинам.
18. Специальность - одна или несколько групп студентов, обучающихся по определенному учебному плану в рамках одного направления.
-
Ну и собственно наша ДБО:
-
1. Не хватает кратности на концах связи.
2. Согласен с Деканатом, Факультетом, Направлением, Кафедра, Специальность, Группа, Студент, Зачетная Книга
3. Преподаватель не учет Студента - он ведет Занятия и числится на кафедре
4. Я бы сказал так - Студент посещает Занятия, по Занатяию студент может присутствовать или нет (Журнал посящений) и по Занятию может быть выставлен Бал.
Остальные замечания позже. Самому надо разобраться с левой частью :)
-
1. Не хватает кратности на концах связи.
Имхо, имеет смысл добавить кратность, когда в целом ДБО будет одобрена.
3. Преподаватель не учет Студента - он ведет Занятия и числится на кафедре
Не привязывали препода к кафедре из тех соображений, что преподаватель может приглашаться со стороны.
-
Имхо, имеет смысл добавить кратность, когда в целом ДБО будет одобрена.
Так в том то и дело, что с кратностью будет более понятно
Не привязывали препода к кафедре из тех соображений, что преподаватель может приглашаться со стороны.
Как раз для этого и нужна кратность - 0..1
-
Насчет кратностей и прочее.
Думаю кратности будут полезны. Это уже бизнес-правила или ограничения.
Да преподаватель может приглашаться со стороны. Однако его принадлежность или не принадлежность к кафедре может быть зафиксирована кратностью. Однако можно учесть факт того, что один и тот же преподаватель может работать на нескольких кафедрах по совместительству
Еще думаю следует попробовать осуществить навигацию по модели. Т.е. сформировать OCL выражения или OCL подобные выражения. Попытаться ответить на разные интересные вопросы:
К примеру:
1. Сколько студентов обучаются такойто дисциплине у такого-то преподавателя
2. По каким занятиям студент не отчитался
3. Какое количество пропусков у группы такой-то за такой-то период
4. Какова средняя успеваемость студентов группы такой-то
5. У какого преподавателя средняя успеваемость студентов в год лучше всех
и т.п.
Попытка собрать такие вопросы и попытаться ответить на них дает много мыслей для анализа и улучшения модели
-
Осилил ДБО:
1. Не нужен Отчет успеваемости, т.к. это уже предмет получения инфы из существующей ИС или бумаг, это не объект ПрОбл
2. Удалить График прохождения ..., т.к. ег онет в Словаре и пока не понятно что он определяет
3. ИМХО пока нужно убрать Контрольную точку и Рейтинг, т.к. не понятна до конца как они считаются с др. объектами ПрОбл
4. Исправить замечания данные выше:
http://www.uml2.ru/forum/index.php?topic=1106.msg13578#msg13578
Жду исправленной ДБО и поехали дальше.
-
очень странные рекомендации от менеджера.
1. Не нужен Отчет успеваемости, т.к. это уже предмет получения инфы из существующей ИС или бумаг, это не объект ПрОбл
Да вполне возможно. Однако ДБО - это не диаграмма классов ПО, следует это понимать.
2. Удалить График прохождения ..., т.к. ег онет в Словаре и пока не понятно что он определяет
Сам по себе учебный план задает лишь дисциплину, семестр и количество часов и виды отчетности.
График прохождения задает ритм прохождения занятий, их количество в семестре и кратность
3. ИМХО пока нужно убрать Контрольную точку и Рейтинг, т.к. не понятна до конца как они считаются с др. объектами ПрОбл
Это очень забавно. Я об этом писал.
Количество контрольных точек естественно может меняться. Однако в нашей практики их 3 в течение семестра. Последняя точка завершающая по семестру.
Рейтинг это совокупная оценка успеваемости студента с учетом посещения занятий, результатов работы в семестре и на экзаменах.
В семестре студент может заработать 50 баллов + 50 баллов за зачет или экзамен. На итоговый рейтинг влияет и посещаемость и своевременность получения зачетов и экзаменов
Существует рейтинг по дисциплине и общий совокупный рейтинг как нарастающая сумма баллов. Она может использоваться при распределении стипендиального фонда.
-
Эд,
Рейтинг - это по сути отчет по данным? Не знаю имет смысл его прилплять или нет.
На счет Графика прохождения и Контрольных Точках подумаем отдельно как их обозначить на Д, пока предлагаю оставить их на Д, но не связывать ни с чем.
-
Новая версия ДБО, сделанная совместно с Veta'ой.
по поводу графика прохождения учебного плана - в Словаре определение есть:
"12. График прохождения учебного плана - документ определяющий общую нагрузку студентов в течение семестра, определяет количество и кратность прохождения занятий по каждой дисциплине."
http://www.uml2.ru/forum/index.php?topic=1106.msg13429#msg13429
В связи с наличием разногласий между менеджером и заказчиком, мы как люди подчинённые менеджеру, всё-таки больше ориентируемся на него.
-
После бурных обсуждений с нашим менеджером :) возникли вопросы к заказчику:
Верно ли :
1. Занятие является элементом Графика прохождения учебного плана?
2. График прохождения учебного плана - это по сути расписание занятий?
-
Рейтинг - это по сути отчет по данным? Не знаю имет смысл его прилплять или нет.
В данном случае рейтинг - это понятие предметной области. Естественно, что рейтинг вычисляется по определенной формуле.
Бывает рейтинг по дисциплине - т.е. сумма баллов которую набрал студент при обучение по данной конкретной дисциплине в конкретный период времени - семестр.
В семестре по дисциплине можно набрать 100 баллов. По сути рейтинг - это оценка успеваемости студента.
Рейтинг текущий выставляется в определенные контрольные моменты - контрольные точки успеваемости, экзамен или зачет в сессии.
Рейтинг числовое понятие - скорее всего целое.
Есть вообще рейтинг студента как тотальная сумма всех рейтингов по дисциплинам за все время обучение с учетом всяких прогулов, невыходов и пересдач. Это можно уточнить
Такми образом я не навязывал свого понимания рейтинга как объекта. Думаю - это простое числовое понятие, являющееся характеристикой контрольной точки.
Если рейтинг вычислять по сумме баллов за занятие, тогда следует вводить автоматические штрафы. Поясню
1. кт№1 - нужно набрать 16 баллов. Студент набрал 10
2. кт№2 - нужно в сумме набрать 34 балла, по разнице можно добрать 18 баллов,т.об студент должен набрать не более 28 баллов и т.п.
Таким образом система должна предусматривать гибконастраиваемое бизнес-правило:
1. понятие штрафа за работу сданную после контрольной точки
2. понятие исключения - человек болел. Ясно что контрольные точки это период 1,5 месяца и весь период болеть студент не может, а если более то у него есть уважительная причина, ее нужно тоже учитывать при простановке оценки за прошедшие занятия задним числом
На счет Графика прохождения и Контрольных Точках подумаем отдельно как их обозначить на Д, пока предлагаю оставить их на Д, но не связывать ни с чем.
сам график не нужен, достаточно расписания занятий, которое вколачивается либо самим преподом, либо работником учебного отдела.
Преподаватель должен определить максимальное число баллов за занятие, какие занятия будут включаться в контрольную точку. Поясню. Пусть за период между контрольными точками 7 занятий, при это на седьмом занятии студенты получают 4 задание на исполнение, ясно, что они еще не успеют выполнить задание к контрлльной точке, т.к. отчетное занятие будет после.
Пусть каждое занятие оценено в 4 балла, тогда к контрольной точке нужно сдать работы на 3*4 = 12 баллов
Я вообще ставлю 1 балл за то, что человек уже присутствовал. Т.е. отсуствующий получает как бы -1 балл. Это стимулирует не колоть занятия. Скажем пропустил все 18 занятий сразу получаешь минус 18 из 50, итого только 32 балла, даже если работы все сдал на сверх отлично, все равно. Тут я обычно сразу предупреждаю стуентов о правилах игры: тот кто по тем или иным соображением не ходят на занятия но не хочет потерять баллы должны брать индивидуальные дополнительные задания, поскольку на своих занятиях я много чего даю, а те кто не ходят часть этих знаний теряют :)
-
После бурных обсуждений с нашим менеджером :) возникли вопросы к заказчику:
Верно ли :
1. Занятие является элементом Графика прохождения учебного плана?
2. График прохождения учебного плана - это по сути расписание занятий?
график регламентирует количество часов по данной дисциплине, кратность занятий в семестре. регламентирует общую загрузку в неделю, количество экзаменов и других видов отчетности.
График служит основанием при разработке расписания, но таковым не является
-
Поясню...
Т.е. в данном случае преподаватель не включает последнее занятие с 4 заданиями в контрольную точку, а баллы, полученные за выполнение этих заданий будет учтено в следующей КТ?
Пусть за период между контрольными точками 7 занятий
Пусть каждое занятие оценено в 4 балла, тогда к контрольной точке нужно сдать работы на 3*4 = 12 баллов
все-таки о скольки занятиях, которые включаются в КТ, идет речь? из формулы следует что о 3. ???
если следовать словесному описанию, то количесвто баллов к контрольной точке должно быть 6*4=24...
-
veta.
до первой контрльной точки состоится 7 занятий. 1 задание на 2 занятий. Т.е получаем 3,5 заданий. Т.е. к контрольной точке будет выполнено и нужно отчиться за 3
-
Новая версия ДБО, сделанная совместно с Veta'ой.
-
Новая версия ДБО, сделанная совместно с Veta'ой.
Замечания
1. У Факультета один и только один Деканат
2. Кафедра может и не иметь Специальности, если мы говорим об выпускающих, т.е. кратность 0 или много
3. Ассоциация "преподается" лишняя. Дисциплина часть учебного плана, а каждая специальностьимеет один учебный план. (на самом деле учебный план может различаться для одной специальности)
4. Учебный план не определяет контрольую точку
-
поправили
-
Отлично. Спасибо Всем за работу. ДБО будем уточнять по ходу, а сейчас переходим к след. этапу - Формализации Пользовательских Требований и Ограничений.
Т.о. нам нужно определить списков СВИ и описать пока их основной сценарий. СДВИ пока может быть поощью, но проверять я ее не буду, главное - список ВИ и их описание.
Господа Аналитики, скажите срок выполнения данной задачи.
З.Ы. Если кто-то еще хочет присоединиться на этом этапе, то велкам....
-
Лично я затрудняюсь сказать, сколько времени займёт, надо начать, а там будет видно.
СВИ - это Список ВИ?
Мы сначала пишем список ВИ, уточняем, одобряем, а потом расписываем сценарий для ВИ?
Будет ли жёстко задан шаблон описания сценария?
-
Тогда когда будет готова первая версия со списком ВИ?
СВИ - это Системные ВИ
Сначала пишем список ВИ, мы его смотрим, и потом расписываем основные сценарии, а вот это уже утверждаем, т.к. список ВИ ничего не даст, только ВИ и описание - вот ключ к успеху.
Шаблон берем из Вигерса, у нас должны быть ВИ уровня Цели Пользователя.
-
Тогда когда будет готова первая версия со списком ВИ?
после майских =)
-
Я предлагаю делать так:
1. создать список вариантов использования - возможно с кратким его описанием
2. выложить список и проголосовать за каждый вариант, чтобы набрать статистику важности и первоочередности
при этом следует участовать - всем аналитикам, менеджеру проекта, архитектору, проектировщику, внедренцам, тестеровщикам и конечно заказчикам
3. по результатм экспертной оценки или если не получиться в результате конференции идей - выделить 10 % ВИ на детальную проработку - завершиться долдно созданием прототипа идеально анимированного, или хотя бы раскадровки - презентации
4. менеджеру проекта следует спланировать первую итерацию, точно указать что войдет туда и каким результатом заверщается
-
Хорошо, планирую:
1. К 12 мая 2009 года - Каждый Аналитик должен приготовить список ВИ, краткое описание каждого ВИ (шаблон ниже) и Диаграмму ВИ
2. К 15 мая 2009 года - МП и Заказчик должны высказать свои замечания
3. К 19 мая 2009 года - Аналитики Должны приготовить единый список ВИ, краткое описание каждого ВИ и Диаграмма ВИ, согласовать это все внутри Аналитиков
4. К 26 мая 2009 года - Аналитик, МП и Заказчик должны утвердить список ВИ, краткое описание каждого ВИ и Диаграмму ВИ
5. К 1 июня 2009 года - Аналитики должны приготовить детальное описание ВИ.
6. Шаблон краткого описания ВИ:
* Идентификатор ВИ - например, "ВИ-01"
* Название ВИ - например, "Управлять Справочником"
* Роли - Роли участвующие в ВИ, например, "Администратор"
* Краткое описание - краткое описание основного потока ВИ в неструктурированном виде, например, "Администратор должен иметь возможность Добавлять, Редактировать и Удалять записи в следующих Справочниках ..."
-
Я бы вообще не упирался бы на диаграмму ВИ. Если все-таки МП настаивает на этом, то я прежде бы подумал о контекстной диаграмме, которая бы отразила роли пользователей системы и другие взаимодействующие системы.
Либо я посоветовал нарисовать интеллект-карту для проведения мозгового штурма.
Т.е. этап обдумывания вариантов, их идентификации и даже краткое описание следует провести на форуме в быстром темпе.
Из имеющихся у нас аналитиков, кто-то должен взять на себя роль старшего, кто подготовит материал для обсуждения:
- список акторов
- список ВИ целей пользователей
-
Всем добрый день!
Список ВИ, их описание и ДВИ в аттаче.
Если все будет плохо :) и возникнет необходимость в общем обдумывании, готова взять на себя подготовку списка актеров и ВИ целей пользователей.
-
veta,
У всех проблема со слишком мелкой детализацией, а у Вас наоборот :)
Надеюсь, что мы все понимаем, что мы говорим о ВИ уровня цели пользователя, т.е. говорим о интересах Пользователя по отношения выполнения операций в ИС.
Возьмем ВИ "Настроить систему":
Название ВИ не соответствует описанию. Описание говорит о Пользователях, а название о Настройках. Я бы назвал этот ВИ - "Управлять правами Пользователя".
Или имеет смысл разделить на два ВИ: "Управлять Пользователями" и "Управлять правами Пользователя"
ВИ "Работа с данными о студенте":
Я бы назвал это - Добавить Студента или Управлять данными о Студенте. И включил бы туда просто добавление\удаление\ изменение данных о Студенте без "необходимости вносит информацию о зачислении, больничных листах, академических отпусках, продлениях сессии, отчислении, восстановлении....".
Другую необходимость из этого в новый ВИ.
ВИ "Тестирование студентов"
Явно выделяется два ВИ:
* "Добавить тест", инициирует Преподаватель
* "Пройти тест", инициирует Студент, участвует Преподаватель (смотрит результаты прохождения)
Далее в таком духе....
-
Прошу прощения за опоздание. Времени как всегда не хватает, но кризис тут не при чём. =)
-
Прошу прощения за опоздание. Времени как всегда не хватает, но кризис тут не при чём. =)
Вычтем из жалования ;)
-
StUtk,
Ну что же даже очень неплохо.
Есть несколько замечаний:
1. ВИ "Учёт успеваемости и посещаемости студентов", лучше наверное выделить ВИ "Поставить оценку" и ВИ "Зафиксировать посещаемость".
2. ВИ "Тестировать студентов", лучше назвать ВИ "Пройти тест", и в нем должен участвовать еще Преподаватель, т.к. он смотрит результат теста или ему приходим мыло и т.д.
3. Не хватает ВИ "Войти в Систему".
Теперь нужно проверить - закрыли ли все потребности из Концепции нашими ВИ.
-
Исправил.
-
Сорри, за отсутствие, дел много было ...
По последнему варианту StUtk, такие замечания:
1. Можно сделать одного Актера, например, Сотрудник, который может "Управлять справочниками" и "Построить консолидированные отчёты". А от него уже унаследовать Сотрудника деканата и Сотрудника кафедры.
2. ИМХО в ВИ "Поставить оценку" и "Зафиксировать посещаемость" должен участвовать еще и Студент, он же видит результаты.
3. ИМХО правильнее заменить ВИ "Управлять учебными материалами" на ВИ "Выложить УМ" и в нем должен участвовать Студент, т.к. он потребляет эти УМ. При этом убрать ВИ "Предоставить учебные материалы"
3. ВИ 08.Предоставить историческую информацию о студенте и ВИ 09.Предоставить информацию об успеваемости студентам, должны называться не Предоставить, а Получить, т.к. ВИ это потребности со стороны Пользователя, а не Системы.
4. ВИ 11. Администрировать систему - слишком общий, ну да ладно, пускай пока так.
Теперь можно исправить недочеты и приступить к полному описанию Сценариев ВИ. Когда можно ждать?
З.Ы. А veta куда пропала?
-
Новая версия, сделанная вместе с Veta'ой.
-
Новая версия, сделанная вместе с Veta'ой.
Не вдаваясь в подробности, я бы порекомендовал сделать следующее:
все ВИ разбить на группы:
мне видятся:
группа Администрирования системы
группа управления учебными материалами
группа управления справочной информацией
группа отчетности
группа оценивание и учета учспеваемости
возможно группа тестирования, т.е. что касается студентов
Возможно группы будут другими, однако уже сейчас ясно, что уровень ВИ у Вас разный. Темы ВИ тоже очень разные, да и реализация ВИ будет идти по мере возможности
Деление поможет сосредоточиться на важнейших, даст возможность описать, выделить ВИ уровня пользователя, а затем системные более точно и без излишнего усложнения
-
Что бы не терять темп пишу замечания:
1. ВИ 03. Управлять справочниками, построить консолидированные отчёты
Зачем Вы два ВИ объединили в один? Это разные Вы со своими целями и потоками, а ДЛ одно и тоже там и там - "Сотрудники ВУЗа"
2. ВИ 09. Получить историческую информацию о студенте
Тут у Вас два ДЛ, а на ДВИ одно ДЛ
3. Я бы сделал 3 ДВИ (3 пакета):
* Иерархия ДЛ только
* Администрирование, где показаны ВИ01 и ВИ02
* Общий, где находится все остальное
Так же можно воспользоваться декомпозицией, кот. предложил Эд, но ИМХО она очень детальная, можно что-то объединить.
Исправляем, выкладываем и начинаем делать полное описание ВИ.
-
Так же можно воспользоваться декомпозицией, кот. предложил Эд, но ИМХО она очень детальная, можно что-то объединить.
Исправляем, выкладываем и начинаем делать полное описание ВИ.
Имхо о детальности рано говорить.
ВИ еще не табулированы
Потом надо их ранжировать по важности
И уже потом начинать первую итерацию - детальное описание 10-15% ВИ
Мне так вот видится
-
Табулированы это как?
С остальным нет возражений.
-
Табулированы это как?
не определен и не утвержден начальный список ВИ в целом. Надо бы его сначала принять и пойти дальше
-
Согласен.
1. Исправляем ВИ и ДВИ
2. Утверждаем
3. Ранжируем\приоритизируем ВИ
4. Выделяем первые наиболее важные ВИ для полного описания и описываем.
-
Исправленные ВИ и ДВИ, совместно со StUtk'ом.
-
veta,
Спасибо. Уже на много лучше. С моей стороны я утверждаю список ВИ и ДВИ, с маленькими замечаниями:
1. На Д пакетов не показан сам Пользователь
2. Рамки Системы есть только на Д Пакетов, а на ДВИ нет. Надо либо убрать везде, либо везде поставить
3. Если Инструмент позволяет, то не плохо на Д Пакетов в самих Пакетах отображать список ВИ в него входящих.
Эд, теперь твое дело утвердить ВИ и ранжировать.
-
ВИ 02. Управлять правами пользователей - Назначить уровень доступа, роль
ВИ 01. Управлять пользователями
Роли: администратор
Краткое описание: Администратор создает роли и пользователей в Системе
ИМХО - два разных ВИ-процесса. Формирование ролей (или формирование уровней доступа) и Управление пользователями куда может войти и ВИ02: создать учетную записб, редактировать учетную запись (в том числе назначить роль), заблокировать, удалить и т.п.
ВИ9 и 10 скорее всего будет объединен, нужно прописать и понять в будущем
ВИ 07. Получить учебные материалы
Роли: студент
Краткое описание: Студент авторизуется в Системе, после чего ему предоставляется доступ к учебным материалам по различным дисциплинам с учётом ограничений доступа, установленного на данные материалы Преподавателем.
Следует добавить, что материал предоставляется в соответствии с учебной программой или учебным планом
Администартор и Преподаватель - не является сотрудником вуза?
Нсчет ранжирования - предлагаю устроить экспертную оценку.
Каждое ВИ оценить в 10 балльной шкале - чем больше тем приоритетнее, сложить баллы и получить конечный результат
Но сначала думаю следует утрясти сами ВИ
-
Администартор и Преподаватель - не является сотрудником вуза?
С т.з. выполнения ВИ Системы не являются. В остальном в принципе согласен.
А кто будет выставлять оценки?
-
С т.з. выполнения ВИ Системы не являются. В остальном в принципе согласен.
А зачем нам сотрудник вуза? какие у него тогда обязанности, почему потребовалось обобщать?
А кто будет выставлять оценки?
Обычно это делают как представители заказчика так и разработчика. Чем больше тем лучше, главное тобы это были не случайные люди
-
Нсчет ранжирования - предлагаю устроить экспертную оценку.
Каждое ВИ оценить в 10 балльной шкале - чем больше тем приоритетнее, сложить баллы и получить конечный результат
не совсем правильный способ, точнее недостаточно описанный. ведь известно, что в составе системы есть "основные" функции и "вспомогательные" (типа ведения справочников).
так вот, сначала нужно выбирать из "основных", а потом дополнять выбор из числа "вспомогательных" безо всякой оценки.
задача из "основных" оставить самые важные, которые помогают достигнуть главных целей создания системы.
а "вспомогательные" сократить до минимума, чуть ли не полностью. Иначе в первом релизе будут отличные функции по ведению тех же справочников, а полезного функционала будет с гулькин нос (если он там вообще окажется).
способ просеивания "основных" простой: рисуется общий процесс, и оценка выполняется на основании ...э... удельной доли функции в достижении целей процесса (во завернул :о)) сам радуюсь). остальные просто откладываются в сторону до следующего релиза.
-
А зачем нам сотрудник вуза? какие у него тогда обязанности, почему потребовалось обобщать?
Читаем твою статью Обобщение действующих лиц (http://www.uml2.ru/index.php?option=com_content&task=view&id=404&Itemid=51) и смотри на ДВИ.
-
Читаем твою статью Обобщение действующих лиц (http://www.uml2.ru/index.php?option=com_content&task=view&id=404&Itemid=51) и смотри на ДВИ.
Обобщение нужно делать тогда и только тогда, когда это облегчает и упрощает понимание.
Сотрудник вуза неая абстракция, которая не имеет реализации. Обратим внимание, что если Сотрудник деканата может выставить оценку, то Сотрудник кафедры у нас нигде никак не проявляется, что означает, что он полностью наследует Сотрудника вуза. Таким образом мы говорим Сотрудник вуза - абстракная роль. Гуд, но семантически он затрудняет понимание на мой взгляд.
Сотрудник вуза как абстракция действительно может посроить консолидированные отчетности - согласен. Однако управлять справочниками имхо должен не абстракный сотрудник вуза - а методист деканата или сотрудник учебного отдела:
1. методист деканата знает ФИО студентов, состав и т.п. поскольку ведет дела студентов. Он знает и учебные планы, графики прохождения учеюного процесса, готовит ведомости и т.п.
2. с другой стороны подготовка планов и т.п. - дело учебного отдела, это он спускает утверждает информацию - он и является главным потребителем консолидированной отчетности поскольку именно он контролирует весь учебный процесс под руководством проректора по учебной работе
-
Эд,
Давай чтобы не затягивать, твои предложения, что и как нужно сделать.
-
Эд,
Давай чтобы не затягивать, твои предложения, что и как нужно сделать.
Ну я высказал. Мне не понятна роль сотрудника ВУЗа. Я предлагаю ее убрать
-
После разговора с Заказчиком (Эд) я его убедил, что так и надо :)
Если серьезно, то решили оставить пока как есть, если будут какие-то еще уточнения потом, то исправим.
Теперь дело за Эдом, чтобы он приоритизировал ВИ.
-
Я представляю себе это примерно так
ВИ 04. Управлять справочниками (10)
ВИ 09. Поставить оценку (10)
ВИ 10. Зафиксировать посещаемость (10)
ВИ 12. Построить консолидированные отчёты (9)
ВИ 05. Получить историческую информацию о студенте (.8.)
ВИ 06. Управлять учебными материалами (7)
ВИ 08. Составить тестовые и проверочные задания (7)
ВИ 11. Пройти тест (6)
ВИ 07. Получить учебные материалы (6)
ВИ 01. Управлять пользователями (5)
ВИ 02. Управлять правами пользователей (5)
ВИ 03. Войти в систему (5)
-
Эд, спасибо.
Но ИМХО, нужно поменять местами ВИ 08 и ВИ 07 или ВИ 06 и ВИ 11
-
Эд, спасибо.
Но ИМХО, нужно поменять местами ВИ 08 и ВИ 07 или ВИ 06 и ВИ 11
Я высказал свое мнение как заказчик на правах мозгового штурма.
Сторона разработки должна сделать свои приоритеты - сумма приоритетов даст нам реальную расстановку
Для того чтобы пройти тестирование, воспользоваться учебными материалами, нужно разработать сами эти материалы и тесты. Когда их структура будет ясна - ясно будет как реализовать доступ к материалам и как проходить тестирование.
Прохождение тестирования повлияет и на выставление оценки
-
Эдуард,
Не могу с Вами не согласиться :)
veta и StUtk,
Давайте теперь описывать детально спецификацию каждого ВИ. И Выкладывайте по мере готовности каждого. Когда ожидать описание первого ВИ?
-
На мой не искушенный взгляд следует понять, что количество ВИ у нас возрастет по мере анализа имеющихся.
-
Извиняюсь за отсутствие.
Коллега StUtk в отпуске, но постараемся справиться без него пока :)
Первый ВИ 04. Управлять справочниками ждать завтра ближе к вечеру. :)
-
Коллеги, не могу удержаться от совета - начните с описания основных ВИ, т.е. тех, которые реализуют целевые функции системы.
И еще вопрос, если позволите: структура описания ВИ согласована?
-
Водолей, на мой взгляд, ВИ управлять справочниками подходит, потому что начинается все с него и в зависимости от того, как мы будем управлять справочниками, будут зависеть все остальные ВИ. Можно сказать это и является одной из основных функций.
Струкутра описания планировалась быть такой:
Намиенование ВИ
Краткое описание
Основной сценарий ВИ с вариантами
Альтернативный сценарий
Замечания и дополнения приветствуются :)
-
Вы неправильно меня поняли.
Насколько я понимаю, Ваша система создается с определенной целью. И эта цель не "управлять справочниками".
Справочники - это обеспечивающая функция, она нужна "чтобы всё работало". Ессно, без нее сложно представить полноценное приложение. Но на мой взгляд, в первом релизе (даже в отношении описания ВИ) эта функция стоит не на первом месте, так как она во многом типовая, и даже при наличии каких-либо наворотов в ее реализации, наличие этой функции не определяет достижения целей приложения.
Поэтому я и предложил выбрать другие ВИ, в большей степени отвечающие целям системы в целом, в качестве первоочередных для описания.
Подумайте над этим. Вы сэкономите себе и Эдуарду массу времени.
По структуре описания ВИ предложу добавить "цель ВИ"
P.S. Всё сказанное выше является моим личным мнением, основанным на "рекомендациях лучших собаководов" и собственном опыте :о))
-
Читаю цели создания системы из концепции:
№ Цель
G1 Увеличить актуальность, достоверность и своевременность данных об успеваемости студентов, собираемых с различных уровней орг. структуры ВУЗа
G2 Ускорить получение деканатами актуальных и точных данных для формирования ведомостей и приказов
G3 Упростить процедуру учета информации о состоянии личных данных и посещаемости студентов
G4 Ускорить представление данных в вышестоящие отделы
G5 Снять с преподавателей рутинную работу по обработке данных успеваемости студентов
G6 Cократить время, требуемое для получения данных о состоянии успеваемости студентов, до 2 мин
G7 Уменьшить объем работы преподавателей по проведению и проверке тестов
G8 Улучшить качество собираемых статистических и аналитических (по успеваемости, по рейтингам студентом, по предметам и т.п.) данных
G9 Увеличить престиж и рейтинг ВУЗа
Судя по первой цели (хотя м.б. это у меня она первая), цель создания системы - систематизировать различные данные, касающиеся аттестации студентов, которые циркулируют внутри струкутры по имени ВУЗ. Эту роль как раз и будут выполнять различные справочники.
Или я опять не так понимаю? :-\ подскажите...
-
Я так понимаю, что Вы не так понимаете :о)) Или у нас сильно разное представление о справочниках. Я, например, могу предположить, что в справочниках ведется перечень кафедр, список преподавателей, групп, предметов и т.п.
Как я уже сказал, без них было бы сложно представить полноценную систему. Но, поверьте, при повышении актуальности, достоверности и своевременности данных об успеваемости студентов они играют не самую основную роль. Здесь важнее так называемые транзакционные данные, т.е. данные о полученных студентами отметках, выполненных заданиях и контрольных мероприятиях и т.п.
Аналогично по другим целям.
Поэтому, на мой взгляд, важнее "фиксировать успеваемость", "управлять тестовыми материалами", "получать задания", "проходить тесты" и т.п. - это и есть основные функции системы. А справочники?.. Они нужны, но в данном случае - они не самоцель.
Хотя это был лишь совет, безусловно, можете делать по своему...
-
Водолей, согласна с Вами :)
Но как бы мы ни выясняли, задание менеджера было пока описать ВИ Управлять справочниками.
1. Наименование ВИ: Управлять справочниками
2. Цель ВИ: Создать, заполнить и содержать в актуальном состоянии справочники данных, необходимые для проведения аттестации студентов.
3. Краткое описание ВИ: Сотрудники ВУЗа, имеющие определенные пользовательские права, добавляют, редактируют, удаляют справочники деканатов, кафедр, дисциплин, преподавателей, студентов.
4. Описание сценариев:
1) Основной сценарий:
1.1. Сотрудник ВУЗа, имеющий соответствующие права, создает справочник.
Вариант А:
1.2-А. Сотрудник ВУЗа заполняет справочник данными.
Вариант Б:
1.2-Б. Сотрудник ВУЗа, создавший справочник передает его для заполнения его данными другим Сотрудникам ВУЗа.
1.3. Сотрудник ВУЗа, имеющий необходимые права, вносит изменения (добавляет или удаляет данные) в справочнике.
1.4. Сотрудник ВУЗа удаляет справочник.
2) Альтернативный сценарий:
2.1. Сотрудник ВУЗа открывает справочник.
2.2. Сотрудник ВУЗа просматривает необходимые ему данные.
2.3. Сотрудник ВУЗа закрывает справочник.
Вопрос:
1. нужно ли описать в спецификации перечень справочников?
2. должна ли быть действующим лицом сама Система?
-
Раз уж я встрял - отвечу от себя.
0. Я бы предложил построить ВИ работы со справочниками по-другому, но это вообще-то дело Вашего менеджера. Так как в приведенном виде этот ВИ, по-моему, бесполезен.
1. В любом случае (вне зависимости от формы описания ВИ) в спецификации должен быть перечень справочников. т.е. ответ "ДА"
2. Тоже "ДА". Она [система] ведь тоже что-то делает (правда, это еще придется запрограммировать, но тем не менее ее действия должны быть понятны пользователю.
Вопросы по ходу:
1. А справочники Вы будет создавать с помощью системы? И как часто нужна будет эта функциональность, например, для справочника предметов?
2. Что значит "заполняет справочник данными"? Какими? Как?
3. Зачем удалять справочник? А что произодет с транзакционными данными прошлого года обучения, при создании которых он использовался?
Любимый вопрос: С чего начинается работа со справочником? Чем заканчивается? (это, кстати, насчет структуры описания ВИ)
-
1) Основной сценарий:
1.1. Сотрудник ВУЗа, имеющий соответствующие права, создает справочник.
Вариант А:
1.2-А. Сотрудник ВУЗа заполняет справочник данными.
Вариант Б:
1.2-Б. Сотрудник ВУЗа, создавший справочник передает его для заполнения его данными другим Сотрудникам ВУЗа.
1.3. Сотрудник ВУЗа, имеющий необходимые права, вносит изменения (добавляет или удаляет данные) в справочнике.
1.4. Сотрудник ВУЗа удаляет справочник.
2) Альтернативный сценарий:
2.1. Сотрудник ВУЗа открывает справочник.
2.2. Сотрудник ВУЗа просматривает необходимые ему данные.
2.3. Сотрудник ВУЗа закрывает справочник.
veta, нужно еще писать действия системы. Т.е пользователь что-то делает, а система на действие всегда отвечает неким откликом. Иначе у вас получается не взаимодействие Пользователь - Система, а монолог по типу "Пользователь кидает камушки в пропасть"
-
Я бы предложил такой бы формат:
1. Наименование ВИ
2. Цель ВИ
3. Действующие Лица
4. Предварительные условия
5. Основной сценарий
5.1. ....
5. Альтернативные сценарии
5.1. АС 1
5.1.1. ...
5.2. АС 2
5.2.1. ....
6. Исключения
6.1. И1
6.1.1. ...
6.2. И1
6.2.1. ...
7. Пост условия
Подразумеваем, что уровень ВИ по Коберну - это уровень целей пользователей.
В основной сценарии предлагаю написать про добавление элемента справочника, в альтернативных написать про редактирование, удаление, просмотр (фильтрацию, сортировка и т.д.), в исключения написать про то, как Система должна реагировать в ошибочных случаях.
Как пример написания спецификации ВИ (в том числе и по справочникам) можно посмотреть в приложенном файле.
Остальное вроде сказали.
Водолей,
Предлагаю описывать ВИ в последовательности написанной Эдом, потом протрассируем ВИ к Целям и поймем в чем мы были неправы. Это же учебный проект, хотя ваша последовательность действий более правильная в боевом применении.
-
не вопрос.
Но о сказанном про удаление все-таки подумайте. Я до сих пор в ярких красках помню реакцию одного заказчика при упоминании термина "удаление данных" :о))
-
Всем комментирующим спасибо!
Замечания учла, буду работать. Постараюсь к завтрашнему полудню выложить более содержательную версию.
-
Раз мы описываем сценарий для ВИ Управлять элементами справочника, значит должен быть где-то ВИ Создать справочник, правильно? Нужно ли его ставить в предусловие для этого ВИ?
Удаление решила все-таки оставить, нужная операция, не весь же мусор хранить в справочниках. В идеальной системе его, конечно, нет, но на практике чего только не насоздают :)
Сценарий ВИ для добавления элемента справочника.
-
Veta,
Мои замечания:
1. Разве так назывался ВИ на ДВИ?
2. Не понятно назначение предусловия по наличию справочников. У нас же есть ДБО, там все сказано - какие сущности должна содержать система
Кстати, можно уже Добавлять атрибуты в сущности на ДБО
3. "1.4.2. Система открывает окно Справочника, отображает его элементы."
Я бы сказал так: 1.4.2. Система открывает окно Справочника, отображает список элементов Справочника.
4. Какие поля в Справочнике Пользователь заполняет? Должна быть ссылка на БО или описание формы
5. 1.4.8. - где описана проверка? нужна ссылка на БПравило
6. 1.4.11 - 1.4.113 - должно быть вынесено в отдельный поток исключения
7. "1.5.1.3. Сотрудник ВУЗа выбирает функциональность «Редактировать элемент в Справочник»."
1.5.1.3. Сотрудник ВУЗа выбирает необходимый элемент из списка и выбирает функциональность «Редактировать элемент в Справочник».
8. "1.5.1.4. Система показывает форму редактирования элемента в соответствии с правами доступа пользователя к Справочнику:"
1.5.1.4. Система показывает форму редактирования элемента в соответствии с правами доступа пользователя к Справочнику с заполненными значениями в полях выбранного элемента
9. А нужен ли п. 1.5.2., может его совместить с фильтром и сортировкой?
По п. 3-8 см. по всем сценариям.
З.Ы, С понедельника я в отпуске на 2 недели, поэтому пишите спеки по остальным ВИ и выкладывайте, м.б .кто-то будет проверять и выставлять замечения.
-
Ну что, все всё бросили?
-
Ну что, все всё бросили?
Саша, люди в отпуске - на каникулах. А потом, имхо, все так затянулось. Правда можно проверить терпимость и целеустремленность:)
Еще мне думаетс, что-то мы где-то не так делаем. Я тут обчитался Унифицированным процессом от Трех Амиго, и подумал, что мы не совсем корректно ведем бизнес-моделирование, да и начала не особо верное взяли
-
А что мы не так сделали?
-
А что мы не так сделали?
процессы не выявили и не описали.
-
процессы не выявили и не описали.
Так мы это сделали в виде интересов ЗЛ
-
Так мы это сделали в виде интересов ЗЛ
Может я и ошибаюсь, но предлагаю прочитать часть книги Унифицированный процесс, в которой рассказывается о бизнес-моделировании.
Стр. 144 русскоязычного издания
Несмотря на различие отправных точек, существуют шаги, которые можно сделать в большинстве случаев. Это позволяет нам предложить типовой рабочий процесс.
Такой рабочий процесс включает в себя следующие шаги, которые обычно не выполняются по отдельности
О Перечисление возможных требований.
О Осознание контекста системы.
О Определение функциональных требований.
О Определение нефункциональных требований.
....
Осознание контекста системы. Множество людей, вовлеченных в развитие программного обеспечения, являются специалистами в вопросах, имеющих отношение к программному обеспечению. Однако чтобы верно определить требования
и правильно сформировать систему, ключевые разработчики — в частности, архитектор и некоторые старшие аналитики — должны понимать контекст, в котором работает система.
Имеется по крайней мере два подхода к описанию контекста системы в форме, доступной для разработчиков программ: моделирование предметной области и бизнес-моделирование. Модель предметной области описывает важные понятия контекста как объекты предметной области. Предметная область при этом связывает эти объекты друг с другом. Идентификация и наименование этих объектов помогают нам разработать словарь терминов, который поможет каждому, кто работает над системой, лучше ее понимать. Впоследствии, когда мы будем проводить анализ и проектирование нашей системы, объекты предметной области помогут нам распознать некоторые классы. Как мы увидим далее, бизнес-модель может быть представлена как надмножество модели предметной области. Она содержит доменные объекты, и не только их.
Цель бизнес-моделирования состоит в описании процессов — существующих или воспринимаемых — для того, чтобы понять их. Бизнес-моделирование — единственная часть бизнес-инжиниринга, которую мы будем использовать в этой книге
[39]. Удовлетворимся замечанием, что бизнес-инжиниринг очень похож на бизнес-моделирование, но имеет своей целью также улучшение бизнес-процессов организации. Когда аналитики моделируют бизнес, они получают обширную информацию
о контексте программной системы и отражают ее в бизнес-модели. Бизнес-модель определяет, какие бизнес-процессы должна поддерживать система. Кроме идентификации вовлеченных в бизнес бизнес-объектов или объектов предметной области, бизнес-моделирование также устанавливает компетентности, необходимые для процессов: работников, их обязанности и действия, которые они должны выполнять.
Это знание является определяющим при идентификации вариантов использования.
Мы вскоре обсудим этот вопрос. Фактически подход бизнес-инжиниринга для определения требований при разработке бизнес-приложений является наиболее системным [39].
Архитектор и руководитель проекта совместно решают, ограничиться ли моделью предметной области или идти до конца и разрабатывать полную бизнес-модель, а может быть, не строить никакой модели вообще.
Понимание контекста системы с помощью бизнес-модели
Бизнес-моделирование — это способ разобраться в бизнес-процессах организации. Но что если вы работаете с системой, которая не имеет никакого отношения к тому, что большинство людей понимает под словом «бизнес»? Например, что мы
должны делать при разработке сердечного электростимулятора, антиблокировочной системы торможения для автомобиля, контроллера фотоаппарата или системы беспроводной связи? В этом случае мы по-прежнему можем создавать бизнес-
модели этих систем, определяющие программную систему, которую мы собираемся разрабатывать. Эта система (часть человеческого органа, часть автомобиля, фотоаппарата, переключатель) — будет «бизнес-системой» для встроенного программного обеспечения. Это будет заметно по высокоуровневым вариантам использования системы, которые мы кратко рассмотрим. Наша цель — выделение вариантов использования программного обеспечения и бизнес-сущностей, которые будут поддерживаться программным обеспечением. Для того чтобы сделать это, мы должны углубиться в моделирование ровно настолько, насколько нужно, чтобы разобраться в контексте. Результатом этой деятельности будет модель предметной области, порожденная нашим пониманием функционирования изученной «бизнес-системы».
Технически бизнес-моделирование поддерживается двумя типами моделей UML: моделью вариантов использования и объектной моделью [57]. Обе они определены в бизнес-расширении UML.
Как разработать бизнес-модель
Бизнес-модель разрабатывается в два приема. Это происходит следующим образом.
1. Разработчики бизнес-модели должны создать бизнес-модель вариантов использования, идентифицирующую актантов, и бизнес-варианты использования, в которых участвуют эти актанты. Эта бизнес-модель вариантов использования позволит разработчикам модели лучше понять, какой результат приносит бизнес его участникам.
2. Разработчики модели должны разработать объектную бизнес-модель, состоящую из сотрудников, бизнес-сущностей и рабочих модулей, которые совместно реализуют бизнес-варианты использования^ С этими объектами связываются бизнес-правила и другие нормы бизнеса. Цель этого шага состоит в том, чтобы создать сотрудников, бизнес-сущности и рабочие модули, которые реализуют бизнес-варианты использования настолько эффективно, насколько это возможно — то есть быстро, точно и недорого.
Бизнес-моделирование и моделирование предметной области похожи друг на друга. Фактически, мы можем считать моделирование предметной области упрощенным вариантом бизнес-моделирования, в котором мы сосредоточиваемся исключительно на «предметах», то есть классах предметной области или бизнес-объектах, с которыми работают сотрудники. Это означает, что классы предметной области и бизнес-объекты — очень близкие понятия, и мы будем использовать попеременно то один из этих терминов, то другой.
Однако между бизнес-моделированием и моделированием предметной области имеются серьезные различия, которые говорят в пользу выполнения более формальной процедуры бизнес-моделирования:
О Классы предметной области возникают из базы знаний, составленной несколькими специалистами по проблемной области, или просто из общих соображений (например, из знания о других классах предметной области, спецификации требований и т. п.), относящихся к похожим на нашу системам. Бизнес-объекты же выделяют путем опроса клиентов бизнеса, вычленения бизнес-вариантов использования и последующего выбора объектов. При подходе, используемом в бизнес-моделировании, включение сущности в бизнес-модель должно оправдываться использованием этой сущности в бизнес-варианте использования.
Эти различные подходы обычно приводят к разным наборам классов, ассоциаций, атрибутов и операций. При моделировании предметной области можно проследить путь от классов назад к опыту специалистов по проблемной области. При бизнес-моделировании можно проследить потребность в каждом элементе модели назад к клиентам.
О Классы предметной области содержат множество атрибутов, но обычно содержат мало операций или не содержат их вовсе. Для бизнес-объектов это не так. Бизнес-моделирование позволяет идентифицировать не только сущности, но и всех сотрудников, которые участвуют в реализации бизнес-варианта использования, используя эти сущности. Кроме того, при бизнес-моделировании мы определяем способы использования сотрудниками этих сущностей посредством операций,
которые должна позволять выполнять каждая сущность. Эти операции также будут получены из требований и могут быть отслежены до клиентов.
О Список сотрудников, обнаруженных при бизнес-моделировании, используется как исходная точка для определения первоначального набора актантов и вариантов использования для информационной системы, которую мы создаем. Это позволяет нам отслеживать каждый вариант использования в информационной системе через сотрудников и бизнес-варианты использования назад, до клиентов.
Мы займемся этим в главе 7. Кроме того, как было описано в главе 3, каждый вариант использования может быть прослежен до составляющих систему элементов. Итак, мы можем заключить, что комбинация бизнес-моделирования и подхода к разработке программного обеспечения, предлагаемого Унифицированным процессом, позволят нам непрерывно отслеживать потребности клиента—в бизнес-процессах, сотрудниках и вариантах использования и коде программы.
При использовании же одной модели предметной области нет никаких очевидных способов отследить требования в промежутке между моделью предметной области и вариантами использования системы.
-
Эд,
ИМХО ключевая фраза здесь вот эта:
Архитектор и руководитель проекта совместно решают, ограничиться ли моделью предметной области или идти до конца и разрабатывать полную бизнес-модель, а может быть, не строить никакой модели вообще.
Мы ограничились ДБО и описанием интересов ЗЛ, ИМХО этого было достаточно, чтобы понять контекст.
Опять же авторы предлагают единственный подход к Б-Моделированию - это БВИ, хотя ИМХО для этого лучше подходят классические нотации описания БП.
-
Опять же авторы предлагают единственный подход к Б-Моделированию - это БВИ, хотя ИМХО для этого лучше подходят классические нотации описания БП.
Не важно строить БВИ или классическое нотации БП. Кстати, а что такое классические нотации БП? Важно оттолкнуться от процессов. Т.е. применить процессный подход
Цель бизнес-моделирования состоит в описании процессов — существующих или воспринимаемых — для того, чтобы понять их.
Мне кажется мы их как-то упустили из вида.
-
Извиняюсь за долгое отсутствие, Эдуард совершенно прав :)
2. Не понятно назначение предусловия по наличию справочников. У нас же есть ДБО, там все сказано - какие сущности должна содержать система
насколько я поняла, речь о последней ДБО http://www.uml2.ru/forum/index.php?topic=1106.msg13782#msg13782
А где здесь инфа о том, что справочники уже есть в системе? ???
4. Какие поля в Справочнике Пользователь заполняет? Должна быть ссылка на БО или описание формы
Ссылка на БО в ДБО? Мы будем описывать формы или это формальная ссылка?
Я готова продолжать работу :)
-
насколько я поняла, речь о последней ДБО http://www.uml2.ru/forum/index.php?topic=1106.msg13782#msg13782
А где здесь инфа о том, что справочники уже есть в системе? ???Ссылка на БО в ДБО? Мы будем описывать формы или это формальная ссылка?
Ну хорошо, если настаивайте, то давай оформим это отдельными требованиями - что должно быть при развертывании приложения, но не будем мешать это в ВИ.
Я готова продолжать работу :)
Отлично продолжаем описывать спеку ВИ и выкладывать на суд.
-
bas, тогда отдельные требования будут в общей концепции системы, перед пунктом о развертывании приложения?
исправленный сценарий и описание форм, куда ссылаюсь.
в конце сценария есть наметки на БП. Чтобы был ясен смысл.
Приношу извинения, что так долго...
Жду комментариев.
-
Прошу прощения, отсутствовал по уважительной причине.
Данная тема ещё актуальна? =)
-
Коллеги,
Сорри, но сейчас полный загруз по делам, совсем некогда.
Если кто-то займется проверкой, будет здорово. Где наш заказчик??
StUtk,
Можно с veta связаться и взаимно проверить спеки ВИ.
-
Сорри, но сейчас полный загруз по делам, совсем некогда.
Если кто-то займется проверкой, будет здорово. Где наш заказчик??
Ну это ваши трудности господа. К заказчику какие вопросы? Есть? отвечу :)
-
Ну это ваши трудности господа. К заказчику какие вопросы? Есть? отвечу :)
Есть вопросы - нужно проверить пользовательские требования и высказать свои замечания
-
Очень интересная и полезная для меня тема! =)
-
ИМХО Шаблоны Документов нужно взять у Вигерса. Они прикреплены к этому сообщению.
Саша, поскольку Вигерс (снова?) начал продавать эти шаблоны, а деньги направляет на поддержку парализованного консультанта, то я думаю, что продолжать распространять эти шаблоны бесплатно не очень этично.
Можно поставить ссылку на http://processimpact.com/goodies.shtml, 150 рублей заплатить для тех, кому надо, не проблема
-
Денис, согласен, убрал.
Если где-то еще найдете, скажите, уберу.
-
Всем доброго дня!
Мне нужно наработать навык построения диаграмм бизнес-процессов, поэтому я решил постфактум поучаствовать в моделировании вышеизложенной ИС.
К сожалению, вложенные файлы уже не доступны для просмотра(если у кого остался какой-нибудь итоговый документ по данной задаче, то просьба перезалить его, буду благодарен), поэтому нет смысла читать всю ветку без конкретных примеров обсуждения.
Я решил взять за основу только это сообщение http://www.uml2.ru/forum/index.php?topic=1106.msg11612#msg11612 (http://www.uml2.ru/forum/index.php?topic=1106.msg11612#msg11612) и по нему делать различные диаграммы.
Для начала use case как я его вижу. Просьба указать на недочеты.
-
Просьба указать на недочеты.
1) Никогда не соединяйте варианты использования коммуникациями (ассоциациями) -- сплошными линиями. У этих связей на одном конце должно быть действующее лицо, а на другом -- ВИ.
2) Избегайте связей обобщения (наследования) между вариантами использования, тем более множественного наследования. Обобщение ВИ предполагает довольно непростое их описание, которое, скорее всего Вы не сможете составить, или составите с большим трудом.
3) Попробуйте начать с простой диаграммы ВИ, где будут указаны только ВИ уровня цели пользователя и не будет никаких связей между ВИ. Затем составьте текстовые описания. По мере составления описаний Вы можете придти к выводу, что следует завести расширения, включаемые ВИ и/или ВИ-наследники. И только в таком случае будет иметь смысл новая версия диаграммы со связями включения, расширения, наследования.