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

×


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

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


Сообщения - div

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 »
121
MichealS,

вопрос не по теме форума. Такие вещи обсуждать лучше на sql.ru.

Кстати, паттерн Model-View-Controller и отделение бизнес-логики от представления - это немного разные вещи.

122
Так вот какие выводы и как можно получить, располагая этой информацией – выделить тренд, построить прогноз. Может я сумбурно выражаюсь, скорее не может, но где-то так)
Можно. Не сомневайтесь. Смело делайте.

123
Интересно: везде где я работал, задача продавца была продавать. Соответственно, его работа оценивалась положительно, если ему удавалось что-то впарить. А выяснил он при этом что-то или не выяснил, не имело значения, потому что выяснять - была не компетенция продавца. Вообще продавец - это частенько кто-то вроде гендиректора, поэтому оценивать его работу - достаточно неблагодарное занятие ;)

124
Как правило, ТЗ пишет тот, кому это больше всего нужно.

125
Внимание вопрос: какие принципы выделения БП верхнего уровня существуют?
Кажется, более или менее общепринято делить процессы на основные (обеспечивающие выполнение миссии, дающие прибыль) и обеспечивающие. А дальше я бы просто взял оргструктуру компании верхнего уровня (например, перечень департаментов), и исходил из того, что каждому руководителю департамента на совещании, посвященном обсуждению вашего документа, будет приятно узнать, что его депертамент выполняет БП Верхнего Уровня.
А если какой-то департамент окажется  не при собственном процессе Верхнего Уровня? Это как бы намек, что он мог бы и войти в состав другого департамента как подразделение более низкого уровня???
Проблемы при дальнейшем общении с начальником такого департамента вам обеспечены!

126
Выполнять моделирование бизнес-процесса можно в любом случае, но не всегда его НУЖНО делать ... из моей практики пример -- когда описание БП делалось только для некоторых важных типов документов,
Точно. Наблюдал у заказчика, как специально созданный отдел пытался построить в Aris абсолютно исчерпывающую модель бизнес-процессов организации (около 300 человек), чтобы потом более или менее автоматически эту DFD запихать в Documentum.
Но правила игры в конторе все время менялись, так что когда к концу очередного квартала была готова очередная версия мегамодели, все время оказывалось, что она уже не соответствует актуальному состоянию.
Я еще тогда обратил внимание, что в реальной жизни в организации часто работает параллельно в один момент времени два бизнес-процесса: старый и новый. А в СЭД это не поддерживается.

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

128
читая подумал, что речь идет не об "АйДиЭс" (IDS), а о "EDS" (ИДиЭс). Думаю, что лучше таки писать по-аглицки названия, чтобы не было путаницы...
Мне кажется, что IDS - это не по-английски, а по-немецки, так что ИДэЭс.
Вы SAP как произносите, кстати, ЭсЭйПи?
А BMW - БиЭмДаблви?

129
1. Исходная оценка трудоемкости на аналитическую фазу делались из предположения, что мы описываем бизнес процессы, а в итоге потребовалась детализация до функциональных требований, что вызывает необходимость дополнительных интервью и доработки документов;
А что в договоре написано, надо сделать описания БП или функциональные требования? Если просят сделать больше, чем в договоре - оценивайте затраты и подписывайте допсоглашение за отдельные деньги. Если уже сделали бесплатно - значит вы это сделали бесплатно, какой смысл теперь оценивать затраты?
2. В процессе согласования документов изменился список согласующих. Т.к. интервью с новыми людьми изначально не проводились (а у них свой взгляд на процессы и их полноту), то согласовать документы в текущем объеме нет возможности и требуются дополнительные интервью и обработка результатов;
Аналогично. Если вы уже сделали что-то бесплатно, то какой смысл обсуждать цену? Зато на будущее вы теперь легко можете вычислить разницу в оценке фактической и планировавшейся трудоемкости. Такие проблемы на всех проектах вылезают.
3. Задержка рецензий согласующими (почти месяц с даты отправки);
4. Задержка при запросах на предоставления информации (регламенты бизнес-процессов и другая документация заказчика)
Надо как в шахматах: передали документ заказчику - на его часах время пошло. Заказчик вернул документы: на ваших время пошло. Протоколы передачи надо подписывать. Если не было протоколов, то сейчас вряд ли чего добьетесь.
5. Набор описываемых бизнес процессов расширился (в начале проекта заказчиком был предоставлен список БП, котороые следует описать. в ходе проекта он был существенно переработан и расширен);
Ну так и хорошо: вслед за этим переработайте и расширьте калькуляцию за свои услуги.

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

130
Это лучше на sql.ru спрашивать.

131

4. Ближайшая к действию цель лучше дальней.
5. Время драгоценнее всего. Стоянием города не берут.
6. Смотри на дело в целом.
7. Ноша службы легка, когда дружно подымают ее многие.

«Потомство мое прошу брать мой пример…»
(Александр Суворов)

Мне всегда казалось, что Agile не вчера изобрели ;)

132
Еще нашел интересные идеи про синтаксический анализ самих требований на предмет различных слов и выражений влияющих на качество, таких как "может", "много", "мало", "быстро" и т.д.
Я бы еще добавил к этому списку слова "все" и "любой". Количество последующих изменений прямо пропорционально количеству этих слов.
Еще будет интересно сравнить размер требования в строках и оцененный разработчиками effort по имплементации этого требования в жизнь, думаю в большинстве случаев здесь должна быть прямая взаимосвязь и если требование краткое, а разработка занимает несколько дней или недель, то тут явно что-то не так с полнотой описания.
ИМХО, тоже очень хороший показатель.

133
прототипы в Axure, этот вариант мне нравится больше всего.
Алексей, не поделитесь, как Вам Axure, представителям заказчика какого уровня Вы показываете прототипы на ней, как они реагируют?

134
Ну как же так, не будете использовать функциональный дизайн... Вот вы подписали с заказчиком ТЗ или ЧТЗ, в которых написано, ЧТО надо сделать. А теперь надо написать КАК вы собираетесь это делать - это будет Функциональный дизайн.
ТЗ и ФД не исключают один другого, они делаются в разное время, с разными целями, и читаются часто разными людьми.

135
Примеры / Re: UML пример физической системы.
« : 21 Декабря 2009, 21:28:12 »
Вопрос цели как всегда первичен!
...пусть автор сам определится
+1
Подсказка для автора: цель - это, как правило, то, за что платят деньги ;)
Если Вам деньги за построение модели не платят, то ооочень трудно определиться с целью ее построения.

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 »