Модераторы: Се ля ви

Поиск:

Ответ в темуСоздание новой темы Создание опроса
> Как стать системным аналитиком? если душа просит =) 
:(
    Опции темы
Bose
  Дата 14.12.2005, 11:55 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Участник Клуба
Сообщений: 1458
Регистрация: 5.3.2005
Где: Riga, Latvia

Репутация: 1
Всего: 51



Что нужно для того, чтобы соответствовать требованиям предъявляемым к системному аналитику при приёме на работу? Насколько реально получить такие знания самому? Какую литературу нужно изучить? Какие инструменты и насколько глубоко нужно/желательно освоить?
PM MAIL WWW Skype   Вверх
AntonSaburov
Дата 14.12.2005, 12:55 (ссылка) |    (голосов:1) Загрузка ... Загрузка ... Быстрая цитата Цитата


Штурман
****


Профиль
Группа: Модератор
Сообщений: 5658
Регистрация: 2.7.2002
Где: Санкт-Петербург

Репутация: нет
Всего: 118



Во-первых - хотеть этим заниматься.
Во-вторых - понимать, что программироать будешь редко
В-третьих - почитать книги по ОО анализу, дизайну, проектированию. Также хорошо посмотреть паттерны проектирования.
PM MAIL WWW ICQ   Вверх
Се ля ви
Дата 14.12.2005, 13:20 (ссылка) |    (голосов:1) Загрузка ... Загрузка ... Быстрая цитата Цитата


Java/SOAрхитектор
****


Профиль
Группа: Модератор
Сообщений: 2016
Регистрация: 5.6.2004
Где: place without tim e and space

Репутация: 3
Всего: 127



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

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

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

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

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

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

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

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

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

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

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


--------------------
  )
 (
[_])
проф. блог

Кролики думали, что занимаются любовью, а на самом деле их просто разводили...
PM MAIL WWW Skype GTalk   Вверх
ida
Дата 14.12.2005, 13:45 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


замужем
****


Профиль
Группа: Завсегдатай
Сообщений: 2277
Регистрация: 14.5.2002
Где: Санкт-Петербург

Репутация: 6
Всего: 58



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

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

Это сообщение отредактировал(а) ida - 12.1.2006, 09:56
PM WWW   Вверх
Bose
Дата 14.12.2005, 15:01 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Участник Клуба
Сообщений: 1458
Регистрация: 5.3.2005
Где: Riga, Latvia

Репутация: 1
Всего: 51



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

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

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


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

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

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

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

Цитата

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

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


последний пункт меня заинтриговал... интересно, что за инструменты такие. Rational Rose и иже с ним?
PM MAIL WWW Skype   Вверх
Се ля ви
Дата 14.12.2005, 15:23 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Java/SOAрхитектор
****


Профиль
Группа: Модератор
Сообщений: 2016
Регистрация: 5.6.2004
Где: place without tim e and space

Репутация: 3
Всего: 127



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

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

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

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


--------------------
  )
 (
[_])
проф. блог

Кролики думали, что занимаются любовью, а на самом деле их просто разводили...
PM MAIL WWW Skype GTalk   Вверх
Bose
Дата 14.12.2005, 15:32 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Участник Клуба
Сообщений: 1458
Регистрация: 5.3.2005
Где: Riga, Latvia

Репутация: 1
Всего: 51



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

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

А если их разделить, то в моём представлении получается, что аналитик решает задачу в целом, а архитектор уже думает над тем, как это воплотить. Но тогда же получается, что между заказчиком и программистами стоит не одно звено, но два Системный Аналитик и Архитектор. Так?
PM MAIL WWW Skype   Вверх
ida
Дата 14.12.2005, 15:45 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


замужем
****


Профиль
Группа: Завсегдатай
Сообщений: 2277
Регистрация: 14.5.2002
Где: Санкт-Петербург

Репутация: 6
Всего: 58



Цитата(Bose @ 14.12.2005, 16:01)
В общем упрощая все, получается, что системный аналитик после исследования передает разработчикам схемы модулей системы и схемы взаимодействия этих модулей.

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

