Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
®




               IBM Software Group


Превращая создание продукта в конкурентное
преимущество:


Инжиниринг требований...
IBM Software Group | Rational software
          IBM Software Group | Rational software


Необходим системный подход к раб...
IBM Software Group | Rational software
         IBM Software Group | Rational software


Что такое “требование” ...

  Тре...
IBM Software Group | Rational software
         IBM Software Group | Rational software


Что такое «требования» ...

Требо...
IBM Software Group | Rational software
          IBM Software Group | Rational software


Успешный проект должен получить ...
IBM Software Group | Rational software
         IBM Software Group | Rational software


Признаки хорошего требования
Кажд...
IBM Software Group | Rational software
          IBM Software Group | Rational software


Как создавать хорошие требования...
IBM Software Group | Rational software
       IBM Software Group | Rational software


Анатомия хорошего требования пользо...
IBM Software Group | Rational software
         IBM Software Group | Rational software


Почему требования должны быть стр...
IBM Software Group | Rational software
           IBM Software Group | Rational software


«Хочу» против «могу»...

  Возм...
IBM Software Group | Rational software
         IBM Software Group | Rational software


Пользователь #1.
Оглавление докум...
IBM Software Group | Rational software
          IBM Software Group | Rational software


Пользователь #2.
Типы документов...
IBM Software Group | Rational software
                IBM Software Group | Rational software


Эффективное формирование т...
IBM Software Group | Rational software
         IBM Software Group | Rational software


Источники требований.
Сложные сис...
IBM Software Group | Rational software
          IBM Software Group | Rational software


Совет: как создавать требования
...
IBM Software Group | Rational software
          IBM Software Group | Rational software


Мы часто слышим – а зачем нужно ...
IBM Software Group | Rational software
        IBM Software Group | Rational software


