631

Обсуждение статей / Re: Рекомендации по написанию спецификаций вариантов использования

« : 08 Июня 2009, 16:43:36 »

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

<конец цитаты>

Позволю себе внести поправку по основному потоку.
Несмотря на то, что в общем-то нет препятствий в использовании таймера как основного действующего лица, в данном конкретном случае его использование неудачно. Можно спросить у любого (!) бухгалтера (и гендиректора :о)), как он отнесся бы к автоматическому переводу денег по таймеру по какому-либо адресу, пусть даже по адресу Налогового управления. Наверняка бы обрадовался :о))
По-моему, правильнее было бы выполнять действия связанные с построением какой-нибудь отчетности.
И главное, в данном случае ДЕЙСТВИЕ ВЫПОЛНЯЕТ НЕ ТАЙМЕР (!), а система! Таймер лишь инициирует действие (!), более близким к делу было бы: пользователь выполняет действие путем выбора соответствующего пункта меню.

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

Далее, очень размыто определено предусловие, если всё-таки говорить о некоей системе, пусть и довольно абстрактной. Думаю, этот пункт стоит дополнить каким-то конкретным комментарием, например: концом налоговых периодов являются полночь 31 марта, полночь 30 июня, полночь 30 сентября, полночь 31 декабря.
Кстати, несмотря на то, что налоговый период соответствует кварталу, тем не менее концом ОТЧЕТНОГО периода является другая дата (если память мне не изменяет +1 месяц, в течение которого должны быть осуществлены все налоговые платежи и подана соответствующая отчетность)

Мелочевку типа "платеж приходит в банк на счет налогового управления" я уже не учитываю.
Чуть ранее тоже хотел внести поправку "система посылает налоговое управление" :о))

...читаю дальше...

P.S. IMHO изначально неудачная задача взята для примера. Пусть даже он демонстрирует всего лишь структуру описания прецедента. Ведь читатели будут воспринимать и содержание описания тоже и будут делать из прочитанного неправильные выводы.
Поэтому гораздо лучше и читабельнее было бы привести все примеры из связанных кусков одной задачи.

632

Проектирование / Re: Роль архитектора в различных методологиях: как лучше?

« : 08 Июня 2009, 12:01:06 »

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

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

И не забываем, что архитектура системы нужна не сама для себя, а для реализации системы, УДОВЛЕТВОРЯЮЩЕЙ ПРИНЯТЫМ (утвержденным, согласованным) ТРЕБОВАНИЯМ!

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

Вопрос "кто определяет" в приведенной трактовке спорный, все перечисленные лица скорее участвуют в процессе разработки требований к системе (не забываем, что требования к системе бывают разные, а не только функциональные)

Я работал по классической схеме Заказчик->Аналитик->Архитектор->Разработчик->...
Причем, Архитектор был как явный, когда писались Архитектурные Решения, так и неявный, когда эту роль играл наиболее опытный Разработчик и он делал наиболее сложные куски.

Правильно, Архитектор (как и другие участники) - это РОЛЬ! Способы реализации этой роли могут быть весьма разнообразны. Аналогично и по другим приведенным примерам...

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

P.S. Советую посмотреть на роль архитектора при строительстве зданий и т.п., что он делает и чего не делает. С программной индустрией очень схоже. Отличаются материалы и методы реализации :о)))

633

О Сайте и Форуме / Re: Как выявить способности к аналитической деятельности

« : 03 Июня 2009, 10:40:36 »

Устойчивость и терпение - главные ПВК аналитика 

лучше "усидчивость и внимательность"

Не нравится кубик - переделаем в мячик.

неее, достаточно ребра/углы чуть-чуть скруглить, а на гранях поставить точки от одной до шести :о))

634

Примеры / Re: Диаграмма последовательности

« : 03 Июня 2009, 10:37:03 »

Фактически она основательно проверила только диаграмму прецедентов, диаграммы взаимодействия для заказа билетов, диаграмму классов, ну и диаграммы компонентов и размещения.

а может так и надо?

ведь  этот перечень дает вполне конкретные ответы на вопросы:
 - что будет система делать в принципе
 - как будет работать ключевой компонент
 - какова структура данных
 - и как будет построена система

635

Теория моделирования и нотации / Re: Анализ методологий IDEF, UML, Aris

« : 30 Мая 2009, 11:20:42 »

Главное в вашем случае, связное объяснение: почему и для чего Вы использовали ту или иную модель? а не методологическая чистота.

А для этого надо подготовиться: сформулировать плюсы (и возможно минусы) используемых методов, разобраться в их назначении - внятно объяснить это комиссии

