46

Примеры / Re: Удивительный контрпример неприменимости как ООП так и Relation Database.

« : 28 Ноября 2009, 23:48:01 »

КОНТРПРИМЕР База данных украденных вещей (всех подряд, разделенных может только на категории не больше). ?? хочу найти СВОЮ шапку (Дополнительные ограничения: 1) визуальных материало в в базе нет 2.Никто не знает УНИКАЛЬНЫЕ  параметры моей шапки, и не кому они не интересны, хотя структуру  объекта можно сделать сколь угодно сложной /проектировщик может/  Так как мне найти мою шапку?  Проблема в том что здесь граница применения как ООП так и RDBMS, так вот. 

Не вижу связи. Как минимум - время попадания обьекта в базу - известно. Место - тоже известно. Обьект в базе  МВД будет содержать целый ряд признаков, предназначеных для оказания помощи при поиске предмета.

47

Примеры / Re: Удивительный контрпример неприменимости как ООП так и Relation Database.

« : 28 Ноября 2009, 22:51:30 »

ivanoval. Можно чуть понятнее? В Вашем сообщении много эмоций, но мало информации. Вы можете точнее сформулировать как задачу, так и ограничения?

48

Термины и Определения / Re: [Термин] FEATURE

« : 27 Ноября 2009, 14:25:27 »

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

Т.е. требование - что нужно, а фича - что уже есть?

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

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

49

Термины и Определения / Re: [Термин] FEATURE

« : 27 Ноября 2009, 12:43:02 »

Если под терминами "feature" и "требование" понимать что-то другое - заранее нельзя однозначно сказать, является ли feature требованием.

По-моему, сейчас, определение того что есть требование что есть фича - вопрос скорее религии, чем стандарта:)

50

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

« : 26 Ноября 2009, 23:44:18 »

Поиски "идеальной" системы продолжаются.

Активно рассматриваются RequisitePro, DOORS и некоторые другие. Инструменты хороши, но цена...
Но вот по матрице похоже есть прокол.
1. Отсутствие фильтрации в матрице
2. Отсутствие сигнализации по изменению в матрице (как это сделано например в RequisitePro)
3. Нельзя кроме визуально инспекции понять быстро и наглядно, а что не покрыто, где требования не привязаны или не реализованы ничем (это в случае большого количества требований). Вероятно что-то типа этого
4. Примитивная история изменений
5. Не отслеживание истории изменений в документах (хотя наверное SVN может взять это на себя, хотя не покажет что и где именно изменилось)
6. Управление изменениями можно сказать нет
Можете поделиться опытом использования? Можно ли сделать ставку на этот продукт?

Я бы не делал на него ставку как на инструмент работы с требованиями. EA хорошь возможностью легко построить многоуровневую связанную модель.
Мы вели требования в ReqPro (с историей и архивацией), а в EA - переносили их и строили от них модель "вниз" (и тут он был почти идеален).
Разумеется - синхронизация была вручную.... 

51

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

« : 25 Ноября 2009, 00:05:23 »

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

Согласен с Ирой. Но, я (возможно, заблуждаясь) - ожидаю от бейзлайна полной фиксации состояния и удобного сравнения с другим состоянием.
ИМХО - в EA - реализация скорее для галочки - У вас есть? - есть!.

52

Идеи и мозговой штурм / Re: Методы оценки эффективности Аналитика

« : 24 Ноября 2009, 12:46:41 »

Вывод получается что оценивать все таки надо не аналитиков, а целиком команду или решение/продукт полученный этой командой
Согласны?

Да. Так оно и есть.

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

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

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

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

53

Примеры / Re: Uml-модель экономической системы общества.

« : 24 Ноября 2009, 09:56:16 »

Я не очень понял данный тезис, и названных авторов не читал, но подозреваю, что это перекликается с теориями Сороса? (его я немножко просматривал) Вы мне льстите А чем так уж плох результат их построений?
Лично я полагаю, что причина кризиса гораздо глубже, чем просто экономические коллизии, пусть даже с учетом всех трансакционных издержек.

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

