16

Примеры / Re: Помогите построить диаграмму sequence

« : 03 Июля 2011, 12:49:08 »

Эдуард, я начала рисовать диаграмму, но на определенном шаге остановилась потому, что не знаю как это отобразить .
Siquence потому, что мне необходимо отобразить взаимодействие объектов в динамике.

17

Примеры / Помогите построить диаграмму sequence

« : 02 Июля 2011, 09:36:59 »

Здравствуйте.

Учусь рисовать диаграммы sequence. Помогите разобраться на примере следующей задачи:
Предусловия   В оперативной очереди ИШ есть сообщения для отправки
Постусловия   Сообщение передано в бизнес-логику (MessageBox) BizTalk
Основной сценарий   
Receive Port производит:
1.Проверку очереди ИШ на наличие сообщений для отправки. Сообщения для отправки найдены.
2.Проверку приоритетов классов, по которым были отправлены сообщения двух последних итераций обработки очереди:

       Итерация   Приоритеты классов, по которым были отправлены сообщения
если
   1   Общий   Высокий   Высокий
   2   Высокий   Общий   Высокий

то Производит извлечение и отправку в бизнес-логику BizTalk  одного сообщения для каждого класса последовательно из всей очереди ИШ    
            3   Высокий   Высокий   Общий

18

Системный Анализ и Требования / Re: Помогите сформулировать требование

« : 23 Июня 2011, 12:32:03 »

Galogen, спасибо, что откликнулись.

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

Не совсем так. Сообщения отправляются не подряд, а по одному для каждого класса. Найден класс с высоким приоритетом отправляется 1 сообщение (даже если для этого класса их будет 25), найден второй класс с высоким приоритетом отправляется 1 сообщение и так до тех пор пока не переберет всю очередь сообщений. Затем опять начинает перебирать очередь сообщений, находит классы с высоким приоритетом и все по той же схеме пока не переберет всю очередь. А вот на третий раз начинает искать классы с обычным приоритетом и производить отправку сообщений для каждого класса по такой же схеме, как я описала для классов с высоким приоритетом.

А потом все сначала.

19

Системный Анализ и Требования / Помогите сформулировать требование

« : 23 Июня 2011, 12:00:43 »

Добрый день.

Прошу помочь с формулировкой требования, а именно...

Существует оперативная очередь сообщений, из которой производится их (сообщений) отправка. Каждое сообщение отправляется по определенному классу, каждый класс имеет один из 2 приоритетов: высокий, обычный.

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

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

Заранее благодарю.

20

Системный Анализ и Требования / Re: Как Вы описываете требования к ПО?

« : 25 Мая 2010, 08:51:09 »

greesha, пойдем по порядку...
Попробуем разобрать по частям.

"Вам нужно описать функциональные требования в некотором проекте (ограничимся пока одним)."

Пусть так.

"Этот проект предполагает создание некоторого решения. (Что такое "решение"? Решение проблемы? Или под "созданием решения" понимается разработка программы или нескольких программ? А может быть, "решение" создаётся путём выбора уже готовых компонентов?)"
В данном случае под "решением" понимается совокупность программного кода, написанного разработчиками Поставщика,  готовых компонентов того инструмента, на базе которого осуществляется разработка и его настроечных механизмов. Хотя может случиться и так, что возможности продукта в целом способны будут реализовать необходимую функциональность, то тогда решением будет являться скажем ввод данных и настройка продукта (это я назвала контентом, хотя может и не очень корректно, потому как кроме данных реализуется логика работы и т.д). В качестве примера можно привести следующее: Задача состоит в автоматизации Системы Сбалансированных показателей (...как то я о ней упоминала на форуме). Берем готовый продукт MS PPS 2007, производим ввод данных по показателям, формируем необходимые карты и т.д. (не буду полностью описывать процесс, не имеет смысла). Решение построено. Построено на основе инструмента с некими функциональными возможностями. Если бы разработка осуществлялась "с нуля", то вопрос не возник бы и требования звучали примерно так: Система должна позволять вводить данные о показателях, Система должна позволять строить стратегические карты и т.д., но в данном случае это возможности продукта MS PPS 2007 и мы используя эти возможности решаем свою задачу по автоматизации ССП или иначе строим решение.

