91

Sparx / Агрегация против агрегированной ассоциации

« : 21 Февраля 2010, 19:43:08 »

На форуме EA разгорелась не шуточная дискуссия. Некто Paolo F Cantoni открыл явный семантический баг ЕА. Дискуссий много, но итог ее как я понял автор подводит здесь: Aggregation and Association proposa

Кому сложно читать по-английски, перескажу кратко содержание и интригу.

Откройте ЕА. Создайте диаграмму классов. Добавьте пару классов. Начинаем.

Найдите среди Class Relationships отношение Assosiate - нарисуйте тот час.

Теперь найдите там же Aggregate - нарисуйте тот час.

Разница видна невооруженным глазом: на конце агрегации - полый ромб.

Войдите в свойства ассоциации!!! например Source role найдите Aggregation и выставите значение share, а теперь то же самое сделайте с Target role. Вы удивлены, поражены. А попробуйте один конец сделать share, а другой compose.

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

Интересно зачем ЕА допускает такие ляпы? Причем явно сознательно

92

Системный Анализ и Требования / Модель штатного расписания

« : 15 Февраля 2010, 21:02:50 »

Коллеги, друзья!

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

Причина такова. У нас в организации есть два несовместных продукта - одно решение для кадров (ОК) и другое для планово-финансового отдела (ПФО) для работы со штатным расписанием.

Исторически так получилось, что ПФО заказал себе разработку гораздо раньше отдела кадров. Внедрил ее и начал использовать. Но проблемы проявились мгновенно. Для ведения штатного расписания (ШР) потребовались и актуальные данные по отделу кадров. В результате в отделе ПФО получали приказы из ОК и вводили их (в самом общем виде по сути регистрировали) в своей системе. Это нужно было для формирования массы отчетов по факту, по среднесписочной численности и т.п.

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

После внедрение ОК проявились и неудобства отделения ОК от ведение ШР. На самом деле в системе, внедренной в ОК, штатное расписание есть и в целом оно организовано не плохо, но отличается от потребностей ПФО.

Решено адаптировать работу со ШР в системе, внедренной в ОК.

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

Я пытаюсь придумать более качественную модель с учетом реализации для системы ОК, ниже представлена она.

Предлагаю высказаться

93

Sparx / Enterprise Architect 8.0 *beta 1

« : 10 Февраля 2010, 10:13:11 »

Sparx Systems аннонсирует выход релиза бета-версии Enterprise Architect 8.0.

В качестве основных изменений заявляется:
1. новый редактор для структуры сценариев вариантов использования
2. возможность генерации на их основе тестовых сценариев, различных диаграмм
3. создание технологического процесса для тонкой настройки управления изменениями
4. повышение производительности приложения в целом
5. улучшение работы в графическом редакторе
6. повышена интеллектуальность глоссария

вообщем можно скачать и посмотреть

Список изменений тут смотреть список можно во вложении

94

Обучение / Анализ и синтез информационных систем

« : 05 Февраля 2010, 08:49:20 »

Коллеги, друзья!

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

Хотелось бы услышать критику каждого раздела и темы лекции. Возможно новые формулировки и даже иное содержание.

Был бы очень рад указанию ресурсов (литература, статьи, интернет издания). В какой-то степени данный предмет перекликается с дисциплинами: Теория информационных процессов и систем и Основы объектно-ориентированного анализа. А следует за первосеместровым курсом Архитектура современных информационных систем

95

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

« : 26 Января 2010, 18:53:15 »

Сегодня имел удовольствие послушать вебинар от профессора Кумскова.

Семинар был бесплатный и, конечно, в нем говорились самые общие слова. Как сказал докладчик, данный семинар читается им без изменения в течение последних 8-9 лет, и он сам научился понимать, то, что он сам говорит.
Говорилось об требованиях в понимании RUP. Главным образом о вариантах использования и некоторых моментах организации процесса управления требованиями.

В целом докладчик владеет темой, говорит вполне легко. Однако:

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

2. презентация была сделана на английском языке, вероятно это презентация самой фирмы IBM. Забавно, но за 8 лет, можно было бы давно перевести на русский.

3. примеры - примеры, набившие искомину. Все тот же АТМ (банкомат) и регистрация на курсы ala Rational. Скучно.

4. Задал вопрос: Вы говорите, что нужно делать и когда, но как это делать? Ответ: а это темы отдельных ПЛАТНЫХ семинаров

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

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