Это сообщение отредактировал(а) ida - 12.1.2006, 09:57
PM WWW   Вверх
Се ля ви
Дата 14.12.2005, 15:49 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Java/SOAрхитектор
****


Профиль
Группа: Модератор
Сообщений: 2016
Регистрация: 5.6.2004
Где: place without tim e and space

Репутация: 3
Всего: 127



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

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

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


--------------------
  )
 (
[_])
проф. блог

Кролики думали, что занимаются любовью, а на самом деле их просто разводили...
PM MAIL WWW Skype GTalk   Вверх
ida
Дата 14.12.2005, 16:10 (ссылка) |    (голосов:1) Загрузка ... Загрузка ... Быстрая цитата Цитата


замужем
****


Профиль
Группа: Завсегдатай
Сообщений: 2277
Регистрация: 14.5.2002
Где: Санкт-Петербург

Репутация: 6
Всего: 58



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

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

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

Это сообщение отредактировал(а) ida - 12.1.2006, 09:58
PM WWW   Вверх
podval
Дата 15.12.2005, 10:56 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Где я? Кто я?
****


Профиль
Группа: Экс. модератор
Сообщений: 3094
Регистрация: 25.3.2002
Где: СПб

Репутация: 3
Всего: 62



Цитата(ida @ 14.12.2005, 16:10)
Вообще говоря, тут наблюдается путаница, как верно заметил Се ля ви. Во-первых, я не знаю, кто такой "системный аналитик".


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

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

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



PM WWW ICQ   Вверх
Aazmandius
Дата 18.3.2007, 02:22 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


O_o
*


Профиль
Группа: Участник
Сообщений: 135
Регистрация: 29.4.2006
Где: Vancouver

Репутация: 1
Всего: 6



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

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

Заранее спасибо =) 
PM WWW   Вверх
Всемогущий
Дата 18.3.2007, 07:24 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 440
Регистрация: 25.6.2006
Где: Челябинск

Репутация: нет
Всего: 13



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

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


--------------------
Цитата(smartov @  16.1.2007,  13:26 Найти цитируемый пост)
Видел я PHP код, который пишут наСильники, никогда на php не писавшие  :D  То еще зрелище. Все пытаются сделать руками и через ж (как в С привыкли). Все пытаются память освобождать итд итп. 
PM MAIL ICQ   Вверх
Се ля ви
Дата 19.3.2007, 18:15 (ссылка) |    (голосов:1) Загрузка ... Загрузка ... Быстрая цитата Цитата


Java/SOAрхитектор
****


Профиль
Группа: Модератор
Сообщений: 2016
Регистрация: 5.6.2004
Где: place without tim e and space

Репутация: 3
Всего: 127



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

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

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

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

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

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

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


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

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


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

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


--------------------
  )
 (
[_])
проф. блог

Кролики думали, что занимаются любовью, а на самом деле их просто разводили...
PM MAIL WWW Skype GTalk   Вверх
Aazmandius
Дата 19.3.2007, 19:55 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


O_o
*


Профиль
Группа: Участник
Сообщений: 135
Регистрация: 29.4.2006
Где: Vancouver

Репутация: 1
Всего: 6



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

Это сообщение отредактировал(а) Aazmandius - 19.3.2007, 20:00
PM WWW   Вверх
Aazmandius
Дата 21.3.2007, 00:16 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


O_o
*


Профиль
Группа: Участник
Сообщений: 135
Регистрация: 29.4.2006
Где: Vancouver

Репутация: 1
Всего: 6



2 Се ля ви
все надеюсь на продолжение разговора smile 

Сорри за оффтоп smile
Кстати, ЖЖ у тебя супер! Прочитал весь и попутно твой креатив про программистов - респект! Очень многое совпадает с моими взглядами smile Было очень интересно 
PM WWW   Вверх
Се ля ви
Дата 21.3.2007, 01:52 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Java/SOAрхитектор
****


