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

EOH>

Теперь главное: дизайном ПО должен заниматься каждый разработчик в меру своих способностей. Не бывает так что все важные решения уже приняты и осталось просто написать код.

EOH>Холиварный вопрос про менеджмент. Мой скромный опыт показывает, что если разработчикам отдавать на откуп аръитектуру, то мы через полгода плодотворной работы получаем неподдерживаемую совокупность велосипедов и странных архитектурных решений. Потому как архитекторов мало и стоят они очень дорого .

Стремление системного архитектора влезать в дизайн каждого компонента и там похозяйничать, ИМХО, это неприятие делегирования и зло мелкоменджмента.

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

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

CB>“Software Architect. This role leads the development of the system's software architecture, which includes promoting and creating support for the key technical decisions that constrain the overall design and implementation for the project”.

CB>“Designer. This role leads the design of a part of the system, within the constraints of the requirements, architecture, and development process for the project”.

А вот скажите, коллега, а выбор языка программирования является ли частью архитектуры? или дизайна?
Я к тому что уж больно размытое это понятние key technical decisions that constrain the overall design — каждый архитектор интерпретирует его в зависимости от условий и требований проекта.
Об этом и была статья...

Здравствуйте, Виталий Цыбульник, Вы писали:

ВЦ>А вот скажите, коллега, а выбор языка программирования является ли частью архитектуры? или дизайна?

ВЦ>Я к тому что уж больно размытое это понятние key technical decisions that constrain the overall design — каждый архитектор интерпретирует его в зависимости от условий и требований проекта.
ВЦ>Об этом и была статья...

К первоисточникам! Коллега. "Учиться, учиться и учиться..." (с) Классики марксизма-ленинизма

Что делает системный архитектор — смотрим RUP:



Успехов.

Коллега,а RUP подойдет?

Я этого боялся . Ладно, рассмотрим RUP ;-E~. Прежде чем его рассмотреть, уточним что такое RUP. RUP — это формализованный процесс для автоматизации бизнеса. Согласитесь, задача достаточно специфическая. Сильно отличается от разработки коробочных продуктов, операционных систем или веб-порталов.

В качестве информации воспользуюсь сайтом IBM. Понимаю, что источник так себе, но вручную выжимку из process books я сделать не смогу. Есть у IBM такая хорошая статья, называется Understanding RUP roles. Что там пишут:

"The iterative approach to software development embodied in RUP urges practitioners to adopt two perspectives. First, it urges the team to understand the overall solution, and then in each iteration to re-evaluate and adjust the overall solution, based on the results of previous iterations. The two views corresponding to these perspectives are often called the breadth view and the depth view. In an iterative project, you focus first on the breadth view, and then pick a piece to focus on in depth. Separating breadth and depth, as we do in iterative development, makes a project much more resilient to change. Not only is the breadth view easier to create, but also, when change comes, you can smile, shrug, and adjust the breadth view with little effort."

А под этим табличка, в которой и архитектор и дизайнер соответствую как раз двум фокусам на "Analysis and Design". Смотрим:
Software Architect: Decides on technologies for the whole solution.
Designer: Details the analysis and design for a single set of use cases.

Совмещая это с выше процитированным тестом, делаем выжимку на русском: "Есть задача 'анализ и дизайн'. В рамках RUP рассматривается в широком фокусе и в узком фокусе. В широком фокусе задачу решает архитектор. В узком фокусе — дизайнер. Занимаются одним и тем же".

Вывод: RUP считает, что архитектор и дизайнер делают одно и то же на разном уровне детализованности. То есть мое определение архитектуры тут всего лишь разделено на два: макроархитектура в лице архитектора и микроархитектура в лице UML и имплементации индусами.