Например, сказать, что IDEF0 использовался для описания предметной области, ОО-методы - для проектирования приложения, а IDEF1X - для проектирования базы данных

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

636

Теория моделирования и нотации / Re: Анализ методологий IDEF, UML, Aris

« : 29 Мая 2009, 22:26:06 »

DFD (Data Flow Diagram) является одной из диаграмм в SADT, о чем можно узнать как из книжки МакГоверна или документации на BPWIN (или как там его сейчас - AllFusion). Безусловно, DFD по большому счету не относится к UML, но не является аналогом IDEF0, это просто другая диаграмма, предназначенная для других целей.

Продукт Visio - просто инструмент-рисовалка, но в нем реализовано столько всего...

В общем, учите матчасть :о))

637

Теория моделирования и нотации / Re: Анализ методологий IDEF, UML, Aris

« : 28 Мая 2009, 18:58:53 »

Используя нестандартные термины (в данном случае - "методы"), Вы только еще более и себя и других запутываете. Это, кстати, к разговору о пользе глоссариев (где-то рядом была тема).

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

P.S. Но всё-таки настоятельно советую ознакомиться с уже имеющимися сравнениями.

638

Системный Анализ и Требования / Re: Как выявить способности к аналитической деятельности

« : 27 Мая 2009, 18:39:14 »

А вот еще попалась такая задачка:

из детской энциклопедии

сказать ответ?

639

MDA / Re: UML в качестве редактора универсального браузера

« : 26 Мая 2009, 19:36:43 »

от себя могу сказать, что в начале девяностых (боже как давно и недавно всё это было) участвовал в разработке подобной системы (описанной в исходном посте), и более того "система" у нас была готовая и работающая, что несколько отличается от термина "прототип", а в кавычках потому как не внедренная - так уж получилось...
тогда правда технологии были другие, сейчас многое можно даже назвать смешным, но как минимум уровни базы данных, обработки и презентейшн левел были разделены. Если говорить кратко, то уровни БД и интерфейса были проработаны до состояния компонентов. Оставалось "запроектировать" уровень обработки, т.е. решить нужную задачу в терминах предметной области. По сути в основе лежала формализованная модель, корректность которой проверялась стандартным компилятором. Фактически, при этом программирование переводилось с системного на прикладной уровень - не надо было программировать БД и уровень представления, достаточно было корректно определить объекты предметной области и их связи, и засунуть полученное описание (она же модель) в обработчик. А от задания их поведения куда ж денешься?

Сама система планировалась для автоматизации банковской деятельности и была реализована менее чем за 1 месяц (прикладная часть разумеется). Базовый софт потребовал где-то до 6 месяцев (за счет использования интерфейсных наработок ТурбоВижн), при практически готовой постановке. Команда была 4 человека, из них 2 прикладника, да два программиста.
Переносимостью особой, правда, эта штука не обладала, но используемый подход, кстати, позволил относительно просто мигрировать на платформу windows (ибо интерфейс был событийно управляемый и использовал близкие к стандартным компоненты), что для дос-приложений было невсегда просто. А чем дальше, тем больше появлялось программ и систем, использующих какие-то из воплощенных нами принципов. По состоянию на сейчас дело, ясное дело, заглохло.

Причем однажды мы этот конплехт показывали на выставке (да после того, как я ушел, показывали). И даже известные на тот момент деятели информационных технологий обратили внимание. С одним из них даже состоялась дискуссия на тему "Ах как хорошо, что программировать не надо!" По окончании дискуссии, когда было продемонстрировано создание простенькой, но работающей системки (типа приведенной выше обработки заказа) за 1 час параллельно неспешной беседе. Был сделан вывод: все-таки программировать надо, причем нужен специалист в двух разных областях: в предметной и в разработке (где-то здесь я это уже писал)

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

Так к чему это я?
1) Не надо изобретать велосипед. Многое уже придумано и реализовано. Хотя...
2) Нужно хорошо прорабатывать интерфейсы (есть даже такие специальные слова: SOAP и иже с ними)
3) Нужно по максимуму использовать стандартные, т.е. готовые компоненты.
4) Уровень программирования (в том или другом виде) никуда не девается, но может видоизменяться и сильно упрощаться. При этом желательно добавление специализации в предметной области

