IBM Software Group · Системный инжиниринг-целостный, ... Системный анализ и дизайн HW/SW design document Дизайн приложения

®

IBM Software Group

© 2008 IBM Corporation

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

преимущество:

Системный инжиниринг

Анатолий Волохов,Software Group, Rational-Telelogic Solutions,

[email protected]

IBM Software Group | Rational software

2


Системный инжиниринг (System Engineering). Определения

� Системный инжиниринг - целостный, ориентированный на изделиеподход, отвечающий за создание и выполнение процессов, охватывающихразличные инженерные дисциплины и обеспечивающих удовлетворениенужд заказчиков и непосредственных пользователей изделия

� Системный инжиниринг – есть междисциплинарный подход, используемый для контроля за разработками сложных, инновационных

изделий и систем *

� Система – это набор компонентов (которые и сами могут

быть системами), соединенных и связанных определеннымобразом так, чтобы обеспечить функционирование, котороесами по себе компоненты обеспечить не могут.

� Корабль, самолет, ракета - есть система.. и их основныекомпоненты (корпус, крылья, система управления, силовые

установки, вооружение, программное обеспечение ...), такжеявляются системами (или оборудованием)


3


Source: The Seattle Times

Bo

ein

g 7

87 D

ream

lin

er

Кол-во комплектующих : 6 млн.Число поставщиков : 2,600

Переход от полного производства к системной сборкеПассажирский самолет Boeing 787

Производство и поставка комплектующих:

Схем в САПР : 20,000Изменений в дизайне : 150,000


4


Значительно возрастает доля программной составляющейи это ведет к существенным проблемам

Типсамолета Год Функции,

контролируемые ПО

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%

��

«Железо»

Разработка

Программное

обеспечение


5


Системный Инжиниринг отвечает за всю картину в целом, обеспечиваявыполнение требований в течение всего жизненного цикла изделия.

Зачем нужен Системный Инжиниринг

� Повышение вероятности успеха создания Системы� Понимание природы Системы и ее поведения в окружающей среде

� Определение характеристик Системы с точки зрения пользователя

� Уменьшение рисков

� Определение и оценка рисков, неопределенностей и изменяемых параметров впроцессе принятия решений

� Соответствие нормативным документам и требованиям регулирующих организаций

� Уменьшение общей стоимости жизненного цикла изделия

� Улучшение процесса принятия решений в планировании, разработке, управлении, эксплуатации

� Такой подход начинается с понимания потребностей заказчика, определенияфункциональности изделия и обязательных запланированных проверок

(аттестаций, приемочных испытаний, контроля) на самых ранних стадияхжизненного цикла создания изделия


6


Проверки, тесты,приемо-сдаточные

испытания, сертификация

Проверки, тесты,приемо-сдаточные

испытания, сертификация

R

R1 R2

R1-1 R1-2 R2-1 R2-2 R2-3

F1 F5

F2 F3

F4 System

Разработка и управлениетребованиями

Разработка и управлениетребованиями

Функциональныйдизайн

Функциональныйдизайн

Архитектурныйдизайн

Архитектурныйдизайн

Физическийдизайн

Физическийдизайн

Проверка требований

Проверка функционала

Проверка архитектуры

Проверка

дизайна

� Разработка продукта в полном соответствии с требованиями

� Учет изменений на всех уровнях разработки

� Тесты, проверки, сертификация проверят требования

� Обеспечивается сквозной мониторинг производства продукта

� Конечный продукт соответствует требованиям на все 100%

� Разработка продукта в полном соответствии с требованиями

� Учет изменений на всех уровнях разработки

� Тесты, проверки, сертификация проверят требования

� Обеспечивается сквозной мониторинг производства продукта

� Конечный продукт соответствует требованиям на все 100%

Для чего это все нужно ?


7


Проблемы с проектами

� Только 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

К чему ведет неиспользование системного инжиниринга


8


� Аэрокосмическое агентствоНа 40с полета бортовой компьютерпрототипа стратегической ракетыстоимостью $1 млрд. ошибочно выдалкоманду на самоуничтожение

Аварии все еще продолжают беспокоить производителейи PLM не является панацеей от всех бед..

� Производитель автомобилейКомпания вынуждена была отозвать75 тысяч автомобилей, которые из-заошибки в ПО вдруг начиналитормозить на большой скорости

� Производитель мед. оборудования:Из-за некачественного ПО пришлосьизымать из эксплуатации42 тысячи дефибрилляторов


9


Почему это происходит?Пользователи разделены разными приложениями и средствами коммуникации

Совместно решать проблемы

Отслеживать статус программы

Общаться с поставщиками

Обслуживание

Производство

Дизайн

Закупки

Качество итестированиеУправление

проектамиПартнеры

Планирование

производства


10


� Несогласованность процессови правил, используемыхучастниками проекта

