106

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

« : 12 Сентября 2007, 10:50:41 »

В результате я все-таки с ребятами оформлю как нам лучше для того, чтобы представить свой проект. А комиссия раз и снизит ему за оформление - мол не стандартно у вас мил человек!

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

107

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

« : 12 Сентября 2007, 10:40:43 »

Нет, Shur, я не за то, чтобы его выкидывать, а зато, чтобы его грамотно использовать. Т.е. в МУ как и следует обыграть ситуация с современными подходами, хотя бы разделить структурный подход и объектный и показать, что в каком случае применять из ГОСТОв и как.

1. По жизни не все документы из ГОСТ используются в проекте. Поэтому пункты структуры методуказаний можно предложить студентам использовать в качестве каталога, из которого они должны выбрать те, которые, как они считают, необходимы для их конкретной работы. И в качестве главного ограничения свободы выбора студентов можно поставить условие, что выбранные документы должны покрывать все стадии проекта (ГОСТ 34.601-90), хотя, возможно, и с рзной степенью полноты.
2. ИМХО неверно требовать от дипломника чтобы он одинаково полно писал и ТЗ и тех. проект. Требует раздвоения личности - представлять себя то Заказчиком (когда пишешь ТЗ), то исполнителем (когда техпроект). По жизни очень часто бывает, что Исполнитель пишет и ТЗ и техпроект потом, но это если ТЗ - простая формальность. А написать в даже в этом случае хорошее ТЗ без искушения проваливания в обсуждение деталей разработки (уровня техпроекта) - для разработчиков сущее мучение. Проблемы, как правило, вылезают на уровне описания программы и методики испытаний - Заказчик стремится испытывать систему как черный ящик, а границы этого черного ящика как раз задаются и должны выдерживаться при написании ТЗ (с чем разработчики, пишущие ТЗ, часто не справляются). Поэтому ИМХО полезно, когда за написания ТЗ и программы испытаний отвечают одни люди, а за техпроект- другие. Может быть возможно рзрешить дипломникам акцентировать свои работы с точки зрения роли, в которой они себя видят? Наверняка большая часть будет писать техпроекты, а задачу написания диплома с акцентом на ТЗ можно рекомендовать тем, кто стремится в аналитики .

108

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

« : 11 Сентября 2007, 17:55:25 »

Ира, к сожалению твой ответ ничего не прояснил.
Возможно это лишь говорит, что реально росГОСТами  действительно мало кто пользуется. Вопрос а зачем такие ГОСТы нужны, а что тогда брать за основу? Международные?

