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

×


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

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


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

1501
Денис, у меня был профиль на моемКруге, но особого эффекта (социально-экономического) я от него не ощутила, поэтому ушла оттуда.
Через 3 года после использования МК я начал получать через него заявки на заказы и обучение с регулярностью 1 раз в неделю.

В чём смысл удалять эккаунт, который не тянет карман? Если я захочу на вас сослаться или связаться, что мне делать? Я сейчас даже имени вашего не помню, не то что фамилии-сайта)

Ваш ник в этом форуме сейчас не работает на вашу репутацию.

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

1503
Денис, а что тебе мешает переименовать??
1. Это не моя тема, я вижу только то, что понял.
2. Эд один из лидеров форума, будет хорошо, если его названия будут выразительны.

1504
Как то так?
Эд, дорогой, спустись с небес абстракции.

Ты о чём пишешь в первом посте — о мешанине требований, технических решений и прочих высказываний под вывеской ТЗ? Ну так и назови.

1505
Эд, переименуй пожалуйста тему так, чтобы у неё было содержательное название.

1506
А кому и зачем может быть интересен сейчас LUXProject?

1507
Работа / Изменения рынка труда за 2008
« : 27 Января 2009, 02:46:34 »
http://hh.ru/file/1817341.pdf

По данным HeadHunter, за 2008 год в Москве средняя зарплата по предложениям для IT-аналитиков упала с 72 до 60 т.р., соотношение числа резюме к числу вакансий увеличилось с 1,18 до 3,39.

Менеджеры проектов остались в топе по отрасли со средним предложением в 63 т.р. и 4-мя резюме на вакансию.

1508
А в чём интерес именно к этой книге?
На Amazon.com со словом UML в названии находится 500 книг.
Просто интересно пальцем потыкать вероятность 1/500, а вдруг найдутся читатели этой книги?

1509
xP Xd Agile ICONIX пр. / Re: Agile-books
« : 30 Декабря 2008, 22:20:35 »
В торрентах

+

http://kibi.ru/xp/xp

1510
Я пытаюсь решать этот вопрос именно с точки зрения Заказчика, а не разработчика... :-)
А что тут решать?
Заказчик: Сколько времени займёт реализация фичи A?
Разработчик: 50 часов
Заказчик: Почему?

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

Поэтому лучший способ добиваться прозрачности — либо доверие, либо детализация сметы работ с точностью до задач, занимающих не более 3-5 человекодней.

1511
Кстати, есть простой ответ — если вы умеете считать бизнес-эффект от новых фич и изменений, то сможете отсекать нерентабельные доработки. Если не умеете — придётся играть в политику.

1512
Это классическая проблема из сферы получения прибыли, которая строится на сокрытии истинной трудоёмкости.

Я не очень понимаю, зачем таковая прозрачность Компании-Разработчику. Существует традиционный подход к оценке трудоёмкости и стоимости изменений у него:

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

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

3. Далее Разработчик смотрит на предмет того, насколько данное изменение будет полезно остальным Клиентам, если скорее бесполезно, то возникает дополнительный коэффициент стоимости.

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

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

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

1514
Для размышления.

Пример из книги UML2 b унифицированный процесс Арлоу и Нейшдатда
стр. 452 русского издания  раздел 20.5

Рассматривается проектирование вариантов использования для системы безопасности.

Акторами там являются некий SecurityGuard, Fire(Пожар)  и Intruder(Взломщик)
и рассамтриваются ВИ - деактивация системы, Активациявсего, АктивацияСигналапоПожару и какойто триггерсенсор

система безопасности встроеная работает в автоматическом режиме
Эд, ну встроенное ПО здесь не совсем в кассу, т.к. мы всё-таки про интеграцию. Хотя как пример того, что Способ Применения "Сообщать об инциденте" инициируется отнюдь не Взломщиком и не Огнём – это хорошо.

Ещё хороший пример – отработка любого триггера в БД, например, Журналирование Операций в независимую специализированную систему из, скажем, АБС. Понятно, что запись отдельной операции при взаимодействии с другой системой может пройти более или менее удачно, для описания чего прекрасно подойдут сценацрии, а Агентом будет либо АБС, либо Демон Журналирования (на ваш выбор, меня вполне устроит АБС).

1515
Аааааааааааааааааааааааааааааааааа, товарищи,

Ну зачем придумывать Демонов каких-то???
Кто сказал придумывать? На того, кто инициирует интеграционное взаимодействие – на того и вешаем, если Админ – то на Админа, если cron – то на cron'а (Отличая его от Системы как Таймер либо не отличая). В последнем случае это будет чисто Технический Способ Применения (Системный Вариант Использования).

Цитировать
Ну сами говорите, что ВИ - это ПТ, и что ВИ - это цель, а при описании Тр. к интеграции в лучшем случае получаем ФТ и Задачи.
Обновить, скажем, срез куба продаж за последние сутки – вполне себе Цель, связанная с реализацией интересов определённых Заинтересованных Лиц. Про только ФТ и Задачи – когда мы, например, моделировали Гарантированную Доставку для выгрузки Документов Дня Банка в отдельный Архив, мы вполне себе получили полноценный набор сценариев взаимодействия, с ожиданием подтверждения доставки и исключениями. Ещё раз – если интеграционная задача простейшая, не вариативная, т.е. не требующая учёта реакции агента, с которым она взаимодействует, например, генерация RSS или отправка фрагмента данных по почте – то да, можно попытаться обойтись без сценариев, хотя это только основной поток будет вырожденным до 1-2 шагов, а исключения всё равно лучше сценарными методами описывать.

Цитировать
Зачем использовать инструмент не по назначению? Ну можно же молотком (ВИ описывать Инегр. Тр.) колоть орехи, если Вы не знаете других способов, но только часть из них выживит, почему бы для этого не использовать специальные щипцы (например, Д Взаимодействия и словесное описание ФТ) ?
А с чего ты решил, что не по назначению? Чем "словесное описание" лучше набора сценариев? Д взаимодействия, как и любая Д, всегда носит вспомогательный характер и не может быть исчерпывающей.