Нужны советы по проектированию wizard'а

[Dimka]

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

А у меня что написано?

2. какой(~ие) БП или их части надо автоматизировать

А какое отношение БП имеет к Use case?

[lapulya]

Dimka,
у тебя написано вот что

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

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

...хотя есть его адаптации для более мелких...

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

А какое отношение БП имеет к Use case?

как это какое? а для чего вы будете писать кейсы? Вот вы представьте себя в роли аналитика, он приходит на предприятие и его сразу ведут к ключевому пользователю и он сразу пишет кейсы, так что ли? Да он понятия не имеет пока о том:
1. как работает предприятие (даже схожие предприятия, допустим автодилеры, легко могут иметь разные БП)
2. ключевые сущности и их связи (это называется модель/словарь предметной области)
3. в чем заключается деятельность персонала предприятия (действия, инструменты, цели, результаты)
4. где узкое место, подлежащее автоматизации (это очень важно, поскольку мы можем автоматизировать работу сотрудника, которую он один, будет выполнять на 15% быстрее, а все остальные 2000 человек, даже и не заметят внедрения системы, я сильно утрирую но мысль должна быть ясна)
5. что именно должно войти в скоуп, а что нет (это очень важно, поскольку тот, кто платит деньги, платит их за совершенно конкретную область своего бизнеса, т.е. за автоматизацию какого-то (возможно нескольких или наоборот только части) БП, а для того чтобы это понимать опять нужны БП)

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

На самом деле я еще пытался заострить внимание на том, что работа аналитика и архитектора совершенно разная (хотя это и не значит, что выполнять эти роли не может один и тот же человек). А вот топик стартер на протяжении обсуждения (ну первые 2/3 точно) слил все в одну кучу, поэтому и возникла неразбериха (я про паттерны и т.д.)

[Dimka]

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

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

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

Мои слова были адресованы человеку неопытному.

Так что считаю это лирическое отступление пустым флеймом.

Цитировать
А какое отношение БП имеет к Use case?
как это какое? а для чего вы будете писать кейсы? Вот вы представьте себя в роли аналитика, он приходит на предприятие и его сразу ведут к ключевому пользователю и он сразу пишет кейсы, так что ли?

А мне и представлять не надо. Я работал бизнес-аналитиком в проектах. Самые крупное предприятие, с которым имел дело в этом своём качестве, это ЛМЗ.

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

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

[lapulya]

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

Дайте мне 2 часа (всего 2 часа) и я за это время проведу лекцию где изложу методологию (ВСЮ!!!, а также всю "реализацию" методологии для маленького проекта, маленьким считаю проект от 2 недель, до 2 - 3 месяцев, силами 2 - 4 человек).

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

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

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

И где у меня написано, что применен не итерационный подход? Как раз наоборот... итерационный (что косвенно подтрерждается п. 2.1 и 3.1) с упреждающей разработкой архитектуры... Про пртотипирование у меня все написано:
1. И тех. реализация сложных механизмов
2. И про UI
3. И про логику (на ранних стадиях это именно проверки покрытия и трассировки, на поздних это они же + прототипы приложения)

[Dimka]

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

Меня, в отличие от тебя самого, мало интересует, как лично ты "крут" в RUP'е. Меня больше интересует тот факт, что нет массовых школ, качественных учебных пособий, позволяющих новичку воспользоваться этой методологией в её адаптированном варианте без длинных предисловий. В частности, твоё горячее желание прочитать лекцию лишний раз подтверждает именно такое положение дел (кстати, фраза "дайте мне" непонятна - а кто мешает?!). Хорошая методология содержит маленькое ядро и его расширения, которые можно отбросить без ущерба для понимания методологии целиком и "быстрого старта" деятельности. Плохая методология содержит большое ядро и адаптации/упрощения на случаи "быстрых стартов"; изучивший адаптацию при этом не может ответственно заявить, что он понимает всю методологию целиком.

И что? Это отменяет необходимость знания и понимания автоматизируемого БП

Странный вопрос. Я такого не говорил, ты такого не говорил. Отчего тогда вопрос? Или это тоже из области "пламенных речей"?

Как можно писать кейс и не понимать что он делает, кто актер и зачем его делают?

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

И где у меня написано, что применен не итерационный подход?

Я говорил исключительно о взаимосвязи use case и БП, а не о процессе разработки. Ещё раз: внимательно читай написанное.

[lapulya]

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

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

