136

Системный Анализ и Требования / Re: Логично ли так формировать ТЗ?

« : 31 Августа 2011, 10:40:47 »

Если мне не изменяет память, в терминологии ГОСТ модуль - это элемент конфигурационного управления, в то время как подсистема - часть архитектурного деления системы. Поэтому лично я хотела бы спросить у Павла, что же именно его интересует: разбиение системы на модули (и, соответственно, реализация требований к конфигурируемости создаваемого ПО) - или выделение подсистем для разрабатываемой системы.

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

До этого момента смутно предствлял, что такое конфигурация, в частности объект конфигурации. Нашёл ответ (ссылка на источник):

- Программная конфигурация – набор функциональных и физических характеристик программного обеспечения, сформулированная в документации или воплощенная в продукте (см. IEEE 610.12-90, Standard Glossary for Software Engineering Terminology). Программная конфигурация может рассматриваться как составная часть общей системной конфигурации.
- Элемент программной конфигурации (software configuration item, SCI) – фрагмент программного обеспечения, вовлеченный в процесс конфигурационного управления и рассматриваемый как одна (атомарная) сущность в рамках SCM-процесса (см. IEEE 610.12-90). Программные элементы, потенциально полезные в качестве элементов программной конфигурации (SCI), включают планы, спецификации и документы (например, полученные в результате моделирования и проектирования), программные инструменты, исходный и исполнимый код, библиотеки кода, данные и словари данных, а также документацию по установке, сопровождению, эксплуатации и использованию программного обеспечения.

Вот ещё: "Конфигурационные объекты (КО) могут представлять собой стол или самолет, если рассматривать оборудование, или программные средства в виде инсталляционных пакетов, если речь идет о программных средствах."

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

Наталья, похоже, это именно то, о чем я хотел сказать.

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

Как я понимаю, HLA - это высокоуровневый анализ.
То есть, получается, если предполагается создавать большую систему (например ERP), логично и необходимо делить её на подсистемы. Но, при этом, для аналитика достаточно указать логику взаимодействия и передачи данных из одной подсистемы в другую.

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

Хотя, назревает вопрос:
- А как связать требования к модулям с пользовательскими требованиями (ВИ)?

Коллеги, возможно покажется, что каша в голове, но, желаю, в конце концов, разобраться в данном вопросе.

137

О Сайте и Форуме / Лента внешних блогов аналитиков

« : 30 Августа 2011, 12:46:35 »

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

В связи с этим есть повод для обсуждения вопросов:
1. Как назвать данный раздел сайта?
2. Какие блоги подключать к разделу? На данный момент лента работает в тестовом режиме, к ней подключены около 15 внешних блогов. В связи с этим предлагаю дополнить созданный excel-документ теми блогами, которые вы хотели бы видеть в ленте. Пока делаем упор на отечественные блоги.

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

138

Системный Анализ и Требования / Re: Логично ли так формировать ТЗ?

« : 30 Августа 2011, 12:33:15 »

Разбивать систему на модули невнятной категории при разработке ТЗ — эта классическая, но опасная российская практика. «Отличающиеся функциональностью» с точки зрения кого? Пользователя, заказчика, архитектора?

Отличающиеся функциональностью - с точки зрения аналитика. Аналитик же пишет ТЗ и разбивает систему (любую, я не говорю именно о больших системах) на части/модули/сервисы.

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

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

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

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

Денис, имеется в виду бизнес-группировка способов применения (вариантов использования)?

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

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

139

О Сайте и Форуме / Re: [ИДЕЯ] Тематические блоги на сайте

« : 29 Августа 2011, 13:27:57 »

Есть ли смысл включать в френдфид-ленту англоязычные ресурсы и блоги? Или ограничимся пока только отечественными блогами аналитиков?

140

Варианты Использования (Use Case) / Re: Именование вариантов использования

« : 29 Августа 2011, 12:05:29 »

