Здравствуйте, уважаемые системные аналитики!) Нужен ваш совет. Как Вы думаете, какие на сегодняшний день самые актуальные проблемы системного анализа и управления?? есть ли какая-нибудь тема, которую можно развить в дипломной работе??

Его полное отсутствие 

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

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

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

Удачи

* Требования для задач предоставляются с опозданием
* Хромает управление требованиями. Скорее, отсутствует совсем.  А попытка разрабатывать требования до внедрения процесса управления приводит к ожидаемым результатам (lurkmore.ru/Конец_немного_предсказуем).
* Ревью требований - бессмысленная операция. Время отнимает а требования как были отстоем так и остаются.
* Написание требований - тоже бессмысленная операция. Если Ревью не выявляет ошибок в требованиях, то зачем нужен формальный документ? Рисуйте на салфетке. Или работайте в паре у доски.
* Зарплата аналитика не соответствует сложности работы.  Студент кодер часто получает больше матерого аналитика
* Ведущий программист не может прочитать юзкейс в нотации Коберна. Это норма.
* Ведущий аналитик не может написать юзкейс средней сложности в любой нотации. Это тоже норма.
* В требованиях практически никогда не описываются цели проекта. То что пишут в разделе цели формально и откровенное гуано. Внезапно (lurkmore.ru/Внезапно) это приводит к типичным результатам (lurkmore.ru/Фэйл)
* Нет никакого способа оценить качество требований не проводятся ревью и ретроспективы.
* Так как нет оценки качества, то нет и улучшения процесса. По крайней мере нет тому объективных свидетельств.
* Трассировка между требованиями  и кодом чаще всего  отсутствуют (в случае изменения требования нет возможности понять какие фрагменты системы будут затронуты)
-----------------------------------------------
Картина описанная Бруксом существенно лучше текущей реальности.

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

Гораздо проще "начать хреначить прям сразу", чтобы видеть какой-то результат. И не важно, что потом будет переписываться весь проект.

На этом принципе, между прочим, целая линейка Agile-методологий построена. И самое смешное, что этот подход работает.

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

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

Я бы сказал, что все еще хуже. Есть два основных типа заказчика:
* Те, которые не понимают зачем им проект (не могут сформулировать цели), но в принципе готовы принять объяснения.
* Те, которые не приемлют фиксацию целей проекта.
А если нет целей, то зачем требования? Важно ж бюджет освоить.

На этом принципе, между прочим, целая линейка Agile-методологий построена. И самое смешное, что этот подход работает.

С каких это пор Agile отказывается от тщательной разработки документации до кодирования?!?!
Это вас неправильные "консультанты" обманули.

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

С каких это пор Agile отказывается от тщательной разработки документации до кодирования?!?!

О полном отказе речь тут не идет. Но идея из манифеста следует: софт важнее документов. И часто оказывается что "тщательная разработка документации" дольше и дороже, чем сделать "что-нибудь за 3-4 дня", написать софт и потом дорабатывать напильником. На такой процесс хорошо ложатся остальные принципы agile: частое изменение требований, устное общение, реакция на изменения важнее плана.

О полном отказе речь тут не идет. Но идея из манифеста следует: софт важнее документов. И часто оказывается что "тщательная разработка документации" дольше и дороже, чем сделать "что-нибудь за 3-4 дня", написать софт и потом дорабатывать напильником.

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

Суть Agile - в управлении рисками и итеративном планировании и исполнении, а не в пренебрежении документацией.

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

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

Чтобы вернуться к теме, нужно сначала определиться, что имел ввиду автор темы:
- проблемы науки "Системный анализ"?
- проблемы в деятельности системных аналитиков?

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

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