Форум Сообщества Аналитиков
Обсуждения => Сообщество Аналитиков => Тема начата: Denis Beskov от 03 Марта 2013, 00:14:54
-
Коллеги, пора бы устроить встречу сообщества.
Напишите пожалуйста, какие вопросы и темы вас сейчас интересуют.
Я готов организовать встречу.
-
Денис, заодно не мешало бы открыть регистрацию (предварительную) - чтобы было понимание, какого масштаба будет встреча.
-
В чём смысла регистрации на событие без темы?
-
Так темы в этом топике и будут озвучены, разве нет?
-
Я с такой надеждой эту дискуссию и открывал.
Только сначала темы, потом — регистрация.
Немного статистики:
В фейсбук-группе на 50 просмотров моего предложения — заявлены 2 темы.
Тут на 60 просмотров — 0.
-
Что-то идей мало :) Ну тогда как-то так:
- ГОСТ 19, 34 как методология разработки ПО? Успешные практики применения. Соотнесение пирамиды Вигерса (Бизнес-требования, ВИ, ФТ) с документами ГОСТ. "Упаковка" в ГОСТ популярных методологий (RUP, MSF, Agile, et cetera...).
Вечная тема. Не знаю, насколько это интересно, да и обсуждалось многократно, просто я сейчас смотрю в эту сторону.
- Примеры успешных внедрений на базе Microsoft SharePoint.
-
Рыбка, спасибо за предложение!
А какую проблему вы решаете в разработке по ГОСТ? Как совместить лучшие мировые практики анализа с требованиями заказчика по формальности документации?
-
Мне интересно построение логических деревьев.
Событие подобное этому: http://cartmendum.livejournal.com/119785.html
Есть готовые схемы из реальных проектов.
-
Мне интересно построение логических деревьев.
Событие подобное этому: http://cartmendum.livejournal.com/119785.html
Есть готовые схемы из реальных проектов.
Построение логических деревьев с какой целью?
-
Построение логических деревьев с какой целью?
Изменение бизнес процессов.
-
Изменение бизнес процессов.
а какую проблему решаем?
-
А какую проблему вы решаете в разработке по ГОСТ? Как совместить лучшие мировые практики анализа с требованиями заказчика по формальности документации?
И это тоже, но не только. Я до недавнего времени воспринимала ГОСТ именно как набор формальных документов, но все чаще у меня появляется мысль, что за ним скрывается нечто бОльшее. Попутно мне попалось несколько хороших статей на эти темы:
http://gaperton.livejournal.com/49867.html (http://gaperton.livejournal.com/49867.html)
http://habrahabr.ru/post/122700/ (http://habrahabr.ru/post/122700/)
http://boatmanshome.ru/cgi-bin/page.pl?21dev_002.page (http://boatmanshome.ru/cgi-bin/page.pl?21dev_002.page)
Так что мысль у меня была несколько утопическая: как совместить лучшие мировые практики разработки ПО с лучшими отечественными практиками?
-
Ну вот и тема сформулировалась: "Что скрывается за ГОСТами?" :)
-
Так что мысль у меня была несколько утопическая: как совместить лучшие мировые практики разработки ПО с лучшими отечественными практиками?
Как вы думаете, а есть ли отечественные практики за рамками ГОСТов?
-
Как вы думаете, а есть ли отечественные практики за рамками ГОСТов?
Не думаю. Если и есть, то мне они неизвестны :)
А в рамках, наверно, были интересные решения - вот, например (http://ru.wikipedia.org/wiki/%D0%94%D0%A0%D0%90%D0%9A%D0%9E%D0%9D)
Но это уже история.
-
Напишите пожалуйста, какие вопросы и темы вас сейчас интересуют.
Интересует матамоделирование.
На мой взгляд, интересное направление для системных аналитиков. Позволяет глубже влезть на поле разработчика. Все-таки разрыв наблюдается. Аналитик разработали требования и отдал в черный ящик. Иногда после ящика выполняют "авторский надзор", по сути функциональное тестирование. Максимум, что имеем - увязку требований с кодом (трассировка).
Что происходит в черном ящике - священная тайна, что там тимлиды творят, только им известно ))).
Метамоделирование по сути позволяет "сшить" вместе требования (предметную модель) и архитектуру ПО, которая формируется на основе метамодели. Если аналитик будет участвовать в проектировании системы (по сути выполнять часть роли архитектора), от этого выиграет качество ПО и сроки его разработки.
Большой эффект от метамоделирования можно достичь при разработке сложных приложений, например ERP, когда на одной платформе автоматизируется множество процессов, описываемых множеством предметных моделей. Загнав эти предметные модели в одну метамодель можем разработать логически связанную структуру большого ПО, а не как обычно, когда большая система состоит из множества подсистем, наслаиваемых в течении многих лет, и по сути являющихся интегрированными, но отдельными приложениями.
Тут немного расписано: http://habrahabr.ru/post/154891/ (http://habrahabr.ru/post/154891/).
-
Интересует матамоделирование.
На мой взгляд, интересное направление для системных аналитиков. Позволяет глубже влезть на поле разработчика. Все-таки разрыв наблюдается. Аналитик разработали требования и отдал в черный ящик. Иногда после ящика выполняют "авторский надзор", по сути функциональное тестирование. Максимум, что имеем - увязку требований с кодом (трассировка).
Что происходит в черном ящике - священная тайна, что там тимлиды творят, только им известно ))).
и к каким последствиям это приводит?
Метамоделирование по сути позволяет "сшить" вместе требования (предметную модель)
Требования и предметная модель — это разве одно и тоже?
…и архитектуру ПО, которая формируется на основе метамодели. Если аналитик будет участвовать в проектировании системы (по сути выполнять часть роли архитектора), от этого выиграет качество ПО и сроки его разработки.
Насколько выиграет? Откуда информация об этом — у вас есть опыт или читали про чужой?
Большой эффект от метамоделирования можно достичь при разработке сложных приложений,
Это гипотеза или опыт?
например ERP, когда на одной платформе автоматизируется множество процессов, описываемых множеством предметных моделей. Загнав эти предметные модели в одну метамодель можем разработать логически связанную структуру большого ПО, а не как обычно, когда большая система состоит из множества подсистем, наслаиваемых в течении многих лет, и по сути являющихся интегрированными, но отдельными приложениями.
Чем это принципиально отличается от MDA (Model-Driven Architecture) и DDD (Domain Driven Design)?
«Можем разработать логически связанную структуру большого ПО» — за какое время? Откуда возьмётся информация для такой структуры? Как поддерживается процесс развития системы?
Вы с какой позиции рассуждаете — архитектора, аналитика, менеджера, заказчика, ИТ-директора?
-
Изменение бизнес процессов.
Изменение ради изменения?
-
и к каким последствиям это приводит?
Когда строится уникальное здание, архитектор осуществляет авторский контроль, т.к. конечная цель связки архитектор-строители является здание для заказчика.
Разве при разработке ПО не так же? Я, конечно, понимаю про тестирование, но неужели роль аналитика заканчивается на разработке требований? Кто в итоге отвечает за пиджак? Я понимаю про "отвечает за все руководитель проекта", но, на мой взгляд, аналитик должен участвовать в приемке приложения и возможно в функциональном тестировании и разработке документации.
Требования и предметная модель — это разве одно и тоже?
Под предметной моделью в данном контексте я понимаю диаграммы классов, в которых аналитик расписывает артефакты предметной области (я пока про статику, без потоков и процессов) и которые используются при описании функциональных требований.
Насколько выиграет? Откуда информация об этом — у вас есть опыт или читали про чужой?
К сожалению, по этой теме теории я читал мало. Потому и разместил сообщение в данной ветке. Да, опыт небольшой был, с коллегами год разрабатывали метамодель будущей системы, без строчки кода. С точки зрения проработки аналитики приложения, мы за этот год сделали больше, чем за предыдущие 9.
Лично для своего случая вижу два плюса: прочитав и поняв метамодель любой разработчик (и аналитик) понимает общую концепцию системы. Второй плюс - мы разрабатываем коробочный продукт для открытого рынка, т.е. заказчик конкретизируется после покупки и начала внедрения. При внедрении происходят различные "уточнения требований". Если изначально предметную модель зашить в коде, то "уточнение" практически невозможно. Поэтому при разработке приходится предполагать различные будущие изменения и разрабатывать настраиваемое ПО. Раньше делали все на интуиции, но почитав немного (к сожалению немного), я понял, что есть некие теоретические знания, которые могут помочь в этом. Насколько я понимаю, можно на основе нескольких предметных моделей (описанных и предполагаемых) построить метамодель, в которой эти модели легко реализовать при настройке у конкретного пользователя.
Это гипотеза или опыт?
Имелся опыт (выше описал), но, к сожалению, не доведенный до конца по организационно-экономическим причинам.
Denis Beskov, я разделяю Ваш скепсис, который Вы высказывали в другой ветке. Действительно можно заиграться в метамоделирование и спроектировать "базу данных в 4-6 таблиц для всего и вся". На мой взгляд, в статье на хабре тоже перегнули палку (вроде речь про НИИ шла, тогда понятно), разрабатывая серии виртуальных машин под различные предметные области.
Чем это принципиально отличается от MDA (Model-Driven Architecture) и DDD (Domain Driven Design)?
Возможно ничем. Спасибо за наводку, буду читать. Почитал по диагонали, очень похоже.
«Можем разработать логически связанную структуру большого ПО» — за какое время? Откуда возьмётся информация для такой структуры?
Так про это и речь, если жизненный цикл разработки и развития ПО превышает 10 лет (условно говоря более 10 версий по 1 разу в год), то к десятому году что-либо внести в систему проблематично. Появляются куски кода, которые никто из существующих на данный период времени разработчиков не видел. Ситуация "в одном месте поправил, в других отвалилось" становится типичной.
Как поддерживается процесс развития системы?
Метамодель (возможно DDD и/или MDA) позволит при внесении изменений понять масштаб бедствия. Обычно такие знания находятся в голове разработчиков, заманчиво иметь хотя бы часть этих знаний "на бумаге". Соответственно, не забываем и про трассировку.
Вы с какой позиции рассуждаете — архитектора, аналитика, менеджера, заказчика, ИТ-директора?
Формально, с точки зрения аналитика. Но коллектив небольшой, роли размыты. Например, ранее часть структуры БД проектировал я, сейчас, правда, разработчики. Код я не пишу, и никогда не писал.
Хотя, на мой взгляд, вещь полезна для всех ролей разработчиков.
-
Изменение ради изменения?
Естественно нет. Для уменьшения связанного капитала и увеличения прохода. И это то, зачем строится дерево текущей реальности.
-
Естественно нет. Для уменьшения связанного капитала и увеличения прохода. И это то, зачем строится дерево текущей реальности.
Отлично, а аналитикам это для чего может понадобиться?
-
Интересует матамоделирование.
....
Тут немного расписано: http://habrahabr.ru/post/154891/ (http://habrahabr.ru/post/154891/).
Текст по ссылке содержит ряд утверждений, которые мне лично кажутся спорными. Я когда-то участвовал в попытке изготовления прикладной информационной системы, в процессе которой произносились похожие утверждения. В конечном счете оказалось, что такой подход привел только к увеличению суммарных затрат и ухудшению качества продукта для потребителя. Допускаю, что бывает и по другому, но лично такого не видел.
-
Согласен, велик соблазн заиграться.
-
Отлично, а аналитикам это для чего может понадобиться?
Это именно то, чем должен заниматься бизнес-аналитик. Если конечно он аналитик, а не человек у которого в трудовой написано "бизнес-аналитик".
Для системного аналитика ценность существенно меньше.
А вот для руководителя проекта ценность высокая. Можно встретиться и спланировать подготовку ЛАФ по этой модели. Я так планировал - получается очень неплохо.
-
Это именно то, чем должен заниматься бизнес-аналитик. Если конечно он аналитик, а не человек у которого в трудовой написано "бизнес-аналитик".
Может тогда начать с темы «чем должен заниматься бизнес-аналитик»? А то, боюсь, ты слишком много страниц выкладок пролистываешь со словами «легко видеть, что» ландау-стайл.
А вот для руководителя проекта ценность высокая. Можно встретиться и спланировать подготовку ЛАФ по этой модели. Я так планировал - получается очень неплохо.
Ага, отличная идея.
-
Может тогда начать с темы «чем должен заниматься бизнес-аналитик»? А то, боюсь, ты слишком много страниц выкладок пролистываешь со словами «легко видеть, что» ландау-стайл.
Всего 500 страниц: http://www.ozon.ru/context/detail/id/4341360/
Эту книгу очень стоит прочитать.
Ага, отличная идея.
Ну так давайте соберемся.
-
Всего 500 страниц: http://www.ozon.ru/context/detail/id/4341360/
Эту книгу очень стоит прочитать.
Я в курсе. Я о том, что если мы выходим с темой «Как нам строить логические деревья» или даже «Как строить логические деревья для увеличения прохода» потенциальные участники могут даже не понять, что это и зачем. А анонсировать событие «Прочитайте Голдратта» или «Прочитайте Голдратта прежде чем приходить к нам» боюсь не очень эффективно.
-
- Примеры успешных внедрений на базе Microsoft SharePoint.
Присоединяюсь.Тоже интересно