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

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - bas

4246
Для всех / Re: Цена методологии
« : 05 Марта 2007, 19:22:25 »
Для меня это вообще странно. В самом примитивном представлении RUP - всего лишь набор правил и пожеланий. Если директор компании купил книжку и выучил RUP, а на следующий день приходит и говорит своим сотрудникам: мы будем делать так то и так то, потому что советует дядя Буч.
Для меня тоже страно, м.б. это еще один мыльный пузырь, который продется.
Хотя с другой стороны все твои сотрудники должны ознакомиться с рекомендациями РУП, а они как раз продаются в виде сайта, а так же потом Вы должны использовать шаблоны, которые тоже платные, т.к. содержаться в поставке РУП. А вообще надо license agreement почитать, там обычно четко "что да по чем" сказано.

4247
Саша, нужно смотреть конкретно что за проект и что за юзкейсы, чтобы можно было действительно рекмендовать добавить дополнительную секцию.
Это понятно, что если надо, то добавляем, если нет, то не добавляем. В принципе, у меня все функц. требования укладываются в ВИ и БПравила. Просто взял твою рекомендацию на заметку.

Вполне разумный подход -- не описанные требования (функц. и нефункц.)  описывать в другом артефакте (как это в RUP сделано) и трассировать на UC, в случае связки.
Это да, но не прижилось у нас как-то использование RMS (requirements management system), т.к. бОльшая часть людей пишут спеки как попало ...

4248
Для всех / Re: Цена методологии
« : 05 Марта 2007, 19:04:42 »
UML, как и все стандарты, разработанные OMG, вроде бесплатны, т.е. ты можешь их использовать в своих коммерческих продуктах бесплатно.
Другое дело RUP - он платный, но есть бесплатная альтернатива ему - OUP
Третье дело, Вы решили делать свой стандарт на основе UML - это  уже надо читать законы, на сколько ваш стандарт должен отличаться от UML.

З.Ы. И все же UML - это стандарт, а не методология

4249
Оки, в ближайшее время добавлю ...

4250
Денис, согласен, описал как-то скомкано, но было поздно, а хотелось дать пищу для размышления.

И так, требования именно к ПО мы описываем в виде единого документа (шаблон взят из SRS) :
1. Функциональные требования - в виде ВИ, т.е. пользовательских требований. На первом этапе только сами ВИ и их краткое описание, далее заполняем всю спецификацию
2. Не функциональные требования и ограничения описываем в виде одного-двух предложений
3. Дополняем диаграммой ВИ, которая называется "функциональная модель Системы"
4. Дополняем диаграммой бизнес сущностей - "Структурная модель Системы"
5. Каждый ВИ может быть дополнителнен макетом формы
6. БПравила описываем либо отдельно в каждом ВИ, либо (и) в отдельной секции.
7. После рекомендации Юрия, добавлю еще секцию - "Доп. функц. требования"

4251
В общем хотелось услышать кто как описывает требования к ПО и с какой детализацией?

Мы описывает требования к ПО в виде сценариев ВИ, добавляем к ним бизнес правила и нефункциональные требования.
Плюсы такого подхода:
1. Учитываются все требования
2. Наиболее понятны и детализированы для программиста
3. Наиболее понятны для заказчика, можно дать почитать

Хотелось услышать другие мнения и минусы моего подхода, если они есть.

4252
FAQ – Use Case

Теперь ФАК ведется здесь: http://www.uml2.ru/index.php?option=com_content&task=category&sectionid=3&id=31&Itemid=51

Что такое Вариант Использования (прецедент или Use Case)?
Что такое актер (actor)?
Что такое Диаграмма Вариантом Использования (ДВИ)?
Чем отличается диаграммы Бизнес ВИ и Системных ВИ?
Что необходимо сделать, чтобы правильно построить ДВИ?
Что такое сценарий ВИ?
Почему ВИ – это не функция?

Какие вопросы будут включены в этот FAQ в ближайшее время?


Что такое Вариант Использования (прецедент или Use Case)?
Вариант Использования (ВИ, прецедент или Use Case) - это последовательность некоторых событий, показывающих как Система должна взаимодействовать с Пользователями (называющимися актером или actor) для достижения какой-то цели. Различают два вида ВИ – это бизнес ВИ (БВИ) и системный ВИ (СВИ).

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

