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

Содержание

Введение

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

мехмат, БГУ
01.09.2010

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

Слайд 2Введение

Слайд 3Данный курс: что, как и почему
Цель (что): изучение процесса разработки требований

к ПО (Карл Вигерс)
Цель (как): на собственной практике (разработка документов/артефактов – требований к ПО)

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

Почему я? (дать знания и умения, консультант)

Слайд 4Форма проведения курса
Практические занятия
учебный пример: разработка требований к «своему» ПО в

группах по 2 человека;
используем приложения MS Office (Word, Visio);
прототип в AxureRP.

Отчетность
выполнение плана (посещения, практические задания в срок);
экзамен: два устных вопроса + практическое задание.

Лекции в формате бизнес-тренинга
презентации в PowerPoint (фактически конспект лекций);
будут выкладываться на req.siroezkin.info.
преподаватель - консультант

Слайд 5Содержание лекций
Роль аналитика в проекте по разработке ПО;
Работа в MS Word;
Методы

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

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

Слайд 7Системный аналитик: Кто он?
Системный анализ (классически) – методология исследования объектов
Исследование операций;
Системы

поддержки принятия решений;

Почему «математик. математик – системный аналитик»
Философия систем – математик→модель;
Математика – набор прикладных моделей;
Что такое наука;

Системный аналитик – Бизнес-аналитик – Аналитик требований

Слайд 8Бизнес-аналитик
Бизнес-аналитик в бизнесе – это бизнес-консультант
Бизнес-аналитик в IT:
интерфейс между IT и

бизнесом ;
системный аналитик – значит процессный аналитик;
функциональный аналитик.

Слайд 9В двух словах
Аналитик помогает определить разницу между тем, что заказчик ГОВОРИТ

ЧТО ОН ХОЧЕТ, и тем, что ЕМУ ДЕЙСТВИТЕЛЬНО НЕОБХОДИМО



Это проще сказать чем сделать

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

разработки

Слайд 11Уровни требований к ПО

Слайд 12Процесс разработки ПО

Слайд 13Основное связующее звено в проекте

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

Слайд 15Результаты работы
“Опытный аналитик может сократить трудозатраты проекта на одну треть по

сравнению с неопытным аналитиком,

а проекты с высококвалифицированным аналитиком требуют половину трудозатрат по сравнению с проектами которые используют менее квалифицированных аналитиков”

(Barry Boehm,
Software Cost Estimation with Cocomo II)


а проекты без аналитика могут закончится провалом!

Слайд 16Обязанности аналитика в двух словах
Аналитик должен в начале понять! ожидания пользователей

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

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

Слайд 18Определение бизнес потребностей
“Почему мы беремся за этот проект?”

Бизнес потребности включают:
Формулировка бизнес

целей организации;
Первичное видение того, что будет представлять система и что она будет делать.

Результаты:
Видение и границы проекта.

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

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

Слайд 20Извлечение требований
“Требования для программного продукта не валяются просто так в ожидании

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

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

Слайд 22Анализ требований
“Ищите вторичные требования которые являются логической последовательностью запросов заказчика, так

же хорошо как охотитесь на те не явно выраженные требования, которые должны быть, но не были озвучены”
Karl E. Wiegers

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

Слайд 23Написание спецификации и моделирование требований
Эффективная разработка требований приводит к более широкому

и глубокому пониманию нужд заказчика и как следствие созданию системы, которая решает проблемы заказчика

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

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

Слайд 25Управления согласованием
Аналитик должен гарантировать, что требования удовлетворяют нуждам заказчика и что

они:
понятные;
законченные;
правильные;
выполнимые;
необходимые;
трассируемые;
не двусмысленные;
проверяемые.

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

Слайд 26Управление требованиями
Установка базовой линии требований;
Хранение требований в системе управления требованиями;
Отслеживание статуса

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

Результаты:
Управление изменениями в требованиях через процесс управления изменениями и с помощью средства управления требованиями.

Слайд 27Способности аналитика
10 способностей которые необходимы аналитику для успеха:

Умение слушать;
Умение проводить интервью

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

Слайд 28Умение слушать
Активное слушание (исключение всего, что может отвлекать; установка ключевых моментов

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

Слайд 29Умение проводить интервью и задавать вопросы
Способность задавать правильные вопросы:
“Что должно произойти

если...?”
“Может ли <определенная проблема> когда либо произойти?”
…..

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

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

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

образом обнажить новые темы для обсуждения.

Слайд 32Умение структурировать информацию
Способность структурировать все части информации в единое целое

Вход:
Огромные массивы

беспорядочной информации собранной в результате получения и анализа требований

Выход:
Функциональная спецификация

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

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

работу.

Слайд 35Спасибо за внимание!

Похожие презентации

Волгоградский кооперативный институт. Команда "402". Крытый скейт-парк. Бизнес-идея 288
Менеджмент гостиничного и ресторанного бизнеса Дистанционный учебный курс 24-30 октября 2010г. г. Минск 267
Тур на Мадагаскар 283
Информация о ключевом обеспечении: ул. Кирова, д.21 250
Шаблон бизнес-модели с заполненными блоками по Остервальдеру и Пинье 338
Бизнес-план ООО Уют (ритуальное агентство) 422

Обратная связь

Если не удалось найти и скачать презентацию, Вы можете заказать его на нашем сайте. Мы постараемся найти нужный Вам материал и отправим по электронной почте. Не стесняйтесь обращаться к нам, если у вас возникли вопросы или пожелания:

Email: Нажмите что бы посмотреть 

Что такое ThePresentation.ru?

Это сайт презентаций, докладов, проектов, шаблонов в формате PowerPoint. Мы помогаем школьникам, студентам, учителям, преподавателям хранить и обмениваться учебными материалами с другими пользователями.

Для правообладателей

Яндекс.Метрика