Форма входа

Поиск

Календарь

«  Январь 2011  »
ПнВтСрЧтПтСбВс
     12
3456789
10111213141516
17181920212223
24252627282930
31

Архив записей

Наш опрос

Интересны ли Вам статьи цикла "Повышение производительности аналитика"?
Всего ответов: 25

Друзья сайта

  • Официальный блог
  • Сообщество uCoz
  • FAQ по системе
  • Инструкции для uCoz
  • Статистика


    Онлайн всего: 1
    Гостей: 1
    Пользователей: 0
    Понедельник, 15.10.2018, 13:45
    Приветствую Вас Гость
    Главная | Регистрация | Вход | RSS

    Я - Аналитик!

    Блог

    Главная » 2011 » Январь » 21 » Нужно ли формально моделировать?
    22:51
    Нужно ли формально моделировать?
    В своем блоге на сайте UML2.ru (http://blogs.uml2.ru/post/Modelirovanie-arhitektury-predpriyatiya-yazyk-UPIA-karkasy#comments) я разместил свое обращение, подобное тому, которое представлено выше. Действительно ведь не вдохновляет, когда работаешь "на корзину".

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

    "Стоит ли писать?" Стоит! Большое спасибо!

    Первое утверждение: Никакой стандарт не гарантирует успеха. Успеха могут добиться только грамотные люди. (Увы, могут и не добиться!).

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

    Утверждение второе: Сегодня серьезный проект, если он не документирован (процесс разработки и целевая система), обречен на неудачу.

    Уже при группе в 5 человек недокументированная неуправляемая разработка превращается в хаос!

    Утверждение третье: Документирование - очень трудоемкая задача.

    Настолько трудоемкая, что ее просто не выполняют, что приводит к плачевным результатам: то, что сделали, не отвечает ожиданиям. Требуются доделки, переделки, тратятся время и деньги.

    Что пропагандируют эти циклы статей, публикуемые на сайте "Я - аналитик"?

    Главная цель - это не описание UPIA и TOGAF (хотя я считаю это важным).
    Я пытаюсь поделиться своим опытом выполнения "самодокументирующихся" проектов с использованием UML.

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

    Мой опыт, которым я делюсь на курсах по моделированию и при выполнении проектов по внедрению RUP, в общем, состоит в следующем:
    1. Все, что можно представить в виде модели, представляется в виде модели. Вы считаете, что документировать в виде текста быстрее? Если инструмент хороший, вряд ли!
    2. Каждый элемент документируется в момент создания (описание - одна фраза, редко - две). Вы думаете - это затраты времени? Нет! Когда вы создаете элемент (если Вы не перерисовываете с бумажки, а я верю, что это не так), Вы обдумываете роль элемента, связи и т.д. Время, затрачиваемое на ввод описания существенно меньше времени обдумывания роли элемента, особенно, если не "вылизывать" формулировки. А зачем их сейчас "вылизывать"? Увидим в контексте в общем документе - исправим, что надо (в модели, и перегенерируем).
    3. Генерируется нужный документ (отчет) из соответствующего шаблона.

    "Бесплатный сыр бывает только в мышеловке!".

    Трудозатраты есть, но другие, и существенно меньшего объема.
    Я использую инструменты IBM Rational. Для документирования модели, допустим, спецификации прецедента по RUP (очень похоже на описание по Коберну) нужны Rational Software Architect и Rational SoDA (или BIRT).
    Чтобы не переделывать шаблон SoDA для каждой спецификации, желательно определить стандартную структуру модели в организации: где что лежит. Думаю, это полезно не только для отчетов, особенно когда над моделью работают больше одного человека.
    Под структуру делается стандартный шаблон, который вставляет в отчет заголовки, элементы (названия, описания, атрибуты, описания атрибутов и т.д., все, что Вы хотите туда вставить), диаграммы деятельности. Этот шаблон Вы будете использовать для генерации всех спецификаций прецедентов, пока будет соблюдаться принятая структура модели.
    Вам нужно напечатать спецификацию? Берете шаблон, правите одну строчку (адрес прецедента в модели) и нажимаете Generate. Через некоторое время Вы получаете красивый документ Word, который не стыдно показать любому заказчику, а главное - тестеру и проектировщику! Но они и в модели посмотреть могут!

    Вернемся к формальному моделированию.

    Моделирование заинтересованных лиц позволяет сохранять информацию о них не в блокноте, не в Worde или Excele, а в модели. Ту же информацию, которую раньше сохраняли в голове. Какие тут ограничения? В моей модели нет нужных атрибутов для описанию нюансов? Добавьте атрибуты, и нет проблем! Изменились сами заинтересованные лица? Их не один, а три?
    Преимущества:
    1. (возможно, только для меня) Когда я их вижу на диаграмме, я вижу общую картину. Когда я "кликаю" по "человечку" - я рассматриваю и думаю о подробностях.
    2. На диаграмме можно установить связь Заинтересованного лице (класса или экземпляра) с модельными элементами, на которые он может оказать влияние; знание, для кого что делаем поможет в разработке.
    3. Документирование по стандартному шаблону.

    С моделированием стратегии предприятия все то же самое. Формально, при разработке ПО бизнес моделирование, а тем более - знание стратегии предприятия, считается не обязательным. Но если уж дело дошло до стратегии, то Вы все равно используете стандартные понятия Видения, Миссии и т.д. Можно все это описать в виде текста. Мне такой текст не написать: что-нибудь забуду. А в тех же терминах нарисовать на одной страничке, с детализацией некоторых элементов на других страничках - вполне доступно. В результате тот же текстовый документ, который напишете Вы. Только с картинками. Какие формальные ограничения?

    Другое дело, что я неправильно могу понять стратегию, которую рассказывает мне ЗЛ "Владелец бизнеса". Так тут никакое моделирование не поможет!!!

    Не верите? присылайте материалы, я Вам сделаю отчет (если не слишком много). Или, если хотите, свой (из существующих) пример подберу!
    Просмотров: 529 | Добавил: lnew | Рейтинг: 0.0/0
    Всего комментариев: 3
    3  
    Диаграмма плюс описания элементов - это хороший стиль, мне тоже нравится. А стандарты - безусловно нужны, тут я согласен. Просто в некоторый момент мы поняли, что излишняя подробность документа - она дает ложную уверенность, особенно потому что заказчик с некоторого объема документа перестает его скурпулезно читать и формально подходить. Поэтому пишем относительно свободные документы, а потом доводим в личном общении и реализуем (или делаем прототип) - а дальше фрагмент сам является документом. Вопрос в поиске оптимального баланса. Но мы понимаем, что не со всеми так можно, и с некоторыми нужны формальные документы. Обычно при этом требования к формату у такого заказчика есть, а нам остается исполнять...

    1  
    В целом - оно понятно и правильно. Есть нюансы. Модели - они не заменяют текст, потому что текст - он гибче для выражения определенных сложных конструкций, и поэтому они текстом представляются компактнее. Особенно это касается слабо определенных конструкций, где важны модальности достоверности - может быть, наверное и т.п. А есть класс вещей, где схемы, наоборот, являются компактным и эффективным представлением, и там их, безусловно. надо использовать. Но, кстати, они полностью не заменяют текст, например, диаграмма классов должны дополняться описанием каждого класса и не очевидных атрибутов и методов. При этом это описание может быть сохранено в атрибутах модели и порождено автоматически, это точно.

    Но есть еще один аспект. Любой формализм - требует изучения и понимания. И это должно быть оправдано. Для диаграмм классов так оно и есть, потому что классы - хорошо формализованы, за ними стоят реальные объекты языков программирования, формализм которых программисту известен. Таким образом, тут надо изучить лишь визуальный образ, а он того стоит - потому что представляет информацию наглядно и компактно. А вот для заинтересованных лиц - ситуация другая. Тут сам формализм представления надо изучать, а не только визуальный образ, и учиться представлять и воспринимать реальную ситуацию в этом формализме. Это эффективно только в условиях относительно большого потока проектов. Кроме того, в этой области очень важны нюансы и модальности. А еще - с самим формализмом тяжело. Тут уместна аналогия с RUP, где для точного описания в процессе выделено много десятков ролей, при этом в реальном проекте они хитро скомбинированы в некоторое количество реальных участников. Так вот, эффективнее описать роли конкретного проекта, а не отображать его на многочисленные эталонные роли.


    2  
    Согласен с тем, что есть документы и документы.
    Проектные документы, на мой взгляд, должны констатировать решения, которые должны интерпретироваться однозначно (if-ы могут быть в случаях неопределенных ситуаций, но внутри if-а снова должна быть однозначность).
    И есть документы концептуальные, научные статьи и т.д. Но они описывают не решения, а возможные пути и обоснования выбора. Но это уже другой (не проектный) случай.
    По такому документу группа не сможет создать продукт!

    Небольшое отступление:
    UML в Rational Software Architect имеет нестандартный стереотип для пакета (<<prspective>>). Этот пакет можно использовать для моделирования альтернативных вариантов чего угодно, а пакеты с этим стереотипом игнорируются при выполнении преобразований и, по умолчанию, генерации отчетов.

    Может быть, это мое индивидуальное восприятие, но мне кажется очень читабельным стиль, когда документ содержит диаграмму, а под диаграммой - тексты описаний элементов. Я начинал со спецификаций прецедентов. Получается тот же Коберн, только сдобренный диаграммами.

    И снова: критерий - "стоимость - эффективность". Если для каждого экземпляра документа "рисовать" свой шаблон - это никому не нужно. Но разработать в организации по одному шаблону для каждого типа документа - это вполне реально.

    И еще личное мнение: если в группе нет "стандартов" (правил, соглашений), ничего серьезного она сделать не сможет. ("Тексты" соглашений могут "храниться" и в мозгу!)


    Имя *:
    Email *:
    Код *: