1.
01. Аналитик.Введение в профессию. Байкин Александр www.uml2.ru bas@uml2.ru

2.
Кто я?  Разработчик и сисадмин  Аналитик  Ведущий аналитик  Руководитель аналитической группы  Менеджер проектов  CIO  Идеолог uml2.ru  Тренер  Консультант  Докладчик на многих конференциях Байкин Александр bas@uml2.ru http://uml2.ru http://blogs.uml2.ru/blogs/bas http://baikin.moikrug.ru 2

3.
План 3

4.
Калькулятор? 4

5.
Реальная разработка ПО 5

6.
Конура или Отель? Область известна Решение простое Один человек Не требует поддержки Рамки требований не меняются 6

7.
Зачем нужны Роли? Плюсы Риски• Распараллелить • Накладные расходы работы на коммуникации• Узкая специализация • Искажение знаний• Распределение • Организация обязанностей в процесса команде • Ожидание другого• Коллективный разум специалиста 7

8.
Кто такой Аналитик? 8

9.
Кому, зачем, что, как? ЗЛ •Кому? Пр •Зачем? Тр •Что?Реал •Как? 9

10.
Задачи Аналитика Определить ЗЛ и Пользователей Понять проблемы, почему нужна Система Очертить бизнес-требования Собрать и проанализировать требования Написать ТЗ Создать модель требований Руководить проверкой требований Способствовать приоритезации Тр. Управлять изменениями требованиями 10

11.
Качества Аналитика Умение слушать и задавать вопросы Аналитический склад ума Наблюдательность и внимание к деталям Возможность посмотреть с высока Навыки организации совещаний Хорошие письменный язык Организационные навыки Взаимодействие с различными людьми Креативность 11

12.
Аналитик должен знать Требования – основа всего Изучение Пр. Обл. и Системы Как выявлять и описывать Цели Методы выявления и анализа требований Методы описания и проверки требований Методы моделирования Принципы управления требованиями Процесс разработки ПО (итерационный) Права и обязанности Заказчика 12

13.
Права Заказчика Аналитик будет говорит на его языке Аналитик будет изучать его Предметную Обл и Цели Аналитик будет обрабатывать выданную информацию Аналитик объяснит ему всю Техническую часть Аналитик будет относиться к Заказчику с уважением Аналитики будут предлагать идеи и альтернативы Требования будут понятны Заказчику Требования будут направлены на использование уже существующих компонентов ПО Цена, влияние и замена будут адекватно оценены Заказчик получит Систему, которая отвечает его потребностям по функциональности и качеству 13

14.
Обязанности Заказчика Обучать Аналитика его Пр Обл и жаргону Уделять достаточно время Аналитику Быть конкретным и точным при предоставлении информации Принимать решения по требования во время Доверять оценкам Аналитиков Выставлять приоритеты по требованиям Проверять требования и документы Предоставлять изменения без задержек Следовать процессу разработки при изменениях Уважать труд Аналитика 14

15.
Кол-во успешных проектов2011 34% 51% 15%2009 32% 44% 24%2006 35% 46% 19%2004 29% 53% 18%2002 34% 51% 15%2000 28% 49% 23%1998 26% 46% 28%1996 27% 33% 40%1994 16% 53% 31% 0% 20% 40% 60% 80% 100% Успешные Частично Провал 15

16.
Причины успеха проектов Факторы успеха % 1. Вовлечение пользователей 15,9% 2. Поддержка топ менеджмента 13,9% 3. Понятные и четкие требования 13,0% 4. Правильное планирование проекта 9,6% 5. Реалистичные ожидания 8,2% 6. Небольшие этапы разработки 7,7% 7. Компетентные сотрудники 7,2% 8. Владение права собственности 5,3% 9. Ясная концепция и цели 2,9% 10. Напряженная работа 2,4% 11. Другое 13,9% 16

17.
Причины провала проектов Факторы провала % 1. Неполные требования 13,1% 2. Недостаточное вовлечение пользователей 12,4% 3. Недостаток ресурсов 10,6% 4. Нереалистичные ожидания 9,9% 5. Недостаточная поддержка топ менеджеров 9,3% 6. Изменение требований 8,7% 7. Плохое планирование 8,1% 8. Это уже не нужно 7,5% 9. Недостаток ИТ управления 6,2% 10. Технологическая неграмотность 4,3% 11. Другое 9,9% 17

