Форум Сообщества Аналитиков

×


Повышение производительности аналитика(Прочитано 24977 раз)
Неее, верстка статьи не совпадает с выделенным для нее местом, например, из-за длинных адресов ссылок (особенно та, которая про TOGAF). рекомендую правильно (с точки зрения верстки) переписать эти ссылки.
Большое спасибо. Заменил тексты ссылок на более приличные. Протестировал в IE. OK!
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



Добавлена очередная статья:
http://lnew.ucoz.ru/publ/opyt_modelirovanija_na_uml/povyshenie_proizvoditelnosti_analitika/povyshenie_proizvoditelnosti_analitika_03/6-1-0-27

Статья посвящена самому забытому на форуме продукту работы аналитика: "План управления требованиями".

Дорогие друзья!
Хочу еще раз напомнить: цикл задуман как возможность поделиться многолетним опытом аналитика. Но рамки статьи предполагается соответствующий стиль изложения, не позволяющей строгой формализации, представления моделей (целиком) или документов.

Эти статьи - вершина айсберга. Основной материал (по важности и по размеру) находится в приложениях, на которые ссылаются статьи.
Тем, кто действительно хочет что-то получить от чтения статей, советую скачивать приложения. Там нет ни одного "придуманного" примера. Все это фрагменты "живых" проектов, которые лишь обезличены, чтобы "хозяева" проектов не могли предъявить претензии к "раскрытию информации".
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



Спасибо, Леонид Борисович, почитаем. Хотя я и не профессиональный аналитик



Читал первую статью: Повышение производительности аналитика 01 и смотрел приложение.

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

Есть вопросы:
1. Почему считается, что способ рисования сценариев ВИ (т.е. реализации ВИ) в виде ДД лучше, чем текст?
2. Почему считается, что реализации ВИ через ДД удобнее и прагматичнее, чем реализации сценариев чере диаграммы сценариев = ДП?
3. Почему ограничивается, что любой include и extend ВИ - есть абстрактный ВИ?
4. Почему ограничивается, запрещается наличии ассоциации между actor и include / extend ВИ ?

Вы пишите:
Цитировать
Примечание: В исключительных случаях, если рабочий поток прецедента может быть ясно описан словами, использование диаграммы деятельности не обязательно. В этом случае можно обойтись описанием прецедента в области документирования (в терминах взаимодействий субъектов с системой).
А скажите:
5. Каким образом диаграммы активностей помогают построить MDA?

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

7. А также есть ли какие-то оценки именно повышения производительности работы аналитика? И что понимается под производительностью аналитика?

Спасибо

« Последнее редактирование: 31 Июля 2011, 12:21:35 от Galogen »



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

1. Почему считается, что способ рисования сценариев ВИ (т.е. реализации ВИ) в виде ДД лучше, чем текст?
2. Почему считается, что реализации ВИ через ДД удобнее и прагматичнее, чем реализации сценариев чере диаграммы сценариев = ДП?
3. Почему ограничивается, что любой include и extend ВИ - есть абстрактный ВИ?
4. Почему ограничивается, запрещается наличии ассоциации между actor и include / extend ВИ ?

3. Я ничего не ограничивал. В метамодели UML UC - это классификатор. Абстрактный классификатор не имеет собственных экземпляров. UCI и UCE не имеют собственных экземпляров: они выполняют экземпляры основного UC.
4. Наверное, Коберн ввел понятие первичного Actor (цель которого реализует UC). Взаимодействие первичного Actor создает экземпляр UC. С UC могут взаимодействовать другие Actor, но они "помогают" (пример - клиент банкомата и процессинг). Т.о., ограничение относится только к первичному Actor. Вторичные могут "помогать", взаимодействуя с экземпляром основного UC в границах основного UC, UCI или UCE.
2. ДД, на мой взгляд, удобнее и прагматичнее, т.к. просто нагляднее, особенно, если процесс достаточно "запутанный" (много логики). RUP вообще возможность использования ДП для этих целей не рассматривает!
1. Простите, за других не говорю! Для меня - несколько причин.
    - Я никогда не сумел бы в голове построить схему сложного процесса с параллельными и альтернативными потоками и описать ее. Все равно стал бы  что-то рисовать и писать по рисунку
    - Я использую инструменты, которые позволяют рисовать и генерировать текст из модели в нужной мне форме
    - Я могу использовать MDA, в частности, преобразовать BUC в пакет функциональной области в модели UC, автоматизируемые действия ДД - в UC, а соответствующий раздел - в Actor (и т.п.) 


5. Каким образом диаграммы активностей помогают построить MDA?

В чем, на мой взгляд, состоит отличие MDA от MDD?
- В MDD есть моделирование и преобразование модели в код
- В MDA есть 4 вида моделей: бизнес (включая UC), анализ, проект, код и преобразования "туда-обратно" для каждой пары смежных моделей.
Наверное, теоретически возможно преобразовать описание UC на естественном языке в модель анализа. Трудно придется! А для моделей это не проблема, есть множество примеров. Если средство моделирования поддерживает MDA, в нем д.б. инструментарий для создания преобразований (так написано на сайте OMG).


6. Имеются ли какие-либо оценки эффективности, полезности на создание и поддержание модели или ее фрагмента отнесенного к трудозатратам на использование специалиста? Сколько вообще нужно специалистов?
7. А также есть ли какие-то оценки именно повышения производительности работы аналитика? И что понимается под производительностью аналитика?

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

По жизни. Система должна отвечать требованиям. Т.о., модель требований первична. Если требования изменились, нет другого способа довести изменения до исполнителей, кроме, как изменить модель (если документы требований генерятся из модели). Или изменить документы. Но если изменить (написать) документы проще, чем изменить модель, на фига она вообще, эта модель?

Конечно, никаких замеров я не делал. Но результаты видел. Я уже говорил, что я иногда зарабатываю на хлеб тем, что помогаю внедрять технологию RUP. Я прихожу не с пустыми руками. И вижу производительность до и после.

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

Относительно солидности и проработанности. А разве аналитик имеет право представлять "не проработанные материалы". Тем более, когда вину свалить не на кого!

Спасибо, Эдуард, за содержательные вопросы.
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



3. Я ничего не ограничивал. В метамодели UML UC - это классификатор. Абстрактный классификатор не имеет собственных экземпляров. UCI и UCE не имеют собственных экземпляров: они выполняют экземпляры основного UC.
Почему выполняют? Встраиваются! Я все равно не понимаю в чем абстрактность? Пусть есть функция sin(x) (это примерно сильно утрирован), но почему я как актор не могу использовать функцию напрямую, если она к примеру используется другим ВИ как включаемая функциональность?
Цитировать
4. Наверное, Коберн ввел понятие первичного Actor (цель которого реализует UC). Взаимодействие первичного Actor создает экземпляр UC. С UC могут взаимодействовать другие Actor, но они "помогают" (пример - клиент банкомата и процессинг). Т.о., ограничение относится только к первичному Actor. Вторичные могут "помогать", взаимодействуя с экземпляром основного UC в границах основного UC, UCI или UCE.
Т.е. Вы предлагаете избегать таких вариантов использования, которые для кого-то первичны, а для кого-то вторичны и между такими вариантами использования могут существовать отношения включения и расширения. Коберн вообще отрицает включенность и расширяемость, поскольку они проявляются только на графических диаграммах, а в тексте проблем включать или расширять у вас вообще не возникает.
Цитировать
2. ДД, на мой взгляд, удобнее и прагматичнее, т.к. просто нагляднее, особенно, если процесс достаточно "запутанный" (много логики). RUP вообще возможность использования ДП для этих целей не рассматривает!
Как Вы считаете обычному заказчику проще понять диаграмму или текст?
Цитировать
1. Простите, за других не говорю! Для меня - несколько причин.
    - Я никогда не сумел бы в голове построить схему сложного процесса с параллельными и альтернативными потоками и описать ее. Все равно стал бы  что-то рисовать и писать по рисунку
Мы о каких реализациях вариантов использования сейчас говорим? О бизнес-вариантах? Они не являются частью UML, хотя, вероятно, придуманы в RUP. Если о вариантах системного уровня, то правильно ли будет говорить, что сложность их проще передать через ДД. ВИ есть сборник сценариев, совокупность сценариев передаст нужную степень сложности в простой форме. Другой разговор, если есть формальные правила и способы прямой трансляции ДД в поведенческие инструменты программной реализации? То я за. Но мне думается ДД также далека от ООП, как обычная блок-схема.
Т.е. я не против рисовать или не рисовать - рисуй, пиши, делай все, что тебе кажется правильным и верным. Но если это определяется как правило, оно должно быть обоснованным
Цитировать
    - Я использую инструменты, которые позволяют рисовать и генерировать текст из модели в нужной мне форме
Т.е. причина в этом?
Цитировать
    - Я могу использовать MDA, в частности, преобразовать BUC в пакет функциональной области в модели UC, автоматизируемые действия ДД - в UC, а соответствующий раздел - в Actor (и т.п.) 
И как это аспект находит отражение в конструкции программы? Как он управляет архитектурой, т.е. реализацией конечного решения?

Цитировать
Наверное, теоретически возможно преобразовать описание UC на естественном языке в модель анализа. Трудно придется! А для моделей это не проблема, есть множество примеров. Если средство моделирования поддерживает MDA, в нем д.б. инструментарий для создания преобразований (так написано на сайте OMG).
Я возможно когда-то где-то что-то упустил, но не могли бы Вы указать литературу, ссылки, которые демонстрируют использования UCs в технологиях MDA.

Цитировать
Если говорить о MDA, то формально вопрос о необходимости поддержки моделей в актуальном состоянии не стоит. Сгенерировался неправильный код - ищи ошибку в модели или в модели/коде преобразования. Но фактически это скорее неблизкое будущее.
Ну, тогда это уже будет не MDA, а что-то синтетическое.

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

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

Цитировать
Спасибо, Эдуард, за содержательные вопросы.
"Этот рад помочь" (c)



