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

Дисциплины => Системный Анализ и Требования => Варианты Использования (Use Case) => Тема начата: boatman от 10 Декабря 2007, 19:39:20

Название: И все таки вариант использования - это функция :P
Отправлено: boatman от 10 Декабря 2007, 19:39:20
В связи с тем, что в текущем проекте написание ТЗ выделено в отдельный этап и его приемка быдет выполняться в том числе и по формальным признакам, нашелся повод еще раз залезть в ГОСТ.

Выяснилось много интересного. В том числе и то, куда все же класть варианты использования в ТЗ по ГОСТ 34.602

Для того, чтобы это выяснить, смотрим ГОСТ 34.003-90 (Автоматизированные системы. Термины и определения).

Три определения:

Цитировать
1.1 автоматизированная система; AC: Система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций.

Цитировать
1.3 функция автоматизированной системы; функция АС: Совокупность действий АС, направленная на достижение определенной цели


Цитировать
1.4 задача автоматизированной системы; задача АС: Функция или часть функции АС, представляющая собой формализованную совокупность автоматических действий, выполнение которых приводит к результату заданного вида

Говорят нам о том, что
1. Система в ГОСТ является организационно-технической (люди + техника)
2. Функция в ГОСТ - это действия, направленные к (ВНИМАНИЕ!) цели, то есть могут быть описаны, в частности вариантом использования.
3. Задача - это набор действий, совершаемых автоматически, то есть функция, выполняемая техникой.

Определение из RUP толкует функциональное требование так:

Цитировать
Functional requirements specify actions that a system must be able to perform, without taking physical constraints into consideration

В результате получаем такое отображение ГОСТ -> RUP (и другие методологии)
функция -> вариант использование
задача -> функциональное требование

Название: Re: И все таки вариант использования - это функция :P
Отправлено: Galogen от 10 Декабря 2007, 20:11:53
Молодец, тонкое замечание.

Судя твоим поискам можно сказать так:
функция - это некий набор действия выполняемых в результате взаимодействия с пользователям, в интересах пользователя, испольняющих задачу пользователя.
Такая функция может быть описана в стиле варианта использования или если это не так разумно в стиле стимул - реакция.

задача - часть функции системы, выполняема по большей части автоматически, в рамках исполнения функции или без оной? Например обновление БД в 00 часов каждого дня. Хотя тут может в качестве пользователя выступить таймер и взаимодействие тоже налицо - так что и ВИ прокатит

Может разберем примерчик?

Да и перевод
Functional requirements specify actions that a system must be able to perform, without taking physical constraints into consideration

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

Не очень понятно про ограничения - имеется в виду без конкретики реализации?
Название: Re: И все таки вариант использования - это функция :P
Отправлено: Galogen от 10 Декабря 2007, 20:45:04
Понятно.
Т.е. ты предлагаешь такой подход:
Описать функцию - в виде сценария скажем.
Эта функция может включать шаги варианта использования, которые ты тут декомпозируешь для подробности.
Далее если шаг требует дальнейшей декомпозиции, дробишь уже на уровне требований?
Так  понимаю. Декомпозиция может быть продолжена?

Хотя вроде не так.
Общая функция подсистемы или скорее всей системы:
Загрузка данных (состоит):
  Загрузка блока данных (сценарий)
      требование 1, требование 2 и т.д. как элементарная операция или набор все-таки элементарных опреаций?
  Получить отчет о загрузке
  Отправить отчет о загрузке
  Принять блок данных

правда чем отличается REQ10 от ВИ C013

И все таки какова цель оператора? Судя по диаграмме, он может загрузить блок данных и тут же получить отчет, но может получить отчет совершенно независимо?
Название: Re: И все таки вариант использования - это функция :P
Отправлено: Юрий Булуй от 11 Декабря 2007, 01:31:32
Для того, чтобы это выяснить, смотрим ГОСТ 34.003-90 (Автоматизированные системы. Термины и определения).
Три определения:
Говорят нам о том, что
1. Система в ГОСТ является организационно-технической (люди + техника)
2. Функция в ГОСТ - это действия, направленные к (ВНИМАНИЕ!) цели, то есть могут быть описаны, в частности вариантом использования.
3. Задача - это набор действий, совершаемых автоматически, то есть функция, выполняемая техникой.

