1906

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

« : 02 Июля 2007, 23:55:50 »

Соглашусь с bas'ом - алгоритмы предметной области - это бизнес-правила. Только что вам даст такая классификация, я не очень понимаю ) В принципе это может вылиться в мини-эскпертную систему, если алгоритм нетривиален и вариативен.

Я в своё время что-то отдалённо напоминающее эту задачу делал на генетических алгоритмах.

1907

Идеи и мозговой штурм / Инженерный анализ структуры БД и диаграмма сетей вообще

« : 28 Июня 2007, 23:20:07 »

Давайте я сразу поделюсь своим алгоритмом анализа и разбора диаграммы БД при инженерном анализе.

Этот метод в принципе достаточно универсален и может быть использован для анализа сетей и графов вообще.

К сожалению, даже дорогие CASE-средства не умеют нормально строить диаграммы инженерного анализа без пересечений и повторений, поэтому родился такой алгоритм:

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

2) Нахожу "справочные" однозависимые таблицы и их цепочки, которые связаны только с конкретным "центром" - выстраиваю сателлиты вокруг "планет".

3) Образующиеся независимые или слабозависимые отдельные кластера таблиц откидываю в процессе подальше или вообще выношу в другие диаграммы/пакеты.

4) Далее принимаюсь за "посредников" - таблицы, которые связывают между собой "центры кристаллизации", при необходимости производя своппинг их друг с другом, напоминающий заплетание косичек, с целью избавления от пересечений и стараюсь размещать из равноудалённо от связуемых.

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

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

1908

Идеи и мозговой штурм / Re: Простые приемы анализа

« : 28 Июня 2007, 23:16:08 »

... разложить ее по полочкам.

Да, многие думают, что именно в этом состоит работа аналитика

Входит ли в предметную область uml2.ru и форума обсуждение общечеловеческих приемов анализа информации или все жестко заточено под анализ с последующим проектированием программного обеспечения?

Я всеми руками за, чтобы входила.

Если эта тема интересна и нужна здесь, могу попробовать описать свои приемы и с удовольствием поучусь у форумян.

Давайте, мы тоже попробуем свои методики выявить и описать.

1909

Системный Анализ и Требования / Re: Требования = Решения

« : 27 Июня 2007, 01:23:49 »

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

О, даже Юра вляпался ) Какая граница? Я говорю о том, что требования ОДНОВРЕМЕННО являются решениями и наоборот, если смотреть на процесс и систему вцелом, не замыкаясь в какой-то одной роли (БА, СА).

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

"Ты перестал пить коньяк по утрам?"

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

Смотря что мы обсуждаем. Я пытался обсуждать очистку совести (избавления от шизофрении) при засовывании макетов интерфейса в ТЗ

3. Кроме этого следует упомянуть еще и про то, что существуют т.н. ОГРАНИЧЕНИЯ ПРОЕКТИРОВАНИЯ ... которые по сути -- дизайн, а по форме -- требования (или наоборот :-)?)

Если ты про таблицу - то да, она давно просит обновления.

1910

Конференции Семинары и Тренинги / Re: Семинар по прецедентам - Подготовка

« : 27 Июня 2007, 00:04:35 »

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

1911

Системный Анализ и Требования / Re: Требования = Решения

« : 26 Июня 2007, 23:52:35 »

Все как-то смешалось - "требование - это решение", а "решение - это требование". С одной стороны, с этим нельзя не согласиться. Но, с другой стороны, какая от этого польза?

Вы знаете, я получаю удовольствие от проникновения в суть вещей, и отделения истинного от традиционного. За инсайтом не всегда следует немедленное понимание практической пользы.

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

Это не игра слов, это Роль, которую играет Утверждение о свойстве системы в отношении Участника процесса её создания. Про "применимость только к документу" обоснуйте.

1912

Системный Анализ и Требования / Re: Требования = Решения

« : 26 Июня 2007, 23:35:57 »

что в ТЗ будем включать все. Это как??

Где я это сказал?

1913

Системный Анализ и Требования / Re: Требования = Решения

« : 26 Июня 2007, 01:25:07 »

Ну ладно уговорили, только решение = набор требований.

Саша, когда Архитектор принимает решение, в частности, что такая-то задача будет решаться с применением шаблона Transaction Script, то это ровно 1 (одно) решение, и ровно 1 (одно) требование для программиста.

Только какой в этом практический смысл??

