'

Введение. Роль бизнес-аналитика в жизненном цикле разработки ПО

Понравилась презентация – покажи это...





Слайд 0

Сергей Сыроежкин Бизнес-аналитик, консультант В рамках курса лекций: «Разработка требований к программному обеспечению», мехмат, БГУ 01.09.2010 Введение. Роль бизнес-аналитика в жизненном цикле разработки ПО


Слайд 1

Введение


Слайд 2

Данный курс: что, как и почему Цель (что): изучение процесса разработки требований к ПО (Карл Вигерс) Цель (как): на собственной практике (разработка документов/артефактов – требований к ПО) Почему (востребованность): «кем и где работают выпускники мехмата и КМ в частности?» Кем работаете Вы? 80% из вас будет работать в IT (разработчик, тестировщик, аналитик) Почему я? (дать знания и умения, консультант)


Слайд 3

Форма проведения курса Практические занятия учебный пример: разработка требований к «своему» ПО в группах по 2 человека; используем приложения MS Office (Word, Visio); прототип в AxureRP. Отчетность выполнение плана (посещения, практические задания в срок); экзамен: два устных вопроса + практическое задание. Лекции в формате бизнес-тренинга презентации в PowerPoint (фактически конспект лекций); будут выкладываться на req.siroezkin.info. преподаватель - консультант


Слайд 4

Содержание лекций Роль аналитика в проекте по разработке ПО; Работа в MS Word; Методы сбора требований, описание границ и образа проекта; Описание бизнес-процессов; Построение диаграммы «High-level use cases», сбор нефункциональных требований; Прототипирование; Определение пользовательских требований; Определение функциональных требований, ограничений и правил, принципы прослеживаемости требований; Качество требования; Инструменты по хранению, управлению и каталогизированию требований.


Слайд 5

Роль бизнес-аналитика в жизненном цикле разработки ПО


Слайд 6

Системный аналитик: Кто он? Системный анализ (классически) – методология исследования объектов Исследование операций; Системы поддержки принятия решений; Почему «математик. математик – системный аналитик» Философия систем – математик>модель; Математика – набор прикладных моделей; Что такое наука; Системный аналитик – Бизнес-аналитик – Аналитик требований


Слайд 7

Бизнес-аналитик Бизнес-аналитик в бизнесе – это бизнес-консультант Бизнес-аналитик в IT: интерфейс между IT и бизнесом ; системный аналитик – значит процессный аналитик; функциональный аналитик.


Слайд 8

В двух словах Аналитик помогает определить разницу между тем, что заказчик ГОВОРИТ ЧТО ОН ХОЧЕТ, и тем, что ЕМУ ДЕЙСТВИТЕЛЬНО НЕОБХОДИМО Это проще сказать чем сделать


Слайд 9

Требования к ПО Совокупность утверждений относительно свойств ПО, подлежащая реализации в процессе разработки


Слайд 10

Уровни требований к ПО


Слайд 11

Процесс разработки ПО


Слайд 12

Основное связующее звено в проекте


Слайд 13

Основные обязанности аналитика Сбор; Анализ; Документирование; Утверждение потребностей заказчика проекта.


Слайд 14

Результаты работы “Опытный аналитик может сократить трудозатраты проекта на одну треть по сравнению с неопытным аналитиком, а проекты с высококвалифицированным аналитиком требуют половину трудозатрат по сравнению с проектами которые используют менее квалифицированных аналитиков” (Barry Boehm, Software Cost Estimation with Cocomo II) а проекты без аналитика могут закончится провалом!


Слайд 15

Обязанности аналитика в двух словах Аналитик должен в начале понять! ожидания пользователей от новой системы, обозначить функциональные требования и показатели качества, которые позволят менеджеру проекта оценить, разработчикам спроектировать и создать, а тестировщикам проверить продукт.


Слайд 16

Обязанности аналитика (сбор) Определение бизнес потребностей; Идентификация заинтересованных сторон и пользователей продукта; Извлечение требований;


Слайд 17

Определение бизнес потребностей “Почему мы беремся за этот проект?” Бизнес потребности включают: Формулировка бизнес целей организации; Первичное видение того, что будет представлять система и что она будет делать. Результаты: Видение и границы проекта.