да, школ нет, а вот качественных (возможно местами, но в сумме они покрывают все) учебных пособий масса, было бы время и желания (второго как правило достаточно). Лекцию я читаю на эту тему достаточно постоянно, поскольку моим проектным командам и клиентам далее так придется работать, поэтому надо, чтобы все были в "теме". Более того, я занимался внедрением руп в 2 организациях, разработчиках ПО (в одной был полный провал, но это отдельная тема... там кстати образно говоря начали писать кейсы без понимания БП , но не по моей вине, я сделал все, чтобы этого не произошло )  как сотрудник, позднее в нескольких выступал как сторонний консультант. По методологии было выполнено море маленьких проектов (и всего около пяти средних, ТТХ год - полтора длительность, около 15 человек в команде со стороны исполнителя + около 12 со стороны заказчика).

у меня были перечислены шаги (в хронологической последовательности) хода выявления и анализа требований (необходимых для разработки ПО), в частности был у меня пункт 2, вот такой - "

какой(~ие) БП или их части надо автоматизировать

", на это был получен вопрос

А какое отношение БП имеет к Use case?

на это вопрос я дал исчерпывающий ответ - если коротко, то на базе описания БП строится кейс (и куча доводов).

Lapulya,

Как можно писать кейс и не понимать что он делает, кто актер и зачем его делают?

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

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

Поменьше книжного догматизма, побольше практических соображений

В первую очередь я практик, и практики настолько много, что я с уверенностью могу сказать, что БП первичен всегда.

Я говорил исключительно о взаимосвязи use case и БП, а не о процессе разработки. Ещё раз: внимательно читай написанное.

Под методологией (процессом и т.д.) разработки понимается весь процесс (от кикофа, до подписи акта о передачи в поддержку), а не только писанина кода. Так что я не понял к чему замечание. И ход анализа (чтоб покороче записать)
1. Key stakeholder request, Business needs (targets)
2. BP
3. UC
4. SRS, UI
и далее итерационный (если проект большой, некоторые шаги могут иметь несколько итераций).

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

[Dimka]

Вот именно!! "его интересы, роль и его видение БП", суда же еще и цели иииии -  это НЕ кейс, это БП

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

С этой точки зрения твоё утверждение:

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

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

В первую очередь я практик, и практики настолько много, что я с уверенностью могу сказать, что БП первичен всегда.

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

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

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

[lapulya]

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

кейс - это понятие из концепции рупа, а не только кусок UML диаграмм (именно в таком смысле я и использовал термин кейс, а не о "яйцах и человечках со стрелками"), так что про телегу ты погорячился. И действительно, ты прав, диаграмма используется для лучшего описания и понимания, но кейс, как понятие рупа, используется при применении методологии (при этом uml может вообще не использоваться). А то что в uml нет БП (кстати, вроде во 2 версии стандарта они есть) к рупу отношения не имеет.

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

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

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

"Птичий язык" это как раз кейсы, а вот с БП тут много проще (может не пониматься сам термин БП, но аналитик это легко обходит, главное общаться с клиентом на его языке). Любой (ну почти любой) сотрудник может сказать, что он делает, какой должен быть результат его деятельности, кому он нужен (ну как минимум кому он его передает  ), что он использует (речь про артефакты) для достижения целей, вот тебе и БП. Не бывает такого, что БП нет, он может быть неэффективным и т.д., но он есть и сотрудники могут о нем рассказать. Я согласен, что для достижения результата все средства хороши и зацикливаться на четком и неукоснительном следовании методологии не надо, но с другой стороны искусство аналитика заключается в том, чтобы выудить все ("все" это общее слово, в которое можно/нужно запихать огромный список) из скейкхолдеров  и при этом не взбесить их, тому есть куча рекомендаций (к рупу не относятся, ну кроме как разговора с заказчиком на языке заказчика, это так называемый софт скиллз). И вообще аналитик - это переводчик (я бы даже сказал, что дипломатия тут не последний момент) между сотрудниками заказчика и разработчика. А провалы в проектах по автоматизации... ммм я склоняюсь к другому выводу... очень слабое управление проектами (к рупу не относится), не зрелость команды (в том числе и не понимание методологии), очень плохое качество анализа (плохо выявлены и задокументированы требования, под час они даже не задокументированы, это ваще ппц) + игнорирование всех рисков.

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

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

На самом деле я еще пытался заострить внимание на том, что работа аналитика и архитектора совершенно разная (хотя это и не значит, что выполнять эти роли не может один и тот же человек). А вот топик стартер на протяжении обсуждения (ну первые 2/3 точно) слил все в одну кучу, поэтому и возникла неразбериха (я про паттерны и т.д.)

все же относится к проблеме обсуждаемой в теме (хотя и не соответствует теме)