� «Know-how» – только в пределахсвоей вертикали

� Информация, доступная тольковнутри вертикалей, снижаетобщую производительность группы

� Сложность сотрудничества иобмена данными и результатами

Почему это происходит?Вертикальная структура организации разработки – уже большая проблема

SW MCAD E / E Рук-во

Программныекомпоненты

Механическиекомпоненты

Электронныекомпоненты

? ? ?

� Заниженные возможности отслеживания оперативных решений и меняющейсяинформации

� Низкий уровень повторного использования существующих решений и артефактов, а также слабый контроль над процессами

� Разработка не всегда отражает потребности рынка


11


Системный инжиниринг требует взаимодействия множестваинструментов и дисциплин для обеспечения и поддержки

Решения для системного инжиниринга

� Управления совместными бизнес-процессами:

� Управление портфелями

� Управление программами

� Управление требованиями

� Управление изменениями

� Управление конфигурациями

� Управление поставками

� Управление потоками задач

� Контроль за соблюдением стандартов

� Моделирование и тестирование системи изделий (в зависимости от их типа) :

� UML & SysML

� Rhapsody

� Simulink

� Modelica

� MCAD & ECAD


12


Разработка без управления требованиями –непредсказуемый результат

Если требования плохие, то все остальные вашиусилия, процессы и инструменты лишь помогут вамкак можно быстрей создать плохой продукт.

Если вы еще только начинаетезадумываться об улучшенииваших процессов, то помните, что начать стоит именно спроцесса управлениятребованиями, потому что здесьдействует простой принцип :

что посеешь, то и пожнешь.


13


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


14


Вся наша жизнь – это работа с требованиями.... В БЫТУ

� Если жена звонит вам и просит по пути с работы домой купить – хлеб, сахар, масло, молоко и вино - то это ничто иное, как сбор и формирование требований

� Если в разговоре выясняется, что она имела ввиду:� Хлеб белый – 1 батон� Масло растительное - 1 бутылка� Сахар-песок– 2 пачки� Молоко топленое – 1 литр

то это ничто иное, как декомпозиция и детализация требований.

� Разговор заканчивается тем, что вы приходите к выводу, что вино выпокупать не стоит, потому что в гости придет друг, которому пить противопоказано ... - это ничто иное, как работа с ограничениями или учет ограничивающих факторов

� Если вы решаете, что хлеб, масло и сахар вы купите в одном магазине, а вот молоков другом - это выглядит как структуризация требований

� Если чуть позже жена вновь звонит вам и говорит, что она передумалаи просит вместо молока купить сметану, то это изменение требований

� Если уже дома вы сверяете купленное с тем списком, что диктовалажена, - это проверка реализации требований или тестирование

� И если обнаруживаете, что вместо сметаны вы все-таки купили молоко- это значит, что вы не учли изменение, ранее внесенное в одно из требований


15


Интеграционное

и модульное

тестирование

Архитектурный

дизайн

Приемочные

тесты

Системное

тестирование

Промышленные

стандарты

Системные

требования

Требования

заказчика

Нормы и

правила

Соответствует

Подчиняется

Тесты

Тесты

Тесты

Реш

ает

Реш

ает

Вся наша жизнь – это работа с требованиями.... НА РАБОТЕупрощенная модель проекта


16


Стоимость

исправлений и

корректировок

Время

Вынужденные

ошибки

Формированиетребованийи их анализ

Системный

анализ и дизайн

HW/SW design

document

Дизайнприложения

Реализация

приложения и

блочные тесты

Requirements

document

SW design

specification

Модульнаяинтеграция итестирование

Приемка

системы

Интеграция итестирование

подсистем

.exe

.doc

.exe

.doc

В большей степени это происходит потому, чтолюди с разным мышлением с трудом понимают друг друга


17


Более 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


18


Треб

ован

ия

Система

КрахДизайн

• Около 60%-70% общего числа всех проектов заканчиваютсяплачевным результатом только из-за неудовлетворительногоформирования требований, их анализа, управления и контроля

- Meta Group, 2003

� Задержки - средний проект «опаздывает» на 220%

� Неэффективная работа - 40-50% времени специалиста тратитсяна задачи, не связанные с выполнением его непосредственныхобязанностей: поиск нужных документов, отслеживание изменений...

Очень важен правильный старт и эффективная работа


19


Формированиетребованийи их анализ

Системный

анализ и дизайн

Приемка

системы

Интеграция итестирование

подсистем

Модульнаяинтеграция итестирование

Дизайнприложения

Реализацияприложения и

блочные тесты

Software Engineering

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

Тест инжиниринг

Инжиниринг требований ломает барьеры


20


20

© 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.

Анатолий Волохов

[email protected]

Documents

IBM Software Group · Системный инжиниринг-целостный, ... Системный анализ и дизайн HW/SW design document Дизайн приложения