Преимущества, которые дает управле...
IBM Software Group | Rational software
               IBM Software Group | Rational software


 Анализ влияния (Impact Ana...
IBM Software Group | Rational software
               IBM Software Group | Rational software

 Трассировка (Traceability A...
IBM Software Group | Rational software
               IBM Software Group | Rational software


Как это выглядит в AIRBUS
С...
IBM Software Group | Rational software
       IBM Software Group | Rational software


Как это выглядит в BAE SYSTEMS




...
IBM Software Group | Rational software
            IBM Software Group | Rational software


Использование инжиниринга треб...
IBM Software Group | Rational software
       IBM Software Group | Rational software


Управление требованиями приносит ре...
IBM Software Group | Rational software
        IBM Software Group | Rational software


Требования и качество


    Качест...
IBM Software Group | Rational software
                             IBM Software Group | Rational software




          А...
Prochain SlideShare
Chargement dans…5
×

Инжиниринг требований

2 307 vues

Publié le

Доклад Волохова Анатолия на SQA Days 7

Publié dans : Formation, Technologie, Business
  • Soyez le premier à commenter

Инжиниринг требований

  1. 1. ® IBM Software Group Превращая создание продукта в конкурентное преимущество: Инжиниринг требований Анатолий Волохов, Software Group, Rational-Telelogic Solutions, anatoly.volokhov@ru.ibm.com © 2008 IBM Corporation
  2. 2. IBM Software Group | Rational software IBM Software Group | Rational software Необходим системный подход к работе с требованиями, чтобы производить успешный и прибыльный продукт Инжиниринг требований = Формирование требований + Управление требованиями Are we solving the right problem ? Инициализация Собирать, извлекать, фиксировать, преобразовывать, конкретизировать, обсуждать, Осмысление анализировать требования, используя различные подходы, метода и нотации Формирование Анализ требований Возможность специалистам по бизнесу работать над требованиями вместе с технологическим экспертам Анализ Are we solving the problem right ? Управление требованиями Систематизировать и структурировать Приоритезация требования, строить взаимоотношения между ними, используя атрибутику, линкование и трассировку. Контролировать и анализировать изменения и Реализация управлять ими 22
  3. 3. IBM Software Group | Rational software IBM Software Group | Rational software Что такое “требование” ... Требование - есть единичная задокументированная необходимость Требование - описание того, каким должен быть определенный продукт (или сервис) Функциональные требования описывают Потреб- ности рынка точное поведение (функционирование) системы, т.е. - «что система должна Требования высокого уровня делать» Функциональные требования Нефункциональные требования описывают насколько хорошо это поведение должно Нефункциональные требования исполняться (но избегайте слова – как) Системные Структурные требования требования Требования ведут нас через весь Требования к интерфейсам процесс разработки продукта Спецификация изделия Спецификация изделия 23
  4. 4. IBM Software Group | Rational software IBM Software Group | Rational software Что такое «требования» ... Требования – это : Список фактических задач группы, работающей над проектом (TO-DO list) Список того, ЧТО хочет получить заказчик Описание того, ЧТО должна делать система, чтобы удовлетворить пользователей и бизнес-потребности Перечень того, КАКИЕ компоненты должны быть реализованы: hardware & software процедуры и регламенты Описание того, ЧТО каждый компонент ДОЛЖЕН ДЕЛАТЬ и КАК компоненты будут ВЗАИМОДЕЙСТВОВАТЬ 24
  5. 5. IBM Software Group | Rational software IBM Software Group | Rational software Успешный проект должен получить свои требования до начала работ по его реализации Решения, принимаемые на ходу, Как «распилить» систему на подсистемы не могут быть оптимальными и компоненты? Что хочет получить Как бы не забыть про заказчик ? интерфейсы сопряжения... Кто будет Кто и что будет пользователем разрабатывать ? системы ? Следствие: За последующие исправления все равно придется расплачиваться 25
  6. 6. IBM Software Group | Rational software IBM Software Group | Rational software Признаки хорошего требования Каждое индивидуальное требование должно быть: Корректное с технической и юридической точек зрения Полное выражать утверждение или законченную идею Четкое, однозначное недвусмысленное и не сбивающее с толку Совместимое согласующееся и не конфликтующее с другими требованиями Проверяемое чтобы подтвердить, что результат соответствует требованию Трассируемое уникально идентифицированное и отслеживаемое Выполнимое чтобы реализоваться в рамках запланированного бюджета и сроков Модульное, блочное изменяться без чрезмерных последствий для всего проекта Инженерно-независимое не должно содержать описания конкретного решения Позитивное сформулировано в утвердительной форме 26
  7. 7. IBM Software Group | Rational software IBM Software Group | Rational software Как создавать хорошие требования... Каждое требование должно выглядеть как законченное предложение, содержащее подлежащее и сказуемое, и при этом отражать: предметную принадлежность (требование относится к пользователю или к системе) содержать утверждение (логическое условие, действие, предполагаемый результат) Необходимо использовать : либо глагол должен, когда требование является обязательным, либо глагол может, когда требование является дополнительным или факультативным возможны и вариации этих глаголов, но при соблюдении смысловых мер предосторожности Законченное требование должно точно формулировать конечную цель или определять желаемый результат Требование должно содержать критерии и оценки его успешной реализации или другие аналогичные индикаторы качества, которые можно было бы измерить. невозможно контролировать то, что нельзя измерить 27
  8. 8. IBM Software Group | Rational software IBM Software Group | Rational software Анатомия хорошего требования пользователя Указывается предметная Используется принадлежность определенный глагол Приложение должнопользователь долженстепень Неподготовленный обеспечить высокую иметь возможность создать отчет менее, чем за 3 минуты использования и удобство работы Декларируется позитивный Измеряемый критерий конечный результат производительности Наибольшая проблема – суметь прописать ВСЕ эти составляющие для КАЖДОГО требования, которое вы формулируете 28 r572
  9. 9. IBM Software Group | Rational software IBM Software Group | Rational software Почему требования должны быть структурированы? Требования должны быть структурированы, чтобы можно было увидеть: Контекст - общие характеристики среды, к которой относятся требования Позволяет охватить взглядом всю картину целиком Дублирование требований Одна и та же работа может выполняться дважды Возможно возникновение конфликтных ситуаций на стадии разработки Значительное удорожание стоимости поддержки продукта в последующем Пропуск требования Отсутствие требования ведут к потере функциональности Может привести к изъянам в области реализации нефункциональных требований (напр., производительность, надежность, простота использования и т.д. – которые практически уже не поддаются исправлению, если проект завершен и система создана. Помните эффект домино?? Это начинается здесь!!! 29
  10. 10. IBM Software Group | Rational software IBM Software Group | Rational software «Хочу» против «могу»... Возможности: • Что заказчик хочет от системы – “Мне нужно устройство, которое обеспечивало бы полив моих посевов” • Наличие ассоциированных характеристик – “ежедневно... и все поля...” Ограничения: • Все, что связано с запретами, лимитами и сдерживающими факторами • Налагаемые извне – обычно обязательные (стандарты, правила, законы) – “Но скважина не может выдавать больше 1000 литров воды в час” • Налагаемые заказчиком – часто не очень обязательные – “Поэтому хотелось бы использовать мощности имеющихся оросительных каналов” 30
  11. 11. IBM Software Group | Rational software IBM Software Group | Rational software Пользователь #1. Оглавление документа с требованиями 1.0. Общее описание 3.0. Специфические требования 1.1. Характеристики продукта 3.1. Функциональные требования 1.2. Контекстные или системные 3.2. Нефункциональные требования диаграммы и схемы (в порядке важности) 1.3. Условия эксплуатации 4.0. Верификационные замеры и проверки 1.4. Характеристики пользователя 5.0. Заметки 2.0. Допущения и зависимости (информация, не имеющая отношения к требованиям) 31
  12. 12. IBM Software Group | Rational software IBM Software Group | Rational software Пользователь #2. Типы документов с требованиями Business Requirements Document (BRD) BRD Market Requirements Document (MRD) User Requirements Document (URD) SRS Statement of Work (SOW) Operational Concept Document (OCD) Interface Control Document (ICD) System Requirements Specifications (SRS) TRs GRs Technical Requirements Specification (TRS) Constrains & Restrictions Document (CRD) 32
  13. 13. IBM Software Group | Rational software IBM Software Group | Rational software Эффективное формирование требований основывается на совместной работе, объединяющей различные точки зрения Фиксируйте предлагаемые решения для будущих проработок Используйте графику и связи для структуризации информации Устраните непонимание - используйте общий глоссарий Координация совместной деятельности Используйте дискуссии для общения Используйте рисунки и наброски для визуализации Стройте модели и детализируйте их 33
  14. 14. IBM Software Group | Rational software IBM Software Group | Rational software Источники требований. Сложные системы получают требования из многих источников Пользователи Бизнес Конкуренты Заказчики Эксплуатация Sales Help Desk Обучение Принимайте во внимание мнение ВСЕХ возможных пользователей. Даже ОДНО неучтенное требование может привести к большим проблемам или печальному результату 34 r572
  15. 15. IBM Software Group | Rational software IBM Software Group | Rational software Совет: как создавать требования Принимайте во внимание различные источники (внутренние, внешние, Web). Идентифицируйте типы и группы пользователей. Общайтесь с каждым. Попытайтесь заставить пользователя выражать свои мысли в терминах процессов и данных, используемых ими на каждом шаге разработки Записывайте каждое требование как полное предложение, сформулированное в утвердительное форме Не забывайте о прошлых ошибках и старайтесь обойти их хорошими и простыми альтернативными вариантами требований Постарайтесь выяснить природу возникновения требования. Не стесняйтесь на некоторые требования заказчика спросить - ПОЧЕМУ? Никогда не оставляйте попыток улучшить формулировку требования. Остановитесь только когда каждый скажет, что понял, что имеется ввиду Не жалейте времени сформулировать требование как можно более однозначно и недвусмысленно. Скорость работы многих специалистов - одна страница в час. Потратьте и вы хотя бы столько же времени, чтобы создать хороший документ с требованиями – это окупится сторицей. 35
  16. 16. IBM Software Group | Rational software IBM Software Group | Rational software Мы часто слышим – а зачем нужно управлять требованиями? Попытаемся ответить на это вопрос вашими же словами: Текущий статус проекта никогда не ясен до тех пор, пока мы не поймем, что уже опаздываем и не укладываемся в плановый график Создается впечатление, что техническое задание всегда изменяется в самое неподходящее время Изменения требуют много внимание и времени и обходятся нам очень дорого У нас в компании большие проблемы в общении между подразделениями – трудно понять кто, что хочет и почему Довольно часто случается, что нам приходится переделывать наш продукт, что обходится в немалую копеечку.. Наблюдаются большие проблемы с тестированием некорректно сформулированных требований У нас нет полной уверенности в том, что наши тесты проверяют все модули и подсистемы продукта Процесс тестирования требует слишком много времени и денег В свои требования наши заказчики зачастую закладывают и решение Мы испытываем большие трудности при попытке организовать требования в управляемую и контролируемую группу 36
  17. 17. IBM Software Group | Rational software IBM Software Group | Rational software Преимущества, которые дает управление требованиями Информированность – ясное понимание целей и задач разработки Прозрачность – руководство может видеть общую картину и статус проекта Тестируемость – известно что тестировать, чтобы сдать продукт заказчику Интеграция – все отдельные блоки и модули наконец-то работают вместе Трассируемость – прозрачность отношений между требованиями Управление изменениями – оценка последствий вносимого изменения Оптимизация – разрабатываем и поставляем только то, что заказывалось Качество – мы хорошо понимаем, как много это значит для бизнеса Удовлетворение - заказчик и бизнес получают то, что хотели Соответствие – демонстрация соответствия нормативным документам Анализ - возможность оперативного принятия решений 37
  18. 18. IBM Software Group | Rational software IBM Software Group | Rational software Анализ влияния (Impact Analysis) Требования Приемочные с на е заказчика тесты пронени Тесты Зазме и Ре Нормы и ш ае правила т Системные требования Системное тестирование Подчиняется Тесты Ре ш Архитектурный ае дизайн т Интеграционное Промышленные Соответствует и модульное стандарты Тесты тестирование 38
  19. 19. IBM Software Group | Rational software IBM Software Group | Rational software Трассировка (Traceability Analysis) Требования Приемочные заказчика тесты Тесты Ре Нормы и ш ае правила т Системные требования Системное тестирование Подчиняется Тесты Ре ш Архитектурный ае дизайн т Интеграционное е Соответствует и модульное 24 . н Промышленные 3 .. стандарты тестирование ен т Тесты с Те ойд пр 39
  20. 20. IBM Software Group | Rational software IBM Software Group | Rational software Как это выглядит в AIRBUS С 2003 года System Engineering называется в Airbus - Requirements Based Engineering Подготовка Специфи- производства Методические кации и Безопа- Обучение инструкции характе- сность ристики Аттестация Тех. поддержка Потребности и Контроль и Приемочные требования проверка испытания Сертификация Дизайн дизайна Эксплуатация Производство Жизненный цикл изделия Процессы и методы 40 Организация Время Стоимость
  21. 21. IBM Software Group | Rational software IBM Software Group | Rational software Как это выглядит в BAE SYSTEMS 41
  22. 22. IBM Software Group | Rational software IBM Software Group | Rational software Использование инжиниринга требований имеет свои неоспоримые преимущества Почти 100% проектов стали выполняться точно в срок Ушли проблемы с перерасходом бюджета Значительно уменьшилось количество исправлений (right first time) Заметно увеличилась процессная, методологическая, инструментальная и персональная эффективность в инжиниринге Снизился риск появления дефектов Инжиниринг требований стал рассматриваться как конкурентное преимущество The US Air Force Academy Требования Анализ Дизайн Разработка Ввод в эксплуатацию Обычно 3% 27% 55% 15% Инжиниринг требований Лучшие практики 20% 13% 22% 5% 30-50% Экономия времени 42
  23. 23. IBM Software Group | Rational software IBM Software Group | Rational software Управление требованиями приносит реальную пользу Совершенствование цикла разработки современной системы управления ракетным вооружением Tomahawk при использовании Requirements Management При отсутствии Impact Analysis, большинство изменений попросту принималось Теперь проведение Impact Analysis - вопрос лишь нескольких минут 43
  24. 24. IBM Software Group | Rational software IBM Software Group | Rational software Требования и качество Качество: полное соответствие результата первоначальным требованиям • Цель управления требованиями: - поставка качественного продукта - в соответствии с графиком, - в рамках выделенного бюджета, - отвечающего исходной спецификации, с полной уверенностью, что все первичные требования учтены, проконтролированы и выполнены 44
  25. 25. IBM Software Group | Rational software IBM Software Group | Rational software Анатолий Волохов anatoly.volokhov@ru.ibm.com © Copyright IBM Corporation 2008. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others. 45

×