1981

Системный Анализ и Требования / Re: комиксы как инструмент иллюстрации требований?

« : 02 Июня 2007, 22:53:11 »

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

Я же пишу - типичные артефакты не задают контекста использования. Из скриншотов не очевидны эргономические требования. Если человек работает с формой, тут у него заплакал ребёнок, он отошёл и вернулся через 15 минут, а система ему - говорит - "ваша сессия закончилась, введите данные заново", то такие исключительные ситуации гораздо проще выявить через механизм обыгрывания комиксов, чем через шаблон Use-Case.

1982

Консалтинг и Внедрение / Re: Консалтинг на практике

« : 02 Июня 2007, 19:39:08 »

Я стандартов по IT-инфраструктуре не смотрел, но скорее всего в вашем случае нужно очень хорошо знать, что такое и опираться в работе на ITIL.

Кстати, вот бесплатный тест по ITIL.

1983

Системный Анализ и Требования / Re: комиксы как инструмент иллюстрации требований?

« : 30 Мая 2007, 15:32:14 »

http://guicci.ru/2007/05/24/galya-masha-misha-dzho-elen-alina-betti-i-migel/

Возможно ли использовать такой подход не только для юзабилити исследований, но и как средство презентации требований для заказчика?

Позволит ли такой подход иногда  сэкономить на прототипах?

Или всё это слишком экзотично?

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

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

1984

Теория моделирования и нотации / Re: Теория и принципы моделирования

« : 29 Мая 2007, 13:58:15 »

Средства моделирования, как инструменты, включают 1 и 2. Объять прагматику моделирования в форме некоторого OTC продукта вряд ли вообще возможно. Тем не менее без прагматики построение модели невозможно.

Да, теперь понял. Правда, объём прагматики определяется сложностью и гибкостью языка, объёмом пространства моделирования. Если язык моделирования очень узок (например, Тетрис), то объём прагматики стремится к нулю.

Если говорить про UML, то его прагматика описывается в RUP и различной литературе, например у тех же Рамбо-Блаха и в материалах по образцам моделирования. Если говорить про ARIS как методологию, то его прагматика также излагается в соотв. литературе Шеера и прочих Логик Бизнеса.

Если возвращаться к теме дискуссии, то можно поставить вопрос так - позволяют ли Синтаксис, Семантика и Прагматика популярных методик моделирования в достаточной степени описывать существующие и создаваемые системы? Вредит ли избыточная детализация моделей? Если да, то как её избежать?

1985

Идеи и мозговой штурм / Re: Настоящий PIM/FIM/TIM

« : 29 Мая 2007, 13:14:21 »

Исследование TKM-систем

1986

Теория моделирования и нотации / Re: Теория и принципы моделирования

« : 29 Мая 2007, 12:40:57 »

Стоп, Ден, давай сначал определимся что такое классический подход 4 + 1. Подход типа RUP? Возможно я изнаю этот подход, но, вероятно, не под именем 4+1.

Я имел в виду The 4+1 View Model of Architecture, хотя наверное не совсем прав, т.к. этот подход говорит об описании только архитектуры, а не всей системы, а Эмерджентность присуща системам, а не их архитектуре.

Все средства моделирования типа UML IDEF ARIS - это описательные системы моделирования, знаковые, языковые, символьные - это не все виды моделирования - а довольно узкая его часть.

Хорошо, узкая. А какая ещё часть есть?

1987

Теория моделирования и нотации / Re: Теория и принципы моделирования

« : 28 Мая 2007, 23:33:45 »

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

Почему именно "механицизм", цитирую:

...В более широком смысле механицизм есть метод «сведения» сложных явлений к их более простым составляющим, метод разложения целого на части, неспецифичные для данного целого (на биологические отношения, когда речь идёт о социальных явлениях, на физико-химические, когда речь идёт о биологии, и т. д.)...

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

Именно это, имхо, и делают методологи моделирования Буч и Шеер - предлагают описывать целое как набор частей, не более.

То, что набор разноаспектных моделей далеко не всегда достоверно описывают систему, достаточно хорошо демонстрирует притча про 6-терых мудрецов и слона.

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

