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

×


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

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


Сообщения - maksiq

Страницы: 1 2 3 4 5 6 7 8 9 »
1
Под классикой я понимал Водопадную модель (http://en.wikipedia.org/wiki/Waterfall_model), из которой выросло в том или ином виде большинство стандартов. И уже потом они вобрали в себя agile-подходы. Так вот, requiremenrs - бизнес-аналитик, design - системный аналитик и архитектор.

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

2
Все-таки, у нас - сообщество системных аналитиков, а не бизнес-аналитиков. Системный аналитик - он (по классике) стоит после бизнес-аналитика и создает дизайн системы, в рамках верхнеуровневой архитектуры, заданной архитектором. Это к вопросу о понятиях вообще. Если говорить о практике, то, наверное, где-то аналитик выступает именно как бизнес-аналитик, снимает требования в виде usecase/userstory, а дальше все делают разработчики. Но, наверное, не все так - кто-то из аналитиков делает диаграммы классов/ER-диаграммы, описывают поведение объектов системы? И там есть свои проблемы и решения. И хочется к следующему ЛАФу призвать поделиться опытом. Я могу рассказать как делаем мы (я, собственно, весь прошлый год рассказывал это на разных конфах, включая ЛАФ), но мне интересно чужой опыт послушать...

3
Пост навеян ретроспективой прошедшего ЛАФ-2012.

Я тут осознал, что на фестивале было много докладов про место аналитика, про организацию процесса и общение с бизнесом, но очень мало собственно про основную работу аналитика - проектирование системы. Из тех, что я слышал к этой категории можно отнести доклады Алексея Смирнова про Реверс-инжиниринг требований в проекте по миграции КИС и Рустема Гайфутдинова про прототипирование GUI, и еще Юрий Веденин про юзабилити рассказывал.

Этому могут быть три объяснения:
1) работа аналитика выродилось в описание usecase/userstory и проектирование интерфейса, остальное делают разработчики;
2) когда первичные требования сняты, в проектировании реализацию - структуры данных и прочее - нет ничего сложного, берешь и делаешь;
3) все общее, что можно сказать о проектировании, сказано методологами по ООП и другими, остальное зависит от проекта и сплошной креатив - не расскажешь и не обсудишь.
Мне все эти варианты не слишком нравятся, да и не представляются верными.

Поэтому как идея: попробовать перед программой следующего ЛАФ поработать над поиском докладов именно в эту сторону.

А что остальные думают? Было бы интересно услышать/рассказать/обсудить именно проектирование системы?

Да, Саша Байктн попросил уточнить, что я понимаю под проектированием системы. Если рассмотреть классический процесс, то там есть этап бизнес-анализа, на котором тем или иным способом выясняются и формулируются потребности бизнеса, и этап системного анализа,  на котором создается архитектура и/или дизайн системы (методологи расходятся). Включая структуру данных/классов и интерфейсов, но не ограничиваясь ими.

4
Для всех / Re: а получили как всегда
« : 23 Октября 2011, 16:55:32 »
Замечательный рисунок

5
Для начала отмечу, что по моему опыту оформление по ГОСТ не имеет никакого отношения к качеству документа. Иногда за этим скрывается некоторые содержательные желания, иногда это чистый формализм большой организации, который надо выполнять. В любом случае требования надо выяснять у тех. кто будет принимать.

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

6
Если имеется некоторый устойчивый способ реализации, который зависит от вида сущности (справочники, документы с документооборотом, вычислимые показатели), то обозначать это в названии полезно. Это позволяет сразу мыслить в нужном контексте, когда встречаешь название в ТЗ. Еще и потому, что классификация не всегда бывает очевидной, например, с договорами подобная вещь - это документ или просто справочник.

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

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

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

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

Но все это - про реальные и сложные use case. Пример с сохранением документа - это use case, которого вообще не должно быть в описании, такие вещи сильно увеличивая объем документа мешают его пониманию. Пишу потому, где видел ТЗ в которых авторы каждый документ сопровождали подобными тривиальными сценариями - наверное, им платили по-странично.

8
Знаком с теорией DDD, myers-briggs и белбина. Интересны практические применения. Зачем на фестивале для аналитков рассказывать теорию чужой дисциплины, которую причём можно свободно почитать в онлайне — не понимаю.

Денис, по DDD будет о нашем опыте практического применения. Ну и сам предмет - он как раз для аналитиков, это такой способ их работы.

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

