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

×


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

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


Сообщения - Galogen

Страницы: « 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 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 »
5521
Публикую презентацию к семинару в форматах PowerPoint и OpenOffice Impress.
ZIP файл вероятно битый. По крайней мере, все кроме прицепленного в этом сообщении, удачно распаковываются, а презентация ppt не хочет

5522
С вашим с bas'ом и Эдуардовским определением прецедента как "неделимой последовательности..." не согласен категорически. Если в сценарии ясно различимы отдельные шаги, то термин "неделимый" здесь неуместен.

Несогласных у нас вешают по вторникам после завтрака, на десерт:-))


Неделимость придумана не мною, а авторами вариантов использования. Читаем хотя бы книгу Максимчука и Нейбруга "Проектирование БД с помощью UML": вариант использования должен твечать правилу WAVE( what, actor, value, entire)

entire I [In'taIq] n
1. редк.
1) полнота, всеобъемлющий характер
the entire of the night - целая ночь
the entire of his property - всё его имущество
2) целое
the entire flawed by poor workmanship - плохое исполнение /плохая работа/ портит всё
2. с.-х. некастрированное животное, особ. жеребец
3. портер (пиво)

entire II [In'taIq] a
1. полный, целый, весь
the entire country - вся страна
the entire world - целый мир, весь свет
the entire medical profession - все медицинские работники
entire liberty of conscience - полная свобода совести
entire happiness - полное счастье
entire ignorance - а) полное невежество; б) полное неведение
his entire devotion to his family - его безраздельная преданность семье
2. целый, неповреждённый; нетронутый
the fortifications were entire - укрепления были целы (и невредимы)
3. цельный, из одного куска
the book is entire in mood - книга отличается целостностью настроения
his heart was entire - его сердце не было затронуто, он ещё не любил
4. чистый, беспримесный; однородный
5. некастрированный (о животном)
6. уст. чистый; непорочный


можно добавить
entire contract — неделимый договор  (see contract)

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

5523
Цитировать
Посмотри тут http://www.processimpact.com/process_assets/sample_requirements_documents.zip

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

5524
Если не затруднит вас - ознакомтесь и выскажитесь.

Статья в общем интересная. Всегда интересно творчество, а не простая компиляция чего-либо:-)

Тем не менее мне не совсем понятна разделение понятий сценарий, вариант использования и сущностный элемент варианта использования.

Перевод essential use case вярд ли назовешь многовариантным.
essential - необходимый, существенный, неотъемлемый, первичный. Я не читал оригинила, могу допустить совершенно иную трактовку прилагательного essential, однако мне думается тут врядли стоит говорить о сущностном элементе - не сосем понятный термин.

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

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

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


5525
выбросить Огромное спасибо за большой вклад в создании сайта galogen.

Удалить или переформулировать фразу о Консалтинге

Определить в концепции ресурса: цели, задачи, структуру сообщества. Видимые и значимые результаты или наши потенциальные возможности. Можно посмотреть документ сообщества....

5526
Подытожим дискуссию.

Всем все ясно, но нам с Серегой яснее всех:-))

То, что к дискусии большого интереса нет, не говорит о не полезности оной, конечно. И так на форуме ты да я да мы с тобой:-)) Откуда выбирать.

Думаю следует немного посмотреть на тему "Формулировка цели". Не постановка. не возникновение, а именно формулировка. Хорошо поставленая задача - половина решения, хорошо определенная (сформулированная) цель - пол царства в придачу.

Позволю себе позволить занятся плагиатом и выдать на гора немножечко саксонского фольклера (Вигерс - хотя моеж он и не саксонец)
Примеры финансовых целей!!!!!!
Освоить Х% рынка за Y месяцев
Увеличить сектор рынка в стране X на Y% за Z месяцев
Достигнуть объема продаж X единиц или дохода, равного $Y, за Z месяцев
Получить Х% прибыли или дохода по инвестициям в течение Y месяцев
Достигнуть положительного баланса по этому продукту в течение Y месяцев
Сэкономить $Х в год, которые в настоящий момент расходуются на обслуживание системы
Уменьшить затраты на поддержку на Х% за Z месяцев
Получить не более X звонков в службу обслуживания по каждой единице товара и Y звонков по гарантии каждой единицы товара в течение Z месяцев после выпуска товара
Увеличить валовую прибыль для существующего бизнеса с Х до Y%

