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

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Denis Beskov

2206
Я бы предложил не создавать пустые папки в хранилище - как будет книга, материал - тогда уже создавать.

Сейчас в разделе "1. Методологии" смешаны методологии организации процесса разработки (RUP, XP, etc) и методологии отдельной его дисциплины - проектирования, причём первые почему-то названы методологиями проектирования. Возможно, это имеет отношение к ведущейся где-то тут дискуссии о смысле и понимании слова "проектирование". Кроме того, здесь же находится раздел, по дисциплине, методологии вообще не имеющей - а именно, сбору требований. Есть отдельные методы сбора, выявления, фиксации, организации и управления требований, методологии - нет.

Раздел "проектирование" имеет разделения по версии UML - не понимаю, какую практическую пользу это несёт. Имхо надо разделять по группам деятельности, по задачам.

А именно, чётко выделить 3 ключевые, в смысле системного анализа в ИС, дисциплины, которые активно применяют UML и не только, а именно:
А. Бизнес-Моделирование
Б. Требования
В. Проектирование

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

2207
"Эксперимент - совокупность действий исследователя, осуществляемая посредством материальных средств исследования с целью получения новой информации об изучаемом объекте (процессе, явлении) путем построения информационных (описательных) моделей, характеризующих различные его стороны и проявления"
Мне всё-таки кажется что основное отличие эксперимента от наблюдения - наличие предварительной гипотезы, которая проверяется в ходе эксперимента.

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

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

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

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

2208
Более подробное исследование проблемы

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

2209
Существующие подходы и их проблемы

  • Аннотация, оглавление и беглый просмотр содержания не дают достоверного представления о полезности книги, к тому же не всегда есть возможность ознакомиться с ними.
  • Традиционные массовые подходы к рекомендациям книг не учитывает многоаспектность качества книги. Многие сводные рейтинги анонимны, т.е. представляют собой усреднённую интегральную оценку множества читателей с неизвестными целями, интересами и квалификацией. Эта оценка очень мало говорит о полезности книги для конкретного читателя.
  • Другой подход - составление персональных списков рекомендаций. Проблемы схожие - чтобы оценить адекватность рекомендаций для себя, надо ознакомиться с личностью рекомендателя, чтобы понять схожесть задач, уровень профессиональной зрелости.
  • BOKи - их есть, но мало (PMBOK, SWEBOK, BABOK), причём не каждый имеет ссылки на литературу, переведены частично.

2210
Отбор литературы для чтения

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

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

Если посмотреть на кривую эффективности чтения литературы при увеличении количества книг, мы увидим, что после зоны роста наступает зона падения.

Это падение эффективности обусловлено:
  • Количество идей, техник и т.д. ограничено, а интерпретаций много - многие книги излагают сходные интерпретации
  • Ряд идей не представляет ценности для читающего
  • Ряд идей представляет собой тупиковые ветви развития.

Таким образом, для эффективного решения профессиональных задач нет необходимости читать всю доступную литературу, достаточно "брать лучшее" - не все книги одинаково полезны. Но как убедиться в том, что читаешь "правильную" часть?

Потребности специалиста:
  • Отобрать для чтения книги, обладающие наибольшей степенью полезности.

Доступность

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

Минимизация времени на чтение и отделение существенного от второстепенного

Потребности специалиста:
  • Получить квинтэссенцию знания, представленного в книге с возможностью его уточнения в дальнейшем.

Бизнес-проблема: Нужна эффективная система рекомендаций и конспектирования профессиональной литературы

2211
Извините, может быть надо было куда-то в другое место писать - если так - перенесите куда надо :)

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

Можно на конкретных примерах пояснить?
Буду очень благодарен.
Спасибо.
В подходе BCE (Boundary-Controller-Entity):

Entity (Класс-сущность) - отвечает за хранение информации по объекту-сущности, например такому, как "Заказ" и содержит методы, соответствующие его бизнес-логике, типа добавить строку заказа, завершить заказ и т.д.

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

