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

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

Получившие благодаря автоматизированным средствам, позволяющим создавать модели, нотации IDEF0 (BPWin), IDEF1X (ERWin), IDEF2 (BPWin) и IDEF3 (BPWin)) "методологией системного анализа" не являются.

Здесь понятно, нотации методологией не являются, это логично.

То же самое можно отнести и к ARIS (существенно испорченной вариации BPMN), и к UML (языку описания систем).

Забудем UML, он в голосовалке для ровного счета добавлен, но с каких это пор методология ARIS стала нотацией (да еще и вариацией нотации BPMN)?

SADT стоит немного в стороне: это, конечно, методология, но она охватывает отнюдь не только системный анализ, а опять же весь жизненный цикл проектирования и внедрения систем.

Прогнозируя ваш вопрос (почему ARIS методология), прошу сначала доказать, что SADT является методологией.

Уважаемый/ая, igusew. Воздержитесь, пожалуйста, от той формы общения, которую Вы тут избрали. Обсуждайте свой вопрос конструктивно и общайтесь с оппонентами уважительно. Спасибо за понимание.

У меня есть подозрение, что Наталья тоже этого не знает.

Ну как же так?
С одной стороны, если яндекс нам не врет, Наталья ушла на вольные хлеба с должности руководителя отдела системного анализа НПК "Высокие технологии и стратегические системы".
С другой, она с легкостью может дать оценку состояния отрасли по стране в целом.
Такой человек явно что-то знает! "I want to believe" (с)!

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

Да, но это определение явления через его влияние на окружающий мир. Само явление при этом остается черным ящиком.
Эдак и я умею: СА - деятельность, направленная на создание образа будущей системы в форме графических моделей, текстовых описаний, эскизов интерфейсов и т.п.
(вспомнил вкладыши к жвачкам "love is...")

Уважаемый/ая, igusew. Воздержитесь, пожалуйста, от той формы общения, которую Вы тут избрали. Обсуждайте свой вопрос конструктивно и общайтесь с оппонентами уважительно. Спасибо за понимание.

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

Да и прошу не особенно привязываться к первым трем пунктам голосовалки, они сделаны как ответ на вопрос Леонида:

А что в Вузе говорили про методологию системного анализа?

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

Леонид, я привел часть известных мне определений. Раскрывать суть системного анализа не хочется, поскольку она разная с учетом точки зрения. Хотя в общем смысле СА предполагает ряд принципов, которые основаны на системном подходе.

Вообще эта тема довольно широко обсуждалась лет 5 назад. Я соглашусь с Натальей Желновой, что все перечисленные топикстартером методологии не являются методологиями только СА, но являются методологиями системной деятельности, т.е. покрывают весь (ну или часть) ЖЦ.

Если взять за основу то, что преподается в университетах (беру не наши, а зарубежные университеты), то СА

SYSTEMS ANALYSIS The purpose of the systems analysis phase is to build a logical model of the new system. The first step is requirements modeling, where you investigate
business processes and document what the new system must do to satisfy users. Requirements modeling continues the investigation that began during the systems planning phase. To understand the system, you perform fact-finding using techniques such as interviews, surveys, document review, observation, and sampling. You use the factfinding results to build business models, data and process models, and object models.     
The deliverable for the systems analysis phase is the system requirements document. The system requirements document describes management and user requirements, costs and benefits, and outlines alternative development strategies.

Т.е. СА может рассматриваться как научная дисциплина, или как фаза процесса системного строительства. Как фаза - это по сути работа с требованиями.

Леонид, я привел часть известных мне определений.

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

Если взять за основу то, что преподается в университетах (беру не наши, а зарубежные университеты), то СА
SYSTEMS ANALYSIS The purpose of the systems analysis phase is to build a logical model of the new system.

Вот до сих я с зарубежными университетами соглашусь.

The first step is requirements modeling, where you investigate
business processes and document what the new system must do to satisfy users. Requirements modeling continues the investigation that began during the systems planning phase. To understand the system, you perform fact-finding using techniques such as interviews, surveys, document review, observation, and sampling. You use the factfinding results to build business models, data and process models, and object models.     
The deliverable for the systems analysis phase is the system requirements document. The system requirements document describes management and user requirements, costs and benefits, and outlines alternative development strategies.