Примеры нефинансовых целей!!!!!!
Достигнуть показателя удовлетворения покупателей, равного по крайней мере X, в течение Y месяцев со времени выпуска товара
Увеличить производительность обработки транзакций на Х% и снизить уровень ошибок данных до величины не более Y%
Достигнуть определенного времени для достижения доминирующего положения на рынке
Разработать надежную платформу для семьи связанных продуктов
Разработать специальную базовую технологическую основу для организации
Получить X положительных отзывов в отраслевых журналов к определенной дате
Добиться признания продукта лучшим по надежности в опубликованных обзорах продуктов к определенной дате
Соответствовать определенным федеральным и государственным постановлениям
Уменьшить время оборота до X часов на Y% звонков покупателей в службу поддержки

Очень интересно! Правда все равно не могу въехать с какого бока меня касается как ИТ-ремесленника например цель: Получить Х% прибыли или дохода по инвестициям в течение Y месяцев. Да получай сколько хочешь, солнце родное!!!! Мне-то от этого какая радость? Вероятно мне будет большая радость, если я скажем глава отдела автоматизации оной компании, тогда да- премия, престиж, гордость за компанию и т.п. А если я вне?

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

Какие виды целей могут быть актуальными для таких видов?

5527
Один из способов -- в п.2.2. должны быть фичи, а в п 3.2 фичи делализируются конкретными требованиями (и группируются по фичам). Так легче контролировать scope, гогда он "облюжен" фичами.
Не по теме. Это на каком языке написано? :-))

Модератор: ответ по теме ...

5528
В чем смысл жизни?
В самой жизне как таковой.


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

Я тут спросил  у одного опытного аналитика по своему проекту. Он мне: А цель то у вас какая - бабки срубить? Хотя я про это явно не заикался. А что такое бабки срубить? Прибыль получить! И чтобы за это плохо никому не было:-)) Ты спросишь, а на кой ляд вам бабки? А чтобы жить, существовать! Ага, скажешь ты, вот в чем ваша серьмяжная правда (цель то бишь) - жить! А бабки для этого служат, значит средство:-)

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

И так решили прибыль средство, что есть цель бизнеса в схоластическом ее значении? У каждого своя, сию минутная?
Но может ли быть целью: получение 23% прибыли или повышение прибыли на Х% или получение вообще какой либо прибыли? Т.е. не получить убытков?
Думаю такая цель вполне нормальная
Тогда продолжаем мысль. Как же ее увеличить умножить и т.д:
1. модифицировать имеющуюся технология, производство, методику, устройство...
2. внедрить что-то передовое и очень производительное, и уволить 1000 человек :-)
3. что-то еще....

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

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

Насколько я понял и могу судить, зачастую от ИТ проектов требуется именно это - т.е. Нобелевская премия. При этом задание далеко сформулировано не так четко и буквально.

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


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

Вот посмотрим на диаграмму 2, она наиболее простая:
Основоной Актер имеет какие-то цели, каждая цель представляется одним или несколькими ВИ, каждый ВИ имеет некую ответсвенность. Что такое SuD - я не понял.

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

Саша, позволь не согласиться. Более того, это ты пошел немного не в ту область. Читай, что пишет автор сообщения.
Я ему лишь отвечаю. по существу вопроса, как я его понял.
Чуть позже я просто описываю проблему использования UML и акцентирую внимания на форме его использования.

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

А SuD это система проектируема, рассматирваемая система, system under discussion (or under design)

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

1. Представление Коберна о возможной структуре понятия действующее лицо
2. Диаграмма классов
3. Коберн привел эти диаграммы для того, кому нравится строить диаграммы
4. Кто и что брался развивать? Иерархию понятия действующего лица? Так не нравится - можно свое видение предложить

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

Тысячи людей с успехом используют UML. Тысячи успешно используют Use Case диаграммы, на разных уровнях абстракции, кто-то сопровождает такие диаграммы текстом, другие предпочитают делать диаграммы деятельности или последовательности.
Другие считаю, что вполне достаточно таблички Действующие лица и их цели, дополняя это текстовым описанием сценариев.
Рамбо например советует для особо сложных сценариев ВИ представлять диаграммы деятельности и диаграммы последовательности.
Другие вообще ясно и однозначно утверждают - одна графическая диаграмма заменяет десятки и сотни строк текста. Тескт неодназначен, картинка мол однозначна, елси сделана по правилам.
Сами по себе картинки конечно важны, но имеет больше смысла, когда эти картинки постепенно преобразуются в модель приложения и на ее основе генерируется каркас кода.
Технология MDA позволяет сформировать диаграмму классов, которая становится управляемым объектным пространством приложения (BOLD, ECO).
Диаграмма состояния позволяет сгенерировать соотвествующий код для отслеживания изменений состояния объекта (ECO)
Логика использования канонических диаграмм заложена в том или ином процессе разработки. При этом некоторые процессы могут использовать смешанные языки моделирования как на разных так и на одном этапе моделирования, проектирования.

Я например могу видеть такую цепочки: Use Case -> Диаграмма классов (VOPC) -> диаграмма последовательности (диаграмма кооперации) -> уточнение диаграммы классов (выявление опреация) -> диаграмма состояний для избранный объектов

5531
Ребята, кто будет, можете потом составить отчет по результатам конференции. Очень хотелось бы их увидеть.

5532
Это принципиальная ошибка. Прибыль - это не главное.
Отлично - это не главное, что тогда есть главное?

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

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

Цитировать
Пример:
Я продаю пирожки и пеку по 20 в час в своей старой печке.
Я заказываю печку, в которой можно печь пирожки по 60 в час (то есть в 3 раза больше) - это ТЗ и за это отвечает поставщик.
Но если я не в состоянии продать 60 пирожков в час или не купил нужное количество полуфабрикатов и не загрузил печку на полную или, просто, устроил себе выходной, то я не увеличу выручку в 3 раза. И поставщик печки не в состоянии повлиять на увеличение моей прибыли. По этому он только обеспечивает техническую возможность испечь 60 пирожков в час при условии соблюдения правил эксплуатации печки, остальное не его проблемы.

Пример конечно понятный, но все-таки не показательный. Это техническая задача.
Все-таки при использовании ИТ проекта ситуация не так прозрачна

5533
Интересно, аренда ПО будет популярна?
А такая услуга уже существует? Если да, то каков механизм ее использования и каковы цены и условия?

5534
Интересно.

Однако все равно есть неясные для меня моменты.

Не буду краток, буду точен.

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

Повышение ли, или просто получение прибыли - неприложный закон бизнеса.

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

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

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

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

Руководство обращается в фирму-разработчика ПО с задаче созданиям для них новой системы учета.
Какую цель они должны поставить перед разработчиком, и кто собственное ее ставить должен. БА предприятия, или БА фирмы разработчика?

Пусть, поставлена цель: снижение затрат на ведения учета на 50% через год после внедрения системы.

При реализации и внедрении ИТ проекта, для фирмы разработчика -это действительно цель?

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

А что будет если через указанный срок затраты на ведение учета снизятся на 20% только, или вообще не снизяться, или вообще возрастут?

Что в этом случае делать? Будет ли отвечать фирма-разработчика?
Будет ли вообще в таких условиях (гарантия снижения затрат на 50%) фирма-разработчика заключать контракт?

Я понимаю - это цель бизнеса в общем, но это же не цель собственно разработки. Цель разработки - разработать систему учета по передовой технологии...

5535
Попытка №1.

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

Страницы: « 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 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 »