Из данной презентации Вы узнаете:
Кто такой Аналитик?
Чем он занимается?
Что он должен знать и уметь?
Почему требования так важны?
Что Вас ждет дальше?
Презентация предназначена для знакомства с ролью Аналитика (или ИТ специалиста, работающего с требованиями) и презентации полного курса «Разработка и управление требований к ПО".
Запись вебинара: http://vimeo.com/61915197
2. Кто я?
Разработчик и сисадмин
Аналитик
Ведущий аналитик
Руководитель аналитической группы
Менеджер проектов
CIO
Идеолог uml2.ru
Тренер
Консультант
Докладчик на многих конференциях
Байкин Александр
bas@uml2.ru
http://uml2.ru
http://blogs.uml2.ru/blogs/bas
http://baikin.moikrug.ru
2
10. Задачи Аналитика
Определить ЗЛ и Пользователей
Понять проблемы, почему нужна Система
Очертить бизнес-требования
Собрать и проанализировать требования
Написать ТЗ
Создать модель требований
Руководить проверкой требований
Способствовать приоритезации Тр.
Управлять изменениями требованиями
10
11. Качества Аналитика
Умение слушать и задавать вопросы
Аналитический склад ума
Наблюдательность и внимание к деталям
Возможность посмотреть с высока
Навыки организации совещаний
Хорошие письменный язык
Организационные навыки
Взаимодействие с различными людьми
Креативность
11
12. Аналитик должен знать
Требования – основа всего
Изучение Пр. Обл. и Системы
Как выявлять и описывать Цели
Методы выявления и анализа требований
Методы описания и проверки требований
Методы моделирования
Принципы управления требованиями
Процесс разработки ПО (итерационный)
Права и обязанности Заказчика
12
13. Права Заказчика
Аналитик будет говорит на его языке
Аналитик будет изучать его Предметную Обл и Цели
Аналитик будет обрабатывать выданную информацию
Аналитик объяснит ему всю Техническую часть
Аналитик будет относиться к Заказчику с уважением
Аналитики будут предлагать идеи и альтернативы
Требования будут понятны Заказчику
Требования будут направлены на использование уже
существующих компонентов ПО
Цена, влияние и замена будут адекватно оценены
Заказчик получит Систему, которая отвечает его
потребностям по функциональности и качеству
13
14. Обязанности Заказчика
Обучать Аналитика его Пр Обл и жаргону
Уделять достаточно время Аналитику
Быть конкретным и точным при предоставлении
информации
Принимать решения по требования во время
Доверять оценкам Аналитиков
Выставлять приоритеты по требованиям
Проверять требования и документы
Предоставлять изменения без задержек
Следовать процессу разработки при изменениях
Уважать труд Аналитика
14
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
19. Требования к ПО
1. Условие или возможность, требуемое
Пользователем для решения проблемы
или достижения некой цели.
2. Некое свойство ПО, которым должна
обладать система или ее компонент, чтобы
удовлетворить требования контракта,
стандарта, спецификации либо иной
формальной документации.
3. Документированное представление условия
или возможности, описанных в п.1 и п.2
19
21. Типы Требований
Функциональные Нефункциональные
Бизнес-
требования
Границы проекта
Бизнес-
Пользовательские правила
требования Атрибуты
качества
Спецификация ПТ
Системные Внешний
требования интерфейс
Функциональные
Ограничения
требования
Спецификация требований к ПО
21
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
32. Литература
К. Вигерс,
Разработка требований к программному обеспечению
А. Коберн,
Современные методы описания функциональных
требований к системам
У. Леффингуэлл,
Принципы работы с требованиями к программному
обеспечению. Унифицированный подход
Полный список литературы:
http://softreqsru.wordpress.com/2009/01/28/analystbookshelf/
43
41. Практические занятия
Применение методов
– Сбора требований,
– Анализа требований,
– Проверки требований.
Написание Концепции и ТЗ.
Основные разделы ПУТ.
52