UC это конкретная цель пользователя по отношению к системе. В ГОСТ нет явного указания что это за "определенная цель" (функция АС: Совокупность действий АС, направленная на достижение определенной цели), не понятно кем определенной и чьей именно цели.
Далее, коль скоро функция = "Совокупность действий АС направленная на достижение определенной цели", а  АС = "Система, состоящая из персонала и комплекса средств автоматизации ...", путем подстановки получаем, что функция АС есть "Совокупность действий Системы, состоящей из персонала и комплекса средств автоматизации, направленная на достижение определенной цели (прим. не понятно ЧЬЕЙ именно цели)"
Т.е. АС ВКЛЮЧАЕТ в себя в т.ч. и Экторов (!) и следовательно цели уже получаются не совсем Экторов по отношению к scope, а по сути "Экторов + средств автоматизации". В то же время мы знаем, что Эктор в том же RUP, это внешняя по отношению к scope сущность, цель которой рассматривается отдельно. Отсюда следует сомнение в эквивалентности и прямом мэппинге понятий "Функция = ВИ"

Не стоит забывать про ключевое слово СИСТЕМА. ГОСТ 34 относится больше к системной инженерии, чем к программной инженерии.

Название: Re: И все таки вариант использования - это функция :P
Отправлено: bas от 11 Декабря 2007, 11:09:51
....
2. Могут ли быть действия без инициатора?
Ответив НЕТ
...
Для ф-ции инициатором м.б. сама система или другая ф-я, для ВИ же только актер.
Название: Re: И все таки вариант использования - это функция :P
Отправлено: Denis Beskov от 11 Декабря 2007, 11:39:40
ура, опять пошли разговоры за герменевтику )
Название: Re: И все таки вариант использования - это функция :P
Отправлено: bas от 11 Декабря 2007, 13:20:58
Сергей,

А ты видел презентацию Юры, когда он описывал что куда из РУП можно всунуть в ГОСТ?
Название: Re: И все таки вариант использования - это функция :P
Отправлено: bas от 11 Декабря 2007, 14:03:33
По идеи ГОСТ ф-я - это часть ВИ, т.е. один или несколько пунктов сценария ВИ.
Т.е. ВИ - это некая функциональность. И ВИ может служить для обобщения ГОСТ ф-ций, т.е. м.б. неким подразделом в ГОСТ ТЗ. Другое дело как этот подраздел описывать? В виде сценария или в виде требований/ф-ций? Если в виде сценария, то не понятно что делать с пред и пост условиями?! Да и вообще это больше походит уже на натягивание непонятно чего на непонятно что.
Возможно, будет правильнее сделать так:
1. ВИ
2. Сценарий ВИ
3. Ф-ции Системы, кот. трассируются к ВИ или п. в сценарии ВИ.
1 и 3 записываем в ТЗ, 2 оставляем для себя.
Название: Re: И все таки вариант использования - это функция :P
Отправлено: bas от 11 Декабря 2007, 16:52:03
Никаких ограничений в ГОСТ я не вижу, т.к. уровень декомпозиции не указан и вообще четкого требования к "ГОСТ ф-ям" нет.
Но, по-хорошему, - это не правильно по выше перечисленным причинам.
Название: Re: И все таки вариант использования - это функция :P
Отправлено: Sunshine от 11 Декабря 2007, 16:54:08
ТЗ это фактически единственный документ, который читает Заказчик. Вы хотите, чтобы он был сильно недоволен?
Написано : ТЗ делать по 34му ГОСТу. Как все люди- словами описывать. В ТП же развлечетесь вставками UC. Я так делала. ТП заказчик все равно читает сквозь пальцы, понимая, что это уже "технологии". А ТЗ - это святое, русскими буквами понятные предложения.
Название: Re: И все таки вариант использования - это функция :P
Отправлено: Galogen от 11 Декабря 2007, 17:15:15
Написано : ТЗ делать по 34му ГОСТу. Как все люди- словами описывать. В ТП же развлечетесь вставками UC.  А ТЗ - это святое, русскими буквами понятные предложения.

