31

Сообщество Аналитиков / Re: Придумываем слоган Сообщества

« : 03 Января 2010, 12:26:15 »

Предлагаю лозунг "Понять и объяснить", смысл которого можно пояснить так:

Понять предмет деятельности, явления или процессы, выделить значимое и достоверное, сформировать емкое представление об этом, доступное объяснению.

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

Объяснить то, что понимаешь сам, другому в доступной для понимания форме.

Правильно (достоверно) - не значит понятно.

32

Обучение / Re: Информационные системы в научных исседованиях

« : 02 Сентября 2009, 15:44:56 »

В материалах ГКНТ есть фраза - "АСНИ отличаются от других типов автоматизированных систем (АСУ, АСУТП, САПР и т.д.) характером информации, получаемой на выходе системы".

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

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

33

Обучение / Re: Информационные системы в научных исседованиях

« : 02 Сентября 2009, 11:15:51 »

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

34

Обучение / Re: Информационные системы в научных исседованиях

« : 01 Сентября 2009, 16:15:58 »

Можно посмотреть здесь чем в России на эту тему занимаются - http://www.cemi.rssi.ru/research/#macromodel

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

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

В отличие от технических (физических) систем сделать какое-нибудь маленькое законченное и полезное для моделирования экономики приложение ИМХО невозможно. Возможность моделирования отдельного человека, как экономического субъекта, представляется более чем проблематичным. А статистические закономерности проявляются на достаточно больших выборках, которые характерны для больших (сложных систем). Вокруг наиболее известных научных результатов для таких моделей, как правило, разгораются нешуточные страсти. Ученые, которые моделировали катастрофические экологические сценарии развития человечества для Римского клуба, отказались опубликовать свои модели, что до сих пор ставит под сомнение научную ценность полученных ими результатов. Советский ученый В.Александров, который получил яркие результаты по компьютерному моделированию сценариев последствий ядерной войны ("ядерная зима") пропал при невыясненных обстоятельствах в Испании на пике интереса к этой теме.

За рубежом математическое моделирование (в отличие от России) широко используется в гос учерждениях и бизнесе - http://www.bankofcanada.ca/en/res/tr/2007/tr98.pdf. Но в этой работе также очень хорошо виден основной акцент на математическую модель,а не на программные решения. В Министерстве энергетики США используется какая-то монстроидальная программа для моделирования энергетического баланса в мире. Они, вроде, сначала пытались моделировать только для США, но чтобы получать приемлемые результаты пришлось расширять моделирование сначала на континент, а потом на весь мир.

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

35

Системный Анализ и Требования / Re: А есть ли специализация у Аналитика по типам ИС?

« : 26 Августа 2009, 11:43:52 »

И вопрос сводится к тому - какие навыки\подходы нужны начинающему Аналитику для работы по созданию того или иного вида ИС.

ИМХО стоит начать с классификации ИС "того или иного вида" имея в виду, что ИС:
*предназначены для разных видов бизнеса, которые предъявляют требования, вытекающие из специфики, логики, технологии деятельности и которые не связаны непосредственно с особенностью используемых для их автоматизации ИТ- решений. Важно учитывать этот аспект на этапе бизнес-анализа, выявленные на этом этапе могут определять архитектуру ИТ-решений, хотя это не всегда осознается/признается. Наверное, без некоторой классификации бизнесов по видам не обойтись...

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

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

36

Бизнес-анализ и Целеполагание / Что такое цель?

« : 24 Августа 2009, 12:52:39 »

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

Т.е. в Вашем определении можно не использовать слово "назначение", а прямо сказать - "цель - ограничение действий (деятельности)"?

37

Обсуждение статей / Re: Отношение extend

« : 24 Июля 2009, 14:12:22 »

Агрегация и композиция не подходят. ВИ не состоит из частей. ВИ - это есть целое + кусочек из другого ВИ (в случае зависимостей).

