Что нужно для того, чтобы соответствовать требованиям предъявляемым к системному аналитику при приёме на работу? Насколько реально получить такие знания самому? Какую литературу нужно изучить? Какие инструменты и насколько глубоко нужно/желательно освоить?

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

Для начала, нужно понимать, что стоит за этой профессией.

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

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

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

Роль аналитика - центральное звено любого проекта автоматизации. Аналитик действует между двумя группами:
- Заказчиком и пользователями
- Архитектором и разработчиками

Если коротко, то задача аналитика - посредничество в удовлетворении разработчиками заказчика и пользователей на протяжении всего проекта. Т.е. он должен буквально понять задачу, поговорив с заказчиком и будущими пользователями и объяснить её архитектору и разработчикам так, что бы они её выполнили наиболее успешным образом.

Есть такая классическая история о банкире и программмисте. Встречаются банкир, которому нужно автоматизировать работу банка, и программист, который умеет программировать. Диалог примерно следующий:
Банкир: "Что вы могли бы предложить?"
Программист: - "А что вам нужно?"
Б: "Нужно, что бы нам было комфортно и хорошо работать!"
П: "А как это?"
Б: "Что значит как? Я же сказал - комфортно и хорошо!"
П: "Я только программировать умею, скажите, что писать!"
...
Они так ни до чего и не договорились. Дело в том, что программист ничего не знает о специфике банкоской детельности, не поймёт, что ему делать, а банкир не представляет себе, как можно было бы автоматизировать то, что он делает, ибо сам в программировании ни бум-бум. Вот по-этому-то им обоим и нужен аналитик.

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

Впрочем, как я уже сказал, это лишь моё видение профессии системного аналитика, и я не удивлюсь, если кто-то представляет её совсем по-другому, ибо во многом эта должность тольько оформляется и пока то, что в неё вкладывает руководство каждой отдельной компании, сильно отличается от остальных...
Добавлено @ 13:25
Если интересно,
1. по системному подходу можешь почитать Рассела Акоффа "О менеджменте",
2. по разработке требований - Вигерса "Разработка требований к программному обеспечению",
3. а по ООА/П, т.е. анализу требований с точки зрения программирования - Крэга Лармана "Применение UML и шаблонов проектирования".

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

Это сообщение отредактировал(а) Се ля ви - 14.12.2005, 15:14

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

Могу поделиться результатами СВОЕГО анализа, но думаю, для начала тебе будет полезнее провести свой собственный. У меня это заняло несколько часов. Если интересно - вперед. Потом сравним результаты.

Это сообщение отредактировал(а) ida - 12.1.2006, 09:56

AntonSaburov
1) есть
2) а зачем системному аналитику вообще программировать? (по поводу этого пункта есть еще один вопрос: нужно ли системному аналитику глубокое знание языков программирования?)
3) буду изучать =)

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

Цитата

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

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

Цитата(ida @ 14.12.2005, 13:45)

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

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

а вот, если интересно описание того обьявления, которое привело меня к этому посту(прошу прощения если текст покажется корявым - перевожу дословно):

Цитата

Цель работы включает в себя исследование бизнес требований и изучение существующей системы, описание возможных вариантов решений системы, поддержку программистов в разработке системы. Требования: • Понимание методов и процессов анализа и проектирования, и связанных с этим расходов • Аналитическое мышление, желание и возможность освоить новые методы, способность оценить, обработать и описать результаты своей работы, умение видеть(? учитывать) взаимосвязи между делами, чуство ответственности, умение самостоятельно организовать свою работу, коммуникабельность, творческий подход к поиску решений. • Желателен опыт в обращении с инструментами системного анализа и проектирования.

последний пункт меня заинтриговал... интересно, что за инструменты такие. Rational Rose и иже с ним?

Цитата(Bose @ 14.12.2005, 15:01)

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

Это ты аналитика и архитектора в одну кучу сваливаешь. Хотя, из-за, недостатка средств, зачастую, эти роли действительно играет один и тот же человек, но роли эти разные и даже если выполняются одним человеком, будет полезно, если он будет это понимать. Что бы разделить их, тебе необходимо ознакомиться с языком UML и с процессом UP - тогда всё встанет на свои места. В UML всё начинается с Use Case - диаграмм. Грубо говоря, всё, что относится к тому, как их стставлять - задача аналитика, дальше - архитектора. А блок-схемы принципиально не подходят к современному программированию, они не рассчитаны на применение ООП ни под каким видом. Тут их как раз заменяет UML.

В тех трёх книгах, которые я тебе посоветовал, всё это есть. Рекомендую купить все три и читать именно в таком порядке. Потом и перечитать не помешает - книги действительно хорошие.
Добавлено @ 15:25
А насчёт того, чего заказчик хочет - часто приходится говорить именно с пользователями системы, ибо они лучше представляют, что им нужно и чётче могут это сформулировать, чем начальство, к тому же, у них на это, как правило, больше времяни.

Это сообщение отредактировал(а) Се ля ви - 14.12.2005, 15:37

Цитата

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

Так и есть. Сваливаю. =) Ибо не знаю, чем должен архитектор заниматься.

А если их разделить, то в моём представлении получается, что аналитик решает задачу в целом, а архитектор уже думает над тем, как это воплотить. Но тогда же получается, что между заказчиком и программистами стоит не одно звено, но два Системный Аналитик и Архитектор. Так?

Цитата(Bose @ 14.12.2005, 16:01)

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

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

