4891

RUP EUP AUP OpenUP / Re: Создание русскоязычной версии и развитие процесса OpenUP/Basic

« : 26 Сентября 2007, 18:24:49 »

с технической точки зрения это слово переводится как наведение, во всех остальных случаях - это руководство.

Наверное не стоит заморачиваться и оставить именно как руководство с использованию (рекомендации по использованию)

4892

Обучение / Требуются задачи на моделирование конечных автоматов или диаграмм состояний

« : 26 Сентября 2007, 17:12:52 »

В течение ряда лет я преподаю дисциплину по кодовым названием Моделирование систем.

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

Среди развитых инструментов Simulink имеется расширение StateFlow, представляющее собой графическую среду моделирования конечных автоматов, основанную на карта Харела - прямой аналог диаграмм состояний в UML. Думаю, диаграммы состояний были реализованы на основе карт Харела.

У меня есть несколько задач на использование концепции StateFlow для изучения детерминированного и вероятностного конечных автоматов.

Поскольку изучение этого предмета происходит раньше или параллельно с изучением ООП, мне вдруг пришла в голову идея как-то связать изучение конечных автоматов и диаграмм состояния вместе.

Диаграммы состояний в UML применяются для описания поведения объекта или системы в целом. Таким образом, можно связать формирование диаграмм состояний с их имитационным моделированием в StateFlow.

Но что-то не придумывается как это сделать.

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

Есть какие-то идеи? Задачки ? Прошу публиковать здесь. Их реализацию будут пытаться сделать и публиковать результаты.

4893

RUP EUP AUP OpenUP / Re: Создание русскоязычной версии и развитие процесса OpenUP/Basic

« : 25 Сентября 2007, 19:05:01 »

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

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

Например, capture - я переводил по-разному и остановился на переводе фиксировать.
Что-то типа вариант использования фиксирует функциональные требования к системе.

4894

RUP EUP AUP OpenUP / Re: Создание русскоязычной версии и развитие процесса OpenUP/Basic

« : 25 Сентября 2007, 14:23:36 »

Отличный анализ.

Однако давайте посмотрим на понятие фаза с другой стороны.

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

Этап и стадия скроее подходят к некоторой восходящей последовательности. Хотя, конечно, вполне можно сказать фаза развития, стадия развития, этап развития - и смысл вряд ли теряется.

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

Для трассировки можно давать переводы с пометкой ГОСТ или тому подобное

4895

Конференции Семинары и Тренинги / Re: 1-й Осенний семинар: подготовка

« : 24 Сентября 2007, 19:22:26 »

Очень интересная тема - жаль не поприсутствую

4896

ПО Аналитика / Re: Ситуация на рынке UML-средств

« : 24 Сентября 2007, 18:01:54 »

Тут и появляется фигура аналитика  , который для пользователя (в его понимании) является программистом, а для программиста - заказчиком (формализует представления заказчика о продукте).

Интересное определение роли аналитика в OpenUP.

роль, представляющая интересы ЗАКАЗЧИКА и КОНЕЧНЫХ ПОЛЬЗОВАТЕЛЕЙ

4897

Обучение / Re: Требование к содержанию квалификационной работы

« : 24 Сентября 2007, 13:27:13 »

А кого готовите-то? "Информационные системы и технологии" - это слишком общее название. Как специальности называются?

Специальность так и называется. Она определена направлением 230200 Информационные системы и имеет название 230201 Информационные системы и технологии. Данное направление формирует куст специальностей Информационные системы в..., а специальность Информационные системы и технологии как раз первая.
Кого готовим вопрос? интересный, ибо я все 7 лет пытаюсь выяснить. Судя по чтению ряда экономических дисциплин - ближе к ИС в экономике. Анализируя программу, можно сказать специалист в области информационных систем ну а специализация у каждого может быть своя. Точно могу сказать не программистов, нет направленности на архитекторов. Скорее все-таки аналитиков, возможно архитекторов баз данных.

4898

Проектирование / Re: FAQ по Проектированию систем

« : 23 Сентября 2007, 21:29:07 »

Денис, мне кажется, за основу все-таки надо взять определение Когаловского, которое перекликается с твоим пониманием вплоть до запятой, но при этом является опубликованным. Книга к тому же имеет гриф Лекции МГУ.

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

Хотелось бы все-таки понять степень родства АИС и ПО, что чему подчинено. Не является ли АИС - подмножеством software. Или же АИС есть одна из сторон использования software.

Российские ГОСТы ориентированы на проектирование именно АС (в нашем понимании АИС), в то время как западные образцы говорят лишь об разработке software.

