Понимание RUP'а

[neco]

Заметил, что тема https://forum.shelek.ru/index.php/topic,15142.0.html всё ещё поддерживается, однако разговор там уже немного на другую тему, поэтому хотел бы вынести обсуждение понимания РУПа в отдельную ветку.
Дело в том, что читая дискуссию, которую вели Dimka и lapulya (надеюсь, вы это тоже читаете, поэтому не сочтите за разговор в третьем лице), я заметил, что мне как-то ближе то, что писал lapulya. Но во-первых, я себя опытным бизнес-аналитиком не чувствую (и поэтому постоянно сомневаюсь), а во-вторых, часто один скажет одно, а второй с ним согласится имея совершено другую точку зрения. На мой взгляд лучше, когда второй в ответ первому выразит своё понимание и первый согласится с данной формулировкой.
Т.е. сейчас я хочу быть вторым, который вроде бы как уловил суть того, что сказал первый (lapulya), и сейчас хотел бы выразить своё понимание данного вопроса.

Обучался я РУПу у Золотухиной Елены (отчества, к сожалению не помню). Курсы длились неделю, первые три дня у меня пухла голова от желания и неспособности уловить суть, а на четвёртый я всё же что-то понял. Признаю, что мог понять неправильно, а также то, что у преподавателя могло быть своё понимание, которое тоже может быть искажено.
Но, честно говоря, мне уже даже не важно, насколько то, что я понял является РУПом. Моя проблема в том, что сейчас на работе мы (наконец-то) формализуем процесс разработки и поэтому важно называть всё своими именами. И есть кое-какие несостыковки, но об этом позже.

