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

×


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

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


Сообщения - Denis Beskov

1936
Предлагаю опрос с целью последующей поисковой оптимизации.

1937
Денис! По поводу стереотипов для UC предлагаю до семинара помотреть в сторону Requironments диаграммы bp UML2
Ты должно быть имеешь в виду SysML.

1938
Для справки.
На форуме существует так называемая группа, основанная на количестве сообщений. Чем больше сообщений тем больше звездочек и соотвественно тем выше статус. Изменить текущие статусы на более информативные - не представляет трудности. Однако привязка таких понятий к количеству опубликованных сообщений сомнительна. Т.е. от того, что я опубликовал больше всех записей - не означает, что я становлюсь скажем Бизнес-аналииком. Т.е. это не подписи к аватарам как таковые, это статусные элементы, завязанные просто на количестве сообщений. Т.е. мы можем считать, что человек с большим статусом внушает доверия и является активным респондентом форума. Больше данная характеристика ничего не показывает. Подписи же к аватарам или просто подпись в письме, дело лично каждого. Так что советую просто указать это в своем профиле.
Вполне возможно, для SMF существуют дополнительные модули - если это так готов расмотреть возможностьих использования, но искать эти модули - свыше моих теперешних сил
Не, я не предлагал эти производные атрибуты менять. С подписью под профилем всё решаемо. Правда Senior Member мне совсем ни к чему.

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

1940
ПО Аналитика / Re: Помогите советом!
« : 18 Июня 2007, 12:38:03 »
Программисты UML не знают, опыта работы с CASE не имеют.
Кстати вы тут сразу автоматически попадаете на следующие задачи и связанные с ними риски:
1. Обучение процессу разработки.
2. Обучение UML.
3. Обучение CASE.
+ возможно Обучение английскому.

Подумайте, а вам оно надо? Может начать с и пока ограничиться постановкой гибкого процесса?

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

1941
ПО Аналитика / Re: Помогите советом!
« : 18 Июня 2007, 12:32:03 »
Первое и главное )
Если у вас с разработкой бардак, то никакой CASE сам по себе вам ничем не поможет. Нужно выстраивать и организовывать процесс разработки, неважно - формальный или неформальный.

Мне не очень понятно, что значит "вести разработку на CASE". Большинство современных CASE-средств поддерживают процессы Моделирования, Проектирования, Инженерного анализа, кое-какие - Управление требованиями, Документирование и Конфигурационное управление. Но всё равно ключевым инструментом Реализации остаются IDE-среды. Сред разработки, целиком покрывающих весь процесс, пока практически нет, если не считать Eclipse.

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

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

Скорее их слова нужно понимать как намёк на то, что нельзя просто найти, поставить и начать использовать UML-tool, а необходимо провести обучение хоть в какой-то форме (но не в форме "вот вам доки, читайте").

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

Например, в RUP помимо 9 дисциплин есть 6 базовых принципов:
1. Итеративная разработка
2. Управление требованиями
3. Использование компонентной архитектуры
4. Визуальное моделирование
5. Постоянный контроль качества
6. Управление изменениями

Вы уверены, что вам сейчас нужно именно 4?

Агилисты вообще говорят "Use the Simplest Tools"

1942
Господа коллеги, а возможно ли вот эти малозначимые подписи к аватарам на форуме "Hero Member", "Senior Member" заменить на что-нибудь более значимое? Например, "Бизнес-аналитик", "Системный аналитик", "Процессный консультант", "Преподаватель".

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

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

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

1944
Вобщем, чтобы перевести дискуссию в более практическое русло, я предлагаю каждому желающему подготовить мини-доклад на 10 мин сообщения + 10 мин обсуждения.

В частности, я готов рассказать о диаграммах прецедентов:

1. Расширение диаграммы прецедентов стереотипами <<потребность>> и <<функция>> - как я к этому пришёл, зачем это надо, как это использовать.

2. Использование отношений <<include>> и <<extend>> на практике - стоит ли их использовать при общении с экспертами заказчика и как сделать их максимально понятными для них.

Было бы здорово, если бы Юра сделал мини-доклад на тему "как убедить Заказчика в целесообразности использования прецедентов для описания ФТ".

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

1945
Я продолжил дискуссию потому, что на мой взгляд, решение не найдено.

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

Цитировать
Почему ты полагаешь, что если ты сумел найти 9 ссылок в интернет, значит это убедительный довод в твою пользу?
Потому что статистика говорит в пользу такой проверки.

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

Цитировать
Я говорю про устоявшийся термин, потому что
1. это дословный перевод с английского, который как раз и имеет то же самое значение
2. еще раз повторяю в литературе и нашей и переводной этот термин только и встречается (лично я других не встречал).
А я ещё раз скажу, что:

1) дословный перевод дословным, но для английской культуры термин swimlane уместен, потому что у них есть близкий термин - workflow, и вообще в английском языке деньги и работы текут (flow), а не ходят, как в русском, потому ассоциации с плаваньем у них уместны и удачны, в отличие от русскоязычной культуры.

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