Мне кажется это достаточно важный аспект. Терминологическая чистота - есть зрелость науки, методологии. А тут получается определенная двусмысленность.

Тем более FAQ посвящен проектированию систем, а каких? если АИС или систем с использованием ПО - это одно, если вообще - то можем ли мы так смело говорить о проектировании системы вообще?

4899

Обучение / Re: Требование к содержанию квалификационной работы

« : 23 Сентября 2007, 20:32:14 »

Вот какая мысль пришла в голову.

Дискуссия по поводу содержательной части рекомендаций к дипломному проектированию с моим коллегой зашла в тупик.
Коллега настаивает на использовании ГОСТ, как единственной разумной альтернативе при описании и документировании цикла разработки АС или АИС.
Я считаю, что альтернатив несколько - они могут определяться общей методологией разработки или  процессом разработки.
Коллега утверждает, что одно другому не противоречит.
Я полагаю, что ГОСт - является методолгией структурного подхода, а следовательно у студентов, практикующих объектный подход, возникнеть необходимость затрачивать определенные усилия для адаптации используемого подхода или методологии к ГОСТу.

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

Поэтому требования к ИС неравны требованиям к программному обеспечению, и требования к программному обеспечению есть подмножество требований к ИС.

Исходя из этой логики, получается коллега прав, утверждая необходимость использования ГОСТов. Например, модель FRUPS+ не содержит таких понятий как организационное обеспечение, правовое обеспечение и некоторые другие. Или же я не прав, и все это входит в раздел business rules?

Стоит ли при разработки АИС учитывать главным образом вопросы разработки software.
Можно ли полагать в настоящий момент, что АИС - просто некоторый класс software?

Кто что думает по этому поводу?

4900

Консалтинг и Внедрение / Re: Выбор системы электронного документооборота

« : 23 Сентября 2007, 19:57:50 »

3) Где можно найти описание DFD нотации на русском языке. Также хотелось бы посмотреть  и нотацию IDEF3.

Interface.ru поиск.
Книги В. Маклакова
Книги Калянова
Книги Черемных и др.
Кое-что можете обнаружить в моей подборке: http://www.isuct.ru/~ivt/books/
Смотрите разделы ИС, CASE_средства

4901

ПО Аналитика / Re: Ситуация на рынке UML-средств

« : 23 Сентября 2007, 19:55:42 »

Здесь явно масонский заговор

4902

Консалтинг и Внедрение / Re: Выбор системы электронного документооборота

« : 22 Сентября 2007, 23:49:23 »

В методолгии Aris имеется модель данных(потоки и структура). Данную модель можно использовать для создания модели документооборота?

Если Вы имеете в виду диаграммы типа DFD, то почему нет? Очень даже можно.
Потоки показывают сами документы (структура показывается отдельно), центры обработки - процессы или системы, хранилища - элементы накапливания данных - документов

4903

Термины и Определения / Re: Термины: Swimlane

« : 22 Сентября 2007, 22:08:26 »

2. "плавательная дорожка" - с кавычками
я за этот вариант, потому что так понятнее всем, кто читал книги по UML. Если назвать коридор или что-нибудь типа того - некоторые люди будут долго смеяться...=) и говорить - а вот был такой парень, который "плавательную дорожку" называл коридором...=)))))))))

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

4904

Сообщество Аналитиков / Re: Ваше базовое образование

« : 21 Сентября 2007, 18:08:11 »

Спрашивается, зачем так мучить детей?

Чтобы огранить бриллиант

4905

Обучение / Re: Опыт преподавания структурного анализа

« : 21 Сентября 2007, 18:06:28 »

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

Нет лабораторный практикум - чтобы тем было не много. У меня их примерно 5 или 6. Просто я отошел от той практики где типа на лабах студентам что-то объясняют, а потом они тут же делают по вариантам. Нет то уровень задач. Задачи слишком сложны сами по себе, ониже слабоструктурированы. Иначе бы и не было проблемы...

Какие приемы? Если можно поподробнее.

ну мозговой штурм - объясняю детали и вперед, поправляю контролирую как они делают это.

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

экспертные оценки (ранжирование, попарное сравнивание и т.п.) - фактически выделить значимую информацию которая принесет 80% успеха

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

группировки по смыслу, по некому признаку

выделение проблемы - понимание в чем причины проблемы, обнаружение корневой причины проблемы

формулировка цели. Проверка цели по SMART
 
могу использовать Ваши предложения

А когда же вы им объясняеете правила игры? как выдаете задание? Наверное всем примерно одно и тоже
 ведь им нужно как-то подготовится или все сразу экспромтом