Профиль
Группа: Модератор
Сообщений: 2016
Регистрация: 5.6.2004
Где: place without tim e and space

Репутация: 3
Всего: 127



Aazmandius, как-то немного сумбурно...

Прежде всего - ты уверен, что ты годишься на роль аналитика? Что это будет хорошо у тебя получаться?

Цитата(Aazmandius @  19.3.2007,  19:55 Найти цитируемый пост)
я представляю себе системного аналитика, как человека, способного провести автоматизацию некоторого объекта или организации, как с нуля, так и уже основываясь на существующих там наработках.

Нехило! smile

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

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


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

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

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

Цитата(Aazmandius @  19.3.2007,  19:55 Найти цитируемый пост)
этот чел должен уметь провести анализ бизнес-процессов внутри организации и ее внешние связи, если таковые будут важны для автоматизации объекта, разобраться в предметной области, на основании этого составить сначала общую картину деятельности внутри объекта, затем декомпозировать ее до необходимого уровня абстракции (чтобы в дальнейшем можно было бы выделить различного рода подсистемы по организационному, функционалному признакам и др. и пр.), на основании понимания полученной картины суметь составить грамотное ТЗ, доступно объяснить своим коллегам по ИТ, что он хочет от них получить

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

А если ты ещё и работаешь не внутри конторы заказчика, то есть ещё и четвёртая сторона - твоё собственное руководство, у которого тоже свои интересы.

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


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

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


--------------------
  )
 (
[_])
проф. блог

Кролики думали, что занимаются любовью, а на самом деле их просто разводили...
PM MAIL WWW Skype GTalk   Вверх
Aazmandius
Дата 21.3.2007, 02:24 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


O_o
*


Профиль
Группа: Участник
Сообщений: 135
Регистрация: 29.4.2006
Где: Vancouver

Репутация: 1
Всего: 6



Цитата

Прежде всего - ты уверен, что ты годишься на роль аналитика? Что это будет хорошо у тебя получаться?
 Мало ли я в чем уверен? Вскрытие покажет... smile Желание есть, способностей надеюсь, что хватит, так что буду стараться, а жизнь все расставит на свои места.
Цитата

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

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

Согласен 100%! Так и стараюсь работать (в пределах своих девелоперских полномочий конечно smile )
Цитата

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

То есть ты предлагаешь описать эту должность с точки зрения занимаемого положения в организации? smile Честно говоря, как оно в больших компаниях - я даже не представляю smile Сейчас работаю в относительно небольшой компании (хотя проекты тут серьезные и большие, автоматизируем страховые компании), тут все в общем-то многостаночники smile и кроме директоров из начальства есть только лидеры групп, которые всем и занимаются - и анализом, и проектами руководят, и кодят наравне со всеми smile Надо сказать, все у них получается хорошо, что б ни говорили по поводу того, что нельзя одновременно вести проекты и их же разрабатывать - на каждой группе по 3 проекта висит, и все окей smile Короче, XP+Agile рулят smile И отношения между людьми на 90% дружеские, и с начальством в т.ч. А вот как оно в больших конторах, я могу только догадываться smile

Все вышеизложенное мной касаемо понимания subj составлено на основании того, о чем нам вот уже какой год рассказывают в универе, так что услышать альтернативное мнение оказалось очень полезным smile Хотя большую часть того, что ты написал, я и так интуитивно понимал (что касается удовлетворить клиента smile и работы с программистами - сам ведь сейчас разработчик smile так что как и что нужно программисту - знаю на собственной шкуре smile) А все те грабли, которые ты описал
Цитата

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