Controller (управляющий класс) - отвечает за передачу запросов от Boundary нужным классам Entity и возвращает ему результаты. Грубо говоря, Контроллер заказа "дёргает" методы Заказа, и получив ответ, обновляет Окно (+ может делать множество других операций,  связанных с другими сущностями ПрОбл и Приложения, типа логирования). Т.е. он отвечает в том числе за Логику Приложения (в отличие от Бизнес-Логики), если нет отдельного слоя Логики Приложений, например, отсечённого от Контроллера Сервисным слоем.

В настольном приложении все классы реализуются в компоненты, находящиеся на данной машине. В клиент-серверных приложениях если клиент толстый, то B и C находится на клиенте, а E - скорее всего на сервере. Если клиент тонкий, то в принципе вся связка BCE находится на серверной стороне, причём эти классы могут быть распределены по разным физическим серверам (по крайней мере BC отдельно от E).

Вот ещё примерчик для неоконного приложения, в котором граничными классами выступают устройства чтения карты и клавиатура.

Подробнее об этом можно почитать, например, у Мацящека.

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

2212
Всё-таки я не понял, Эдуард, вы знакомы или нет вот с этими материалами?

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

Во-вторых, моя фраза обусловлена тем, что Эдуард сказал насчёт Интуитовских курсов в теме про онлайновые курсы - я так понял, что он достаточно хорошо знаком с ними, к тому же учитывая, что конкретно по теме СисАн из 100 представленных там курсов есть только 4-5, причём конкретно "Проектирование ИС" висит там года 2 + он к тому же как учебник рекомендован вузам. И мне кажется логичным, что прежде чем изобретать велосипед, человек с системным подходом всё-таки находит время, чтобы наточить пилу, прежде чем пилить, а именно - формулирует задачу, ищет аналоги, анализирует их и адаптирует их или создаёт своё, чёткое понимая, чем его не устраивает существующее.

2213
...
http://www.intuit.ru/department/se/devis/4/
...

Цитата из приведенного материала:
...

Комментарий: Насколько корректно связывать Data Flow диаграммы и юзкейсы?! Что-то не понимаю я автора (несмотря на ВМиК и прочия) ...
По приведённой мной ссылке (Лекция 4) я подобных фраз не нашёл. Вообще я рекомендовал этот материал Эдуарду потому, что ему близка SADT-методология, которую достаточно подробно освещает Грекул (Лекции 6-10) + дан, на мой взгляд, хороший материал по Орг моделированию (Лекции 1-5), подобно которому я ничего не встречал. Те цитаты, которые приводите Вы, похоже, из последних лекций (11-12), посвящённых UML, в котором возможно Грекул не имеет такого обширного опыта, как в SADT. Я не вижу ничего дурного в том, что человек знает что-то лучше, что-то хуже, как говорил тут Александр - нет гуру в своём отечестве.

Цитировать
Далее цитата:
"Например, формулировки "система должна использовать СУБД Oracle для хранения данных", "нужно, чтобы при вводе неверных данных раздавался звуковой сигнал" не очень хорошо описывают потребности. Исключением в первом случае может быть особая ситуация, например, если СУБД Oracle уже используется для хранения других данных ... Соответствующие потребности лучше описать так: "нужно организовать надежное и удобное для интеграции с другими системами хранение данных", "необходимо предотвращать попадание некорректных данных в хранилище".
Комментарий: насколько надежное? и удобное ЭТО КАК ? ЗАЧЕМ приводить ТАКИЕ примеры? ... (вообще-то, если мне не изменяет память, это списано у Соммервиля, и его уже критиковали за это :-).)
Во-первых, коим образом это относится с бизнес-процессам? Во-вторых, сколько я помню, именно в такой форме Потребности и описываются, даже у мажоров требований типа Вигерса-Лефингвелла-Коберна, т.к. "насколько надёжно" - это не уровень потребностей, а уровень требований к системе, определяемый совместно архитектором и аналитиком. См. мою таблицу уровней требований. Какие точные требования к атрибутам качества может предъявлять Заказчик??? Это скорее исключение, чем правило.

