Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Водолей

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 »
166
но ведь очевидно, что этот единственный UC (как и сошлись раньше) - предметного уровня (привет военным об бизнеса!).
и этого недостаточно, чтобы разработать систему, в т.ч. ответить на вопрос - нужен монетоприемник или нет. или нужно ли предусмотреть купюроприемник (или оба два) или считыватель карточек (или все три). вот и изгаляемся с детализацией. думаю, что и она предметного уровня, только более детальная (на то она и детализация).

167
Цитата: Galogen
Может быть вариантом использования: вернуть деньги, выдать сдачу, выдать билет, принять деньги?

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

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

так что ты уж определись...

Цитата: Galogen
Да и вопрос, а если Actor = Пассажир, а Субъект = Монетоприемник, чья единственная функция - принимать монеты
Будет ли это правильно?

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

168
Цитата: lnew
В общем случае, процесс может и не иметь выраженной цели. Пример: "Это вполне естественный природный процесс!"

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

Цитата: lnew
прецедент описывает варианты процесса

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

169
IМНО процесс позволяет достигнуть цели - купить билет (либо в приведенном Вами варианте - получить деньги). для достижения этой цели необходимо использовать несколько UC, т.е. процесс реализуется несколькими (или всеми) UC

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

Это я к тому, что процесс - это одно, а UC - другое. они между собой могут быть связаны, а могут и нет.

170
Цитата: lnew
Представьте себе полноценный автомат, к нему подходит человек с целью возвратить свои деньги. Если автомат функционирует правильно, то он не отдаст чужие деньги. Т.о., полный процесс должен включать и засовывание монеток в монетоприемник! А это у вас отдельный Use Case?

неее, не надо путать отождествлять процесс и use case.

171
формально может, только речь должна идти о процессе управления требованиями. а ничего, что тема прорабатывалась раньше?
IMHO надо брать сравнимые разработки и рассматривать некий "стандартный" процесс управления требованиям, который в одном случае использовался, а в другом нет. и выявлять разницу между этими разработками.
и еще... умозрительно это не сделать, нужны формальные данные и факты. вряд ли они у вас есть :о(((

172
2 котик: Проблема в том, что определяющим фактором должна быть не зарплата программиста, а стоимость и востребованность продукта. Если продукт не пользуется спросом, его создатели вымирают или перерождаются, как вариант приучаются жить на скудную зарплату (пример, наши бюджетники)
Недавно в ЧГК был вопрос "почему был грустен газовщик?". Ответ был: "потому что газовые фонари на улице заменили на электрические", а программист не успел выучить java газовщик не умел ничего, кроме как зажигать и гасить газовые фонари.

2 Galogen: уже давно последовал этому совету :о))) но по другой причине, т.к. мою жизнь программирование обогащало, причем непосредственно :о))) сейчас ее же обогащает уже другая деятельность :о)))

173
угумс - программист, знай свое место!
:о))

174
Вопрос действительно интересный! Пошел за попкорном :о)))

2 Денис Иванов: IMHO а работник автовокзала (и почему, кстати, "авто-"?)  - actor? Он ведь не использует эти UC, разве что в целях тестирования какого-нибудь.
И потом зачем ему уменьшать время выдачи билета? Можно ведь поставить несколько автоматов (как впрочем и было раньше).
Целесообразнее сократить время обслуживания и увеличить интервалы между обслуживаниями (ну там рулон бумаги для билетов потолще, монетоприемник поглубже и популенепробиваемей, корпус повандалоустойчивее, электричество поменьшеупотреблениестей).

P.S. кстати, вопрос: автомат выдает только один вид билетов? может стоит добавить выбор билета хотя бы по пункту назначения?

175
IMHO основная ошибка кроется в словах "хочу получить от пользователя". Это принципиально неверно! Не нужно даже ждать получения чего-то подобного от пользователя. Нужно предлагать сделать так-то и так-то!
Действительно, откуда пользователь может знать, как ему работать с несуществующей еще системой???

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

Подобная же схема описана у Леффингуэлла.

P.S. Если нет понимания предметной области и имеющихся в ней сущностей и их связей и взаимозависимостей не надо вылезать со сценарием - заказчик все равно не будет вас понимать. Сначала разберитесь сами и научитесь понимать заказчика. Это конечно потребует определенного времени, но можно мотивировать его выделение за счет того, что будет создан более качественный и удобный для пользователя продукт.

176
Цитата: kas link
Я даже в курсе, что иногда аналитики умудряются общаться с заказчиком матами

дык надо же уметь говорить с заказчиком на его языке :о))))

177
еще точнее "будет ли гуд, если мы организуем управление требованиями в каком-то другом виде и выделим для этого отдельного человека?"

178
Цитата: skan201
to Водолей and greesha:
Не понимаю, почему столько негатива выливается в форуме на новичков форума? Почему отвечая на вопрос, вы задаете больше вопросов? Вы же аналитики. и не можете ответить на простой вопрос, указанный выше.

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

179
Цитата: Takhir
Часть причин указана ниже.

аааа, ну-ну...

Цитата: Takhir
Ого, это что-то новенькое. Люди есть, но без процессов будет как в басне «Ле́бедь, Щу́ка и Рак» И. А. Крылова

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

Цитата: Takhir
Качество измеряю не я и цифры не могу привести. И откуда берутся новые заказчики 1с бух?

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

Цитата: Takhir
Как ну и что? Приведу только один пример из множества: "Порядка 20 больших, маленьких проектов и крупных задач только за последние 3 месяца. Где мне взять инфу про проект двухлетней давности, если ПМ и разработчики уже давно уволились?"   

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


180
Цитата: Thyestes
Затраты РП (Руководителя проекта) при решении определенной задачи будут стоить больше , в сравнении с Аналитиком  (при условии что оклад у РП больше чем у аналитика). Т.е если аналитик за тоже  время решает данную задачу с приемлемым качеством , то расходы на него будут меньше.

Например, если считать что бюджет проекта =100. ТО для решении 1 задачи РП потратит 20 , а аналитик 16

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

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

получается, что изменения, связанные с вводом в команду аналитика, увеличивают затраты связанные с процессами и персоналом, и снижают возможности реагирования на риски :о)))

Цитата: Takhir
Хотелось бы еще услышать тех, кто управляет бюджетом на проектах

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

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

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

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

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


Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 »