Re: Повышение производительности аналитика Ответ #21 : 01 Августа 2011, 13:34:06
Дорогой Эдуард.

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

Например, относительно абстрактных UC.
В справочнике трех друзей "UML. 2-е издание, Питер, серия "Классика computer science" этому вопросу суммарно посвящено больше 30 страниц. С картинками.
Если абстрагироваться от деталей, об абстрактности классификатора можно судить с двух точек зрения: с точки зрения исполнения (например, UC не может быть конкретным, т.к. его не планируется использовать самостоятельно (нет GUI)) и по отношению к другим классификаторам (если между двумя UC установлено отношение includе, то один из UC (имспользуемый) является абстрактным в данном отношении).

Ну, а способ моделирования уже зависит от ситуации, личных предпочтений и т.д.
Я предпочитаю (следуя рекомендациям RUP) существенные общие части UC описывать и реализовывать как абстрактные и в модели хранить их отдельно. И на диаграммах UC показывать их отношения с основными UC как include, хотя, м.б., в рабочем потоке основного UC они выполняются по условию.
Существенную часть поведения конкретного UC, выполняемую по условию, я реализую как абстрактный EUC, и храню его вместе с основным. Если, в какой-то момент жизненного цикла разработки выясняется, что этот фрагмент можно выделить как общий многоразового использования, я перетаскиваю его к другим общим UC.
Никакого криминала я не вижу. Но такое разделение я считаю удобным. Ведь применение UC в проекте не ограничивается описанием функциональных требований.
"Не нравится - не ешь!" - как сказал Чингачгук, Когда Чапаев заявил, что ему не нравится Штирлиц.

Это относится и к другим моим советам.

Коберн и абстрактные UC.
Да я об этом и не говорю ничего! У Коберна и в UML UC вообще имеют разный смысл, но похожий, и мы можем применять идеи Коберна в моделировании на UML.
Выделение первичного Actor - одна из таких плодотворных идей. Но Actor по отношению к одному UC может быть первичным, а по отношению к другому - вторичным. Т.о. свойство "первичности" (primary) определяется для ассоциации.
Если на диаграмме UC представлен контекст конкретного UC (с добавляемыми включениями и расширениями, то есть только один первичный Actor, который выполняет свою цель (при этом порождается экземпляр UC, общий для всего контекста); UC включения и расширения могут взаимодействовать со вторичными Actor).
Я вижу в этом много преимуществ. Не нравится?

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

Относительно MDA.
"По странному совпадению" в 2004 году были опубликованы релизы MDA, UML2 и появилась первая версия RSA, инструмента, поддерживающего UML и имеющего средства реализации преобразований MDA. В приложении - одна из первых спецификаций MDA и моя старая статья на эту тему.

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

Не считайте меня "коммивояжером" от Rational. Это не так.
« Последнее редактирование: 01 Августа 2011, 13:35:56 от lnew »
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



Re: Повышение производительности аналитика Ответ #22 : 01 Августа 2011, 14:27:16
Спасибо, Леонид Борисович, за разъяснение



Re: Повышение производительности аналитика Ответ #23 : 13 Августа 2011, 22:28:16
Приглашаю прочитать четвертую статью выпуска (http://lnew.ucoz.ru/publ/opyt_modelirovanija_na_uml/povyshenie_proizvoditelnosti_analitika/povyshenie_proizvoditelnosti_analitika_04/6-1-0-28):
Некоторые соображения об изменении отношений моделирования и документирования после появления концепции MDA.
Как писать документ "Видение":
- Собственная технология автора моделирования причинно-следственных отношений проблем заинтересованных лиц
- Модель документа "Видение"
- Документ, сгенерированный из модели
« Последнее редактирование: 13 Августа 2011, 22:43:13 от lnew »
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



Re: Повышение производительности аналитика Ответ #24 : 20 Августа 2011, 13:28:09
Представляю 5-ю статью цикла:
http://lnew.ucoz.ru/publ/opyt_modelirovanija_na_uml/povyshenie_proizvoditelnosti_analitika/povyshenie_proizvoditelnosti_analitika_05/6-1-0-30.
Статья посвящена модели UC (как я использую бизнес-модель для создания модели прецедентов).
Не забудьте скачать приложение!

Заходите в гости!
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



Re: Повышение производительности аналитика Ответ #25 : 25 Августа 2011, 21:03:41
6-я статья:
http://lnew.ucoz.ru/publ/opyt_modelirovanija_na_uml/povyshenie_proizvoditelnosti_analitika/povyshenie_proizvoditelnosti_analitika_06/6-1-0-31

Тема очень модная на нашем форуме: "Как описывать UC".

Жду комментариев!
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



7-я (заключительная) статья цикла http://lnew.ucoz.ru/publ/opyt_modelirovanija_na_uml/povyshenie_proizvoditelnosti_analitika/povyshenie_proizvoditelnosti_analitika_07/6-1-0-32.

О моделировании интерфейса в модели анализа.

Спасибо всем, кто прочитал, и особенно тем, кто принял участие в обсуждении.
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19