256

Для всех / Re: IDS Scheer - гуру БП или просто продавец?

« : 25 Февраля 2010, 13:39:12 »

Я уж перепугался, читая что "ИДС" создал "АРИС" ... читая подумал, что речь идет не об "АйДиЭс" (IDS), а о "EDS" (ИДиЭс), которая ныне куплена HP :-). Думаю, что лучше таки писать по-аглицки названия, чтобы не было путаницы...

257

ПО Аналитика / Re: помогите понять, что мне надо и где это взять

« : 20 Февраля 2010, 13:13:41 »

яж русским по белому написал: средство разработки(прога)для ПРОЭКТИРОВАНИЯ!

Ну, во-первых не по-русски вы написали, по-русски будет все-таки проЕктирование :-). А во-вторых ответить на ваш вопрос корректно, даже в уточненной постановке - невозможно. Т.к. тот же UML имеет множество возможностей для применения, и мне лично не понятно, как именно вы собираетесь использовать инструмент, и для каких целей ... проектирование-проектированию рознь. Так что если желаете получить внятный ответ, задавайте конкретный вопрос.
В вашем случае, имеет смысл развернуто пояснить аудитории форума о том что вы понимаете под проектированием, для каких целей вам нужно проектировать (почему вам необходима модель), ведь не секрет, что множество проектов обходятся и без проектирования на UML.

258

Поздравления / Re: Поздравляем Ирину Сурову с Днем Рождения

« : 20 Февраля 2010, 13:00:13 »

И я присоединяюсь к поздравлениям, с пожеланиями всего самого наилучшего!!!

259

Системный Анализ и Требования / Re: Чем отличается Функциональный дизайн от Технического задания?

« : 04 Февраля 2010, 19:14:16 »

Ну как же так, не будете использовать функциональный дизайн... Вот вы подписали с заказчиком ТЗ или ЧТЗ, в которых написано, ЧТО надо сделать. А теперь надо написать КАК вы собираетесь это делать - это будет Функциональный дизайн.
ТЗ и ФД не исключают один другого, они делаются в разное время, с разными целями, и читаются часто разными людьми.

ФД ответит на вопрос, КАК будет сделана система только с одной точки зрения - с т.зрения ее функциональности. Но ничего не скажет об устройстве системы с других точек зрения (архитектурных), например с т.з. той же безопасности. Т.е. описание все равно не будет полным. Тогда зачем, спрашивается огород городить? Кроме этого - следует отдавать себе отчет, что если вы внедряете OEBS, то логичнее работать по AIM, а не выхватывать что-то из ГОСТ, а что-то из AIM - стыковка разных методик/стандартов не такая уж тривиальная задача, если мы хотим, чтобы "гибрид" получился жизнеспособным. Если же речь не идет об OEBS, то зачем использовать методику, которая не факт, что однозначно подходит для конкретного случая?

Хотел добавить, если речь идет о достижении согласия с заказчиком о GUI или тех же отчетных формах - то можно попробовать обойтись "малой кровью" - прототипами, если конечно заказчик готов воспринимать такой формат.

260

Системный Анализ и Требования / Re: Чем отличается Функциональный дизайн от Технического задания?

« : 01 Февраля 2010, 16:21:00 »

Говоря об отличии терминов, то если речь идет о Oracle AIM и конкретно MD050 - Functional Design, то даже если рассматривать ТОЛЬКО различие моделей ЖЦ в AIM и по ГОСТ, станут понятны и различия соответствующих документов. Исходя из шифра - FD разрабатывается в процессе Module Design and Build, преимущественно на фазе Solution Design. Назначение его достаточно очевидно - представить в связке с соотетствующими бизнес-требованиями (BR030) детальное описание имплементации конкретного модуля, включая описание форм (суть GUI) и отчетов. Т.е. имеем классический пример описания внутреннего и внешнего устройства системы, т.е. - по сути дизайн системы но с  т.з. ее функциональности.

Рассматривая ТЗ по ГОСТ - стадия ТЗ в ГОСТ 34 и одноименный документ - суть фаза сбора и формулировки ТРЕБОВАНИЙ к системе или ее части. Дизайн системы как таковой по ГОСТ 34 разрабатывается на более поздних этапах, в частности на стадии Технического проекта (не берем в расчет в данном случае Эскизный проект или Рабочий проект).

Таким образом имеем следующее - сравнение этих двух документов не корректно, как минимум с точки зрения их назначения (ТЗ - это требования, FD - описание дизайна) и фазы ЖЦ на которых они создаются.  Другой вопрос, что в практике отечественных интеграторов, занимающихся внедрением того же OEBS можно увидеть причудливые смеси ГОСТа и Oracle AIM, который делается иногда в угоду бредовым требованиям заказчика, иногда по незнанию самих интеграторов, искренне считающих, что ТЗ - это описание дизайна системы :-).

