Добрый день уважаемые коллеги.
Предлагаю обсудить зоны ответственности каждой из ролей при создании ПО.

Зона ответственности аналитика:
1.Обследование предметной области;
2.Определение требований;
3.Обоснование необходимости внедрения, смета затрат, предполагаемый экономический эффект и время окупаемости;
4.Разработка ТЗ; подготовка сопроводительной документации;
5.Создание необходимые диаграмм;
6.Разработка шаблонов проектирования;
7.Разработка тест-кейсов;
8.Участие в тестировании и сдаче продукта заказчику;
9.Участие во внедрении и сопровождении программного продукта.
------------------------------------------------------------------
Следует учесть, что ТЗ может включать в себя диаграммы компонентов и развертывания.
Касательно BPMN 2 довольно сложно определить зону ответственности аналитика и разработчика.

Учитывая вышесказанное, так что же входит в зону ответственности архитектора и менеджера проекта?

p.s.Если что то забыл для аналитика дополните пожалуйста.
p.p.s.Также прошу поправить по терминологии.

Мое имхо,
зона ответственности аналитика понять ЧТО требуется заказчику для решения его проблемной ситуации и предложить концепцию решения. Т.е. это аналитическая деятельность.

Действительно, аналитик готовит ТЗ, постановки, ТК, внедряет и сопровождает продукт. Участвует в обсуждении проектных решений. Но пункт 6 не компетентность аналитика, а архитектора.

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

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

менеджер проекта управляет ресурсами. Этого не делает больше никто в команде. Архитектор занимается проектированием. Если кверент не понимает разницы между проектированием и анализом, путая архитекторов с аналитиками, рекомендую ему учебник Орлова Технологии разработки ПО (вроде так), там все разжевано

Если кверент

Ida, ну к чему эти словечки. Русский достаточно богат и сам по себе

В том то и дело что зоны ответственности имхо пересекаются. Поэтому и хочу понять где же проходит граница между аналитиком и архитектором.
Куда например относятся диаграммы компонентов и развертывания UML? Кто их должен делать?
У нас в ТЗ указывалось все вплоть до формата отдельных команд и их взаимодействия, т.е. оставалось, что называется закодить. Где же в этом случае работа архитектора?
Или напр. 3.Обоснование необходимости внедрения, смета затрат, предполагаемый экономический эффект и время окупаемости; Это обязанность аналитика из менеджера проекта?
Хотелось бы по пунктам определись зоны ответственности каждого.
Спасибо за рекомендацию книги. Почитаем.

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

•    Анализ — преобразование требований к системе в классы и объекты, выявляемые в предметной области;
•    Проектирование — создание статического и динамического представления системы, выполняющего выявленные требования и являющегося эскизом реализации

Разве классы/объекты не являются статистическим и динамическим представлением системы?
p.s.Нашел видеолекции http://www.youtube.com/watch?v=wB6rfqxRKn0 может что интересного узнаю.

В том то и дело что зоны ответственности имхо пересекаются. Поэтому и хочу понять где же проходит граница между аналитиком и архитектором.

Так это типичная ситуация. В чем проблема-то?

Куда например относятся диаграммы компонентов и развертывания UML? Кто их должен делать?

Точно уж не аналитик. ДК и ДР - типичные архитектурные диаграммы. Делает их проектировщик, т.е. человек который умеет отвечать на вопросы: из каких компонентов будет состоять система? где будут размещены части системы?

У нас в ТЗ указывалось все вплоть до формата отдельных команд и их взаимодействия, т.е. оставалось, что называется закодить. Где же в этом случае работа архитектора?

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

Или напр. 3.Обоснование необходимости внедрения, смета затрат, предполагаемый экономический эффект и время окупаемости; Это обязанность аналитика из менеджера проекта?

думаю менеджера проекта при активном участии аналитика

Хотелось бы по пунктам определись зоны ответственности каждого.

где-то на форуме и в сети гуляет документ обязанностей и компетенций системного аналитика. Кроме того посмотрите википедию. И вообще Вы обращаетесь по таким очевидным вопросам, материал по которым имеется в избытке. Find it

Разве классы/объекты не являются статистическим и динамическим представлением системы?

не являются. являются статическим

Galogen Большое спасибо за ответы.

Дополнительно хотелось бы узнать объем работ, ответственность и относительный уровень зп каждой из ролей.
Насчет ответственности, если провал/срыв сроков случится по вине данного специалиста каковы санкции? Лишение премии/бунусов или что-то еще?
Поскольку с аналитиком наиболее понятно примем его уровень зп за 100%
Сколько по вашему должен получать архитектор и менеджер проекта?

где-то на форуме и в сети гуляет документ обязанностей и компетенций системного аналитика.

См. вложение.

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

p_safin то, что надо! Спасибо большое!

Elfх Ролей можно множество добавить/придумать.
"Оценщик трудозатрат" как отдельный персонаж впервые слышу. Неужели где-то есть такие специализированные должности? Полагаю что это входит в обязанности или аналитика или менеджера проекта.

Так же можно добавить эксперта предметной области, программистов, внедренцев.

Elfх Ролей можно множество добавить/придумать.
"Оценщик трудозатрат" как отдельный персонаж впервые слышу. Неужели где-то есть такие специализированные должности? Полагаю что это входит в обязанности или аналитика или менеджера проекта.

Так же можно добавить эксперта предметной области, программистов, внедренцев.

Это не специализированная должность, а одна из ролей.

Чтобы разрабатываемое/внедряемое ПО заработало, надо решить определенное количество задач. Каждая задача должна быть решена кем-то из членов проектной команды. Кто из бойцов будет решать каждую конкретную задачу, обычно определяется не тем, какая у бойца нашивочка на рукаве ("аналитик", "архитектор" и т.д.), а тем, что этот боец по своей квалификации и опыту в состоянии справиться с этой задачей, согласен заниматься ей, и оказался в нужное время в нужном месте.
А на нашивочки ссылаются обычно, когда нет желания заниматься данной задачей, и нужен повод для отмазки: "программисты не меняют перегоревшие лампочки, это чисто аппаратная проблема".

Опытный ПМ подбирает людей в команду, обращая внимание не на должности, а на конкретные умения и навыки людей. Например, если в плане намечается задача "Нарисовать диаграмму развертывания", и ПМ знает, что Вася отлично планирует развертывание, то зачем ему задумываться над вопросами:
1. Должен эту диаграмму рисовать аналитик или архитектор?
2. Что написано у Васи в трудовой книжке: аналитик или архитектор?
Все равно будет рисовать Вася...

div Это все понятно. Я же хочу рассмотреть команду в которой присутствуют все перечисленные должности. Команда специалистов, каждый в своей области согласно "нашивки" и записи в трудовую.

div Я же хочу рассмотреть команду в которой присутствуют все перечисленные должности.

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