Это сообщение отредактировал(а) ida - 12.1.2006, 09:57

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

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

Это сообщение отредактировал(а) Се ля ви - 14.12.2005, 15:51

Вообще говоря, тут наблюдается путаница, как верно заметил Се ля ви. Во-первых, я не знаю, кто такой "системный аналитик". Есть бизнес-анализ и есть анализ требований. Их могут проводить разные люди, а может один.

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

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

Это сообщение отредактировал(а) ida - 12.1.2006, 09:58

Цитата(ida @ 14.12.2005, 16:10)

Вообще говоря, тут наблюдается путаница, как верно заметил Се ля ви. Во-первых, я не знаю, кто такой "системный аналитик".

Бизнес-аналитик и системный аналитик - это действительно разные люди.

Основная роль бизнес-аналитика - это разработка непротиворечивой и достаточно полной модели требований реального бизнеса.
Ida о нем и говорит.

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

реанимирую сию тему =)

Что следует знать и уметь, чтобы после окончания универа получить должность системного аналитика?.. В следующем году заканчиваю ВУЗ (ХИРЭ, если мож кто знает=) ) как раз по этой специальности, и квалификация будет соответствующая, но есть одно "но" =) - готовят нас уж совсем со стратегическим прицелом, то есть такая база, как понимание системного подхода, различные методы оптимизации, исследование операций и д.р. вещи такого плана дают очень мощно (что само по себе конечно очень неплохо - происходит именно формирование этого самого системного взгляда на вещи, миропонимания с точки зрения системного подхода) и в то же время почти совершенно упускают современные технологии и методики, что как раз не есть гут... Из технологий изучали только SSADM, UML прошел мимо вовсе... Кое-как рассказали про PowerDesigner (чуток поработали с DFD-диаграммами), скоро вот BPWin пойдет, но боюсь на том же уровне...  Я уже молчу про RUP, Agile и т.д. и т.п... Так вот хочется у вас спросить - что следует изучить (инструментальные средства, технологии, книги какие почитать) за то время, которое у меня осталось (год с небольшим выходит), чтобы после выпуска я имел максимальные шансы на трудоустройство именно системным аналитиком? Сейчас пока работаю простым девелопером на J2EE, что в принципе свой плюс также дало - по крайней мере знаю, как оно там изнутри в больших проектах все делается =)

Заранее спасибо =) 

 по разработке требований - Вигерса "Разработка требований к программному обеспечению"

пожалуйста скажите где можно заказать эту книгу в твёрдом переплёте

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

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

Вот на одном из своих бывших мест работы моя должность так называлась - "Системный аналитик". Реально это означало лишь, что мне просто ставили проблему и я её решал полностью сам. Т.е. говорит тебе твой начальник что есть такая-то проблема в таком-то подразделении - ты идёшь туда, начинаешь спрашивать и выяснять для себя - что и как тебе с этим делать. Пишешь небольшой документ о том, как ты видешь её решение при помощи программирования - эту бумажку утверждаешь у своего начальника и у конечных пользователей. Затем как царевна-лягушка перерождаешься в разработчика и уже кодишь. Потом внедряешь, обучаешь пользователей, принимаешь их жалобы, некоторые выполняешь, некоторые откладываешь... Помощников у меня не было - я всё делал сам и нанимать людей себе в помощь не мог, соответственно постепенно тонул в support`е...

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

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

Хотя у нас тестировщики тоже иногда в аналитики выбираются, но это довольно сложно.

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


В довершение всего, в последнее время стало очень модно в момент обсуждения какого-то вопроса выйти и с умным видом сказать "во всём нужен СИСТЕМНЫЙ ПОДХОД!" и после этого прогнать какую-нибудь чушь, но так, что никто и не осмелится возразить, потому что им стыдно признаться, что они не знают - что такое системный подход. При этом, как я не раз убеждался, говорящий это, о системном подходе не имеет ни малейшего понятия, но хочет называться аналитиком, притом неприменно системным.

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


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

Это сообщение отредактировал(а) Се ля ви - 19.3.2007, 18:20

Ну, скажем так, я представляю себе системного аналитика, как человека, способного провести автоматизацию некоторого объекта или организации, как с нуля, так и уже основываясь на существующих там наработках. Соответственно, этот чел должен уметь провести анализ бизнес-процессов внутри организации и ее внешние связи, если таковые будут важны для автоматизации объекта, разобраться в предметной области, на основании этого составить сначала общую картину деятельности внутри объекта, затем декомпозировать ее до необходимого уровня абстракции (чтобы в дальнейшем можно было бы выделить различного рода подсистемы по организационному, функционалному признакам и др. и пр.), на основании понимания полученной картины суметь составить грамотное ТЗ, доступно объяснить своим коллегам по ИТ, что он хочет от них получить, если нет архитектора - разработать архитектуру. Далее - взаимодействие с заказчиком, уточнение и дополнение ТЗ (я вообще приверженец экстремального программирования  ), ну и отражение всей это деятельности на процессе разработки - внесение различного рода изменений в проект системы, возможно непосредственно общаясь с разработчиками, или через ПМ-а.. Если нужно - выполнить некоторую часть проекта руками, например, чтобы разработчики имели перед глазами пример какого-нибудь реализованного архитектурного решения - по экзамплам всегда легче разобраться.. Ну вот в целом так 

Это сообщение отредактировал(а) Aazmandius - 19.3.2007, 20:00