по-моему могут рещаться в рамках экстремального программирования, недаром оно мне так нравится (хотя может я и заблуждаюсь - реально ведь проектом не руководил никогда smile

Цитата

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

И отдельное данке за предупреждения
Цитата

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

Цитата

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

Постараюсь такого расклада не допустить smile А так, я и занимаюсь как раз тем, что
Цитата

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

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

PM WWW   Вверх
ida
Дата 21.3.2007, 17:12 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


замужем
****


Профиль
Группа: Завсегдатай
Сообщений: 2277
Регистрация: 14.5.2002
Где: Санкт-Петербург

Репутация: 6
Всего: 58



Прочитала вопрос: "как стать системным аналитиком?" и захотелось простонать в ответ: "а может, не надо?....."

 smile 

Прежде всего необходимо получить техническое образование.
Заостряю внимание - ТОЛЬКО техническое! гуманитарный цикл или естественно-научный тут не пойдет, т.к. вам потребуется математика в объеме 3 курсов, чтобы научиться правильно мыслить.
98% аналитиков это люди с высшим образованием.

Затем необходимо поработать в течение 2-3 лет в сфере автоматизации.

Изучить теорию программирования и сущность объектно-ориентированного подхода так, чтобы его понятия стали для вас естественными.

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

Прочитать следующие книги:
Разработка требований к ПО
Объектно-ориентированное моделирование и разработка
Методы описания функциональных требований
Анализ требований и проектирование систем
первые две - необходимо, остальные - опционально.

Развить коммуникативные навыки:
1. Проведение интервью
2. Телефонное общение
3. Деловая переписка

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

Важно свято помнить 2 вещи:

1. Никакие инструментальные средства тебе не помогут, если ты не знаешь, КАК создавать модели. А для этого нужно знать, что такое объектно-ориентированный анализ и в какой последовательности его осуществлять. Модель - это результат умственного труда аналитика, а не работы программы. Она создается в голове, и лишь потом переносится в память ЭВМ.

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

Это сообщение отредактировал(а) Се ля ви - 22.4.2007, 15:31
PM WWW   Вверх
Aazmandius
Дата 21.3.2007, 19:53 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


O_o
*


Профиль
Группа: Участник
Сообщений: 135
Регистрация: 29.4.2006
Где: Vancouver

Репутация: 1
Всего: 6



Спасибо за советы, обязательно постараюсь все учесть smile Все, что описано, в той или иной мере присутствует =) Образование у меня будет именно техническое (ф-т Компьютерных Наук) и математику и всевозможные моделирования систем разных видов (математическое, динамическое, объектный подход...) нам читали и читают, так что суть создания модели я понимаю и это у меня получается, более того - это мне нравится smile Конечно, уровень моих умений пока невысок, но база уже заложена, суть я в той или иной мере ухватил - буду совершенствоваться smile ООА уже настолько въелся в мой мозг, что как когда-то разработки велись по другому я себе уже слабо представляю. Так что тут тоже остается только расти выше, суть опять-таки понятна. А вот 
Цитата

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

Большое спасибо за очерчивание круга TODO's smile Буду продвигаться в этом направлении. Если есть еще какие-нибудь дополнительные замечания или пожелания - с радостью выслушаю smile

З.Ы.: +1 to ida и Се ля ви
За активное участие, советы и помощь smile
PM WWW   Вверх
Gunslinger
Дата 22.4.2007, 11:03 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 842
Регистрация: 30.12.2006
Где: Астрахань

Репутация: нет
Всего: 3



Чтобы не создавать тему, пишу здесь. Купил книгу Рамбо и Блаха "UML 2.0. Объектно-ориентированное моделирование и разработка" 2-е издание.
Вначале, где описываются этапы процесса разработки.
1. Концептуализация системы.
2.Анализ.
3. Проектирование системы.
4. Проектирование классов.
5. Реализация.

На 1м этом этапе создается ТЗ со всеми требованиями? Или же требования дорабатываются и на следующем этапе? То есть концептуализация системы и анализ связаны друг с другом циклом и только после определенного количества итераций ТЗ готово и только затем передается на этап проектирования системы?
Относительно этапа 2. Создвается модель предметной области и модель приложения. Модель приложения - способ отображения программы, цветовая гамма, кнопочки и менюшки (с соответствующими обработчиками), и все прочее? А модель предметной области - это основное, вся программная начинка. Я правильно понял? 
PM MAIL   Вверх
Се ля ви
Дата 22.4.2007, 15:25 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Java/SOAрхитектор
****


