Contents

Младший аналитик

Необходимые специальные, лидерские и управленческие навыки:
1. Выявлять заинтересованных лиц (ЗЛ).
2. Управлять ожиданиями ЗЛ.
3. Проводить собрания.
4. Проводить интервьюирование.
5. Проводить анкетирование.
6. Проводить «мозговые штурмы».
7. Уметь определять границы системы.
8. Уметь выделять подсистемы и определять их границы.

9. Уметь выявлять требования типов:

ответы и собранная информация;
запросы заинтересованных лиц;
глоссарий;
стандарты и ГОСТы;
характеристики аналогичных/наследуемых систем;
бизнес-требования;
бизнес-правила;
концепция создания и развития продукта (B VISION);
ограничения и допущения;
концепция системы (T VISION);
пользовательские требования;
функциональные требования;
функции системы/варианты использования/прецеденты (Use Cases);
нефункциональные требования;
требования к пользовательскому интерфейсу;
требования к взаимодействию с внешними системами.

10. Выявлять функции системы (Use Cases), моделировать поведение системы.
11. Уметь строить трассировки/прослеживать требования.
12. Понимать основные принципы тестирования.
13. Знать английский язык на уровне, достаточном для чтения технической литературы

Аналитик

Необходимые специальные, лидерские и управленческие навыки:
Все навыки младшего аналитика, а также:

знать, что такое ПУТ (план управления требованиями), и уметь его разрабатывать;
понимать, какие модели существуют и где их место в разработке ПО;
уметь создавать модель анализа;
строить Robustness- и Sequence-диаграммы, понимать, зачем их вообще надо строить;
уметь читать программный код;
иметь навыки проведения презентаций

Старший/ведущий аналитик

Необходимые специальные, лидерские и управленческие навыки:
Все навыки аналитика, а также:

иметь детальное представление о жизненном цикле проекта и продукта;
знать, что такое ПУД (План Управления Документами проекта), и уметь его создавать;
уметь создавать логическую модель и модель данных;
уметь создавать простой программный код (этот навык нужен для умения читать программный код — ведь никто так не поймет разработчика, как другой разработчик, и если вы хотите говорить с разработчиками на одном языке, вам придется освоить программирование в минимальном объеме);
уметь профессионально проводить презентации;
проводить выученные уроки по практикам разработки и управления требованиями;
быть наставником для аналитиков;
уметь предотвращать и разрешать конфликты в проектах;
уметь выявлять риски и управлять ими.

Начальник отдела анализа

Необходимые специальные, лидерские и управленческие навыки:
Все навыки аналитика, а также:

знать модель зрелости процессов компании CMMI 1.2. в областях: RD, REQM, DAR, TS, PI, VER, RSKM, PP, PMC, IPM, VAL, QPM, SAM;
уметь анализировать эти области на предмет требуемых улучшений и несоответствий с моделью;
разрабатывать методологию системного анализа для компании;
проводить тренинги и семинары;
иметь четкое представление об управлении проектом/программой проектов;
уметь строить и развивать команду аналитиков в проектах;
проводить выученные уроки по результатам выполненных работ/проектов;
участвовать в совершенствовании процессов;
разрабатывать процедуры, регламенты, рабочие инструкции;
создавать функциональную стратегию своего направления;
планировать развитие отдела, вовлекать топ-менеджеров в решение стратегических и тактических вопросов;
выстраивать эффективное взаимодействие с другими подразделениями;
разрешать конфликты на всех уровнях;
быть способным управлять проектом;
профессионально развивать подчиненных;
уметь проводить аттестацию сотрудника;
курировать создание базы знаний отдела;
управлять совершенствованием процессов в области анализа, разработки и управления требованиями;
управлять формализацией процессов и созданием системы менеджмента качества отдела.

Что такое план управления требованиями?

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

Введение.
Общее описание методологии анализа, разработки и управления требованиями в проекте.
Системный анализ и моделирование.
- Обзор основных моделей системного анализа.
- Управление артефактами (моделями) системного анализа.
Разработка требований.
- Типы требований.
- Типизация нефункциональных требований.
- Атрибуты требования.
Управление требованиями.
- Методология управления.
  - Атрибуты требований.
  - Полномочия по работе с требованиями.
  - Обсуждение требований.
  - Согласование требований.
  - Утверждение требований.
- Жизненный цикл требований.
  - Запросы заинтересованного лица.
  - Все остальные типы требований.
- Трассировка требований.
Управление изменениями в требованиях.
- Обработка запроса на изменение.
- Базовые версии требований (baselines) в проекте.
Спецификации требований.
Управление процессом анализа и разработки требований.
- Список основных артефактов и деятельностей по управлению требованиями.
- Передача знаний бизнес-аналитику.
- Обучение и передача знаний системному аналитику.
- Постоянные улучшения процесса анализа и разработки требований.

Что такое техническое задание?

