page 1copyright 2007 © siemens corporate research portraits in practice software engineering...

Copyright 2007 © Siemens Corporate Research

Portraits in Practice

Software Engineering Research & Development Challenges at Siemens

Juergen Kazmeier

Brian Berenbach

Dan Paulish

Marlon Vieira


Siemens has a long tradition of technological innovations.


The rate of innovations is increasing.

… 5 years and younger

… 6 to 10 years old

… more than10 years old

Share of sales with products…

1985 20051980

48%

30%

22%

55%

29%

16%

75%

19%

6%


Siemens is one of the world’s largest software companies.

► Siemens has more than 30,000 software developers.

► 60% of Siemens’ business is based on software.

► Siemens spends more than 3 billion euros per year on software development.


But, Siemens is not recognized as a software company, since most of our software is embedded.

Examples:

Automation devices

Industrial control systems

Automotive components

Communication systems

Rail systems

Medical devices


Siemens at a Glance

Medical

Medical Solutions

Transportation

TransportationSystems

Siemens VDOAutomotive

Power

Power Generation

PowerTransmission and

Distribution

Automation and Control

Automation andDrives

Industrial Solutions and

Services

Siemens Building Technologies

Lighting

Sylvania

Information andCommunications

Communications

Siemens BusinessServices Annual Worldwide Sales

75% of total sales are from products and services

developed in the last five years

$98.2 billion47,000 employees

$6.6B dedicated to global R&D

Net Income: $2.8B

World’s 21st largest company

Siemens AG: Worldwide figures for fiscal 20051 (U.S. GAAP2)1Fiscal Year October 1 – September 302Average annual exchange rate for FY 2005: €1.00 =$1.273


Global presence of Research and DevelopmentMore than 47,000 R&D employees at 150 locations


Berkeley

Romsey (RMR)

Berlin

Erlangen

Tokyo

Princeton

Shanghai

St. Petersburg

Bangalore

SiemensCorporate Technology

A Global Network

Corporate Technology: About 2,300 Researchers and Developers Worldwide

Moscow

Beijing

Munich


Much of our research is done in collaboration with universities.


Software Engineering Challenges at Siemens

Functionality previously realized in electrical or electro-mechanical systems is now being realized in software => bigger, more complex, & more software projects (hundreds of developers, millions of lines of code).

Meeting functional and non-functional requirements is important to business success => restricted hardware resources, real-time performance, safety critical applications.

Multisite development projects.

High quality (i.e., thoroughly tested, reliable) software is important to business success.

Our software engineering methods and technologies must address the increasing scale and complexity of

emerging software systems.


There are three major levers for optimizing software development.

Synergies• Architecture• Platforms

Structure• Offshoring/

Outsourcing• Site strategy

Processes• Simplification• Standardization• Stabilization


We address software engineering challenges in R&D programs. Today’s Portraits in Practice focus: Requirements Engineering, Architecture Practices, Testing

SCR SE

RequirementsEngineering

(Brian)

ArchitecturePractices, GSD

(Dan)

SW PlatformTechnologies

ProcessAssessment & Improvement

ProjectManagement

Testing(Marlon)

System & Software Quality Architecture & Platform Technologies

Requirements EngineeringProcesses & Project Management

Assess and improve software development processes and project management

Ensure high quality software based systems by Testing, Code Quality Management and Performance Engineering

From business needs to software design faster, with

better quality and transparency for project control and

oversight

Building coherent, interoperable and

future-proof systems

QualityEngineering


Thank you!

Contact: Juergen KazmeierDepartment Head, Software & Systems [email protected] +1 (609) 734-3610


Requirements Engineering @ Siemens

Brian [email protected]


The Challenge

To provide effective requirements development and management processes

for a set of extraordinarily disparate Siemens companies.

To raise the level of expertise in requirements engineering throughout

Siemens.


For Example… Siemens Automotive

Chassis & Car body

Fleet Management

Infotainment

Interior

Marine Solutions

Special OEM Solutions

Power Train

