Я очень часто сталкиваюсь с обратным - если задача невелика, всё делает сам программист, начиная с вопросов заказчику - что ему нужно.
Разумеется, это всеобъемлющая практика. Но я повторяю:
Вы готовите себе еду, но это не делает вас поваром.
Это повторение ничего не даёт, Ваше мнение я понял. Но не считаю его общепринятым.
В данном случае то, что я сказал, не общеизвестно (как выясняется) и не доказано (в этой области вместо понятия доказательства следует пользоваться понятием практики). Просто то, что я сказал, более-менее соответствует положению дел.
То, что сказал я, тоже более-менее соответствует положению дел. На предыдущем месте работы у нас были специальные аналитики (специалисты по банкам, не программисты), и в то же время в одном проекте я общался с работниками банка и выяснял их требования самостоятельно. Более того, меня программирование изначально привлекало тем, что решая разные задачи из разных предметных областей, появляется возможность узнать об об этих сферах деятельности. Ещё учась в институте, я узнал, как работают мелкооптовые магазины, чем они отличаются от розничных, как работает сеть торговцев газет, из чего делают мороженое, как работает станция переливания крови и т.п. Потом посмотрел, как делаются авиационные движки (те, которые сейчас идут на Super-JET), и движки снегоходов: ребята рассказали как делаются движки снегоходов сейчас - берётся японский движок, разбирается, перемеривается, делается из собственных деталей и - разваливается, т.к. материалы не держат расчётных нагрузок. Посмотрел, как работают банки, был в Deutsche Bank, Intesa и BSGV. И так далее.
Да и ну его тогда - это изучение предметной области. Речь-то шла о творчестве. Создание архитектуры системы сродни работе архитектора, который проектирует здания (мне рассказывал один товарищ). Они тоже не выполняют все расчёты сразу, в момент, когда задумывают здания - это делают позже специалисты по сопромату. Но архитектор должен предвидеть качественно, что эти расчёты будут выполнимы на базе доступных материалов, что не окажется такого, что доступной прочности недостаточно. То же самое - в программировании, плохая архитектура системы потом приведёт к проблемам.
Не советую молиться на RUP как на единственный свет в окошке. Это всего лишь практические советы по организации разработки software. Причём в довольно специфической ситуации: в компании, занятой разработкой software. Например, в компании, решающей другие задачи, и разрабатывающей software не для внешнего заказчика, а под собственные нужды, RUP "как есть" неприменим, а reqiurements могут составляться коллегами из "непрограммистского отдела".
Да и вообще, странное заявление, с учётом того, что в RUP вообще нет понятия программиста в указанном вами смысле "мастер на все руки".
Во-первых, я изначально упоминал "RUP и иже с ними", я работал также по V-Model, правда давно, то есть никто и не молится. Во-вторых, если мы хотим найти какое-то общепринятое мнение, то необходимо на что-то опираться, я привёл пример из того материала, который мне известен, был бы не против, если бы Вы также ссылались на что-нибудь. В-третьих, в RUP есть набор ролей, и сказано, что несколько ролей может выполнять один человек, причём совмещение аналитика с разработчиком не запрещается (я не встречал). В-четвёртых, достаточен ли Ваш опыт использования RUP, чтобы его не советовать?
Если человек будет программистом - шансы, что ему придётся заниматься математикой, около 10 % (а шансы, что серьёзной и глубокой математикой - около 1 % (вычметоды и криптография) и 0,01 % на всё остальное).
Если человек будет математиком-прикладником - шансы, что ему придётся заниматься программированием - 99 %, но шансы, что ему придётся заниматься профессиональным программированием (в смысле RUP и software engineering) - ниже 50 %.
Не знаю насчёт цифр, но качественно как-то так, наверное. Программист - это инженер, его выпускает институт, его серьёзной и глубокой математике не учили. Зато учили множеству других полезных вещей. Здесь я даже не вижу поводов для возражений. При чём тут профессиональное программирование - я не понял. Чтобы разговаривать на русском, не обязательно быть лингвистом. Всё равно он будет общаться с заказчиком, всё равно как-то будет планировать (хотя бы ближайшую) структуру системы, т.е. так или иначе будет проходить стадии техпроцесса - независимо от того, слышал ли он что-то о RUP или нет.
-- Вс авг 11, 2013 19:33:29 --Upd: а, да, забыл - ещё мы студентами работали в конторе, занимавшейся акциями (типа Гермес-Союз, Токур-Золото), и тогда я разрабатывал схему работы Городского Депозитария. Правда этот рынок потом пошёл на спад и в итоге всё накрылось медным тазом, так что тот проект в реализацию не пошёл.
одни примитивы унылые.
Ибо образование получила на мех-мате университета.
Системы распознавания изображений и звука, машинный перевод? Вроде бы тоже поставлено на поток, хотя, возможно, таким системам далеко до совершенства и простор для творчества там все еще есть.