Что такое Диаграмма Вариантом Использования (ДВИ)?
ДВИ (диаграмма прецедентов или use case diagram) – это диаграмма, на которой показаны несколько ВИ, актеров и связей между ними.

Чем отличается диаграммы Бизнес ВИ и Системных ВИ?
На Бизнес Диаграмме ВИ (БДВИ) отображается, как взаимодействуют внешние пользователи с вашей организацией для достижения бизнес целей. На ней обычно показывают внешних по отношению к вашей организации актеров, например, клиентов и  внешние организации. Старайтесь на этом этапе избегать связей <include> и <extend>. Данная диаграмма используется на этапе Бизнес Моделирования. Очень важно на этом этапе показать диаграмму Бизнес Объектов, которая отображает основные бизнес-сущности (и их свойства) и взаимосвязи между ними.
На Системной Диаграмме ВИ (СВИ) отображается, как взаимодействуют ваши внутренние Пользователи с вашей автоматизированной Системой, т.е. отображаются пользовательские функциональные требования к ПО. Данная диаграмма используется на этапе Системного Анализа и формализации требований к ПО.

Что необходимо сделать, чтобы правильно построить ДВИ?
Необходимо пройти несколько основных шагов:
1.   Выделить действующих лиц (ДЛ). Если это СДВИ, то нужно выделить внутренних Пользователей Системы и внешнее (другое) ПО. Если это БДВИ, то нужно понять – кто может являться Клиентом вашей организации, и с какими другими организациями взаимодействует ваша компания, например, налоговая или РАО ЕЭС.
2.   Для каждого выделенного ДЛ написать свои цели, которые он пытается достичь, используя ваше ПО (СДВИ) или вашу организацию (БДВИ). Ранжировать эти цели для каждого ДЛ и попытаться выделить основные цели, если другие цели являются подцелями или задачами. Понять какие другие ДЛ могут участвовать при достижении этой цели. Попробовать объединить цели нескольких ДЛ, если они несут некую одну пользу.
3.   Нанести на диаграмму ДЛ, которые будут являться актерами, и основные цели, которые будут являться ВИ. Причем основным словом в названии ВИ должно являться глагол, например, «Принять товар». Нанести на диаграмму связи (в виде однонаправленных ассоциаций) между ДЛ и целями, в соответствии с п. 2. Если другое ДЛ участвует в достижении цели основного ДЛ, то этот ВИ надо также связать с первым ДЛ.
4.   Для каждого ВИ необходимо написать сценарий – последовательность действий внутри этого ВИ. БВИ лучше описывать в виде прозрачного ящика, а СВИ лучше описывать в виде черного ящика.

Что такое сценарий ВИ?
Сценарий или спецификация ВИ (use case scenario or specification) – тестовое формальное описание последовательности действий, которые происходят внутри ВИ для достижения некой цели актера. Принята следующая структура описания спецификации ВИ:
1.   Название
Это уникальное название ВИ. Оно должно быть написано в виде глагол-существительное, например «Получить книги», «Снять наличные».Лучше написать «Регистрировать пользователя», чем «Регистрация пользователя».  Оно должно описывать конечную цель актера и чтобы было понятно – о чем данный ВИ. Оптимально название из 2 или 3 слов.
2.   Итерация
Часто эта секция нужна, чтобы информировать читателя – какой стадии достиг ВИ. Начальный ВИ, разработанный для бизнес анализа, может сильно отличаться от хорошо разработанной версии, когда началась разработка ПО. Более старшая версия ВИ м.б. все еще текущим документом, потому что предназначается для другой группы людей. Может быть пропущено.
3.   Описание
Обеспечивает краткое описание ВИ, чтобы понять суть ВИ и не углубляться в полное описание. Часто используется на первых стадиях, когда полный процесс еще не ясен, но хочется описать основные моменты. Может быть пропущено.
4.   Предусловия
Данная секция используется для описания любых условий, которые необходимо соблюсти, когда пользователь начинает выполнение данного ВИ. Данные условия могут непосредственно не инициировать данный ВИ.
5.   Триггер
Описывает начальное условие, при котором начинается данный ВИ. Это может быть внешним, временным или внутренним условием.
6.   Основной поток действий
Каждый ВИ должен иметь по крайней мере одну секцию, описывающую основной поток действий. Обычно представлен как нумерованный список шагов:
a.   Система показывает форму вводу имени пользователя и пароля
b.   Пользователь вводит свое имя и пароль
c.   Система проверят введенные данные и подтверждает их правильность
d.   Пользователь считается авторизованным
e.   И т.д.
7.   Альтернативные потоки действий
ВИ может иметь разветвления потока событий или иметь другие (альтернативные) сценарии. Все вариации описываются в данной секции. Обычно также представлен как нумерованный список шагов:
a.   Система распознала cookies на компьютере пользователя
b.   Перейти к п. с
Или:
c.   Система проверят введенные данные, и они являются не верными
d.   Перейти к п. а
8.   Постусловия
Здесь указываются состояние, которые происходят после того как основной сценарий исполнился.
9.   Бизнес правила
Это правила, которые определяют как организация взаимодействует внутри в соответствии с ВИ. Бизнес правила могут быть как внутри ВИ, так и затрагивать несколько ВИ, чтобы описать взаимодействия, которые выходят за рамки описания ВИ. Нужно чтобы получить более полную картину взаимодействия. Может быть пропущено.
10.   Замечания
Другая информация, которая не может быть описана в рамках шаблона. Может быть пропущено.
11.   Автор и дата
Должна быть показана версия документа,  его автор и дата последнего обновления.