Павел, мне показалось, что в подходе, описанном в твоем посте, для определения Use Cases опять же используются тот самый метод функциональной декомпозиции... Меня учили (и я с этим согласен), что это мягко говоря "неверный" подход. Дело не в чистоте учения! Дело в том, что такой подход уведет вас в сторону и создаст море проблем. Каких, можно обсудить
Короче! Не согласен я!  

Да, там нечто подобное: сначала декомпозируем систему на модули/подсистемы, а в рамках каждой подсистемы ДЛ выполняют определённые ВИ (но ВИ выполняются как ДЛ, так и, возможно, сервисом системы). Почему это неверный подход? В данном подходе, на мой взгляд, проявляется некое пересечение с ГОСТ 34.602-89, где изначально необходимо определить структуру системы, а потом уже написать функциональные требования к каждому модулю. Однако ФТ могут же быть описаны и с помощью ВИ.

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

Спасибо.

141

Варианты Использования (Use Case) / Re: Именование вариантов использования

« : 29 Августа 2011, 09:49:01 »

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

Здесь я вижу некоторое пересечение в недавно созданной мною темой.

142

О Сайте и Форуме / Re: [ИДЕЯ] Тематические блоги на сайте

« : 25 Августа 2011, 09:06:55 »

Мы долго шли к коллективному блогу, но так и не используем его активно. Почему? Трудно сказать, но это факт.

Предлагаю на этом блоге размещать статьи от сообщества uml2.ru, написанные коллективно, а также те материалы, которые размещают участники, которые привыкли это делать именно через коллективные блоги. Для написания статей коллективно наверное лучше всего подходит Wiki (к сожалению, сам не пользовался ни разу, но слышал отзывы), либо гугл-доки (применял, и не раз).

143

О Сайте и Форуме / Re: [ИДЕЯ] Тематические блоги на сайте

« : 25 Августа 2011, 09:00:04 »

Павел, посмотрите как все реализовано у software-testing.ru. Мне кажется, можно что-то в подобном же ключе.

Мы долго шли к коллективному блогу, но так и не используем его активно. Почему? Трудно сказать, но это факт.

Что с ним делать? Оставить? Убрать? Оставить и интегрировать ленту анонсов блога на первой страницы с индивидуальными блогами? Последний вариант мне нравится больше (правда, там другой стоит движок drupal)

1. Администратор software-testing.ru дал советы по настройке такой функциональности на uml2.ru (см. e-mail).
2. Коллективный блог очень неудобный. Лучшим вариантом будет агрегированная лента: пусть каждый выбирает удобную площадку для изложения мыслей, а мы добавим уже подписку в наше ленту. Однако тут есть одна проблема: важно фильтровать только ту информацию, которая ценна и отсеивать всё лишнее. Это можно решить либо рассылкой на e-mail авторов блогов письма с просьбой писать только на проф. темы, либо подпиской на rss определённого тега блога (некоторые площадки поддерживают такую функциональность), либо вручную фильтровать ленту. Последний вариант самый трудозатратный. В любом случае нужно попробовать.

144

О Сайте и Форуме / Re: [ИДЕЯ] Тематические блоги на сайте

« : 24 Августа 2011, 15:49:53 »

Ну я для себя блог сообщества видел немного в другом свете. То есть не так, что все дружно взяли, побросали свои блоги и начали писать только в блог сообщества.

А так, чтобы посты, касающиеся аналитики, из своего блога кросспостить в блоге сообщества.

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

У меня вот, например, 2 блога: личный (подседневная жизнь), профессиональный - события и высказывания, ссылки относительно профдеятельности.

Сейчас вот думаю над вопросом агрегации блогов аналитиков.

145

Варианты Использования (Use Case) / Re: Варианты использования не могут иметь пред и постусловия

« : 22 Августа 2011, 10:44:55 »

Если UseCase выполняются в определенной последовательности, то этот общий процесс можно определить как Use Case более высокого уровня, описать его как деятельность, действия которой - Use Case включения и расширения.

