76

Обсуждение статей / Re: Управления Требованиями на базе Wiki-движков (Confluence)

« : 14 Июня 2011, 10:48:26 »

Интересный подход. Зря я не обратил внимания раньше на этот пост. А сейчас вот начал копаться с Confluence и наткнулся на этот пост. Сейчас понимаю, что использованием этого мощного wiki движка можно сделать серьезные вещи.

У нас был пилотный проект на XWIKI делали описание основных ИС и связанных с ними бизнес-процессов, по большей степени как глоссарий процессов. Дополнительно использовали MS SharePoint как хранилище документации по проекту (ссылки на дизайны, пользовательские инструкции и т.п.), в XWIKI ссылки на документы. Получилось неплохо, но дальше пилота не пошло (лидеров проекта не осталось, ресурсов на поддержку не выделили).

77

Для всех / Re: Какие диаграммы использовать для процедурных яызков впрограммирования.

« : 14 Июня 2011, 09:13:54 »

А какие диаграммы использовать?

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

78

Примеры / Re: Концептульная модель системы мониторинга подвижных и стационарных объектов

« : 09 Июня 2011, 17:39:43 »

Основной целью Пункта сбора является сбор информации и ее последующий анализ.

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

79

Примеры / Re: Концептульная модель системы мониторин

« : 09 Июня 2011, 16:11:27 »

Про необходимость ввода родительского класса для объектов мониторинга написал Galogen.
Объекты мониторинга содержат Датчики, имеет смысл для них сделать свой класс. Датчики связаны с объектами мониторинга отношением композиции, многие к одному.
Чем принципиально отличаются подвижный объект от неподвижного, за исключением того что георгафическое положение подвижного меняется?
В вашем примере не понятно назначение сущности (класса) "Пункта сбора информации"
Какая у него цель, что этот класс выполняет?
Не понятна фраза "Стационарные и подвижные объекты также могут обмениваться данными с помощью сетей связи", они что передают данные друг другу? Если да то какие направления передачи возможны, например только от подвижных в стационарные или двунаправленная. Ну допустим они обменялись какой-то информацией а какая цель? Возможно что в этом случае объект играет роль пункта сбора информации.

80

Вакансии / Re: Ведущий бизнес-аналитик (Москва) / срочно/

« : 08 Июня 2011, 16:36:17 »

Что то с адресом не очень понятно, м. Коломенская, а адрес Варшавское шоссе?
Не могли бы уточнить чем торгуют?

81

Для всех / Re: Логическая модель БД: правила именования сущностей

« : 08 Июня 2011, 12:52:19 »

Периодически участвую в споре с коллегами на тему: использовать ли в именах сущностей на логической модели БД дополнительные пометки, раскрывающие общий тип назначения сущности?
Например, создаём мы сущность "Тип куздры" или "Вид бокрёнка", которые при реализации станут справочниками. Появляется предложение добавить в имена этих сущностей приставку "Справочник" или хотя бы "С_". В теории это должно облегчить поиск справочников и повысить читаемость модели и простого списка сущностей. Таким же образом предлагается поступать с внутрисистемными сущностями, не имеющими прямого отношения к бизнесу.
Есть альтернативная точка зрения - грамотно названная сущность и без дополнительных приставок позволяет легко раскрыть её предназначение и выгоды поиска(спорные) не стоят уродования модели приставками сущностей.
Проблема общего согласия по вопросу усугубляется тем, что разные точки зрения закреплены многолетними наработками нескольких проектов. Так что перспектива оказаться со своим проектом "вне закона" сильно мешает объетивному рассмотрению вопроса отдельным аналитиком.
Так же считаю нужным упомянуть, что ранее мы уже пришли к договорённости, согласно которой сущности на логической модели подкрашиваются в соответствии с назначением. Так же был выработан единый стиль расцветки.
Прошу участников сообщества помочь в аргументации того или другого подхода. Возможно, это позволит положить конец нашему противостоянию.

Если речь о моделях UML то:
- Для расширения семантики существуют стереотипы
- Для диаграмм классов анализа в рамках RUP определены стереотипы boundary, control, entity
Я сторонник использования терминов предметной области без дополнительных обозначений, это не накладывает на этапе анализа никаких ограничений на реализацию. Но зачастую от этих правил приходится отступать, в зависимости от наличия таких наименований в рабочем проекте или особенностей среды разработки.

82

Примеры / Re: BUSINESS USE CASE MODEL

« : 31 Мая 2011, 10:12:38 »

БДВИ для предметной области и для моделируемой системы это одно и то же? или нужно рисовать 2 диаграммы отдельно?

Две отдельно.

83

UML SysML и пр. / Re: Вопрос о реализации диаграммы

« : 30 Мая 2011, 12:03:45 »

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

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

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

Я бы рекомендовал автору использовать даже не диаграммы деятельности UML, а посмотреть в сторону нотации eEPC диаграммы в ARIS (тем более что появился бесплатный Aris Express). Там более строгие требования к оформлению и он больше приспособлен именно к описанию БП, дает более четкое понимание какие действия к какому результату приводят (например каждое действие должно переходить в событие).

84

Вакансии / Re: Бизнес аналитик на проект, Москва, до 200000 р.

« : 25 Мая 2011, 10:23:36 »

Ребята, не флудите. Зарплата приличная. Найдется тот, кто нужен. БА или СА. Имхо разница холиварная.