Вероятно, Коберн "прокололся" на этих страницах (русское издание стр. 176-177)

В английском варианте (стр. 172)
Use cases and functional decomposition
If you are using structured decomposition techniques, then the function decomposition in the use cases is probably useful to your work. However, if you are doing object-oriented design, then there are some special notes to take.

96

Бизнес-анализ и Целеполагание / Перенесено: Нужен совет

« : 06 Января 2010, 14:08:33 »

Тема перенесена в Для всех.

http://www.uml2.ru/forum/index.php?topic=1999.0

97

Обучение / Как готовить специалистов (в том числе ИТ)

« : 05 Января 2010, 17:38:40 »

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

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

В чем же причины?

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

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

Что же делать? В ряде статей предлагаются такие решения:

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

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

3. Третьи предлагают восстановить и расширить практику заочного образования.

4. Считают, что нужно усилить влияние и качество образования на среднем уровне (профтехучилища например)

А Вы что думаете по этому вопросу? Если у Вас идеи, как исправить положение? А может быть все отлично, просто мы имеем дело с очередными "газетными страшилками"?

98

О Сайте и Форуме / Перенесено: Курсовая работа - кодовый замок

« : 04 Января 2010, 17:22:28 »

Тема перенесена в Примеры.

http://www.uml2.ru/forum/index.php?topic=1995.0

99

Sparx / RaQuest: впечатления от работы

« : 03 Января 2010, 16:12:19 »

Если кто-то не знает, то RaQuest представляет собой надстройку над Enterprise Architect и предназначен для работы с требованиями.

Сам EA вполне может заменить RaQuest при работе с требованиями. Я тут не пытаюсь дать анализ того что есть в ЕА, а что добавляет RaQuest.

Просто свои впечатления от работы.

1. RaQuest позволяет сосредоточить внимание на работу с требованиями.
2. RaQuest представляет два списка - иерархический в виде дерева пакетов и требований и линейный список требований
3. RaQuest позволяет отображать списки требований с некоторым правилом отбора: по пакету, по статусу и т.п.
4. RaQuset позволяет задать определенный жизненный цикл работы с требованиями (хотя не очень гибко)
5. RaQuest позволяет сделать анализ влияния изменения требований - графически показав, связанные (зависимые) требования. Это особенно хорошо проявляется, после того, как некое требование переводится из состояния Одобрено опять в предложено. Зависимые требования переходят в состояние требуется ревизия и меняют цвет.

6. Не смог проверить и понять работает ли какая-то нотификация: т.е. я меняю что-то в требовании, а другой пользователь сразу это видит (требование подсвечивается, измененная часть как-то выделяется) - похоже всего этого нет
7. Есть возможность добавлять комментарии, но нет связанных проблем (issues). А это было бы очень удобно. Правда если перейти в ЕА и использовать окно Maintenance... Правда при переходе в ЕА теряются цветовые настройки требований
8. Систему фильтрации можно было бы сделать куда как лучше и интереснее, если прямо в списке требований можно было создавать настраиваемые папки отбора, сохранять всевозможные фильтры или даже генерить автофильтры
9. Минусом, конечно, является отсутствие возможности локализации интерфейса

100

Sparx / Работа с изменениями требований в RAQuest

« : 25 Декабря 2009, 23:45:21 »

Обнаружил интересную функцию в RaQuest: при изменении какого-либо требования (т.е. изменение статуса с одобрено в другое) все связанные требования автоматом переходят в состояние Требуется ревизия.

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

Не совсем понял как этим пользоваться в RAQuest и вообще в процессе.

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

Можно ли получить консультацию?

101

Sparx / Настройка RaQuest для совместной работы

« : 25 Декабря 2009, 14:07:14 »

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

Потребность в неком инструменте высокая.

Сначала пробовал сделать все на базе testlink, но там он заточен под тестирование.

В целом создал в RaQuest струтуру, выложил файл в общий доступ. Пока планируется два подключение: мое как заказчика и приемщика, и аналитика, который пишет работы по требованиям.

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

Нужна помощь в настройке RAQuest и EA для работы:
1. как и где настроить виды, статусы требований - хотелось бы иметь руссифицированые обозначения
2. Как спланировать и реализовать жизненный цикл
3. Стоит ли вводит разделение прав и полномочий по пользователям и как лучше это сделать
4. имеет ли смысл использовать СУБД или лучше оставить rqe и просто реплицировать его попотребности
5. как правильно и корректно мерджить реплики
6. стоит ли заморачиваться на бейзланах
7. какие вообще настройки рекомендуется сделать в начале работы

