Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Околесица ИМХО написана Бруксом.
Да, есть некоторая сумбурность, но по-моему вполне объяснимая (см. ниже).

MSS>Перепутаны архитектор и аналитик требований ("постановщик задачи").
MSS>Представителем пользователя является именно и конкретно аналитик требований. Он привносит пользовательский взгляд на систему, и его функция — сделать так, чтобы этот взгляд таки в системе отражался. Ему при этом в общем плевать на технические нюансы системы.
По-моему, просто Брукс засунул архитектора в "представители пользователя" просто по другому критерию, нежели сейчас обычно понимается, мне показалось, что он говорит о некоторой ответственности архитектора за разрабатываемую систему.

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

[skipped]
В принципе, все это достаточно хорошо укладывается в "диполь Тыугу" (бизнес-аналитик/постановщик + системный аналитик/архитектор): Диполь Тыугу, или Как преодолеть искажения ИС — то есть все, что вы сказали верно, но Брукс вроде особенно и не противоречит этому, просто недостаточно подробно описал... ну или недостаточно хорошо понимал тогда все это.

Здравствуйте, Maxim S. Shatskih, Вы писали:

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

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

Я вас, вероятно, обрадую, но на самом деле никакой ответственности не лежит ни на ком ну что сделают с архитектором, который провалил проект? уволят? а он новое место найдет. Про рядовых сотрудников я и вовсе не говорю.

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

R>и сводить внутренние проектные движения не в направлении достижения ожиданий бизнес-аналитика к минимуму.

Ну это очевидно. Но архитектор таки представитель платформ, тулов и законов физики, а не пользователя.

R>В принципе, все это достаточно хорошо укладывается в "диполь Тыугу" (бизнес-аналитик/постановщик + системный аналитик/архитектор):

О! Эта пара прекрасно работает, я это с конца 90х знал безо всяких Тыугу.

Здравствуйте, Maxim S. Shatskih, Вы писали:

[skipped]
Это все верно, со всем согласен, только, по-моему, Брукс все же ничему этому особенно не противоречит, а просто говорите несколько о другом.

MSS>О! Эта пара прекрасно работает, я это с конца 90х знал безо всяких Тыугу.
Ну... Э. Х. Тыугу постарее будет.

Здравствуйте, Maxim S. Shatskih, Вы писали:

R>>Пример и видение 75-го года от Брукса, интересны мнения: сильно ли концептуально устарело или нет?[q]Аристократия и демократия

MSS>Околесица ИМХО написана Бруксом.

MSS>Перепутаны архитектор и аналитик требований ("постановщик задачи").
Никакой околесицы и путаницы нет. Это у нас, в русском сознании, архитектором называют человека, который придумывает внутреннюю структуру программы.

А на западе под термином Software Architect понимают человека, который придумывает внешнее поведение системы. Именно это поведение описывает решение задачи, сформулированной пользователем.

У нас традиционно этим вообще никто не занимается. Большая часть софта разрабатывается, полностью минуя стадию выбора подходящего поведения — от требования "Мне нужно отслеживать статусы сепулек" мы мгновенно, не думая, переходим к "экран №123412: список сепулек пользователя", а архитектор занимается разработкой фреймворка для отображения списков и деревьев. Более того, если спросить "кто вас просил делать этот чудовищный список сепулек с постраничной навигацией" любой разработчик мгновенно ответит: "пользователь!".

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

Здравствуйте, Sinclair, Вы писали:

S>А на западе под термином Software Architect понимают человека, который придумывает внешнее поведение системы. Именно это поведение описывает решение задачи, сформулированной пользователем.

S>У нас традиционно этим вообще никто не занимается. Большая часть софта разрабатывается, полностью минуя стадию выбора подходящего поведения — от требования "Мне нужно отслеживать статусы сепулек" мы мгновенно, не думая, переходим к "экран №123412: список сепулек пользователя", а архитектор занимается разработкой фреймворка для отображения списков и деревьев. Более того, если спросить "кто вас просил делать этот чудовищный список сепулек с постраничной навигацией" любой разработчик мгновенно ответит: "пользователь!".

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

1. Позвольте узнать на основании чего возникло утверждение про Архитектора и архитектуру как "внешнее поведение" или что вы понимаете под внешним поведением? Какие стандарты или методологии подтверждают эту точку зрения? И было бы здорово если бы вы уточнили, что значит "на западе" ... это в отдельно взятой западной компании или где?
2. Как соотносится ваше утверждение про Software Architect со SWEBOK (http://www.sorlik.ru/swebok/3-2-software_engineering_design.pdf), со стандартом IEEE 1471 (IEEE Recommended Practice for Architectural Description of Software-Intensive Systems), а так же с этим http://www.sei.cmu.edu/architecture/published_definitions.html#Modern и с этим http://www.sei.cmu.edu/architecture/what_architects_do.pdf
3. Как вы прокомментируете явное сходство вашего утверждения с тем, что в RUP назывют моделью анализа и/или в AIM функциональной архитектурой?

Здравствуйте, Sinclair, Вы писали:

S>А на западе под термином Software Architect понимают человека, который придумывает внешнее поведение системы. Именно это поведение описывает решение задачи, сформулированной пользователем.

Ну, как показывает википедия, единого мнения нет и на западе.
http://en.wikipedia.org/wiki/Software_Architect

Здравствуйте, AndrewVK, Вы писали:
AVK>Ну, как показывает википедия, единого мнения нет и на западе.
AVK>http://en.wikipedia.org/wiki/Software_Architect
Ну вот так всегда! Мир до этого интернета был простым и непротиворечивым.