2866

Sparx / Re: Как задать стартовую модель

« : 30 Ноября 2009, 13:32:22 »

Голосование мне не нужно было, но форум почему-то требовал от меня заполнение этих полей.

Так надо было создать тему а не новое голосование:)

2867

Системный Анализ и Требования / Re: Выбор СУТ для отраслевого проекта с большим числом клиентов

« : 30 Ноября 2009, 11:03:23 »

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

Андрей, идею я понимаю, я спрашиваю о технической стороне вопроса.

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

Есть все этом в freemind и bugzilla?

2868

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

« : 30 Ноября 2009, 11:00:08 »

Юрий, в чем принципиальное отличие фичи от требования?

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

Т.е. требование - пользователь должен иметь возможность оправить письмо разными способами. Фича - конкретный способ отправки реализованный в НАШЕЙ системе и выгодно отличающие ее от других систем например...

2869

Системный Анализ и Требования / Re: Выбор СУТ для отраслевого проекта с большим числом клиентов

« : 30 Ноября 2009, 09:47:22 »

На самом деле, мне весьма понравилась идея того гибрида - freemind+bugzilla (если я правильно запомнил), о котором рассказал Станислав Фомин на Req Labs - мысль здравая и интересная

Андрей, а в чем выражается идея? freemind - это карты памяти как я понимаю, которые могут каким-то образом интегрироваться с bugzilla. А bugzilla - багтрекер ... что это дает вместе?

2870

Системный Анализ и Требования / Re: Выбор СУТ для отраслевого проекта с большим числом клиентов

« : 29 Ноября 2009, 22:13:00 »

Андрей, спасибо за Ваше мнение.

Наш ПМ склоняется к использованию ЕА. А надстройку типа RaQuest предполагает разработать собственными силами. Если это произойдет, я дам знать.

2871

Системный Анализ и Требования / Re: Выбор СУТ для отраслевого проекта с большим числом клиентов

« : 29 Ноября 2009, 20:10:41 »

Тогда - зачем там возможность генерить код?

Я не говорю, что ЕА исключительно СУТ. Я лишь сказал, что его часто позиционируют как СУТ. Посмотрите многие списки по системам - ЕА там неизменно фигурирует, наряду с RaQuest, RequisitePro. Причем иные uml средства типа VisualParadigm в них нет.

Купить 2 использовать 10:)

7 тысяч долларов дороже 3,500. А у нас и на 3,500 нет бюджета

2872

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

« : 29 Ноября 2009, 20:04:40 »