Это решение должно использовать какие-то готовые продукты MS, Oracle и т. д. (Какие конкретно продукты? Каким образом использовать? Почему должно?)
Выше привела пример. Ниже почему должно.

Среди прочего, вам нужно описать требования к контенту. (Что такое "контент"?)
Выше пояснила.

anastazya, вы очень компактно излагаете свои вопросы, не передавая при этом контекста. Изящные формулировки - это не самый эффективный способ обмена информацией. Или вы очень боитесь случайно раскрыть какие-то конфиденциальные сведения?
)) не все так плохо в смысле конфиденциальности. Да, каюсь, времени мало на общение.

Например, по некоторым ключевым словам (MS, Oracle и в первую очередь "контент") кто-то можно сделать вывод, что вы разрабатываете веб-сайты.
В том числе, но не только.

"А кто-то другой по тем же ключевым словам может понять, что вы адаптируете и внедряете какие-то тяжеловесные ERP системы."
И их тоже.

"А кто-то третий (я, например), может воспринимать Oracle и MS как ограничения заказчика, который какой-то из этих продуктов уже давно купил, и не собирается докупать новую СУБД и нанимать администратора исключительно для сопровождения вашего решения."
И такое бывает. А чаше мотивируя это тем, что завязываться на что то самописное опасается, так как это завязка на конкретного поставщика, который в скором времени может не подойти по ценовой политике или по другим причинам. Брендовые продукты проще сопровождать и выбор в поставщиках не так ограничен. Да это уже другая тема, почему Заказчик выбирает тот или иной продукт. Меня больше интересует постпериод, когда выбор сделан и необходимо решать задачу.

Надеюсь информации будет достаточно )

21

Системный Анализ и Требования / Re: Как Вы описываете требования к ПО?

« : 24 Мая 2010, 16:01:20 »

Всем доброго дня. Все чаще сталкиваюсь с проектами, где необходимо создать некоторое решение используя готовые продукты MS, Oracle и т.д. Подскажите, как в этом случае можно подойти к описанию функциональных требований? Описывать требования к существующим функциям продукта? Описывать требования к контенту? Что посоветуете?

22

Бизнес-анализ и Целеполагание / Re: Первый вопрос при интервьюировании. Анкетирование

« : 16 Марта 2009, 09:10:45 »

Мне кажется это стандартная ситуация работы с гос. органами и здесь меня ничего не удивляет. Даже при приеме на работу приходится отвечать вопрос о наличии опыта работы с гос. органами. Полностью согласна с подходом Юрия (предложить что-то свое, а Заказчик скажет да или нет), хотя конечно и в нем есть свои минусы и риски, но иногда это того стоит. В последнем проекте, в котором мне приходилось участвовать, пришлось исследовать маркетинговые инструменты и модели, например: матрица МакКинзи. Заказчик сказал: "Я слышал о наличии такой вещи, как матрица МакКинзи, изучите что это такое и как это можно привинтить к тем задачам, которые выполняются нашими сотрудниками" (Прогнозирование ситуации на рынках при изменении определенных параметров). Мы провели работы по изучению этой матрицы и нескольких альтернатвных инструментов оказалось, что более подходящим для этой задачи стал движок использующий методы иммитационного моделирования. Дав полное обоснование, Заказчиком была принята наша точка зрения и он отказался от идеи автоматизации матрицы. Однако почуяв, что можно сильно не напрягаться, Заказчик постоянно пытался идти таким путем... Имхо, здес важно не увязнуть...