А смысл такой, что Требования не замыкаются только на аналитика, практически каждый участник команды их формулирует в рамках своей зоны ответственности и выполняет внешние для себя требования. Практический смысл такой, что под фразой "Требования к системе" на само деле скрывается громадный спектр возможных требований, в зависимости от того, какие именно категории включает в понятие говорящий. Чтобы преодолеть разночтения, я предлагаю распространить понятие требования на весь спектр решений, и при оперировании понятием требования всегда указывать, к какому уровню оно относится. Грубо говоря, в проекте "всё есть требование", только какие-то требования (цели и задачи проекта) формулируются и за их выполнение отвечает ПМ, за какие-то БА (модель предметной области, БПроц, БПрав, б-требования),  за какие-то - Инженер по качеству, за какие-то - программист. Причём различные категории требований имеют различные механизмы задания. Например, цвета, шрифты, относительные размеры блоков в интерфейсе вполне могут задаваться в графическом макете графдизайнером. Эти требования выполняет верстальщик.

Кроме того, это снимает внутреннюю психологическую напряжённость от необходимости включать в ТЗ то, что традиционно считается относящимся к области решений, а не требований.

1914

Системный Анализ и Требования / Re: Требования = Решения

« : 23 Июня 2007, 18:55:16 »

Решение на мой взгляд - это готовый продукт. А будут ли требования совпадать с решением еще не факт.

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

1915

Системный Анализ и Требования / Re: Требования = Решения

« : 23 Июня 2007, 18:52:04 »

bas, "Решение" как взаимоувязанный программно(-аппаратный) комплекс, предназначеный для автоматизации конкретного вида деятельности, БП или их набора - это одно из возможных пониманий термина, причём навязанное консалтерами и интеграторами. Понятия "управленческое решение", "проектное решение" и "техническое решение" - гораздо более зрелые термины.

Давай я скажу не Design Solutions, а Design Decision. Ведь тебе как аналитику приходится принимать решения? И архитектору и программисту приходится и бизнесу само собой.

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

1916

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

« : 23 Июня 2007, 00:54:40 »

Вот тут возникла идея статьи для Requirements Network.

Главный тезис такой - Requirements ARE Design Solutions.

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

Как же так, скажете вы, нас всю жизнь учили - "не путайте требования с решениями"?

А дело, на мой взгляд, вот в чём - объективно нет никаких Требований и Решений - есть только Утверждения. И эти Утверждения могут играть Роль Требования или Решения, в зависимости от его отношения к вам. Оно либо приходит к вам (Input, Requirement Statement) и вы его перерабатываете во что-то другое, либо исходит от вас, и тогда для вас оно Решение (Output, Design Statement).

Пример:

Рынок давит на Заказчика, вынуждает его повышать качество продукции и объёмы производства и снижать цены. Это Утверждения, которые порождает Рынок, в каком-то смысле его Решения.

Заказчик воспринимает эти Утверждения как Требования рынка, думает и говорит - хочу, чтобы система производства обрабатывала в 10 раз больше заявок, чем сейчас. Это его Бизнес-Решение.

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

Эти утверждения относительно системы передаются Архитектору, который воспринимает их как Общесистемные Требования. Прорабатывая их, он создаёт Решения относительно внутреннего устройства системы, а именно - технической архитектуры, набора подсистем и их интерфейсов - Внутрисистемные Решения.

Эти утверждения передаются как Требования к подсистеме Проектировщику подсистемы и т.д.

Далее см. мою таблицу типов требований (а на самом деле - категорий утверждений о свойствах системы).

Что думаете, дерзко? )

1917

Конференции Семинары и Тренинги / Re: Семинар по прецедентам - Подготовка

« : 23 Июня 2007, 00:13:12 »

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

Название семинара:
Концепция системы и варианты использования (use-cases)

Сергей

• Целеполагание как разработка модели целей, проблем и решений
• Увязывание модели целей с моделями процессов и сущностей
• Образец модели концептуального документа

Денис

• Диаграммы UC для согласования интересов
• Отношения include и extend на практике

Александр, Эдуард

• Особенности UC, типовые ошибки и проблемы
• Обучение применению UC
• Границы применимости UC - когда нужны бизнес-UC
• Трансформация моделей UC в ходе проекта по RUP: бизнес-UC, системные UC и модель классов

Евгений

• UC уровня реализации как наиболее точные спецификации

Если по 10 минут на сообщение, то уже 1ч40мин получается, и это без обсуждений. А я думаю, что у нас реально времени будет - часа 2. Пока не поздно - предлагаю выкинуть лишнее

Предлагаю даты семинара: 5 июля либо 12 июля.
Если 12-го, то возможно приедет Эд.

1918

Конференции Семинары и Тренинги / Re: Семинар по прецедентам - Подготовка

« : 22 Июня 2007, 18:30:37 »

Такими темпами, чувствую, действительно пиво с проблемами пьём )

