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

×


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

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


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

1036
Пробуйте, я бы такой подход только приветствовал.

Как аналитик я всегда себя продавал нестандартно, поэтому проблем занудности собеседований и потерь времени не помню.

1037
Обсуждение статей / Re: BABOK для Золушки
« : 15 Сентября 2011, 13:59:24 »
Как вы думаете, для какого контекста больше всего подходит идеология BABOK — внутренней разработки и внедрения, заказной разработки, продуктовой разработки или системной интеграции? Для каких контекстов не подходит вообще?

Мне думается, что BABOK прежде всего применим в inhouse. Частично — в системной интеграции. В заказной разработке мало и в продуктовой совсем неприменим.

1038
Исторически один из самых древних методов — контекстная диаграмма.
Более формально в структурно-функциональной парадигме SADT это 2 списка — 1) входные данные 2) выходные данные.

1039
Обсуждение статей / Re: КС
« : 07 Сентября 2011, 19:44:36 »
Т.е. на мой взгляд вместо статьи "КС ЗНАНИЕ UML КАК ФАКТОР ВЛИЯНИЯ НА КАРЬЕРУ И РАБОТУ С ЗАКАЗЧИКОМ" гораздо актуальнее была бы статья "Умение писать сочинения, ессе, рассказы как фактор влияния на карьеру и работу с заказчиком".
Не?
Ну для тебя-то может и актуальнее, а ребята искали ответы на свои вопросы :)

1040
Я не говорю, что систему не надо разбивать на части.

Я говорю, что это надо делать ПОСЛЕ выделения и пакетирования способов применения, причём на уровне требований — только на бизнес-подсистемы, а не технические.

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

По российскому ГОСТу в ТЗ входит разбиение системы на подсистемы, поэтому вопрос имеет прямое отношение к «как формировать ТЗ».

1041
«По-модному» он описывает только вырожденные способы применения просмотра веб-страниц.

1042
Денис, да не важно, что взято за основу
А мне важно, тем более что вы начали рыть в сторону «да понимают ли они, что делают».

Цитировать
главное, что бы они понимали, что такое UC.
А вам это зачем?

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

А то, знаете ли, можно и холодильник в синий цвет покрасить — как вам идея? по-моему, здорово, давайте обсудим, плюсы-минусы-подводные камни.

1043
Да, и не совсем понял по поводу "...вопросы не имеют смысла"
Александр, вы знакомы с примерами документов Вигерса, опубликованными на его сайте processimpact.com? Сравните текст его документа с текстом индийца. И переадресуйте вопросы Вигерсу, если не находите проработки бизнес-части в документах Вигерса.

1044
При формировании ТЗ я разделяю данную систему на модули/подсистемы, отличающиеся своей функциональностью. Например: модуль цифровой подписи, модуль отчетности, модуль администрирования и т.п.

Таким образом, разбив концептуально целую систему на модули, я рисую ДВИ каждой подсистемы, описывая в спецификации то, как взаимодействуют с этой подсистемой пользователи + поведение самой подсистемы (алгоритмы работы - по сути те же UC, но ДЛ является сама подсистема).
Правильно ли я делаю?
Разбивать систему на модули невнятной категории при разработке ТЗ — эта классическая, но опасная российская практика. «Отличающиеся функциональностью» с точки зрения кого? Пользователя, заказчика, архитектора?

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

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

Вот что такое «модуль цифровой подписи» на уровне концепции? Зачем он нужен?

1045
:)
В корне не согласен с подходом товарища Putcha. Возникает вопроос, проводился ли вообще этап, именно, Бизнес анализа?! Определялись ли бизнес проблемы, которые необходимо решить с помощью открываемого проекта, выявлялись ли Business Actors, определялись ли их Goals, вообще, каким образом формируется список будущих Use Cases? Если путем функциональной  (или системной) декомпозиции будущей системы, то это врядли получится, так как на этапе формирования Busines Use Cases видение системы еще только самое общее... Прикинуть-то можно, только ценность такой прикидки будет нулевая.
Александр, Putcha всего лишь предложил названия, альтернативные тем, что заявлены у Вигерса: http://processimpact.com/process_assets/sample_requirements_documents.zip
За основу взят перечень способов применения из образца документа Вигерса, поэтому вопросы не имеют смысла.

1046
Из профиля уважаемого индийца я сделал вывод, что он работает и преподаёт в Индии.

Эд, ты не мог бы уточнить у него, о каких именно ошибках идёт речь во фразе «We arrived at this convention after seeing that a lot of students and professionals are utterly confused in interpreting the Use Case Names»?

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


1047
Это ITIL.
И что из этого следует? Что у Вигерса не такая уж и «исчерпывающая» классификация? Допустим :)

1048
Я еще думала, что это зависит от того, какую цель реализует требование. Так, если требование печатать отдельный документ вызвано желаеним сэкономить на бумаге, и это будет значимая экономия в масштабах предприятия, то это бизнес-требование. Если не значимая, то пользовательское.
Скорее, не какую цель, а чью. Интересы заказчика — бизнес. Пользователя — пользовательская.

1050
Это ожидание, а не требование. У требования есть типовые характеристики типа — атомарность, проверяемость и т.д.