ИМХО большая часть денег, которая осваивается  проектным образом (т.е. сначала проектируем, описываем, потом делаем в соовтетствии с описанным) делается для (полу)госудрарственных заказчиков. И там, как писал greesha, нужно работать по ГОСТ. Так что ГОСТ очень даже востребован. Минус - он заточен под функциональную модель, а разработчики объектных моделей часто обходятся без неё. И бывает проблема в какой из требуемых по договору документов удобнее воткнуть диаграмму классов.
Не предусмотрено в нем и многоуровневых моделей (ну не все 7 уровней открытых систем, то хотя бы как, не нарушая букву ГОСТ, описать физический и логический уровень бывает проблематично).
Но народ выкручивается . Так что ГОСТ пока рано списывать со счетов, важно только оговорить для каких соверменных подходов он плохо применим (и даже - какие современные подходы плохо дружат с функциональным представлением о системе .

109

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

« : 09 Сентября 2007, 16:35:30 »

Shur, мне это тоже показалось даже не категоричным, как не совсем верным. Наверное имелось в виду приоритет функции над структурой.

Анфилатов и др. Системный анализ в управлении. М.: Финансы и статистика, 2002?

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

возможно это обыгрывалось Сурминым?

Утверждения Сурмина о возможности "выведения" функций из структуры - антипод приведенного определения функциональности. Если функции системы (однозначно?) "выводимы" из структуры (как пишет Сурмин) то это можно понять и как примат структуры над функциями (в рамках его дескриптивного подхода), что противоположно приоритету функций над структурой, утверждемой в рамках принципа функциональности.

Наверное, существуют системы и практические ситуации, когда можно из структуры системы вывести её функции, но не стоило бы оформлять это в виде безусловного утверждения (вне контекстов), как это делает Сурмин.

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

110

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

« : 08 Сентября 2007, 19:37:21 »

Shur, в принципе думаю, что просто больше внимания в данном случае уделено Системам техническим (например самолет какой-нить или ракета).

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

Одной из важных изюминок (и составляющих стоимости) истребителя F-22 (и F-35) является программное обеспечение, которое обеспечивает "дружественый интерфейс" летчика и самолета и определяет боевые возможности (фактически - назначение) самолета. Невозможность контролировать нераспространения этого ПО при продаже такого самолета даже союзникам США уже привело к трениям между ними. В частности, были сообщения, что австралийцы напряглись, когда узнали, что США не дадут им доступа к кодам.
Можно ли относить ПО самолета к его структуре? Можно ли говорить, что мы точно знаем особенности его боевого применения (точно знаем цели его применения) если мы не знаем особенностей (алгоритмов) его системы управления?

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

111

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

« : 08 Сентября 2007, 13:53:06 »

проект системы — модель системы как средство конструирования системы.

Отождествление проекта и модели системы представляется ошибочным.
1. Формализованные представления о процессах создания систем давно уже стали неотъемлемой частью сложных проектов. Поэтому там где нужно организовывать совместную работу многих специалистов, особенно разных специализаций, в явной форме проектируется не только модель (план) системы, но и способ и план действий по её созданию. И документированный процесс создания системы (наряду с моделью системы) является частью проекта (проектной документации).
2. А вот процесс создания системы совсем не обязательно является частью модели системы. Хотя этот процесс и можно моделировать.

Утверждения автора о том, что из структуры системы можно "вывести её функции" (и цели?) представляется как минимум чересчур категоричным...

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

Эти два подхода встречаются фактически во всех областях знания - математике, философии.

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

112

Варианты Использования (Use Case) / Re: Рефакторинг мельчащих use-case'ов

« : 06 Сентября 2007, 23:53:53 »

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

113

Бизнес-анализ и Целеполагание / Re: Главная, базовая, основная цель бизнеса

« : 28 Августа 2007, 11:43:43 »

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

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

2. Эффективность же деятельности самого предприятия развивалась в рамках "теоретического менеджмента" (и консалтинга), который утвердился как общественнй институт благодаря Ф.Тэйлору и поколениям консультантов. В частности, есть очень увлекательная книга на эту тему - Г.Эмерсон "Двенадцать принципов управления".
Важно, что совершенстование производства в "научном менеджменте" также ориентировалось не только на денежные показатели, но и первичные показатели деятельности производства, в частности, и затрат, в натуральном выражении.

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

В второй главе в четвертом абзаце Эмерсон кратко описывает ситуацию в Америке в начале 20 века. Трудно поверить, что Америка тогда ориентировалась фактически на валовые показатели, аналогичные использовавшимся у нас в советское время. Т.е. если современному человеку неообходимость ориентироваться в коммерческой деятельности на прибыль, а не на доход, почти очевидна, то 100 лет назад это было совсем не так. Даже в Америке.

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

114

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

« : 22 Августа 2007, 21:22:05 »

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

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

115

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

« : 21 Августа 2007, 13:06:45 »

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

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

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

К тому же каждая специализация часто вкладывает свой смысл в термины и понятия.

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

Првильно ли я понял - это всё в  рамке разработки?

- отсутствие инструмента верификации и упорядочивания материалов обследования заказчика (это культура системного и бизнес-анализа)

Стоит ли относить это к бизнес-анализу (даже в плане «только» культуры бизнес-анализа)? Ведь речь идет о контроле результатов работы бизнес-аналитика. Если приобретение культуры бизнес-анализа предполагает, что данное лицо фактически должно уметь проводить бизнес-анализ, то это обесценит разделение труда между бизнес-анализом и разработкой.
Может быть, как раз, ценным было бы вооружить разработчика специфическими представлениями, общими для разработчика и бизнес-аналитика (так сказать, пересечение множеств необходимых знаний разработки и бизнес анализа)? В частности, например, Ваше утверждение об избегании колец в иерархии целей, если его удастся развернуто обосновать, могло бы ИМХО претендовать на инструмент из пересечения компетенций бизнес-аналитика и разработчика

- отсутствие критического взгляда заказчика на собственные цели и цели, которые он ставит перед проектом автоматизации (это культура управления)

Это также всё предполагается, что можно раскрыть, детализировать в  рамке разработки? Или в рамке управления проектами?

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

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

116

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

« : 21 Августа 2007, 12:19:40 »

Теория деятельности, элементы которой упоминались выше, говорит о том, что человек МОЖЕТ действовать целенаправленно (в отличие от всяких букашек и зверушек). Но из этого не следует обратное. Нельзя утверждать, что ВСЁ поведение человека целенаправленно. Ну сами подумайте, вот я сейчас чихнул - это было целенаправленно или нет?

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

2 Shur
А я и не подвергаю сомнению возможность целенаправленной деятельности человека. Я сомневаюсь лишь в том, что человек ВСЕГДА действует осознанно и целенаправленно. Читайте внимательнее.

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

117

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

« : 20 Августа 2007, 15:45:59 »

Если я упорно избегаю отвечать на заданные вопросы, может быть это потому, что эти вопросы неверно формулируются?

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

118

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

« : 20 Августа 2007, 15:26:23 »

Тут не нужно изобретать велосипед. Такие вопросы выясняются в процессе либо интервьюирования сотрудников организации Заказчика. Либо в письменной форме предоставляются Заказчиком Разработчику.

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

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

119

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

« : 20 Августа 2007, 13:47:11 »

Могу ответить точнее.Решение по выбору ПО принимает ШеФ - Заказчик. Кто платит деньги, тот и танцует. Вроде всегда было именно так.

Важно тогда понять, из каких именно сооображений он принимает решение по выбору конкретного ПО? Если предлагаемые ПО различны, то значит они обладают какими-то различными характеристками. И Шеф будет решать, что именно даст его бизнесу внедрение того или иного ПО. Для оценки он будет пользоваться какими-то критериями, по которым он оценивает успешность своей деятельности. Эти критерии, собственно, и характеризуют цели бизнеса либо являются следствием главных критериев учпешности бизнеса. Нет целей - нет критериев.

Изначально БП возникают в процессе создания организации или предприятия. Для обеспечения протекания этих БП нужны определенные работники, которые выполняют фиксированный перечень должностных задач. Например есть БП - "Закупки" который состоит из следующих стадий:
      1. Определение потребности в материале
      2. Выбор поставщиков:
             2.1 Подготовка списка возможных поставщиков.
             2.2 Отправка запроса в соответствии с заявкой на материал.
             2.3 Выбор поставщиков.
      3. Обработка заказов
      4. Контроль выполнения условий договора
      5. Поступление материала
      6. Оприходование материала
      7. Контроль счетов
В этом примере БП "Закупка" декомпозирован на конкретные задачи (функции или подпроцессы) "1-7", и для примера задача "2. Выбор поставщиков" разложена вниз на более мелкие  задачи. "2.1, 2.2, 2.3". Далее возможна декомпозия на еще более мелкие задачи, вплоть до примитивных задач - взять ручку, взять бумагу и т.д.
Просто хочу донести мысль, что любой БП в компании может быть разложен на ряд совсем простых задач, автоматизация которых и позволит в сумме автоматизировать весь БП, или ту его часть которую требовал Заказчик.

Насчет разложимости БП по задачам я думаю, никто врзражать не будет.
Вопрос в том, можете ли Вы указать, в каких именно показателях Вы определяет потребности в материалах, какими показателями характеризуется результат обработки,  какие именно показатели необходимо должны быть результатом выполнения перечисленных Вами задач 1-7?
Ведь названия задач не раскрывают точно, что именно требуется получить в результате их выполнения.

120

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

« : 20 Августа 2007, 12:23:30 »

2Rocket:
Вы к сожалению, ушли от ответа на оба мои вопроса . Несмотря на их кажущуюся тривиальность, в жизни ответ на них полчается не всегда просто.
Если решения по тому - какое ПО, принимает ШеФ, то важно Шеф - кто? Разработчик или Заказчик?

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

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