Профиль
Группа: Модератор
Сообщений: 2016
Регистрация: 5.6.2004
Где: place without tim e and space

Репутация: 3
Всего: 127



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

user posted image

Если интересно более подробно, почитай что-нибудь про RUP.

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


--------------------
  )
 (
[_])
проф. блог

Кролики думали, что занимаются любовью, а на самом деле их просто разводили...
PM MAIL WWW Skype GTalk   Вверх
ida
Дата 23.4.2007, 09:15 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


замужем
****


Профиль
Группа: Завсегдатай
Сообщений: 2277
Регистрация: 14.5.2002
Где: Санкт-Петербург

Репутация: 6
Всего: 58



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

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

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

Это сообщение отредактировал(а) ida - 23.4.2007, 09:16
PM WWW   Вверх
Gunslinger
Дата 23.4.2007, 18:24 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 842
Регистрация: 30.12.2006
Где: Астрахань

Репутация: нет
Всего: 3



Понятно. Четкое разграничение в книге - в реальной ситуации условно. А относительно модели приложения? Все эти графические объекты и их обработчики, они тоже фигурируют в моделях состояний и взаимодействия? Т. е. в диаграммы включаются и графические объекты (например, кнопки с обработчиками или поле для отображения графиков), или только программная начинка?  
PM MAIL   Вверх
ida
Дата 24.4.2007, 08:17 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


замужем
****


Профиль
Группа: Завсегдатай
Сообщений: 2277
Регистрация: 14.5.2002
Где: Санкт-Петербург

Репутация: 6
Всего: 58



Gunslinger, я же объяснила - у каждого разработчика свои правила.
Рассматривать теорию в отрыве от практики бесполезно.

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

У вас программистский подход - требуете четких правил в такой области, где их быть не может. Здесь нужен только опыт, который позволяет определить, в какой ситуации какие модели нужны. Универсальных вариантов нет.
PM WWW   Вверх
Се ля ви
Дата 24.4.2007, 11:30 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Java/SOAрхитектор
****


Профиль
Группа: Модератор
Сообщений: 2016
Регистрация: 5.6.2004
Где: place without tim e and space

Репутация: 3
Всего: 127



Gunslinger, могу ответить цитатой из Мартина Фаулера:

Цитата
Why Bother with the UML?

Graphical design notations have been with us for a while. For me, their primary value is in communication and understanding. A good diagram can often help communicate ideas about a design, particularly when you want to avoid a lot of details. Diagrams can also help you understand either a software system or a business process. As part of a team trying to figure out something, diagrams both help understanding and communicate that understanding throughout a team. Although they aren't, at least yet, a replacement for textual programming languages, they are a helpful assistant.

Many people believe that in the future, graphical techniques will play a dominant role in software development. I'm more skeptical of that, but it's certainly useful to have an appreciation of what these notations can and can't do.

Of these graphical notations, the UML's importance comes from its wide use and standardization within the OO development community. The UML has become not only the dominant graphical notation within the OO world but also a popular technique in non-OO circles.

http://safari.oreilly.com/0321193687/pref07


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

Это сообщение отредактировал(а) Се ля ви - 24.4.2007, 11:30


--------------------
  )
 (
[_])
проф. блог

Кролики думали, что занимаются любовью, а на самом деле их просто разводили...
PM MAIL WWW Skype GTalk   Вверх
Gunslinger
Дата 25.4.2007, 10:47 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 842
Регистрация: 30.12.2006
Где: Астрахань

Репутация: нет
Всего: 3



ida, не знал, как правильно выразиться, вот и сказал, как мне ближе. Под программистской начинкой подразумевал задачу, разобранную на классы и связанную в техпроцесс. Т. е. как пример в книге про брокерскую контору. Определили сущности, которые принимают участие в работе, связали. 
PM MAIL   Вверх
ida
Дата 25.4.2007, 11:15 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


замужем
****


