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

Материал конечно интересный, но есть еще проблема и времени.

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

Всё-таки я не понял, Эдуард, вы знакомы или нет вот с этими материалами?

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

Всё-таки я не понял, Эдуард, вы знакомы или нет вот с этими материалами?
http://www.intuit.ru/department/se/devis/4/

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

Комментарий: Насколько корректно связывать Data Flow диаграммы и юзкейсы?! Что-то не понимаю я автора (несмотря на ВМиК и прочия) ...

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

Комментарий: насколько надежное? и удобное ЭТО КАК ? ЗАЧЕМ приводить ТАКИЕ примеры? ... (вообще-то, если мне не изменяет память, это списано у Соммервиля, и его уже критиковали за это :-).)

Oh mein gott! Что автор дальше про юзкейсы списывает :-) в этой же главе ... ну вобщем все всё поняли ...

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

P.S. Интереcно, почему говоря о бизнес-процессах и вообще о бизнес-анализе, не рассмтриваете тот же Guide to the Business Analysis Body of Knowledge? Интересно было бы послушать высказывания на этот BOK.

...
http://www.intuit.ru/department/se/devis/4/
...

Цитата из приведенного материала:
...

Комментарий: Насколько корректно связывать Data Flow диаграммы и юзкейсы?! Что-то не понимаю я автора (несмотря на ВМиК и прочия) ...

По приведённой мной ссылке (Лекция 4) я подобных фраз не нашёл. Вообще я рекомендовал этот материал Эдуарду потому, что ему близка SADT-методология, которую достаточно подробно освещает Грекул (Лекции 6-10) + дан, на мой взгляд, хороший материал по Орг моделированию (Лекции 1-5), подобно которому я ничего не встречал. Те цитаты, которые приводите Вы, похоже, из последних лекций (11-12), посвящённых UML, в котором возможно Грекул не имеет такого обширного опыта, как в SADT. Я не вижу ничего дурного в том, что человек знает что-то лучше, что-то хуже, как говорил тут Александр - нет гуру в своём отечестве.

Далее цитата:
"Например, формулировки "система должна использовать СУБД Oracle для хранения данных", "нужно, чтобы при вводе неверных данных раздавался звуковой сигнал" не очень хорошо описывают потребности. Исключением в первом случае может быть особая ситуация, например, если СУБД Oracle уже используется для хранения других данных ... Соответствующие потребности лучше описать так: "нужно организовать надежное и удобное для интеграции с другими системами хранение данных", "необходимо предотвращать попадание некорректных данных в хранилище".
Комментарий: насколько надежное? и удобное ЭТО КАК ? ЗАЧЕМ приводить ТАКИЕ примеры? ... (вообще-то, если мне не изменяет память, это списано у Соммервиля, и его уже критиковали за это :-).)

Во-первых, коим образом это относится с бизнес-процессам? Во-вторых, сколько я помню, именно в такой форме Потребности и описываются, даже у мажоров требований типа Вигерса-Лефингвелла-Коберна, т.к. "насколько надёжно" - это не уровень потребностей, а уровень требований к системе, определяемый совместно архитектором и аналитиком. См. мою таблицу уровней требований. Какие точные требования к атрибутам качества может предъявлять Заказчик??? Это скорее исключение, чем правило.

Эти лекции -- в основном компиляция из литературных источников.

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

P.S. Интереcно, почему говоря о бизнес-процессах и вообще о бизнес-анализе, не рассмтриваете тот же Guide to the Business Analysis Body of Knowledge? Интересно было бы послушать высказывания на этот BOK.

Посмотрев на их драфт 1.6 меня уже одно то смущает, что у них там ни одной диаграммы - хороши мастера представления знаний.

Всё-таки я не понял, Эдуард, вы знакомы или нет вот с этими материалами?

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

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

Во-вторых, моя фраза обусловлена тем, что Эдуард сказал насчёт Интуитовских курсов в теме про онлайновые курсы - я так понял, что он достаточно хорошо знаком с ними, к тому же учитывая, что конкретно по теме СисАн из 100 представленных там курсов есть только 4-5, причём конкретно "Проектирование ИС" висит там года 2 + он к тому же как учебник рекомендован вузам. И мне кажется логичным, что прежде чем изобретать велосипед, человек с системным подходом всё-таки находит время, чтобы наточить пилу, прежде чем пилить, а именно - формулирует задачу, ищет аналоги, анализирует их и адаптирует их или создаёт своё, чёткое понимая, чем его не устраивает существующее.

ообще я рекомендовал этот материал Эдуарду потому, что ему близка SADT-методология, которую достаточно подробно освещает Грекул (Лекции 6-10) + дан, на мой взгляд, хороший материал по Орг моделированию (Лекции 1-5)

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

Юрию...

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

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

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

Денис, даже коллега может быть оппонентом:-))