Слайд 18

Идентификация заинтересованных сторон и пользователей продукта Определение основных классов пользователей продукта; Работа со спонсором проекта что бы выделить подходящих представителей для каждого класса пользователей; Результаты: Записать вклад каждого представителя со стороны заказчика который вы бы хотели иметь и договориться о соответствующем уровне участия в проекте каждого из представителей заказчика.


Слайд 19

Извлечение требований “Требования для программного продукта не валяются просто так в ожидании того, что кто-то соберет их” Karl E. Wiegers. Результаты: Функциональные атрибуты; Атрибуты качества; Показатели производительности; Бизнес правила; Внешние интерфейсы; Ограничения.


Слайд 20

Обязанности аналитика (разработка) Анализ требований; Написание спецификаций; Моделирование требований.


Слайд 21

Анализ требований “Ищите вторичные требования которые являются логической последовательностью запросов заказчика, так же хорошо как охотитесь на те не явно выраженные требования, которые должны быть, но не были озвучены” Karl E. Wiegers Поиск неоднозначных слов которые служат причиной неясности и неразберихи Выделение конфликтных требований и областей требующих большей детализацией Спецификация функциональных требований до необходимого уровня детализации для разработчиков которые разрабатывают продукт.


Слайд 22

Написание спецификации и моделирование требований Эффективная разработка требований приводит к более широкому и глубокому пониманию нужд заказчика и как следствие созданию системы, которая решает проблемы заказчика Результаты: Хорошо организованная спецификация Графические аналитические модели, таблицы, математические выражения, прототипы


Слайд 23

Обязанности аналитика (управление) Управление согласованием; Управление требованиями.


Слайд 24

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


Слайд 25

Управление требованиями Установка базовой линии требований; Хранение требований в системе управления требованиями; Отслеживание статуса каждого функционального требования от начала проекта до верификации требования в продукте; Сбор трассируемой информации от участников команды для соединения конкретных требований с другими элементами (задачи, варианты тестирования и т.д.). Результаты: Управление изменениями в требованиях через процесс управления изменениями и с помощью средства управления требованиями.


Слайд 26

Способности аналитика 10 способностей которые необходимы аналитику для успеха: Умение слушать; Умение проводить интервью и задавать вопросы; Умение анализировать; Умение управлять групповой работой; Наблюдательность; Умение писать; Умение структурировать информацию; Умение моделировать; Умением общаться и ладить с людьми; Креативность.


Слайд 27

Умение слушать Активное слушание (исключение всего, что может отвлекать; установка ключевых моментов для подтверждения правильности понимания) Быстро понимать то, что говорят, а также читать между строк для того, чтобы определить то, что возможно не решаются сказать. Следить за предположениями которые выделяют то, что вы слышали от других и вашей собственной интерпретацией.


Слайд 28

Умение проводить интервью и задавать вопросы Способность задавать правильные вопросы: “Что должно произойти если...?” “Может ли <определенная проблема> когда либо произойти?” …..


Слайд 29

Умение анализировать Способность оперировать на различных уровнях абстракции: Опускаться от высокоуровневой информации к деталям; Отталкиваться от специфических нужд одного пользователя к набору требований, которые принадлежат к целому классу пользователей; Оценивать информацию полученную из различных источников информации для урегулирования конфликтов в требованиях; Отделять желания пользователей от их нужд.


Слайд 30

Наблюдательность Способность выделить тонкости которые пользователь либо заказчик не упоминал и таким образом обнажить новые темы для обсуждения.


Слайд 31

Умение структурировать информацию Способность структурировать все части информации в единое целое Вход: Огромные массивы беспорядочной информации собранной в результате получения и анализа требований Выход: Функциональная спецификация


Слайд 32

Умение моделировать Типичный инструментарий аналитика BPMN UML EPC flowchart data flow diagrams entity-relationship diagrams …..


Слайд 33

И в завершение…. Умение писать; Умение общаться и ладить с людьми; Креативность; Умение организовать групповую работу.


Слайд 34

Спасибо за внимание!


×

HTML:





Ссылка: