Trends in System/Software Engineering Discipline

Trends in System/Software Engineering Discipline Lorenco Damjanic Ericsson Nikola Tesla Z b Zagreb

  • Contents Contents
  • Telecom industry trends Telecom industry trends
  • Software Engineering – an overview F d t k bl d t
  • From code to workable product
  • System vs. Software Engineering
  • Further Challenges
  • Literature Literature

Telecom industry trends Telecom industry trends

Industry transformation / Convergence (from 1997) mobility Wireless/Cellular 3G/Wireless Internet Telecom Industry Intranet/Internet Wireline Wireless/Cellular PSTN PTN ISDN New Telecoms Industry Carrier class MMM Personal (Mobile) Multi-media WAP desk top computing PC-LAN PC-WAN The Converged Industry PC/Server s Carrier class WWW Multi media services main frames electronic publishing and Computer Industry entertainment Media Industry

Transformation to new communication architecture and business models Today’s Single-Play service networks TV business models Application Content Starting Triple-Play service per network Converged Multi-media services network ata/IP eless reline Cable T Multi-Media & Telephony Control (IMS with Mobility) Multi-Media Services TV IMS IMS IMS Services Services Services Da Wire Wi Connectivity Connectivity/ Packet Backbone Network Multi-Access Networks 3G IMS IMS IMS xDSL/GbE WiFi/Max Cable

Network Topology Service layer p gy IMS and other standardized services Charging Business Processes Value add service execution Transport MRFP MGW Softswitch IMS server Messaging Multi access edge Transport network Wireless access Policy control Wired access Metro aggregation CESR MSER AGW e.g.

Cable, POTS GPON, xDSL e.g. GSM, LTE, HSPA, WCDMA BS CESR AN

End-to-end transport Network News Internet IP Video Data Gaming Weather Voice Entertainment DSL Gigabit/s xDSL Hundreds of Megabit/s Tens of Gigabit/s Terabit/s Network Hundreds of Megabit/s Gigabit/s Gigabit/s Customer Access Metro Core Network management Gigabit/s

Evolution into an Multi Access All-IP Network SERVICE NETWORK ALL-IP NETWORK ALL-IP CORE NETWORK Internet “4G” ACCESS NETWORKS WLAN 3G Broadband 2G band PERSONAL AREA NETWORK Bluetooth

Bandwidths 1 Gbps EFM-Fiber 2007 24 Mbps 100 Mbps ADSL2plus EFM-VDSL2 Super 3G 4G 2012 2009 2006 2004 WiMax (LOS) 2005 8 Mbps ADSL p 3G Evolved p 2009 2005 2004 2005 WiMax (e/mobile) ~2007 64 kbps 512 kbps Dial-up ADSL WiMax (NLOS) 2G 3G 2005 2002 2000 ~2007 64 kbps Fixed Broadband Fixed-Wireless Broadband Mobile Broadband Dial up 2G 1990 1990 2005 Shared Access Shared Core

Coverage vs Bitrate Bitrate 14.2 Mbps 1.8 Mbps 7.2 Mbps p Coverage 1.8 Mbps Coverage Double Peak Rate does not correspond to double Capacity

Common LTE Evolution Alignment for WCDMA/HSPA TD-SCDMA(China) and Alignment for WCDMA/HSPA, TD SCDMA(China) and CDMA GSM GSM WCDMA WCDMA HSPA HSPA LTE LTE GSM Track (3GPP) DoCoMo Vodafone GSM GSM WCDMA WCDMA HSPA HSPA TD TD- -SCDMA SCDMA LTE LTE FDD and TDD FDD and TDD Vodafone China Mobile Verizon CDMA Track (3GPP2) CDMA One CDMA One EVDO Rev A EVDO Rev A Verizon WiMax Track (IEEE) (Fixed WiMax) (Fixed WiMax) Mobile WiMax Mobile WiMax Sprint Nextel ( ) ( ) 2001 2005 2008 2010 LTE the Global standard for Next Generation

Bitrates and Technologies OFDMA d t 4G OFDMA does not mean 4G Bitrate (Mbps) 300 LTE FDD and TDD ”4G” 3G 40 HSPA WiMax FDD TDD Technology FDD TDD CDMA OFDMA 4G relates to IMT Advanced, over 100 Mbps - not to OFDMA

Research Areas Service Layer Technologies Service layer Research Areas IMS and other standardized services Charging Business Processes Value add service execution Multimedia Technologies Transport MRFP MGW Softswitch IMS server Messaging Multi access edge IP Networks Technologies SW Research Transport network Wireless access Policy control Wired access Metro aggregation CESR MSER AGW Wireless Access Networks e.g.

Cable, POTS GPON, xDSL e.g. GSM, LTE, HSPA, WCDMA BS CESR AN Access Technologies & Signal Processing EMF Health and Safety Broadband and Transport Networks