Во-вторых, моя фраза обусловлена тем, что Эдуард сказал насчёт Интуитовских курсов в теме про онлайновые курсы - я так понял, что он достаточно хорошо знаком с ними, к тому же учитывая, что конкретно по теме СисАн из 100 представленных там курсов есть только 4-5, причём конкретно "Проектирование ИС" висит там года 2 + он к тому же как учебник рекомендован вузам. И мне кажется логичным, что прежде чем изобретать велосипед, человек с системным подходом всё-таки находит время, чтобы наточить пилу, прежде чем пилить, а именно - формулирует задачу, ищет аналоги, анализирует их и адаптирует их или создаёт своё, чёткое понимая, чем его не устраивает существующее.

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

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

Те цитаты, которые приводите Вы, похоже, из последних лекций (11-12), посвящённых UML, в котором возможно Грекул не имеет такого обширного опыта, как в SADT. Я не вижу ничего дурного в том, что человек знает что-то лучше, что-то хуже, как говорил тут Александр - нет гуру в своём отечестве.

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

Во-первых, коим образом это относится с бизнес-процессам? Во-вторых, сколько я помню, именно в такой форме Потребности и описываются, даже у мажоров требований типа Вигерса-Лефингвелла-Коберна, т.к. "насколько надёжно" - это не уровень потребностей, а уровень требований к системе, определяемый совместно архитектором и аналитиком. См. мою таблицу уровней требований. Какие точные требования к атрибутам качества может предъявлять Заказчик??? Это скорее исключение, чем правило.

1. Коберна и Вигерса вы напрасно поставили в один ряд с Леффингвеллом говоря о user&stakeholder needs. Кроме этого что-то я не увидал их в списке литературы которые приводит автор лекции :-).
2. Связь с бизнес-процессами очевидна, при условии понимания причины -- ЗАЧЕМ в конкретном случае мы занимаемся описанием БП -- если делаем автоматизацию (читай создаем систему), то очевидно. что БП/Потребности/Требования -- будут связаны.
3. Серьезного формализма в описании needs нет, достаточно почитать апологета их выделения - Лефингвелла, (не важно какое 1 или 2 издание). И тем более ПРЕДЪЯВЛЕНИЯ к user needs "не вводить необоснованных ограничения на имплементацию". Это, пардон, характеристика требований, а никак не needs, не так ли? Остается открытым вопрос, на основании чего автор это утверждает, собственное IMHO? Тогда ценность этого утверждения невелика.
4. Что касается вашей "таблицы уровней требований". Не могли бы вы более детально описать, что вы вкладываете в понятие "Требования к системе" (вид требования в вашей таблице)? И как он связан с источниками "Стандарты, Архитектурные шаблоны" и документом SAD?

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

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

Посмотрев на их драфт 1.6 меня уже одно то смущает, что у них там ни одной диаграммы - хороши мастера представления знаний.

О каких диаграммах идет речь? Какие диаграммы есть в других BOK, выражающие "представление знаний", которые не преведны в этом?

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

Меня однажды пригласили вместо моего большого босса, в бытность работы в ВТБ, почитать вместо него лекцию о бизнсес-моделированию для студентов одного известного столичного ВУЗа, готовившего специалистов на стке банковских и ИТ-технологий. Когда я увидел их программу, то ужаснулся, в результате, пришлось самому делать презентацию для лекции. Но после этого, я понял, что одно дело учить студентов, другое давать знания в рамках консалтинга. Это несколько разные вещи. Чтобы писать лекции и/или книги -- это тяжелый труд (если не делать халтуры конечно). Перевод SWEBOK и комментарии тоже был труд.

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

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

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

Господа, хватит убиваться, формулировка процесса, как таковая, и применяемая везде и поголовно с минимальными изменениями не затрагивающими суть представлена в ИСО 9000:2000, Формулировка А.В. Шеера от этой фактически не отличается. Бизнес-процесс от обычного отличает создание ценности выходящему продукту, таким образом производственный процесс с наибольшей вероятностью будет являться бизнес-процессом, а вот приведенные вами примеры НЕТ, ибо логистика- это лишь обеспечение поставки входов и доставки выходов до потребителя, туда же идет бухгалтерия и ИТ, это вспомогательные процессы, если конечено бизнесом компании не является оказание услуг в области логистики, ИТ или бухгалтерии.  В бизнесе есть 2 понятия ценность и стоимость, так вот ценность создается бизнес процессами, а вот стоимость всеми в купе, конкретно добавленная стоимость вспомогательными. что проще?

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

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

Давайте всеж подходить реально, воздействия инициирующие каждый шаг могут относится и к управляющим воздействиям и к механизмам и ко ВХОДАМ процесса, кои тут в списке почемуто не указаны? Странно, ибо процесс и есть последовательность действий преобразующая входы в выходы?
Да, и ещё, как раз наоборот исполнители это один из вариантов механизма или инструмента с помощью которого и выполняется процесс...

Да, и ещё, кто сказал, что модель процесса это изображение?

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

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

Модератор: оффтоп удален