В теме 18 ответов, и 13 участников, последнее обновление сделано пользователем 
Romario 11 г, 9 мес. назад.
-
Сообщения
-
А давайте попробуем своими силами и нашим накопленным опытом разобраться (если и не раз и навсегда, то хотя бы начнем это делать), какие же существуют различные аналитики и чем они отличаются. Чем они отличаются каждый сам сможет разобраться, если для каждого будут даны четкие определения.
Давайте так.. кто каких аналитиков знает, тот таким и дает описания.
Я пока подкину четырех. Без описания (:· Бизнес аналитики (Business Analyst, BA)
· Системный аналитик (Systems Analyst, SA)
· Business Systems Analyst (BSA, извиняйте не знаю, как это будет на русском)
· Аналитик требований (Requirements Analyst, RA)Привет,Ниже опишу, как я лично себе представляю эти роли.
BA — в чистом смысле слова "бизнес-аналитик". Не обязан иметь технического экспириенса (только в общем представлять процесс разработки ПО), зато должен обязательно говорить на языке заказчика, знать его культуру, особенности, уметь общаться и быть лицом компании, в которой он работает. В идеале должен быть знаком в определенной степени с бизнес-областью проекта. Его задачи и цели — помочь заказчику понять, чего тот хочет, то бишь, предложить идеи автоматизации бизнеса, основываясь на бизнес-целях и текущих проблемах. Вследствие специфики часто ездит по командировкам. Максимум, что на него можно возложить — это извлечение user requirements и передача команде.
Я лично не участвовал в проектах с четко выделенными BA и мне кажется, что эта роль является излишней в традиционном Offshore процессе разработки (при наличии постоянного меняющихся проектов различных бизнес областей и заказчиков, которые знают хотя бы на приблизительном уровне, чего они хотят).SA — не сильно знаком с этим термином, но предположу, что это почти "системный архитектор", то бишь человек, который на основе функциональных требований (либо требований пользователя — но тогда в его компетенции уже будет формулировка и специфицирование функциональных требований) должен предложить функциональное видение системы (а вполне возможно и физическую архитектуру и концепцию системы). Я не знаю точно, кто такой SA, поэтому, наверное, скажу, что их я в глаза не видел
.BSA — судя по названию — нечто общее между BA и SA. На данном этапе позволю себе приравнять его к RA и сказать, что это, собственно, большинство из нас. И задача этих людей… ну тут долго писать и все, думаю, знают, чем они занимаются на работе
.. Короче, прослойка между командой разработки и заказчиком. Как-то так..Буду рад услышать другие трактовки этих терминов.
Привет!От себя я бы сказал следующее:
— Системный аналитик это более широкое определение аналитика как такового без специализации в какой-либо области. Конечно можно было бы предположить что это должно быть слово "аналитик", однако все что мы пытаемся проанализировать так или иначе представляет из себя систему с причинно следственными связями, а следовательно любой кто пытается проанализировать и разобрать систему может считаться "системным аналитиком". Этот тот же пример с "системным архитектором", считаю оба понятия весьма абстрактными. При конкретизации архитектора может выйти "Adobe Flex Architector" или же "Java Architector".
- Я еще знаю одну конкретную специализацию для аналитика — это Финансовый аналитик (Financial Analyst, FA). Познаний в этой профессии у меня не много, все что прочитал это то что их может быть несколько под видов. Одни занимаются анализом деятельности компании по отношению к рынку, другие же наоборот анализируют внутреннее фин. состояние компании.
Обещал написать в эту тему. Вот, собственно.
Я работаю SA 3 года. До этого выступал в ролях BA, Configuration Specialist, Application Engineer, Architect Assistant, IT Support Specialist, Pre-sales Consultant, наконец — 12 лет "отпахал" как Software Development Engineer. Вроде (как мне кажется) знаю процесс разработки программного продукта "от и до". К слову, процессы эти бывают весьма и весьма различными и отличающимися от классических. Здесь я рассмотрю один из процессов разработки, в котором явно прослеживаются различия между BA и SA.Итак, основной "неклассической" чертой является то, что проект отталкивается не столько от требований, сколько от собственно анализа бизнеса и моделирования процессов.
1. Клиент звонит в отдел pre-sales и проявляет заинтересованность в покупке нашего продукта и интеграции его в уже имеющуюся у них корпоративную систему и, соответственно, бизнес-процесс.
2. Pre-sales Specialist (он же BA со знанием специфического домена) выезжает на место и проводит предварительное интервью с клиентом, где выясняет возможности для предоставления сервисов.
3. BA и SA вместе пишут предложение. BA берет на себя часть, касающуюся функций системы, а SA — технологий и продуктов, используемых для её разработки. PM добавляет коммерческую часть. Legal dept. проверяет предложение с юридической точки зрения.
4. PM заключает договор с клиентом и на его основании пишет Statement of Work — документ, расписывающий состав и содержание необходимых работ. Также, составляет проектный план.
5. Архитектор, общаясь с high and medium level менеджерами заказчика, пишет System Architecture Document. В нём (в абсолютном отрыве от используемых технологий !) описываются бизнес-сущности, их взаимоотношения, основные workflows, ввод и вывод, бизнес правила. Строится высокоуровневая модель данных и всего бизнес-процесса, в котором задействована система.
6. Бизнес-аналитик, общаясь с medium and low level менеджерами заказчика и основываясь на архитектурном документе, пишет Functional Specification. Здесь определяются и описываются (как правило, как Use Cases) функции, которые выполняет система.
7. Архитектор, SA и представители IT заказчика определяют технологии и программные продукты, необходимые для функционирования системы. SA пишет Technical Requirements Document.
8. SA пишет Detailed Specification. В ней — скрины, детальное описание каждого поля, комбика и иконки. Там же — детальное описание каждого алгоритма, отражающего специфические бизнес-правила. Здесь уже учитываются технологические особенности.
9. Configuration Specialist производит конфигурацию готовых продуктов, баз данных, систем поддержки версий и т.д. Разработчики начинают кодировать.
10….Указанные выше шаги не обязательно исполняются один за другим. Часто они происходят "внахлёст". Также часто необходимо бывает вернуться назад, чтобы переосмыслить систему — принять новые решения или вовсе прекратить работу.
Выводы сделайте сами.
Приведу другие определения, отличия и предназначение названных выше специалистов. И так:1. Бизнес аналитики (Business Analyst, BA) — специалисты, которые занимаются изучением и моделированием исключительно предметной области (для этого используют специфические стереотипы языка UML) включая:
а) выявление и моделирование сущностей предметной области, определяют их атрибуты, иерархии, при необходимости связи между сущностями. Создается диаграмма сущностей предметной области (по типу это Class diagram);
б) выявление и моделирование функционеров предметной области (бизнес-актеры) и их функциональных обязанностей (бизнес-use case´s). Создаются специальные Business Use Case Diagram;
в) изучение и моделирование бизнес-процессов (при необходимости состояний). Создаются Activity/Statechart Diagram;
г) создают Глоссарий предметной области.2. Аналитик требований (Requirements Analyst, RA). Отвечает за выявление, документирование и моделирование функциональных требований и за обеспечение их однозначной трассировки с пожеланиями заказчика. Его деятельность включает:
а) выявляет и фиксирует пожелания заказчика, связанные с функциональностью системы;
б) каждому выявленному пожеланию ставит в соответствие одну или несколько функций системы, благодаря которым оно реализуется;
в) создает спецификацию функциональных требований;
г) функции (несколько, или одну) отождествляет с Use Caseами;
д) документирует пожелания, функции и Use Case в трассировочной матрице;
е) создает Use Case-модели, в которых находят отражение каждая функция бизнес-логики;
ж) приводит краткое высокоуровневое описание Use Case, связанных с бизнес-логикой, моделирует Use Case с помощью Activity Diagram3. Системный аналитик (Systems Analyst, SA). Создает модели системного анализа (с помощью специальных стереотипов), т.е. первичную архитектуру (архитектуру анализа):
а) проводит подробное описание потоков событий Use Case, создавая для этого экранные формы;
б) из описанных потоков событий выявляет взаимодействующие объекты программной системы (лингвистический анализ потоков событий);
в) создает динамические модели взаимодействия объектов программной системы, построение Sequence Diagram;
г) моделирует структуру связей между объектами программной системы (Collaboration Diagram);
д) создает диаграмму классов анализа (Class Diagram).Business Systems Analyst (BSA, извиняйте не знаю, как это будет на русском) — это, возможно, когда не требуется большого изучения предметной области и двух специалистов можно объединить в одном.
Если у кого возникнут вопросы по этому посту, то буду рад на них ответить!Каждый из указанных мною выше аналитиков отвечает за определенную область анализа программной системы и создает определенные артефакты, которые отличаются от других набором специфических стереотипов, входящих в стандарт UML. Весь процесс разработки программного продукта при этом полностью согласуется с технологией Unified Process (если хотите, то с Rational Unified Process), т.е. является итерационным инкрементальным, хорошо поддерживается средствами Rational Software (Requisite Pro, Rational Rose, Rational Soda). Каждый из аналитиков точно знает круг своих обязанностей. На каждого такого специалиста имеется свой вид сертификации. С заказчиками контактируют все эти специалисты, но каждый в рамках своих обязанностей: БА едет (если это требуется) к заказчику и изучает предметную область и обсуждает с заказчиком vision; специалист по RE согласует с заказчиком спецификацию требований и высокоуровневые описания Use Cases; СА согласует с заказчиком подробные сценарии вместе с первичными экранными формами.При такой организации работ все очень четко и главное, есть у кого и за что спрашивать!
nousy123 — практически идеальная картина Ещё бы такое в реальности увидеть практически идеальная картина Ещё бы такое в реальности увидеть
Нет, это не идеальная, а такая как она должна быть. При этом, это не догма, а руководство к действиям и, в зависимости от проекта и степени знания предметной области можно оптимизировать. Хотите так организовать на своей фирме, приглашайте, проведу тренинг на основе очень маленького реального проекта и все как и, что делать подробно на практике объясню на хороших примерах.
[quote]практически идеальная картина Ещё бы такое в реальности увидеть
Нет, это не идеальная, а такая как она должна быть. При этом, это не догма, а руководство к действиям и, в зависимости от проекта и степени знания предметной области можно оптимизировать. Хотите так организовать на своей фирме, приглашайте, проведу тренинг на основе очень маленького реального проекта и все как и, что делать подробно на практике объясню на хороших примерах.[/quote]
Спасибо. Я уже неоднократно проводил "тренинги" на основе реальных и больших и маленьких проектов для руководства, но у них есть своя, "перпендикулярная" точка зрения на происходящее в целом и на аналитику в частности. К сожалению.Из собственных наблюдений, в наших реалиях есть два самых распространенных вида аналитиков:
- Человек, который собирает данные в кучу и предоставляет на их основе руководству красивый отчет. Распространен в крупных торговых, реже в производственных, компаниях. Существует потому, что квалифицированный бухгалтер, на которого эта задача бы вешалась за неимением аналитика, стоит дорого.
- Человек, который общается с заказчиком и превращает его "хотелки" в требования к продукту, он же переводит пожелания "белого масы" на язык понятный кудрявым девелоперам.
Добавлю свои пять копеек в копилку (на основе своего опыта):
1. Business Analyst — отвечает за коммуникации с заказчиком, на выход выдаёт High Level Requirements и документ с Use Cases
2. System Analyst — на вход получает документы от BA и на выход выдаёт Low Level Requirements и дизайн спецификации
3. QA Analyst — отвечает за контроль внутренних процессов и качество выдаваемого решения
4. Product Analyst — занимается сбором и анализом требований с проектов и за последующее расширение продуктового решенияДобавлю свои пять копеек в копилку (на основе своего опыта):
1. Business Analyst — отвечает за коммуникации с заказчиком, на выход выдаёт High Level Requirements и документ с Use Cases
2. System Analyst — на вход получает документы от BA и на выход выдаёт Low Level Requirements и дизайн спецификации
3. QA Analyst — отвечает за контроль внутренних процессов и качество выдаваемого решения
4. Product Analyst — занимается сбором и анализом требований с проектов и за последующее расширение продуктового решенияПозволю себе несколько вопросов, чтобы лучше разобраться в вашем опыте..
1) А где работает Business Analyst?
2) С кем он(а) общается, кроме заказчика и системного аналитика?
3) Системный аналитик не общается с заказчиком вообще?
4) QA аналитик отвечает за контроль внутренних процессов чего: проектной команды, отдела, в котором работает, отдела QA, всей компании?
5) Если QA аналитик отвечает за качество выдаваемого решения, то за что отвечает QA Engineer / QA Lead / QA Manager? Понимаете, к чему я клоню?
6) Не совсем понятны функции и обязанности продуктового аналитика. С каких именно проектов он собирает и анализирует требования? В чем принципиальное отличие от бизнес и системного аналитиков?Добавлю еще один взгляд на специфику всех этих аналитиков. Недавно участвовал в тренинге по работе с требованиями, и так предлагалась следующая интерпретация:- Системный аналитик: мегагуру всего и вся ("трехзвездочный генерал"). Человек, который умеет работать с требованиями, начиная с этапа анализа бизнеса (типа, я проанализирую, что у вас в компании не так, и предложу свое решение, которые поможет вам сократить издержки/увеличить прибыль и т.д.) и заканчивая чуть ли не построением архитектуры приложения и структуры классов/БД. Такие люди — на вес золота и встречаются крайне редко.
- Бизнес-аналитик ("однозвездочный генерал") — собственно, работа с бизнес-частью. Результаты его работы нельзя пускать в разработку.
- Аналитик требований ("однозвездочный генерал") — трансформирует результаты работы бизнес-аналитика в функциональную спецификацию.
Т.о. БА + RA — это примерно СА. Только СА все равно гораздо предпочтительнее, чем связка БА — RА.
В наших условиях аутсорсинга БA/CА нужны довольно редко, так как клиент обычно представляет, что конкретно ему нужно внедрить и какие бизнес-цели это преследует. Поэтому и наиболее распространены у нас аналитики требований.От себя: я не совсем согласен с определением системного аналитика. Но соглашусь с тем, что человек, умеющий все описанное выше, это некий сверхаддский мегагуру
.Я работаю системным аналитиком. И действительно могу сказать, что занимаюсь всем начиная от анализа бизнес-процессов и заканчивая разработкой архитектуры приложения и моделей данных с ним связанных. Теперь буду знать что я на вес золотаЯ работаю системным аналитиком. И действительно могу сказать, что занимаюсь всем начиная от анализа бизнес-процессов и заканчивая разработкой архитектуры приложения и моделей данных с ним связанных. Теперь буду знать что я на вес золота
Интересно (:
А вы не могли бы рассказать немного о себе в теме "Давайте знакомиться"?
Вы должны авторизироваться для ответа в этой теме.