261

Системный Анализ и Требования / Re: Чем отличается Функциональный дизайн от Технического задания?

« : 01 Февраля 2010, 00:49:29 »

ТЗ (например, по ГОСТ 34) может быть как на автоматизированную систему в целом, так и на ее отдельные части. ТЗ на отдельные части (при наличии ТЗ на систему) называются ЧТЗ - Частные Технические Задания.

262

Системный Анализ и Требования / Re: Сравнение различных подходов к формированию функ. требований к ИС

« : 30 Января 2010, 14:08:41 »

Почему в названии должны обязательно фигурировать требования? Вы ведь сравниваете две нотации/методологии используемых преимущественно для моделирования БП. Т.е. до требований в вашем контексте 2 шага - сначала БП, потом на их основе - требования. А для разработки требований - фиолетово, в какой нотации были описаны БП, по большому счету.

263

Системный Анализ и Требования / Re: Сравнение различных подходов к формированию функ. требований к ИС

« : 29 Января 2010, 00:34:01 »

Вышеперечисленные нотации более ассоциированы с описанием бизнес- и иных процессов, которые как известно никакого отношения к требованиям, тем более функциональным, не имеют (достаточно взглянуть на определение что есть ТРЕБОВАНИЕ). Следовательно, утверждение, что "САМИ МОДЕЛИ уже являются описанием требований" - в данном контексте не верно. Более корректно вашу работу следовало бы назвать сравнением подходов к описанию бизнес-процессов, или бизнес-, информационной и системной архитектуры предприятия (в терминах TOGAF, например).

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

264

Обучение / Re: Впечатление от on-line семинара от профессора Кумскова

« : 28 Января 2010, 00:54:49 »

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

265

Обсуждение статей / Re: Использование Method Composer при описании сложных и нестандартных процессов

« : 27 Января 2010, 22:22:39 »

Идея интересная, но нужен ли нам еще один фреймворк?

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

266

Обучение / Re: Впечатление от on-line семинара от профессора Кумскова

« : 27 Января 2010, 22:15:25 »

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

267

Обучение / Re: Впечатление от on-line семинара от профессора Кумскова

« : 27 Января 2010, 19:19:04 »

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

268

Обучение / Re: Впечатление от on-line семинара от профессора Кумскова

« : 27 Января 2010, 15:27:19 »

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

Денис, каждый имеет право на свою точку зрения. Эд высказал свою, причем на публичное событие (а не о личности человека). Теперь, что никто НЕ ИМЕЕТ ПРАВА ВЫСКАЗЫВАТЬ СВОЮ ТОЧКУ ЗРЕНИЯ? А Эд, лишний раз подтвердил, что семинар был сделан с четким расчетом на определенную аудиторию :-). Но, либо часть аудитории, которой Эд делал пояснения не подготовлена, либо одно из двух :-)

269

Обучение / Re: Впечатление от on-line семинара от профессора Кумскова

« : 27 Января 2010, 01:38:28 »

Эд, что касается слайдов на аглицком языке. Не знаю как обстоят дела сейчас, но в то время, когда Rational не была куплена IBM, периодически выплывали вопросы связанные с переводом того же RUP на др. языки. Официальной позицией Rational было неодобрение переводов. Насколько я понимаю, по причине неких правовых ограничений, нельзя переводить на национальные языки оригинальный курс Rational. Так что проф. Кумсков в данном контексте является образцом порядочности :-).

Что же касается его отношения к Коберну - то это давно известно. Но тут каждый имеет право на свою точку зрения. Но с другой стороны, тот же RUP относит юзкейсы к функциональным требованиям, в то время как Вигерс их называет пользовательскими требованиям, но входящими в большую группу функциональных требований. Вот такой хитрец этот Карл Вигерс :-).

Кстати, он писал о такой "нестыковке" где-то.... вот вспомнить бы где.

270

Идеи и мозговой штурм / Re: Что было бы интересно увидеть в новой книге по требованиям от Ivy Hooks.

« : 24 Января 2010, 15:03:00 »

Я не вижу ничего предосудительного  в высказывании собственной точки зрения, даже если не ознакомлен со всеми 60+ книгами. Всегда можно сказать, что БЫЛО БЫ интересно увидеть в новой книге, отталкиваясь хотя бы от знания 5-6 "основных" книг по тематике. А уж их большинство из нас читало.