1846

Задачи студентов / Re: Проверте пожалуйста диаграммы

« : 07 Мая 2011, 19:53:39 »

А стоит ли Вам что-то объяснять. Ну нарисовали, кто-то будет проверять? Раз не учили, зачем пользоваться тем что не знаете?

1847

Для всех / Re: Пример описания предметной области с использованием UML

« : 06 Мая 2011, 14:16:15 »

Возник вопрос: "Корректно ли такое сравнение, указанное в статье, что бизнес-требования - это виды деятельности, которые необходимо автоматизировать?"

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

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

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

1848

Для всех / Re: Пример описания предметной области с использованием UML

« : 06 Мая 2011, 13:29:53 »

Спасибо за отзыв!
Эдуард, Мне тоже показалось, что некоторые диаграммы приведены с ошибками.

Вот почитайте, если интересно: Смерть от UML иUML лихорадка – диагностика и лечение

1849

Для всех / Re: Пример описания предметной области с использованием UML

« : 06 Мая 2011, 12:34:43 »

Согласен с Максимом, хотя сама статья мне не очень нравится, я бы ее не рекомендовал для изучения и использования.

Что касается диаграммы на рисунке 10, то она просто элементарно ошибочна, поскольку копии актов - это два совершенно различных объекта, и один и тот же объект не может находится в двух состояниях.

Рисунок 9 тоже довольно странный, т.е. он далек от прагматики использования этой диаграммы

1850

Конференции Семинары и Тренинги / Re: ЛАФ 2011 тема конференции

« : 05 Мая 2011, 18:08:42 »

Если выбирать среди этих тем, то я за use case, т.к. хочу более детально понять, как и в каких ситуациях их разумнее всего применять на практике.

Павел - вот аналогично, вообще хотелось бы получить обменяться этим с другими. Кстати и имя сайта оправдываем

1851

Конференции Семинары и Тренинги / Re: ЛАФ 2011 тема конференции

« : 05 Мая 2011, 16:24:08 »

Так для размышления.
Фестиваль (фр. festival, от лат. festivus — праздничный) — массовое празднество, показ (смотр) достижений музыкального, театрального, эстрадного, циркового или киноискусства

Аналитическая работа сродне искусству, тут проблем нет. Однако хочу обратить внимание на "показ (смотр) достижений". Как вам такое направление?

1852

Конференции Семинары и Тренинги / Re: III Международная научно-практическая конференция "ОБЪЕКТНЫЕ СИСТЕМЫ - 2011"

« : 05 Мая 2011, 13:59:09 »

Поздравляю тех, кто принял участие в работе конференции и чьи доклады были приняты к публикации!
Кстати, хотел бы узнать - даст ли что-нибудь именной сертификат? Где его можно будет использовать?

Повесить на стенку и любоваца Реально, подождем еще пару стройку лет, глядишь конференция станет очень престижной

1853

Обсуждение статей / Re: О статьях

« : 05 Мая 2011, 07:50:49 »

Максим, спасибо за ответ. Вам не в чем извиняться:) Я ведь сам в начале темы обозначил три варианта.
Вариант "сами писатели полные идиоты" - не проходит, Вы убедительно показали, что ребята знали, что делали
Вариант "всех за идиотов держат" или "ты идиот" - ну по сути очень близкие.
Потому такая ассоциация

Интересно, как один и тот же текст создает разные его трактовки. По-моему уже само это обсуждение указывает, что авторы глубоко видимо ошибаются.

Вот Вы говорите, что они против Agile! А мне показалось, что они как раз за Agile и более того там вверху ссылка, печтается с разрешения "блабла"

Но впрочем, это мы уже переходим в другое русло обсуждения

1854

Обсуждение статей / Re: О статьях

« : 03 Мая 2011, 22:37:12 »

Спасибо, Максим, за разъяснение. Из Ваших слов я так понял, что я сам дурак со своим "прямолинейным" знанием английского языка.

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

Далее не будем углубляться слишком далеко, возьмем размифистацию первого мифа.
"where we have measured the density of unintelligible words at 30% to 90% and more"
and more - это сколько?

"It should be possible to reduce defective written requirements defects by two orders of magnitude, as our clients have done"
Во - первых, что тут планируется уменьшить? или дефекты дефективно написанных требований, либо что?
Во - вторых, откуда взялись два порядка величины - это все-таки не в пределах от 30 до 100%, как говорится чуть выше - это все-таки разы, а не порядки.

Вывод о том, что грамотно, точно и однозначно понимаемая спецификация не нуждается в последующем устном объяснении, понятен и мною одобряем, но

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

Правда, поймал себя на мысли может авторы статьи хотят докричатся до коллег, мол не только USs жив agilист, но должен тянуться к спецификациям?

1855

Вакансии / Re: Требуется консультант (аналитик + тестер) или чистый аналитик

« : 03 Мая 2011, 19:20:04 »

Можно в любое время, если нет встречь с членами проектной команды (как со стороны заказчика, так и со стороны исполнителя).

так на всякий случай: встреч - множественное число родительный падеж от слова встреча

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

Как то раз я составил для заказчика наглядную BPMN модель его процессов, связанных с назначением надбавок сотруднику. Ооо, заказчик с интересом их изучил, даже внес коррективы. Когда же по этим процессам было реализовано решение, то заказчик сильно не доумевал, почему ему сделали именно так. Обучение, правда, рулит. (с паяльником)

1856

Для всех / Re: Касательно ГОСТ 34.601-90

« : 03 Мая 2011, 18:14:24 »

Я бы вообще смоделировал поток работ с помощью IDEF0 - строго всё и формально: вход, выход, управление, механизм. Нечто подобное я делал в дипломном проекте.

Для потока работ имеется другая нотация IDEF3. IDEF0 все-таки показывает иерархию функций (активностей) + горизонтальные связи на каждом иерархическом уровне

1857

Вакансии / Re: Требуется аналитик для формирования требований к Web приложению

« : 01 Мая 2011, 22:14:40 »

Где все аналитики? АУ!!!

Вне Москвы

1858

Обсуждение статей / О статьях

« : 29 Апреля 2011, 23:23:18 »

Подписан на рассылку с сайта requirementsnetwork.

Довольно часто приходят извещения на выход той или иной статьи.
От прочтения некоторых из них, например вот такой User Stories: A Skeptical View, остается какой-то странный осадок. То ли ты идиот, раз не понимаешь, что писатели пишут, то ли писатели всех за идиотов держат, то ли сами писатели полные идиоты.

Я понимаю писать на чужом языке не так-то просто, но уж если пишите... Или у западников такой менталитет? Ну полная чушь на мой взгляд. Может я ошибаюсь?

1859

Обсуждение статей / Re: Рецепт работы с требованиями

« : 29 Апреля 2011, 23:09:45 »

А к чему, уважаемый Николай привел цитату из книги? К тому, что он показывает нам, что все уже известно? что то, что используется далеко от идеальности? или вообще далеко? или нет ничего нового, что грустно?

1860

UML SysML и пр. / Re: В чем различия business actor и actor?

« : 29 Апреля 2011, 16:00:57 »

Как раз это и читаю, но там нет прямого ответа!

Хм, а что вы считаете прямым ответом?

Смотрите. Пусть имеется система - Металлургический комбинат
все actors - будут в этом смысле бизнес-актерами:

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

Теперь берем АСУ "Металлургический комбинат"
Вот все акторы - просто актеры - пользователи системы или взаимодействующие системы - инициаторы вариантов использования системного уровня

Фирштейн Зи?