16

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

« : 15 Мая 2011, 20:02:57 »

Вопрос следующего характера:
В ТЗ иногда  пишут use case.
Насколько уместно в ТЗ помимо вариантов использования включать конкретные сценарии (вплоть до указания вводимых пользователем данных).
Или для ТЗ это не преемлемо?

17

IDEF ARIS BPMN и пр. / Re: IDEF0: Как определиться со взглядом на модель?

« : 10 Февраля 2011, 20:32:22 »

Большое спасибо за ответ!
Мне надо чуть-чуть подумать.
Самое смешное, что есть:
* первая заинтересованная сторона (это утверждающая сторона). Она же заказчик программы
* вторая заинтересованная сторона (инициатор документа). Заинтересованная, но средне
* третья незаинтересованная сторона ))). хотела я и для программистов написать модель, чтобы они видели связи между функциями системы.

  - с точки зрения инициирующей стороны (тогда может стать понятен смысл визирования - поясните, кстати, зачем обратно в отделе А визировать? уведомить об утверждении?)

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

Вы, неплохо начав, стали путать действия (фактически операции, выполняемые с документами) и функции, выполняемые с определенной целью. Попробуйте ответить на вопрос "зачем?" для каждого своего пункта - "зачем выполняется согласование в отделе В" и т.д. Правильно сформулировав ответ, Вы скорее всего найдете цели, ради которых выполняются эти функции, и сможете их (функции) более корректно переформулировать.

вот это мнение и пыталась выяснить на форуме! насколько корректно подменять целевые функции (рассмотреть документ с целью ...") простейшими функциями системы (что делает система). Такое желание на секунду возникло.

Забудьте о программисте. Нет такой точки зрения в природе. Выдумана она. Программист - исполнитель чужой воли, он должен сделать так, как ему скажут.

Это была моя жалкая попытка нарисовать для программистов функции системы.
Им же интересно, что после блока "Передать на другой уровень"  документ опять появляется на входе процесса "Рассмотрение документа на предприятии (а уж там декомпозиция на простые функции).

попробуйте сказать сотрудникам отдела А, что они всего лишь редактируют документ - да они Вас загрызть могут :о)))

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

18

IDEF ARIS BPMN и пр. / Re: IDEF0: Как определиться со взглядом на модель?

« : 10 Февраля 2011, 19:52:35 »

Читала. Пытаюсь понять.
Представьте, что вы утверждаете строительную смету в разных конторах. Документ между организациями передается, подписывается. Блок А0 ясен (утвердить смету). Но  по отношению к документу внутри каждого блока "Согласование в организации А", "Утверждение в организации В"... действия одинаковые. Самое смешное, что функций прилично, но они почти идентичны на всех уровнях ("Сохранение документа", "Анализ документа по отношению к нормативному акту", "Корректировка документа" и т.д.)
1. Модель интересна пользователю, который будет работать с системой (тогда казалось бы лучше вариант 1, где ЖЦ документа).
2. Модель интересна программисту, чтобы видеть все связи функций. Тогда, казалось бы, просто перечень функций и связь между ними. ЖЦ документа не важен. Ведь по сути, с точки зрения программиста, согласование и утверждение это одно и то же (просто меняется организация).

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

Может сумбурно объяснила. Но я как раз не пойму какой подход разумнее.
Или для программиста надо писать свою модель, а для пользователя системы - другую?
Что-то из серии модель и альтернативная модель?
поддерживать актуальность сложно

19

IDEF ARIS BPMN и пр. / Re: IDEF0: Как определиться со взглядом на модель?

« : 10 Февраля 2011, 18:53:37 »

Я не обижаюсь. У меня дома есть Process Modeler, и UML-редактор...и BNMP скоро поставлю (жаль ARIS toolset не впечатлил, а его полнофункциональный собрат все ж труднодоступен).
Я думаю не надо играться из серии "это нотация клевая, а это фигня полная".
Если ты только учишься на аналитика, то работа с разными нотациями как-то расширяет горизонт понимания аспектов моделирования.
Если уж вопрос совсем тупой, то извиняюсь..... Мы все учились понемного, когда-нибудь да как-нибудь

20

IDEF ARIS BPMN и пр. / IDEF0: Как определиться со взглядом на модель?

« : 10 Февраля 2011, 17:58:29 »

Начала учить IDEF0. Столкнулась с проблемой при определении взгляда на модель.
Конкретнее: есть некая система документооборота.
Один и тот же документ рассматривается, корректируется и подписывается на различных уровнях.
Казалось бы, процесс пользователя определяется жизненным циклом документа:
1 Создание документа в отделе А
2 Согласование в отделе В
3 Согласование в отделе С
4 Утверждение в отделе Д
5 Окончательное визирование в отделе, который документ выпустил (отдел А).

Но создавать модель из этих 5 блоков казалось бы странно (декомпозиция 2 уровня).
Дело в том, что в отделах (п.2 - п.4) пользователь выполняет одни и те же действия: добавляет запись, корректирует и удаляет существующие записи, подписывает документ и т.д.

Насколько логична модель, где используется подход "отдельные функции":
1 создание документа
2 редактирование документа (декомпозиция на удаление, редактирование, добавление)
3 подписание документа.
4 передача документа между отделами ( + выход на вход п.2)

Вроде функции ясны, но ЖЦ сразу исчез! С другой стороны, в первом варианте куда запихать редактирование, удаление и т.д. (не дублировать же)
Описала конечно примерно, чтобы суть была ясна.

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