И на Use Case Diagram неправильно показывать последовательности их выполнения, она не для того предназначена.

Вот этого выражения не хватает во многих книгах по UML для понимания того, для чего же нужны ассоциации включения и расширения. Везде include и extend описаны слишком замудренно. Я поначалу тоже думал, что стереотипы include нужны для того, чтобы показать последовательность выполнения ВИ. Но теперь наступила окончательная ясность, что это не так на диаграммах ВИ. Спасибо за разъяснение.

То есть, смотрите. Есть UC. Описываем его шаги текстом (не ДП или ДД). Каждый шаг - это т.н. "поддеятельность". Эти шаги и описываем как расширения и включения. Верно?

146

Варианты Использования (Use Case) / Re: Варианты использования не могут иметь пред и постусловия

« : 19 Августа 2011, 15:40:50 »

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

+1.
Я ранее предлагал создать либо RSS-поток блоггеров-аналитиков, либо хотя бы twitter-ленту, код которой можно легко встроить в страницу сайта.

147

Системный Анализ и Требования / Re: Макеты интерфейсов + ГОСТ

« : 18 Августа 2011, 10:08:04 »

По остальному.
Можно в Требования к эргономике и технической эстетике или  Требования по стандартизации и унификации.
Смотри
Техническое задание по ГОСТ 34 - разделы 4-8

Да, спасибо.

Вот тут http://www.rugost.com/index.php?option=com_content&task=view&id=108&Itemid=62#4_1_6
и тут http://www.rugost.com/index.php?option=com_content&task=view&id=108&Itemid=62#4_1_13
конкретно про GUI написано.

148

Системный Анализ и Требования / Re: Логично ли так формировать ТЗ?

« : 18 Августа 2011, 09:43:59 »

Павел,

В доп требования должно попасть либо детализация шага Системы из ВИ или те требования, кот. не описаны в ВИ.

Понятно. То есть, допустим, в подсистеме формирования отчётности пользователь может выполнять ВИ с названием "Формировать отчёт". Пишем сценарий на этот ВИ. Одним из шагов этого сценария будет действие по выбору отчета из шаблона. Описания сценария шага "Выбор отчёта из шаблона" и будет его детализацией, то есть дополнительным требованием?

Кстати, очень интересует метод описания требований к упомянутым выше атомарным действиям работы с данными (СЧОУ). Их тоже можно описывать в ВИ? Или в виде описания отдельных разделов в ТЗ?

Например, сначала описываем ВИ по формированию отчёта в одном разделе ТЗ. Затем в разделе дополнительных требований создаем раздел "Требования к функциям модуля отчётности" с подразделами:
- Требования к созданию отчёта.
- Требования к редактированию отчёта.
- Требования к удалению отчёта.

Требования в подразделах описываем с помощью обычного абзацного текста, не сценариями.

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

149

Системный Анализ и Требования / Re: Макеты интерфейсов + ГОСТ

« : 17 Августа 2011, 14:12:06 »

В итоге, какой-то ясности по названной теме я так и не обнаружил. Формулирую вопросы следующим образом:
- В каком разделе ГОСТа допускается указывать требования к пользовательскому интерфейсу?
- Как этот раздел допускается назвать?
- Сами макеты GUI допускается ли оформлять в созданном разделе требований к GUI или логичнее их переместить в приложение, проставив ссылки из раздела требований к GUI?

150

Системный Анализ и Требования / Re: Логично ли так формировать ТЗ?

« : 17 Августа 2011, 13:59:07 »

Пока делаю такой предварительный вывод: допустим, разбиваем мы концептуально проектируемую систему (система может быть небольшой) на модули. Каждый модуль служит для выполнения какой-то отдельной функции. Соответственно, в ТЗ пишутся сценарии использования каждого из модулей, а также в дополнительных ФТ к данному модулю описываются атомарные функции вроде СЧОУ. Верно?