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

×


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

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


Сообщения - 474

Страницы: « 1 2 3 4 5 6 7 8 9 »
91
Дело в том, что создание регламента является завершающим этапом нашего проекта
Мне кажется, что Эдуард имел в виду те регламентирующие документы, которые у вас уже существуют. Сомнительно, что бы производственное предприятие могло успешно работать опираясь только на те знания, которые имеются в головах у персонала.

92
Я нашел такое утверждение.

A state invariant is:
A condition applied to a lifeline, which must be fulfilled for the lifeline to exist. 

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

94
Раз владеете методологией разработки , имеются навыки аналитика и управление проектами, то сможете поставить и процесс производства фильма.
Любая кухарка может управлять государством? ;)

95
В предметной области не только сущности есть и значимы.
Согласен. Я не писал, что только сущности.

96
кризис кризисом, а работать тоже надо
Хм. Продавать недвижимость тоже вполне себе работа. Тем не менее, пока в риэлторском бизнесе наблюдаются, в основном, одни только сокращения.

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

Впрочем, это офтоп. Предлагаю закончить обсуждение кризиса.

97
Денис, можно узнать, для чего эта задачка тут выкладывалась? Что ты в результате получил/узнал/сделал вывод?

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

99
Андрей, во первых у вас очень странная нотация выбрана. Мне кажется, что проще было-бы нарисовать это в ARIS или в IDEF. Тогда можно будет избавиться от надписей "входная/выходная", да и нагляднее будет.

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

А диаграммы UC будут уже на следующем этапе - "Описание способов применения". Кстати, а "структуры данных" - что вы под этим понимаете? Если это структуры в разрабатываемой ИС, то вряд ли их создает аналитик. Как правило это задача либо разработчика, либо архитектора. И что такое "сценарии"?

"Разработка макетов экранов" у вас на выходе ничего не имеет? А что же тогда там происходит?

100
Согласен с bas'ом. Сейчас, не понимая цели создания данной ДД, она смотрится излишне низкоуровневой.

101
Присоединяюсь к поздравлениям!
Расти большой и довольный, как говорила моя бабушка :)

102
Тогда уж - как написать "Идеальное ТЗ"? ;)

103
Нет, Денис говорил что-то об опросе, который производился неизвестно кем и среди неизвестно кого. Неизвестно - это в том смысле, что я не запомнил.
И был этот опросник, в котором была перечислена куча технологий (Денис назвал их методами) так или иначе соприкасающихся с ИТ. Кстати, на мой неискушенный взгляд этот список выглядел очень неоднородным.

104
Будет ли эффективно с точки зрения бизнес-показателей компании выделить одну из касс только для покупок объёмом не более 2 товаров?
А что следует понимать под эффективностью бизнес-показателей? Если рассматривать прибыль, как один из таких показателей, и поэ эффективностью понимать ее увеличение, то следует произвести оценку того, при каких условиях, возможно ее увеличить.

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

Как Эдуард написал, можно промоделировать. Например в GPSS, система хоть и старая, но для таких целей вполне подойдет.

105
Офтопик. А кто нибудь сталкивался с такой ситуацией, когда продумывание интерфейса отдается на откуп разработчику? У меня на работе именно такая технология. Макет интерфейса делается только если совсем сложная форма. Несложные формы разработчики ваяют прямо по ТЗ. Плюс в том, что при написании ТЗ нет надобности и интерфейс разрабатывать, а с другой стороны юзабилити полученного результата, мягко скажем, хромает. Правда у нас ПО для внутреннего употребления, возможно поэтому такая схема и продолжает быть рабочей.

По теме.
Если сейчас у вас этап разработки ТЗ, то сначала пусть все бизнес-требования соберут. А уже когда их зафиксируют(!), тогда и делайте прототип интерфейса. Причем сразу в VS, чтобы не наталкиваться на то, что нарисованное в Visio невозможно реализовать в VS. И на просьбы в очередной раз изменить ваш прототип требуйте обоснований. Изменения тех же бизнес-требований, например. Основной смысл - поставить между вами и заказчиками еще один слой, через который их пожелания будут проходить к вам и который будет играть роль фильтра для действительно значимых требований.

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

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