Уважаемая Анна Васильевна, а скажите мне, пожалуйста, как пишутся варианты использования? Не словами? А также, для чего пишутся варианты использования и как? Не пишет ли господин Коберн, что вариант использование ПИШЕТСЯ словами понятными для заказчика с использованием терминологии предметной области и избегания технических терминов, при этом форма ВИ определяется назначением документа. Разве неформальное описание ВИ, не может служить описанием функции, выполняемой АС? И разве связное описание не будет понятным заказчику?

другой вопрос - можно ли писать ВИ в ТЗ в какой-либо форме.

Как я полагаю дискуссия развертывается вокруг этого + вокруг того, как анализ требований ориентированный на ВИ приспособить к написанию ТЗ
Название: Re: И все таки вариант использования - это функция :P
Отправлено: bas от 11 Декабря 2007, 17:51:43
Сергей,

То ли ты не слышишь, то ли не хочешь слышать, что мы с Юрой пытаемся до тебя донести.
Любой ВИ может считаться ГОСТ ф-цией, но не любая ГОСТ ф-я может считаться ВИ.
Что бы полностью описать ФТ к Системе, то нужно еще как минимум БПр не забыть. Куда ты их будешь сувать? А еще порой не достаточно описать шаги ВИ, нужна еще и детализация некоторых шагов ВИ.
Просто, когда ты так говоришь, то большая вероятность, что ВИ в конечном счете превратятся просто в ФТ или простые операции Системы (ф-ции).
Название: Re: И все таки вариант использования - это функция :P
Отправлено: Galogen от 11 Декабря 2007, 18:26:46
В 34 ГОСТе нет ясной направлености на пользователя. Однако при описании функции АС их можно распределять по подсистемам. естественно подсистемы определяются с заказчиком(например подсистема кадровго утчеа, подсистема расчета и начисления з/п, подсистема учета успеваемости студентов и т.п.). Каждая подсистема может содержать набор выполняемых ею функций - достаточно высокоуровневых: ведение личной карточки сотрудника, оформление и учет кадровых приказов и т.п.
Очевидно, что ведение личной карточки сотрудников может состоять из некоторого набора сценариев. Стоит ли написать просто: Система должна обеспечивать упраление кадровыми данными сотрудника.
Или можно описать это более подробно в виде неформального описания вариантов использования?
Название: Re: И все таки вариант использования - это функция :P
Отправлено: Sunshine от 12 Декабря 2007, 09:50:09
Как вариант, предлагаю само ТЗ сделать как все (без вкропления инородных слов "вариант использования"). Все ВИ и их нужную детализацию вынести в Приложения. Другой вопрос, что объем ТЗ будет весьма велик и его, как следствие, заказчик может не дочитать.
И другой вопрос: а что тогда вставлять в ТП? =)
Название: Re: И все таки вариант использования - это функция :P
Отправлено: Galogen от 12 Декабря 2007, 11:56:41
Вопрос Sunshine и другим:
Является ли вариант использование требованием (или набором требований)
или
это описание реализации требования (проектное решение)?
Название: Re: И все таки вариант использования - это функция :P
Отправлено: bas от 12 Декабря 2007, 11:58:27
ВИ - это пользовательские требования, как написано, например, у Вигерса.
Название: Re: И все таки вариант использования - это функция :P
Отправлено: Galogen от 12 Декабря 2007, 12:04:22
ВИ - это пользовательские требования, как написано, например, у Вигерса.
это написано не только у Вигерса - т.е. ВИ это однозначно требование. ТЗ - это однозначно документ описывающий , что должна делать система. Т.е. явных противоречий нет, есть лишь противоречие можно или нет и в какой форме описывыать вариант использования в ТЗ, даже скорее несколько иначе, как использовать описания требований в виде ВИ в ТЗ по ГОСТ.