Техническое задание (ТЗ, техзадание) — исходный документ для проектирования сооружения или промышленного комплекса, конструирования технического устройства (прибора, машины, системы управления и т. д.), разработки информационных систем, стандартов либо проведения научно-исследовательских работ (НИР).
ТЗ содержит основные технические требования, предъявляемые к сооружению, изделию или услуге, и исходные данные для разработки; в ТЗ указываются назначение объекта, область его применения, стадии разработки конструкторской (проектной, технологической, программной и т. п.) документации, ее состав, сроки исполнения и т. д., а также особые требования, обусловленные спецификой самого объекта либо условиями его эксплуатации. Как правило, ТЗ составляют на основе анализа результатов предварительных исследований, расчетов и моделирования.

Что такое План управления документами (ПУД)?

План управления документами (ПУД) — описывает, какие проектные артефакты на каком этапе проекта в каком состоянии должны находиться, какие роли являются согласующими лицами для каждого артефакта, какие роли входят в команду утверждения, какая роль является ответственной за артефакт, даты готовности артефактов и т. д. и т. п.

Что такое Спецификация требований программного обеспечения?

Спецификация требований программного обеспечения (Software Requirements Specification) — законченное описание поведения системы, которую требуется разработать. Включает ряд пользовательских сценариев (Use cases), которые описывают все варианты взаимодействия между пользователями и программным обеспечением.
Пользовательские сценарии являются средством представления функциональных требований. В дополнение к пользовательским сценариям спецификация также содержит нефункциональные требования, которые налагают ограничения на дизайн или реализацию (такие как требования производительности, стандарты качества или проектные ограничения).
В более широком смысле спецификация требований — документ с требованиями или моделями, который используется в процессе разработки и управления требованиями в проекте.

Трассировки — что это такое?

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

Обычно трассировки строятся от одного типа требований к другому, далее к третьему, четвертому типам — пока не дойдем до «конечных» типов требований. «Конечным» типом требований обычно выбирается «вариант использования» или «функциональное требование» и «нефункциональное требование». Вся информация о трассировках, их назначениях и «конечных» типах требований фиксируется в ПУТ.

Рисунок «Соответствие модели системы и требований к системе. Концептуальная модель системы и Technical Vision»:

В результате можно построить «дерево» трассировок, которое позволит проследить, как учтено «исходное» требование в «конечном».

Решение о том, делать или не делать трассировки и если делать, то какие именно трассировки делать, принимает менеджер проекта совместно с системным аналитиком и тест-менеджером.

Все трассировки условно можно разделить на причинно-следственные (основные) и проверочные (дополнительные). Причинно-следственные трассировки нужны для разработки качественного продукта. Проверочные трассировки необходимы в первую очередь менеджеру проекта как ответственному за качество продукта. От выполнения проверочных трассировок зависят успех проекта и удовлетворенность заказчика.

Рисунок «Проверочные трассировки требований»:

Какие виды «архитектур» встречаются в работе аналитика?

Архитектура предприятия/корпоративная архитектура: Это высокоуровневая архитектура всего предприятия, покрывающая бизнес-потребности ИТ-способностями. Корпоративная архитектура фокусируется на определении потоков и бизнес-процессов, действий, функций, информации, данных и технологий предприятия и на вызовах, стоящих перед ИТ, необходимых для того, чтобы эффективно применить технологию в ответ на изменение бизнес-потребностей.

Бизнес-архитектура: Описывает все бизнес-процессы, бизнес-акторы, бизнес-сущности и бизнес-правила с точки зрения бизнеса. Бизнес-архитектура не зависит от применяемых в разработке технологий

Информационная архитектура: Определяет структуры данных и описывает все потоки данных, которые используются для поддержки бизнес-архитектуры. Такие операции, как идентификация, систематизация, категоризация, хранение данных, относятся к информационной архитектуре (Information Architecure). Может представляться в виде модели данных (Data Model).

Архитектура решения: Архитектура программного обеспечения, которое реализует функции бизнес-архитектуры (Business Architecture).

Технологическая архитектура: Описывает архитектуру IT-окружения, которое используется для поддержки информационной архитектуры (Information Architecture) и архитектуры решения (Solution (System/Application) Architecture).

Системная архитектура: Это представление системы, которое показывает реализацию функциональных возможностей системы аппаратными средствами и компонентами программного обеспечения, устанавливает связь архитектуры программного обеспечения и архитектуры аппаратных средств, а также регламентирует взаимодействие пользователя с этими компонентами. Существуют и другие определения системной архитектуры (System Architeture), например: ряд взаимосвязанных шаблонов (паттернов), которые структурируют модули и данные и обеспечивают требуемое поведение системы (см. определение Data Architecture). Системная архитектура (System Architecture) является составной частью архитектуры решения (Solution Architecture).

Архитектура программного обеспечения: Является составной частью системной архитектуры (System Architecture). Описывает организацию системы с точки зрения программных компонентов, из которых она состоит, и связи между компонентами.

Архитектура данных: Является составной частью системной архитектуры (System Architecture). Описывает структуры данных и логические связи между данными.

Методологии, с которыми работают аналитики