Я как раз про кусочки .  И Якобсон пишет про parts of usages. Если мы все таки можем говорить о "кусочках из другого ВИ" , то тезис о единстве и неделимости ВИ фактически ставится под сомнение. Почему бы про такие "кусочки" прямо не указать - частью чего они являются на диаграмме нотацией агрегации(композиции), принятой для "обычных" классов? Где жмет? Почему у авторов UML use case как бы и класс, и в то же время не класс? Оправдано ли на практике такое обособление ВИ от "обычных классов"?

38

Обсуждение статей / Re: Отношение extend

« : 24 Июля 2009, 12:00:24 »

"Крамольное предположение": если исходить из тезиса Якобсона о том, что "Abstract use cases are used for declaring commonalities at one place which later can be reused when defining new use cases that share these commonalities, to declare parts of usages (subflows) that are added in a later version of the model, or to model subflows explicitly." то может быть полезно было бы использовать нотацию aggregation(composition) для описания отношений между ВИ (хотя это и не соответствует спецификации)?

39

Работа / Re: Головоломки (логические) на собеседовании

« : 25 Июня 2009, 10:32:16 »

Мне на собеседовании давали логическую задачку.
"В пруд площадью 50 квадратных метров попадает кувшинка. Каждый день количество кувшинок увеличивается вдвое. На 50 день весь пруд зарастает кувшинками. Через сколько дней пруд зарастет на половину".
Задача простая, но в условиях волнения, которое обычно бывает у интервьюируемого решение приходит не сразу

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

40

Управление Проектом / Re: Оценка трудоемкости модификаций (разработки)

« : 17 Июня 2009, 13:07:02 »

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

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

1. Необходим план доработок исполнителем, каждый пункт которого отражает дискретный этап работы, который может также дискретно оцениваться "сделано/не сделано" - соответственно не должен содержать расплывчатых определений "улучшение", "доработка".
2. Оценка человекочасов для каждого этапа - benchmarking по аналогичным работам уже выполнявшимся Исполнителем или разработчиками Вашей компании. Оценка должно проводиться с участием специалистов, имеющих реальный опыт разработки приложений в данной или близкой технологии. Метрики для сопоставления/оценки работ выбрать с учетом предпочтений участников процесса оценки трудоемкости (типа кол-во отчетов, интерфейсных форм, полей в форме, таблиц и пр. - для каждой задачи наиболее адекватные с согласия сторон - не пытайтесь сделать универсальный список на все случаи жизни). Искать какие-нибудь "абсолютно объективные" методики не советую - все они так или иначе содержат фактор субъективной экспертной оценки функционала, опирающийся на некий общий опыт/практику Исполнителя и Заказчика + возможно, громоздкие наукообразные расчеты.
3. Утверждение/согласование как плана, так и трудоемкости должен включать аргументированное согласование оценок (и предложенных метрик, задач-аналогов, использованных в качестве исходных). Если Заказчик считает деньги, молчаливое принятия оценок как основной режим работы мало реально.

41

Поздравления / Re: Поздравляем Эда - Galogen'а с Днем рождения!!!

« : 15 Июня 2009, 10:48:19 »

Присоединяюсь к поздравлениям, Эдуард,  желаю Вам успехов во всех начинаниях, старых и новых!

42

Системный Анализ и Требования / Re: Критерии выявления

« : 18 Мая 2009, 12:39:02 »

Что хочется увидеть, например, такой критерий - "требование не должно содержать сущностей, которые могут быть уточнены" - вместо "одновременного сеанса работы на 20 АРМ", использовать "одновременный ввод данных в зону актирования". Или это совсем не обязательно?

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

43

Системный Анализ и Требования / Re: Критерии выявления

« : 14 Мая 2009, 17:36:34 »

Здравствуйте!
Помогите, пожалуйста, с ответами на вопросы.
1. Можно ли говорить о критериях этапа выявления требований и нужно ли? Под критерием понимается некий признак, на основании которого производится оценка этапа выявления (сбора информации).
2. Покрывает ли этап анализа требований оценку этапа выявления?
3. Что вы скажете, если использовать следующие критерии:
- внутренняя согласованность и непротиворечивость;
- системность;
- объективность;
- историзм.
 ?
4. Внутренняя согласованность и непротиворечивость. В собранной информации, фактах, требованиях достигнуты единство, стройность, гармония, они недиффузны, отсутствуют формулировки, при которых одно требование исключает другое, несовместимое с ним, противоположное ему. Установлены синтаксические связи между зависимыми словами. Учтены оттенки модальности, такие как: пользователь знает, что ...; пользователь думает, что ...; пользователь хочет, чтобы...; пользователь считает, что ... Учтены границы сбора информации. Разрешены все противоречия предметной области и интересы пользователей при формулировании требований.
Системность. На основе собранной информации рассмотрены все уровни многоуровневой иерархической организации любых объектов. На каждом уровне определены специфические свойства объектов, выявлены необходимые связи между ними.
Объективность. Собранная информация, сформулированные факты, требования не истолкованы с точки зрения субъекта – аналитика по требованиям и/или пользователя/эксперта, а отражают настоящую действительность, проблему. Достигнута необходимая глубина понимания - осознаны смысл, сущность, значение.
Историзм. Этот критерий связан с развитием. В собранной информации присутствует история возникновения проблем, которые необходимо решать. Автоматизируемые процессы рассмотрены с учетом временных изменений - присутствует связь как с прошлым, так и с будущим. Структура собираемых требований и сами требования допускают подстройку и коррекцию, как в период разработки, так и во время эксплуатации разработанной системы.
?
5. Каким образом вы проводите оценку этапа выявления требований? Есть ли какие-либо практические примеры, какие критерии при этом используются?

Трудность использования предложенного подхода может быть связан с моделью, задающей логику в которой анализируются требования.
Обычно имеем следующую ситуацию: есть некоторое описание требований и есть некоторая модель, которая задает логику анализа требований. Требования анализируются на предмет соответствия модели бизнеса заказчика, оформленной в документе или существующей в головах участников проекта.
Здесь же предлагается рассматривать требования в рамках модели не сколько автоматизируемой деятельности, сколько модели собственно требований.
Вопрос, насколько объективны представление об этой модели, в частности с нашей с Вами точки зрения? В рамках одной модели требования могут быть непротиворечивы, а в рамках другой - противоречия возникают. В частности, уже в пунктах 4-5 есть указания на некоторые модельные представления, которые могут разными людьми, даже специалистами, трактоваться по разному.
Насколько реально однозначно и объективно интерпретировать следующие фразы:
* "Установлены синтаксические связи между зависимыми словами".
* "Учтены границы сбора информации".
* "Разрешены все противоречия предметной области"
* "все уровни многоуровневой иерархической организации любых объектов".
* "требования не истолкованы с точки зрения субъекта – аналитика по требованиям и/или пользователя/эксперта, а отражают настоящую действительность, проблему." Как определить, выполнено ли это требование, как решать такую задачу - отдельная тема.

Требование рассмотрения анализируемой деятельности в контексте истории её формирования ИМХО весьма полезно. Как правило, выводит на анализ истории бизнеса заказчика, причем не только как отдельного предприятия, а как вида, отрасли деятельности.
Предложенный взгляд на "внутреннюю структуру", логику требований интересен. Но модель, в рамках которой этот анализ производится требует уточнения.

44

UML SysML и пр. / Re: Плюсы и минусы диаграмм вариантов использования

« : 12 Мая 2009, 13:19:42 »

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