Ты точно указываешь что ВИ - не проектное решение, так что по-моему ему места в техпроекте нет, в техпроекте должна присутствовать реализация ВИ
Название: Re: И все таки вариант использования - это функция :P
Отправлено: Юрий Булуй от 13 Декабря 2007, 00:26:47
Вот еще для затравки ....ВИ -- это функциональные требования в контексте их использования
Название: Re: И все таки вариант использования - это функция :P
Отправлено: Galogen от 13 Декабря 2007, 08:16:40
Юра, ты думаешь все это выпускают из виду?
Название: Re: И все таки вариант использования - это функция :P
Отправлено: Gevorg от 13 Декабря 2007, 11:38:56
Для построения функциональной иерархии мы берем иерархию вариантов использования
 и выкидываем все ручные шаги (действия людей), тогда остаются или декомпозируемые функции или атомарные шаги-задачи.
Проблема только в том, что один ВИ может включаться в несколько других, тогда или поднимаем его на уровень выше или произвольно включаем в одну из ветвей функциональной иерархии. Так как важен, в основном, только список задач (функциональных требований) с их подробным описанием.

это очень близко моему опыту:
функциональные требования к разрабатываемой системе уровня пользователей (использование системы)
- однозначно в ВИ,

далее по ним - строю функциональные требования системного уровня,
а именно так:

собираю все строки сценариев, начинающиеся "Система(в ответ на пред-й шаг пользователя)...чего-то делает"

НО! Строю по ним ДРУГУЮ, логичную с т.зр. зависимостей функций, без учёта логики работы отдельных пользователей.

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

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

за выходные или на след неделе выложу соответствующее продолжение в тему об управлении требованиями.
Название: Re: И все таки вариант использования - это функция :P
Отправлено: bas от 13 Декабря 2007, 11:49:07
кроме того, что один ВИ может включаться в другой,
так и одна системная функция может обеспечивать(реализовывать) несколько разных шагов из различных сценариев и даже различных ВИ.

к примеру, один и тот же диалог просмотра данных по Клиету может использовать как Оператор контакт-центра,
так и Менеджер, изменяющий статус Клиента. Каждый -  в своих, совершенно разных, ВИ.
А не легче тут выделить ВИ включения или расширения? И сосредоточится на детализации каких-то шагов ВИ? Зачем по 10 раз все переписывать?
Название: Re: И все таки вариант использования - это функция :P
Отправлено: Gevorg от 13 Декабря 2007, 12:23:05
А не легче тут выделить ВИ включения или расширения? И сосредоточится на детализации каких-то шагов ВИ? Зачем по 10 раз все переписывать?
не легче
Гуры настоятельно советуют НЕ прегружать ВИ глубокой детализацией.
кроме того - функциональная детализация мне видится принципиально отличной от концепции ВИ, а соответственно, и место ей в другом документе, с другой структурой.
мне очень понравился термин "ортогональность" понятий ВИ и функции в одной из тем на форуме.
Название: Re: И все таки вариант использования - это функция :P
Отправлено: bas от 13 Декабря 2007, 14:39:18
не легче
Гуры настоятельно советуют НЕ прегружать ВИ глубокой детализацией.
кроме того - функциональная детализация мне видится принципиально отличной от концепции ВИ, а соответственно, и место ей в другом документе, с другой структурой.
мне очень понравился термин "ортогональность" понятий ВИ и функции в одной из тем на форуме.
Так нет, я имел в виду, что детализируем уже в других требованиях, более низкого уровня со ссылкой на пункт ВИ или весь ВИ.