Желательно прочитать и что-то экономическое - что бы представлять то, что Вы критикуете и базу чего Вы пытетесь смоделировать.

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

54

Примеры / Re: Uml-модель экономической системы общества.

« : 24 Ноября 2009, 00:53:57 »

Мне кажется нет оснований отождествлять человека и сколько-нибудь значительное множество людей. Это две совершенно различные сущности, с совершенно разными свойствами. Множество людей не есть субъект, обладающий самосознанием и волей. Иногда это множество ведет себя в лучшем случае, как безмозглый организм, чаще – как стихия, - то есть как объект, а не субъект. Поэтому в экономической модели большого общественного образования совершенно нет необходимости "моделировать человека", разве что человеческие массы – но тут они могут и должны рассматриваться в качестве обычных учетных сущностей, - таких как персонал, подотчетные лица, учредители - в бухгалтерии. Да, у этих "ролей" существенно различные свойства, однако человеческая подоплека здесь нас совершенно не интересует. Финансово-экономическая достоверность модели предприятия от этого совершенно не страдает.

Вы очень серьезно заблуждаетесь, вычеркивая из экономической модели человеческую подоплеку. 90% трансакционных издержек в экономике приходятся именно на нее.
Почитайте Коулза "теория фирмы" и кого-нибудь из неоинституционалистов (например - Уильямсона).
То, о чем Вы пишите - повторяет классическую ошибку старой школы экономистов, которые исходят примерно из таких же принципов при построении своих теорий (результат этих построений, надеюсь, Вам известен).

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

55

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

« : 23 Ноября 2009, 20:16:59 »

Андрей, а в чем конкретно проявляются проблемы? Вы можете их описать? Хотя бы кратко, я бы тогда подергал саппорт

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

Если недай Бог, используется ссылки на внешние документы (а  у нас на паре проектов такое было) - то эти документы не попадают под версионный контроль EA. А именно для требований это серьезно (хотя и не только там - у нас цеплялись иногда XML-схемы обьектов, и некоторые эскизы GUI, в итоге - мы сами загоняли весь каталог, включая модель под CC - дешего и сердито).


 

56

Примеры / Re: Uml-модель экономической системы общества.

« : 23 Ноября 2009, 18:17:24 »

Перечитал еще раз то, что написано у Владимира в блоге, и пришел к выводу: много эмоций, мало теории. Слишком популярно и эмоционально.
Интересно, существуют ли сколь-нибудь зрелые модели (имитационные я имею в виду) по современным экономическим системам? Как-то ведь народ-капиталисты (или государство, государства) моделируют развития экономической системы

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

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

57

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

« : 23 Ноября 2009, 15:56:26 »

В чем они проявляются, можно примеры?
Т.е.? Что конкретно не устроило? Можете описать подробнее? Я бы саппорт подергал за ниточки
Может быть. Но майнмеп отражает тип или ход мыслей того, кто моделирует и строит ее. Неокажется ли это проблематичным при построении модели требований в коллективе?

По поводу связей - я сейчас не помню точно - надо поднять проект - обязательно отвечу в течении пары дней (это было год назад и я тогда пользовался версией 7.1).

Что касается истории изменений требований - то для них, КМК, есть небоходимость вести и фиксировать историю изменений вместе с описанием их причины - что бы потом можно было легко проследить ход работы над требованием (что хорошо сделано в ReqPro).

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

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

Именно. Пользоваться этим невозможно (по крайней мере в 7.1).

58

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

« : 23 Ноября 2009, 00:15:28 »

Использовал EA. В целом - положительные впечатления.
Субьективные минусы:
1. Есть некоторые ограничения по трассеровке в другие виды обьектов.
2. Нет встроенного механизма ведения истории изменения требований и примечаний (что огорчало сильно)

P.S. Вообще, мне иногда кажется, что mindmap для требований, по крайней мере на начальном этапе - даже где-то удобнее (не пинать ногами:) )