4846

Бизнес-анализ и Целеполагание / Re: Обещанная статья про целеполагание

« : 23 Октября 2007, 19:28:29 »

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

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

Не всякий ИТ проект венчурный и инновационный. Если, например, система учета, выполненная на FoxPro переводится под MS SQL+Delphi при том, что все устраивает то, как работала предыдущая система - это ИТ проект с известной спецификацией требований, но цель его не создать новую организационную структуру, а расширить возможности имеющихся технических средств.

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

Согласен ссылок мало. Но тут могу сказать, что формат именно этого материала не позволяет излагать слишком отсушенным языком.

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

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

ну скажем http://www.tonich.ru/glossary/term/?id=37
http://www.hrm.ru/db/hrm/0A1C8BB8A0CA78E4C3256F8700534EF9/category.html
http://www.improvement.ru/bibliot/decision/decision04.shtm
Можно найти и более интересное.

Обзор литературы нужен, но до него надо еще дожить.

Обычно с него и начинается все. Я понимаю - это авторский материал, а не научная работа. Кончено, этим можно пренебречь.

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

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

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

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

Не все так просто, но попробуем.

Я и не настаиваю просто предлагаю... Решать тебе все равно.

4847

О Сайте и Форуме / Re: Внимание! Плановые работы на Сайте и Форуме.

« : 23 Октября 2007, 09:16:53 »

"Ангел-хоронитель" уже подзае, если честно.

Фи, Денис, как грубо :-)
А вообще нужно быстро решаться на переезд! Думаю переезд уже давно состоялся бы, если мы имели коллективную финансовую ответственность за него. Правда в сравнении с суммами, которые народ тратит, содержание сайта не так обременительно, но может имеет смысл переходить в ВИП зону или близкую к ней?
Соотвественно менять провайдера. Поскольку эдак недели другая такой работы - и всех посетителей и т.п. мы просто фактически растеряем

4848

Бизнес-анализ и Целеполагание / Re: Обещанная статья про целеполагание

« : 21 Октября 2007, 21:13:08 »

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

Не могу согласиться с примером. В данном случае речь идет не о системе и надсистеме, а об объекте управления и системе управления. Последняя должна удовлетворять принципу Эшби. это очевидно, но система управления не является надсистемой или суперсистемой (поскольку именно такой смысл скрывается под "над" в описании автора)

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

Не понятна логика выводов. Любой проект, а тем более инновационный (а ИТ проект как мне думается и относится к таковым, то есть венчурным связанным с риском), подразумевает вопросы организации, выбора средств и т.п.
Мне не ясно из статьи в чем разница системного происхождения цели и проблемного, и почему они противопоставляются?

если кроме создания ПО не планировалось больше ничего - это принципиальная ошибка создателей сайта

Это камень в известный мне огород? 

Для того, чтобы не нести бремя этого риска самостоятельно любой исполнитель, чем бы он не зарабатывал себе на жизнь, ДОЛЖЕН УМЕТЬ ФОРМАЛИЗОВЫВАТЬ И ФИКСИРОВАТЬ НА БУМАГЕ ЦЕЛИ, относящиеся к его обласи компетенции, ВЫБИВАТЬ ПОДПИСЬ ЗАКАЗЧИКА под этими целями и ПРИТЯГИВАТЬ ЗА ЯЗЫК в случае попытки нагрузить избыточной ответственностью за чужие просчеты.

Может легче государство поменять, а лучше Галактику

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

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

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

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

4849

Бизнес-анализ и Целеполагание / Re: Обещанная статья про целеполагание

« : 21 Октября 2007, 20:30:33 »

Хотел сразу отметить некоторый момент. Часто используется понятие модель требований. Это понятие довольно часто встречается и в иностранной, и отечественно литературе. Так же прослеживается и в case-инструментарии.

В очень интересной книге по требованиям: Элизабет Халл, Кен Джексон, Джереми Дик. "Разработка и управление требованиями"
<< Некоторые употребляют термин «моделирование требований». Это термин является неверным по сути. Моделируется реализация системы, а не требования к ней. Моделирование поддерживает наиболее творческий процесс - разработку реализации системы, выработку конкретных системных решений. Моделирование помогает инженеру уточнять и детализировать реализацию системы путем разбиения ее на компоненты при движении вниз от одного уровня требовании к другому. Требования это полный «снимок» того, что именно требуется от системы на каждом уровне. При этом детализация «снимка» увеличивается при движении вниз от уровня к уровню.>>

4850

Бизнес-анализ и Целеполагание / Re: Обещанная статья про целеполагание

« : 21 Октября 2007, 20:05:09 »

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

То что вторые счастливы - можно понять, но почему первые правы, да еще абсолютно?

Неплохо бы прикрепить возможность комментирования прямо в статье

4851

Бизнес-анализ и Целеполагание / Re: Обещанная статья про целеполагание

« : 21 Октября 2007, 20:02:22 »

80 просмотров и ни одного критического замечания. 1 отзыв в стиле "ЙОУ". кто знает, что это может означать?

Сережа, я честно не осили еще статью. Просто есть другие приоритеты. Почитаю выскажусь :-)

4852

Системный Анализ и Требования / Re: Взаимосвязь понятий, артефактов и работ при создании ТЗ

« : 21 Октября 2007, 20:01:23 »

1. Для того, чтобы понимать порядок и состав работ по созданию требований. В контексте разработки ПО.

В контексте создания какого ПО? Судя по твоим отзывом ПО у тебя особенно.

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