Цитировать
Эти лекции -- в основном компиляция из литературных источников.
А что плохого в том, чтобы взять всё лучше, скомпилировать и переработать? Аутентичность текста - насколько важная ценность в контексте задачи накопления и передачи знаний?

Цитировать
P.S. Интереcно, почему говоря о бизнес-процессах и вообще о бизнес-анализе, не рассмтриваете тот же Guide to the Business Analysis Body of Knowledge? Интересно было бы послушать высказывания на этот BOK.
Посмотрев на их драфт 1.6 меня уже одно то смущает, что у них там ни одной диаграммы - хороши мастера представления знаний.

2214
...
2. Приведенные вами ссылки учебных курсов затрагиваю теорию, а не практику - две совсем разные вещи
Э-э, а я как-то на название предмета ориентировался. Не надо было?

2215
Денису!
Ну хорошо с целями определились.
Сразу вопросы:
- 4 балла из скольки?
- Ты представляешь себе объем работы по составлению тестов с учетом приведенного перечня навыков?
- Ты представляешь, как перечень навыков впихнуть в 1 семестр?
- Как организовать надежный механизм признания работодателем навыков студентов?

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

2216
Тут на днях брал в книжном магазине полистать учебник по "Теории информационных процессов и систем" - так вот там сплошные формулы, векторы и матрицы. Вы уверены, что SADT - это то, чем надо кормить наших студентов?

Ну т.е. даже если брать банально в лоб информ. процессы - хранение, представление, передача, обработка (преобразование), удаление, сбор, поиск - то SADT тут вообще непричём, впору половину семестра читать Теории передачи информации и т.д.

Если смотреть ГОС 654700, то там после курса ТИПиС ещё отдельно будут "Моделирование Система" и "Проектирование ИС", вот там SADT, ARIS и UML уместны.

А в ТИПиС мне кажется надо смотреть ближе к этому.

2217
Что-то я не очень понял, почему беседа потекла в такое русло.

Имхо, методика преподавания - это прежде всего КАК учить, исходя из того, ЧЕМУ учить.

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

Говоря о типичных осязаемых бизнес-процессах, хочу привести пример работы кассира - в читаемой мной сейчас книге Лармана "Applying UML and Patterns" в качестве сквозного примера выбрана POS-система. Как раз с точки зрения бизнеса в книге всё очень плохо описано. Мне кажется, это гораздо более наглядный и доступный процесс, нежели доставка и хранение книг, которую редко кто наблюдает и сталкивается.

2218
На самом деле в основе бизнес-модели всегда лежат бизнес-цели предприятия, по большому счету полностью определяющие состав всех базовых компонентов бизнес-модели :
  • бизнес-функции, описывающие, ЧТО делает бизнес;
  • бизнес-процессы, описывающие, КАК предприятие выполняет свои бизнес-функции;
  • организационная структура, определяющая, ГДЕ исполняются бизнес-функции и бизнес-процессы;
  • фазы, определяющие, КОГДА (в какой последовательности) должны быть внедрены те или иные бизнес-функции;
  • роли, определяющие, КТО исполняет бизнес-процессы;
  • правила, определяющие связь между ЧТО, КАК, ГДЕ, КОГДА и КТО.
Странно, что в базовый набор не входит структурная модель предметной области бизнеса.

Всё-таки я не понял, Эдуард, вы знакомы или нет вот с этими материалами?
http://www.intuit.ru/department/se/devis/4/
http://www.intuit.ru/department/se/compprog/4/

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

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

Цитировать
Мне кажется в этом отношении показательна книга Нейбурга и Максимчука "Проектирование баз данных с помощью UML". К сожалению не нашел ее в электронном виде, даже на all-ebooks.com.
Что значит показательна? Почему бы вам просто не озвучить тезисы оттуда? У меня книга есть, но сейчас нет возможности лопатить 300 страниц.

2220
Сообщество Аналитиков / Re: Место встреч
« : 03 Января 2007, 21:01:10 »
2. Давайте без экзотики в виде "миров" ... лучше таки реальный мир :-)
Я предложил виртуальные миры, учитывая, что далеко не все участники обсуждения находятся в мск.