Public Transport Solutions

Replacement Parts


Customers Provide the Requirements

Stakeholder requests from customers

in PDF documents & Excel tables

ManualProcessesManual

Processes

RequirementsDatabase

RequirementsDatabaseDifficulty Managing Change!


Requirements as State Tables

Again, Difficulty Managing Change!


CustomerSiemens


Unique OEM Problems

Customers deliver their requests in varying media

Everything is priority 1

Customers feel under no obligation to limit change requests

Change requests come in the form of new documents (PDF) and state tables (Excel) with no change matrix. How do you manage change and traces?

Requests may be vague because customers expect that “Siemens will figure it out”.


Providing Integrated Medical Solutions Leads to Many

Requirement Dependencies


“V” Model for Traceability

Stakeholderrequirements

Systemrequirements

Subsystemrequirements

Componentrequirements

Acceptancetest plan

Systemtest plan

Integrationtest plan

Componenttest plan

Impact analysis

Der

ivat

ion

ana

lysi

s

Impact analysis

Derivation analysis

Are all requirements covered by the layer below?

Are all requirements covered by tests?


“V” Model leads to tag based tracing


Tag based training has issues

No rationale for traces

Difficult to cluster traces

Effort rises geometrically with project size

Difficulty managing cascading or cross-cutting changes


Companies such as Siemens Building Technology build products with distributed (worldwide) stakeholders and development teams.


How to capture functional and non-functional requirements?

Desired Single Customer View but…

Multiple Regions

Multiple Business Units

Everything must plug and play TOGETHER


Global Challenges for Siemens

Conversion of products to product lines

Capturing requirements across regions and across business units

Raising the RE skill level of staff world-wide


Challenges

One size does NOT fit all!

Effectively Controlling Change

Managing Scale

Managing Customers


…and Some Possible Solutions

Traceability Dynamic Tracing

Rich Traces

New Modeling Languages

Complexity, Scale (>10K Requirements)

Model-Driven RE

Advanced Tools.

RE Skills Basic RE Courses

Skill Certification


Thank you!

Contact: Brian BerenbachRE Center of Competence [email protected] +1 (609) 734-3395


Dan [email protected]

Methods & Processes forGlobal Software Development


Agenda

Motivation for Global Software Development (GSD)

Challenges

An Approach

Lessons Learned

Open Issues and Research Questions


Global Software Development (GSD): Motivation

Lower development costsLower development costs• Low-wage countriesLow-wage countries

Capitalizing on a pool of trained workforceCapitalizing on a pool of trained workforce• Quest for talentQuest for talent

Increased output, reduced timeIncreased output, reduced time• Improve time-to-marketImprove time-to-market• Round-the-clock developmentRound-the-clock development

Market proximityMarket proximity• Specific local expertiseSpecific local expertise• Market acquisition effortMarket acquisition effort

Governmental policies and incentivesGovernmental policies and incentives

Original motivation was reduced

development cost,but there are other reasons for GSD.


Time Difference: 11.5 hours

Physical distance

But, Global Software Development is Difficult.


Global Software DevelopmentSiemens has more than 15 years experience developing software products globally.

Today, most Siemens business groups develop software in low-cost countries.

Organization and process model for global development divides responsibility between a central headquarters organization & remote development teams.

Software engineering

expertise

Domainexpertise

Management&

Processexpertise

Central team

Developmentexperience

Technology expertise

Softwareengineering

expertise

Remote development teams

Supplier Managers

Integrated byCode

Component requirements

Component design

Verified by

TestsVerified by

Requirements

Architecture & design

Acceptancetests

Developmentplan


Global Studio Project (GSP)Experimental global software development project using university student teams and researchers.

Shadows real Siemens global development project, process, & organization.

Document processes, best practices, and understanding of how to successfully execute global projects.

International Institute of Information Technology,

Bangalore, India

Technical University of Munich, Germany

University of Limerick, Ireland

Pontifical Catholic University of Rio de Sul,

Brazil

Carnegie Mellon University, USA