Итак, как вести разработку по РУПу (версия моя, искажённая призмой моего мозга):
1. В основе всего лежат бизнес-процессы. Их обозначить в первую очередь и требуется. Причём важно, что собираем мы информацию обо всех бизнес-процессах (тем глубже и тем тщательней, чем, на наш взгляд, это может затронуть автоматизируемый бизнес-процесс). Если говорим, что мы документируем используя UML, то на этом этапе рисуются BusinessCases (которые графически выглядят фактически также как UseCases, только с чёрточкой сбоку).
2. BusinessCase'ы детализируются в ProcessFlow, которые дают понять какие именно этапы понимаются под данным BusinessCase. Это важно, поскольку часто по названию сложно понять, что же за этим понимается, а кроме того пользователь глядя на такой Flow может спросить "а где мы делаем вот это (какое-то действие)?" и тогда мы скажем "ах вы ещё и это делаете?" и подкорректируем своё понимание бизнеса.
3. Каждый шаг в ProcessFlow довольно в общем виде характеризует этап/действие. И поэтому их тоже надо детализировать. Следующий этап я не помню даже близко как называется, поэтому я называю его термином UML - ActivityDiagram, что, каюсь, неправильно. На этом уровне мы детально прописываем шаги и, что важно, у каждого шага указываем входные и выходные объекты. Если шаг не имеет входного или выходного объекты, значит мы что-то не понимаем.
4. Далее мы проходим по всем диаграммкам и помечаем какие из этапов (на ActivityDiagram'ах) мы будем автоматизировать. Фактически немного перефразируя названия этапов, мы получаем список системных требований.
5. Далее, имея на руках объекты, полученные в шаге №3, мы можем осмелиться начать рисовать диаграмму объектов или даже БД. В принципе, по-моему скромному опыту, на этом этапе уже редко ошибаешься.
6. Имея какое-то понимание бизнес-процессов, мы (фактически от балды) выдумываем нефукнциональные требования, применимые в данном случае. Может быть по странному стечению обстоятельств, но на данном этапе тоже вроде пока не ошибался с набором требований, хотя он и выдуманный.
7. Имея диаграмму объектов из пятого шага и требования из четвёртого и шестого, мы начинаем проектировать код (в голове ли или на диаграммах).
8. Когда чувствуем готовность пишем код. Код можем покрыть как юнит-тестами, так и функциональными тестами, исходя из списка требований. Пишем "снизу вверх", сначала реализуем нефункциональные требования. Функциональные требования и их принадлежность с определённым бизнес-процессам, позволяет разбить написание продукта на итерации.

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

Меня в моём понимании РУПа смущает ряд фактов. Пара из них:
- слабая итеративность. Т.е. итеративность начинается только тогда, когда более-менее сформировано понимание БП и можно приступить к кодингу. А сбор БП выглядит слишком уж большим шагом.
- если основой РУПа считать сосредоточенность на рисках, то у меня это нигде прослеживается.

Давайте, обменяемся нашими пониманиями на примере какого-нибудь бизнес процесса?
Например, мы собираемся автоматизировать "Жизнь простого смертного человека" (как если бы мы писали игру Sims).
Я бы делал это так:
1. Основные процессы в жизни человека, это "Питаться", "Работать", "Отдыхать", "Удовлетворять физиологические потребности". Нарисовали.
2. Заходим в "Питаться". Почему-то сразу вспоминаем про холодильник, но при этом понимаем, что холодильник в этом не всегда участвует. Возвращаемся на первый этап и дополняем бизнес-процессы.
1(а). Основные процессы в жизни человека, это "Питаться дома", "Питаться вне дома", "Работать", "Отдыхать", "Удовлетворять физиологические потребности". Нарисовали.
2(а). Снова заходим в "Питаться дома". Рисуем Flow: "достать продукты из холодильника", "приготовить поесть", "накрыть на стол", "поесть", "убрать за собой". Есть смутные сомнения, что "убрать за собой" является чем-то не входящим в данный процесс. Записываем мысль в notes, но оставляем так как есть.
3. Заходим в "достать продукты из холодильника" и начинаем рисовать детальный Flow с входными и выходными объектами. Придумали шаги: "открыть холодильник", "найти нужные продукты", "взять их", "закрыть холодильник". Теперь надо приписать им входные и выходные объекты. Что может быть входным объектом для шага "открыть холодильник"? Очевидно, что сам холодильник. А где мы его взяли? Купили! Возвращаемся к первому шагу и дописываем BusinessCase.
1(б). "Питаться дома", "Питаться вне дома", "Работать", "Отдыхать", "Удовлетворять физиологические потребности", "Покупать товары". Возвращаемся в третий шаг.
3(а). Шагу "открыть холодильник" во входной объект поставили "холодильник", в качестве правила тут же приписали "мы должны иметь холодильник" в notes (возможно, это будущий exception). Что поставить шагу "открыть холодильник" в качестве выходного объекта? Видимо "набор имеющихся продуктов перед глазами" - формулировка ни к чёрту, но оставим пока так. Следующий шаг "найти нужные продукты". У него во входных данных будет набор видимых продуктов и....? должно быть что-то ещё, иначе мы захапали бы все продукты сразу. Ага - нужен список требуемых продуктов. А он обычно рождается из какого-нибудь рецепта (пусть даже из головы). Значит возвращаемся к шагу 2.
2(б). Меняем шаги: "решить, что будем готовить", "достать продукты из холодильника", "приготовить поесть", "накрыть на стол", "поесть", "убрать за собой". Возвращаемся в шаг 3.
3(б). Есть список нужных продуктов, есть список имеющихся в холодильнике. Где-то тут будет исключение "не всё найдено" - пишем в правила в notes. Хочется совместить шаги "найти нужные продукты" и "взять их" - ок, делаем так, называем новый шаг "взять нужные продукты" и в выходные данные ставим "нужные продукты на столе". Откуда стол? Добавляем "стол" во входные объекты. Далее шаг "закрыть холодильник" - во входных данных у него холодильник, а в выходных гм... опять холодильник что ли?... Ага! Значит холодильник меняет состояния. Вводим для объекта "холодильник" два состояния "открытый" и "закрытый" и добавляем их к "холодильникам" в шагах "открыть холодильник" и  "закрыть холодильник".
4. Проходим по уже нарисованным диаграммкам и решаем, что автоматизировать мы будем полностью шаг "достать продукты из холодильника" (можно и лишь частично его автоматизировать, но он у нас и так короткий). Видим список системных требований "система должна позволять открыть холодильник", "система должна сопоставлять имеющиеся продукты с нужными" и т.п.
5. Знаем, что понадобятся объекты "холодильник", "продукт", "список продуктов", "стол" и т.п.
6. Нефункциональные требования пропустим, ибо я уже жрать хочу ))
7. Представляем себе код - понадобятся вспомогательные классы для сверки списков, нужны абстракции для продуктов, думаем, как будет меняться состояние холодильника и т.п. Если надо рисуем.
8. Пишем, что надумали. По ходу возвращаемся в предыдущие этапы, меняем что-то, рефакторим и т.д.

