Приветствую.
Ни для кого не секрет, что существует достаточно большое количество подходов к определению этапов жизненного цикла (ЖЦ) IT проекта. Эти самые ЖЦ описаны в работах Вигерса и других известных авторов, работающих в этой теме, описан свой подход в RUP, есть классификация этапов ЖЦ в BABOK. Названия этапов варьируются, но по смыслу они все примерно говорят об одном и том же.
Мне кажется, что если отнести пункты, приведенные ниже, к более или менее формализованным этапам ЖЦ проекта, это поможет точнее ответить на заданный вопрос.
Давайте попробуем:
1.Обследование предметной области;
Это этап Бизнес Моделирования (Анализа) (Business Analysis). Это, безусловно, обязанность Бизнес Аналитика
2.Определение требований;
Это этап работы с требованиями (Requirements). Часто его разделяют на этапы "Получения, извлечения" требований(Requirements Elicitation) и "Разработки или управления" требованиями (Requirements Management). Но, как бы там ни было - это работа Аналитика, Бизнес или Аналитика Требований, если таковой выделен в компании (такая ситуация часто возникает в проектах с "импортными" заказчиками со сложной предметной областью. Они предпочитают выделять своих специалитстов в предметной области (SME) в качестве Бизнес Аналитиков, проектной же команде оставляют работу по разработке собственно требований).
3.Обоснование необходимости внедрения, смета затрат, предполагаемый экономический эффект и время окупаемости;
"Обоснование необходимости" - это то, что выполняется на этапе "Предварительного анализа" (Preliminary Analysis), когда проводят анализ проблемы (Problem Analysis), которая, собственно и явилась причиной старта проекта, или возможности (Opportunity), которую хочет реализовать компания, заказывающая проект. Все это является частью более глобального этапа - Бизнес Анализа. Т.е. это тот же этап, что мы упоминали для первого пункта.
"Смета затрат", вот тут нужно быть аккуратными. Бизнес Аналитик обязан разрабатывать планы проведения этапа Бизнес Анализа, оценивать ресурсы, необходимые для его реализации, но... деньги проекта, глобальное планирование ресурсов на все этапы проекта, не только Бизнес Анализа, - это прерогатива Руководителя Проекта. Соотвественно, такие "денежные" показатели как "предполагаемый экономический эффект" и "время окупаемости" - это все-таки зона отвественности человека, стоящего повыше Аналитика. Повторюсь, Аналитик не располагает информацией о всех проектных ресурсах, не решает политических (денежных) вопросов с заказчиком, поэтому - это не его.
4.Разработка ТЗ; подготовка сопроводительной документации;
5.Создание необходимые диаграмм;
Если ТЗ то, в общепринятом смысле содержит требования, то это этап Работы с Требованиями. Разработка диаграмм, строго говоря, не тянет на отдельный, самостоятельный этап, поскольку "диаграммы" являются артефактами, которые разрабатываются для разработки требований - облегчение понимания, обсуждение с заказчиком и т.д. Чаще всего, самостоятельным артефактом (независимым от других артефактов, например от требований), который принимается заказчиком, включается в поставку они не являются. Это всего лишь иллюстрация. Но, сразу оговорюсь, что степень формализации документации требований определяется типом проекта, обсуждается с заказчиком и поэтому очень может быть, что в каком-нибудь Agile проекте диаграммы будут, по договоренности с заказчиком, приняты как необходимый и достаточный документ требований.
6.Разработка шаблонов проектирования;
Это этап Системного Анализа и Проектирования (System Analysis and Design). Это этап, на котором подключаются две новые роли - Системный Аналитик и Системный Дизайнер. Это люди не от Бизнес Анализа. Это люди от программирования, поскольку речь идет уже о разработке базы для будущей реализации: определение будущих классов, интерфейсов и т.д. Более того, некоторые шаблоны проектирования являются платформенно зависимыми. Что это означает? Это означает, что существуют отдельные шаблоны проектирования для Java, для C++ и т.д.
Не во всех компаниях Системные Аналитики отделены от Бизнес Аналитиков. Не во всех компаниях, где такие роли (должности) выделены (у нас они называются Архитекторы), эти "Архитекторы" занимаются Системынм Анализом и Дизайном. Зачастую они ограничиваются разработкой технических решений по выбору платформы для реализации, проектированием БД, проектированием общей архитектуры (сервера, сетка) и т.д. Обязанности же по проведению Системного Анализа и Дизайна делят между собой Аналитик и разработчики.
7.Разработка тест-кейсов;
Это этап Тестирования, не смотря на то, что собственно тестирование начнется несколько позже - тест кейсы начинают разрабатывать как только аналитик представил требования и это выполняется параллельно с разработкой софтинки. Это, безусловно, обязанность Тестировщика. Роль Аналитика в этом процессе: провести ревью разработанных тест-кейсов, чтобы убедиться, что тестировщик все правильно понял и тестирует то, что нужно, провести трассировку требований на тест-кейсы, что бы иметь возможность понять степень готовности требования по результатм тестирования.
8.Участие в тестировании и сдаче продукта заказчику;
Этап тестирования проводят Тестеры. Аналитик только наблюдает за процессом. Необходимо знать, все ли требования, вошедшие в Base Line протестированы, какие успешно прошли, какие завернули и т.п. поскольку, при нормальной организации работы с требованиями, все это отражается на статусе требования
9.Участие во внедрении и сопровождении программного продукта.
Аналогично предыдущему
Прошу прощения за "лаконичность".
По поводу должностных инструкций скажу только, что очень часто их составляют люди либо очень далекие от понимания всех этих вещей, либо, наоборот, очень недале### люди. Ну, вы понимаете
Поэтому, совершенно нормально, если разработкой тест-кейсов и планированием бюджета всего проекта в какой-то компании занимается Аналитик. Нужно понимать, что это не норма, это - отклонение
Зоны ответственности аналитика, архитектора и менеджера проекта.