Форум Сообщества Аналитиков

×


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



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



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



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

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

Удачи :)



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



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



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

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



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


На этом принципе, между прочим, целая линейка Agile-методологий построена. И самое смешное, что этот подход работает.
С каких это пор Agile отказывается от тщательной разработки документации до кодирования?!?!
Это вас неправильные "консультанты" обманули.
Сергей Мартыненко
http://martyinenko-sergey1.moikrug.ru/



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



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



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

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



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



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

Чтобы вернуться к теме, нужно сначала определиться, что имел ввиду автор темы:
- проблемы науки "Системный анализ"?
- проблемы в деятельности системных аналитиков?
Л. Новиков
http://lnew.ucoz.ru
lnew@yandex.ru



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



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




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19