Так на первом занятии и объясняю сразу все правила игры. Причем ВСЕ правила от сегодня и до зачета :-)

т.е на лабораторках?

Именно - лекции это святое, хотя и на лекциях их немного терроризирую - устраиваю летучки
 

А если окажется что группа пришла и совсем не подготовилась? Что делать ? Нужен ведь какой-то стимул, скажем оценка в журнале или зачет лаб. работы или еще как.

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

Как я понял типичные рекомендации:
1. Наводящий вопрос для детализации структуры и процессов происходящих в предметной области
2. Дискуссия членов группы по заданной преподавателем темы
3. Мозговой штурм (как я его понимаю - быстрая генерация идей с последующей фильрацией)
4. Что такое карты памяти?

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

 

Основная дискуссий цель -выделит ключевые  процессы в Пр. Обл.

Да в итоге именно это, чтобы группа увидела ключевые моменты в своей Пр Обл.

А как они фиксируют накопленное? сразу пишут функциональные требования и сценарии в Вариантам Исп.

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

Или На основе этих вопросв потом пишутся Фун.ТР.

в принципе так и должно быть
 

Интересно посмотреть как она выглядит!

ну я спрошу разрешение у студентов, хотя мне думается они будут возражать...

те каждая группа выступает скажем минут 10-20 а потом вопросы, дискуссия - как на защите диплома. интересно!

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

Как вы их назначаете? И кого? Лидер видимо говорит доклад по презентации, да?

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

Итак, план занятий таков
1 занятие . Вступление препод. Правила игры.  Выдача задания. разбиение на группы (по сколько человек?) Что потом? Сразу дискуссия?

Да. Рисую на доске 4 колонки и прошу студентов записываться в группы. Потом ребята рассаживаются. И начинают дискуссию. Я сразу прошу брать бумагу, и писать все что прийдет в голову. Естественно есть набор рекомендаций, образцов, которые во время обсуждения группа может обсудить..

2. занятие .  Студенты подготовились. Принесли вопросы, ответы, возможно описание предм. области. Дискуссия продолжается в  оснвном внутри групп? Уточнаяются некоторые моменты. Выявляются слабые места. Выдается задание подготовить презентацию.

Да идет дискуссия с преподавателем и внутри группы. Задание уже выдано на презентацию в начале 1. Ибо говрю на 3 занятие принести презентацию бла бла бла

3. занятие. выступления лидеров групп по презентации. Наблюдатели наблюдают и записывают. Выступил один начинаются дискуссия и вопросы затем другой и т.д. или дискуссия в конце? В завершении дискуссии кратко выступают наблюдатели со своей оценкой проектов   

Нет вся команда выходит и выступает. Я сразу говорю - оценивается вся команда. Хорошо подготовились - отлично, плохо - всем плохо. Обязательно учитываю кто как выступает - если только один - то снижаю - лидер не сумел вдохновить ребят или задавил авторитетом и то и это плохо. Так было в прошлом году, В этом году ребята как-то сразу поняли что к чем и хорошо вошли в роль. Некоторые настолько, что я и сам поверил, что передо мной генеральный директор или пиар-менеджер компании или бизнес-эксперт.
В прошлом году делали дискуссия после каждой защиты и потому пришлось проводить 2 занятия. В этом году я дискуссию оставил на потом. Мне показалось - это лучше. Я говорил - обсуждаем 1 команду, остальные задаем вопросы, команда отвечает. Налюдатели оппонетов высказывают общее мнение о презентации.
Как я и говорил лидер 4 команды - прирожденный проджект-менеджер. Тонкий аналитик. Дал прекрасные оценки, по крайней мере чисто презентационной логике

 

Резюме преподавателя. Группы разбиваются и продолжают работать над проектами в обычном режиме

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

А как их разделять ведь кому-то прийдется изменять Пред.О? или ПО одна а делают по своему?

Разделение произойдет после утверждения контектса - а это 3 занятия, т.е. на 6 занятие. Также будет дискуссия в рамках группы и преподаватель как помощник и консультант.
на 1 занятии этой фазы я показываю общие приемы работы в BPWIN и объясняю как строятся контексты. Очень даже может быть на базе такой же задачи. Но без оставления примера для изучения. Дело втом, что иногда примеры заразительны:-) Вернее чаще всего. Думать не охота - лучше сделать по шаблону. Но каждый ИТ проект это индивидуальность посколькуо одинаковых информационных моделей не бывает, бывают лишь похожие

Так они потом садятся за копмьютер и делают диграмму ВИ со сценариями так?

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

Как это понимать упор на форм. треб.?

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