Учитывая, что ты рассматриваешь веб-системы, либо системы с приоритетностью веб-интерфейса, хотелось бы понять, что это значить приоритетность интерфейса? Приоритентность над функциональностью, атрибутов качества, архитектуры? Если так, то как это понимается?

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

В таком случае на кого рассчитано это техническое задание? Почему спрашиваю - потому как техническая спецификация - это уже часть проектного решения.

4. Архитектура накладывает ограничения на функциональную спецификацию, последнюю нельзя создавать в отрыве от неё.

С учетом предыдущего пункта можно ли понимать так, что используются некие готовые инструменты(cms, lcms, wiki ...)

5. У нас нет требований эргономики, вместо них сразу идёт дизайн. Можно пытаться называть это прототипами форм электронных документов, но, во-первых, это не прототипы, а окончательный дизайн, во-вторых, экраны развлекательного сайта имеют мало общего с понятием "форма электронного документа".

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

6. Вопрос не понял. Это из серии - имеет ли смысл фиксировать требования.

В смысле, а нужно ли тратить усилия на него? По крайней мере в таком формализованном виде...

4853

Системный Анализ и Требования / Re: Взаимосвязь понятий, артефактов и работ при создании ТЗ

« : 20 Октября 2007, 22:58:52 »

Хотелось бы задать вопрос:
1. для чего существует потребность такой взаимосвязи? Т.е. в каком контексте?
2. Какой процесс разработки ПО или ИТ системы заложен в данную взаимосвязь или эта модель применима к любому процессу, любой методологии?
3. Что в данном случае понимается под техническим заданием? Понятие ГОСТ или какое-то иное понятие?
4. Несовсем понятно направление стрелки от описания архитектуры к функциональной спецификации
5. Где место требованиям эргономики (usability)? Они представлены как я вижу только дизайном (причем это явно прототипы форм так называемых форм электронных документов)

6. Вообще имеет ли смысл составлять такое ТЗ, т.е. имеет ли смысл фиксировать это документально?

4854

О Сайте и Форуме / Re: Внимание! Плановые работы на Сайте и Форуме.

« : 19 Октября 2007, 17:24:24 »

Сань! а ты дампишь сайт и форум?
очень бы надо хоть раз в месяц. А то всякое может быть! Главное, чтобы у нас это хранилось а не у них на серверах на всякий случай.

Нужно не забывать дампить и файлы

4855

О Сайте и Форуме / Re: Внимание! Плановые работы на Сайте и Форуме.

« : 19 Октября 2007, 13:43:49 »

Агава опять жжет:

Что ж тут поделаешь - фоксмажорные обстоятельства

4856

Идеи и мозговой штурм / Re: Россия-Англия, делаем ставки

« : 19 Октября 2007, 07:51:03 »

Анатолий, Ваш прогноз оказался на высоте!

Ну и как всегда, по закону Парето, именно 20% сделали 80%!

4857

Системный Анализ и Требования / Re: Сбор требования или информации для неизвестного пока решения

« : 16 Октября 2007, 13:50:30 »

Спасибо, Shur. Интересный комментарий и дельные советы.

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

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

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

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

4858

Системный Анализ и Требования / Re: Сбор требования или информации для неизвестного пока решения

« : 16 Октября 2007, 09:43:55 »

С какой целью ты склоняешь его к комплексному обследованию, когда оно ему не нужно?

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

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

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

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

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

4859

Системный Анализ и Требования / Re: Сбор требования или информации для неизвестного пока решения

« : 15 Октября 2007, 23:08:53 »

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

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

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

Идеально, если он сам выговорит приемлемые формулировки, а не кивнет Вам в знак согласия.

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

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

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

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

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

Интересно спросить, как правильно задавать такие вопросы. И какие должны быть вопросы? Каковы ваши проблемы? Что мешает вам работать? Что раздражает вас в работе? Что делает вашу работу не комфортной? Чтобы вы хотели изменить? - Не являются ли эти вопросы слишком прямолинейны?

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

Очень хорошая рекомендация

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

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

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

Нельзя ли это прокомментировать некоторыми ассоциативными примерами?

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

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

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

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

4860

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

« : 14 Октября 2007, 19:50:20 »

В прошлую среду 10.10.07 состоялось очередное зачетное занятие. Напомню тема вторго задания составить контекст задачи.

Задача впрочем у всех примерно одинаковая. На вводном занятии этого цикла объяснил общие правила и приемы работы с BPWin и составления контекстной диаграммы. Для примера была взята аналогичная задача и рассмотрена референтная модель с сайта http://finexpert.ru. Немного переделанная, упрощенная и адаптированная.

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

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

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

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

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

В день зачета 1 группа была выделена в роль судей - наблюдателей. Другая должна играть роль обвинения, т.е. критиковать полученную модель. Третья выступает в роли адвоката. Выступающая группа в роли ответчика. Обвинение, адвокаты и ответчики меняфются местами. Группа наблюдателей-судей нет.

К сожалению 2 из 4 групп не были готовы. Конечно, виноватым оказался преподаватель. Неготовы оказались группы моего преподавателя-партнера.Якобы он им ничего не сказал. Это при том, что на протяжении каждого занятия я неднократно говорю, все задания, рекомендации по его выполнения, дополнительная литература выложены на сайте(к которому они имеют доступ).

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

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

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

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

В эту среду т.е. 17.10.07 ожидаем выступления отстающих групп, посмотрим сумели ли они сделать какие-то выводы