А вообще нужно в первую очередь решать задачу и не увлекаться чрезмерно созданием инструмента (если конечно не он сам является продуктом.

P.S. Про фастбейс ничего сказать не могу, но с задачей генерации кода сталкивался неоднократно. Без напильника там не обойтись, взять тот же дельфи. А ввод значений в окошки свойств по сути мало отличается от текстового редактора, но это уже лирика

640

Сообщество Аналитиков / Re: Порекомендуйте интересные сайты и блоги

« : 26 Мая 2009, 13:13:26 »

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

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

по-второму. видел. примеры есть http://www.i-teco.ru/terms.pdf , а также статья на эту тематику http://www.i-teco.ru/cio122007.pdf , также см. http://www.itsmforum.ru/ZAM-test
:о))

641

Теория моделирования и нотации / Re: Анализ методологий IDEF, UML, Aris

« : 26 Мая 2009, 12:59:41 »

Если посмотреть на первоисточник (Шеер. Бизнес-процессы. Основные понятия. Теория. Методы), то прочитаем следующее:
Функциональные модели. Процессы, преобразующие вход в выход, группируются в функциональную модель. Обозначения «функция», «процесс» и «операция» употребляются как синонимы. В связи с тем, что функции тесно связаны с целями, поскольку они направлены на их достижение и подчиняются их управлению, цели также относят к функциональным моделям. В прикладных системах (ПС) описываются правила компьютерной обработки функции. Таким образом, ПС адекватно подходит под определение «функций» и также относится к функциональной модели.
Организационные модели. Класс организационных моделей служит для описания иерархической структуры организации. В организационных моделях группируются субъекты ответственности и средства, выполняющие работу над одним и тем же объектом Именно поэтому сущность «человеческий ресурс», а также средства «финансовые ресурсы» и «компьютерная техника» относятся к организационной модели
Модель данных. Модели данных описывают информационный контекст (среду обработки данных), а также сообщения, активизирующие функции или активизируемые ими. С именами данных можно также связать предварительные детали, касающиеся функции информационных систем как носителей данных. В моделях данных неявным образом фиксируются также объекты в виде информационных услуг. Однако в основном такие объекты описываются в моделях выходов.
Модели выходов. Модели выходов содержат все физические и нефизические входы и выходы, включая потоки денежных средств
Модели управления / модели процесса. В этих моделях соответствующие классы моделируются с учетом их внутренних взаимоотношений. Представление отношений между отдельными моделями, так же как и в рамках всего бизнес-процесса, в виде управляющих моделей (или моделей процесса) позволяет постоянно отслеживать все двусторонние отношения между моделями различных типов, а также полностью описать процесс.

Сравниваю только нотации, описания процессов.

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

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

642

Теория моделирования и нотации / Re: Анализ методологий IDEF, UML, Aris

« : 25 Мая 2009, 17:22:33 »

Вы разрабатываете свою систему управления проектами САПР как я понимаю. Ну что ж поздравляю!

присоединюсь к поздравлению!

Всё уже придумано до нас. Существует масса и довольно большая продуктов реализующий subj (выделено): отошлю по адресу http://plmpedia.ru/wiki/Категория:Поставщики_и_продукты

Хотя на практике оказалось, что управление проектами САПР принципиально ничем не отличается от управления проектами, например, разработки софта. Единственным отличием с определенной натяжкой можно признать специальные средства для работы с данными, представленными в специальных форматах, т.е. собственно САПР-программы, которые работают с САПР-моделями и данными. Но и на этот случай уже много чего придумано - есть PDM-системы (смотреть ту же ссылку).

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

P.S. кстати, не надо путать продукт ARIS-Toolset (кстати не только он входит в состав продукта ARIS) с методологией, которая лежит в его основе: ARIS (архитектура интегрированных информационных систем) и ABI (архитектура бизнес инжиниринга)

А можно ли сравнить между собой ARIS, BPMN и ... UML ? В контексте применения к описанию бизнес-процессов...
Правильно ли, что я ставлю акцент на нотации описания Б-П? в UML использовать  Sequence Diagram и Activity Diagram, в ARIS все четыре вида диаграмм, ну и BPMN полностью ?

непонятен-таки предмет сравнения: бизнес-процессы и вообще процессная модель - есть способ реализации более высокоуровневой архитектуры, относящейся к бизнесу (в широком смысле).

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

643

Работа / Re: Рекомендательное письмо. Что написать?

« : 21 Мая 2009, 17:29:05 »

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

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

P.S. А вообще всё это (и рекомендации, и примеры) есть на работных сайтах.

644

Обучение / Re: [Статья] Строим систему дистанционного обучения

« : 19 Мая 2009, 14:43:04 »

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

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

645

О Сайте и Форуме / Re: Сменился дизайн сайта

« : 19 Мая 2009, 14:36:13 »

типично водолейское

таки задевает...

у каждого из нас есть уникальный опыт

поделитесь своим