Эд, скажи честно - где эмерджентность в классическом подходе 4+1?

1988

Теория моделирования и нотации / Re: Теория и принципы моделирования

« : 28 Мая 2007, 22:52:27 »

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

А, ну так бы и говорили, что хотите обсудить правило максимальной адекватности модели моделируемому объекту.

Норберту Винеру приписывают слова, что "лучшей моделью кота является кот, а ещё лучше - тот самый кот".

Мне кажется, что всё-таки важно различать контекст моделирования как научного метода, и как промышленного метода.

В науке, как мы видим, систематически происходило уточнение моделей (Птолемей -> Коперник, Ньютон -> Эйнтшейна), которое сопровождалось новыми возможностями по использованию этих уточнённых моделей.

В науке правит бал беспредельное и чистое познание, не знающее преград. Цель учёного - создать как можно более точную модель, чтобы выявить новые, ранее не известные свойства объекта моделирования. Учёный ищет максимально точные, лучшие решения.

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

В механистических, редукционистских индустриальных подходах, таких как UML/ARIS/whatever... до последнего времени считалось, что если мы моделируем дискретную и/или реактивную систему, как это бывает в большей части современного типового бизнеса и соотв. ИС, то мы можем брать отдельные представления модели, такие как модель оргструктуры, модель бизнес-процессов, модель состояний и т.д.  и они будут в достаточной мере адекватности отражать моделируемую систему.

Холистические, системные подходы же говорят, что важны не только отдельные проекции, но и эмерджентные свойства системы, такие как "социальный капитал", "душа компании" и т.д.

1989

Идеи и мозговой штурм / Re: Поделитесь своими визитками?

« : 28 Мая 2007, 12:29:15 »

Денис, мне кажется, это больше вопрос к дизайнерам должен быть, а не к коллегам. Или вы предпочитаете продукты собственного приготовления? Тогда попробуйте сформулировать своими словами то, что ВЫ считаете сутью своей работы, т.к. IT вообще - это множество контекстов и целей. От слов (концепции) можно будет перейти к придумыванию образа. Если образ есть сразу - прекрасно.

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

У коллег удачных и выразительных визиток не видел.

Может, просто так:

ФИО

Решаю проблемы

Контакты

? )

1990

Теория моделирования и нотации / Re: Теория и принципы моделирования

« : 27 Мая 2007, 23:30:30 »

Сильно. И в чём состоит тезис? "это всё неправильно"? Так мы слона не продадим.

Может стоит тему поуже сформулировать, а не замахиваться сразу на "Уильяма нашего, на Шекспира"? )

1991

Идеи и мозговой штурм / Настоящий PIM/FIM/TIM

« : 27 Мая 2007, 22:01:48 »

Было бы здорово, если бы существовал софт, по настоящему реализующий идею Personal Information Manager, Family Information Manager, Team Information Manager.

Мои потребности относительно PIM:

• Записывать, какую книгу/фильм/место я планирую посетить/читаю/прочитал/посмотрел, каковы мои впечатления.
• Записывать свои траты и покупки, денежные поступления, планировать и получать информацию о плановых тратах, с возможностью анализа.
• Записывать совершённые и планируемые встречи с людьми, их контактную информацию.
• Организовывать взаимосвязанное хранилище документов - счета, статьи, книги, рецепты и т.д.

Ещё идеи?

1992

Вакансии / МСК - Архитектор ПО и интеграции

« : 25 Мая 2007, 06:15:16 »

В связи с моим уходом в аналитики нужен человек на моё место:

Архитектор ПО и интеграции

Разработка новых локальных и интеграция существующих корпоративных информационных систем группы компаний "ЛУКОЙЛ"