Почему ВИ – это не функция?
ВИ – это не функция, это некая последовательность действий, которая приносит пользу для основного актера, инициирующего данный ВИ. ВИ – это скорее цель Пользователя, чем отдельная функция. ВИ теоретически может быть разбит на несколько функций, и как правило не является одной лишь функцией. Например, «Выдать деньги» в банкомате не является ВИ, а «Снять деньги» - это ВИ, который включает в себя некую последовательность действий по выдаче денег. Декомпозировать ВИ до функции является очень большой ошибкой.
Подробнее можно прочитать здесь: http://www.uml2.ru/index.php?option=com_smf&Itemid=45&action=dlattach;topic=47.0;attach=23

Какие вопросы будут включены в этот FAQ в ближайшее время?
В данный FAQ будут включены следующие вопросы:
•   Какую литературу можно почитать, чтобы лучше понимать ВИ?
•   Что такое уровень прозрачности ВИ?
•   Какие бывают уровни декомпозиции ВИ?

4253
зарегестрировался, скорее всего буду на 5ой секции

4254
Денис, просто Keen_G, хотел прежде чем покупать, полистать эту книгу и посмотреть - стоит ли ее вообще брать.

4255
Вопрос из разряда: 2ухзвенка vs 3ехзвенки, СУБД Oracle vs MS SQL

Скажу, свое скромное ИМХО, т.к. не являюсь спецом в ERP.
Я проголосовал за Oracle по двум причинам:
1. Oracle очень сильно двигает свои продукты, примером тому их СУБД, кто мог сказать 10-15 лет тому назад, что их СУБД займет львиную долю рынка. Плюс их заявления по продвижению направления ERP & CRM
2. Люблю я его :)

4256
Итог будет подведен?

4257
Я вот не до конца понял, а чем плох подход сделать ДК и схему БД и на их основе сгенрить мапинг? Что Вы улучшаете по сравнению с этим подходом?

4258
Немного поправил описание

4259
Примеры / Re: Модуль учета, первые шаги.
« : 28 Февраля 2007, 15:10:30 »
Ну в принципе уже все сказали, добавлю и свои 5 коп.:
1. Надо определиться что мы описываем?! СВИ или БВИ. Я так понимаю что СВИ, т.е. ВИ Системы. Как уже сказал Эдуард, нужно выделить актеров только тех, кто использует Систему непосредстенно.
2. По Коберну, первый этап - это выделить актерев и их цели. Думаю, следующим постом Денис, ты, это и сделаешь. Тем более, что Эдуард уже львиную долю за тебя сделал.
3. Не надо на ДВИ указывать Систему - это не правильно, т.к. все ВИ реализуются этой самой Системой и тогда придется ко всем приделывать атера-Систему.

4260
Консалтинг и Внедрение / Re: ERP обзор
« : 26 Февраля 2007, 15:45:17 »
Наверное я не совсем точно выразился. Имел ввиду, что если кто-то чем-то пользовался/внедрял, то свой субъективный взгляд - что хорошего, а что плохого. Ну или в крайнем случае анал. обзоры. Т.к. все, что выложено выше, не более чем рекламные слоганы.