1919

Обучение / Re: Курс "Анализ требований к автоматизированным информационным системам"

« : 22 Июня 2007, 16:14:39 »

Судя по тому, что я успел посмотреть (мельком по всему + 3 первые лекции) - курс вводно-обзорный.

Автор просто собрал по сусекам ту инфу, что есть в книгах Лефингвелла, Вигерса, Коберна, SWEBOK, Лармана, Мацяшека, причём без попытки как-то это осмыслить. Не смог представить постигаемую наглядную карту типов требований, не описал границы применимости работы с требованиям, не понятно почему ограничился ИС, не представил диаграмм процесса разработки и управления требованиями, не описал роль аналитика требований. Про нефункциональные требования - 2 абзаца, что недопустимо. Целиком прошляпил BABOK, Requirements Engineering и SysML.

Раздел "Методических указаний" довольно полезен (Эд, посмотри обязательно!).

1920

IDEF ARIS BPMN и пр. / Re: IDEF0 - описание правил оформления документов

« : 22 Июня 2007, 00:28:12 »

...
И потом, опять же, рассеивать информацию по 10 разным видам диаграмм или попытаться собрать ее  в 4-х или 5-ти видах - есть разница, правда?
Словом, все, что выше 3-ки в IDEF - довольно тяжеловесно.

Поэтому Буч, Рембо и Якобсон не зря потратили свое время. Кстати, одним из самых выдающихся ходов в UML я считаю разделение диаграмм на статические и динамические. На динамических в концентрированном виде преподносится все то, что мы хотели бы узнать о поведении модели.

В IDEF же, мне кажется, несколько наивный подход: есть такая вещь как классы - рисуем классы. Есть такая вещь как методы - рисуем методы. А есть аргументы - рисуем и их. На разных диаграммах, причем. Это как раз то, что в первую очередь может прийти в голову человеку с аналитическим складом ума.
А вот у создателей UML, как мне кажется, все-таки преобладает синтетическое мышление.

Ну не сказал бы, наибольшей интегрированностью и полнотой диаграмм всё-таки обладают ARIS eEPC и IDEF0. У первого на одной диаграмме отображаются действия, ресурсы, исполнители, документы, механизмы, у второго почти то же самое, только менее наглядно. А вот в UML на каждом типе диаграмм отображаются только 2-3 категории моделирования, причём наверное действительно классы их них самая богатая.

Мне кажется более вероятными следующие причины такой разницы в подходах между функциональными нотациями методологиями 60-70х и объектными 80-90-х - во времена первых в мире ИС доминировали ТРАНСФОРМАЦИОННЫЕ системы, которые сильно напоминали обычное производство, а в последние десятилетия доминируют РЕАКТИВНЫЕ системы, в которых на первое место вышли взаимодействия и которые потребовали для себя новых инструментов.

Вот что об этом пишет R.J. Wieringa в книге "Design Methods for Reactive Systems: Yourdon, Statemate, and the UML", точнее, он делает акцент на необходимости моделирования того, что он называет "окружением" (environment):

"A reactive system is a system that, when switched on, is able to create desired effects in its environment by enabling, enforcing, or preventing events in the environment. For example, real-time, embedded, and control systems are reactive systems because, when they are switched on, they enforce a certain desirable behavior on their environment. Information systems, groupware systems, workflow management systems, ERP systems, e-commerce systems, and EDI systems are reactive too because they provide desired information and enable communication and collaboration between people or organizations in their environment. Other examples of reactive systems are word processors and operating systems.

...

Reactive systems can be contrasted with transformational systems, which exist to transform an input into an output. Compilers, assemblers, and routines in a library of mathematical functions are transformational systems. The execution of a database query can also be viewed as a transformational system; the query execution maps a query and a database state into a set of data. The entire database server, however, is reactive because it exists to allow its environment to ask queries. A diagnostic expert system is a transformational system; it may enter an interactive dialog to acquire all relevant data about a malfunctioning machine, but when all data are provided, the expert system will produce its diagnosis as output, after which it is finished.

...

Methods for the design of transformational systems must specify the transformation to be computed by the system, the logical structure of the input and output data, and the algorithm that computes the transformation. The behavior and structure of the environment is not particularly important for these systems. They will perform the same transformation in different environments. A widely used design approach for transformational systems is, therefore, functional decomposition, a method by which external functionality is mapped to internal components of the system.

By contrast, reactive systems are in close interaction with their environment. Design methods for reactive systems must contain techniques to describe the environment and the structure of the interaction with the environment. Functional decomposition is not the only nor the most important design approach for reactive systems; the structure of the environment is at least as important."