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
Zagreb
FER: Informacija, logika i jezici
Lipanj 2009.Contents • Telecom industry trends • Software Engineering – an overview • From code to workable product • System vs. Software Engineering • Further Challenges • Literature
Telecom industry trends
Industry transformation / Convergence
(from 1997)
mobility 3G/Wireless Internet
Wireless/Cellular
MMM
Wireline ISDN WAP
New Personal
PTN
Telecoms
Telecom Industry (Mobile)
PSTN
Industry Intranet/Internet
Carrier class Multi-media
PC-WAN WWW
PC-LAN services
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
Cable TV
Multi-Media Services
Wireline
Data/IP
Services Services Services
Wireless
Multi-Media & Telephony
TV
Control (IMS with Mobility)
IMS IMS IMS
xDSL/GbE Cable Connectivity/
3G WiFi/Max Packet Backbone Network
Connectivity
Multi-Access NetworksFull Service Broadband
Transformation
Broadband Access
Multi Access Edge
Metro transport
IPTV
Telephony Evolution
ManagementTelephony Evolution
Fixed and mobile exhibits different transformation
paths
2000 Million subs
Mobile
Mobile
80-300 Million subs
Softswitching (mobile)
CS Mobile NB
Richer
Communication
Converged
Multimedia
Telephony
(MMTel)
Broadband
Fixed
VoIP
CS Wireline NB 400 Million subs
(fixed)
PSTN
Modernization
200-400 Million subs
Estimated total acc. segment sizes 2008-2015Vision: Enhanced consumer convenience
IMS - A well established
platform for fixed and
mobile service delivery
Home
Network
Content and communication services on the Residential gateway as means to deliver
best suitable device or combination of devices managed services to the home. Eco system
at any point in time, anywhere for Content and Service providersEnd-to-end transport Network
News
Internet
Data Weather
IP
Video Gaming
Entertainment Voice
xDSL
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 Core“IP”fication of Networks
A growing trend for telecom operators
IP RAN
LTE
“IP”fication of
wireless networks
IPTV
“IP”fication of
IP optical networks
DSLAMs GMPLS
“IP”fication of video
VOIP
“IP”fication of
wireline access
“IP”fication of voice
IP in the InternetBandwidths
1 Gbps EFM-Fiber
2007
100 Mbps EFM-VDSL2 4G
2006 2012
24 Mbps ADSL2plus WiMax (LOS) Super 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 2G
1990 2005 1990
Fixed Fixed-Wireless Mobile
Broadband Broadband Broadband
Shared Access
Shared CoreCoverage vs Bitrate
Bitrate
14.2 Mbps
7.2 Mbps
1.8 Mbps
Coverage
Double Peak Rate does not correspond to double CapacityBitrates and Technologies
OFDMA does not 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 OFDMAHSPA and LTE capacity
evolution
Downlink spectrum efficiency
2
Bit/Hz
1
0
2006 2007 2008 2009
HSPA R6 HSPA R6 HSPA R7 HSPA & LTE R8
GRAKE/Eq. GRAKE/Eq. 2x2 MIMO 64QAM&MIMO
Rx Diversity
Simulated under normal radio conditions
Twice the capacity with HSPA evolution and LTECommon LTE Evolution
Alignment for WCDMA/HSPA, TD-SCDMA (China) and CDMA
DoCoMo
Vodafone
GSM Track (3GPP) AT&T
GSM WCDMA HSPA
Telstra
LTE China Mobile
TD-SCDMA FDD and TDD
TeliaSonera
NGMN
Verizon Others....
China Telecom /”Unicom”
CDMA Track (3GPP2) KDDI (?)
CDMA One EVDO Rev A
WiMax Track (IEEE) Clearwire
(Fixed WiMax) Mobile WiMax
2001 2005 2008 2010
LTE the Global standard for Next Generation (4G)LTE and WiMAX Performance
Urban macro network scenario (500m site-site)
• LTE TDD performance similar to LTE FDD performance
• LTE TDD outperforms WiMAX TDD
Downlink
Avg cell tp [bps/Hz/cell]
Difference in
1.5 1.73 1.70 overhead,
power control,
Reuse 1
1 scheduling,
1.06 MIMO scheme
0.5 Reduced
Efficiency
in Reuse 3
0
LTE FDD LTE TDD WiMAX TDD
LTE TDD is industry mainstream for un-paired spectrumFrequency Reuse 1 and 3
Frequency Reuse 1 Frequency Reuse 3
• All frequencies used in all • One third of frequencies
cells used in each cell
• Full bandwidth available • Limited bandwidth available
• High interference • Reduced interference
• No planning • Requires planning
f fSAE and LTE
CS networks
2G Core Network
Circuit Core
3G
User mgmt IMS domain
LTE
Packet core
Non-3GPP ”IP networks”
Teminology
LTE Long Term Evolution (also known as eUTRAN)
SAE System Architecture Evolution (3GPP study item)Evolution 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
BluetoothService 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 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,
– product lines and product families and
– systems-of-systems.Software 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
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).
• 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.
• 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 and related devices.
• 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 with a different operating system).
• 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, a non-real-time system is one for which there is no 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
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-
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 availability is a system design protocol and associated implementation that
ensures a certain absolute degree of operational continuity during a given
measurement period.
• Availability refers to the ability of the user community to access the system, whether
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.
• The term downtime is used to refer to periods when a system is unavailable.
• 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 process
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
traditional engineering in many respect has its own unique properties and
problems.Generic Software Life Cycle Cost
Evolution of ISO/IEC 12207 Standard
(System and software 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-
Software life cycle processes)The major engineering process steps for
developing software .Software Engineering Development
Methods
• Some software development methods:
– Waterfall model
– Spiral model
– Model driven development
– User experience
– Top-down and bottom-up design
– Chaos model
– Evolutionary prototyping
– Prototyping
– ICONIX Process (UML-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, Methods
diversity Spaghetti Code
Waterfall Process
Large Projects,
Hardware Weak Planning &
Engineering Software Craft Control
Methods -Code-and-fix
-SAGE -Heroic
Software Process overhead
-Hardware debugging
Deficiency
Efficiency
Many Defects Formal Methods
Skill Shortfall
Domain
Understanding
Hardware Engineering Crafting Formality, Waterfall
1950’s 1960’s 1970’sThe SAGA Software Development Process (1956)
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, Methods
diversity Spaghetti Code
Waterfall Process
Large Projects,
Hardware Weak Planning &
Engineering Software Craft Control
Methods -Code-and-fix
-SAGE -Heroic
Software Process overhead
-Hardware debugging
Deficiency
Efficiency
Many Defects Formal Methods
Skill Shortfall
Domain
Understanding
Hardware Engineering Crafting Formality, Waterfall
1950’s 1960’s 1970’sThe Royce Waterfall Model (1970)
System
Requirements
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 Systems
Object-oriented
And Software
Methods Human factors Engineering
Spaghetti Code
Global connectivity,
Stovepipes business practicality,
Process
Structured security threats,
bureaucracy
Methods 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, Computational
methods’;
evaluation Plenty,
Enterprise
environments Multicultural
architecture;
mega systems
Many Defects System
building
Rapid change
by users
Formal Methods Lack of scalability Rapid
Domain specific change
Scale
SW architecture,
Skill Shortfalls product line reuse
Service-orientated
Architecture, Model
Business 4GLs
Domain Lack of Model-driven clashes
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 focus of the Cleanroom process is on defect prevention, 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. 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.
•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 that the development process is proceeding acceptably. A failure to meet quality standards results in the
cessation of testing for the current increment, and a return to the design phase.
•Statistically sound testing
Software testing in the Cleanroom process is carried out as a statistical experiment. Based on the formal specification,
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-cycle of the 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 Software Development • Agile methods emphasize face-to-face communication over written 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.
Agile Software Development
Some of the principles behind the Agile Manifesto are:
•Customer satisfaction by rapid, continuous delivery of useful software
•Working software is delivered frequently (weeks rather than months)
•Working software is the principal measure of progress
•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,
– 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's 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.
• Present was Admiral Klas Fleming,
one of the most influential men in the
Navy. His only comment to the failed
stability test was "If only His Majesty
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” 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
• Tests for each software requirement
• 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.
• 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).
• 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)).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 is itself testable in an optimal 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
Software TestingSoftware Testing Approaches
• Software Technical Reviews • Proof of correctness
– Walk-troughs • Simulation and Prototyping
– Inspections • Requirements tracing
– Audits
• Software Testing
– 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
Back-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 design characteristics that are crucial for the 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.Integration of Test related activities in the
Extended/Modified V-ModelIntegration, Verification and Validation
Processes
• Integration Process is to realize the system-of-interest by progressively
combining system elements in accordance with the architectural design
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 built it right.”).
• The purpose of the Validation Process is to confirm that the realized
system complies with the stakeholder requirements. System validation is
subject to approval by the project authority and key stakeholders. 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 good tester • Open minded (curious ) • Persistent (not give up) • Investigative (“suspicion”) • Dare to try • Dare to ask • Speak up
System 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 – Work across discipline
Industry Environment
• Rapidly changing technology
• Higher degree of specialization
• Global corporations
• Multiple standards
• Complex systems of systems
– Software is ubiquitous
– Everything is a software-intensive system
– Everything needs to talk to everything
• Integrated teams and processes
• “Fluid” business environmentSystem Engineering- Basic definitions
• System An interacting combination of elements to accomplish a defined objective. These include
hardware, software, firmware, people, information, techniques, facilities, services, and other support
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 Needs)
• Establish the Functionality (Functional Analysis)
• Establish Performance Requirements (Requirements Analysis)
• Evolve Design and Operations Concepts (Architecture Synthesis)
• 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
Overview
Note: Acquisition & Supply process
Requirements consist of stakeholder
needs and expectations, as opposed
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 & integrated framework for describing and
managing the full lifecycle of systems for:
• Small, medium and large organizations
• Internal self-imposed 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, software, humans, or processes
Source: Adapted from ISO/IEC JTCI/SC7/WG7 presentation on ISO/IEC 15288.What is system-of-systems? • There is an emergent class of systems which are built from components which are large scale systems in their own right. • Prominent examples include – integrated air defense 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
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
component systems the component systems must be able to usefully operate independently. 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.
• 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 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
that relays messages between systems)Boundaries of Systems and Systems of
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. 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 the relationship will be. Thus, coordinating rates of communication is an aspect of maintaining interoperation.
• 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
Globalization
• The global connectivity provided by:
• the Internet and
• low-cost, high-bandwidth global communications
provides
• major economies of scale and
• network economies
that drive:
• an organization’s product and
• process strategies.
• Location-independent distribution and mobility services create:
• rich new bases for synergetic collaboration and
• challenges in synchronizing activities.
• Differential salaries provide opportunities for:
• cost savings through global outsourcing,
although lack of careful preparation can easily turn the savings into overruns.
• The ability to develop across multiple time zones creates the prospect of:
• very rapid development via three-shift operations,
although there are significant challenges in:
• management visibility and control,
• communication semantics, and
• building shared values and trust.Globalization - side effects
• Competition will be increasingly multinational, with
– outsourcees trying to master the skills necessary to become outsourcers,
as their internal competition for talent drives salaries upward (e.g. India, China, and Russia).
• Pressure on creation of a homogeneous global culture.
• Pressures for countries to preserve their national cultures and values.
• The nature of products and processes would also evolve toward
– the complementarity of skills
in such areas as culture-matching and localization
• Some key culture-matching dimensions are:
• power distance,
• individualism/collectivism,
• masculinity/femininity,
• uncertainty avoidance, and
• long-term time orientation.
• These often explain low software product and process adoption rates across culturesGlobal Collaborative Processes
Challenges
• A lot of work needs to be done to establish robust success patterns
for global collaborative processes.
• Key challenges include:
• cross-cultural bridging;
• establishment of common shared vision and trust;
• contracting mechanisms and incentives;
• handovers and change synchronization in multi-timezone
development; and
• culture-sensitive collaboration-oriented groupware.
• Most software packages are oriented around individual use
just determining how best to support groups will take a good deal of
research and experimentation.Computational Plenty
• Assuming that Moore’s Law holds, another 20 years of doubling computing
element performance every 18 months will lead to a performance improvement
factor of
220/1.5 = 213.33 = 10,000 by 2025
.
Similar factors will apply to the size and power consumption of the competing
elements.
• The computational plenty will spawn:
• new types of platforms (smart dust, smart paint, smart materials,
nanotechnology, micro electrical mechanical
systems: MEMS), and
• new types of applications (sensor networks, conformable or adaptive
materials, human prosthetics).Computational Plenty vs. Software Engineering
• The computational plenty will enable new and more powerful software engineering approaches
such as:
• new and more powerful self-monitoring software,
• computing via on-chip co-processors for assertion checking,
• trend analysis,
• intrusion detection, or
• verifying proof-carrying code.
• It will enable higher levels of abstraction, such as:
• pattern-oriented programming,
• multi-aspect oriented programming,
• domain-oriented visual component assembly, and
• programming by example with expert feedback on missing portion
• It will also enable more powerful software and systems engineering tools that provide feedback to
developers based on:
• domain knowledge,
• programming knowledge,
• systems engineering knowledge, or
• management knowledge.
• It will support
• show-and-tell documentation,
• much more powerful system query and
• data mining techniques.
• realistic virtual game-oriented systems,
• software engineering education and training.Literature
Literature
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.orgYou can also read
