331

IDEF ARIS BPMN и пр. / Re: IDEF0: Парадоксы "материального" баланса

« : 27 Декабря 2011, 15:47:40 »

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

332

Управление Проектом / Re: Планирование трудозатрат по написанию документации

« : 27 Декабря 2011, 15:43:40 »

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

Если хотите изучать самостоятельно, то готовьтесь примерно к году работы по изучению методов и калибровке ваших оценок.
Шаг 1. Достаете книгу "сколько стоит программный проект" Макконнела и читаете. Берете данные по распределению трудозатрат на проекте  из книги и начинаете считать. по мере накопления статистики калибруете оценки. Для оценки объема проекта в целом используйте Use Case Points.

333

UML SysML и пр. / Re: Как средствами UML описать протокол общение между сервером и клиентом

« : 27 Декабря 2011, 15:34:25 »

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

Что же касается описания XML- это важнейшая часть работы. Здесь есть несколько хитростей.
1. Будучи однажды опубликованным протокол не может быть изменен. Протокол наиболее неизменная часть системы. Собственно описание протокола и есть архитектура. Вы можете поменять структуру хранения данных, можете даже перейти на другую платформу (с перла на джаву), протокол должен оставаться неизменным. Но можно опубликовать новую версию. Поэтому сразу ведите версионность протокола и расписывайте очень тщательно.

2. существует множество способов описания структуры XML сообщения. Из машиночитаемых, пожалуй наиболее популярны xsd и dtd. Некоторыми нотациями я пользовался, но мне больше нравится человекочитаемые.
В конце концов, я остановился на варианте нотации из трех частей. Сначала структура без значений, потом таблица с описанием элементов, потом пример с комментариями.

Нужен пример... Я попробую найти что-нибудь.

334

Идеи и мозговой штурм / Re: Как сделать так, чтобы не замыливался глаз

« : 09 Декабря 2011, 11:50:23 »

Логические деревья Голдратта,
ведение статистических данных + проведение ретроспектив - пожалуй самый простой способ
Мышление на разных досках - метод разработанный группой Щедровицкого. Очень мощный, но и сложность у него огого.

335

Методологии / Re: Как вы думаете, к какой методологии или идее относятся десять высказываний ниже?

« : 09 Декабря 2011, 11:20:35 »

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

Agile - видимо имелась ввиду группа методологий, а не методология.
CMMI - вооще ни разу не методология, а стандарт. Так же как и ГОСТ. (с) Кэп.
PMBOK - как следует из названия тоже не методология.

Ох уж эти сказочки, ох уж эти сказочники...

336

Обучение / Re: Литература по анализу - а существует ли она?

« : 08 Ноября 2011, 16:29:30 »

Господа, список рекомендованной литературы - это неплохая вещь. Но в этом списке наиболее интересны не те книги, которые эксперт рекомендует, а те которые эксперт прочитал и признал негодными.
Я читал "Введение в UML" Фаулера  и не рекомендую эту книгу к изучению. Эта информация по настоящему ценна.
-- Часть моего списка с рекомендациями -----------

* Современные методы описания функциональных требований к системам   Алистер Коберн    учебник   Читал   Обязательно   Аналитикам
* Разработка требований к ПО   Карл Вигерс   учебник            Читал    Обязательно   Аналитикам
* Принципы работы с требованиями к программному обеспечению. Унифицированный подход   Дин Леффингуэлл, Дон Уидриг               В плане         

* Введение в UML   Фаулер   Сборник best practice            Читал      Можно, но не зацепило   Аналитикам
* It's matter (блеск и нищета информационных технологий)   Николас Карр               Читал      Топ и автоматизаторы
* Бизнес со скоростью мысли   Билл Гейтс               Читал      Не зацепило   
* Поиск решения   Балк, М.; Балк, Г.   задачник и решебник            Читал         
* ГОСТ 34.602      стандарт            Использую         Аналитикам
* ГОСТ 34.603      стандарт            Использую         Аналитикам
* Управленческие дилеммы   Эли Шрагенхайм   учебник            Читал    Нужно Бизнес аналитикам и Топ
* Теория ограничений Голдратта   Детмер   учебник            Ознакомился / в плане      ПМ, SEPG
* ГОСТ Р 50779.42-99 Контрольные карты Шухарта      стандарт            Ознакомился. В плане      Нужно   SEPG

337

Для всех / Re: современные проблемы системного анализа

« : 25 Октября 2011, 14:00:12 »

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

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

На этом принципе, между прочим, целая линейка Agile-методологий построена. И самое смешное, что этот подход работает.

С каких это пор Agile отказывается от тщательной разработки документации до кодирования?!?!
Это вас неправильные "консультанты" обманули.

338

Для всех / Re: современные проблемы системного анализа

« : 25 Октября 2011, 11:53:02 »