Цитировать
Не знаю зачем упоминать тут про мою голову? Это в общем не твое дело, что у меня в голове и про что. Попрошу впредь выбирать выражения!
Ты же сам выше сказал "меня он устраивает", т.е. ограничил уместность и удачность термина своей персоной. Конечно, в рамках себя самого ты можешь считать что угодно. С другой стороны, если ты обиделся на то, что я не люблю ставить смайлики  и считаешь упоминание своей головы в качестве зоны признания нормальности термина неуместным личным выпадом, то practice what you preach, и как воспринимать твою фразу про "странный ты человек"?

1946
Ты сам желаешь получить ответ на риторический вопрос, и при этом требуешь АБСОЛЮТНОЙ точности от других в их ответах тебе (на риторический вопрос, подчеркиваю). В то же время сам же допускаешь неточность в формулировке вопроса. Так, в частности говоришь про "согласованно спроектировать" - это как? Далее "не забывая про детали и не делая ошибок" ... раз так, тогда давай формулируй требования к работе более внятно. Иначе это примерно тоже, что и "сделай мне крсной и синей краской шоб было красиво". О каких деталях идет речь? Что является критерием того, что детали не упущены? Что есть ОШИБКА, если все ПИШЕТСЯ со СЛОВ заказчика? Очевидно чтобы ответит на этот "вопрос-пример", ОДНОГО твоего описания НЕДОСТАТОЧНО.  Нужно заказчику "посмотреть в глаза", побеседовать, понять его действительные потребности, а не рассчитывать только на интерпретацию потребностей заказчика некими посредниками.
Во-первых, это не совсем риторические задачи, скорее - это те задачи, которые у меня так или иначе реально стоят и по которым пока окончательно не ясно, что лучше - сделать их самому или нанять консультанта. Я тебе прошу ещё раз - возьми пожалуйста один из моих примеров  и перепиши это предложение так, чтобы оно звучало корректным с твоей точки зрения, по желанию додумывая недостающие детали. Цель - добиться такой формулировки, которая позволила максимально продуктивно начать общаться с консультантом. Я для начала пока выкину те вещи, которые ты посчитал непрозрачными:
Цитировать
"Нужен человек, который сможет быстро со слов клиента описать в ARIS'е текущий бизнес-процесс продажи некоторого продукта и спроектировать с его же слов новый с учётом пожеланий по автоматизации".

Цитировать
Денис, ну это не серьезно ... ты хочешь сказать что ты не доверяешь этим людям, которые у тебя в контакт-листе?
Нет, это какая-то инсинуация. Я правда спрашиваю - рассылать ли всем, кому доверяю? Или только отобранным? Если отобранным, то как отобранным?

Цитировать
В любом случае тебе нужно будет ИСКАТЬ, как минимуем номер его телефона :-)
Я о том и спрашиваю, как искать, причём, чтобы это не было конём в вакууме, дал примеры задач.

Цитировать
Если упростить задачу - я могу порекомендовать людей тебе на CRM, очень серьезных ... по деньгам потянешь их услуги???
А при чём тут "очень серьёзные"? Такого пожелания вроде не было. Странно, что ты только сейчас вспомнил, что у задачи есть бюджет и наверное надо искать не просто так, а с учётом бюджета.

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

1947
... что проблемы на экзаменах связаны с тем, что студенты практически не читают рекомендованную литературу, а все свои знания извлекают только из лекций и практических заданий. Претензии свелись к тому, что мои требования читать дополнительную литературу необоснованы. Мол вы вот ведете один свой предмет, так сказать смотрите узко, а у нас в течение семестра множество других дисциплин и чо, по каждой читать ту литературу, которую нам рекомендуют? Я был, мягко сказать, в шоке....
Да, есть такая тема. Но тут смысл в том, что должен быть перечень ОБЯЗАТЕЛЬНОЙ литературы, и перечень ДОПОЛНИТЕЛЬНОЙ. И вот обязательную они должны читать, а твоя задача - обеспечить её наличие в университетской библиотеке. Думаю, если бы вузы заявили о своих потребностях в Вигерсе/Лефингуелле, то проблем с их переизданием не было бы.

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

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

1948
Хорошая у них кстати контекстная реклама (см. под результатами).

1949
1. Лучше формулировать цель, и критерии ее достижения, а на задачи сами с консультантом разберете
Мои примеры правильно сформулированы? Если нет, поправь плиз, чтобы было бы лучше.

Цитировать
2. Искать а) по рекомендациям людей которым ты доверяешь
Ну вот у меня у контакт-листе 300 человек, из них it-шников - штук 150. Спрашивать всех напропалую? А если в контакт-листе - 20 человек?

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

Цитировать
в) просто приглашать тех кого не знаешь и БЕСЕДОВАТЬ ... консультанты они ж тоже люди ...
Я много кого не знаю :) Кого мне приглашать на Друпал? На CRM? На моделирование БП мелкого опта?

Цитировать
3. Раздлить оплату на 30% + 70% или в иных пропорциях ... работать итерационно или поэтапно, анализировать результаты этапов и степень достижения поставленных целей
Как убедиться ДО начала работы - фактически речь о том, как ВЫБРАТЬ. Заплатить треть денег - это уже риск, не считая потраченного времени - как его снизить?

1950
Как устоявшийся термин от нормален.
Я не думаю, что 9 ссылок - это устоявшийся термин. Или ты про свою голову?