9
Эдуард, если вспомните про бассейновую модель какие-то подробности или источники, будет интересно - потому что примерно похожие идеи у меня есть, но я про это нигде не читал. Если кто-то занимается, будет любопытно сравнить.

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

Галина, предмету спора не то что бы положено оставаться тайной, просто в готовом к публикации виде этого нет. Так что если я буду-таки об этом рассказывать, а Вы - послушаете, то потом мы обсудим - учат этому или нет, и где именно. Если учат, то мне интересно.

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

10
Мне интересно услышать про DDD именно с практической точки зрения. Действительно ли возможно это?
Ну я правда преподаю на учебной практие MDA и вполне успешно. И книгу Эрика Эванса тоже скачал.
DDD - да, возможно. И мы думаем, что мы именно потому можем развивать наши проекты, что под ними есть модель. В общем-то такие подходы были у нас до знакомство с DDD, так что тут много просто соотнесения с мировой практикой.

А что такоего необычного в бухгалтерском учете? Вы какую школу будуте рассказывать? Староитальянскую (миланскую вроде), бассейновую или нечто совершенно другое и не про это?
А бассейновая - это что? Я не знаю, и яндекс не знает, что интересно. Я знаю итальянскую, с двойной записью, и купеческую, когда следишь cash flow и ресурсы, а баланса нет. А в рассказе я буду показывать, как потоки ресурсов превращаются в баланс. Ну и всякие особенности - почему доходы в пассиве, зачем амортизация и т.п.

А вот это типология Майерс-Бригсс - это не типа гороскопа? Что-то у меня сложилось такое ощущение :о)
Нет, это не гороскоп. Это некоторая практическая классификация, которая работает и активно применяется в Штатах и не только там.

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

11
Галина, а вы приезжайте на фестиваль, там здорово!

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

12
По DDD в прошлом году наконец-то перевели концептуальную книгу Эрика Эванса Domain Driven Design (2003) - в переводе "Предметно-ориентированное проектирование", но перевод хороший. Djvu ходит по инету. Первая концептуальная часть около 50-70 страниц, и именно она наиболее интересна. Но теорию в каком-то виде я буду рассказывать.

А по 3 мне тут пришла мысль, что вместо круглого стола можно устроить jam-session, только со введением по каждому вопросу. Вроде как это эффективно получается.

Что касается Васи, то тут есть две разные ситуации: (1) он сознательно придерживает инфу по своим соображениям, тогда это к психологии слабо относится, и (2) он не понимает, что вам непонятно, потому что по-другому думает о мире, в этом типология может помочь разобраться.

13
Мне очень понравилось на ЛАФ в прошлом году и я надеюсь, что в этом тоже будет много интересных участников. Поэтому я хотел бы ориентировать свои рассказы по их потребностям. Я напишу темы, о которых хотел бы рассказать и надеюсь, что отклики помогут мне сделать доклады и сообщения лучше, ну и вообще понять - будут ли темы интересны.

Первая тема - DDD, модель вместо требований. Мы применяем этот подход для проектирования корпоративных систем и у нас сложился некоторый набор моделей. В докладе я планирую рассказать о подходе в целом, иллюстрируя нашей практикой. Понятно, что если слушатели сами знакомы с DDD, то им интереснее практика, а если не слишком, то надо подробнее рассказывать о теории. Какие акценты были бы интересны на ЛАФ?

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

Третья тема - психология взаимодействия - типология Майерс-Бриггс и командные роли Белбина. Об этом я в свое время читал книги, которые произвели на меня впечатление, и рассказывал в своей компании на внутреннем семинаре - слушателям было интересно. А сами темы регулярно всплывают в различных докладах на конференциях. И я готов поделиться - это позволит составить представление а, быть может, сильно заинтересует.

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

Надеюсь на отклики будущих участников конференции.

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

15
Идеи "идеального ТЗ" понятны, и я с ними согласен (более того, 1 и 2 - это часть принципов DDD, который сейчас mainstream, по-моему). Единственное, на тему 2 - представление НЕ является однозначным, всегда есть техническая вариативность, да и не-техническая - тоже есть - иначе сложность ТЗ будет равна сложности системы. 3 - это, в общем,  следствие. А вот "шаблон идеального ТЗ" - это уже интереснее. Потому что он имеет смысл, если применим для любых предметных областей и/или для любых классов задач. Или подразумевается шаблон все-таки ограниченной применимости? В общем, с интересом послушаю доклад на эту тему.

Страницы: 1 2 3 4 5 6 7 8 9 »