Напоминаю основной вопрос. Я считаю что макроархитектура и икроархитектура — это одно и то же, но разного уровня детализованности. Вы же с коллегой считаете, что макроархитектура ( в вашей терминологии — архитектура и микроархитектура (в вашей терминологии — дизайн) — это разные вещи, где на макро уровне стек технологий вида LAMP, а на микро уровне непосредствено код. RUP, насколько я вижу, все-таки ближе к моей позиции, хотя и использует термин "designer"

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

EOH>

Коллега,а RUP подойдет?

EOH>Я этого боялся . Ладно, рассмотрим RUP ;-E~. Прежде чем его рассмотреть, уточним что такое RUP. RUP — это формализованный процесс для автоматизации бизнеса. Согласитесь, задача достаточно специфическая. Сильно отличается от разработки коробочных продуктов, операционных систем или веб-порталов.

Ок. Понял. Могут быть только два мнения: твое и неправильное : .

EOH>В качестве информации воспользуюсь сайтом IBM. Понимаю, что источник так себе, но вручную выжимку из process books я сделать не смогу. Есть у IBM такая хорошая статья, называется Understanding RUP roles. Что там пишут:

EOH>"The iterative approach to software development embodied in RUP urges practitioners to adopt two perspectives. First, it urges the team to understand the overall solution, and then in each iteration to re-evaluate and adjust the overall solution, based on the results of previous iterations. The two views corresponding to these perspectives are often called the breadth view and the depth view. In an iterative project, you focus first on the breadth view, and then pick a piece to focus on in depth. Separating breadth and depth, as we do in iterative development, makes a project much more resilient to change. Not only is the breadth view easier to create, but also, when change comes, you can smile, shrug, and adjust the breadth view with little effort."

Упс... А где здесь про архитектуру и проектирование???

EOH>А под этим табличка, в которой и архитектор и дизайнер соответствую как раз двум фокусам на "Analysis and Design". Смотрим:
EOH>Software Architect: Decides on technologies for the whole solution.
EOH>Designer: Details the analysis and design for a single set of use cases.

EOH>Совмещая это с выше процитированным тестом, делаем выжимку на русском: "Есть задача 'анализ и дизайн'. В рамках RUP рассматривается в широком фокусе и в узком фокусе. В широком фокусе задачу решает архитектор. В узком фокусе — дизайнер. Занимаются одним и тем же".

EOH>Вывод: RUP считает, что архитектор и дизайнер делают одно и то же на разном уровне детализованности. То есть мое определение архитектуры тут всего лишь разделено на два: макроархитектура в лице архитектора и микроархитектура в лице UML и имплементации индусами.

EOH>Напоминаю основной вопрос. Я считаю что макроархитектура и икроархитектура — это одно и то же, но разного уровня детализованности. Вы же с коллегой считаете, что макроархитектура ( в вашей терминологии — архитектура и микроархитектура (в вашей терминологии — дизайн) — это разные вещи, где на макро уровне стек технологий вида LAMP, а на микро уровне непосредствено код. RUP, насколько я вижу, все-таки ближе к моей позиции, хотя и использует термин "designer"


Да о чем спорим-то! И тот и другой делают одинаковую работу: анализ проблемы и синтез решения, удовлетворяющего требованиям. Только делают ее на разном уровне.

Готов предложить свой вариант. Архитектор – это дизайнер системы на верхнем уровне. Проектировщик – дизайнер компонента системы. Программист – дизайнер программного пакета. Стажер – дизайнер класса HelloWorld.

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

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

Где-то так...

Здравствуйте, Виталий Цыбульник, Вы писали:

ВЦ>Здравствуйте, craft-brother, Вы писали:

CB>>“Software Architect. This role leads the development of the system's software architecture, which includes promoting and creating support for the key technical decisions that constrain the overall design and implementation for the project”.

CB>>“Designer. This role leads the design of a part of the system, within the constraints of the requirements, architecture, and development process for the project”.

ВЦ>А вот скажите, коллега, а выбор языка программирования является ли частью архитектуры? или дизайна?
ВЦ>Я к тому что уж больно размытое это понятние key technical decisions that constrain the overall design — каждый архитектор интерпретирует его в зависимости от условий и требований проекта.
ВЦ>Об этом и была статья...

Не то выделил. См что я выделил. Сразу субъективизм пропадает. Designer занимается тем что решает конкретные задачи, реализующие определенные требования. Software Architect задает подход к их решению, которые тоже своего рода ограничения.

Очевидно что язык больше относится к общим подходам, поэтому выбор языка — архитектурный вопрос.

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

ВЦ>>А вот скажите, коллега, а выбор языка программирования является ли частью архитектуры? или дизайна?

CB>Что делает системный архитектор — смотрим RUP:

CB>

1) Не увидел ответа на свой вопрос о языке программированя — хотелось бы однозначного "да" или "нет"

2) Дискуссия не о том, какая роль арихитектора или проектировщика в RUP, почему именно RUP? А давайте посмотрим для сравнения какая его роль в XP? А если мне больше нравится Scrum, что там мат часть говорит на эту тему? Давайте не будем сужать до того конкретного процесса, по которому привыкли работать именно Вы.