Был бы  признателен за подобную пошаговую инструкцию "а как вы разрабатываете софт"?
p.s. Уфф, всё - пошёл я жрать.

[Dimka]

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

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

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

а кроме того пользователь глядя на такой Flow может спросить "а где мы делаем вот это (какое-то действие)?" и тогда мы скажем "ах вы ещё и это делаете?" и подкорректируем своё понимание бизнеса.

А бывает и так, что пока пользователь не наткнётся на невозможность что-то сделать, он и не вспомнит, что надо было.

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

Следующий этап я не помню даже близко как называется, поэтому я называю его термином UML - ActivityDiagram, что, каюсь, неправильно. На этом уровне мы детально прописываем шаги и, что важно, у каждого шага указываем входные и выходные объекты. Если шаг не имеет входного или выходного объекты, значит мы что-то не понимаем.

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


Ну а про RUP пусть lapulya напишет лекцию - он в предыдущей теме порывался.

[neco]

При это возникает тендеция описать всю Вселенную.

Хех, это верно подмечено.

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

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

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

Вот это очень интересный момент. У нас на эту же тему возник разговор с моим начальником. Он бывший разработчик, по ходу действительно с хорошим бэкграундом. Но вот в этом вопросе мы с ним не можем сойтись.
Моя точка зрения в том, что надо рисовать диаграммки, обсуждать их с заказчиком, стараться делать их проще до тех пор, пока он не поймёт (пока я сам не почувствую, что он понял).
Его точка зрения в том, что диаграммы пользователям непонятны и нечитабельны для них (в этом похоже на твою точку зрения), но при этом он утверждает, что им надо предоставлять словесное описание всех этих процессов (в вордовском формате).
Для меня это вообще святотатство - свести иерархические диаграммы в плоский документ и потом дать кому-то этот многотомник прочитать. Я бы никогда не прочитал.
Dimka, а как ты сам ведёшь переговоры по бизнес-процессам? Пользователям почему-то ближе всего начинать переговоры с интерфейса (как они его себе представляют - у них сразу и критерии поиска и поля имеются), но начинать обсуждение с прототипов - не знаю, это как-то странно, нет?

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

"Поддержание объёма запаса сырья" - это, как мне кажется, полноценный бизнес-кейс, а не часть flow.
Т.е. этот по вышеописанной методике этот кейс будет биться на крупные шаги (для понимания сути), а потом эти шаги будут биться на детальные шажки (для выявления требований и объектов) вот тут-то и должны будут у каждого шажка появиться входные и выходные данные. И, не знаю, на моём скромном опыте я уже почувствовал подтверждение того, что входные и выходные данные должны быть всегда. Если пользователь говорит, что делает что-то и не имеет ничего результатом - значит надо поискать другого пользователя и уточнить у него.
Я конечно не работал с логистиками, но чисто интуитивно я бы разбил данный кейс на такие крупные шаги:
- Сверка планируемого и фактического уровней запасов
- Корректировка уровня запасов