Monmouth University, USA

Harvard Business School, USA

Siemens Corporate Research, USA


GSP Research Goals

Identify and document best (and worst) practices for global software development.

Identify the prerequisites for successful global software development.

Test a global software development reference process.

Determine artifacts for commissioning a remote development team.

Identify communications necessary for effective global development.


Social Network Analysis (SNA)

Roles Developer Team Leader Function Manager Remote Supp. Manager Central Supp. Manager Executive

Affiliations (Sites) SCR Central Team Tech. Univ. Munich CMU Sapphire IIITB Monmouth #5 Monmouth Codicons Monmouth TCT Limerick ArdnaCroise


Some Lessons Learned

Amount of Required Communications

Cultural Differences among Teams

Start-up Time for Remote Teams

Supplier Managers as the interface to Remote Teams

Team Size

Agility


Open Issues and Research Questions

1. Given that the technical artifacts that are delivered to the remote component development teams are not adequate in specifying the precise work to be done, in what ways are they deficient?

2. What strategies do the remote teams employ to compensate for the deficiencies found in the received technical artifacts?

3. What are the early warning signs that an issue is imminent? Can communication patterns, for example, between the central and remote teams be used to predict future component integration problems?


Thank you!

Contact: Dan PaulishDistinguished Member of Technical [email protected] +1 (609) 734-6579


Agenda

Motivation and Some Challenges

Observations on Automation of Testing for Diverse Siemens Projects

Some Observable Best Practices

Our Research Focus

Suggestions on Research Topics

Final Comments


Automation of Testing: Motivation

Motivation • Pressure to release software to the

market (with quality and on time)• Some tests cannot be run without

automation• Test teams have time to address

bigger test issues• Improve tester job satisfaction


Automation of Testing: Some Challenges to Adopt It in Practice

Some Challenges• Global Development• Investment in the automation itself (ROI calculation)• Testers with development skills• Industrial scale solutions


Automation of Testing: Observations (Diverse Siemens Projects)

The test process and its automation in practice (Tools)

plan test Design tests Execute tests Analyze resultsPlan tests

Component Integration ValidationUnit

Test Management Tools

MBT Tools

Capture-Replay

Simulators/emulators

Custom Frameworks

High * Medium * Medium * Low *

* Automation level (usage)

Test Analysis Tools

Defect Classification

Metrics Analysis


Other Observations: Best Practices

Observable Best Practices• Dealing with testing automation as a

software development process• Designing tests first before deciding to

automate–Test creation (or generation)

separated from execution• Applying an incremental approach

–Start small and grow - Provide frameworks (libraries) and exercise tests with different data

–Not everything is automated (allow exploratory tests)


Other Observations: Emerging Strategies

Emerging Industrial Strategies• Test-driven development (Unit Testing Frameworks)• Model-based testing • Keyword-driven automation


Our Research Focus on Automation of Testing

Model Based Testing• Test case generation based on UML Analysis Models• UML 2.0 Models – Use Case, Activity, Sequence and

Statechart diagrams• U2TP (UML 2 Testing Profile)

Data driven test case generation • Category-Partition Method

Architectural issues on flexible/robust testing frameworks• Customizable framework to execute tests in a specific domain


Suggestions for Research: Improvements for Industrial Scale Problems

Testability • Design changes (dynamic)• Different environments• Failure treatment (restart and

remote test execution)• Visibility and Control (stimulus

and result verification)

Event-Triggered Real-time Systems

• Non-deterministic execution orders

• Impact of the execution environment


Final Comments

Automation of Testing must fit within project and organizational context.

The industrial automation approach needs to be affordable.

1. Usable and Scalable2. Allow early results3. Easy Evolution

A broad range of academic research is currently being used in the software industry.

Examples:– Assertions– Model-Based Testing– Model Checking


Contact: Marlon Vieira Program Manager, Software Testing [email protected] +1 (609) 734-3313

Thank you!

page 1copyright 2007 © siemens corporate research portraits in practice software engineering...

Documents