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

×


Темы для встречи в Москве(Прочитано 17574 раз)
Re: Темы для встречи в Москве Ответ #15 : 05 Марта 2013, 20:19:06
Напишите пожалуйста, какие вопросы и темы вас сейчас интересуют.

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

Метамоделирование по сути позволяет "сшить" вместе требования (предметную модель) и архитектуру ПО, которая формируется на основе метамодели. Если аналитик будет участвовать в проектировании системы (по сути выполнять часть роли архитектора), от этого выиграет качество ПО и сроки его разработки.

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

Тут немного расписано: http://habrahabr.ru/post/154891/.



Re: Темы для встречи в Москве Ответ #16 : 06 Марта 2013, 00:04:49
Интересует матамоделирование.
На мой взгляд, интересное направление для системных аналитиков. Позволяет глубже влезть на поле разработчика. Все-таки разрыв наблюдается. Аналитик разработали требования и отдал в черный ящик. Иногда после ящика выполняют "авторский надзор", по сути функциональное тестирование. Максимум, что имеем - увязку требований с кодом (трассировка).
Что происходит в черном ящике - священная тайна, что там тимлиды творят, только им известно ))).
и к каким последствиям это приводит?

Цитировать
Метамоделирование по сути позволяет "сшить" вместе требования (предметную модель)
Требования и предметная модель — это разве одно и тоже?

Цитировать
…и архитектуру ПО, которая формируется на основе метамодели. Если аналитик будет участвовать в проектировании системы (по сути выполнять часть роли архитектора), от этого выиграет качество ПО и сроки его разработки.
Насколько выиграет? Откуда информация об этом — у вас есть опыт или читали про чужой?

Цитировать
Большой эффект от метамоделирования можно достичь при разработке сложных приложений,
Это гипотеза или опыт?

Цитировать
например ERP, когда на одной платформе автоматизируется множество процессов, описываемых множеством предметных моделей. Загнав эти предметные модели в одну метамодель можем разработать логически связанную структуру большого ПО, а не как обычно, когда большая система состоит из множества подсистем, наслаиваемых в течении многих лет, и по сути являющихся интегрированными, но отдельными приложениями.
Чем это принципиально отличается от MDA (Model-Driven Architecture) и DDD (Domain Driven Design)?

«Можем разработать логически связанную структуру большого ПО» — за какое время? Откуда возьмётся информация для такой структуры? Как поддерживается процесс развития системы?

Вы с какой позиции рассуждаете — архитектора, аналитика, менеджера, заказчика, ИТ-директора?



Re: Темы для встречи в Москве Ответ #17 : 06 Марта 2013, 00:20:17
Изменение бизнес процессов.
Изменение ради изменения?



Re: Темы для встречи в Москве Ответ #18 : 06 Марта 2013, 10:52:36
и к каким последствиям это приводит?
Когда строится уникальное здание, архитектор осуществляет авторский контроль, т.к. конечная цель связки архитектор-строители является здание для заказчика.
Разве при разработке ПО не так же? Я, конечно, понимаю про тестирование, но неужели роль аналитика заканчивается на разработке требований? Кто в итоге отвечает за пиджак? Я понимаю про "отвечает за все руководитель проекта", но, на мой взгляд, аналитик должен участвовать в приемке приложения и возможно в функциональном тестировании и разработке документации.
 

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


Насколько выиграет? Откуда информация об этом — у вас есть опыт или читали про чужой?
К сожалению, по этой теме теории я читал мало. Потому и разместил сообщение в данной ветке. Да, опыт небольшой был, с коллегами год разрабатывали метамодель будущей системы, без строчки кода. С точки зрения проработки аналитики приложения, мы за этот год сделали больше, чем за предыдущие 9.
Лично для своего случая вижу два плюса: прочитав и поняв метамодель любой разработчик (и аналитик) понимает общую концепцию системы. Второй плюс - мы разрабатываем коробочный продукт для открытого рынка, т.е. заказчик конкретизируется после покупки и начала внедрения. При внедрении происходят различные "уточнения требований". Если изначально предметную модель зашить в коде, то "уточнение" практически невозможно. Поэтому при разработке приходится предполагать различные будущие изменения и разрабатывать настраиваемое ПО. Раньше делали все на интуиции, но почитав немного (к сожалению немного), я понял, что есть некие теоретические знания, которые могут помочь в этом. Насколько я понимаю, можно на основе нескольких предметных моделей (описанных и предполагаемых) построить метамодель, в которой эти модели легко реализовать при настройке у конкретного пользователя. 


Это гипотеза или опыт?
Имелся опыт (выше описал), но, к сожалению, не доведенный до конца по организационно-экономическим причинам.
Denis Beskov, я разделяю Ваш скепсис, который Вы высказывали в другой ветке. Действительно можно заиграться в метамоделирование и спроектировать "базу данных в 4-6 таблиц для всего и вся". На мой взгляд, в статье на хабре тоже перегнули палку (вроде речь про НИИ шла, тогда понятно), разрабатывая серии виртуальных машин под различные предметные области.


Чем это принципиально отличается от MDA (Model-Driven Architecture) и DDD (Domain Driven Design)?
Возможно ничем. Спасибо за наводку, буду читать. Почитал по диагонали, очень похоже.