Software Engineering 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: 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, that the quality of software was generally unacceptably low and that deadlines and cost limits were not being met.

  • Software system Software system
  • A software system is a system based on software forming part of a compute system (a combination of hardware and software) 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 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
  • 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).

p 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 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 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 computerFault-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 Software Reliability Hi h il bilit ti th t
  • High availability is a system design protocol and associated implementation that ensures a certain absolute degree of operational continuity during a given measurement period. A il bilit f t th bilit f th it t th t h th
  • 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. Th t d ti il bl
  • 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 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 p 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 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 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 Computer science
  • Management
  • Mathematics
  • Project management
  • Quality management
  • Software ergonomics
  • Systems engineering
  • 30 year later 30 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 it i ti d traditional engineering in many respect has its own unique properties and problems.

Generic Software Life Cycle Cost Generic Software Life Cycle Cost

Evolution of ISO/IEC 12207 Standard (System and software engineering- (System and software engineering Software life cycle processes)

  • Standards Relationship
  • ISO 9001:2000 Quality management systems 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- (System and software engineering Software life cycle processes)

The major engineering process steps for d l i ft developing software .

  • Software Engineering Development M th d Methods
  • Some software development methods: Waterfall model – Waterfall model – Spiral model – Model driven development – User experience Top down and bottom up design – Top-down and bottom-up design – Chaos model – Evolutionary prototyping – Prototyping ICONIX Process (UML based object modeling with use cases) – ICONIX Process (UML-based object modeling with use cases) – Unified Process – V-model – Extreme Programming Software Development Rhythms – Software Development Rhythms – Specification and Description Language – Incremental funding methodology – Verification and Validation (software)

A Full Range of Software Engineering Process Trends 1 Structured Methods Demand growth Waterfall Process Spaghetti Code Large Projects growth, diversity Hardware Engineering Methods -SAGE -Hardware Efficiency Software Craft -Code-and-fix -Heroic debugging Software Deficiency Large Projects, Weak Planning & Control Process overhead y Formal Methods Many Defects Domain Skill Shortfall Understanding Hardware Engineering 1950’s Crafting 1960’s Formality, Waterfall 1970’s

The SAGA Software Development Process (1956) e S G So op e t ocess ( 956) Operational Plan Machine Specification Operational Specification Program Specification Coding Specification Coding Parameter Testing (Specification) Assembly Testing Assembly Testing (Specification) Shakedown System Evaluation

A Full Range of Software Engineering Process Trends 1 Structured Methods Demand growth Waterfall Process Spaghetti Code Large Projects growth, diversity Hardware Engineering Methods -SAGE -Hardware Efficiency Software Craft -Code-and-fix -Heroic debugging Software Deficiency Large Projects, Weak Planning & Control Process overhead y Formal Methods Many Defects Domain Skill Shortfall Understanding Hardware Engineering 1950’s Crafting 1960’s Formality, Waterfall 1970’s

The Royce Waterfall Model (1970) e oyce ate a ode ( 9 0) System R i t Requirements Software Requirements Preliminary Program Program Design Analysis Program Program Design Coding Preliminary Design Analysis Testing Operation Program Design Coding Testing Usage

Object oriented Enterprise integrity Evolvability, reusability Integrated Systems A Full Range of Software Engineering Process Trends 1 Structured M th d Object-oriented Methods St d d Stovepipes g y And Software Engineering Human factors Spaghetti Code Global connectivity, business practicality, security threats, massive systems Process bureaucracy Methods Waterfall Process Standards, Maturity Models Agile Methods Noncompliance Hybrid Agile, Plan-Driven Methods Lack of scalability massive systems of systems Disruptors: Autonomy, Bio-computing Computational Software Factory Concurrent, riskdriven process Rapid composition HCI, COTS, emergence Slow execution Process overhead Rapid change Collaborative methods, infrastructure, environments; Value-based methods’; Large Projects, Weak Planning & Control ?

p Plenty, Multicultural mega systems Software Factory Formal Methods Rapid composition, evaluation environments Lack of scalability Rapid change Rapid methods’; Enterprise architecture; System building by users Many Defects Formal Methods Business 4GLs Domain Domain specific SW architecture, product line reuse y L k f Rapid change Service-orientated Architecture, Model driven Scale Model l h Skill Shortfalls CAD/CAM, User Programming Domain Understanding Lack of scalability Formality, Waterfall 1970’s Productivity 1980’s Concurrent Processes 1990’s Model-driven development Agility; Value 2000’s Global Integration 2010’s clashes

Risk Driven Spiral Software Engineering Model Risk Driven Spiral Software Engineering Model

Rational Unified Process Rational Unified 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. Cleanroom Software Engineering Process y p p , 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 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 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 if di bl f il li 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, 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 is a conceptual framework for software development that promotes development iterations throughout the life cycle of the project Agile Software Development 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 methods emphasize face-to-face communication over written documents Most agile teams are located in a single open 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.

S hi d h A il M if 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
  • Continuous attention to technical excellence and good design
  • Simplicity
  • Self-organizing teams
  • Regular adaptation to changing circumstances
  • Software Intensive Systems 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 – embedded systems, – product lines and product families and – systems-of-systems.

From a code to workable product

  • Vasa Testing Vasa Testing
  • In the inquiries after the Vasa disaster it was revealed that a stability test 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 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 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 t bilit t t "If l Hi M j t stability test was "If only His Majesty were at home!" After that he let the Vasa make her maiden voyage.
  • What is Software Testing? 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 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 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: levels (from ISO 12207) for new development are:
  • Each software unit and database
  • Integrated units and components T t f h ft i t
  • 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 requirements
  • System qualification testing for system requirements
  • Type of software testing Type 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) 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)) above the maximum(s)).
  • Test Planning and Tracking 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 , y p , 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 T i Software Testing

  • Software Testing Approaches Software Testing Approaches
  • Software Technical Reviews Walk-troughs
  • Proof of correctness
  • Simulation and Prototyping – Walk-troughs – Inspections – Audits S ft T ti
  • Simulation and Prototyping
  • Requirements tracing
  • Software Testing – Levels of Testing
  • Module Testing
  • Integration Testing
  • System Testing
  • Regression Testing Regression Testing – Testing Techniques
  • Functional testing and analysis
  • Structural testing and analysis
  • Error-oriented testing and analysis
  • Hybrid approaches Integration strategies
  • Integration strategies
  • Transaction flow analysis
  • Stress analysis
  • Failure analysis
  • Concurrency analysis
  • Performance analysis