Профиль
Группа: Завсегдатай
Сообщений: 2277
Регистрация: 14.5.2002
Где: Санкт-Петербург

Репутация: 6
Всего: 58



Главное, понимать, какие классы вы моделируете - предметной области или программные smile
Первое часто полезно. Второе ИМХО в промышленной разработке ни к чему.
PM WWW   Вверх
SergeBS
Дата 1.6.2007, 12:25 (ссылка) |  (голосов:2) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1111
Регистрация: 10.6.2005
Где: Владимир

Репутация: нет
Всего: 22



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

ИМХО - неверно. 
Аналитик - не посредник. Задача аналитика - разобраться в процессах и их взаимосвязи, создать модель эффективной работы организации. Т.е. "заполнить черный ящик". На входе у этого ящика - внешние воздействия на организацию (отдел, участок ...), на выходе - реакция на эти воздействия. Внутри - ресурсы, их распределение, взаимодействие. Это не посредничество. Это достаточно муторная и неблагодарная работа - разобраться в функционале объекта автоматизации (далее ОА) и создать модель его эффективной работы. Просто посредничеством тут не обойдешься, поскольку заказчик хочет, чтобы "было хорошо", но при этом как правило существующая схема работы - из рук вон плохая, требуется переделка связей и функций  внутри ОА. И соответственно имеем главную проблему: проблему доверия заказчика. Его нужно убедить в том, что нужно изменение. Для этих целей и служат всякие диаграммы, авторитет разработчика и т.п. Отсюда - 2 задачи аналитика:
1. Построить правильную модель ОА.
2. Убедить заказчика, что она правильна (или замаскировать под что-то ему понятное и приемлемое).
И дальше аналитик корректирует модель по следам жизненных пертурбаций.
Архитектор получает модель и определяет - какими средствами ее воплотить в жизнь. Ну и раздает задачи програмистам.
Программист, получив задачу, разбивает ее на фукциональные блоки и раскидывает по кодерам, которые находятся в самой нижней части иерархии.  
Соответственно кодер, имея фунцию, которую нужно реализовать, ее кодит smile.
Результаты кодинга скидываются тестерам, те в меру вредности капают на мозги программистам, которые либо просто спихивают ошибки на исправление кодерам, либо еще и функциональные блоки переделывает и опять же на кодеров спихивает.
Ну и т.д.
Относительно сбоку от основного производственного процесса - дизайнер, тех.писатель, техсаппорт.
Дизайнер пудрит мозги программистам и кодерам, где, что и как должно располагаться и быть выкрашено.
Тех.писатель на доступном 5-класснику языке расхваливает в документации (будущий) продукт и на какую кнопку там нужно нажать, чтобы Doom был спрятан за отчетом о поставке фигурных скрепок смежной конторе smile.
Что делает техсаппорт - все знают.