Я бы предложил зафиксировать, что:
1. диаграммы ВИ могут соответствовать разным уровням. В спецификации самого UML применение одних и тех же диаграмм для описания ВИ разных уровней, кажется, не артикулированао. Но эта "разноуровневость"  используется в методологиях анализа и разработки систем. Эти методологии (RUP и пр.), уже используют UML в качестве инструмента. Методологии описываются в книгах "мэтров", причем каждый "мэтр" демонстрирует авторский подход к использованию и трактовке инструментария UML. Подход Лармана, с моей точки зрения  тяготеет к использованию UML на программно-техническом, а не бизнес уровне. Применительно к его трактовке ДВИ ИМХО можно говорить о неоправданном сужении содержания ДВИ. Это скорее не ошибка, а сознательное ограничение себя чересчур жесткими рамками, которые могут затруднить использование ДВИ для понимания анализируемой деятельности.
2. вроде бы предложенная мной интерпретация изображенной на ДВИ деятельности в целом совпадает с Вашей. Во всяком случае наши "неоднозначные" точки зрения касались не сколько того, что изображено на диаграмме, сколько того, что на ней не нарисовано, а также какими именно ВИ  наше общее (однозначное?) понимание представленной на ДВИ деятельности может быть изображено.
3. использование ДВИ, как впрочем и других диаграмм UML представляется целесообразным использовать не сколько для описания того, что уже является "общим местом" для участников анализа/моделирования системы, сколько для фиксации разных точек зрения, разного видения анализируемых ВИ для дальнейшего обсуждения. Но видения, возникшего на основе общего для всех участников обсуждения контекста, например автоматизируемой деятельности Заказчика. В этом смысле сначала должен быть предъявлен контекст, на основании которого рисуется ДВИ, затем уже рисуется ДВИ и обсуждается её соответствие контексту. Этот контекст может возникать из обсуждения с ДЛ или из нормативных документов, регламентов Заказчика. Отсутствие реального контекста, общего для нас Вами и с другими участниками обсуждения, затрудняет развернутое обсуждение ВИ. Возможность выявления полезности ДВИ  применительно к контекстам типа "наливание чашки кофе" вызывает сомнения. 
4. ценность ДВИ существенно зависит от количества ВИ и ДЛ, представленных на диаграмме. ИМХО основная ценность ДВИ - это топология взаимосвязей ВИ и ДЛ: какие ДЛ в каких ВИ участвуют. Понимание в деталях, что стоит за каждым ВИ на ДВИ важно не сколько для "угадывания" правильного названия ВИ, сколько для того, чтобы правильно разграничить ВИ.  ВИ Например, глядя на ДВИ удобно обсуждать распределение/разграничение прав в системе для различных ДЛ. Если ДЛ и ВИ мало, тема для обсуждения может отсутствовать - например, все права будут у Продавца.

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

45

UML SysML и пр. / Re: Плюсы и минусы диаграмм вариантов использования

« : 11 Мая 2009, 18:14:06 »

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

Если исходить из определения спецификации (A use case is the specification of a set of actions performed by a system, which yields an observable result that is, typically, of value for one or more actors or other stakeholders of the system.), то определение, на которое ориентируется Ларман для понимания ВИ,  чересчур жесткое. Если спецификация предполагает наблюдаемый результат, то в определении Лармана результат должен быть измеримым, действия должны производиться в одно время и в одном месте. И одним ДЛ. Жестковато. Он и сам абзацем ниже признает, что определение ЭБП скорее соответствует духу, но не букве ВИ.
Если  оценивать ВИ с точки зрения ценности результата их завершения для ДЛ на бизнес уровне, то разбиение ВИ "Заказа товара" на ВИ "Заказать товары или услуги" и ВИ "Подтвердить получение заказа" ИМХО  снижает ценность этих ВИ, поскольку для покупателя отправка заказа без подтверждения его получения продавцом едва ли может считаться самоцелью и, соответственно, завершенным бизнес-процессом. Подтверждение получения заказа может содержать важные уточнения условий доставки товара продавцом, по результатам которых покупатель может отказаться от покупки (оплаты заказа). Доводы, которые я привожу, относятся к ДВИ, рассматриваемой на бизнес-уровне.
Возможно, детализация ВИ (разбиение на частные ВИ) важна для учета результатов отдельных этапов бизнес-транзакции и в этом смысле представленные на диаграмме ВИ имеют ценность для продавца, как пользователя компьютерной системы. В этом случае, если рассматривать предложенную ДВИ для системного уровня, нанесение рамок системы на ДВИ представляется весьма полезным. Хотя ограничение количества действующих лиц 2-3 персонажами, как правило, действительно вызывает вопрос о полезности рисования ДВИ, особенно по сравнению с другими диаграммами для уровня системы.