и потом детализировал бы
- Сверка планируемого и фактического уровней запасов
----------- выяснить планируемый уровень (вход: артикул товара, план; выход: планируемый уровень) -> выяснить фактический уровень (вход: артикул товара, результаты инвентаризации; выход: фактическое количество на складе) -> вычисление разницы (вход: планируемый уровень, фактическое количество на складе; выход: разница).
- Корректировка уровня запасов
----------- если не хватает, то делаем следующие шаги, иначе в конец flow -> оформить заявку на товар (вход: артикул товара, количество, производитель; выход: заявка [заполненная]) -> отправить заявку производителю (вход: заявка [заполненная], производитель; выход: заявка [отправленная])

как-то так.
а оценка качества бесперебойности - это уже другой кейс, видимо. Но всегда есть что-то на выходе - будь-то отчёт или галочка в каком-нибудь спредшите. Иначе нет смысла делать что-либо.

Ну а про RUP пусть lapulya напишет лекцию - он в предыдущей теме порывался.

Ок, буду ждать ))

[Dimka]

Поэтому "либо сначала организуйте процессы по-новому и поработайте в новом режиме" либо "делаем так как у вас сейчас работает".

Разумно.

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

И ты прав, и твой начальник прав, и я прав Истина посередине. Схемы - это компактный и наглядный (графический) способ донесения какой-либо идеи. Нотации диаграмм (UML, IDEF0 и т.п.) позволяют добиться формализации графического языка, что полезно для личного использования аналитиком, организации работы группы аналитиков и взаимодействия между аналитиками и разработчиками. Пользователь не только не знает нотаций (и не собирается их учить), самое главное, что пользователь не имеет ни культуры, ни навыков логически строгого мышления, не умеет аккуратно обращаться с абстракциями. Это не профессия пользователя, поэтому не надо пытаться заставлять пользователя говорить с аналитиком на языке аналитика; как раз наоборот, аналитик должен говорить с пользователем на языке пользователя. Это значит, что в первую очередь прав твой начальник; но в то же время впадать в экстремизм чисто словесных описаний не нужно - в этом прав ты. Если вместо 2-х страниц текста можно сделать неформальную схему из квадратиков и стрелочек для пояснения идей, лучше делать именно так.

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

Я разделяю предмет анализа по уровням. Верхний уровень - общий охват (например, бизнес-процесса) без деталей, нижние уровни - детали, которые являются темами для отдельных встреч/совещаний/семинаров (как правило, в разных подразделениях предприятия). Но полного удовлетворения у меня от такого подхода нет, так как декомпозиция на верхнем уровне, на основе которой строится план остальных встреч и, возможно, "дорожная карта" анализа, сразу должна быть близка к правильной, или требуется повторная итерация с самого начала. Главное - не перегрузить пользователей и не дать им самим загрузиться темой до потери смысла мероприятия; поэтому объём информации на каждой встрече регулируется: поддерживаются разговоры, близкие к теме, и не поддерживаются (но фиксируются как дополнительная информация) разговоры, уходящие от темы. Здесь тоже есть сложности, так как "высокоуровневые" представления начальников далеко не всегда согласуются с "низкоуровневыми" представлениями подчинённых и их фактической работой. Ну и психология важна - люди разные бывают, и далеко не все умеют говорить внятно и по делу и давать говорить другим, не встревая и не начиная переубеждать в чём-то; это всё надо уметь контролировать.

Я конечно не работал с логистиками, но чисто интуитивно я бы разбил данный кейс на такие крупные шаги:
- Сверка планируемого и фактического уровней запасов
- Корректировка уровня запасов

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

Но всегда есть что-то на выходе - будь-то отчёт или галочка в каком-нибудь спредшите. Иначе нет смысла делать что-либо.

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

[neco]

И ты прав, и твой начальник прав, и я прав Истина посередине.

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

Вся эта информация должна как-то фиксироваться. И вот вопрос: на каком из этих уровней какой вид записи (диаграммный или словесный) ты используешь?

Ограничимся проверкой: если проверка показала, что запасов недостаточно, выпускаем "бумажку" - заявку на пополнение; в противном случае... нет результата? проверка без результата - бессмысленная проверка?

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