Вы не можете понять что все шапки ( а в особенности ваша! имеют уникальные свойства типа: "она пролежала у меня на антресолях 8 лет и несколько была смятая".

А кому, кроме вас, есть дело до вашей шапки. Почему вы так уверены, что, если вам предложить для опознания несколько шапок пролежавших на антресолях 8 лет и несколько смятых, вы уверено выберите свою?

Я не могу вам  этого донести.

Так и начните с этого, научитесь доносить свою мысль другим.

Все это станет ясно со временем всем.

Все это что?

2873

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

« : 29 Ноября 2009, 00:30:07 »

ivanoval, не могу понять, что вы пытаетесь донести. Причем тут ваша шапка, которую у вас украли, а потом нашли. И причем тут концепции ООП и реляционных отношений.

Скажите, а если перед вами выложат 100 шапок Красного октября среди которых одна - ваша, как вы ее найдете?

2874

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

« : 28 Ноября 2009, 22:54:21 »

Уровень вашей культуры дисскурсий, меня не поразил. 

Меня он тоже не поражает

Этот человек, в отличии от вас, признанный гений, а вы и я нет, увы.

Вы прямо загадками говорите

Вы вопрос сформулируйте, или идею того, что Вы хотите донести до аудитории. В чем проблема, я так и не понял:
проблема идентификации шапок Красный богатырь?
или проблема, что МВД не умеет создавать реляционные модели данных или использовать ООП?

 

2875

Примеры / Re: Система начисления зарплаты

« : 28 Ноября 2009, 22:48:54 »

Дмитрий, извините, но сразу в топку.

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

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

В любом случае начните с процессов. Пока не очень внятно.

Формализуйте ваше описание, также. Примерно так. Выделите бизнес-правила. Определите функции, Выделите атрибуты качества, ограничения...

1. Новая система должна предоставлять бухгалтеру возможность начислять заработную плату служащим, в соответствии с количеством отработанных часов и объемов продаж.
2. Новая система должна предоставлять бухгалтеру возможность вводить информацию об отработанном времени,
3. служащие должны иметь возможность вводить заказы на поставку,
4. изменять свои параметры (такие, как способ оплаты за работу),
5. и формировать различные отчеты.
6. С целью обеспечения безопасности и аудита служащие должны иметь возможность доступа и редактирования только своих собственных карточек учета рабочего времени и заказов на поставку.
7. В системе должна храниться информация о всех служащих компании в разных странах.
8. Система должна обеспечивать правильную и своевременную оплату работы каждого служащего в соответствии с указанным им способом.
9. Компания по соображениям экономии затрат желает сохранить без изменений одну из существующих баз данных (БД управления проектами), которая содержит всю информацию о проектах и тарифов.
10. БД управления проектами функционирует в среде Microsoft Access на обычном компьютере.
11. Новая система может читать данные из БД управления проектами, но не может обновлять их.
12. Некоторые служащие получают почасовую зарплату.
13. Она начисляется на основе карточек учета рабочего времени, каждая из которых содержит дату и количество часов, отработанных в соответствии с конкретного тарифа.
14. Если любой служащий отработал в день больше 8 часов, сверхурочное время оплачивается с коэффициентом 1.5.
15. Служащие-почасовик получают зарплату каждую пятницу.
16. Некоторые служащие получают фиксированный оклад,
17. однако они тоже предоставляют свои карточки учета рабочего времени.
18. Благодаря этому можно вести учет количества часов, отработанных в соответствии с конкретными тарифами.
19. Такие служащие получают зарплату в последний рабочий день месяца.
20. Некоторые из служащих с фиксированным окладом также получают комиссионное вознаграждение, учитывающей объем продаж.
21. Они представляют заказ на поставку, отражающих дату и объем продаж.
22. Процент комиссионного вознаграждения определяется индивидуально для каждого служащего и может составлять 10%, 15%, 25% или 35%.
23. Одной из наиболее часто используемых возможностей новой системы является формирование различных отчетов: пригласить количество отработанных часов, суммарную зарплату оставшееся время отпуска, и т.п.
24. Служащие могут выбирать способ оплаты за работу. Они могут получать чеки на оплату по почте, на счет в банке или на руки в офисе.
25. Бухгалтер ведет информацию о служащих. В его обязанности входит введение данных о новых служащих, удаление данных и изменение любой информации о служащего, такой, как имя, адрес и способ оплаты, а также формирования различных отчетов для руководства.
26. Начисление зарплаты осуществляет бухгалтер.

Определите круг заинтересованных лиц. Точно и ясно определите цели, которые преследуют ЗЛ при использовании системы. Помните о правиле: элементарный бизнес-процесс, одобрение руководителем, временные рамки (один сеанс).

ДБВИ рассматривается с точки зрения бизнес-участников,  ДВИ с точки зрения пользователей, решающих бизнес-задачи выявленные например на ДБВИ.

Не усердствуйте с диаграммами, ВИ - текст. Модель взаимодействия в первую очередь текстовая модель

2876

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

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

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

Или скажите какую травку курили, может, если покурить ее, то сразу будет ясно, что же Вы имели в виду А то не понятно, что о чем Вы спрашиваете.

2877

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

« : 28 Ноября 2009, 13:02:09 »

В переводе SWEBOK, по KA Software Requirements на стр. 6 приведено пояснения что есть фича, и ее "дуализм".

На самом деле никакого прояснения понятия feature в SWEBOK нет. То же самое "словоблудие". Похоже действительно, имеет смысл просто не обращать на это внимание..

2878

Системный Анализ и Требования / Re: Выбор СУТ для отраслевого проекта с большим числом клиентов

« : 27 Ноября 2009, 23:45:26 »

По совету модератора, изменил в очередной раз название темы. Возможно оно более точно описывает суть проблематики.

Действительно. Проект отраслевой (все может изменится, но пока не вижу тенденций). Клиентская база расширяется.

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

Есть некое базовое ядро функциональности, но есть особенности клиентского бизнеса. Каждый новый клиент добавляет  в общую копилку новые идеи, которые, благодаря усилиям организации, превращаются в новые возможности продукта.

Клиентура расширяется и становится все более серьезной по финансовым условиям, по требованиям и т.п.

Потому нужны средства фиксации и управления информацией необходимой для построения системы, внесения в нее контролируемых модификаций, отслеживания изменений, реализуемости и т.п.

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

2879

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

« : 27 Ноября 2009, 18:28:44 »

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

Мне импонирует определение, которое дает Виталий: фича - то, что уже есть. И переход ясен - требование (что должна делать система), фича - реализация (что уже есть). Причем в описании предложения вся разница в слове ДОЛЖНО.

Может на этом и остановиться

2880

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

« : 27 Ноября 2009, 13:44:27 »

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

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

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

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