А вот с этим не могу. На мой вкус, эта часть относится к тому, что принято называть бизнес-анализом. И является лишь подготовительным этапом для "to build a logical model of the new system". Просто потому, что на выходе мы в лучшем случае получим документ с человеко-ориентированной моделью "как есть", перечнем плюсов-минусов затеваемого и направления дальнейшего развития.

Вообще, они честно признаются, для чего это нужно: "You use the factfinding results to build business models, data and process models, and object models." (причем это будет потом, поскольку в "The deliverable for the systems analysis phase" все это не упомянуто).

Впрочем - контекст, контекст и еще раз контекст.

Т.е. СА может рассматриваться как научная дисциплина,...

Может (как и управление).

...или как фаза процесса системного строительства. Как фаза - это по сути работа с требованиями.

Фаза протяженностью во все строительство. Поскольку сначала мы собираем данные для формирования требований, потом формируем их, потом реализуем (видоизменяя в процессе), потом проверяем, что получилось.

Я соглашусь с Натальей Желновой, что все перечисленные топикстартером методологии не являются методологиями только СА, но являются методологиями системной деятельности, т.е. покрывают весь (ну или часть) ЖЦ.

Уточняю, что ARIS уважаемая Наталья за методологию не считает.

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

Если понимать под системным анализом то, что должен делать Аналитик на проекте по разработке/внедрению ПО (т.е. requirements engineering), то как таковой методологии системного анализа нет. Также как и нет отдельно методологии тестирования и кодирования. А имеет ли смысл методология анализа в отрыве от всего цикла разработки ПО?

А что есть?
1. Своды знаний в области софта, по которым можно понять, что нужно делать аналитику.
2. Методологии (framework) разработки ПО, в которых системный анализ - это одна из дисциплин
3. Стандарты по оценке,  в которых системный анализ - это одна из дисциплин

А имеет ли смысл методология анализа в отрыве от всего цикла разработки ПО?

Если
1. воспринимать анализ в контексте того, что я писал чуть выше ("создание образа будущей системы", оно же "проектирование"), или что говорят "зарубежные университеты" ("to build a logical model of the new system"),
2. помнить, что в отечественной практике по сей день цветут и пахнут не только ОКР, но и НИР,

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

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

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

Structured Analysis and Design Technique - вот что такое SADT. Почитать можно тут: http://dit.isuct.ru/ivt/books/CASE/case8/sadt_index.htm
SADT - не является стандартом.

Да, я понимаю Ваше сомнение, в том смысле, что SADT не дает явных инструментов например реализации системы. Да в этом смысле SADT не поддерживает все этапы ЖЦ, как впрочем и ARIS. Тут, скажем, так я погорячился.

Не уверен, что я доживу до дня, когда увижу "методологию творчества и созидательного начала" версии хотя бы 1.0.

Это не потянет? http://www.methodolog.ru/

Это не потянет? http://www.methodolog.ru/

Не потянет.

Авторы отталкиваются от: "Методология – это учение об организации деятельности. Такое определение однозначно детерминирует и предмет методологии – организация деятельности. Этим определением мы и пользуемся."

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

Не поспоришь: действительно известно, как организовать научную (как наиболее близкую к нашему случаю) работу. То есть, как создать условия для продуктивной (см. определение авторов) деятельности организационной системы (см. рис.1 авторов).
У того же Л.П. Берии, к примеру, прекрасно получалось даже без глубоких философских изысканий.

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

Structured Analysis and Design Technique - вот что такое SADT. Почитать можно тут: http://dit.isuct.ru/ivt/books/CASE/case8/sadt_index.htm
SADT - не является стандартом.

Не понятно на счет стандарта. А РД IDEF0 2000? ://www.staratel.com/iso/IDEF/IDEF0/IDEF0Rus.pdf

Не понятно на счет стандарта. А РД IDEF0 2000? ://www.staratel.com/iso/IDEF/IDEF0/IDEF0Rus.pdf

Эдуард имеет ввиду классическую книжку Марка и Макгоуэна по методологии SADT. Вы же имеете в виду российский стандарт по "методологии" IDEF0. Вы его только Наталье Желновой не показывайте. 

Не понятно на счет стандарта. А РД IDEF0 2000? ://www.staratel.com/iso/IDEF/IDEF0/IDEF0Rus.pdf

IDEF- стандарт США, национальный. Немеждународный, если не обманываюсь. SADT методология. Стандарт основан на методологии. Но это не тождественные понятия. Я высказываю свое мнение. Естественно.