Код:

            var fact_qty = GetFactQty(good_name, storage);
            var plan_qty = GetPlanQty(good_name, plan);
            var diff = CalculateDifference(plan_qty, fact_qty);
            if (diff > 0) {
                var req = PrepareRequest(good_name, diff);
                SendRequest(req);
            }
            // end of the flow

Ты же требуешь от своих методов, чтобы они что-то делали? Можешь представить себе метод, который ничего не принимает на входе (и не использует глобальное состояние) или ничего не выдаёт (и не меняет никакого состояния, будь то глобальное или состояние объекта)?
Но от оператора if в качестве результата мы ждём только перенаправления потока выполнения - что и имеем.
То же должно быть и в бизнес-процессах, мне кажется.

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

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

[Dimka]

И вот вопрос: на каком из этих уровней какой вид записи (диаграммный или словесный) ты используешь?

Какой удобнее в конкретном случае

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

Т.е. ты пишешь "(Контроль)=>[Заявка]", где "Контроль" - активность, "Заявка" - объект. А внутри контроля

Код:

if Проверка then
  return Заявка
else
  return NULL

Но это не избавляет от обстоятельства, что иногда мы ничего не имеем на выходе.

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

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

Правда, отдельная тема - энтропия в данной точке; хорошая галочка - такая, про которую заранее ничего не известно, вероятности будет она поставлена или нет составляют 50/50, такая галочка наиболее информативна и нужна; плохая галочка - такая, которая всегда ставится или не ставится, вероятности 100/0 или 0/100, от неё никакого толку. А также взаимосвязь производителя и потребителя галочек. Но не буду углубляться в этот вопрос.

[neco]

Но это не избавляет от обстоятельства, что иногда мы ничего не имеем на выходе.

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

Вот здесь я нарисовал пример

Я вовсе не претендую на абсолютную правильность данного подхода. Просто в рамках моих потуг к анализу, вроде всё этому правилу соответствует.

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

[Dimka]

Ну всё равно у тебя от ромбика сразу на выход идёт стрелка.

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

Давай, только не в таком надуманном виде, как выше про холодильник.

[RXL]

Offtopic:

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

Поставлю в угол.

[Dimka]

Меня в моём понимании РУПа смущает ряд фактов. Пара из них:
- слабая итеративность. Т.е. итеративность начинается только тогда, когда более-менее сформировано понимание БП и можно приступить к кодингу. А сбор БП выглядит слишком уж большим шагом.
- если основой РУПа считать сосредоточенность на рисках, то у меня это нигде прослеживается.

Не знаю уж, куда делся lapulya - не спешит он ознакомить всех читающих с RUP'ом. Тогда обратимся к этому моменту.

Опять же, оговорюсь, что моё изложение не претендует на каноничность по RUP'у, ибо уже довольно давно я пришёл к мысли, что здравый смысл лучше буквы методологии.

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

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

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

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

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

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

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

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

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

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

[lapulya]

я предлагал рассказать, а не написать (не вижу смысла в писанине, про RUP и так много книг написано, из которых треть заслуживают внимания)

[Dimka]

lapulya, по крайней мере объясни, как ориентироваться в литературе по RUP. Раз ты говоришь, что 2/3 бесполезны, то каковы признаки полезных книг? Может порекомендуешь чего.

[lapulya]

Ну, вот эти не плохи, если смотреть именно в сторону RUP, если копать в сторону выявления, анализа, структурирования, трекинга и документирования требований, то надо ползти в другие книги, если интересует проектирование и моделирование архитектуры + рефакторинг, то еще другие и т.д.

Пер Кролл, Филипп Крачтен "Rational Unified Process - это легко. Руководство по RUP для практиков"
Филипп Кратчен "Введение в Rational Unified Process"
Джим Арлоу, Айла Нейштадт "UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование"

не совсем по RUP (больше для управления, но очень неплохо)
Уокер Ройс "Управление проектами по созданию программного обеспечения"

[ezus]

Спасибо!