Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
®
IBM Software Group
© 2010 IBM Corporation
Превращая создание продукта в конкурентное
преимущество:
Системный инжиниринг
Анатолий Волохов,Software Group, Rational-Telelogic Solutions,
®
IBM Software Group
© 2010 IBM Corporation
Превращая создание продукта в конкурентное
преимущество:
Инжиниринг требований
Анатолий Волохов,Software Group, Rational-Telelogic Solutions,
®
IBM Software Group
© 2010 IBM Corporation
Анатолий Волохов,Software Group, Rational-Telelogic Solutions,
Превращая создание продукта в конкурентное
преимущество:
Rational DOORS -инструментальное средствоуправления требованиями
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 4
Системный инжиниринг (System Engineering). Определения
� Системный инжиниринг - ориентированный на изделие подход, отвечающий за создание и выполнение процессов, охватывающихразличные инженерные дисциплины и обеспечивающих удовлетворениенужд заказчиков и непосредственных пользователей изделия
� Системный инжиниринг – есть междисциплинарный подход, используемый для контроля за разработками сложных, инновационных
изделий и систем *
� Система – это набор компонентов (которые и сами могут
быть системами), соединенных и связанных определеннымобразом так, чтобы обеспечить функционирование, котороесами по себе компоненты обеспечить не могут.
� Корабль, самолет, ракета - есть система.. и их основныекомпоненты (корпус, крылья, система управления, силовые
установки, вооружение, программное обеспечение ...), такжеявляются системами (или оборудованием)
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 5
Самолет – это сложная авиационная система
Source: The Seattle Times
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 6
Значительно возрастает доля программной составляющейи это ведет к существенным проблемам
Типсамолета Год Функции, контро-
лируемые ПО
F-4 1960 8%
A-7 1964 10%
F-111 1970 20%
F-15 1975 35%
F-16 1982 45%
B-2 1990 65%
F-22 2000 80%
Рост софтверных составляющих Влияние на бизнес
1970 1990 2008
Об
ща
яс
то
им
ос
ть
Распределениесоставляющихстоимости
100%
60%
20%
����
«Железо»
Разработка
Программноеобеспечение
Средняя продолжительность(месяцы)
Вероятность провала(проценты)
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 7
Системный Инжиниринг отвечает за всю картину в целом, обеспечиваявыполнение требований в течение всего жизненного цикла изделия.
Зачем нужен Системный Инжиниринг
� Повышается вероятность успеха создания Системы� Понимание природы Системы и ее поведения в окружающей среде
� Определение характеристик Системы с точки зрения пользователя
� Уменьшаются риски принятия неправильных решений
� Выявление и оценка возможных рисков
� Поиск неопределенностей и изменяемых параметров
� Учет требований нормативных документов и ирегулирующих организаций
� Уменьшение общей стоимости жизненного цикла изделия
� Улучшение процесса принятия решений в планировании, разработке, эксплуатации
� Такой подход начинается с понимания потребностей заказчика, определенияфункциональности изделия и обязательных запланированных проверок
(аттестаций, приемочных испытаний, контроля) на самых ранних стадияхжизненного цикла создания изделия
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 8
Проверки, тесты,приемо-сдаточные
испытания, сертификация
Проверки, тесты,приемо-сдаточные
испытания, сертификация
R
R1 R2
R1-1 R1-2 R2-1 R2-2 R2-3
F1 F5
F2 F3
F4 System
УправлениетребованиямиУправление
требованиями
Функциональныйдизайн
Функциональныйдизайн
Архитектурныйдизайн
Архитектурныйдизайн
Физическийдизайн
Физическийдизайн
Проверка требований
Проверка функционала
Проверка архитектуры
Проверка
дизайна
� Разработка продукта в полном соответствии с требованиями
� Учет изменений на всех уровнях разработки
� Тесты, проверки, сертификация проверят требования
� Обеспечивается сквозной мониторинг производства продукта
� Конечный продукт соответствует требованиям на все 100%
� Разработка продукта в полном соответствии с требованиями
� Учет изменений на всех уровнях разработки
� Тесты, проверки, сертификация проверят требования
� Обеспечивается сквозной мониторинг производства продукта
� Конечный продукт соответствует требованиям на все 100%
Для чего это все нужно ?
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 9
Проблемы с проектами
� Только 28% проектов отвечаютзапланированным срокам и бюджету
Прямые убытки
� Выпуск изделия на рынок всего на 6 месяцев позже может стоитькомпании трети планового пятилетнего показателя возврата инвестиций
Исправление ошибок
� Более 45% бюджета на разработку, может «уйти» на исправление и переделки
� От 35 до 50% общего объема работ тратится на исправление ошибок в дизайне
� Исправление ошибок, обнаруженных на этапе эксплуатации, обходится в 200 раз
дороже ошибок, обнаруженных на ранних этапах
Sources:• Don Reinertsen, McKinsey, 1983• Standish Group, 2001• Leffingwell & Widrig, “Managing Software Requirements,” Addison Wesley, 1999• Effective Requirements Practices, NASA• IAG Consulting, 2008• Dynamic Market Limited, 2007
К чему ведет неиспользование системного инжиниринга
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 10
� Аэрокосмическое агентствоНа 40с полета бортовой компьютерпрототипа стратегической ракетыстоимостью $1 млрд. ошибочно выдалкоманду на самоуничтожение
Аварии все еще продолжают беспокоить производителейи PLM не является панацеей от всех бед..
� Производитель автомобилейКомпания вынуждена была отозвать75 тысяч автомобилей, которые из-заошибки в ПО вдруг начиналитормозить на большой скорости
� Производитель мед. оборудования:Из-за некачественного ПО пришлосьизымать из эксплуатации42 тысячи дефибрилляторов
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 11
Почему это происходит?Пользователи разделены разными приложениями и средствами коммуникации
Совместное решение проблем
Отслеживание статуса программы
Общение с поставщиками
Обслуживание
Производство
Дизайн
Закупки
Качество итестированиеУправление
проектамиПартнеры
Планирование
производства
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 12
� Несогласованностьпроцессов и правил
� «Know-how» – только впределах своей вертикали -снижение общейпроизводительности
� Сложность сотрудничества иобмена данными ирезультатами
� Заниженные возможностиотслеживания оперативныхрешений и меняющейсяинформации
� Низкий уровень повторногоиспользования существующихрешений и артефактов
IterativeProcess V Process V Process
MCAD EDA
Механическиекомпоненты
Программныекомпоненты
Электронныекомпоненты
SW Рук-ство
???
Аппаратчикиизменилиспецификацию, нозабыли сказать нам
Это проблемыпрограммистов
Каждый из них говорит, что на 95% закончилработу, но мы не можемзапустить систему влаборатории. Что же происходит???
Почему это происходит?Вертикальная структура организации разработки – уже большая проблема
Ну мы же предупреждалиэлектронщиков, что долженбыть один разъем, а не два
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 13
Системный инжиниринг требует взаимодействия множестваинструментов и дисциплин для обеспечения и поддержки:
Решения для системного инжиниринга
� Управление совместными бизнес-процессами:
� Управление портфелями
� Управление программами
� Управление требованиями
� Управление изменениями
� Управление конфигурациями
� Управление поставками
� Управление потоками задач
� Контроль за соблюдением стандартов
� Моделирование и тестирование системи изделий (в зависимости от их типа) :
� UML & SysML
� Rhapsody
� Simulink
� Modelica
� MCAD & ECAD
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 14
Разработка без управления требованиями –непредсказуемый результат
Если требования плохие, то все остальные вашиусилия, процессы и инструменты лишь помогут вамкак можно быстрей создать плохой продукт.
Если вы еще только начинаете задумываться обулучшении ваших процессов, то помните, что начатьстоит именно с процесса управления требованиями, потому что здесь действует простой принцип :
что посеешь, то и пожнешь.
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 15
49%
Улучшить связь и взаимодействие между дисциплинами / доменами
Повысить доступность требований
Уметь прогнозировать поведение системы до тестирования
Внедрить новый или переделать имеющийся процесс разработки, чтобы охватить множественные дисциплины / домены
(... что-то, не имеющее отношения к данной теме ...)
71%
46%
39%
43%
К чему все это приводит ...... и как найти выход из этого нерадостного положения?
Организационные возможности
Aberdeen Group, System Design: New Product Development for Mechatronics, Michelle Boucher, David Houlihan, January, 2008
Нечеткое позиционирование продукта
Ценовая политика
Качество продукта
Слабая коммерциализация / раскрутка
Поздний выход на рынок / упущенный спрос
Продукт не удовлетворяет заказчика
19%
23%
24%
26%
33%
46%
Проблемы бизнеса
The CIO’s Guide to the PERFECT Launch: Translating Innovation to Business Benefit, AMR Research, 2005
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 16
Вся наша жизнь – это работа с требованиями.... В БЫТУ
� Если жена звонит вам и просит по пути с работы домой купить – хлеб, сахар, масло, молоко и вино - то это ничто иное, как сбор и формирование требований
� Если в разговоре выясняется, что она имела ввиду:� Хлеб белый – 1 батон� Масло растительное - 1 бутылка� Сахар-песок– 2 пачки� Молоко топленое – 1 литр
то это ничто иное, как декомпозиция и детализация требований.
� Разговор заканчивается тем, что вы приходите к выводу, что вино выпокупать не стоит, потому что в гости придет друг, которому пить противопоказано ... - это ничто иное, как работа с ограничениями или учет ограничивающих факторов
� Если вы решаете, что хлеб, масло и сахар вы купите в одном магазине, а вот молоков другом - это выглядит как структуризация требований
� Если чуть позже жена вновь звонит вам и говорит, что она передумалаи просит вместо молока купить сметану, то это изменение требований
� Если уже дома вы сверяете купленное с тем списком, что диктовалажена, - это проверка реализации требований или тестирование
� И если обнаруживаете, что вместо сметаны вы все-таки купили молоко- это значит, что вы не учли изменение, ранее внесенное в одно из требований
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 17
Интеграционное
и модульное
тестирование
Архитектурный
дизайн
Приемочные
тесты
Системное
тестирование
Промышленные
стандарты
Системные
требования
Требования
заказчика
Нормы и
правила
Соответствует
Подчиняется
Тесты
Тесты
Тесты
Реш
ает
Реш
ает
Вся наша жизнь – это работа с требованиями.... НА РАБОТЕупрощенная модель проекта
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 18
Стоимость
исправлений и
корректировок
Время
Вынужденные
ошибки
Формированиетребованийи их анализ
Системный
анализ и дизайн
HW/SW design
document
Дизайнприложения
Реализация
приложения и
блочные тесты
Requirements
document
SW design
specification
Модульнаяинтеграция итестирование
Приемка
системы
Интеграция итестирование
подсистем
.exe
.doc
.exe
.doc
Но не все так просто ...Люди с разным мышлением с трудом понимают друг друга
.exe
.doc
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 19
Более 80% разработок заканчиваются плачевно только из-за неудовлетворительногоформирования требований, их анализа и управления им
IDC, November 2007
Почти 80% ошибок вносится на стадии формирования требованийNASA, 2006
Проблемы в работе с требованиями ведут к излишним доработкам и
переделкам, плохому качеству, задержкам и провалу проектов
20
200
Сто
им
ост
ьи
спра
вле
ния
(%)
AcceptanceTest
Unit TestCodingDesignAnalysis
0
Maintenance
1-2
10
5
50
Время, которое не тратилосьна требования – есть время, затрачиваемое на переделку
(издержки x200)
Стадия обнаружения ошибки
Инжиниринг требований – составная часть системногоинжиниринга
Source:• Defense System Management College, DAU, 2004
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 20
Треб
ован
ия
Система
КрахДизайн
• Около 60%-70% общего числа всех проектов заканчиваютсяплачевным результатом только из-за неудовлетворительногоформирования требований, их анализа, управления и контроля
- Meta Group, 2003
� Задержки - средний проект «опаздывает» на 220%
� Неэффективная работа - 40-50% времени специалиста тратитсяна задачи, не связанные с выполнением его непосредственныхобязанностей: поиск нужных документов, отслеживание изменений...
Очень важен правильный старт и эффективная работа
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 21
Формированиетребованийи их анализ
Системный
анализ и дизайн
Приемка
системы
Интеграция итестирование
подсистем
Модульнаяинтеграция итестирование
Дизайнприложения
Реализацияприложения и
блочные тесты
Software Engineering
Инжиниринг требований
Тест инжиниринг
Инжиниринг требований ломает барьеры
®
IBM Software Group
© 2010 IBM Corporation
Превращая создание продукта в конкурентное
преимущество:
Инжиниринг требований
Анатолий Волохов,Software Group, Rational-Telelogic Solutions,
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 23
Необходим системный подход к работе с требованиями,чтобы производить успешный и прибыльный продукт
Are we solving the right problem ?
Собирать, извлекать, фиксировать, преобразовывать, конкретизировать, обсуждать, анализировать требования, используя различныеподходы, метода и нотации
Возможность специалистам по бизнесуработать над требованиями вместе
с технологическим экспертами
Формированиетребований
Осмысление
Анализ
Are we solving the problem right ?Систематизировать и структурироватьтребования, строить взаимоотношения между ними, используя атрибутику, линкование и трассировку. Контролировать и анализировать изменения иуправлять ими
Управлениетребованиями
Приоритезация
Реализация
Анализ
Сбор требований
Инжиниринг требований = Формирование требований + Управление требованиями
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 24
Потреб-ности рынка
Требованиявысокого уровня
Функциональныетребования
Нефункциональные
требования
Системныетребования
Спецификация изделия Спецификация изделия
Структурныетребования
Требования кинтерфейсам
� Требование - есть единичнаязадокументированная необходимость
� Требование - описание того, какимдолжен быть определенный продукт(или сервис)
�Функциональные требования описываютточное поведение (функционирование) системы, т.е. «ЧТО система должна делать»
�Нефункциональные требования описываютнасколько хорошо это поведение должноисполняться (но избегайте слова – КАК)
� Требования – это навигатор, который ведет нас через весьпроцесс разработки продукта
Что такое “требование” ...
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 25
� Список фактических задач группы, работающейнад проектом (TO-DO list)
� Список того, ЧТО хочет получить заказчик
� Описание того, ЧТО должна делать система,чтобы удовлетворить пользователей ибизнес-потребности
� Перечень того, КАКИЕ компоненты должны бытьреализованы:
� программные и аппаратные
� процедуры и регламенты
� Описание того, ЧТО каждый компонент ДОЛЖЕН ДЕЛАТЬ иКАК компоненты будут ВЗАИМОДЕЙСТВОВАТЬ
Требования – это :
� Список фактических задач группы, работающейнад проектом (TO-DO list)
� Список того, ЧТО хочет получить заказчик
� Описание того, ЧТО должна делать система,чтобы удовлетворить пользователей ибизнес-потребности
� Перечень того, КАКИЕ компоненты должны бытьреализованы:
� программные и аппаратные
� процедуры и регламенты
� Описание того, ЧТО каждый компонент ДОЛЖЕН ДЕЛАТЬ иКАК компоненты будут ВЗАИМОДЕЙСТВОВАТЬ
Что такое «требования» ...
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 26
Как «распилить»систему на подсистемы
и компоненты?
Что хочетполучитьзаказчик ?
Кто и что будетразрабатывать ?
Кто будетпользователем
системы ?
За ошибки, сделанные ВЧЕРА, и исправления, вносимые СЕГОДНЯ, все равно придется расплачиваться ЗАВТРА
Успешный проект должен получить свои требованиядо начала работ по его реализации
Надо не забыть проинтерфейсы сопряжения...
Решения, принимаемые на ходу, не могут быть оптимальными
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 27
Признаки хорошего требования
� Корректное с технической и юридической точек зрения
� Полное выражать утверждение или законченную идею
� Четкое, однозначное недвусмысленное и не сбивающее с толку
� Совместимое согласующееся и не конфликтующее с другимитребованиями
� Проверяемое чтобы подтвердить, что результат соответствуеттребованию
� Трассируемое уникально идентифицированное и отслеживаемое
� Выполнимое чтобы реализоваться в рамках запланированногобюджета и сроков
� Модульное, блочное изменяться без чрезмерных последствийдля всего проекта
� Инженерно-независимое не должно содержать описания конкретного решения
� Позитивное сформулировано в утвердительной форме
Каждое индивидуальное требование должно быть:
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 28
Как создавать хорошие требования...
� Каждое требование должно выглядеть как законченное предложение, содержащееподлежащее и сказуемое, и при этом :�отражать предметную принадлежность (требование относится к пользователю или к системе)
�содержать утверждение (логическое условие, действие, предполагаемый результат)
� Формулируя требование, необходимо использовать :�либо глагол должен, когда требование является обязательным,
�либо глагол может, когда требование является дополнительным или факультативным
�возможны и вариации этих глаголов, но при соблюдении смысловых мер предосторожности
� Законченное требование должно точно формулироватьконечную цель или определять желаемый результат
� Требование должно содержать критерии и оценкиего успешной реализации или другие аналогичныеиндикаторы качества, которые можно было бы измерить:невозможно контролировать то, что нельзя измерить
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 29
r572
Наибольшая проблема – суметь прописать ВСЕэти составляющие для КАЖДОГО требования,
которое вы формулируете
Анатомия хорошего требования пользователя
Разрабатываемое приложение должно обеспечитьвысокую степень использования и удобство работы
Неподготовленный пользователь должен иметьвозможность создать отчет менее, чем за 3 минуты
Указывается предметнаяпринадлежность
Используетсяопределенный глагол
Декларируется позитивныйконечный результат
Измеряемый критерийпроизводительности
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 30
Требования должны быть структурированы... А зачем?
� Контекст - общие характеристики среды, к которой относятся требования
�Позволяет охватить взглядом всю картину целиком
Требования должны быть структурированы, чтобы можно было увидеть:
Помните эффект домино??Это начинается здесь!!!
� Дублирование требований... и избежать этого, чтобы:�Не выполнять дважды одну и ту же работу
�Избежать конфликтных ситуаций на стадии разработки
�Не способствовать удорожанию стоимости поддержки продукта в последующем
� Пропущенные требования�Отсутствие требования ведет к потере функциональности системы
�Может привести к изъянам в области реализации нефункциональных требований(напр., производительность, надежность, простота использования и т.д.) – которыепрактически уже не поддаются исправлению, если проект завершен и система создана.
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 31
Возможности:
• Что заказчик хочет получить от системы
– “Мне нужно устройство, которое обеспечивало бы полив посевов”
• Наличие ассоциированных характеристик
– “ежедневно... и все поля...”
Ограничения:
• Все, что связано с запретами, лимитами и сдерживающими факторами
• Налагаемые извне – обычно обязательные (стандарты, правила, законы)
– “Но скважина не может выдавать больше 1000 литров воды в час”
• Налагаемые заказчиком – часто не очень обязательные
– “Поэтому хотелось бы использовать мощности имеющихся
оросительных каналов”
Ограничения: «Хочу» против «могу»...
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 32
Обязательный учет ограниченийКомпания YYY. Оглавление документа с требованиями
1.0. Общее описание
1.1. Характеристики продукта
1.2. Контекстные или системныедиаграммы и схемы
1.3. Условия эксплуатации
1.4. Характеристики пользователя
2.0. Допущения и зависимости
3.0. Специфические требования
3.1. Функциональные требования
3.2. Нефункциональные требования(в порядке важности)
4.0. Верификационные замерыи проверки
5.0. Заметки(дополнительная информация, не
имеющая отношения к требованиям)
3.0. Специфические требования
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 33
Обязательный учет ограниченийКомпания ZZZ. Типы документов с требованиями
� Business Requirements Document (BRD)
� Market Requirements Document (MRD)
� User Requirements Document (URD)
� Statement of Work (SOW)
� Operational Concept Document (OCD)
� Interface Control Document (ICD)
� System Requirements Specifications (SRS)
� Technical Requirements Specification (TRS)
� Constrains & Restrictions Document (CRD)
BRD
SRS
TRs
GRs
� Constrains & Restrictions Document (CRD)
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 34
r572
Пользователи ЗаказчикиБизнес
Эксплуатация Обучение
Источники требований.Сложные системы получают требования из многих источников
Help Desk
Принимайте во внимание мнение ВСЕХ возможных пользователей. Даже ОДНО неучтенное требование может привести к большим
проблемам или печальному результату
Конкуренты
Sales
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 35
Эффективное формирование требованийосновывается на совместной работе, объединяющей различные точки зрения
Используйтеграфику и линки
для структуризацииинформации
Используйтедискуссии для
общения
Стройте модели идетализируйте их
Фиксируйте предлагаемыерешения для будущих
проработок
Устранитенепонимание -используйте
общий глоссарий
Используйте рисункии наброски длявизуализации
Координация
совместной
деятельности
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 36
Совет: как создавать требования
� Принимайте во внимание различные источники (внутренние, внешние, Web).Идентифицируйте типы и группы пользователей. Общайтесь с каждым.
� Попытайтесь заставить пользователя выражать свои мысли в терминах процессови данных, используемых ими на каждом шаге разработки
� Записывайте каждое требование как полное предложение, сформулированное вутвердительное форме
� Не забывайте о прошлых ошибках и старайтесь обойти их хорошими и простымиальтернативными вариантами требований
� Постарайтесь выяснить природу возникновения требования. Не стесняйтесь на некоторые требования заказчика спросить - ПОЧЕМУ?
� Никогда не оставляйте попыток улучшить формулировку требования. Остановитесь только когда каждый скажет, что понял, что имеется ввиду
� Не жалейте времени сформулировать требование как можно более однозначно инедвусмысленно. Скорость работы многих специалистов - одна страница в час. Потратьте и вы хотя бы столько же времени, чтобы создать хороший документ стребованиями – это окупится сторицей.
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 37
Мы часто слышим – а зачем нужно управлять требованиями?
�
� Текущий статус проекта никогда не ясен до тех пор, пока мы не поймем, что уже опаздываем и не укладываемся в плановый график
� Создается впечатление, что техническое задание всегда изменяется в самоенеподходящее время
� Изменения требуют много внимание и времени и обходятся нам очень дорого
� У нас в компании большие проблемы в общении между подразделениями –трудно понять кто, что хочет и почему
� Довольно часто случается, что нам приходится переделывать наш продукт, что обходится в немалую копеечку..
� Наблюдаются большие проблемы с тестированием некорректносформулированных требований
� У нас нет полной уверенности в том, что наши тесты проверяют все модулии подсистемы продукта
Попытаемся ответить на это вопрос вашими же словами:
� Процесс тестирования требует слишком много времени и денег
� В свои требования наши заказчики зачастую закладывают и решение
� Мы испытываем большие трудности при попытке организовать требованияв управляемую и контролируемую группу
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 38
Управление требованиями дает огромные преимущества
� Информированность – ясное понимание целей и задач разработки
� Прозрачность – руководство может видеть общую картину и статус проекта
� Тестируемость – известно что тестировать, чтобы сдать продукт заказчику
� Интеграция – все отдельные блоки и модули наконец-то работают вместе
� Трассируемость – прозрачность отношений между требованиями
� Управление изменениями – оценка последствий вносимого изменения
� Оптимизация – разрабатываем и поставляем только то, что заказывалось
� Качество – мы хорошо понимаем, как много это значит для бизнеса
� Удовлетворение - заказчик и бизнес получают то, что хотели
� Соответствие – демонстрация соответствия нормативным документам
� Анализ - возможность оперативного принятия решений
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 39
Интеграционное
и модульное
тестирование
Архитектурный
дизайн
Приемочные
тесты
Системное
тестирование
Промышленные
стандарты
Системные
требования
Требования
заказчика
Нормы и
правила
Соответствует
Подчиняется
Тесты
Тесты
Тесты
Реш
ает
Запрос на
изменение
Реш
ает
Анализ влияния (Impact Analysis)
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 40
Интеграционное
и модульное
тестирование
Архитектурный
дизайн
Приемочные
тесты
Системное
тестирование
Промышленные
стандарты
Системные
требования
Требования
заказчика
Нормы и
правила
Соответствует
Подчиняется
Тесты
Тесты
Тесты
Реш
ает
Трассировка (Traceability Analysis)
Тест324 не
пройден ...
Реш
ает
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 41
Как это выглядит в AIRBUS
С 2003 года System Engineering называется в Airbus - Requirements Based Engineering
Процессы и методыВремяОрганизация Стоимость
Обучение
Подготовкапроизводства Методические
инструкции
Аттестация
Безопа-сность
Специфи-кации ихаракте-ристики
Тех. поддержка
Потребности итребования Дизайн
Производство
СертификацияПриемочныеиспытания
Эксплуатация
Контроль ипроверкадизайна
Жизненный цикл изделия
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 42
Как это выглядит в BAE SYSTEMS
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 43
Использование инжиниринга требований имеет своинеоспоримые преимущества
� Почти 100% проектов стали выполняться точно в срок
� Ушли проблемы с перерасходом бюджета
� Значительно уменьшилось количество исправлений (right first time)
� Заметно увеличилась процессная, методологическая, инструментальная и персональная эффективность в инжиниринге
� Снизился риск появления дефектов
� Инжиниринг требований стал рассматриваться как конкурентноепреимущество
Обычно
Лучшие практики
3%
Требования Анализ \ Дизайн Разработка Ввод в эксплуатацию
27% 55% 15%
20% 13% 22% 5%30-50%
Экономия времени
The US Air Force Academy
Инжиниринг требований
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 44
� Совершенствование цикла разработки современнойсистемы управления ракетным вооружением Tomahawkпри использовании Requirements Management
При отсутствииImpact Analysis,
большинство измененийпопросту принималось
Теперь проведениеImpact Analysis - вопрослишь нескольких минут
Управление требованиями приносит реальную пользу
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 45
� Качество:полное соответствие результата
первоначальным требованиям
• Цель управления требованиями:
- поставка качественного продукта- в соответствии с графиком,
- в рамках выделенного бюджета, - отвечающего исходной спецификации,
с полной уверенностью, что все
первичные требования учтены,
проконтролированы и выполнены
Требования и качество
�
®
IBM Software Group
© 2010 IBM Corporation
Превращая создание продукта в конкурентное
преимущество:
Rational DOORS -инструментальное средствоуправления требованиями
Анатолий Волохов,Software Group, Rational-Telelogic Solutions,
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 47
DOORS: Вначале было слово...
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 48
Требования
заказчика
ABC
Требования рынка
DEF
Cопровождение
GHI
Функциональные
требования
CDAHIG
BEF
Системные
требования
D1D2A1H1H2G1C1I1I2
B1E1F1F2
Архитектурный
дизайн
Software
Hardware
Manuals
D1A1H2C1B1
D2G1I1E1
H1I2F1
И длинный список заказчиков, подрядчиков, поставщиков ...
С тех пор все усложнилось...
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 49
Результат нескоординированной работы
… что хотел
отдел маркетинга
… как это поняли
аналитики
… как это было
сконструировано
… так это было
поставлено
…так это было
собрано
… это реально хотел
иметь заказчик !
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 50
Любые
разрозненные
данные
импортируются
Структури-
руются и
линкуются
чтобы
синтезировать
матрицу для
управления
информацией
DOORS – это все в одном... и сразу...
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 51
Архитектура DOORS
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 52
DOORS: база данных
Привычное окружение - легко структурировать проект
Удаленная папка
Документы DOORS
Папки
Проекты
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 53
DOORS: взгляд на документ
Ничего нового – можно сразу начинать
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 54
DOORS: поддержка русского языка
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 55
Импорт из Microsoft Word
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 56
Окно DOORS
Колонкиатрибутов
Вся информация в одном окне
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 57
DOORS: все в одном
Любые данные, в любом формате
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 58
Индикатор
изменений
Идеально для быcтрого отслеживания изменений
Указатель
связей
DOORS – изменения и связи
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 59
как внутри одного документа...
... так и между разными документами
Создание связей – drag-and-drop
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 60
От А до Я - полная картина
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 61
Организация совместной работы
� Преодолеть разногласиямежду многочисленными� подрядчиками
� подразделениями
� сотрудниками
� Привлечь всех к теснойи организованнойсовместной работе
� Устранить недоразумения, связанные снедостоверностьюинформации
?
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 62
Трассировка дает возможности анализа
1. 820.30(b) Design and Development Planning
Each manufacturer shall establish and maintain plans that describe or reference the design and development
activities and define responsibility for implementation.
The plans shall identify and describe the interfaces with different groups or activities that provide, or result
in, input to the design and development process.
The plans shall be reviewed as design and development evolves.The plans shall be updated as design and development evolves.
The plans shall be approved as design and development evolves.
2. 820.30(c) Design Input
2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to adevice are appropriate and address the intended use of the device, including the needs of the user
and patient.
2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to a
device are appropriate and address the intended use of the device, including the needs of the userand patient.
2.3. The procedures shall include a mechanism for addressing incomplete requirements.
2.4. The procedures shall include a mechanism for addressing ambiguous requirements.2.5. The procedures shall include a mechanism for addressing conflicting requirements.
2.6. The design input requirements shall be documented by a designated individual(s).
2.7. The design input requirements shall be reviewed by a designated individual(s).
2.8. The design input requirements shall be approved by a designated individual(s).2.9. The approval, including the date and signature of the individual(s) approving the requirements,
shall be documented.
2.10. Questions.2.10.1. Summarize the manufacturer's written procedure(s) for identification and control of
design input.2.10.2. From what sources are design inputs sought?
2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and
list additional aspects.)2.10.3.1. intended use
2.10.3.2. user/patient/clinical
2.10.3.3. performance characteristics
2.10.3.4. safety2.10.3.5. limits and tolerances
2.10.3.6. risk analysis
2.10.3.7. toxicity and biocompatibility
2.10.3.8. electromagnetic compatibility (EMC)
2.10.3.9. compatibility with accessories/auxiliary devices2.10.3.10. compatibility with the environment of intended use
2.10.3.11. human factors
2.10.3.12. physical/chemical characteristics
2.10.3.13. labeling/packaging2.10.3.14. reliability
2.10.3.15. statutory and regulatory requirements
2.10.3.16. voluntary standards2.10.3.17. manufacturing processes
2.10.3.18. sterility
2.10.3.19. MDRs/complaints/failures and other historical data
2.10.3.20. design history files (DHFs)
2.10.4. For the specific design covered, how were the design input requirements identified?2.10.5. For the specific design covered, how were the design input requirements reviewed for
adequacy?
Comply with FDA Design Control Guidance GMP Regulation
1. Capture design and related information
1.1. Input electronically formatted data
1.2. Reference external information sources
1.3. Reference external documentation
2. Store design and related information
2.1. Identify and tag design information as unique “design elements”
2.2. Organize design elements2.2.1. Organize by Design Control Guidance Element2.2.2. Organize by inter-relationships
2.3. Ensure all design elements are available
2.3.1. Store design elements by Design Control Guidance Element
2.3.2. Store design elements and their historical values
3. Manage all user needs3.1. Identify the source of the user need3.2. Identify all user types (groups)3.3. Identify the customer (s)3.4. Profile the expected patients3.5. State the intended use of the product (family)3.6. Capture the acceptance criteria for each user need
4. Manage design input requirements
4.1. Identify the source of the requirement
4.2. Identify the associated user need4.3. Capture requirement description and attributes
4.4. Capture acceptance criteria4.5. Assign responsibility for each requirement
4.6. Manage incomplete requirements
4.7. Manage ambiguous requirements4.8. Manage conflicting requirements
4.9. Approve all requirements
5. Manage acceptance
5.1. Ensure the acceptance of every user need5.2. Ensure the acceptance of every design input requirement
5.3. Document the results of every user need acceptance test
5.4. Document the results of every design input requirements test
5.5. Make acceptance results available
6. Manage change
6.1. Maintain history of design element changes
6.1.1. Make complete change history available
6.1.2. Maintain history within and across any organizational procedure
6.1.3. Maintain history within and across any project milestone
6.1.4. Maintain history within and across any Design Control Guidance Elements6.2. Capture frequency and nature of element changes
6.2.1. Provide rationale for change6.2.2. Describe decisions made
6.2.3. Identify approval authority for the change6.2.4. Capture date, time, and signature of approving authority
6.3. Identify impacted elements due to a change in another element
6.3.1. Create backward traces to design elements within and across any organizational procedure
6.3.2. Create backward traces to design elements within and across any project milestone
1.1. Identify impacted elements due to a change in another element
• Traceability Reports: consistency with driving design elements
• Impact Reports: other design elements affected
• Links to impacted design elements
1.1.1. Create backward traces to design elements within and across any organizationalprocedure
• Traceability Reports: Procedure Attribute
1.1.2. Create backward traces to design elements within and across any project milestone• Traceability Reports: Milestone Attribute
1.1.3. Create backward traces to design elements within and across Design ControlGuidance Elements
• Traceability Reports: Linked design elements
1.1.4. Create forward impacts to design elements within and across any organizationalprocedure
• Impact Reports: Procedure Attribute
1.1.5. Create forward impacts to design elements within and across any project milestone
• Impact Reports: Milestone Attribute
1.1.6. Create forward impacts to design elements within and across Design ControlGuidance Elements
• Impact Reports: Linked design elements
1.2. Associate changed design elements with related elements
• Link Change Design Object with affected design element(s)
• Traceability Links and Reports from affected design element(s)
• Impact Links and Reports from affected design element(s)
1.2.1. Associate design element changes with decisions, rationale, and approval authority
information
• Change Decision Objects with following Attributes:
• Disposition Attribute
• Decision Attribute
• Rationale Attribute
• Owner Attribute
• Management Approval Attribute
1.2.2. Provide associations within and across any organizational procedure• Change Design Object Traceability Link on Procedure Attribute
• Change Design Object Impacts Link on Procedure Attribute
1.2.3. Provide associations within and across any project milestone
• Change Design Object Traceability Link on Milestone Attribute
• Change Design Object Impacts Link on Milestone Attribute
1.2.4. Provide associations within and across Design Control Guidance Elements• Change Design Object Traceability Link to traced design elements
• Change Design Object Impacts Link to linked design elements
1.3. Mange the change process
• Design Change Module
• Design Change Reports
• Object History
• Object History Reports
• Versions
• Baselines
1. 820.30(b) Design and Development Planning
Each manufacturer shall establish and maintain plans that describe or reference the design and development
activities and define responsibility for implementation.
The plans shall identify and describe the interfaces with different groups or activities that provide, or result
in, input to the design and development process.
The plans shall be reviewed as design and development evolves.The plans shall be updated as design and development evolves.
The plans shall be approved as design and development evolves.
2. 820.30(c) Design Input
2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to adevice are appropriate and address the intended use of the device, including the needs of the user
and patient.
2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to a
device are appropriate and address the intended use of the device, including the needs of the userand patient.
2.3. The procedures shall include a mechanism for addressing incomplete requirements.
2.4. The procedures shall include a mechanism for addressing ambiguous requirements.2.5. The procedures shall include a mechanism for addressing conflicting requirements.
2.6. The design input requirements shall be documented by a designated individual(s).
2.7. The design input requirements shall be reviewed by a designated individual(s).
2.8. The design input requirements shall be approved by a designated individual(s).2.9. The approval, including the date and signature of the individual(s) approving the requirements,
shall be documented.
2.10. Questions.2.10.1. Summarize the manufacturer's written procedure(s) for identification and control of
design input.2.10.2. From what sources are design inputs sought?
2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and
list additional aspects.)2.10.3.1. intended use
2.10.3.2. user/patient/clinical
2.10.3.3. performance characteristics
2.10.3.4. safety2.10.3.5. limits and tolerances
2.10.3.6. risk analysis
2.10.3.7. toxicity and biocompatibility
2.10.3.8. electromagnetic compatibility (EMC)
2.10.3.9. compatibility with accessories/auxiliary devices2.10.3.10. compatibility with the environment of intended use
2.10.3.11. human factors
2.10.3.12. physical/chemical characteristics
2.10.3.13. labeling/packaging2.10.3.14. reliability
2.10.3.15. statutory and regulatory requirements
2.10.3.16. voluntary standards2.10.3.17. manufacturing processes
2.10.3.18. sterility
2.10.3.19. MDRs/complaints/failures and other historical data
2.10.3.20. design history files (DHFs)
2.10.4. For the specific design covered, how were the design input requirements identified?2.10.5. For the specific design covered, how were the design input requirements reviewed for
adequacy?
Comply with FDA Design Control Guidance GMP Regulation
1. Capture design and related information
1.1. Input electronically formatted data
1.2. Reference external information sources
1.3. Reference external documentation
2. Store design and related information
2.1. Identify and tag design information as unique “design elements”
2.2. Organize design elements2.2.1. Organize by Design Control Guidance Element2.2.2. Organize by inter-relationships
2.3. Ensure all design elements are available
2.3.1. Store design elements by Design Control Guidance Element
2.3.2. Store design elements and their historical values
3. Manage all user needs3.1. Identify the source of the user need3.2. Identify all user types (groups)3.3. Identify the customer (s)3.4. Profile the expected patients3.5. State the intended use of the product (family)3.6. Capture the acceptance criteria for each user need
4. Manage design input requirements
4.1. Identify the source of the requirement
4.2. Identify the associated user need4.3. Capture requirement description and attributes
4.4. Capture acceptance criteria4.5. Assign responsibility for each requirement
4.6. Manage incomplete requirements
4.7. Manage ambiguous requirements4.8. Manage conflicting requirements
4.9. Approve all requirements
5. Manage acceptance
5.1. Ensure the acceptance of every user need5.2. Ensure the acceptance of every design input requirement
5.3. Document the results of every user need acceptance test
5.4. Document the results of every design input requirements test
5.5. Make acceptance results available
6. Manage change
6.1. Maintain history of design element changes
6.1.1. Make complete change history available
6.1.2. Maintain history within and across any organizational procedure
6.1.3. Maintain history within and across any project milestone
6.1.4. Maintain history within and across any Design Control Guidance Elements6.2. Capture frequency and nature of element changes
6.2.1. Provide rationale for change6.2.2. Describe decisions made
6.2.3. Identify approval authority for the change6.2.4. Capture date, time, and signature of approving authority
6.3. Identify impacted elements due to a change in another element
6.3.1. Create backward traces to design elements within and across any organizational procedure
6.3.2. Create backward traces to design elements within and across any project milestone
1.1. Identify impacted elements due to a change in another element
• Traceability Reports: consistency with driving design elements
• Impact Reports: other design elements affected
• Links to impacted design elements
1.1.1. Create backward traces to design elements within and across any organizationalprocedure
• Traceability Reports: Procedure Attribute
1.1.2. Create backward traces to design elements within and across any project milestone• Traceability Reports: Milestone Attribute
1.1.3. Create backward traces to design elements within and across Design ControlGuidance Elements
• Traceability Reports: Linked design elements
1.1.4. Create forward impacts to design elements within and across any organizationalprocedure
• Impact Reports: Procedure Attribute
1.1.5. Create forward impacts to design elements within and across any project milestone
• Impact Reports: Milestone Attribute
1.1.6. Create forward impacts to design elements within and across Design ControlGuidance Elements
• Impact Reports: Linked design elements
1.2. Associate changed design elements with related elements
• Link Change Design Object with affected design element(s)
• Traceability Links and Reports from affected design element(s)
• Impact Links and Reports from affected design element(s)
1.2.1. Associate design element changes with decisions, rationale, and approval authority
information
• Change Decision Objects with following Attributes:
• Disposition Attribute
• Decision Attribute
• Rationale Attribute
• Owner Attribute
• Management Approval Attribute
1.2.2. Provide associations within and across any organizational procedure• Change Design Object Traceability Link on Procedure Attribute
• Change Design Object Impacts Link on Procedure Attribute
1.2.3. Provide associations within and across any project milestone
• Change Design Object Traceability Link on Milestone Attribute
• Change Design Object Impacts Link on Milestone Attribute
1.2.4. Provide associations within and across Design Control Guidance Elements• Change Design Object Traceability Link to traced design elements
• Change Design Object Impacts Link to linked design elements
1.3. Mange the change process
• Design Change Module
• Design Change Reports
• Object History
• Object History Reports
• Versions
• Baselines
Требованиязаказчика
Техническиетребования
ТестированиеДизайн
Реализацию этоготребования как разупустили из виду
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 63
Виды... Атрибуты...
Практически неограниченное число атрибутов (колонок)
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 64
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 65
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 66
Подозрительные связи (Suspect links) представлены в документе:
либо как индикаторы либо как полное описание
Цепь последовательности никогда не прервется
Подозрительные связи
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 67
Трассировка поддерживает целостность набора документов
Если документы связаны …
то изменение,
сделанное в одном
документе...
... отражается в
виде флага в
другом документе
Может быть организована нотификация исполнителей по e-mail
�
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 68
Предложения другихпользователей
Внесение предложенияна изменение
Принятиерешения
в режиме on-line
Accepted
Rejected
On Hold
In Review
Пусть DOORS вместо вас контролирует процесс внесение изменений
���� К какому требованию
���� По какой причине
���� Текущая формулировка ���� Предлагаемая формулировка
Система внесения изменений:Change Proposal System (CPS)
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 69
DWA как альтернатива DOORS Desktop
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 70
DOORS Web Access – все для работы
Полная панель
атрибутов
Доступ к
дискуссиям
Полный
доступ к базе
Удобные линки
Поиск
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01
DXL : Doors eXtension Language
Анализ
Специальныеокна
пользователя
Статистика
Подсказка
Расширение возможностей Doors
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 72
Экспорт модели в Rhapsody, Tau, Rose
DOORS/Analyst
TAU/Architect
TAU/Developer
• Перенос модели в TAU/Developer
• Детализация модели
• Проверка архитектуры и функционала
• Генерация кода
TraceabilityTraceability
TraceabilityTraceability
Application
• Перенос модели в TAU/Architect
• Детализация модели
• Проверка архитектуры и фукционала
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 73
Разработка на основе требованийПредпосылки перехода к Model Driven Architecture
Rhapsody & Tau:Визуализация требований и модели
«Привяжите» элементы модели к вашим требованиям
DOORS:Управление требованиями и трассировка
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 74
Сравнение результатов тестирования
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 75
Тестирование требований (статус реализации)
Фильтр:результаты
всех тестов
по каждому
требованию
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 76
Сравнение результатов тестовых запусков
� Наглядность
� Понятность
� Доступность
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 77
Основные преимущества DOORS:
� Полная информация по проектам – в любое время, в любом месте
� В работе всегда самая последняя редакция любого документа
� Возможность контролировать реализацию каждого отдельноготребования и всего проекта в целом
� Эффективная работа в коллективе (в т.ч. и с заказчиками):� Работа с единой базой данных
� Контроль доступа к информации
� Контроль за исполнением на любом этапе (особенно на самых ранних)
� Простота внедрения:� с текстом умеет работать все
� остальному – научатся
� Значительное повышение качества разработок. Проект реализуется:� В нужные сроки
� В рамках бюджета
� С уверенностью, что каждый пункт задания выполнен
� Значительная экономия времени, средств и ресурсов
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 78
Управление требованиями, разработка и производство –вместе для достижения общей цели
Системныетребования
Детализация и «перевод»требований заказчика на
язык разработки, преобразуя скрытые инеявные требования в
точные, ясные инедвусмысленные
Требования кподсистемам. Ограничения
Дальнейшая детализацияуже системных требований,
подразумевающаяописание модулей, их
функциональности, интерфейсов,
производительности
Дизайн испецификации
Полная спецификациякомпонентов с
описание того, как ониудовлетворяют
предъявляемым к нимтребованиям
Требованиязаказчика
Характеристики системы, необходимые заказчику,
чтобы или решитьимеющуюся проблему
или достичь цели, или удовлетворить
условиям стандарта
DOORS PLM, PDM, CAD..
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 79
Процесс создания – от начала и до конца
� Шаг 1 � Собрать и сформулировать требования заказчика
� Шаг 2� Организовать и приоритезировать требования
заказчика
� Шаг 3 � Сформировать системные требования
� Шаг 4� Предусмотреть и сформулировать
конструктивные ограничения
� Шаг 5 � Разработать физическую структуру продукта
и его детальный дизайн
� Шаг 6� Организовать контроль, проверку,
тестирование, верификацию
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 80
АвтопромАвиация, ВПКТелеком Кораблестроение
Rational DOORS решает проблемы наших партнеров…
IBM Software Group | Rational softwareIBM Software Group | Rational software
[email protected], (985) 773-05-01 8181
© 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.
Анатолий Волохов