Some more definitions Some more definitions Back k -end Programming

ISO 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 y g p 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 Multiple validations may be performed if there are different intended uses.

Integration of Test related activities in the E t d d/M difi Extended/Modified V-Model

  • Integration, Verification and Validation P Processes
  • Integration Process is to realize the system-of-interest by progressively bi ith th hit t l d i 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 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 bj t t l b th j t th it ld Thi 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 g
  • Open minded (curious ) Open minded (curious )
  • Persistent (not give up)
  • Investigative (“suspicion”) Investigative ( suspicion )
  • Dare to try
  • Dare to ask
  • Dare to ask
  • Speak up

System v.s. Software Engineering

  • Systems Engineering Systems Engineering
  • Systems Engineering is a broad discipline Fundamental principles – Fundamental principles – Techniques – Specialty engineering – Domains...
  • Systems Engineering is a broadly applicable discipline – Product systems
  • Hardware
  • Software
  • Software – Management systems – Project management – Organizations
  • Industry Needs Industry Needs
  • Well-educated, well-rounded staff
  • Experience in a process-based environment
  • Managers and engineers who
  • Managers and engineers who – Understand process concepts – Understand systems engineering principles – Understand software principals p p – Work across discipline
  • Industry Environment Industry Environment
  • Rapidly changing technology p y g g gy
  • Higher degree of specialization
  • Global corporations
  • Multiple standards
  • Complex systems of systems S ft i bi it – Software is ubiquitous – Everything is a software-intensive system – Everything needs to talk to everything
  • Integrated teams and processes
  • “Fluid” business environment
  • System EngineeringBasic definitions System 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 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 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 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)
  • 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 Systems Engineering Process The linearity of the functions depicted does Not represent sequential performance 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 i Overview Note: Acquisition & Supply process Requirements consist of stakeholder d d t ti d needs and expectations, as opposed to system technical requirements that result from the System Design process.

(Source: ANSI/EIA-632)

Project Processes Technical Processes Processes Enterprise Processes Agreement Processes

  • ISO/IEC 15288 System and Software Engineering System Life Cycle Processes
  • Provides a common, comprehensive & integrated framework for describing and scope p g g managing the full lifecycle of systems for:
  • Small, medium and large organizations
  • Internal self imposed use as well as providing a basis for contractual
  • 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 Hardware, software, humans, or processes Source: Adapted from ISO/IEC JTCI/SC7/WG7 presentation on ISO/IEC 15288.
  • Software Intensive Systems 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 – embedded systems, – product lines and product families and – systems-of-systems.
  • What is system-of-systems? 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 components which are large scale systems in their own right.
  • Prominent examples include – integrated air defense networks integrated air defense networks, – the Internet, – intelligent transport systems, and – enterprise information networks.
  • What factors set these systems-ofsystems 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 p gy IMS and other standardized services Charging Business Processes Value add service execution Transport MRFP MGW Softswitch IMS server Messaging Multi access edge Transport network Wireless access Policy control Wired access Metro aggregation CESR MSER AGW e.g. Cable, POTS GPON, xDSL e.g. GSM, LTE, HSPA, WCDMA BS CESR AN

  • Monolithic 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-oft 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-ofsystems 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 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
  • 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) y g 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 The more that owners of systems can 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 ff ti th l ti hi ill b Th di ti t f i ti ti 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 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

