Trends in System/Software Engineering Discipline - Lorenco Damjanic Ericsson Nikola Tesla
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Trends in System/Software
Engineering Discipline
Lorenco Damjanic
Ericsson Nikola Tesla
Z
ZagrebbContents
• Telecom industry trends
• Software Engineering – an overview
• F
From code
d tto workable
k bl product
d t
• System vs. Software Engineering
• Further Challenges
• LiteratureTelecom industry trends
Industry transformation / Convergence
(from 1997)
mobility 3G/Wireless Internet
Wireless/Cellular
MMM
Wireline New
ISDN WAP
Telecoms Personal
Telecom PTN
Industry (Mobile)
PSTN
Industry Intranet/Internet
Carrier class Multi-media
Multi media
PC-WAN WWW
services
PC-LAN The Converged
PC/Server
s
desk top computing Industry
Computer Industry
main frames
electronic
publishing and
entertainment
Media IndustryTransformation to new
communication architecture and
Today’s
business models Starting Converged
Single-Play service networks Triple-Play service per network Multi-media services network
Content Application
TV
Cable T
Multi-Media Services
Wireline
ata/IP
Services Services Services
eless
Multi-Media & Telephony
TV
Control (IMS with Mobility)
Da
IMS
Wire
IMS IMS
xDSL/GbE Cable Connectivity/
3G WiFi/Max Packet Backbone Network
Connectivity
Multi-Access NetworksNetwork Topology
p gy
Service layer
Value add
Charging service Business
execution Processes
IMS and other standardized services
IMS Mess- Soft-
server aging switch
MRFP MGW
Multi access edge
Transport
Policy network
MSER control AGW
Wired Wireless
access Metro aggregation access
CESR
AN BS
e.g. Cable, POTS e.g. GSM, LTE,
GPON, xDSL HSPA, WCDMAEnd-to-end transport Network
News
Internet
Data Weather
IP
Video Gaming
Entertainment Voice
xDSL
DSL
Gigabit/s
Hundreds of
Megabit/s
Gigabit/s Tens of Gigabit/s
Terabit/s
Hundreds of
Megabit/s
Gigabit/s Network
management
Customer Access Metro CoreEvolution into an Multi Access
All-IP Network
SERVICE
NETWORK
ALL-IP
Internet
CORE NETWORK
ACCESS
NETWORKS “4G”
Broad- WLAN
band 3G
2G
PERSONAL AREA
NETWORK
BluetoothBandwidths
1 Gbps EFM-Fiber
2007
100 Mbps EFM-VDSL2 4G
2006 2012
24 Mbps ADSL2plus
p WiMax (LOS) Super
p 3G
2004 2005 2009
WiMax
8 Mbps 3G Evolved
(e/mobile)
ADSL ~2007 2005
512 kbps WiMax (NLOS)
2000 3G
2002
64 kbps Dial-up
Dial up 2G
1990 2005 1990
Fixed Fixed-Wireless Mobile
Broadband Broadband Broadband
Shared Access
Shared CoreCoverage vs Bitrate
Bitrate
14.2 Mbps
p
7.2 Mbps
1.8 Mbps
Coverage
Double Peak Rate does not correspond to double CapacityCommon LTE Evolution
Alignment for WCDMA/HSPA,
WCDMA/HSPA TD-SCDMA(China)
TD SCDMA(China) and
CDMA
GSM Track (3GPP)
DoCoMo
GSM WCDMA HSPA LTE Vodafone
TD--SCDMA
TD FDD and TDD
China Mobile
Verizon
CDMA Track (3GPP2)
CDMA One EVDO Rev A
WiMax Track (IEEE) Sprint Nextel
(Fixed
( WiMax)) Mobile WiMax
2001 2005 2008 2010
LTE the Global standard for Next GenerationBitrates and Technologies
OFDMA d
does nott mean 4G
Bitrate (Mbps)
300 LTE
FDD and TDD
”4G”
3G
40
HSPA WiMax
FDD TDD
Technology
CDMA OFDMA
4G relates to IMT Advanced, over 100 Mbps - not to OFDMAService Layer
Technologies
Research Areas
Service layer
Value add
Charging service Business
execution Processes
IMS and other standardized services Multimedia
IMS Mess- Soft-
Technologies
server aging switch
SW Research
MRFP MGW
Multi access edge IP Networks
Transport
Policy network Wireless Access
MSER control AGW
Networks
Wired Wireless
access Metro aggregation access
CESR
AN BS
e.g. GSM, LTE, Access Technologies
e.g. Cable, POTS
GPON, xDSL HSPA, WCDMA & Signal Processing
Broadband and
Transport Networks EMF Health
and SafetySoftware Engineering
History and Rational of Software Engineering
In the belief that software design, implementation and maintenance could be
put on the same footing as traditional engineering discipline a NATO study
group in 1967 coined the term:
Software Engineering
which should use philosophies and paradigms of established engineering
discipline to solve what was termed
the software crises
namely, that the quality of software was generally unacceptably low and that
namely
deadlines and cost limits were not being met.Software system
• A software system is a system based on software forming part of a compute
system (a combination of hardware and software)
software).
• The term software system is often used as a synonym of computer program or
software.
• The term software system is related to the application of systems theory
(Systems theory is an interdisciplinary field of science and the study of the nature of complex systems
in nature, society, and science.)
approaches in software engineering context.
context
• This approach is often used to study large and complex software, because it
focuses on the major components of software and their interactions.
• The term software system is also related to the field of software architecture.Software
• Software is a general term for the various kinds of programs used to operate
computers
t andd related
l t dddevices.
i
• Software is often divided into
– application software (programs that do work users are directly interested in) and
– system software (which includes operating systems and any program that supports application software).
– The term middleware is sometimes used to describe programming that mediates between application and
system software or between two different kinds of application software (for example, sending a remote work
request from an application in a computer that has one kind of operating system to an application in a
computer
p with a different operating
p g system).
y )
• Software can be purchased or acquired as
– shareware (usually intended for sale after a trial period),
– liteware (shareware with some capabilities disabled),
– Freeware (free software but with copyright restrictions),
– public domain software (free with no restrictions), and
– open source (software where the source code is furnished and users agree not to limit the distribution of
improvements).Software Types
• In computer science, real-time computing (RTC) is the study of hardware and software systems
which are subject to a "real-time constraint"—i.e., operational deadlines from event to system
response.
• By contrast,
contrast a non
non-real-time
real time system is one for which there is no deadline
deadline, even if fast response
or high performance is desired or even preferred.
• The needs of real-time software are often addressed in the context of real time operating systems,
and synchronous programming languages, which provide frameworks on which to build real-time
pp
application software.
• A real time system may be one where its application can be considered (within context) to be
mission critical
• Fault-tolerance or graceful degradation is the property that enables a system (often computer-
computer
based) to continue operating properly in the event of the failure of (or one or more faults within)
some of its components. If its operating quality decreases at all, the decrease is proportional to
the severity of the failure, as compared to a naively-designed system in which even a small failure
can cause total breakdown.
• Fault-tolerance is particularly sought-after in high-availability or life-critical systems.Software Reliability
• High
Hi h availability
il bilit is
i a system
t design
d i protocol
t l and
d associated
i t d iimplementation
l t ti th
thatt
ensures a certain absolute degree of operational continuity during a given
measurement period.
• Availability
A il bilit refers
f to
t the
th ability
bilit off the
th user community
it to
t access the
th system,
t whether
h th
to submit new work, update or alter existing work, or collect the results of previous
work. If a user cannot access the system, it is said to be unavailable.
• Th tterm downtime
The d ti i used
is d tto refer
f tot periods
i d when
h a system
t iis unavailable.
il bl
• A life-critical system or safety-critical system is a system whose failure or
malfunction may result in:
– death or serious injury to people, or
– loss or severe damage to equipment or
– environmental harm.Software Engineering Definition
• Software engineering is the application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance of software.
• Software engineering encompasses techniques and procedures, often regulated
by
a software development
p process
p
with the purpose of improving the reliability and maintainability
of software systems.
• A software development process is a structure imposed on the development of a
software product.Software Engineering Discipline
• The discipline of software engineering includes knowledge, tools, and methods for
• Software requirements
• Software design
• Software construction
• Software testing
• Software maintenance
• Software configuration management
• Software engineering management
• Software engineering process
• Software engineering tools and methods
• Software quality.
• Software engineering is related to the disciplines of
• Computer engineering
• Computer science
• Management
• Mathematics
• Project management
• Quality management
• Software ergonomics
• Systems engineering30 year later
• The software crises is still with us which force us to rename it to the
software depression in view of its long duration and poor prognosis.
• The question is does the software production process, while resembling
t diti
traditional
l engineering
i i iin many respectt h
has it
its own unique
i properties
ti andd
problems.Generic Software Life Cycle Cost
Evolution of ISO/IEC 12207 Standard
(System and software engineering-
engineering
Software life cycle processes)Standards Relationship • ISO 9001:2000 Quality management systems • ISO/IEC 90003:2004; Software engineering – Guidelines for the application of ISO 9001:2000 to computer software”.
Structure of ISO/IEC 12207 Standard
(System and software engineering-
engineering
Software life cycle processes)The major engineering process steps for
d
developing
l i software
ft .Software Engineering Development
M th d
Methods
• Some software development methods:
– Waterfall model
– Spiral model
– Model driven development
– User experience
– Top down and bottom
Top-down bottom-up
up design
– Chaos model
– Evolutionary prototyping
– Prototyping
– ICONIX Process (UML
(UML-based
based object modeling with use cases)
– Unified Process
– V-model
– Extreme Programming
– Software Development Rhythms
– Specification and Description Language
– Incremental funding methodology
– Verification and Validation (software)A Full Range of Software Engineering Process Trends 1
Demand Structured
growth
growth, Methods
diversity Spaghetti Code
Waterfall Process
Large Projects
Projects,
Hardware Weak Planning &
Engineering Software Craft Control
Methods -Code-and-fix
-SAGE -Heroic
Software Process overhead
-Hardware debugging
Deficiency
Efficiencyy
Many Defects Formal Methods
Skill Shortfall
Domain
Understanding
Hardware Engineering Crafting Formality, Waterfall
1950’s 1960’s 1970’sThe
eSSAGA
G Software
So t a e Development
e e op e t Process
ocess ((1956)
956)
Operational Plan
Machine Specification Operational Specification
Program Specification
Coding Specification
Coding
Parameter Testing
(Specification)
Assembly Testing
(Specification)
Shakedown
System EvaluationA Full Range of Software Engineering Process Trends 1
Demand Structured
growth
growth, Methods
diversity Spaghetti Code
Waterfall Process
Large Projects
Projects,
Hardware Weak Planning &
Engineering Software Craft Control
Methods -Code-and-fix
-SAGE -Heroic
Software Process overhead
-Hardware debugging
Deficiency
Efficiencyy
Many Defects Formal Methods
Skill Shortfall
Domain
Understanding
Hardware Engineering Crafting Formality, Waterfall
1950’s 1960’s 1970’sThe
e Royce
oyce Waterfall
ate a Model
ode ((1970)
9 0)
System
Requirements
R i t
Software
Requirements
Preliminary
Program
Design
Analysis
Program
Design
Preliminary
Design Coding
Analysis
Testing
Program
Design
Coding Operation
Testing
UsageA Full Range of Software Engineering Process Trends 1
Evolvability,
reusability Enterprise integrity Integrated
g Systems
y
Object-oriented
Object oriented
And Software
Methods Human factors Engineering
Spaghetti Code
Global connectivity,
Stovepipes business practicality,
Process
Structured security threats,
bureaucracy
M th d
Methods St d d
Standards, massive systems
Agile Methods Lack of scalability of systems
Maturity Models
Noncompliance Hybrid Agile,
Waterfall Process
Plan-Driven
Methods
Large Projects, HCI, COTS, Concurrent, risk-
Weak Planning emergence driven process Rapid Collaborative
& Control change methods,
Disruptors:
Slow execution infrastructure,
Autonomy,
Process overhead
environments;
Bio-computing ?
Value-based
Software Factory Rapid composition
composition, Computational
p
methods’;
evaluation Plenty,
Enterprise
environments Multicultural
architecture;
mega systems
Many Defects System
building
Rapid change
by users
Formal Methods Lack of scalabilityy Rapid
Domain specific change
Scale
SW architecture,
Skill Shortfalls product line reuse
Service-orientated
Architecture, Model
Business 4GLs
Domain Lack
L k off Model driven
Model-driven clashes
l h
CAD/CAM, User
Understanding scalability development
Programming
Formality, Waterfall Productivity Concurrent Processes Agility; Value Global Integration
1970’s 1980’s 1990’s 2000’s 2010’sRisk Driven Spiral Software Engineering Model
Rational Unified Process
Cleanroom Software Engineering Process
The Cleanroom Software Engineering process is a software development process intended to produce software with a
certifiable level of reliability.The
y focus of the Cleanroom process
p is on defect pprevention,, rather than defect removal.
The name Cleanroom was chosen to evoke the clenrooms used in the electronics industry to prevent the introduction of
defects during the fabrication of integrated circuits.
The Cleanroom process first saw use in the mid to late 80s.
80s Demonstration projects within the military began in the early
1990s.Recent work on the Cleanroom process has examined fusing Cleanroom with the automated verification capabilities
provided by specifications expressed in CSP (Communicating Sequential Processes is a formal language for describing
pattern of interaction in concurrent systems).
The basic principles of the Cleanroom process are:
•Software development based on formal methods
Cleanroom development makes use of the Box Structure Method to specify and design a software product. Verification
that the design correctly implements the specification is performed through team review
review.
•Incremental implementation under statistical quality control
Cleanroom development uses an iterative approach, in which the product is developed in increments that gradually
increase the implemented functionality. The quality of each increment is measured against pre-established standards to
verify
if that
h theh development
d l process is
i proceeding
di acceptably.
bl A failure
f il to meet quality
li standards
d d results
l in
i the
h
cessation of testing for the current increment, and a return to the design phase.
•Statistically sound testing
Software testingg in the Cleanroom process
p is carried out as a statistical experiment.
p Based on the formal specification,
p ,
a representative subset of software input/output trajectories is selected and tested. This sample is then statistically
analyzed to produce an estimate of the reliability of the software, and a level of confidence in that estimate.Agile Software Development
Agile Software Development is a conceptual framework for software development that promotes development iterations
throughout the life
life-cycle
cycle of the project.
project
There are many agile development methods; most minimize risk by developing software in short amounts of time.
Software developed during one unit of time is referred to as an iteration, which typically lasts from one to four weeks.
Each iteration passes through a full software development cycle: including planning, requirements analysis, design, coding,
testing, and documentation.
An iteration may not add enough functionality to warrant releasing the product to market but the goal is to have an available
release (without bugs) at the end of each iteration. At the end of each iteration, the team re-evaluates project priorities.
Agile methods emphasize face-to-face
face to face communication over written documents.
documents Most agile teams are located in a single open
office sometimes referred to as a Scrum .At a minimum, this includes programmers and their "customers" (customers define
the product; they may be product managers, a business annalists, or the clients). The office may include software testers,
interaction designers, technical writers, and managers.
S
Some off the
h principles
i i l behind
b hi d the
h Agile
A il Manifesto
M if are:
•Customer satisfaction by rapid, continuous delivery of useful software
•Working software is delivered frequently (weeks rather than months)
•Workingg software is the pprincipal
p measure of progress
p g
•Even late changes in requirements are welcomed
•Close, daily cooperation between business people and developers
•Face-to-face conversation is the best form of communication (Co-location)
•Projects are built around motivated individuals, who should be trusted
•Continuous attention to technical excellence and good design
•Simplicity
•Self-organizing teams
•Regular adaptation to changing circumstancesSoftware Intensive Systems
• software-intensive systems —any system in which software
development and/or integration are dominant considerations—most
complex systems these days.
• This includes computer-based systems ranging from
– individual software applications,
– information systems,
– embedded systems
systems,
– product lines and product families and
– systems-of-systems.From a code to workable
productVasa Testing
• In the inquiries after the Vasa disaster
it was revealed that a stability test
had been performed prior to the
maiden voyage.
• Thirty men had run back and forth
across the Vasa
Vasa'ss deck when she was
moored at the quay. The men had to
stop after three runs, well before the
test could be completed - otherwise,
the ship would have capsized.
capsized
• Present was Admiral Klas Fleming,
one of the most influential men in the
Navy. His only comment to the failed
stability
t bilit ttestt was "If only
l His
Hi Majesty
M j t
were at home!" After that he let the
Vasa make her maiden voyage.What is Software Testing?
• Testing is the process of examining the attributes of software to see if it
meets both the defined expectations of the software developers and the
actual needs of the users.
• It can include direct examination of the code (a “static” test) or execution of
the code (a “dynamic”
dynamic test) under circumstances that may or may not be
predefined.
• Testing is normally done in more than one level. Some examples of test
levels (from ISO 12207) for new development are:
• Each software unit and database
• Integrated units and components
• T t for
Tests f each h software
ft requirement
i t
• Software qualification testing for all requirement
• System integration: aggregates of other software configuration items,
hardware, manual operations and other systems
• System qualification testing for system requirementsType of software testing
• The term “coverage” refers to the amount of testing that is targeted and/or
achieved.
achieved
• Tests are either “white box” (internal structure) or “black box” (data input
range definitions) focused.
• An example of a white box coverage measure is the % of decision branch
options exercised. A common goal is to set a 100% target for a new unit
during unit testing, but not for a full system during qualification testing (it is
too hard to set up an environment that will make all of the options happen)
happen).
• A common black box coverage measure is 100% of boundary values
(minimum value(s), maximum value(s), just below the minimum(s), just
above the maximum(s))
maximum(s)).Test Planning and Tracking
• A robust model for testing starts with early test planning to assure that the environments are
available when needed,, the system
y is itself testable in an optimal
p manner,, and all resources are
present at the time that they are required.
• Some organizations start with a Master Test Plan that identifies how many levels of test will be
required, as well as the attributes that distinguish them.
• After the planning there is usually some kind of test design (documented or undocumented)
where there is refinement of the approaches and establishment of the coverage goals.
• Specific test cases (the input and corresponding expected output) are selected and then
executed. Actual results are recorded.
• Some organizations record all results, others record only the defects that are found.
• After each test level is executed, some assessment is made as to the success or failure of it.
• Retesting occurs as fixes are made.The breakdown of topics for the
S f
Software Testing
T iSoftware Testing Approaches
• Software Technical Reviews • Proof of correctness
– Walk-troughs • Simulation and Prototyping
– Inspections • Requirements tracing
– Audits
• S ft
Software Testing
T ti
– Levels of Testing
• Module Testing
• Integration Testing
• System Testing
• Regression Testing
– Testing Techniques
• Functional testing and analysis
• Structural testing and analysis
• Error-oriented testing and analysis
• Hybrid approaches
• Integration strategies
• Transaction flow analysis
• Stress analysis
• Failure analysis
• Concurrency analysis
• Performance analysisSome more definitions
Backk-end
ProgrammingISO 9001:2000 on Design Output and Validation
6.4.3 Design Output (S)
We document and present design output as requirements, measurements, calculations, analyses
and manufacturing documents.
Design output shall:
conform to design input requirements
contain or refer to acceptance criteria
identify
y design
g characteristics that are crucial for the p
product's safe and
proper function conform to industrialization and financial requirements
Design output documents are reviewed before release.
6.4.4 Validation (S)
Validation is performed to ensure that the product meets customer requirements and is fit
for its intended use.
Validation is usually performed on the finished product under defined operating conditions,
but may be necessary at earlier stages.
Multiple validations may be performed if there are different intended uses.
usesIntegration of Test related activities in the
E t d d/M difi d V
Extended/Modified V-Model
M d lIntegration, Verification and Validation
Processes
• Integration Process is to realize the system-of-interest by progressively
combining
bi i system
t elements
l t iin accordance
d with
ith the
th architectural
hit t l d design
i
requirements and the integration strategy. This process is successively
repeated in combination with the Verification and Validation Processes as
appropriate
• The purpose of the Verification Process is to confirm that all requirements
are fulfilled by the system elements and eventual system-of-interest, i.e. that
the system has been built right ( “you
you built it right.”).
right. ).
• The purpose of the Validation Process is to confirm that the realized
system complies with the stakeholder requirements. System validation is
subject
bj t tto approvall b
by th
the project
j t authority
th it and d key
k stakeholders.
t k h ld Thi
This
process is invoked during the Stakeholders Requirements Definition
Process to confirm that the requirements properly reflect the stakeholder
needs and to establish validation criteria (“you built the right thing.”).Guidelines for selection of g
good tester
• Open minded (curious )
• Persistent (not give up)
• Investigative (“suspicion”)
( suspicion )
• Dare to try
• Dare to ask
• Speak upSystem v.s. Software
EngineeringSystems Engineering
• Systems Engineering is a broad discipline
– Fundamental principles
– Techniques
– Specialty engineering
– Domains…
• Systems Engineering is a broadly applicable discipline
– Product systems
• Hardware
• Software
– Management systems
– Project management
– OrganizationsIndustry Needs
• Well-educated, well-rounded staff
• Experience in a process-based environment
• Managers and engineers who
– Understand process concepts
– Understand systems engineering principles
– Understand software principals
p p
– Work across disciplineIndustry Environment
• Rapidly
p y changing
g g technologygy
• Higher degree of specialization
• Global corporations
• Multiple standards
• Complex systems of systems
– Software
S ft is
i ubiquitous
bi it
– Everything is a software-intensive system
– Everything needs to talk to everything
• Integrated teams and processes
• “Fluid” business environmentSystem Engineering-
Engineering Basic definitions
• System An interacting combination of elements to accomplish a defined objective. These include
hardware,, software,, firmware,, people,
p p , information,, techniques,
q , facilities,, services,, and other support
pp
elements.
•
• Systems Engineering An interdisciplinary approach and means to enable the realization of
successful systems.
• Systems Engineer An engineer trained and experienced in the field of Systems Engineering.
• Systems Engineering Processes A logical, systematic set of processes selectively used to
accomplish Systems Engineering tasks.
• System Architecture The arrangement of elements and subsystems and the allocation of functions
to them to meet system requirements.
• The name of the discipline is termed “Systems Engineering” in that the practice of the discipline be
applied to
– many varied types systems (e.g. natural, physical, organic, people, hardware, etc.)
– operating with respect to its environment (open, closed, etc.)
• The term “System Engineering” is only used with respect to the act of engineering a specific system.Systems Engineering Process
• The basic engine for systems engineering is an iterative process
that expands on the common sense strategy of
• understanding a problem before you attempt to solve it,
• examining alternative solutions (do not jump to a point design), and
• verify that the selected solution is correct before continuing the definition
activities or proceeding to the next problem.
• The basic steps in the systems engineering process are:
• Define the System Objectives (User's
(User s Needs)
• Establish the Functionality (Functional Analysis)
• Establish Performance Requirements (Requirements Analysis)
• Evolve Designg and Operations
p Concepts
p ((Architecture Synthesis)
y )
• Select a Baseline (Through Cost/Benefit Trades)
• Verify the Baseline Meets Requirements (User's Needs)
• Iterate the Process Through Lower Level Trades (Decomposition)The Systems Engineering Process The linearity of the functions depicted does Not represent sequential performance of the tasks. Functions are performed in parallel and repetitively, as better information on the objective system becomes available in any task area.
Systems Engineering Process
O
Overview
i
Note: Acquisition & Supply process
Requirements consist of stakeholder
needs
d and d expectations,
t ti as opposed
d
to system technical requirements that
result from the System Design process.
(Source: ANSI/EIA-632)Project Processes Technical Processes Enterprise Processes Agreement Processes
ISO/IEC 15288 System and Software Engineering
System Life Cycle Processes
scope
• Provides a common, comprehensive
p & integrated
g framework for describing
g and
managing the full lifecycle of systems for:
• Small, medium and large organizations
• Internal self-imposed
self imposed use
use, as well as providing a basis for contractual
arrangements (i.e., any agreement)
• Defines a set of processes and associated terminology
• Can be applied at any level in the hierarchy of a system’s development
• Applies to man-made systems configured with one or more of the following:
• Hardware,
Hardware software
software, humans
humans, or processes
Source: Adapted from ISO/IEC JTCI/SC7/WG7 presentation on ISO/IEC 15288.Software Intensive Systems
• software-intensive systems —any system in which software
development and/or integration are dominant considerations—most
complex systems these days.
• This includes computer-based systems ranging from
– individual software applications,
– information systems,
– embedded systems
systems,
– product lines and product families and
– systems-of-systems.What is system
system-of-systems?
of systems?
• There is an emergent class of systems which are built from
components which are large scale systems in their own right
right.
• Prominent examples include
– integrated air defense networks
networks,
– the Internet,
– intelligent transport systems, and
– enterprise information networks.
• What factors set these systems-of- systems apart from large and
complex, but monolithic, systems?
• Does the process of architecting and/or developing these systems
differ in important ways from other types of systems?Network Topology
p gy
Service layer
Value add
Charging service Business
execution Processes
IMS and other standardized services
IMS Mess- Soft-
server aging switch
MRFP MGW
Multi access edge
Transport
Policy network
MSER control AGW
Wired Wireless
access Metro aggregation access
CESR
AN BS
e.g. Cable, POTS e.g. GSM, LTE,
GPON, xDSL HSPA, WCDMAMonolithic systems vs. systems-of-systems
principles
• Operational Independence of the Elements: If the system-of-systems is disassembled into its
p
component systems
y the component
p systems
y must be able to usefully
y operate
p independently.
p y The
system-of-systems is composed of systems which are independent and useful in their own right.
• Managerial Independence of the Elements: The component systems not only can operate
independently, they do operate independently. The component systems are separately acquired
and integrated but maintain a continuing operational existence independent of the system-of-
systems.
t
• Evolutionary Development: The system-of-systems does not appear fully formed. Its
development and existence is evolutionary with functions and purposes added, removed, and
modified with experience.
• Emergent Behavior: The system performs functions and carries out purposes that do not reside
in any component system. These behaviors are emergent properties of the entire system-of-
systems and cannot be localized to any component system. The principal purposes of the
systems-of-systems are fulfilled by these behaviors.
• Geographic Distribution: The geographic extent of the component systems is large. Large is a
nebulous and relative concept as communication capabilities increase, but at a minimum it means
that the components can readily exchange only information and not substantial quantities of mass
or energy.Systems Interoperability
• Interoperability is the ability of a collection of communicating entities to
• share specified information and
• operate on that information according to a shared operational semantics in order to
achieve a specified purpose in a given context.
• The essence of interoperation is that it is a relationship between systems,
where systems are entity in the above definitions.
• Interoperability relationships necessarily involve communication.
• For instance, the mere fact that two software systems are both installed on a single
machine does not imply that they are interoperable (though they might, of course, be
interoperable by some other relationship).
• Software interoperability relationships can be of many possible kinds and
degree, and can be brought about by many different implementation
mechanisms.
• some relationships between software systems as “tightly
tightly coupled,
coupled ” and other
relationships as “loose.”
• Implementation of an interoperability relationship by means of capabilities entirely within
the communicating entities (e.g., an agreement to share a common protocol), or the
relationship can be implemented by some other software entity (e.g., a request broker
y messages
that relays g between systems)
y )Boundaries of Systems and Systems of
S t
Systems
• “a system” may in fact be composed of several constituent systems, and this may recursively be true at several
levels.
• anything that at one level can be call a “system” may actually internally be a “system of systems,” and
• any “system of systems” may itself be part of some larger “system of {systems of systems},” and so forth.Properties of Evolution that Affect Interoperability
• Relative stability of the components. It is likely that different systems will evolve at different rates. However, if individual systems are
relatively stable, that is to say that there is some synchronization of changes among the systems, then there is an increased likelihood
that interoperability will be maintained.
• Existence of agreements regarding the evolution between systems affected by the changes. changes The more that owners of systems can
make local agreements with respect to change, the more likely local interoperability relationships will be preserved. This tends toward, but
does not guarantee, preservation of global interoperability. Where there are few or no local agreements concerning change in any one
system, every other system will be forced to react to change rather than harmonize with it.
• The number of interoperability relationships in the system of systems. The greater the aggregate number of relationships, the
harder it is for any one system to evolve without requiring evolution in many other systems. A large number of relationships requires
greater coordination than when there are fewer relationships.
• The number and complexity of interoperations affected by the change. Given that any system may be involved in more than one
interoperability relationship, it follows that the greater the number of relationships affected by a change, the harder it will be to maintain
global interoperability.
• Coordination of communication among systems. As systems evolve there is reasonable probability that the rates at which they
interoperate will vary. However, the more closely coordinated the communication rates in any local interoperability relationship, the more
effective
ff ti the
th relationship
l ti hi will
ill b
be. Th
Thus, coordinating
di ti rates
t off communication
i ti iis an aspectt off maintaining
i t i i iinteroperation.
t ti
• Commonality of purpose among component systems. Our definition of interoperability used the notion that systems interoperate in
order to achieve some purpose. Hence, the more closely each system is aligned with that purpose, the more willing the system’s owners
will be to accommodate changes. For example, if a service provided by system A is peripheral to the purpose of system B, then changes
in A that decrease local interoperability between A and B will tend to be ignored, and B will look for some other provider of the service.
Note that this is true regardless of the diversity of these components.
• The ability to assess trust in the face of change. A key aspect of interoperability is the need for one system to establish trust in
another. Indeed, not only must trust be established but also must be constantly re-evaluated. Such re-evaluation is particularly necessary
with every evolution of a trusted system.
• Adaptability of components. Given the notion that all systems are continually evolving and that the context for those systems is also
evolving, it follows that each system must be continually adapting to its new context. For example, if a system is adaptable with respect to
different communication rates, then it is likely that the interoperability relationships will be preserved even though the competition for
communication resources changes.Further Challenges
Literature
Literature
1
1. Barry Boehm: A View of 20th and 21th Century Software Engineering
http://sunset.usc.edu/csse/TECHRPTS/2006/2006_main.html
2. Guide to the Software Engineering Body of Knowledge
http://www.swebok.org/swebokcontents.html
3. Guide to the Systems Engineering Body of Knowledge -- G2SEBoK
http://g2sebok.incose.org/app/mss/menu/index.cfm
1. Wikipedia
http://en.wikipedia.orgCurrent Standards & Models For Systems Engineering (Back-up) STANDARDS Capability Models • EIA/ANSI 632 - 1998 • EIA-IS 731 – Interim Standard – Processes for Engineering systems 1998 • IEEE 1220 - 1998 Systems Engineering Capability Standard for Application and Model Management of the Systems • ISO/IEC 15504 FDIS - 2002 Engineering Process Systems Engineering – Process • ISO/IEC 15288 - 2002 Assessment Standard for Information Technology - • CMMIsm SE/SW/IPPD V1.1 – System Life Cycle Processes 2002 • ISO/IEC 19760 – PDTR - 2002 Capability Maturity Model Integration Guide for ISO/IEC 15288 - System Life – SE/SW/IPPD Cycle Processes • ECCS-E-10A - 1996 Space Engineering – Systems Engineering
SOME BASIC SYSTEMS ENGINEERING DEFINITIONS
•System
• a combination of interacting elements organized to achieve one or more stated purposes
• System-of-Interest
• the system whose life cycle is under consideration in the context of this International
Standard
• System Element
• a member of a set of elements that constitutes a system
NOTE: A system element is a discrete part of a system that can be implemented to fulfill
specified requirements
• Enabling System
• a system that complements a system-of-interest during its life cycle stages but does not
necessarily contribute directly to its function during operation
NOTE: For example, when a system-of-interest enters the production stage, an enabling
production system is required.
Source: ISO/IEC 15288.A Full Range of Software Engineering Trends 1
Evolvability,
reusability Enterprise integrity Integrated
g Systems
y
Object-oriented
Object oriented
And Software
Methods Human factors Engineering
Spaghetti Code
Global connectivity,
Stovepipes business practicality,
Process
Structured security threats,
bureaucracy
M th d
Methods St d d
Standards, massive systems
Agile Methods Lack of scalability of systems
Maturity Models
Noncompliance Hybrid Agile,
Waterfall Process
Plan-Driven
Methods
Large Projects, HCI, COTS, Concurrent, risk-
Weak Planning emergence driven process Rapid Collaborative
& Control change methods,
Disruptors:
Slow execution infrastructure,
Autonomy,
Process overhead
environments;
Bio-computing ?
Value-based
Software Factory Rapid composition
composition, Computational
p
methods’;
evaluation Plenty,
Enterprise
environments Multicultural
architecture;
mega systems
Many Defects System
building
Rapid change
by users
Formal Methods Lack of scalabilityy Rapid
Domain specific change
Scale
SW architecture,
Skill Shortfalls product line reuse
Service-orientated
Architecture, Model
Business 4GLs
Domain Lack
L k off Model driven
Model-driven clashes
l h
CAD/CAM, User
Understanding scalability development
Programming
Formality, Waterfall Productivity Concurrent Processes Agility; Value Global Integration
1970’s 1980’s 1990’s 2000’s 2010’sA Full Range of Software Engineering Trends 1
Evolvability,
reusability Enterprise integrity
Object-oriented
j
Methods Human factors
Process Stovepipes
Structured bureaucracy
Demand
growth
growth, Methods Standards,,
A il M
Agile Methods
th d
diversity Spaghetti Code Maturity Models
Waterfall Process Noncompliance Lack of
scalability
Large Projects
Projects, HCI, COTS
HCI COTS, Concurrent,
C t risk-
i k Rapid
Hardware Weak Planning & emergence driven process change
Engineering Software Craft Control
Methods -Code-and-fix Slow execution
-SAGE -Heroic
Software Process overhead
-Hardware debugging
Deficiency Software Factory Rapid composition,
Efficiency
y
evaluation
environments
Rapid change
Many Defects Formal Methods Lack of scalability Rapid change
Domain specific
Skill Shortfall SW architecture,
product line reuse
Business 4GLs
Domain Lack of
CAD/CAM, User
CAD/CAM
Understanding scalability
Programming
Hardware Engineering Crafting Formality, Waterfall Productivity Concurrent Processes
1950’s 1960’s 1970’s 1980’s 1990’sA Full Range of Software Engineering Trends 1
Evolvability,
reusability Enterprise integrity
Object-oriented
j
Methods Human factors
Process Stovepipes
Structured bureaucracy
Demand
growth
growth, Methods Standards,,
A il M
Agile Methods
th d
diversity Spaghetti Code Maturity Models
Waterfall Process Noncompliance Lack of
scalability
Large Projects
Projects, HCI, COTS
HCI COTS, Concurrent,
C t risk-
i k Rapid
Hardware Weak Planning & emergence driven process change
Engineering Software Craft Control
Methods -Code-and-fix Slow execution
-SAGE -Heroic
Software Process overhead
-Hardware debugging
Deficiency Software Factory Rapid composition,
Efficiency
y
evaluation
environments
Rapid change
Many Defects Formal Methods Lack of scalability Rapid change
Domain specific
Skill Shortfall SW architecture,
product line reuse
Business 4GLs
Domain Lack of
CAD/CAM, User
CAD/CAM
Understanding scalability
Programming
Hardware Engineering Crafting Formality, Waterfall Productivity Concurrent Processes
1950’s 1960’s 1970’s 1980’s 1990’sYou can also read