102

Sparx / Enterprise Architect и управление требованиями

« : 14 Декабря 2009, 20:31:06 »

Если не приживется убьем!

Для начала хочу задать несколько вопросов по организации группировок требований и связей.

Итак, ЕА позволяет нам группировать требования разным способом:
1. Пакеты - пакеты классические элементы группировки и ограничения поля внимания.

Вопрос такое: в каком случае целесообразно использовать именно пакеты? Или, что лучше выбрать за элемент классификации. Пакеты это иерархическая, строгая, но не гибкая классификация.

2. Вложенность - т.е. требование можно вложить в другое требование. В ЕА это связь владения, она никак графически не отображается, но проявляется в виде иерархии.

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

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

4. Группировка по типу требований - это сквозная группировка и тут, кажется, все понятно.

5. Зависимости - наверное просто показывает влияние одних от других и к группировке не относится.

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

7. Еще можно выделить ассоциации - можно ли считать это тоже своего рода группировками? Когда работают ассоциации?

8. Могут ли требования находится в отношении реализации? И может ли это являться также группировкой?

103

Термины и Определения / [ТЕРМИН] ТРЕБОВАНИЕ

« : 01 Декабря 2009, 09:38:18 »

Термин требование является, пожалуй , одним из достаточно понятных и устойчивых понятий:

• Условие или возможность, требуемая пользователем для решения задач или достижения целей.
• Условие или возможность, которые должны удовлетворяться системой/компонентом системы или которыми система/компонент системы должна обладать для обеспечения условий контракта, стандартов, спецификаций или др. регулирующими документами.
• Документальная репрезентация (зафиксированное определение, описание) условий или возможностей, перечисленных в предыдущих пунктах.

Однако и в таком простом, кажется, понятии можно найти массу причин для дискуссий и толкований.

Недавно была такая дискуссия на работе. Ощущение, что все прекрасно знаю, что такое требование. Однако...

Вот такой вызов.
- Что такое требование? - говорит один из участников. - Это то, что можно проверить. Следовательно требование, которое группирует другие требования, не является требованием, потому, что оно не проверяемое. А требование должно быть проверяемы.

Т.е.
Система должна обеспечить возможность составлять отчет по форме 3НК - это не требование, это пожелание, запрос, потребность, нужда. Как Вы проверите, что отчет составлен правильно? Никак.

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

Система должна обеспечить возможность составлять отчет по форме 3НК
    Система должна сохранять отчет в формате csv
    Отчет должен содержать следующие графы: ......
    Значения полей вычисляются по формулам:
      1. формула 1
      2. формула 2

и т.д.

А Вы что об этом думаете?

104

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

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

Сегодня возникла дискуссия по поводу того, что означает понятие feature.

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

Мой оппонент понимает или хочет понимать под этим некий элемент реализации. Т.е. у него взгляд, что Feature реализует некоторое требование. Хотя явно имеет место обратная зависимость. Ну, например, в примерах RequsitePro - там Use cases реализуют Features.

Итак вопрос, что есть feature, каково его место в проекте? Как можно назвать спроектированные элементы, реализующие некие требования.

Например, требуется реализовать отчет 3НК по профессорско-преподавательскому составу по заданным разрезам группировки. Это требование заказчика.

Что может быть feature в этом случае? Некоторые артефакты проекта позволяющие это сделать? Или это системные требования? Или реализованные свойства системы? Просто функция системы?

105

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

« : 22 Ноября 2009, 00:25:38 »

Нужна помощь в выборе системы управления требованиями, причем как можно быстрее.

Точных требований к СУТ, я сейчас сформулировать не могу, но общие скажу:
1. возможность совместной работы в одном репозитории
2. возможность ведения и отслеживания базлайна
3. возможность быстрой и удобной прослеживаемости по требованию вверх и вниз
4. возможность добавления удаления атрибутов, привязка артефактов и т.п.
5. составления отчетности
6. возможность ведения некой общей модели требований и наследования от нее различных версий ориентированных на конкретных клиентов

Сейчас в качестве кандидатуры рассматривается связка RaQuest+EA.

TrackStudio - не понравилась (мнение пиэма)