211
ПО Аналитика / Re: Как отобразить в Rational Software Modeler ....
« : 10 Февраля 2011, 11:43:28 »
Извините, я сегодня занят. При первой возможности посмотрю.
Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
212
Для всех / Re: Нужна помощь в документировании CRM
« : 09 Февраля 2011, 16:51:03 »
Я не совсем понял, о чем идет речь.
Если, предположим, проект преобразования модели в код, то нужно строить в любом виде карту отображений.
Я такие карты рисую с помощью двух диаграмм классов: модель-источник и модель-цель, и, "неправильно" зависимостями показываю из чего в источнике появляется много чего-то в цели.
По такой "картинке" легко программировать преобразование.
Извините, если речь идет не о том.
Если, предположим, проект преобразования модели в код, то нужно строить в любом виде карту отображений.
Я такие карты рисую с помощью двух диаграмм классов: модель-источник и модель-цель, и, "неправильно" зависимостями показываю из чего в источнике появляется много чего-то в цели.
По такой "картинке" легко программировать преобразование.
Извините, если речь идет не о том.
213
ПО Аналитика / Re: Как отобразить в Rational Software Modeler ....
« : 08 Февраля 2011, 20:07:48 »
Небольшое замечание: аргумент сообщения д.б. доступен сообщению. В Вашем случае класс "Подчиненный" должен иметь атрибут "состояние".
Когда вы отправляете сообщение, аргументом является текущее значение этого атрибута.
Я вижу два варианта. Оба плохие.
- На линию жизни перед сообщением устанавливаете State Invariant. В качестве ограничения устанавливаете "состояние = <нужное значение>". Это значение будет действительно на линии жизни до следующего изменения.
На диаграмме видно, какое значение пересылается. Валидатор нарушений не обнаруживает, т.е. это правильно.
Что плохо? Не используется элемент перечисления (Enumeration)
- Выбираем сообщение. На закладке Arguments в правой таблице создаем новую строку и выбираем тип Literal String. В поле Value пишем значение аргумента.
Тоже не используется перечисление.
Извините, лучше придумать не могу!
Если найдете более приличный способ, сообщите пожалуйста, будьте добры!
P.S. Если это не "придуманный" пример, то, наверное, сообщение должно включать идентификатор работяги.
Когда вы отправляете сообщение, аргументом является текущее значение этого атрибута.
Я вижу два варианта. Оба плохие.
- На линию жизни перед сообщением устанавливаете State Invariant. В качестве ограничения устанавливаете "состояние = <нужное значение>". Это значение будет действительно на линии жизни до следующего изменения.
На диаграмме видно, какое значение пересылается. Валидатор нарушений не обнаруживает, т.е. это правильно.
Что плохо? Не используется элемент перечисления (Enumeration)
- Выбираем сообщение. На закладке Arguments в правой таблице создаем новую строку и выбираем тип Literal String. В поле Value пишем значение аргумента.
Тоже не используется перечисление.
Извините, лучше придумать не могу!
Если найдете более приличный способ, сообщите пожалуйста, будьте добры!
P.S. Если это не "придуманный" пример, то, наверное, сообщение должно включать идентификатор работяги.
214
О Сайте и Форуме / Re: Правила работы на форуме uml2.ru
« : 05 Февраля 2011, 20:23:34 »
Спасибо!
Я со вчерашнего дня мучаюсь, как опечатку исправить!
Я со вчерашнего дня мучаюсь, как опечатку исправить!
215
Управление Проектом / Re: Шпаргалка руководителю проекта
« : 04 Февраля 2011, 19:30:11 »Сколько же можно. Где вы вообще это слово гадкое берёте — BOOK?
Нету в аббревиатуре Body Of Knowledge двойного O, ну нету его там.
Спасибо, что вычитали опечатку! Увы, я не всегда вычитываю, спешу!
Есть еще?
216
Управление Проектом / Re: Шпаргалка руководителю проекта
« : 04 Февраля 2011, 16:47:39 »IMHO для "мета-процесса" и тем более шпаргалки диаграмма сложновата и без пояснительного текста ее воспринимать не просто, особенно на ночь глядя. Множество форков -с распараллеливанием и потом синхронизацией да еще в распределении по ролям затрудняют восприятие. Я бы предложил активнее использовать событийный аппарат, думаю это бы упростило восприятие да собственно саму диаграмму. Другой аспект - реальная ценность такой шпаргалки, о чем пытался сказать тов. Водолей ... я понимаю для чего это может быть полезно, особенно с методологической точки зрения ... но, боюсь, у "полевых командиров" это не вызовет энтузиазма.
Юра, спасибо за конструктивную критику.
Один "полевой командир" (из-за которого и нарисовано) выставил сегодня бутылку пива. Посмотрим, поможет ли ему эта "шпаргалка"!
Использование событий, на мой взгляд, не сильно упростит картину.
Я хотел сделать карточку на А4, которую можно было бы охватить одни взглядом, но получилось очень мелко.
Можно чуть подсократиться, исключив понятие "возможности" и, соответственно, убрав цикл по прецедентам.
Есть самый простой способ:
- у меня инстинкт на уровне спинного мозга: создал модельный элемент - написал краткое описание, т.е. диаграмма описана
- сгенерить SoDA-отчет: диаграмма и текстовое описание процесса
- т.к. "карточка" все равно не получилась, диаграмму декомпозировать с использованием Call Bechavior
Вопрос только, стоит ли овчинка выделки?
Судя по реакции читательской аудитории, стоит.
218
Управление Проектом / Re: Шпаргалка руководителю проекта
« : 04 Февраля 2011, 15:55:37 »План не может содержать действий и/или исполнителей и/или трудоемкостей.
Если более простыми словами, то:
План - есть совокупность конечных и промежуточных состояний, описанных в терминах достижимости.
Как только вы написали действие вместо результата, все - это более не план. И эта диаграмма перестала быть актуальной, как только вы закончили ее рисовать.
жЫрный плюсадин !!!
про то, собственно, и речь толкую...
Ну, ребята, вы меня уели!!! Поставил бы жирные плюсы, но ...
Есть и другие определения плана:
- План — вершина выпуклого множества решений в симплекс-методе линейного программирования.
- План — муниципалитет в Испании, входит в провинцию Уэска.
- План — сленговое название продуктов конопли, известных также под названием гашиш, используемых как наркотическое средство.
Но, я думаю, эти термины не подходят.
Бытовое понятие плана, пример из реальной жизни:
- Вечер. Двое бегут в магазин. Подбежали - магазин закрыт!
" Что делать будем? Какие планы?".
Это ближе к теме.
Я открыл PMBOK (ANSI/PMI 99-001-2004), там несколько связанных определений, перепечатывать лень!
Поищем, что попроще!
Вот: http://www.klerk.ru/boss/articles/104256/
Цитата из этой статьи:
"Проект позволяет достичь определенного результата в определенные сроки и за определенные деньги. План проекта составляется для того, чтобы определить, с помощью каких работ будет достигаться результат проекта, какие люди и оборудование нужны для исполнения этих работ, в какое время эти люди и оборудование будут заняты работой по проекту. Поэтому проектный план содержит три основных элемента: задачи (task), ресурсы (resource) и назначения (assignment)."
Но и это еще не все:
Та диаграмма, которую я нарисовал, это не план проекта, и даже не шаблон. Это описание стандартного процесса разработки всего одной возможности будущего ПО, шпаргалка, которую (начинающий) руководитель проекта может использовать при рисовании графика в части реализации возможности (задачи и исполнители).
Если хватит терпения, прочитайте, это наверху написано!
Желаю успехов!
219
Вакансии / Re: Вакансия Аналитик
« : 04 Февраля 2011, 14:50:06 »
Какой город, подскажите пожалуйста?
220
Управление Проектом / Re: Шпаргалка руководителю проекта
« : 03 Февраля 2011, 23:48:55 »
А я и не призываю всех использовать один шаблон.
И даже RUP не призывает!
И назвал я свою работу не шаблон, а шпаргалка. Пусть лежит в кармане до случая!
Вот вторая версия. Все то же, но добавлены роли исполнителей.
Напоминаю: роли, а не люди! Это может быть даже один человек.
Французы говорят, что "человек может носить множество шляп". От себя добавлю: но в каждый момент только одну (если не в цирке).
И даже RUP не призывает!
И назвал я свою работу не шаблон, а шпаргалка. Пусть лежит в кармане до случая!
Вот вторая версия. Все то же, но добавлены роли исполнителей.
Напоминаю: роли, а не люди! Это может быть даже один человек.
Французы говорят, что "человек может носить множество шляп". От себя добавлю: но в каждый момент только одну (если не в цирке).
221
Управление Проектом / Re: Шпаргалка руководителю проекта
« : 03 Февраля 2011, 22:39:44 »
Дорогой друг!
Целиком с вами согласен: не бывает правил без исключений.
Вам не приходилось сталкиваться с такой книжкой: "Международные правила предупреждения столкновения судов в море"? Толстая такая книжка. Правила посложнее, чем на дороге. Там в одном из последних правил написано примерно следующее: "Ничто в настоящих правилах не освобождает судоводителя от ответственности за происшествие, если под предлогом соблюдения правил он нарушил правила хорошей морской практики".
Аналогично, в Петровском "Морском уставе" было написано: "Здесь правила писаны, а случаев нет!"
И тем не менее, правила, уставы ("технологии") очень помогают в обычных ситуациях, которых большинство!
Использование технологий, шаблонов, "шпаргалок" при разработке ПО существенно сокращает время (о деньгах ни слова!), повышает качество за счет применения проверенных решений, и освобождает голову для решения сложных проблем, которых в нашем деле хватает!
Не хотите использовать проверенные технологии - удачи! Только посложнее жить будет.
А эту "шпаргалку" я рекомендую начинающим руководителя проектов. Не эту версию, я обещаю выставить, наверное, на своем сайте, полное описание.
Целиком с вами согласен: не бывает правил без исключений.
Вам не приходилось сталкиваться с такой книжкой: "Международные правила предупреждения столкновения судов в море"? Толстая такая книжка. Правила посложнее, чем на дороге. Там в одном из последних правил написано примерно следующее: "Ничто в настоящих правилах не освобождает судоводителя от ответственности за происшествие, если под предлогом соблюдения правил он нарушил правила хорошей морской практики".
Аналогично, в Петровском "Морском уставе" было написано: "Здесь правила писаны, а случаев нет!"
И тем не менее, правила, уставы ("технологии") очень помогают в обычных ситуациях, которых большинство!
Использование технологий, шаблонов, "шпаргалок" при разработке ПО существенно сокращает время (о деньгах ни слова!), повышает качество за счет применения проверенных решений, и освобождает голову для решения сложных проблем, которых в нашем деле хватает!
Не хотите использовать проверенные технологии - удачи! Только посложнее жить будет.
А эту "шпаргалку" я рекомендую начинающим руководителя проектов. Не эту версию, я обещаю выставить, наверное, на своем сайте, полное описание.
222
Управление Проектом / Re: Шпаргалка руководителю проекта
« : 03 Февраля 2011, 21:16:31 »
Извините, процесс разработки плана программного проекта от цели конкретного проекта никак не зависит. От объема, формальности - зависит. А вот от предметной области - практически нет!
(Я имею ввиду объектно-ориентированный проект разработки ПО по RUP (процесс итерационный, инкрементный, базирующийся на use cases).
(Я имею ввиду объектно-ориентированный проект разработки ПО по RUP (процесс итерационный, инкрементный, базирующийся на use cases).
223
Управление Проектом / Re: Шпаргалка руководителю проекта
« : 03 Февраля 2011, 21:04:21 »
Спасибо!
В общем-то о цели шпаргалки я написал: помочь руководителю программного проекта в составлении плана проекта.
По RUP, проект должен реализовать требования, главные из которых - это требования возможностей. Возможности декомпозируются в прецеденты.
RUP поставляет шаблоны MS Project для планов итераций. RMC может сгенерить шаблон для проекта в целом. Но работать с ними достаточно сложно.
Т.к. RUP, смею Вас заверить, знаю достаточно хорошо, я и решил сделать такую картинку, глядя на которую руководитель сможет определить (предположим, в MS Project) задачи проекта для каждой возможности и прецедента (действия диаграммы), установить зависимости между задачами (ребра диаграммы) и назначить исполнителей (я сейчас дорисовываю версию диаграммы с потоками - ролями RUP), сегодня выложу.
Поводом для этой работы послужила встреча-консультация в одной из компаний.
Диаграмма приводит бизнес-процесс разработки возможности в программном проекте. Процесс несколько упрощен по сравнению с глобальным RUP и доведен до реально практического уровня.
Почему выложил на сайт аналитиков?
Аналитики - интеллигенция проекта, часто знают проект лучше руководителя, который занят текучкой, и помогают ему, в том числе - в планировании.
В общем-то о цели шпаргалки я написал: помочь руководителю программного проекта в составлении плана проекта.
По RUP, проект должен реализовать требования, главные из которых - это требования возможностей. Возможности декомпозируются в прецеденты.
RUP поставляет шаблоны MS Project для планов итераций. RMC может сгенерить шаблон для проекта в целом. Но работать с ними достаточно сложно.
Т.к. RUP, смею Вас заверить, знаю достаточно хорошо, я и решил сделать такую картинку, глядя на которую руководитель сможет определить (предположим, в MS Project) задачи проекта для каждой возможности и прецедента (действия диаграммы), установить зависимости между задачами (ребра диаграммы) и назначить исполнителей (я сейчас дорисовываю версию диаграммы с потоками - ролями RUP), сегодня выложу.
Поводом для этой работы послужила встреча-консультация в одной из компаний.
Диаграмма приводит бизнес-процесс разработки возможности в программном проекте. Процесс несколько упрощен по сравнению с глобальным RUP и доведен до реально практического уровня.
Почему выложил на сайт аналитиков?
Аналитики - интеллигенция проекта, часто знают проект лучше руководителя, который занят текучкой, и помогают ему, в том числе - в планировании.
224
ПО Аналитика / Re: Как отобразить в Rational Software Modeler ....
« : 03 Февраля 2011, 12:08:48 »
Когда Вы создаете сообщение на диаграмме последовательности, нужно выбрать название соответствующей операции целевого класса. Если нужной операции нет, будет создана новая операция с именем сообщения.
Сообщение использует для передачи параметры и возвращаемое значение этой операции.
Т.о., устанавливать параметры и возвращаемое значение сообщению диаграммы последовательности не требуется.
Сообщение использует для передачи параметры и возвращаемое значение этой операции.
Т.о., устанавливать параметры и возвращаемое значение сообщению диаграммы последовательности не требуется.
225
Управление Проектом / Re: Шпаргалка руководителю проекта
« : 02 Февраля 2011, 20:20:13 »
Ну, я, для затравки, без объяснений выставил.
Возможность обеспечивается множеством прецедентов. Они обрабатываются по плану, в порядке приоритетов (здесь, как будто, один аналитик, по-этому прецеденты модели обрабатываются по-очереди).
Горизонтальная полоса под действием "Разработка спецификации..." - это Fork UML2 (Разветвление на параллельные потоки).
Параллельно выполняются:
- если есть еще прецеденты - аналитик обрабатывает следующий
- полученная спецификация передаются на анализ (если он будет выполняться) или сразу на проектирование
- технический писатель начинает писать руководство пользователя для прецедента
- тестер начинает писать сценарий тестирования прецедента, и т.д.
Системный аналитик "сдает" спецификацию после согласования с заинтересованными лицами и проектировщиками. Ошибка требований, увы, обнаруживается, обычно, при "шапочном разборе", что условно обозначено переходом после действия "Тестирование".
Любое изменение требований подразумевает повторение всей цепочки.
Вообще, при рисовании все комментарии были документированы в свойстве Description.
В частности, там написано, что "разработка" - это "создание", "изменение" или "удаление".
На верхнем уровне описания (Activity) указано, что при обнаружении ошибки процесс переходит к первому Merge.
Возможность обеспечивается множеством прецедентов. Они обрабатываются по плану, в порядке приоритетов (здесь, как будто, один аналитик, по-этому прецеденты модели обрабатываются по-очереди).
Горизонтальная полоса под действием "Разработка спецификации..." - это Fork UML2 (Разветвление на параллельные потоки).
Параллельно выполняются:
- если есть еще прецеденты - аналитик обрабатывает следующий
- полученная спецификация передаются на анализ (если он будет выполняться) или сразу на проектирование
- технический писатель начинает писать руководство пользователя для прецедента
- тестер начинает писать сценарий тестирования прецедента, и т.д.
Системный аналитик "сдает" спецификацию после согласования с заинтересованными лицами и проектировщиками. Ошибка требований, увы, обнаруживается, обычно, при "шапочном разборе", что условно обозначено переходом после действия "Тестирование".
Любое изменение требований подразумевает повторение всей цепочки.
Вообще, при рисовании все комментарии были документированы в свойстве Description.
В частности, там написано, что "разработка" - это "создание", "изменение" или "удаление".
На верхнем уровне описания (Activity) указано, что при обнаружении ошибки процесс переходит к первому Merge.