* Требования для задач предоставляются с опозданием
* Хромает управление требованиями. Скорее, отсутствует совсем.  А попытка разрабатывать требования до внедрения процесса управления приводит к ожидаемым результатам (lurkmore.ru/Конец_немного_предсказуем).
* Ревью требований - бессмысленная операция. Время отнимает а требования как были отстоем так и остаются.
* Написание требований - тоже бессмысленная операция. Если Ревью не выявляет ошибок в требованиях, то зачем нужен формальный документ? Рисуйте на салфетке. Или работайте в паре у доски.
* Зарплата аналитика не соответствует сложности работы.  Студент кодер часто получает больше матерого аналитика
* Ведущий программист не может прочитать юзкейс в нотации Коберна. Это норма.
* Ведущий аналитик не может написать юзкейс средней сложности в любой нотации. Это тоже норма.
* В требованиях практически никогда не описываются цели проекта. То что пишут в разделе цели формально и откровенное гуано. Внезапно (lurkmore.ru/Внезапно) это приводит к типичным результатам (lurkmore.ru/Фэйл)
* Нет никакого способа оценить качество требований не проводятся ревью и ретроспективы.
* Так как нет оценки качества, то нет и улучшения процесса. По крайней мере нет тому объективных свидетельств.
* Трассировка между требованиями  и кодом чаще всего  отсутствуют (в случае изменения требования нет возможности понять какие фрагменты системы будут затронуты)
-----------------------------------------------
Картина описанная Бруксом существенно лучше текущей реальности.

339

Термины и Определения / Re: Терминологическая база Бизнес Анализа (перевод BABOK Glossary)

« : 19 Октября 2011, 12:14:17 »

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

Во всех нормальных инструментах такого направления есть возможность использовать технологию "переиспользуемый контент". Попробуй ее найти.

PS. В дешевых/бесплатных, создаваемых "for fun" такой возможности, скорее всего не будет.

PSS. "копи-пэйст" не просто зло. Это очень большое зло. Особенно для текстов.

340

Для всех / а получили как всегда

« : 18 Октября 2011, 20:48:22 »

Картинка с качелями немного приелась, а тут такой шикарный пример расползания требований в процессе разработки:
http://img-fotki.yandex.ru/get/4710/32070366.1b/0_67d73_c8f3a7a5_orig

Утверждают, что это "Крокодил" за 1982 год.

341

Обсуждение статей / Re: В чем ценность ИТ для бизнеса?

« : 26 Сентября 2011, 12:09:25 »

Обсудим, обсудим.

Является ли деятельность ИТ отдела ключевой в компании? Если это касается ИТ-инфраструктуры, то ИТ отдел жизненно необходим. Без принтеров, почты и интернета сегодня встанет любая компания.

Без принтеров, почты и интернета работать некоторое время можно. А вот без электричества... Или еще интереснее без канализации. ;-)
Николас Карр в своей знаменитой " Блеск и нищета информационных технологий" наглядно показал, что IT перестает/перестала быть "ключевой", "обеспечивающей конкурентное преимущество" и т.д. технологией. И становится/стала просто инфраструктурной. Пример с отключением почты выглядит классным, но только до той поры, пока не задается вопрос: "А что будет, если отключить электроэнергию?"

Потому что считается, что программисты не в состоянии ни разговаривать с заказчиками, ни адекватно вести себя при переговорах.

Можно брать на переговоры не программиста, а разработчика.

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

а) Ровно тоже самое в других областях. В строительстве, например.
б) Ровно тоже самое в других областях. В строительстве, например.
в) Ровно тоже самое в других областях. В строительстве, например.

---------------------
И некоторые рекомендации по чтению. О том, что же именно может сделать ИТ для основного бизнеса и как это посчитать написано во многих книгах. Я рекомендую следующие:
Николас Карр  "Блеск и нищета информационных технологий"
Э. Голдратт "Цель-3"
А. Орлов "Записки автоматизатора"

342

Системный Анализ и Требования / Re: Бизнес-требования и бизнес-цели

« : 07 Сентября 2011, 12:43:50 »

6.Актуальность — требование не стало устаревшим с течением времени.
9.Обязательность — требование представляет собой определенную заинтересованным лицом характеристику, отсутствие которой ведет к неполноценности решения, которая не может быть проигнорирована. Необязательное требование — противоречие самому понятия требования.

Эти пункты я бы выкинул. Причины:
1) Это скорее "Управление требованиями". Другая дисциплина, другая классификация. Классификация методом смешения классификационных атрибутов: "Автомобили бывают легковые, зеленые и мерседесы" - меня не устраивает.
2) Обязательность — а с этим я сильно не согласен.

343

Обсуждение статей / Re: КС

« : 07 Сентября 2011, 12:35:40 »

Во многом согласен с автором, но я был бы еще категоричнее.

В роли аналитика я не так часто использую UML. Другие типы диаграмм для аналитика гораздо полезнее (EPS, ER, ДТР, СИВС, рыбий хвост, карты Шухарта,  ...). И уж конечно, гораздо важнее уметь писать внятный текст. Почему  свет клином сошелся на UML?

Т.е. на мой взгляд вместо статьи "КС ЗНАНИЕ UML КАК ФАКТОР ВЛИЯНИЯ НА КАРЬЕРУ И РАБОТУ С ЗАКАЗЧИКОМ" гораздо актуальнее была бы статья "Умение писать сочинения, ессе, рассказы как фактор влияния на карьеру и работу с заказчиком".

Не?

344

О Сайте и Форуме / Re: Лента внешних блогов аналитиков

« : 31 Августа 2011, 11:39:59 »

Мыло из открытого доступа уберите.

Хотя наверное уже поздно. Опять ящик менять....

345

Работа / Re: Кто где работает территориально?

« : 24 Августа 2011, 15:44:20 »

Мск, Владыкино