166

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

« : 18 Июня 2007, 12:55:31 »

Мне кажется, такое определение семантически не значимо. Поясню. Что такое swimlane в его предназначении. Показать зону, область ответственности действующего лица. Т.е. показывая и группируя те или иные действия в рамках swimlane мы тем способом обращаем внимание читателя на то, что конкретно делает именно это действующее лицо, в чем его отвественность, его функциональность.
http://ooad.asf.ru/standarts/uml/spr/Swimlane.aspx

В стандарте UML 2 понятие swimlane отсутствует в глоссарии, т.е. авторы станадрта не настаивают на точном понимании этого термина, но применяют его для пояснения использования понятия "partition" (фактически как синоним partion нижнего уровня в иерархических partition, хотя сам термин partion определяется в Superstructure UML 2.0.

В другом детище OMG - стандарте BPMN вводятся понятия Pool и Lane, которые являются аналогами parrtition и фактически используются для тех же целей.

Поэтому можно утверждать, что термин swimlane не является строго определенным. Но утверждать, что он семантически незначим, фактичиески (из определения понятия "семантика") означает, что это термин не имеет смысла. И, учитывая широкое использование этого термина во вполне осмысленных документах, с бессмысленностью (семантической незначимостью) этого термина никак нельзя согласиться.
Объявление этого термина семантически незначимым только санкционировало бы бездумное применение этого термина в русскоязычной литературе. Не слишком ли много англоязычных понятий в отчественно практике уже де-факто объявлено "семантически незначимыми"?

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

Sorry, но сути возражения не понял....

В Интернете можно найти такие варианты: просто дорожка и разделительная линия.
Просто дорожка - вполне нормально.

Предлагаю такие варианты:
зона (область, рамки, границы) ответственности

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

Ваш вариант хорошо ложится на опредление Pool и Lane в BPMN.
А просто "дорожка" ИМХО не годится, по крайней мере для Диаграмм деятельности UML, потому что эти диаграммы относятся скорее к бизнес-уровню и являются ИМХО, в большей мере, инструментом коммуникации аналитика и специалиста предметной области, а в бизнесе "дорожками" не мыслят.
 Лучше как раз использовать термины, которые были бы употребимы и для описания логики системного уровня и прдметной области. Общий термин работал бы на "привязку" элементов бизнес модели и элементов модели системного уровня.

167

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

« : 18 Июня 2007, 11:04:46 »

Предлагаю вариант - swimlane - "направление деятельности".

168

Теория моделирования и нотации / Re: Теория и принципы моделирования

« : 29 Мая 2007, 16:56:24 »

Если возвращаться к теме дискуссии, то можно поставить вопрос так - позволяют ли Синтаксис, Семантика и Прагматика популярных методик моделирования в достаточной степени описывать существующие и создаваемые системы? Вредит ли избыточная детализация моделей? Если да, то как её избежать?

Судя по тому, что OMG продолжает разрабатывать новые средства описания предметной области:
1. Business Motivation Model (BMM) Specification
 2. Semantics of Business Vocabulary and Business Rules (SBVR)

то OMG не считает вопрос создания средств моделирования закрытым. Один замах, судя по названиям, чего стоит!
Если обсуждать  достаточность существующих средств, то нужно бы уточнить:
1.   "достаточная степень описания" - достаточная для чего?.
2.   Какие качества существующих моделей (избыточноть?), которые мы связываем с используемыми средствами моделирования,  нас решительно не удовлетворяют?
3.   Что имеется в виду под избыточной детализацией моделей? Можно ли попытаться категориально проклассифицировать ситуации такой избыточности (чем вызвана, в частности, вызвана ли они именно средствами модлеирования, в чем проявляется)? Возможно, попробовать проиллюстрировать ситуацию такой избыточной детализации на примерах из тем данного форума ?

169

Теория моделирования и нотации / Re: Теория и принципы моделирования

« : 29 Мая 2007, 13:28:09 »

Хорошо, узкая. А какая ещё часть есть?

Семиотика моделирования:
1. Синтаксис - правила конструирования систем знаков (сложных знаков - схем, дигаграмм) из простых.
2. Семантика - смысл и значение знаковых систем
3. Прагматика - практика, приемы и способы использования знаковых систем субъектами и сообществами.

Средства моделирования, как инструменты, включают 1 и 2. Объять прагматику моделирования в форме некоторого OTC продукта вряд ли вообще возможно. Тем не менее без прагматики построение модели невозможно.

170

Теория моделирования и нотации / Re: Теория и принципы моделирования

« : 29 Мая 2007, 11:10:45 »

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

Ну меня, в общем, смущает немного 3й пункт...Модель должна упрощать реальность. Это относится и к диаграммам, где гуру советуют не перегружать модели второстепенными элементами, из-за того что она станет визуально непонятной и сложной. И к тому же в качестве примера можно привести различные математические модели, которые бывает невозможно (по ряду причин: из-за недостаточной мощности компьютеров, развитие науки и тд), и зачастую даже ненужно уточнять, т.е. необходимо использовать определенную степень приближения. Конечно согласен, что чем подробней мы опишем систему, тем проще нам с ней будет работать в дальнейшем, но опять же точность модели зависит от поставленной задачи...

Определить, является ли элемент важным или второстепенным невозможно вне контекста создания и использования модели. Как отметил  выше Galogen - моделирование инструмент деятельности, но важно уточнить: инструментом оно является в контексте (деятельности) использования модели. В контексте создания модели сама модель является целевым объектом процесса создания модели. Мы можем либо верифицировать модель на соответствие правилам в процессе её создания, либо опытным путем - на соответствие целям Зазказчика модели в процессе её использования. Априорно определить второстепенные детали исходя из внутренней логики самой модели невозможно. Вне контекста можно обсуждать только наличие или отсутствие внутренних противоречий в самой модели с точки зрения внутренних правил  самой модели.

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

Контекст практической деятельности  человека (бизнеса):
1. При моделировании человеческой деятельности мы пытаемся постигнуть логику бизнеса, которая была придумана человеком. Человеческая деятельность может носить системный характер и логика модели может быть распределенной по раличным професиональным специалиазациям. Но принципиально важно, что для устоявшихся относительно медленно изменяющихся процессов пытаться понять их логику гораздо менее рискованное занятие чем пытаться построить модель для решения научной проблемы. Применительно к практике моделирования (анализа) человеческой деятельности мы ограничены рамками интеллекта создателей (и пользователей) бизнеса. А как сказал герой одного фильма: «Что один человек собрал, другой завсегда разобрать сможет…». И это выгодно отличает с точки зрения возможностей моделирования человескую деятельность от природных процессов и явлений.
2. Субъективность целевых оснований человеческой деятельности (эмерджентность - её проявление) – наоборот, затрудняет моделирование человеческой деятельности, по сравнению с моделированием природы. Полет мысли некоторых Заказчиков существенно опережает возможности  моделирования её результатов.


Контекст научного моделирования:
В практике же научного моделирования ученый пытается постигнуть логику (замысел) природы (Лейбниц: «Cum Deus calculat, fit mundus - Как Бог вычисляет, так мир и устроен»), разрешить парадоксы и проблемы, возникшие на границе (или за гранью   разумной практики человека.
Ученый лишен возможность общаться с природой на природном человеческом языке (Галилей: «Природа разговаривает с нами на языке математики…»), еще меньше возможностей у ученого моделировать природу исходя из целей природного замысла.

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

171

Теория моделирования и нотации / Re: Теория и принципы моделирования

« : 27 Мая 2007, 23:44:59 »

Теперь предлагаю обсудить принципы моделирования, с которыми не очень согласен, из книги "Язык UML. Руководство пользователя" (Г.Буч, Д.Рамбо, И.Якобсон)
1. Выбор модели оказывает определяющее влияние на подход к решению проблемы и на то, как будет выглядеть это решение.
2. Каждая модель может быть представлена с различной степенью точности.
3. Лучшие модели - те, что ближе к реальности.
4. Нельзя ограничиваться созданием только одной модели. Наилучший способ при разработке любой нетривиальной системы - использовать совокупность нескольких моделей, почти независимых друг от друга

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

Присоединяюсь к предложению уточнить, с чем именно Вы не согласны в приведенной цитате?

172

Варианты Использования (Use Case) / Re: Статья: Варианты Использования. Обсуждение.

« : 26 Мая 2007, 13:38:07 »

Ух, тема интерфейсов прогрессирует. Ладно, как говорится - Devil is in the details. Чем отвечать на каждую фразу, думается, полезней рассмотреть конкретный случай: пользователю нужно просматривать список платежных поручений с возможностью фильтра по дате поступления. Другими словами, ему интересно просмотреть список документов задавая диапазоны дат. Я вижу здесь один сценарий - "просмотреть платежные поручения". Можете привести пример такого вот сценария?

Безотносительно к различию предложенных Вами вариантов описания механизмов соединения, очень странно в качестве цели (интереса) пользователя согласиться просто на "просмотр документов".  Какое отношение эта цель (интерес) имеет к столь детально разбираемой далее специфике механизмов установки соединения? Ведь эти механизмы никак не связаны ЯВНО (в тексте описания) не только с целью (просмотром), но даже с интерфейсной формой (один из механизмов, который действительно является средством "просмотра"). Выше Boatman уже писал о риске "исчезновения" ВИ как такового при утрате отчетливого представления о цели.

Важно уточнить, для чего именно собирается просматривать платежки пользователь. И, возможно, пользователь не один.
Возможно просматривать список платежных поручений нужно будет РАЗНЫМ заинтересованным лицам, которые будут решать на основании информации из платежки РАЗНЫЕ задачи?  Тогда еще, возможно, нужно будет решать, насколько оправданно делать один интерфейс для обоих пользователей... Т.е. хорошо бы еще понять -
1. ЗАЧЕМ пользователю нужно просматривать (с какой целью на бизнес-уровне).
2. Последовательность действий пользователя в ВИ, как способ достжения цели (сначала и отдельно на бизнес-уровне, затем на программно-архитектурном).
3. А от этого уже выстраивать логику интерфейсного взаимодействия пользователя и системы.

173

Варианты Использования (Use Case) / Re: Статья: Варианты Использования. Обсуждение.

« : 25 Мая 2007, 15:18:04 »

Есть статья - авторы пытаются увязать диаграммы UML c interface-driven подходои к разработке.

В самом общем виде тезисы авторов:
1. Поскольку ВИ задает способ взаимодействия пользователя с системой, такой способ должен обеспечиваться адекватными интерфейсными средствами. Каждый пользователь ассоцирован как с ВИ, так и интерфейсными средствами для выполнения действий в рамках конкретного ВИ. Диаграмма ВИ используется для укзания какой интерфейс для какого ВИ применяется.
2. Поля интерфейсной формы используются для потроения модели данных (диаграммы классов).
3. Логика взаимодействия с интерфейсной формой может быть описана средствами диаграмм последовательности и взаимодействия.

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

Возможно, если удобно мыслить классы модели сразу в интерфейсном представлении, такой interfce driven подход к описанию системы может служить альтернативой data-driven подходу. Но при этом остается аналогичным data-driven подходу, данные берутся все равно "из жизни" и документов, просто модель сначала рисуется в виде набора интерфейсных формы, а не дигарммы классов.
 
Неясно, возможны  ли проекты, в которых можно (насколько удобно) увидеть процессную модель за интерфейсныи формами (т.е. выявить ключевые процессы и их взаимосвязь по интерфейсам до формализации модели данных)?

174

Бизнес-анализ и Целеполагание / Re: IDEF ( or ARIS) vs Use Cases при описании БП

« : 23 Мая 2007, 23:45:13 »

Вот тут у меня появилась вопрос о границах наилучшей применимости (или не применимости) IDEF ( or ARIS) и  Use Cases при описании БП внутри организации.
Скорее даже интерсуют границы применимости ВИ, но решил расширить тему до IDEF ( or ARIS) vs Use Cases.

Если брать ВИ, то наилучшее их применение - это описание БП с точки зрения организации снаружи, с точки зрения RUP. Если же взять Кокберна, то можно спуститься и ниже - внутр организации. Но как это будет работать на больших проектах, на проектах по документообороту. Все ли БП будут охвачены, все ляжет в ВИ и Бизнес Правила (и много ли их будет).

Если же взять IDEF 0 и 3 (про ARIS плохо знаю, но рискну его сюда засунуть), то это как раз их стихия описания больших сложных БП именно внутри организации, особенно хороши они будут для документооборота и всяких учетных систем.

Что кто скажет?

Речь идет о диаграммах ВИ или о текстовом описании по Коберну?
Если речь о текстовом описании ВИ, то предлагается сравнить их с текстовми документами, генеримыми из под BPwin в результате работы с IDEF?

175

Бизнес-анализ и Целеполагание / Re: Бизнес-процессы верхнего уровня

« : 20 Мая 2007, 16:11:56 »

Shur, спасибо за конструктивный ответ, теперь есть над чем подумать.
Приходится делать диаграммы в ARIS'е, а с наиболее простыми методологиями там есть некоторые проблемы Но это не суть, рисовалка она и в Африке рисовалка. Текущий проект с бизнес-процессами очень косвенно связан, это лишь отправная точка для понимая бизнеса, естественно и требования к БП наиболее лояльные. Поэтому с такой степенью подробности, которую предлагает IDEF0 (или мне ближе DFD), к сожалению, просто возможности не имею изобразить. Поэтому даже не говорю об арисовском eEPC... хотя хотелось бы. В любом случае, Вы правы, надо выделить существенные блоки по видам деятельности, чтобы от них можно было отталкиваться...
Диаграмма визуально ужасно воспринимается, очень тяжелая. Для понимания человека, который не работает с БП, нужно делать диаграммы "каскадно"-структурированные, что далеко не всегда оказывается возможным.

Жаль, что у Вас нет возможности рисовать в BPwin. Там есть возможность автоматического "проваливания" связей между блоками верхней диаграммы на нижний уровень. Например, нарисовали биллинг и обслуживание сетей/ ремонты на верхнем уровне. Нарисовали связь между ними. Кликаете на один "ящик" вида деятельности в IDEF0, проваливатесь внутрь него на нижний уровень. А Вас там уже ожидает стрелочка от нарисованной на врехнем уровне связи. Если например, эта стрелочка исходящая заявка от биллинга для обслуживания сетей, иногда приходится подумать из какого "яшика" нижнего уровня (подфункции биллинга) нужно делать эту стрелочку исходящией.
К сожалению, не знаю есть ли в ARIS такой контроль связей на разных уровнях (а то можно нарисовать связь между деятельностями на одном уровне и потерять на другом - вложенном уровне, если делать все совсем врукопашную, скажем в Visio). Удобство выбора нотации заключается еще и в возможности использования инструмента рисования диаграмм, который будет в нужное время "хватать за руку" и отслеживать хотя бы правильность сопряжения диаграмм разного уровня (так сказать, на уровне диаграммного синтаксиса).

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

Вот как раз сейчас вопрос возник: Для правильного составления диаграмм желательно придерживаться одного уровня декомпозиции... Как себя проверить - не спустился ли я на более низкий уровень или наоборот?

Не очень понятно, в чем может быть проблема: если Вы на время забудте про уже нарисовнную диаграмму в Excel и нарисуете в IDEF0 как устроена организация на верхнем уровне (например, по видам специализированной детельности, как я предложил выше), то у Вас должно получить 3-4 блока, внутрь которых нужно класть то что нарисовано в Excel. То, что сложно положить внутрь конкретного блока, например, что нибудь связанное с финансовыми отношениями, нужно заводить отдельный блок (вид деятельности) верхнего уровня.

Такая врехнеуровневая нарезка на блоки очень небезобидное занятие, правила её выполнения не могут сведены к формальным синтаксическим и даже универсальным семантическим правилам. Фактически нарезка на такие блоки может задавать то, что назвается "система управления бизнесом". И возможны РАЗНЫЕ нарезки, которые соответствуют разным "системам управления". Если получится, что предлагаемая система управления не соответствутет фактически используемой в жизни, Вас точно не поймут. Может быть Ваша схема (система управления) отличная от фактической будет и лучше для бизнеса, но Вам придется её отдельно отстаивать и аргументировать.  У Вас уже есть сформулированные требования к критериям качества, эффективности системы? Что она должна дать для бизнеса? Очень важно, чтобы предалагаемая вами структура (верхнеурневая режде всего) могла быть объяснена и обоснована с точки зрения этих целей.
Например, "нарезка" по видам деятельности, которую я предложил выше, может быть не единственным возможным вариантом. Биллинг и обслуживание сетей может быть объединено в один верхнеуровневый производственно-технической блок , а договорная работа, решение  вопросов подключения клиентов, рабор жалоб, и предъявление исков и претензий выделен самостоятельный блок клиентского обслуживания. Постарайтесь критически отнестись к моим конкретным предложениям по выделению верхнеуровневых блоков, вы всё-таки ближе к конкретике Вашего проекта. Я предложил пример, чтобы проиллюстировать принцип.
Возможно, потребуется рассмотреть, несколько вариантов и лучше бы если последнее слово было за теми, кто реально по этой схеме управления будет работать: обсудите (итеративно, по мере увложения схемы) возможные варианты со специалистами Ваших предметных областей, особенно ответственных за принятие решений. Удачи.

176

Бизнес-анализ и Целеполагание / Re: Бизнес-процессы верхнего уровня

« : 20 Мая 2007, 12:47:25 »

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

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

Четкого направления определено не было, поэтому пришлось выделить самые простейшие моменты из DFD и SADT. В итоге получилось не очень понятно, потому что все-таки для любых диаграмм нужно использовать устоявшиеся правила, иначе фигня получится. Какую нотацию посоветуете? (нужно чтобы она была интуитивно понятной на 100%, т.е. чтобы ее понял человек никогда не работавший с бизнес-процессами.)

Раз Вы ознакомились с SADT, предалагаю довести дело до конца - сделайте диаграмму в IDEF0. Если использовать BPwin получится диаграмма из 3-4 "ящиков" деятельностей верхнего уровня, внутри которых будут упакованы результаты декомпозиции в виде отдельных диаграмм более низкого уровня, которые по сути являются частями уже нарисованной вами диаграммы в Excel. 
По диаграммам верхнего уровня будут видны взаимосвязи между биллингом, обслуживанием сетей, ремонтами. Когда вы покажете эту диаграмму специалистам из эти трех блоков, они еще укажут Вам  на неточности, которые нужно будет поправить. По диаграммам нижнего уровня можно будет сконцентрировать обсуждение со специалистом каждого направления именно на его специфике и особенностях взаимосвязи о смежниками. Например, специалисту по оборудованию и сетям не нужно будет показывать в деталях диаграмму биллинга (и наоборот). А с начальством - организацию взаимодейтсвия между направлениями.

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

177

Бизнес-анализ и Целеполагание / Re: Формулировка цели для процесса "учебная работа деканата"

« : 15 Мая 2007, 22:08:35 »

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

Какая-то совсем идеальная картина получается ... Может быть всё-таки не все студенты разделяют благие намерения деканата . ? Очень опасно пытаться описать цели участника процесса за него самого, хотя практика обучения IT-технологиям часто грешит нарушением собственных же теоретических положений о необходимости выявления целей и мотивов ЗЛ именно у самого участника.
То, что для каждого ВИ будет, как правило 2 ЗЛ - одно от деканата, другое - студент, содержит в себе возможность конфликтов при внедрении  и использовании системы и должна предусматривать механизмы разруливания разнонправленных устремлений участников. Если бы все студенты были такими заинтересованными, наверное и система такая не требовалась бы? А если они заинтересованы, то, возможно, система должна быть не учетной, а скорее информационной, ориентированной на студента (студент, как увидит, что он отстает по показателям и сразу начнет работать, и данные будет сам вводить и всё-всё прямо сам будет делать .
Если "карательные" функции системы действительно окажутся эффективными, вокруг системы могут начать происходить интересные события (опять таки по сценарию известного анекдота про освоение шведской бензопилы русскими лесорубами). Лучше бы, конечно, если бы удалось замотивировать студентов на учебу без превращения их в элемент автоматизированной системы. В общем, успеха Вам в Вашем нелегком деле...

178

Бизнес-анализ и Целеполагание / Формулировка цели для процесса "учебная работа деканата"

« : 15 Мая 2007, 18:55:16 »

.....
2. контроль текущего рейтинга и посещаемости занятий - цель Обеспечение выполнения студентами учебного плана по специальности в полном объеме за отчетный период
3. контроль выполнения сессии - цель Обеспечение выполнения студентами учебного плана по специальности в полном объеме за отчетный период
.....

...что проясняет нам картинка диаграммы взаимосвязей ЗЛ? Ну отразит она иерархию этих лиц, а дальше?

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

Возможно имеет смысл попытаться определить:
Какие ВИ актуальны для данных задач?
Какие лица к каким ВИ имеют отношения?
Кто будет собирать контрольные данные для задач п.п. 2 и3?
И, возможно, какое отношение собираемая информация может иметь к конкретным формам и срокам воздействия на студентов целью достижения результатов, для которых данные контрольные действия будут предприниматься (т.е. в чем может на практике заключаться управление учебным, а не контрольным процессом, и как они между собой связаны)?

179

Примеры / Re: Моделирование деятельности деканата

« : 19 Апреля 2007, 18:37:34 »

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

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

Цели автоматизации необходимо должны следовать из целей деятельности конкретных (!) сотрудников/руководителей деканата. Если эти цели в явном виде выявить пока не удается, можно зайти с другой строны:
1. Какие конкретные (!) проблемные ситуации реально возникали в работе деканата? У кого?
2. Кто главный инициатор автоматизации, кто автор идеи? Являются ли его инициативы следствием проблемных ситуаций п.1, "пострадал" ли он в этих конкретных ситуациях?
3. Могут ли такие проблемные ситуации предотвращены в будущем в результате автоматизации работы деканата?

Главный смысл предложения:
1. цели должны обязатльно быть "чьими-то" целями. Говорить о целях деканата вообще - некорректно.
2. цели могут быть обнаружены, когда преследующие цели конкретные сотрудники (п.1), сталкиваются с препятствиями на пути к их достижению. Обсуждение этих проблемных ситуаций позволяет легче эти цели обнаружить.


Ожидаемый положительный результат:
1. проблемные ситуации, с которыми столкнулись эти лица необходимо рассмотреть под углом зрения "что именно хотели эти люди сделать?", когда с этой ситуацией столкнулись. Ответ на вопрос: "что хотели сделать?" может указать на цель, или по крайней мере, направленность намерений участников.
2. Ответы на эти вопросы должны выявить. наличие реальных заинтересованных в автоматизации лиц.

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

180

Варианты Использования (Use Case) / Re: Структурные Диаграммы представления ВИ

« : 08 Апреля 2007, 21:47:49 »

На самом деле мне не понятно, таки почему это "дело обстоит не совсем так" ... и почему ТОЛЬКО диаграммы юзкейсов не должны вызывать скепсис?? Особенно если учесть тот факт, что практика использования только диаграмм юзкейсов фактически приводит к функциональной декомпозиции но на юзкейсах ... и запросто при этом встречаем ВИ "Отправка уведомления о регистрации на мероприятие", который в лучшем случае будет "included". Никто не отрицает, что использование диаграммы юзкейсов в качестве "оглавления", предваряющего собственно текстовые спецификации вполне полезно, более того, я сам часто использовал диаграммы ВИ в "Modern SRS", но обязательно за ними следовали и сами юзкейсы. Кроме этого еще и графически показывал связь м/у диаграммами уровня "облака" и "user goal". Так что речь тут в большей степени о том, что имеет смысл использовать диаграммы СОВМЕСТНО с текстовыми спецификациями ... Но при этом, одни текстовые спеки дают больше value, чем одни диаграммы.

1. Мне в принципе близок Ваш подход к использованию диаграмм юзкейсов. Когда я писал о том что "дело обстоит не  совсем так", это относилось к Вашему утверждению о том, что никто в принципе не возражает против использования диаграмм (в частности, юзкейсов, как я понимаю) в дополнение к текстовому описанию. Я указал, что Коберн в этом отношении занимает фактически более жесткую позицию по сравнению с Вашей. Цитаты , которые  я привел, свидетельствуют о гораздо жестком оппонировании (фактически, возражении)  использованию диаграмм, даже в дополнение к текстовому описанию. Нет практически ни  одного примера использования диаграмм UML в его книге, в которых рассмотрение способов их использования не сопровождались бы впоследствии уничижительными замечаниями в адрес этих диаграмм, напрочь дезавуирующих любые утверждения об их возможной полезности, которые он делает перед этим. Цитаты в подтверждение я и привел в предыдущем посте.

2. Наряду с вопросами применения диаграмм в конкретных проектах, не менее интересным представляется применение диаграмм для формирования паттернов бизнес-уровня, которые ухватывали бы типовые модели ведения бизнеса. Бизнес-анализ в сфере менеджмента, управления предприятиями давно уже использует различные модели, также использующие диаграммные представления. Такие схемные представления широко распространены в так называемых развитых странах и нашли свое отражение и в модульных структурах  ERP-систем.  Да и в отечественном бизнесе термин "типовая схема управления"  уже стала привычной . Несмотря на то, что управленцы давно понимают друг друга с полуслова и могут оперировать такими крупноблочными схемными представлениями для организации бизнеса, описание этих схем лишено той четкости, которая обычно требуется для задач автоматизации деятельности. В то же время при внедрении автоматизированных систем (особенно типовых решений)  неизбежна встает задача выделения типовых схемы управления из всего многообразия подходов к управлению, культивируемых конкретным Заказчиком. И эта работа занимает существенную часть времени затрачиваемого на проектирование/внедрение системы.
При этом представляется важным решение двух задач:
1. Каким образом можно упорядочить системные представления о различных видах бизнеса с целью их дальнейшего применения в других проектах(ускорить, облегчить этап бизнес-анализа)?
2. Возможно ли обеспечить взаимопонимание IT и бизнес структур за счет использования близких (схемных?) представлений (ускорить, облегчить передачу информации о бизнесе разработчикам)?

Можно ли считать эффективным для целей п. 2 использование традиционных текстовых представлений?

Работа управленца - конструктора управленческих схем давно уже напоминает работу конструктора-машиностроителя и схемы (чертежи) давно уже стали неотъемлемой частью проектной документации.  И схема управления давно уже не может быть заменена текстовым перечнем (содержанием) включающих её элементом. Для достаточно больших схем именно затраты на выстраивание структуры связей, а не разработку (приобретение) отдельных компонентов вносит основной вклад в valuе этих систем.

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

Вопрос: могут ли быть
1. разработаны типовые схемные представления о бизнесе (в том числе и зарубежном), учитывающие отечественную специфику и, возможно, опыт,
2. конкурентоспособные на мировом уровне и
3. сопрягаемые как с существующими моделями как в сфере менеджмента, так и IT, в частности, с использованием UML?

Как обеспечить сопряжение схемно мыслящего бизнеса и текстово мыслящего IT сообщества?