Как то на этом же форуме читала тему, к сожалению не помню названия, писал Водолей о необходимости наличия у аналитика определенных начальных знаний. Поэтому я думаю, что если есть ожидания получить от Заказчика ответ на вопрос "как сделать стул" или "распилить доску", то они я думаю, эти ожидания, останутся не оправданными. Другое дело если проблема несколько в другом, например: Какой метод вы используете ЛИФО или ФИФО, а Заказчик просит вас сделать выбор за него, то мне кажется, что это работа консалтера, который сначала научит Заказчика жить , а потом вы эту жизнь будете анализировать.
   

23

Системный Анализ и Требования / Re: Как Вы описываете требования к ПО?

« : 25 Февраля 2009, 13:11:19 »

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

24

Системный Анализ и Требования / Re: Как Вы описываете требования к ПО?

« : 25 Февраля 2009, 12:53:59 »

greesha, разрабатывающей собственный софт

25

Бизнес-анализ и Целеполагание / Re: Первый вопрос при интервьюировании. Анкетирование

« : 25 Февраля 2009, 12:36:44 »

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

Психология.

Об этом и речь

26

Примеры / Re: Диаграмма activity

« : 25 Февраля 2009, 12:35:12 »

Денис, большое спасибо. Опубликованные тренинги я уже скачала, буду слушать и сомтреть .

27

Бизнес-анализ и Целеполагание / Re: Первый вопрос при интервьюировании. Анкетирование

« : 25 Февраля 2009, 11:45:01 »

Да, действительно подробное, но разве бывает "слишком подробное" при обследовании? Цель - разобраться в предметной области, автоматизацию которой планируется провести.

Я смотрю, что и моя и ваша использует шаблон описания БП. Имхо это не совсем понятно для Заказчика. Я столкнулась с тем, что Заказчик не понимает, что должен вписать в эту строку... Он не понимает что такое БП, да что там говорить не каждый аналитик может правильно его определить. Теперь я склоняюсь к тому, что необходимо запрашивать и описывать функции, которые выполняет Заказчик так ему понятней, а аналитик должне разложить все это дело по полочкам, определить связи между этими функциями и выстроить процессы. К тому же большинство организаций ориентированы на функции, а мы стремимся к процессному подходу, чтобы было с кого спросить

Как считаете?

28

Системный Анализ и Требования / Re: Как Вы описываете требования к ПО?

« : 25 Февраля 2009, 11:26:28 »

А мне хотелось бы знать как в требованиях вы описываете реквизиты форм (поля), с указанием обязательности из заполнения, типами и т.д. наверняка есть рекомендации на такие вещи. Посоветуйте что-то...

29

Бизнес-анализ и Целеполагание / Re: Первый вопрос при интервьюировании. Анкетирование

« : 25 Февраля 2009, 11:17:57 »

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

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

Вопросы первой тоже не задаю. Начинаю с чего-то вроде "Расскажите, что ..." (как, зачем - но чаще "что") и слушаю, направляя беседу.

Я начинаю с: "Научите меня делать Вашу работу" Дальше диалог очень хорошо начинает развиваться. Заказчик может спросить а какую именно, я могу спросить а какую вы делаете? и т.д

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

Хорошо, если встречу с заказчиком проводят два аналитика, из которых один слушает, а второй записывает. Сравнив результаты, вы откроете удивительные вещи

Полностью разделяю мнение по обоим пунктам.

Аудио или видеозапись - очень полезная вещь для интервью.
Мы, к сожалению, не пользовались.

Мы пользуемся, на мой взгляд очень полезно и удобно.

30

Бизнес-анализ и Целеполагание / Re: Первый вопрос при интервьюировании. Анке&

« : 25 Февраля 2009, 11:02:21 »

Nastёna, очень интересно... А посмотреть их можно? Если не жалко конечно. Я для себя использую методику обследования предметной области, предложенной здесь: http://www.mista.ru/obsledov.htm . С некоторыми корректировками, не использую DFD диаграммы и требования описываю по внутрифирменному шаблону.