EOH>>"The iterative approach to software development embodied in RUP urges practitioners to adopt two perspectives. First, it urges the team to understand the overall solution, and then in each iteration to re-evaluate and adjust the overall solution, based on the results of previous iterations. The two views corresponding to these perspectives are often called the breadth view and the depth view. In an iterative project, you focus first on the breadth view, and then pick a piece to focus on in depth. Separating breadth and depth, as we do in iterative development, makes a project much more resilient to change. Not only is the breadth view easier to create, but also, when change comes, you can smile, shrug, and adjust the breadth view with little effort."
CB>Упс... А где здесь про архитектуру и проектирование???

Здесь про роли. Вы же из RUP названия ролей взяли?

EOH>>Напоминаю основной вопрос. Я считаю что макроархитектура и икроархитектура — это одно и то же, но разного уровня детализованности. Вы же с коллегой считаете, что макроархитектура ( в вашей терминологии — архитектура и микроархитектура (в вашей терминологии — дизайн) — это разные вещи, где на макро уровне стек технологий вида LAMP, а на микро уровне непосредствено код. RUP, насколько я вижу, все-таки ближе к моей позиции, хотя и использует термин "designer"


CB>Да о чем спорим-то! И тот и другой делают одинаковую работу: анализ проблемы и синтез решения, удовлетворяющего требованиям. Только делают ее на разном уровне.

Согласен. А что говорил Станислав:

Архитектура ПО — некоторые рамки в пределах которых будет строиться ПО. Например будет ли приложение веб или декстоп, будет ли оно размещено в "облаке" или нет. Будет ли использовать реляционную СУБД или какую-то другую. С какими другими программами придется взаимодействовать и как это делать. Используемые языки и технологии.Другое дело дизайн — это конкретный набор компонент и связей между ними для решения определенных задач. Выделенное как-бы намекает что должны быть задачи.
Архитектура не может быть эволюционной. В процессе эволюции декстоп не станет вебом, язык и платформа вряд ли сменится. Некоторые архитектурные решения могут поменяться, но зачастую это приводит к огромным затратам.
Дизайн при этом очень эволюционен, итерации дизайна выявляют новые требования, которые изменяют общий подход к решению.

Согласитесь, что он не считает что архитектура и дизайн — это одно и то же на разном уровне ^_^.

CB>Готов предложить свой вариант. Архитектор – это дизайнер системы на верхнем уровне. Проектировщик – дизайнер компонента системы. Программист – дизайнер программного пакета. Стажер – дизайнер класса HelloWorld.

Меня вполне устроит такая трактовка. Слово "дизайн" я правдо выкинул бы в поьзу макроархитектуры, архитектуры и микроархитектуры — но это уже дело вкуса.

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

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

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

CB>>Да о чем спорим-то! И тот и другой делают одинаковую работу: анализ проблемы и синтез решения, удовлетворяющего требованиям. Только делают ее на разном уровне.

EOH>Согласен.

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

С ролями еще сложнее и больше неоднозначностей.

Здравствуйте, Виталий Цыбульник, Вы писали:

ВЦ>1) Не увидел ответа на свой вопрос о языке программированя — хотелось бы однозначного "да" или "нет"

И "да" и "нет". Язык может быть задан на всю систему, например, Java + PL SQL. А может и нет. Например, для одной подсистемы будет эффективнее PHP, а для другой Эрланг. ИМХО, выбор языка, может быть частью проектирования модуля.

ВЦ>2) Дискуссия не о том, какая роль арихитектора или проектировщика в RUP, почему именно RUP? А давайте посмотрим для сравнения какая его роль в XP? А если мне больше нравится Scrum, что там мат часть говорит на эту тему? Давайте не будем сужать до того конкретного процесса, по которому привыкли работать именно Вы.

Не стоит сравнивать PUP со Srum или XP. RUP это фреймворк для построения процессов. Из компонентов RUP может быть построен любой процесс от Agile до CMM L5. А Scrum и XP это всего лишь конкретные процессы.

Однако это не имеет отношение к нашей дискуссии. Поскольку архитектора системы требуется при любом процессе разработки. Или я не прав?

CB>>>Да о чем спорим-то! И тот и другой делают одинаковую работу: анализ проблемы и синтез решения, удовлетворяющего требованиям. Только делают ее на разном уровне.
EOH>>Согласен.
G>Вы очень легко переходите от обсуждения собственно архитектуры и дизайна к обсуждению ролей, и наоборот.
G>С ролями еще сложнее и больше неоднозначностей.

Это не я, это Сергей ^_^".