Требования
• Опыт ОО-разработки от 5 лет (C#, Java)
• Опыт документирования информационных систем на UML
• Знакомство с дисциплинами Управление требованиями, Анализ и Проектирование по RUP
• Опыт практического применения одного из подходов: EAI, MDD/MDA, EDA, SOA
• Опыт практического применения архитектурных, конструкционных и интеграционных шаблонов
• Знание особенностей ИС классов: OLTP, DocFlow, ERP, OLAP/Reporting, Portal, GIS

Функции
• Согласование функциональных требований
• Выявление и управление нефункциональными требованиями
• Проектирование архитектуры информационных систем
• Разработка интеграционных решений
• Описание архитектуры существующих систем
• Взаимодействие с и контроль работы подрядчиков
• Экспертиза проектной документации организаций-исполнителей
• Участие в планировании работ по проектам

Условия
• Офис в центре Москвы
• Белая зарплата на уровне рынка + премии
• Соцпакет (мед страховка)

Рекомендации, резюме и вопросы можно слать на soft-arch <> beskov.ru

1993

Бизнес-анализ и Целеполагание / Re: Шаблон концепции системы автоматизации

« : 25 Мая 2007, 00:10:14 »

Несколько мыслей - во-первых, таковая концепция должна опираться как минимум на словарь терминов, а лучше - и на бизнес-модель. Т.к. каждая цель/задача пользователя и сооти процесс должны не висеть в воздухе, а быть частью какой-либо бизнес-деятельности.

во-вторых, имхо стоит явно разделить интересы Заинтересованных лиц ВНЕ системы, с точки зрения на неё как ПОЛНОСТЬЮ ЧЁРНЫЙ ЯЩИК, и задачи пользователей ВНУТРИ системы, и связанные с этими задачами цели и функции системы.

Вообще, типичный сценарий работы с заказчиком выглядит так:
1. Для начала работ над проектом нужна концепция - Хм, ну я же вам объяснил насчёт того, что нужна система как у конкурента А, только штоб интерфейс поживее.
2. Нет, нужно расписать проблемы и ключевые требования - Ок, вот у нас тут Леночка написала чего-то (1 неделя).
3. Но тут нет x, y, z, которые крайне важны для успеха проекта - Ну так скажите, что там должно быть!
4. Вот вам шаблон - Ок, мы заполнили, смотрите (через 2 недели)
5. Но тут вещи x, y, z написаны неправильно - Ок, а как правильно? Может у вас есть образец?
6. Правильно вот так, вот так и вот так, держите образец - Ок, вот заполнили по образцу (ещё 1 неделя)
7. Теперь лучше, но возникает ряд вопросов... (собственно, пошла работа).

Не знаю, имхо лучше всего сразу устраивать совместную рабочую сессию на полдня, как у Лефингвелла, самому с их слов заполнять правильным образом документы, чем бодаться с шаблонами. Хотя конечно при первичном обращении, когда ещё не понятно, стоит ли работать с заказчиком, альтернативы анкете нет.

Ещё возникла идея насчёт универсальной цели системы - "обеспечить выполнение интересов заинтересованных лиц", всё

1994

Сообщество Аналитиков / Re: Компетенции аналитика (профессиональные и личностные)

« : 24 Мая 2007, 19:56:53 »

Чтобы поддержать тему, выкладываю черновик профстандарта профессии "Системный аналитик", разрабатываемого сейчас Комитетом по образованию в области ИТ Ассоциации Предприятий Компьютерных и Информационных Технологий.

Вот отзывы коллег, с которыми я полностью согласен:

Удивило, что до четвёртого квалификационного уровня предлагается расти два года. Маловато. Просто достаточное количество проектов в этот срок не укладывается. А из "проектов полного цикла" -- хорошо, если два влезут.

Не встречала живьём представителей пятого уровня. Обычно они всё-таки уже не аналитики, а архитекторы.

Колонка "Основные знания" показалась заполненной случайным образом.

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

Хороший термин - андрогогика. Кто-нибудь знает, что за зверь - "основы системного анализа"?

1995

Сообщество Аналитиков / Re: Компетенции аналитика (профессиональные и личностные)

« : 24 Мая 2007, 18:49:38 »

Относительно этого документа имхо стоит сказать, что они выделяют 3 области деятельности (модели):
* Business Analysis Model
* Quality Assurance Model
* Usability Engineering
т.е. опять имеет место семантическое передёргивание, т.к. последние 2 дисцплины/сферы совершенно точно никоим боком не входят в понятие "бизнес-анализ"; то, что IIBA понимает под BA (а именно, требования) - тоже.