Из ответов автора темы понятно, что нужен "специалист с опытом работы в проектах SCAD, желательно в фармацевтике".
Громкие слова "рекомендовать решения, благодаря которым организация сможет достичь своих целей" трансформировались в "поиск оптимальных вариантов использования возможностей системы или её доработки под процессы компании".
Нужны в большей степени компетенции в области платформы и архитектуры решения.
Вообще есть сомнения что автор найдет кандидатов на данном ресурсе, лучше искать на профильных связанных именно со SCAD. 

85

Вакансии / Re: Бизнес аналитик на проект, Москва, до 200000 р.

« : 25 Мая 2011, 10:14:55 »

SCAD платформа аналогичная Oracle или SAP в РФ не используется. Поиск решения состоит в том, что систему нужно будет адаптировать под российскую действительность и бизнес-процессы компании, либо, что хуже для компании адаптировать процессы под систему

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

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

86

Вакансии / Re: Бизнес аналитик на проект, Москва, до 200000 р.

« : 23 Мая 2011, 10:45:09 »

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

Тогда это "больше СА" чем "БА".
А потом вводит в недоумение эта фраза: "Задача бизнес-аналитика: изучить и понять структуру, политики и опреционную деятельностьорганизации и рекомендовать решения, благодаря которым организация сможет достичь своих целей."
А если предложенное решение по достижению целей будет вне области применения ИТ или вне области "методологии SCAD" (кстати интересно что это за методология и какое отношение она имеет к области фармацевтики).
То есть получается специалист нужен для внедрения уже выбранного решения или методологии, но в то же время задачи стоят в поиске решения.

87

Для всех / Re: Каким образом можно описать принцип работы класса в системе, если например класс

« : 23 Мая 2011, 10:34:35 »

А что эти "функции класса" (методы) никак не вызываются например в алгоритмах методов других классов?
Если не вызываются то класс кандидат на удаление.
Читайте материалы:
Диаграмма кооперации
http://khpi-iip.mipk.kharkiv.edu/library/case/leon/gl9/gl9.html
Диаграмма последовательности
http://khpi-iip.mipk.kharkiv.edu/library/case/leon/gl8/gl8.html

88

Задачи студентов / Re: Выручайте студента!!!

« : 16 Мая 2011, 13:28:49 »

И как тогда быть с угнанными авто??

В принципе угнанные авто это характеристика ТС изменяемая во времени
По идее можно реализовать через атрибуты класса ТС: ДатаСообщенияОбУгоне, Угнан, ДатаУгона,  и т.п. Если достаточно только текущего состояния "угнан" - "не угнан", то достаточно атрибутов в классе ТС и метода который будет возвращать отчет по угнанным.
Но если представить ситуацию более широко то один и тот же ТС за свою жизнь может быть угнан несколько раз, то для необходимо отдельная сущность предназначенная для учета фактов угона и возврата угнанных ТС. Через методы такого класса можно будет организовать формирование отчетов, вывод списков угнанных  и т.п.

89

Термины и Определения / Re: [Термин] Диаграмма Вариантов Использования

« : 16 Мая 2011, 09:46:53 »

Странный термин Откуда он родился вообще? И почему использования?

А вроде говорили что английским владеете.
Use - использовать.
Case - вариант.

90

Системный Анализ и Требования / Тренинг «Идеальное ТЗ»

« : 13 Мая 2011, 17:40:44 »

ТЗ наверное не самый лучший термин (просто данный пост посвящен ТЗ). Я имею в виду спецификацию (описание) того, что пользователь ожидает от программы.

Да по ГОСТУ именно для этого в том числе предназначено ТЗ.
Но ТЗ по ГОСТУ не определяет детально архитектуру и конкретику проектирования - это более высокоуровневый документ.

"2) идеальное ТЗ, а вернее требования, которые в нем описаны, должны иметь ОДНОЗНАЧНОЕ представление в виде программных конструкций, используемых Разработчиком. Другими словами архитектуры системы должна строиться в терминах Заказчика, а не в терминах Разработчика. Иначе новые требования через какое-то время разрушат архитектуру."

Требования Заказчика и "архитектура" это разные уровни абстракции. И однозначного соответствия между терминами не будет, поскольку разработчик вынужден оперировать "терминами" той среды (платформы) которая используется для разработки.
Например Заказчик использует термин Классификатор (суть НСИ).
Разработчик в 1С будет использовать "термин" - Справочник.
Разработчик в другой системе вообще может оперировать термином - таблица БД и т.п.

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

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

На самом деле в разных командах и проектах по разному используют термин ТЗ.
Во многих мох проектах использовалось и используется абсолютно не гостовское понимание. У нас под "ТЗ" подразумевается низкоуровневый документ описывающий постановку задачи, требования к структурам данных, алгоритмам их обработки и т.п. именно в терминах конкретной среды или платформы разработки - то есть по сути это постановка задачи разработчику.
Дерево документации в наши проектах такое:
RFA (Заявка на доработку или решение задачи или проблемы)
  Концепция (не обязательно)
      Бизнес-дизайн, функциональные требования (это собственно основной документ оговаривающий все значимые с точки зрения требований заказчика моменты, зачастую с примерами экранных форм разъясняющий логику работы пользователей с разрабатываемой фунциональностью)
         Техническое задание, постановка задачи