Literature 1 Barry Boehm: A View of 20th and 21th Century Software Engineering 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.org

  • Current Standards & Models For Systems Engineering (Back-up) STANDARDS
  • EIA/ANSI 632 - 1998 Capability Models
  • EIA-IS 731 – Interim Standard – Processes for Engineering systems
  • IEEE 1220 - 1998 Standard for Application and Management of the Systems 1998 Systems Engineering Capability Model
  • ISO/IEC 15504 FDIS 2002 Management of the Systems Engineering Process
  • ISO/IEC 15288 - 2002 Standard for Information Technology -
  • ISO/IEC 15504 FDIS - 2002 Systems Engineering – Process Assessment
  • CMMIsm SE/SW/IPPD V1.1 – System Life Cycle Processes
  • ISO/IEC 19760 – PDTR - 2002 Guide for ISO/IEC 15288 - System Life Cycle Processes 2002 Capability Maturity Model Integration – 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 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 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.

Object oriented Enterprise integrity Evolvability, reusability Integrated Systems A Full Range of Software Engineering Trends 1 Structured M th d Object-oriented Methods St d d Stovepipes g y And Software Engineering Human factors Spaghetti Code Global connectivity, business practicality, security threats, massive systems Process bureaucracy Methods Waterfall Process Standards, Maturity Models Agile Methods Noncompliance Hybrid Agile, Plan-Driven Methods Lack of scalability massive systems of systems Disruptors: Autonomy, Bio-computing Computational Software Factory Concurrent, riskdriven process Rapid composition HCI, COTS, emergence Slow execution Process overhead Rapid change Collaborative methods, infrastructure, environments; Value-based methods’; Large Projects, Weak Planning & Control ?

p Plenty, Multicultural mega systems Software Factory Formal Methods Rapid composition, evaluation environments Lack of scalability Rapid change Rapid methods’; Enterprise architecture; System building by users Many Defects Formal Methods Business 4GLs Domain Domain specific SW architecture, product line reuse y L k f Rapid change Service-orientated Architecture, Model driven Scale Model l h Skill Shortfalls CAD/CAM, User Programming Domain Understanding Lack of scalability Formality, Waterfall 1970’s Productivity 1980’s Concurrent Processes 1990’s Model-driven development Agility; Value 2000’s Global Integration 2010’s clashes

Object-oriented Enterprise integrity Evolvability, reusability A Full Range of Software Engineering Trends 1 Structured Methods j Methods Standards, Demand growth A il M th d Stovepipes Human factors Process bureaucracy Waterfall Process , Maturity Models Spaghetti Code Large Projects growth, diversity C t i k Agile Methods HCI COTS Noncompliance Lack of scalability Hardware Engineering Methods -SAGE -Hardware Efficiency Software Craft -Code-and-fix -Heroic debugging Software Factory Software Deficiency Large Projects, Weak Planning & Control Concurrent, riskdriven process Rapid composition, HCI, COTS, emergence Rapid change Slow execution Process overhead y Formal Methods Many Defects evaluation environments Lack of scalability Rapid change Rapid change Business 4GLs CAD/CAM User Domain Skill Shortfall Domain specific SW architecture, product line reuse Lack of CAD/CAM, User Programming Understanding Lack of scalability Hardware Engineering 1950’s Crafting 1960’s Formality, Waterfall 1970’s Productivity 1980’s Concurrent Processes 1990’s

Object-oriented Enterprise integrity Evolvability, reusability A Full Range of Software Engineering Trends 1 Structured Methods j Methods Standards, Demand growth A il M th d Stovepipes Human factors Process bureaucracy Waterfall Process , Maturity Models Spaghetti Code Large Projects growth, diversity C t i k Agile Methods HCI COTS Noncompliance Lack of scalability Hardware Engineering Methods -SAGE -Hardware Efficiency Software Craft -Code-and-fix -Heroic debugging Software Factory Software Deficiency Large Projects, Weak Planning & Control Concurrent, riskdriven process Rapid composition, HCI, COTS, emergence Rapid change Slow execution Process overhead y Formal Methods Many Defects evaluation environments Lack of scalability Rapid change Rapid change Business 4GLs CAD/CAM User Domain Skill Shortfall Domain specific SW architecture, product line reuse Lack of CAD/CAM, User Programming Understanding Lack of scalability Hardware Engineering 1950’s Crafting 1960’s Formality, Waterfall 1970’s Productivity 1980’s Concurrent Processes 1990’s

You can also read
Next part ... Cancel