Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: p_safin от 16 Августа 2011, 12:31:40
-
Предположим, что я пишу техзадание на АИС. В процессе формирования ТЗ использую только MS Word и средство рисования uml-диаграмм (хотя, рисование, как я понимаю не обязательно, но желательно). При формировании ТЗ я разделяю данную систему на модули/подсистемы, отличающиеся своей функциональностью. Например: модуль цифровой подписи, модуль отчетности, модуль администрирования и т.п.
Таким образом, разбив концептуально целую систему на модули, я рисую ДВИ каждой подсистемы, описывая в спецификации то, как взаимодействуют с этой подсистемой пользователи + поведение самой подсистемы (алгоритмы работы - по сути те же UC, но ДЛ является сама подсистема).
Правильно ли я делаю?
-
А какие есть альтернативы такому подходу?
На мой взгляд такой подход выглядит вполне логично. Необходимость подготовки uml определяется кругом заинтересованных лиц, если все эти люди владеют uml, то, пожалуй, стоит потратить время на подготовку диаграмм, в противном случае подготовка uml-диаграмм может себя не оправдывать, как минимум ключевые заинтересованные лица должны владеть uml для работы с вашими диаграммами.
-
Павел,
В принципе правильно, но только использовать подсистемы в качестве ДЛ - это не правильно.
Если что-то не ложится в ВИ, то это описывается просто доп функциональными требованиями.
-
В рамках ВИ одной подсистемы - остальные подсистемы будут ДЛ. По моему, ни чему не противоречит
-
В принципе правильно, но только использовать подсистемы в качестве ДЛ - это не правильно.
Почему неправильно?
-
Павел,
В принципе правильно, но только использовать подсистемы в качестве ДЛ - это не правильно.
Смотрите, Александр, ведь ДЛ могут быть пользователи, внешние системы, часы (это по данным вашего доклада на ЛАФ). А почему бы не сделать ДЛ и другую подсистему, которая выполняет свой вариант использования в рамках границ рассматриваемой подсистемы (например, взаимодействует с ней для достижения какой-либо цели)? Тогда, по сути, другая подсистема является ДЛ по отношению к рассматриваемой подсистеме.
-
Павел,
Если что-то не ложится в ВИ, то это описывается просто доп функциональными требованиями.
То есть, помимо разделов ТЗ с описанием ВИ (пользовательские требования), необходимо создавать раздел с дополнительными ФТ для данной подсистемы? По сути, это "требования к функциям, выполняемым системой", исходя из ГОСТ 34?
-
Коллеги,
ВИ - это взаимодействие НАШЕЙ СИСТЕМЫ с внешними объектами (пользователями, др. системами, часами в конце концов), если же мы начинаем описывать в виде ВИ требования по взаимодействию между подсистемами НАШЕЙ СИСТЕМЫ, то теряем нужный/одинаковый уровень абстракции, т.к. будут ВИ по взаимодействию подсистемы с пользователем (один уровень абстракции) и будут ВИ по взаимодействию м\у подсистемами (другой уровень абстракции). Ни к чему хорошему это не приведет.
Исключения - это ВИ включения, необходимые для обобщения потока событий.
-
То есть, помимо разделов ТЗ с описанием ВИ (пользовательские требования), необходимо создавать раздел с дополнительными ФТ для данной подсистемы? По сути, это "требования к функциям, выполняемым системой", исходя из ГОСТ 34?
Именно так. А в чем сложность? Не надо все стараться засунуть в ВИ!!!
-
Коллеги,
ВИ - это взаимодействие НАШЕЙ СИСТЕМЫ с внешними объектами (пользователями, др. системами, часами в конце концов), если же мы начинаем описывать в виде ВИ требования по взаимодействию между подсистемами НАШЕЙ СИСТЕМЫ, то теряем нужный/одинаковый уровень абстракции, т.к. будут ВИ по взаимодействию подсистемы с пользователем (один уровень абстракции) и будут ВИ по взаимодействию м\у подсистемами (другой уровень абстракции). Ни к чему хорошему это не приведет.
Исключения - это ВИ включения, необходимые для обобщения потока событий.
1. кто сказал, что ... "ВИ - это взаимодействие НАШЕЙ СИСТЕМЫ с внешними объектами"? Это написано в спецификации?
2. все-таки нужно различать элементарные части системы и подсистемы
3. а зачем нам нужен одинаковый уровень абстракции? Может он нужен только будучи на определенном уровне? Если я на уровне всей системы, я имею один boundary. Но если я буду находится на уровне подсистемы, то эти другие подсистемы для меня такие же внешние сущности. Более того, эти внешние сущности-подсистемы помогают мне понять какие интерфейсы мне следует спроектировать.
4. возможно это не следует делать для простых системы, но Павел рассматривает АСУ, так что не вижу криминала, более того вполне законно и обосновано
-
Александр, с нарушением одинакового уровня абстракции в случае использования описанного подхода я согласен.
2. все-таки нужно различать элементарные части системы и подсистемы
Эдуард Геннадьевич, вопрос в следующем: "А как я могу отличить элементарную часть системы и подсистему?"
4. возможно это не следует делать для простых системы, но Павел рассматривает АСУ, так что не вижу криминала, более того вполне законно и обосновано
Нет, я не рассматриваю АСУ (АСУ - это довольно сложная система, где логично производить деление на подсистемы). В первом посте указано о том, что, допустим, я пишу ТЗ на автоматизированную информационную систему, которой может являться, вполне возможно, небольшое веб-приложение.
-
Именно так. А в чем сложность? Не надо все стараться засунуть в ВИ!!!
Александр, а не будет ли дублирования информации в разделе ТЗ, описывающем ВИ подсистемы, и в разделе с описанием требований к функциям подсистемы?
-
дублирования информации в разделе ТЗ
По идее не будет , а если и будет то другими словами :)
ВИ - это не функция.
И в целом, например, рассматривая подсистему - модуля отчетности, наверное ВИ и функции к данной подсистеме это разные вещи?
Как мне видится, описывать ВИ подсистемы как-то не очень правильно. У подсистемы есть функция формирования отчетности.
Но чтобы сформировать отчет пользователь использует скорее всю систему, а не только подсистему.
-
Эд, я высказываю свое мнение на основании довереных статей и книг и на основании своего немалого практического опыта. Можешь привести ссылки, где рассказывалось про дл, как подсистем?
Для бви имеет смысл бить организацию на отделы, для системы нет.
-
По идее не будет , а если и будет то другими словами :)
ВИ - это не функция.
И в целом, например, рассматривая подсистему - модуля отчетности, наверное ВИ и функции к данной подсистеме это разные вещи?
Как мне видится описывать ВИ подсистемы не как-то не очень. У подсистемы есть функция формирования отчетности.
Но чтобы сформировать отчет пользователь использует скорее всю систему, а не только подсистему.
Да, конечно ВИ и фунции - это разные вещи.
Смотрите, допустим, с помощью ВИ я описываю требования к п/системе формирования отчётности с точки зрения пользователя. Цель пользователя - сформировать отчёт. Исходя из этого пишется основной и альтернативные сценарии для данного ВИ.
Но а как быть с такими атомарными действиями, как СЧОУ (создание, чтение, обновление, удаление), ещё встречается термин CRUD. Они же, по сути, являются отдельными функциями данной подсистемы/модуля формирования отчётности? И, притом, в качестве ВИ действия СЧОУ не рекомендуется описывать, насколько я знаю.
-
Пока делаю такой предварительный вывод: допустим, разбиваем мы концептуально проектируемую систему (система может быть небольшой) на модули. Каждый модуль служит для выполнения какой-то отдельной функции. Соответственно, в ТЗ пишутся сценарии использования каждого из модулей, а также в дополнительных ФТ к данному модулю описываются атомарные функции вроде СЧОУ. Верно?
-
Павел,
Что-то мне подсказывает, что не совсем так (
В доп требования должно попасть либо детализация шага Системы из ВИ или те требования, кот. не описаны в ВИ.
А разбиение на подсистемы поможет разбить ВИ по разным Д, если биение не очень мелкое.
Давай лучше разберем на примере.
-
Павел,
В доп требования должно попасть либо детализация шага Системы из ВИ или те требования, кот. не описаны в ВИ.
Понятно. То есть, допустим, в подсистеме формирования отчётности пользователь может выполнять ВИ с названием "Формировать отчёт". Пишем сценарий на этот ВИ. Одним из шагов этого сценария будет действие по выбору отчета из шаблона. Описания сценария шага "Выбор отчёта из шаблона" и будет его детализацией, то есть дополнительным требованием?
Кстати, очень интересует метод описания требований к упомянутым выше атомарным действиям работы с данными (СЧОУ). Их тоже можно описывать в ВИ? Или в виде описания отдельных разделов в ТЗ?
Например, сначала описываем ВИ по формированию отчёта в одном разделе ТЗ. Затем в разделе дополнительных требований создаем раздел "Требования к функциям модуля отчётности" с подразделами:
- Требования к созданию отчёта.
- Требования к редактированию отчёта.
- Требования к удалению отчёта.
Требования в подразделах описываем с помощью обычного абзацного текста, не сценариями.
Зачем я задаю такие вопросы? Просто есть цель - сформировать для себя оптимальный и удобный шаблон документа требований. Знаю, что есть общие стандарты. Но также есть и корпоративные стандарты...
-
Эдуард Геннадьевич, вопрос в следующем: "А как я могу отличить элементарную часть системы и подсистему?"
Это зависит от контекста, но если система многоцелевая и многофункциональная - каждая цель-функция - подсистема, если нельзя так обособить, то наверное можно считать элементарной. Хотя ты, наверное, помнишь, что элемент - нечто, чье внутреннее устройство нам не важно, достаточно знать как функционирует (т.е. что получает на вход, что на выход).
Нет, я не рассматриваю АСУ (АСУ - это довольно сложная система, где логично производить деление на подсистемы). В первом посте указано о том, что, допустим, я пишу ТЗ на автоматизированную информационную систему, которой может являться, вполне возможно, небольшое веб-приложение.
Ну веб-приложение и не является АИС. Хотя не вижу проблем и в этом случае. Вот со студентами делали COS: систему для кафетерия. Там подсистема работы с меню - вполне самостоятельная независимая часть. Подсистема заказа клиента, вот она уже зависит от подсистемы меню, и т.д.
-
Эд, я высказываю свое мнение на основании довереных статей и книг и на основании своего немалого практического опыта. Можешь привести ссылки, где рассказывалось про дл, как подсистем?
Для бви имеет смысл бить организацию на отделы, для системы нет.
Каждый имеет право на собственное мнение. Я не буду спорить.
Но послушай, я не понимаю в чем разница между НАШЕЙ и НЕНАШЕЙ системой? Т.е. если ты разрабатываешь систему один -то все части твоей системы НАШИ? Ну, а если ты делишь реализацию своей системы по группам, которые будут работать параллельно? Разве для одной группы то, что делает другая группа, не будет некой обособленной ВНЕШНЕЙ частью?
-
Эд,
Теоретически можно говорить бесконечно, давай примеры.
-
Теоретически можно говорить бесконечно, давай примеры.
Саша, там не было никаких теоретических рассуждений, абстрактные - возможно. Абстракция вообще прекрасный инструмент аналитика.
Я не могу выложить тебе немедленно примеры, поскольку у нас в компании не используется UML в достаточной мере. А при обучении задачи слишком небольшие. Хотя на 5 курсе в ходе реализации проекта COS, о чем я много и, возможно, нудно писал, мы это делали. Некоторые наброски смотри в архиве.
Цели и задачи клиента - это первичные ВИ по клиенту (посетителю кафетерия)
Цели и задачи менеджера меню - это первичные ВИ по менеджеру меню (в качестве примера)
ДИ по подсистемам - это уже скорее некий архитектурный набросок, декомпозиция по подсистемам, показана как пакеты с зависимостями
ДИ Работа с заказами и подписками
ДИ Готовка блюд
ДИ Доставка
//в каждой из этих подсистем появляются дополнительные ВИ для сопряжения, естественно, что в них подсистемы выступают второстепенными ДЛ (сама по себе подсистема не обладает инициативой и потребностями, но она может действовать от имени)
Эти второстепенный ВИ являются дополнительными (учетными) источниками требований и при этом акцентируют внимание на наличие интерфейсов, что будет учитываться дальше в архитектурном анализе
Я, возможно, и ошибаюсь, но поскольку ВИ часть UML, то и следует это учитывать при работе с требованиями.
-
Эд, а не получается ли при этом уже функциональная декомпозиция?
Описав все СВИ относительно всех Пользователей вы и получите набор всех необходимых ФТ. Зачем еще дальше дробить на функции?
-
Эд, а не получается ли при этом уже функциональная декомпозиция?
Описав все СВИ относительно всех Пользователей вы и получите набор всех необходимых ФТ. Зачем еще дальше дробить на функции?
Саша, не в данном случае. Здесь не декомпозиция, здесь группировка по определенным (например, по архитектурным признакам). Я согласен, может это не должно сразу появится в ТЗ, хотя а почему нет? В этом случае просто меняются углы зрения и высвечиваются некоторые темные местечки. Если ВИ считать не просто констатацией требований, но и синтетическими штучками, то почему нет?
Мой вопрос в Use Cases Professionals: Could a subsystem be of an actor? Could one subsystem initiate (communicate) an use case of another one?
Ответы:
James Shields • Any user or system or subsystem that interacts with your system is an actor.
And your system is an actor when it interacts with another system or subsystem.
That other system or subsystem you interact with is often termed a secondary actor.
Personally I don't like this secondary actor terminology as it leads to confusion.
It's just a system or subsystem you interact with to use it's functionality via it's use cases.
Putcha Narasimham
If a subsystem SubX-SD becomes an Actor, the system boundary has to be redefined and the new SD NSD will be different. The SubX-SD must be truly independent of the NSD. As said earlier "initiation" use case is not crucial. It can be taken up and resolved later, that is after Naming the Use Case and its Goal.
I wish to restate what you wrote: "in some cases SubX-SD can initiate some UC of the NSD ON BEHALF OF a previous Actor (PA) of the original SD. PA is NOT directly connected to the New SD and is NOT an Actor of NSD". I hope this is consistent with what you wrote & intended.
If the SubX-SD is truly a subsystem with some independent processing power / storage etc (NOT A mere TRANSMITTER OF INFRORMATION with or without amplification) then the connection between SubX-SD and the PA (now Actor of SubX- SD) is irrelevant to the context of the new SD. SubX-SD must deal with the PA as its Current Actor CA separately in a suitable way. The SubX-SD must have its own GOAL (it may be related to what CA asks SubX-SD) with ref to the new SD. This is the principle of system boundary and specific context for each subsystem of any system.
Within a SYSTEM BOOUNDARY of an SD, NO SubSystems of itself should be recognized and represented in the USE CASE DIAGRAM of SD. Accordingly it cannot be an actor of another External System ES which may be connected with SD . If a USE CASE DIAGRAM of the ES is drawn, then SD as a whole will be an Actor of ES which will now be THE SD.
If an Actor A is a mere TRANSMITTER he or she or it is NOT an Actor. The entity on the other end is the true Actor of the System Under Development.
John Watson Hello Edward,
I think that if Ivar Jacobson had English as his first language that Actors would have been called Interactors. An Actor (or Interactor)symbol on a Use Case diagram represents a role filled by anything outside the boundary of a system that interacts with that system.
Consider an Automatic Check-in Kiosk at an airport. A traveller (Actor) interacts with the Check-in Kiosk (System) in order to obtain their boarding pass and bagggage tags. To complete the process, The Check-in Kiosk System requests the Reservation System (Actor from the viewpoint of the Check-in Kiosk) to validate the Traveller's reservation details. In this context, Get Boarding Pass is a Use Case of the Check-in Kiosk initiated by the Traveller Actor. From the viewpoint of the Traveller the Check-in Kiosk is a system and the Reservation System is "invisible". From the viewpoint of the Check-in Kiosk, the Reservation System is an Actor. From the viewpoint of the Reservation System the Check-in System is an Actor.
If you would like a diagram and Use Case descriptions to illustrate the above, e-mail me.
For scope control purposes we choose to treat the Check-in System and Reservation Systems as separate entities. From the viewpoint of each system (or sub-system?) the other system is an Actor
Мнения пока разделились :)
-
При формировании ТЗ я разделяю данную систему на модули/подсистемы, отличающиеся своей функциональностью. Например: модуль цифровой подписи, модуль отчетности, модуль администрирования и т.п.
Таким образом, разбив концептуально целую систему на модули, я рисую ДВИ каждой подсистемы, описывая в спецификации то, как взаимодействуют с этой подсистемой пользователи + поведение самой подсистемы (алгоритмы работы - по сути те же UC, но ДЛ является сама подсистема).
Правильно ли я делаю?
Разбивать систему на модули невнятной категории при разработке ТЗ — эта классическая, но опасная российская практика. «Отличающиеся функциональностью» с точки зрения кого? Пользователя, заказчика, архитектора?
Имхо в таком подходе получается месиво бизнес-архитектуры (внешняя группировка свойств системы, полезная для заказчика и аналитика) и технической архитектуры (внутренняя группировка свойств системы, полезная для архитектора и разработчика).
По моему опыту более полезно приходить к технической архитектуре через бизнес-процессы, фичи, способы применения. и их бизнес-группировку, а не так, что «модули» с техническим назначением вознимают как проектные решения раньше, чем способы применения.
Вот что такое «модуль цифровой подписи» на уровне концепции? Зачем он нужен?
-
Не разбив большую Систему на блоки/модули, трудно ее описывать и потом понимать. Возможно к этому нужно привлекать архитектора или группировать требования по бизнес-блокам, но это тема совсем уже другого топика - как правильно разбивать систему на блоки.
Как правило, кстати, модули потом (при разработке) разбиваются в соответствии с функциональной бизнес-принадлежностью, добавляя служебные.
-
А вообще Вигерс как-то начал описывать ВИ "по модному":
http://t.co/RAIHiTX
-
«По-модному» он описывает только вырожденные способы применения просмотра веб-страниц.
-
Я не говорю, что систему не надо разбивать на части.
Я говорю, что это надо делать ПОСЛЕ выделения и пакетирования способов применения, причём на уровне требований — только на бизнес-подсистемы, а не технические.
Технически в любой системе можно выделять подсистемы:
1. Подсистема отображения данных и организации взаимодействия с пользователем
2. Подсистема обработки данных
3. Подсистема хранения данных
4. Подсистема интеграции со смежными системами
От этого на уровне требований больше вреда, чем пользы.
По российскому ГОСТу в ТЗ входит разбиение системы на подсистемы, поэтому вопрос имеет прямое отношение к «как формировать ТЗ».
-
Разбивать систему на модули невнятной категории при разработке ТЗ — эта классическая, но опасная российская практика. «Отличающиеся функциональностью» с точки зрения кого? Пользователя, заказчика, архитектора?
Отличающиеся функциональностью - с точки зрения аналитика. Аналитик же пишет ТЗ и разбивает систему (любую, я не говорю именно о больших системах) на части/модули/сервисы.
Имхо в таком подходе получается месиво бизнес-архитектуры (внешняя группировка свойств системы, полезная для заказчика и аналитика) и технической архитектуры (внутренняя группировка свойств системы, полезная для архитектора и разработчика).
Про то, что получаются некие модули невнятной категории, смесь бизнес- и технической архитектуры - согласен. От незнания того, как делать правильно, и "каша в голове".
По моему опыту более полезно приходить к технической архитектуре через бизнес-процессы, фичи, способы применения. и их бизнес-группировку, а не так, что «модули» с техническим назначением вознимают как проектные решения раньше, чем способы применения.
То есть, Денис, вы предлагаете изначально исследовать то, что необходимо автоматизировать (процесс "AS IS"), затем по этому процессу определить, что какую деятельность конкретно необходимо автоматизировать (какую фичу создать), написать для этой фичи ВИ. Правильно понимаю?
Денис, имеется в виду бизнес-группировка способов применения (вариантов использования)?
Вот что такое «модуль цифровой подписи» на уровне концепции? Зачем он нужен?
Денис, дело в том, что сейчас я в ТЗ изначально рисую некую диаграмму концепции архитектуры - то есть то, из чего состоит система, какие сервисы содержит, и как они между собой взаимодействуют. Может это и не правильно и к такой архитектуре необходимо уже приходить системному архитектору.
-
Мне кажется, здесь изначально есть некоторая терминологическая путаница. Если мне не изменяет память, в терминологии ГОСТ модуль - это элемент конфигурационного управления, в то время как подсистема - часть архитектурного деления системы. Поэтому лично я хотела бы спросить у Павла, что же именно его интересует: разбиение системы на модули (и, соответственно, реализация требований к конфигурируемости создаваемого ПО) - или выделение подсистем для разрабатываемой системы.
Если рассматривать модули в их классическом смысле (реализации требований к конфигурируемости системы), то никакой путаницы возникнуть не должно.
Если же речь идет о выделении подсистем, то эта вещь должна лечь в основу HLA и заказчика, по большому счету, как таковая не интересует. Она затрагивает требования к масштабируемости (в основном горизонтальной), производительности, надежности и отказоустойчивости, и окончательный вариант лучше все-таки обсудить с системным архитектором (если он есть) или руководителем группы разработчиков. Аналитику, мне кажется, здесь лучше просто ограничиться логической компоновкой реализуемых функциональных возможностей.
-
Если мне не изменяет память, в терминологии ГОСТ модуль - это элемент конфигурационного управления, в то время как подсистема - часть архитектурного деления системы. Поэтому лично я хотела бы спросить у Павла, что же именно его интересует: разбиение системы на модули (и, соответственно, реализация требований к конфигурируемости создаваемого ПО) - или выделение подсистем для разрабатываемой системы.
Наталья, я тут пришёл к выводу, что скорее всего, говорю именно о реализации требований к конфигурации программной системы, т.е. модулях и сервисах (может применим в данном случае UML-термин "компонент"?). Пример: сервис взаимодействия с электронной почтой, сервис очистки данных. А это, на мой взгляд самый низкий уровень абстракции, в отличие от деления большой системы на подсистемы. Считаю, что такой метод нормален для систем, обладающей небольшой функциональностью.
До этого момента смутно предствлял, что такое конфигурация, в частности объект конфигурации. Нашёл ответ (ссылка на источник) (http://www.it4business.ru/lib/52/):
- Программная конфигурация – набор функциональных и физических характеристик программного обеспечения, сформулированная в документации или воплощенная в продукте (см. IEEE 610.12-90, Standard Glossary for Software Engineering Terminology). Программная конфигурация может рассматриваться как составная часть общей системной конфигурации.
- Элемент программной конфигурации (software configuration item, SCI) – фрагмент программного обеспечения, вовлеченный в процесс конфигурационного управления и рассматриваемый как одна (атомарная) сущность в рамках SCM-процесса (см. IEEE 610.12-90). Программные элементы, потенциально полезные в качестве элементов программной конфигурации (SCI), включают планы, спецификации и документы (например, полученные в результате моделирования и проектирования), программные инструменты, исходный и исполнимый код, библиотеки кода, данные и словари данных, а также документацию по установке, сопровождению, эксплуатации и использованию программного обеспечения.
Вот ещё (http://citforum.ru/SE/quality/configuration_management/): "Конфигурационные объекты (КО) могут представлять собой стол или самолет, если рассматривать оборудование, или программные средства в виде инсталляционных пакетов, если речь идет о программных средствах."
Если рассматривать модули в их классическом смысле (реализации требований к конфигурируемости системы), то никакой путаницы возникнуть не должно.
Наталья, похоже, это именно то, о чем я хотел сказать.
Если же речь идет о выделении подсистем, то эта вещь должна лечь в основу HLA и заказчика, по большому счету, как таковая не интересует. Она затрагивает требования к масштабируемости (в основном горизонтальной), производительности, надежности и отказоустойчивости, и окончательный вариант лучше все-таки обсудить с системным архитектором (если он есть) или руководителем группы разработчиков. Аналитику, мне кажется, здесь лучше просто ограничиться логической компоновкой реализуемых функциональных возможностей.
Как я понимаю, HLA - это высокоуровневый анализ.
То есть, получается, если предполагается создавать большую систему (например ERP), логично и необходимо делить её на подсистемы. Но, при этом, для аналитика достаточно указать логику взаимодействия и передачи данных из одной подсистемы в другую.
В каждой подсистеме есть некоторые модули (в терминах конфигурациии), которые выполняют некоторые функции. Требования вот к этим модулям и описываю.
Хотя, назревает вопрос:
- А как связать требования к модулям с пользовательскими требованиями (ВИ)?
Коллеги, возможно покажется, что каша в голове, но, желаю, в конце концов, разобраться в данном вопросе.