http://cmcons.com
http://uml2.ru
Методы оценки качества требований и работы аналитика
семинар 15 июня 2010 года - «ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ IBM RATIONAL ДЛЯ УЛУЧШЕНИЯ ПРОЦЕССОВ РАЗРАБОТКИ И СОПРОВОЖДЕНИЯ ПО»
* Классификация нефункциональных требований
* Шаблоны нефункциональных требований
* Численные значения нефункциональных требований
* Связи между нефункциональными и функциональными требованиями
* Влияние различных категорий нефункциональных требований друг на друга
* Атрибуты качества продукта и нефункциональные требования
* Роли в проекте, с которыми взаимодействует аналитик при выявлении и уточнении нефункциональных требований
Семинары и тренинги по делопроизводству, документообороту и архиву предприятияProfi-Cariera
http://www.seminarna.ru/
Семинары по делопроизводству проводят ведущие специалисты ВНИИДАД ведущего центра подготовки специалистов в области документоведения.
ВНИИДАД Всероссийский научно-исследовательский институт документоведения и архивного дела.
ВНИИДАД является единственным в России учреждением, занимающимся вопросами документационного обеспечения управления.
Целевая аудитория
Сотрудники службы ДОУ, офис-менеджеры, делопроизводители, секретари, архивариус
Презентация на конференции Software People 2009. Предлагается простой и практичный метод оценки трудозатрат в проектах разработки ПО, позволяющий количественно учесть риски в сроках работ, оперировать прогнозами в условиях высокой неопределенности, а также дающий инструменты проверки достоверности прогноза при помощи метрик.
Презентация к моему докладу на конференции SWP'11
- Цель управления как выполнение скоординиваронного и целенаправленного командного действия
- Понятие "трения", как основного отличия плана на бумаге от практического действия.
- "Тактика миссии" (Auftragstaktik) как философия управления, необходимая для преодоления "трения".
- 5-paragraph order и процесс планирования корпуса морской пехоты США, как пример системы, реализующий принцип тактики миссии.
- "Трение" в различных типах оргструктур в компаниях разработчиках ПО, и их совместимость с "тактикой миссии"
Презентация семинаров по деловой переписке с клиентамиProfi-Cariera
Пройдите курс по деловой переписке и превратите всех клиентов в лояльных Вашей организации. Деловая переписка - это Ваш имидж. Как научиться аргументированно и структурированно писать, грамотно оформлять письма, пользоваться речевыми клише? Все это узнаете на наших курсах. 15 лет помогаем лучшим бизнесам России стать еще эффективнее.
http://cmcons.com
http://uml2.ru
Методы оценки качества требований и работы аналитика
семинар 15 июня 2010 года - «ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ IBM RATIONAL ДЛЯ УЛУЧШЕНИЯ ПРОЦЕССОВ РАЗРАБОТКИ И СОПРОВОЖДЕНИЯ ПО»
* Классификация нефункциональных требований
* Шаблоны нефункциональных требований
* Численные значения нефункциональных требований
* Связи между нефункциональными и функциональными требованиями
* Влияние различных категорий нефункциональных требований друг на друга
* Атрибуты качества продукта и нефункциональные требования
* Роли в проекте, с которыми взаимодействует аналитик при выявлении и уточнении нефункциональных требований
Семинары и тренинги по делопроизводству, документообороту и архиву предприятияProfi-Cariera
http://www.seminarna.ru/
Семинары по делопроизводству проводят ведущие специалисты ВНИИДАД ведущего центра подготовки специалистов в области документоведения.
ВНИИДАД Всероссийский научно-исследовательский институт документоведения и архивного дела.
ВНИИДАД является единственным в России учреждением, занимающимся вопросами документационного обеспечения управления.
Целевая аудитория
Сотрудники службы ДОУ, офис-менеджеры, делопроизводители, секретари, архивариус
Презентация на конференции Software People 2009. Предлагается простой и практичный метод оценки трудозатрат в проектах разработки ПО, позволяющий количественно учесть риски в сроках работ, оперировать прогнозами в условиях высокой неопределенности, а также дающий инструменты проверки достоверности прогноза при помощи метрик.
Презентация к моему докладу на конференции SWP'11
- Цель управления как выполнение скоординиваронного и целенаправленного командного действия
- Понятие "трения", как основного отличия плана на бумаге от практического действия.
- "Тактика миссии" (Auftragstaktik) как философия управления, необходимая для преодоления "трения".
- 5-paragraph order и процесс планирования корпуса морской пехоты США, как пример системы, реализующий принцип тактики миссии.
- "Трение" в различных типах оргструктур в компаниях разработчиках ПО, и их совместимость с "тактикой миссии"
Презентация семинаров по деловой переписке с клиентамиProfi-Cariera
Пройдите курс по деловой переписке и превратите всех клиентов в лояльных Вашей организации. Деловая переписка - это Ваш имидж. Как научиться аргументированно и структурированно писать, грамотно оформлять письма, пользоваться речевыми клише? Все это узнаете на наших курсах. 15 лет помогаем лучшим бизнесам России стать еще эффективнее.
PMBOK Extension for Software Projects (in Russian)IAMCP MENTORING
The content of this presentation deals with species of software projects' management. The Extension strikes the specific features of software projects, team management, motivation, main project phases.
One of the main features is an attempt to combine waterfall and adaptive project management techniques.
Лицензированный центр "Профи-Карьера" проводит корпоративное обучение по различным тематикам. для сотрудников российских и международных компаний. Курсы повышения квалификации, семинары и тренинги, дистанционное обучение по управлению персоналом, секретариату, делопроизводству, бизнес-процессам, сервису и обслуживанию клиентов, телефонному общению. Звоните: +7 495 150 18 17, info@seminarna.ru, www.seminarna.ru
Dependency injection in Java EE 6 allows injecting dependencies into classes through constructors, setters, and fields. It supports injecting various types of beans including EJBs and managed beans. Features of CDI include qualifiers to select specific implementations of interfaces to inject, producer methods to dynamically provide dependencies, and interceptors for cross-cutting concerns. Scopes determine when injected instances are created and destroyed. Events allow classes to observe and respond to occurrences in the system.
Соединяя точки. Моделе-ориентированный процесс системного проектированияYulia Madorskaya
Презентация вице-президента 3SL, в которой описываются принципы MBSE, дается пример MBSE процесса, который использует NASA на базе 3SL Cradle и описываются диаграммы SysML
2. Об авторе доклада
• Наталья Желнова:
– С 1997 года занимается сбором,
систематизацией и управлением требованиями
в проектах по разработке ПО.
– 6 лет участия в консалтинговых проектах
(постановка процессов разработки ПО).
– Автор нескольких курсов по управлению
требованиями, управлению рисками в
проектах по разработке ПО.
– Редактор сайта Software People.
3. Тезисы доклада
• Роль бизнес-аналитика и системного аналитика
в проекте: «Зачем здесь все эти люди?»
• Различие границ ответственности проектных
ролей для системного и бизнес-аналитика
в разных методологиях.
• Как проверить качество артефактов, которые
готовят бизнес- и системный аналитик?
• Основные процессы, в которых участвуют
бизнес- и системный аналитик, и их аудит.
• Методы оценки работы бизнес- и системного
аналитика.
5. Что делает аналитик
• Три уровня навыков системных
аналитиков: первый, второй,
третий
• Обязательные и необязательные
навыки
• С какими ролями взаимодуйствует
6. Первый уровень
• Выявление заинтересованных лиц в проекте
• Управление ожиданиями заинтересованных
лиц
• Выявление высокоуровневых требований и
увязывание их с собранной информацией и
между собой
• Участие в проектировании системы:
– описание поведения системы
– выявление нефункциональных требований
7. Второй уровень
• Определение границ системы
• Выделение подсистем и определение их
границ
• Выявление низкоуровневых требований
– описания алгоритмов
– описания структур данных
– описания компонентов ПО
– описания низкоуровневых интерфейсов
– описания механизмов управления ресурсами и др
• Применение стандартов (ГОСТ, IEEE 1990)
8. Третий уровень
• Знание существующего IT-ландшафта и
умение определять перспективы его
развития в контексте выполняемого
проекта
• Участие в управлении рисками проекта
• Управление требованиями
– управление документами
– управление требованиями: участие в процессе
упрпвления полным жизненным циклом
требований и трассировки требований
10. RUP
• Бизнес-аналитик:
– описание бизнес-процессов
– изменение бизнес-процессов
– верхнеуровневые и функциональные требования к
системе
– управление изменениями, источниками которых
являются изменения бизнес-процессов
• Системный аналитик:
– функциональные и нефункциональные требования
– низкоуровневые требования
– изменения в IT-системах
– управление требованиями
– создание моделей для проектирования
11. Iconix
• Аналитик:
– выявление требований как бизнес-, так и
пользовательского уровня
– моделирование предметной области
– составление глоссария
– составление модели прецедентов
– сбор и систематизация требований к
пользовательскому интерфейсу
– управление требованиями
12. Agile
• Product Owner:
– требования бизнес-области
• «Аналитик»:
– системные требования
– требования к пользовательскому интерфейсу
13. Agile
• Product Owner:
– требования бизнес-области
• «Аналитик»:
– системные требования
– требования к пользовательскому интерфейсу
14. Разработка требований
Какую информацию собирает системный аналитик
scope: quality:
• пользователи системы, их роли и • требования к качеству продукта
число (производительность, масштабируемость,
• функции системы надежность, доступность, безопасность,
• системы, с которыми отказоустойчивость, алгоритмическая
предполагается интеграция сложность; системные требования:
• ограничения потребляемые ресурсы и требования к
• регламенты и стандарты, взаимодействию с внешним окружением;
влияющие на разработку требования к платформе; usability, etc.)
• приоритеты требований
15. Разработка требований
Какие артефакты при этом создаются
• профиль ЗЛ
• потребности ЗЛ
• требования (User Story, Use Case, перечень функций системы, НФТ)
• глоссарий
• описание реализации и архитектуры (в том числе и прототип UI)
• план тестирования
16. Связи между артефактами
uc Use Case Model
Requirements
«trace» «trace»
Use Case Model Data Flow s
Conceptual Model «trace»
«trace»
«trace» «trace» «trace»
Obj ect Model
«trace»
Components Deployment Model
«trace»
17. Связи между артефактами
uc Use Case Model
Requirements
«trace» «trace»
Use Case
Change Request
«trace»
«trace» «trace»
System Test Case Acceptance Test
Case
«trace»
«trace» «trace»
Bug
19. Основные артефакты
• Vision:
– требования бизнес-области
• Use Cases
– Пользовательские требования
• SRS:
– требования бизнес-области
– системные требования
– требования к пользовательскому интерфейсу
– нефункциональные требования
20. Качество требований
Полнота
• точность определения scope
• точность оценки степени влияния данного требования на достижение целей каждой из
заинтересованных сторон
• возможность составления детализированного плана работ в проекте (WBS)
• возможность оценок трудоемкости работ с требуемой точностью
• возможность календарного и ресурсного планирования работ
Однозначность
• одинаковое понимание требований всеми ролями в проектной команде
Необходимость
• каждое требование – шаг к достижению целей заинтересованных сторон
• каждое требование имеет свой источник (решаемая проблема)
Осуществимость
• результат проверки возможности реализации в условиях существующих ограничений
Проверяемость
• наличие однозначных критериев проверки корректности реализации данного требования
Управление требованиями: трассировки
21. Качество требований: риски
• На этапе концептуальной проработки продукта
• scope: не все заинтересованные стороны выявлены, не все цели и
проблемы заинтересованных сторон идентифицированы
• не все ограничения выявлены
• не все участники проекта одинаково понимают цели, задачи,
перспективы, связанные с проектом
• существуют конфликты между целями заинтересованных сторон
(решение: цели -> измеряемые показатели)
22. Качество требований: риски
• На этапе разработки
• time&cost&quality: риск переделок
• time&cost: невозможность точного планирования работ
• scope: невозможность реализовать те или иные требования
• quality: низкое качество продукта (много ошибок реализации; требования,
диктуемые стандартами, не выполняются)
• технические риски (неправильный выбор или несоблюдение технологий)
• На этапе тестирования
• quality: качественное тестирование продукта невозможно (отсутствуют критерии
проверки; трудности с локализацией ошибок)
23. Качество требований: проверка
и улучшение
• Процессы:
• верификация – соответствие одних создаваемых в ходе разработки и сопровождения ПО
артефактов другим, ранее созданным или используемым в качестве исходных данных, а
также соответствие этих артефактов и процессов их разработки правилам и стандартам
• валидация – соответствие любых создаваемых или используемых в ходе разработки и
сопровождения ПО артефактов нуждам и потребностям пользователей и заказчиков этого
ПО, с учетом законов предметной области и ограничений контекста использования ПО
• Полнота
• детализация
• Однозначность (ясность)
• уточнение
• унификация (анализ глоссария)
24. Качество требований: проверка
и улучшение
• Корректность отдельного требования и согласованность (непротиворечивость) системы
требований
• трассировка на другие требования
• Необходимость
• трассировка на потребности пользователя
• Осуществимость
• трассировка на другие требования и артефакты
• постановка задач для членов проектной команды
• Проверяемость
• наличие количественной метрики (критерия достижения определенного результата)
• наличие критериев проверки сформулированного требования
25. Управление требованиями:
метрики процесса
Метрика Измеряемый параметр
Наличие артефактов процесса УТ
• Артефакты проектного управления • Перечень артефактов проектного управления, участвующих в УТ
• Источники технических требований • Перечень источников технических требований в проектах (маппинг на
трассировки)
• Технические требования к системе • Виды технических требований
• Форматы представления технических требований
• Источники изменения требований • Перечень источников изменения требований (маппинг на трассировки)
Актуальность артефактов УТ
• Поддержка версионности артефактов • Находится ли артефакт под версионным контролем (да/нет)
• Своевременность актуализации • Своевременность обновления артефактов и соответствие представленных
артефактов данных реальному состоянию
• Использование артефактов УТ в • Оценка использования артефактов УТ в реальной деятельности (экспертная
реальной деятельности оценка)
26. Управление требованиями:
метрики процесса
Метрика Измеряемый параметр
Участие системного аналитика в подготовке и согласовании артефактов УТ
• Артефакты УТ, в создании которых • Перечень артефактов, в создании которых участвует системный аналитик
системный аналитик принимает участие
• Роли, с которыми взаимодействует • Перечень ролей, с которыми взаимодействует системный аналитик
системный аналитик
• Артефакты проекта, в создании и • Перечень артефактов проекта, в создании и актуализации которых принимает
актуализации которых принимает участие системный аналитик
участие системный аналитик
Связь артефактов УТ с другими артефактами проекта
• Поддержка трассировок между • Наличие и поддержка трассировок (да/нет)
техническими требованиями и другими • Своевременность актуализации трассировок
артефактами проекта
• Поддержка трассировок между • Наличие и поддержка трассировок (да/нет)
техническими требованиями в • Своевременность актуализации трассировок
различных проектах