«Можем разработать логически связанную структуру большого ПО» — за какое время? Откуда возьмётся информация для такой структуры?
Так про это и речь, если жизненный цикл разработки и развития ПО превышает 10 лет (условно говоря более 10 версий по 1 разу в год), то к десятому году что-либо внести в систему проблематично. Появляются куски кода, которые никто из существующих на данный период времени разработчиков не видел. Ситуация "в одном месте поправил, в других отвалилось" становится типичной.
 

Как поддерживается процесс развития системы?
Метамодель (возможно DDD и/или MDA) позволит при внесении изменений понять масштаб бедствия. Обычно такие знания находятся в голове разработчиков, заманчиво иметь хотя бы часть этих знаний "на бумаге". Соответственно, не забываем и про трассировку.

Вы с какой позиции рассуждаете — архитектора, аналитика, менеджера, заказчика, ИТ-директора?
Формально, с точки зрения аналитика. Но коллектив небольшой, роли размыты. Например, ранее часть структуры БД проектировал я, сейчас, правда, разработчики. Код я не пишу, и никогда не писал.
Хотя, на мой взгляд, вещь полезна для всех ролей разработчиков.



Re: Темы для встречи в Москве Ответ #19 : 06 Марта 2013, 11:49:38
Изменение ради изменения?
Естественно нет. Для уменьшения связанного капитала и увеличения прохода. И это то, зачем строится дерево текущей реальности.
Сергей Мартыненко
http://martyinenko-sergey1.moikrug.ru/



Re: Темы для встречи в Москве Ответ #20 : 06 Марта 2013, 11:51:43
Естественно нет. Для уменьшения связанного капитала и увеличения прохода. И это то, зачем строится дерево текущей реальности.
Отлично, а аналитикам это для чего может понадобиться?



Re: Темы для встречи в Москве Ответ #21 : 06 Марта 2013, 19:58:40
Интересует матамоделирование.
....
Тут немного расписано: http://habrahabr.ru/post/154891/.
Текст по ссылке содержит ряд утверждений, которые мне лично кажутся спорными. Я когда-то участвовал в попытке изготовления прикладной информационной системы, в процессе которой произносились похожие утверждения. В конечном счете оказалось, что такой подход привел только к увеличению суммарных затрат и ухудшению качества продукта для потребителя. Допускаю, что бывает и по другому, но лично такого не видел.



Re: Темы для встречи в Москве Ответ #22 : 06 Марта 2013, 22:16:00
Согласен, велик соблазн заиграться.



Re: Темы для встречи в Москве Ответ #23 : 07 Марта 2013, 14:21:18
Отлично, а аналитикам это для чего может понадобиться?
Это именно то, чем должен заниматься бизнес-аналитик. Если конечно он аналитик, а не человек у которого в трудовой написано "бизнес-аналитик".

Для системного аналитика ценность существенно меньше.

А вот для руководителя проекта ценность высокая. Можно встретиться и спланировать подготовку ЛАФ по этой модели. Я так планировал - получается очень неплохо.
Сергей Мартыненко
http://martyinenko-sergey1.moikrug.ru/



Re: Темы для встречи в Москве Ответ #24 : 07 Марта 2013, 14:30:46
Это именно то, чем должен заниматься бизнес-аналитик. Если конечно он аналитик, а не человек у которого в трудовой написано "бизнес-аналитик".
Может тогда начать с темы «чем должен заниматься бизнес-аналитик»? А то, боюсь, ты слишком много страниц выкладок пролистываешь со словами «легко видеть, что» ландау-стайл.

Цитировать
А вот для руководителя проекта ценность высокая. Можно встретиться и спланировать подготовку ЛАФ по этой модели. Я так планировал - получается очень неплохо.
Ага, отличная идея.



Re: Темы для встречи в Москве Ответ #25 : 07 Марта 2013, 16:46:32
Может тогда начать с темы «чем должен заниматься бизнес-аналитик»? А то, боюсь, ты слишком много страниц выкладок пролистываешь со словами «легко видеть, что» ландау-стайл.
Всего 500 страниц: http://www.ozon.ru/context/detail/id/4341360/
Эту книгу очень стоит прочитать.

Ага, отличная идея.
Ну так давайте соберемся.
Сергей Мартыненко
http://martyinenko-sergey1.moikrug.ru/



Re: Темы для встречи в Москве Ответ #26 : 07 Марта 2013, 16:49:57
Всего 500 страниц: http://www.ozon.ru/context/detail/id/4341360/
Эту книгу очень стоит прочитать.
Я в курсе. Я о том, что если мы выходим с темой «Как нам строить логические деревья» или даже «Как строить логические деревья для увеличения прохода» потенциальные участники могут даже не понять, что это и зачем. А анонсировать событие «Прочитайте Голдратта» или «Прочитайте Голдратта прежде чем приходить к нам» боюсь не очень эффективно.



Re: Темы для встречи в Москве Ответ #27 : 09 Марта 2013, 21:54:35
- Примеры успешных внедрений на базе Microsoft SharePoint.
Присоединяюсь.Тоже интересно




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19