Capability Maturity ModelIntegration (CMMI) — набор моделей (методологий) совершенствования процессов в организациях. Capability Maturity Model Integration (CMMI) — набор моделей (методологий) совершенствования процессов в организациях разных размеров и видов деятельности. CMMI содержит набор рекомендаций в виде практик, реализация которых, по мнению разработчиков модели, позволяет реализовать цели, необходимые для полной реализации определенных областей деятельности.
SWEBOK (Software Engineering Body of Knowledge) — документ, подготавливаемый комитетом Software Engineering Coordinating Committee, в который вовлечено сообщество IEEE Computer Society. Назначение SWEBOK — в объединении знаний по инженерии программного обеспечения (разработке программного обеспечения).
Rational Unified Process — унифицированный процесс разработки ПО компании Rational с однозначно выраженными рекомендациями по разработке ПО, включающими в себя перечень всех необходимых деятельностей, выполняемых проектными ролями на каждой итерации, и шаблонов артефактов.
Microsoft Solution Framework (MSF) не является методологией разработки ПО. MSF предлагает подходы, основанные на определенной совокупности принципов, моделей, дисциплин, руководств и методик для проектов различной степени сложности, ориентированных на поставку решений.
Iconix — Процесс разработки программного обеспечения с использованием ограниченного количества UML моделей и диаграмм, состоящий из небольших шагов, ведущих к цели.
Спиральная разработка Barry W. Boehm (spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.
Agile — Гибкая методология разработки программного обеспечения.
Экстремальное программирование (англ. Extreme Programming, XP) — одна из гибких методологий разработки программного обеспечения. Авторы методологии — Кент Бек, Уорд Каннингем, Мартин Фаулер и др.

Риски и вероятные причины наступления рисков

Риски качества конечного продукта:

Недостижения бизнес-целей заказчика.
Неприменимости системы в реальном бизнесе заказчика.
Неудовлетворенности заказчика.
Противоречия ожиданий заказчика правилам его бизнеса.
Неправильного понимания поведения системы.
Неполного понимания всего поведения системы.
Нереализации системой всех бизнес-целей заказчика.
Несоответствия поведения системы ожиданиям заказчика.
Неправильной реализации поведения системы.
Нереализации ожидаемых функций.
Пропущенных вариантов использования.
Отторжения и сопротивления внедрения системы.
Реализации требований, не нужных бизнесу.
Неудовлетворительной работы по скорости, масштабированию и нагрузке.
Неоптимальной реализации поведения.
«Голд платины» — реализации никому не нужных «дорогих» функций.
Низкого качества тестирования.
Невозможности приемочных испытаний.
Сложности в поддержке и сопровождении продукта.

Вероятные причины наступления риска:

Не выявили и не утвердили с заказчиком все бизнес-требования заказчика.
Не выявили и не утвердили с заказчиком все бизнес-правила в бизнесе заказчика.
Не выявили и не утвердили с заказчиком все его ожидания.
Не выполнили трассировку правил бизнеса на ожидания заказчика.
Не выявили и не утвердили с заказчиком все варианты использования системы.
Высокий уровень описания выявленных вариантов использования.
Не выполнили трассировку бизнес-требований на варианты использования.
Не выполнили трассировку ожиданий заказчика и пользовательских требований на варианты использования.
Не выявили и не утвердили в проектной команде все варианты использования системы.
Не выявили и не утвердили в проектной команде все функциональные требования к системе.
Не выполнили трассировку «от вариантов использования» к функциональным требованиям.
Не выявили и не утвердили с заказчиком все требования пользователей системы.
Не выполнили трассировку требований бизнеса на требования пользователей.
Не выявили и не утвердили в проектной команде нефункциональные требования.
Не выполнили трассировку нефункциональных требований на варианты использования.
Не выполнили трассировку пользовательских требований на варианты использования.
Не выполнили трассировку функциональных требований на нефункциональные.
Не выполнили трассировку пользовательских требований на нефункциональные.
Не выполнили трассировку бизнес-требований на нефункциональные.
Не показали реализацию каждого значимого варианта использования системы конкретными классами системы («оторванная от поведения архитектура» может привести к излишней сложности архитектуры, кроме того, существует риск не заметить очевидных «пересечений» одной и той же функциональности по реализации разными классами). Без углубленного анализа поведения системы (построения диаграмм пригодности вариантов использования, диаграмм активности, диаграмм последовательности, модели анализа, логической модели системы) есть риск несвоевременного выявления нефункциональных требований, важных с точки зрения реализации продукта.
Не выполнили трассировку утвержденных требований пользователя, бизнес-требований, бизнес-правил и ожиданий заказчика на варианты использования.
Отсутствие базы для создания тестовых спецификаций — не выявили функциональных требований, нет описанных вариантов использования системы.
Нет утвержденных функциональных требований для формальной сдачи-приемки системы заказчику.
Отсутствие материалов для написания пользовательской документации, для разработки рекомендаций и обучающих курсов

Используемая литература для подготовки статьи

А. Перерва, В. Иванова — «Путь Аналитика»

5 2 Голоса

Рейтинг статьи