18.
Цена исправления ошибки Цена ошибки 100-1000 раз 18

19.
Требования к ПО1. Условие или возможность, требуемое Пользователем для решения проблемы или достижения некой цели.2. Некое свойство ПО, которым должна обладать система или ее компонент, чтобы удовлетворить требования контракта, стандарта, спецификации либо иной формальной документации.3. Документированное представление условия или возможности, описанных в п.1 и п.2 19

20.
На какой вопрос отвечают тр? ЧТО? 20

21.
Типы Требований Функциональные Нефункциональные Бизнес- требования Границы проекта Бизнес- Пользовательские правила требования Атрибуты качества Спецификация ПТ Системные Внешний требования интерфейс Функциональные Ограничения требования Спецификация требований к ПО 21

22.
Бизнес-правила 22

23.
Атрибуты качества Availability Usability Maintainability Robustness Efficiency Reliability Quality Portability Attributes Interoperability Flexibility Testability Reusability Integrity 23

24.
Хорошие Требования Полные Корректные Реализуемые Необходимые Приоритезированные Однозначные Проверяемые 24

25.
Хорошая Спецификация Полная Непротиворечивая Модифицируемая Трассируемая 25

26.
Процесс работы с тр. Проверка Выявление Управление Документ Анализ 26

27.
Документы требований • Vision (RUP, IEEE, Wiegers) • Концепция АС (ГОСТ 7.32 Отчет о НИР) BR • Use Case Specification (RUP) • Use Case Document (Wiegers)UR • User Stories (Agile) • Software Requirement Specification (RUP, IEEE 830-1998, Wiegers) • System Requirement Spec (IEEE) SR • Техническое Задание (ГОСТ 34.602) 38

28.
Различные названия Аналитика Аналитик ИТ аналитик Системный аналитик Бизнес аналитик Консультант Постановщик задач …… 39

29.
БА vs СА Бизнес Аналитик Системный Аналитик• Знание Пр. Обл. • Изучение Пр. Обл.• Анализ структуры Орг. • Формулирование Задач ПО• Участие в Стратегии • Изучение ПО-конкурентов• Выявление З. Л. • Выявление Пользователей• Описание БП • Формулирование ПТ• Выявление Целей • Формулирование ФТ и БПр• Выявление Проблем • Формулирование НеФТ• Выявление Потребностей • Участие в разработке Арх.• Оптимизация БП • Участие в Тестировании• Формирование Задач ПО • Участие во Внедрении 40

30.
БА vs СА Бизнес Аналитик Системный Аналитик• Знание Пр. Обл. • Изучение Пр. Обл.• Анализ структуры Орг. • Формулирование Задач ПО• Участие в Стратегии • Изучение ПО-конкурентов• Выявление З. Л. • Выявление Пользователей• Описание БП • Формулирование ПТ• Выявление Целей • Формулирование ФТ и БПр• Выявление Проблем • Формулирование НеФТ• Выявление Потребностей • Участие в разработке Арх.• Оптимизация БП • Участие в Тестировании• Формирование Задач ПО • Участие во Внедрении 41

31.
Профстандарты BABOK v.2 Стандарт АПКИТ Близкие своды знаний и стандарты: http://bas4all.livejournal.com/23385.html 42

32.
Литература К. Вигерс, Разработка требований к программному обеспечению А. Коберн, Современные методы описания функциональных требований к системам У. Леффингуэлл, Принципы работы с требованиями к программному обеспечению. Унифицированный подход Полный список литературы: http://softreqsru.wordpress.com/2009/01/28/analystbookshelf/ 43

33.
План курса 44

34.
Сбор требований 45

35.
Анализ требований 46

36.
Документ. требований 47

37.
Проверка требований 48

38.
Управление требований 49

39.
Проблемы требований 50

40.
Моделирование требований 51

41.
Практические занятия Применение методов – Сбора требований, – Анализа требований, – Проверки требований. Написание Концепции и ТЗ. Основные разделы ПУТ. 52

42.
Успех 53