1.
Лекция 6. Особенности работы системного аналитика
ПРОМЫШЛЕННАЯ РАЗРАБОТКА ПО

2.
• Кто такие системные
аналитики?
• Цели и задачи аналитика в
проекте
• Особенности первичного
анализа системы
• Участие аналитика в процессе
разработки
• Качества, необходимые
аналитику
О ЧЁМ БУДЕМ ГОВОРИТЬ СЕГОДНЯ

3.
СИСТЕМНЫЙ АНАЛИТИК - ЭТО
Специалист в области анализа предметной
области и формулирования требований к
разрабатываемым информационным системам
и прикладному программному обеспечению

4.
• Формирование полных,
непротиворечивых и
актуальных требований к
системе
• Соответствие
разрабатываемой системы
ожиданиям пользователя
ЦЕЛИ АНАЛИТИКА
Проф. стандарт «системный аналитик»: http://www.apkit.ru/committees/education/meetings/standarts.php

5.
• Исследование предметной
области системы
• Детальное описание системы и
составление соответствующей
документации
• Формирование требований к
системе
• Поддержание требований в
актуальном состоянии
• Взаимодействие с заказчиком
и командой разработки
ОСНОВНЫЕ ЗАДАЧИ

6.
• Написание проектной
документации
• Декомпозиция задач для
первичной оценки трудозатрат
• Создание макетов
пользовательского интерфейса
ДОПОЛНИТЕЛЬНЫЕ ЗАДАЧИ

7.
Аналитик отвечает за то, ЧТО будет сделано в то время, как команда
разработки за то, КАК это будет сделано
СЛЕДСТВИЕ 1

8.
Успех проекта напрямую зависит от того, насколько хорошо аналитик
проработал требования
СЛЕДСТВИЕ 2

9.
Более половины всех неудач проектов связаны с проблемами в управлении
требованиями: неполные требования, бесконтрольные изменения и т.д.
ФАКТ О ПРОВАЛЕ ПРОЕКТА

10.
SPIN-OFF: ВАРИАНТЫ ОПЛАТЫ ЗАКАЗНОЙ
РАЗРАБОТКИ

11.
• Оплата производится по факту
затраченных часов
• Изменения оплачиваются в
общем потоке
• Обычно оплата производится
периодически
• Стоимость проекта
рассчитывается до его старта
• Каждое отклонение от ТЗ
рассматривается как
изменение и добавляется в
общую стоимость
• Оплата приурочена к
контрольным точкам проекта
ВАРИАНТЫ ОПЛАТЫ ЗАКАЗНОЙ РАЗРАБОТКИ
Fixed Price Time & Material

12.
ПОДРОБНЕЕ О ЗАДАЧАХ

13.
• Общение с
заинтересованными лицами
• Понимание задач, решаемых
пользователями
• Моделирование бизнес-
процессов предметной области
• Исследование решений,
которые используются в
данный момент
ИССЛЕДОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

14.
• Описание общего списка
функций системы
• Детальное описание каждой
функции
• Уточнение деталей у заказчика
• Описание ограничений и
нефункциональных требований
• Согласование списка функций
с заказчиком или
заинтересованными лицами
ФОРМИРОВАНИЕ ТРЕБОВАНИЙ

15.
• Уточнение неясных деталей
• Выяснение его видения
отдельных функций и системы
в целом
• Выяснение нефункциональных
требований
• Утверждение спецификации
• Трансляция вопросов команды
ВЗАИМОДЕЙСТВИЕ С ЗАКАЗЧИКОМ

16.
• Доведения требований до
каждого разработчика
(постановка задачи)
• Объяснение непонятных
моментов в требованиях
• Решение спорных вопросов
• Консультация тестировщика
ВЗАИМОДЕЙСТВИЕ С КОМАНДОЙ РАЗРАБОТКИ

17.
Аналитик – представитель заказчика в команде разработки
СЛЕДСТВИЕ 3

18.
ПЕРВИЧНЫЙ АНАЛИЗ ПРОЕКТА

19.
• Заказчик предоставляет заявку на
предложение (Request for proposal)
• На основе RFP аналитик формирует
видение системы и задаѐт
уточняющие вопросы
• Заказчик даѐт ответы на вопросы
• Аналитик предоставляет
коммерческое предложение (proposal):
видение проекта и грубую оценку
трудозатрат
• При удовлетворении заказчика
запускается фаза анализа системы
ПРОЦЕСС ПЕРВИЧНОГО АНАЛИЗА ПРИ ЗАКАЗНОЙ
РАЗРАБОТКЕ
• Аналитик детально прорабатывает
требования к системе
• Заказчик предоставляет
дополнительную информацию и
вносит коррективы
• Заказчик утверждает ТЗ
• Аналитик формирует список
функций системы, после чего
производится их финальная оценка
вместе с командой разработки
• Разрабатывается архитектура
системы
Предпродажная фаза
(presale)
Фаза анализа*
В зависимости от методологии разработки содержание фазы анализа может меняться

20.
• RFP иногда содержит всего
пару абзацев
• Подготовка коммерческого
предложения идѐт в очень
сжатые сроки
• Часто работа идѐт в условиях
жѐсткой конкуренции
• Первичная оценка может в
несколько раз отличаться от
финальной (обычно – в
меньшую сторону)
ОСОБЕННОСТИ PRESALE-ФАЗЫ
При работе на аукционных площадках доля выигранных проектов ~3%

21.
• Чем детальнее будет
проработаны требования, тем
меньше проблем возникнет в
ходе разработки проекта
• Самая большая опасность для
проекта – необходимые
требования и функции,
отсутствующие в ТЗ
• Требования обязательно будут
меняться в процессе
разработки. Важно управлять
этими изменениями
ОСОБЕННОСТИ ФАЗЫ АНАЛИЗА
Некоторые методологии не предполагают отдельную фазу анализа

22.
ПОДДЕРЖКА СИСТЕМЫ В ПРОЦЕССЕ
РАЗРАБОТКИ

23.
• Требования для функции
должны быть сформированы
к началу её разработки
• В процессе разработки
требования к системе не раз
претерпят изменения
• Новые требования должны
обрабатываться и добавляться в
систему таким же образом, как
первоначальные
• Требования должны быть
понятными всем участникам
проектной команды
ОСОБЕННОСТИ АНАЛИТИКИ ВО ВРЕМЯ
РАЗРАБОТКИ

24.
ЕЩЁ РАЗ О СТАТИСТИКЕ
• 51% всех провалов проектов случается из-за некачественного управления
изменениями требований
• 48% всех провалов проектов случается из-за неправильной оценки трудозатрат (в
том числе из-за неучтѐнных функций
Роберт Гласс: «Факты и заблуждения профессиоального программирования»
http://www.ozon.ru/context/detail/id/3707281/

25.
• Способность увидеть систему с
точки зрения пользователя
• Дотошность, внимание к
деталям
• Способность увидеть скрытые
функции системы
• Способность разговаривать на
языке как заказчика, так и
разработчиков
• Навыки технического писателя
• В большинстве случаев – знание
английского
ОСНОВНЫЕ НАВЫКИ СИСТЕМНОГО АНАЛИТИКА

26.
ВРЕМЯ ЗАДАВАТЬ ВОПРОСЫ