Место Аналитика в разработке
Почему так получается?
Требования
Работа с требованиями
Кто такой Аналитик?
Системный Ан. vs Бизнес Ан.
Основные функции Бизнес Ан.
Литература и Профстандарты
http://cmcons.com
http://uml2.ru
Методы оценки качества требований и работы аналитика
семинар 15 июня 2010 года - «ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ IBM RATIONAL ДЛЯ УЛУЧШЕНИЯ ПРОЦЕССОВ РАЗРАБОТКИ И СОПРОВОЖДЕНИЯ ПО»
Управление требованиями. Сбор требований. Характеристики хороших требований. Анализ требований. Управление изменениями требованиями. Курс для бизнес-аналитиков. Основы бизнес-анализа для начинающих
В докладе предложены последовательность и практические действия по созданию и описанию процесса управления требованиями для работы конкретной команды, а так же описаны действия по планированию и адаптации процесса управления требованиями для использования в условиях конкретного проекта.
http://cmcons.com
http://uml2.ru
Методы оценки качества требований и работы аналитика
семинар 15 июня 2010 года - «ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ IBM RATIONAL ДЛЯ УЛУЧШЕНИЯ ПРОЦЕССОВ РАЗРАБОТКИ И СОПРОВОЖДЕНИЯ ПО»
Управление требованиями. Сбор требований. Характеристики хороших требований. Анализ требований. Управление изменениями требованиями. Курс для бизнес-аналитиков. Основы бизнес-анализа для начинающих
В докладе предложены последовательность и практические действия по созданию и описанию процесса управления требованиями для работы конкретной команды, а так же описаны действия по планированию и адаптации процесса управления требованиями для использования в условиях конкретного проекта.
Управление требованиями - это не только требования. Для CEE-SECR-2015. Анна А...Anna Abramova
Управление требованиями - это вспомогательный процесс управления проектом. Сами требования - инструмент управления. Когда мы начинаем путать требования с другими видами информации в проекте - запросами на изменения, описание реализации, потребностями бизнеса, - мы теряем управляемость проекта. Разница между разными видами информации - это разница во внутренней структуре, её потребителях, частотой и критичностью изменения.
Взаимодействие бизнес-аналитика с командой проекта и Заказчиком, Людмила Гули...DataArt
Правильное взаимодействие бизнес-аналитика с командой проекта и заказчиком — самая важная составляющая его успешности как специалиста. Во многом от бизнес-аналитика зависит, насколько комфортно будет команде работать над проектом, и будет ли доволен заказчик в итоге.
Оценка эффективности от внедрения и использования методологии и инструменталь...Alexander Novichkov
http://cmcons.com
http://anovichkov.msk.ru
Оценка эффективности от внедрения и использования методологии и инструментальных средств IBM Rational.
Практика внедрения и взаимодействия с заказчиком.
15 июня 2010 года - «ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ IBM RATIONAL ДЛЯ УЛУЧШЕНИЯ ПРОЦЕССОВ РАЗРАБОТКИ И СОПРОВОЖДЕНИЯ ПО»
Доклад на конференции AnalystDays 2013 ( Санкт-Петербург )
Авторы доклада: Дмитрий Безуглый, Ирина Сурова
У каждого руководителя вместе с успехом неизбежно наступает момент, когда компания/команда растет, задач непочатый край, а специалисты по анализу, как и сам руководитель, "не резиновые". Остро встает вопрос где взять, как выбрать и как включить аналитика в команду.
Типичные проблемы с которыми сталкивается руководитель в этом процессе:
Проверенный специалист, отлично зарекомендовавший себя в нескольких проектах, "ни с того ни с сего" проваливает проект.
Отличный кандидат, взятый на вырост, месяц за месяцем проедает ваше время и силы и когда остается еще чуть-чуть упирается в невидимую стену и прекращает расти сколько его не "окучивай", или еще хуже, сразу после завершения обучения уходит в другой проект или компанию.
Опытный профессионал "с репутацией", пришедший в команду, так и не находит себе места, проходят месяцы, а результата нет. И приходится расставаться, потеряв и время и деньги. Хорошо если обойдется без обид и взаимных обвинений.
Такова жизнь или все-таки можно что-то сделать?
Разумеется можно и что для этого нужно делать мы расскажем в своем докладе.
В рамках доклада мы хотим раскрыть тему компетентности и эффективности аналитика.
Основные вопросы на которые вы получите ответы:
Требования к личностным характеристикам аналитика, простые инструменты их идентификации и взаимосвязи с эффективным применением в проекте
Структура и методы оценки знаний и навыков аналитика
Методология применения модели компетенций к отбору и развитию компетенции специалистов и отдела бизнес и системного анализа в целом
Для кого: Руководители групп аналитиков, Специалисты по методологии, Аналитики и желающие ими стать.
Аналитика требований в разрезе управления проектамиГузель Рахимова
В презентации показано о том, как влияет правильно проведенный анализ на успешность проекта, как проводить анализ и как это встраивается в процесс управления проектами.
Базовый инструментарий аналитика. Методы и техники используемые в инженерии т...Yury Buluy
Доклад, сделанный на конференции ReqLabs 2009, г. Москва. В докладе рассматривается подход к классификации методов и техник используемых в инженерии требований и описание ряда техник.
Большие компании и корпорации имеют сложную Орг структуру, множество Бизнес-процессов (БП), Систем, Данных. Все это очень тесно переплетно и сильно влияет друг на друга. Изменили структуру отдела или заменили людей, забыли про БП - получили проблему. Изменили Систему, забыли про другую Систему - получили проблему. Поменяли БП, забыли про людей и Системы - получили проблему. И т.д....
Чтобы все это увязать и управлять придумано много фреймворков - Zachman, TOGAF, FEA и т.д. И везде требования ставятся во главу угла. Но нужны ли все практики и такие сложные фреймвоки? В каких российских компаниях они внедрены? Мне кажется, что можно взять из этих фреймворков все самое лучше и необходимо и построить свой подход по управлению корпоративной архитектурой.
Аналитики не нужны требования (поставь запятую, где нужно)Alexander Baikin
Я часто слышу: «А зачем нам Аналитики? Хорошие разработчики — вот это сила!» или «Зачем нам требования? Мы и так по Agile шарашим!».
Тогда почему многие жалуются:
«Мы одно и тоже по нескольку раз переделываем!»,
«Заказчик все время орет, что мы делаем не то, что ему нужно!»,
«Мы как будто разговариваем с Заказчиком на разных языках!»,
«Да блин, этот Заказчик сам не знает, что хочет!»,
«У нас постоянно расширяется скоуп проекта!»,
«Мы развиваем большой проект, но уже никто не знает, как он работает! В одном месте правим, в другом ломается!»,
«Но мы же договаривались о другом!!!»
и т. д.
Чтобы решить эти и другие проблемы на проекте как раз нужны Аналитики, которые пишут правильные требования.
Я вас не убедил, что вам нужны правильные Аналитики и хорошие требования?! Тогда послушайте вебинар:
Задача Джоэля Спольски
Зачем нужны аналитики?
Кто такой хороший аналитик?
Как бороться с извечными проблемами?
Как быть с Agile?
Описание бизнес-правил и дополнительных требований в вариантах использования (use cases)
Все прекрасно знают, что варианты использования (ВИ) отлично описывают функциональные требования, но что делать с не функциональными требованиями? Кто-то пишет их отдельно, кто-то включает в текст спецификации ВИ, кто-то про них вообще забывает. В докладе будет рассказано про основные подходы описания бизнес-правил в ВИ:
* Отделенные бизнес-правила
* Размазанные бизнес-правила
* Привязанные бизнес-правила
* Группированные бизнес-правила
* Решения вместо бизнес-правил
* Как делаю я?
Requirements Engineering: People Processes ToolsAlexander Baikin
Треугольник работы с требованиями: люди, процессы, инструменты
Многие начинающие аналитики и менеджеры делают огромную ошибку, возлагая большие надежды на инструменты управления требованиями и проектом. На самом деле нужно сначачала найти (сделать) хороших людей, потом наладить процессы, а далее уже искать способы автоматизации рутинных операций (инструменты).
В докладе:
почему аналитики любят инструменты,
рекомендации по тому, что должен знать и уметь хороший аналитик,
как наладить процесс разработки и управления требованиями
какие необходимы инструменты управления требованиями и для каких проектов
Есть мнение, что совещание - это лучшее место отдохнуть от работы, показать себя, порисовать у доски, перекусить и произвести впечатление на коллег. На самом деле, совещание - это тяжелая работа всех его участников. И чтобы эта работа привела к успешному результату, необходимо знать и применять несложные приемы проведения совещаний.
В докладе будет раскрыта психология проведения совещаний, техники, позволяющие собрать максимальное число мнений и приемы для принятия решения, которое бы удовлетворяло всех его участников.
В презентации:
• Что такое Концепция требований, для чего она нужна и что туда должно войти?
• Какие техники сбора и анализа требований можно использовать на старте проекта?
• Как можно формировать ТЗ к такому проекту и что туда должно войти?
• Какие моменты нужны учесть и какие инструменты можно использовать при управлении требований?
* Показаны и рассказаны реальные примеры докладчика.
Из данной презентации Вы узнаете:
Кто такой Аналитик?
Чем он занимается?
Что он должен знать и уметь?
Почему требования так важны?
Что Вас ждет дальше?
Презентация предназначена для знакомства с ролью Аналитика (или ИТ специалиста, работающего с требованиями) и презентации полного курса «Разработка и управление требований к ПО".
Запись вебинара: http://vimeo.com/61915197
* Классификация нефункциональных требований
* Шаблоны нефункциональных требований
* Численные значения нефункциональных требований
* Связи между нефункциональными и функциональными требованиями
* Влияние различных категорий нефункциональных требований друг на друга
* Атрибуты качества продукта и нефункциональные требования
* Роли в проекте, с которыми взаимодействует аналитик при выявлении и уточнении нефункциональных требований
Requirement Managament System based on Wiki (Confluence+Jira)Alexander Baikin
Что такое Система Управление Требованиями (СУТ)?
Какие есть еще СУТ кроме Telelogic Doors, Rational RequisitePro и Borland Together?
Как Wiki + Issue Tracker + SVN использовать для СУТ?
Варианты Использования (use cases) - это наиболее популярный метод описания пользовательских требований в последние нескольких лет. Но только единицы владеют этим <<искусством>>. Да-да, не побоюсь этого слова, т.к. при правильном применении варианты использования дают неоспоримые преимущества: интуитивно понятны заказчикам и разработчикам; помогают выявить функциональные требования; диаграмма
помогает представить требования в целом; Аналитик фокусируется на потребностях Пользователя, а не на Системе и т.д.
На мастер классе будут даны основные понятия вариантов использования, их шаблоны и конечно будет разобран пример моделирования и описания вариантов использования для одной из популярных веб систем.
Для проведения полноценного тренинга обращайтесь ко мне.
Типичные проблемы Выявления Требований и их РешениеAlexander Baikin
На протяжении многих лет написано огромное количество книг и статей по методам Выявления Требований и их применению, но все хорошо в теории. На практике же Аналитики, раз за разом, натыкаются на одни и те же грабли: не выявлены все требования; заказчик не знает, что хочет; «да, но …» синдром и т.д. В данном докладе описаны основные проблемы, с которыми сталкиваются Аналитики на этапе Выявления Требований и предложены пути их решения.
20. Типы Требований Функциональные Нефункциональные Пользовательские требования Бизнес- правила Атрибуты качества Функциональные требования Системные требования Внешний интерфейс Ограничения Бизнес- требования Спецификация требований к ПО Спецификация ПТ Границы проекта
38. Шаблон Видения 1. Бизнес-требования 1.1 Описание объекта автоматизации 1.2 Проблемы и Возможности 1.3 Цели и критерии их достижения 1.4 Потребности ЗЛ или рынка 1.5 Бизнес-риски 2. Видение решения 2.1 Описание решения 2.2 Основные характеристики 2.3 Предположения и Зависимости 3. Границы и Ограничения 3.1 Границы начальной версии 3.2 Границы будущих версий 3.3 Ограничения и Исключения 4. Бизнес-контекст 4.1 Профиль ЗЛ 4.2 Приоритеты проекта 4.3 Окружение
39. Шаблон Спецификации ПО 1. Введение 1.1 Назначение 1.2 Соглашения о документе 1.3 Целевая аудитория 1.4 Границы проекта 1.5 Ссылки 2. Общее описание 2.1 Описание предметной области 2.2 Характеристики продукта 2.3 Группы пользователей 2.4 Окружение 2.5 Ограничения Архитектуры и Разработки 2.6 Пользовательская документация 2.7 Предположения и зависимость 3. Функциональные требования 3.x Характеристика продукта X 3.x.1 Описание и приоритет 3.x.2 Входные и выходные данные 3.x.3 Детальные функциональные требования 4. Требования к интерфейсу 4.1 Пользовательский интерфейс 4.2 Аппаратные интерфейсы 4.3 Интерфейсы ПО 4.4 Интерфейсы взаимодействия 5. Нефункциональные требования 5.1 Требования к производительности 5.2 Требования к надежности 5.3 Требования к безопасности 5.4 Атрибуты качества ПО 6. Другие Требования Appendix A: Глоссарий Appendix B: Аналитические модели Appendix C: Список задач
45. Литература К. Вигерс, Разработка требований к программному обеспечению А. Коберн, Современные методы описания функциональных требований к системам У. Леффингуэлл, Принципы работы с требованиями к программному обеспечению. Унифицированный подход