Реально такие конструкции бывают только в очень крупных проектах. А в большинстве случаев аналитик, архитектор и дизайнер - один и тот же человек. Хорошо если при этом ему не приходится еще и программировать :(. Программист как правило еще и кодер. Тестером часто оказывается заказчик или программист-сосед. Техписатель - как получится. Тут вообще никаких тенденций. Техсаппорт - девочка в отделе делопроизводства smile. Или программист, первый поднявший трубку телефона.

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

П: "Я только программировать умею, скажите, что писать!"

Это не программист. Кодер. Считающий себя программистом.

Да, если не забуду, в понедельник закину реквизиты полезной (с моей точки зрения) книжки на тему управления проектом и т.п. Дома она.
PM MAIL   Вверх
ida
Дата 20.6.2007, 08:59 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


замужем
****


Профиль
Группа: Завсегдатай
Сообщений: 2277
Регистрация: 14.5.2002
Где: Санкт-Петербург

Репутация: 6
Всего: 58



SergeBS, так я и не поняла, почему аналитик не посредник smile Все остальное изложено довольно правильно.

Аналитик это посредник, т.к. заказчик не общается напрямую с программистами. Вы понимаете смысл слова "посредник"? smile ПОСРЕДством ТЗ программист получает требования заказчика. А ТЗ пишет аналитик.

Больших проектов много. Поэтому чистые системные аналитики есть.
Утверждаю из опыта.
PM WWW   Вверх
boloeng
Дата 9.6.2008, 16:28 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 7
Регистрация: 4.6.2008

Репутация: 1
Всего: 1



SergeBS, вот мое мнение по поводу твоего поста:
Цитата

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

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

Соответственно кодер, имея фунцию, которую нужно реализовать, ее кодит .

Это что-то мне не напоминает объектно ориентированный подход? Шо то больше подходит на функциональное программирование.
А разбивка на программиста и кодера, мне вообще не понятна :-(. Кодер, это тот кто только -что выучил синтаксис, какого нибудь высокоуровнего языка программирования? А где таких учат? В подвалах и на компьютерных курсах? По моему у нас в ВУЗах человек выходит инженером-программистом, как минимум, и основы процесса проектирования ПО, равно как и тестирования в ВУЗах изучают.
Ну, а то что в небольших конторах, каждый и швец и жнец и на дуде игрец, так это потому, что у нас подход к вопросу проектирования орг-структуры девелоперских контор, простите за каламбур - ламерский(несистемный) и в большинстве случаев идет снизу. И естественно, что аналитик, если такая должности и есть и даже допустим занимается он анализом и моделированием будующего ПО, рупь за сто в прошлом програмер, ведь кто еще должен заниматься созанием ПО? smile Я сейчас столкнулся с несколькими средними програмерскими конторами - и был приятно удивлен, что в их рядах есть очень грамотные аналитики, как говориться "освобожденные" от выполнения програмерских обязанностей.
В этом вопросе мне крайне нравиться позиция ida, буду следить за ее постами и осваивать системный анализ по указанной здесь литературе.

Это сообщение отредактировал(а) boloeng - 9.6.2008, 16:38
PM MAIL   Вверх
Brilliant
Дата 3.9.2008, 12:46 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 1
Регистрация: 3.9.2008
Где: Саратов

Репутация: нет
Всего: нет



Здравствуйте. Я наткнулась на ваш форум случайно, мне он понравился и я зарегистрировалась. Если не секрет кто-то работает реально системным аналитиком в данный момент? Я пять лет назад закончила технический университет по специальности информатик-менеджер (преподаватели сами не понимали что это за специальность, знаний нам давали во всех областях в общем и программирование, и сети, и железо, и экономика и юридический уклон).В своем городе, после окончания работала программистом по 1С, занималась системой менеджмента качества, системным администрированием, железом, в данный момент работаю опять программистом. Дипломную работу писала по разработке информационной системы, с использованием UML и RationalRose.В ощем все было красиво, но вот только от этих знаний ничего не осталось. Хочу переквалифицироваться в системного аналитика перехать в Москву, устроиться хотя бы помошником системного аналитика для начала. Могу ли я с данным образованием и опытом работы устроиться или нужно определенной образование и где его можно получить?
PM MAIL ICQ   Вверх
Страницы: (3) [Все] 1 2 3 
Ответ в темуСоздание новой темы Создание опроса
Правила форума "Системный анализ, проектирование и UML"
Се ля ви

Форум "Системный анализ, проектирование и UML" предназначен для обсуждения вопросов, так или иначе связанных с этапами жизненного цикла автоматизированных (программных, информационных, автоматических) систем:

• предпроектные обследования объектов автоматизации;

• разработка концепции создания систем;

• моделирование бизнес-процессов (в т.ч. на UML);

• проектирование архитектуры систем;

• управление проектами;

• управление качеством;

• CASE-средства;

• реинжиниринг.


Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, Се ля ви.

 
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема | Системный анализ, проектирование и UML | Следующая тема »


 




[ Время генерации скрипта: 0.1496 ]   [ Использовано запросов: 21 ]   [ GZIP включён ]


Реклама на сайте     Информационное спонсорство

 
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности     Powered by Invision Power Board(R) 1.3 © 2003  IPS, Inc.