Module CS6003ES Advanced Software Engineering

System Engineering
and
Software process
By
Dr. L. Ranathunga

System Engineering

1
 Introduction
• Software engineering occurs as a consequence of system
engineering
• System engineering may take on two different forms depending
on the application domain
– “Business process” engineering – conducted when the context of the work
focuses on a business enterprise
– Product engineering – conducted when the context of the work focuses on
a product that is to be built
• Both forms bring order to the development of computer-based
systems
• Both forms work to allocate a role for computer software and to
establish the links that tie software to other elements of a
computer-based system

What is a System?
• Definition of a System
(NASA Systems Engineering Handbook)
– A system is a set of interrelated components which
interact with one another in an organized fashion
toward a common purpose.

• System components may be quite diverse

– Persons and Organizations
– Software and Data
– Equipment and Hardware
– Facilities and Materials
– Services and Techniques

2
 What is Systems Engineering?
• Systems Engineering is an interdisciplinary
process that ensures that the customer's
needs are satisfied throughout a system's
entire life cycle.
• Systems engineering is an interdisciplinary
field of engineering focusing on how
complex engineering projects should be
designed and managed over their life cycles.

The “V” Life-Cycle Model

Mission Operation &

Continuous Quality Improvement Plan
Analysis Retirement

System Final
Validation Plan
Requirements System Test

Functional Verify
Verification Plan
Decomposition Subsystems
D
ec

n
tio
om

Physical Test
a

Test Plan
po

gr

Decomposition Components
te
si

In
tio
n

Build
Components

The design downstroke and the manufacturing upstroke

3
 Computer-based System
• Defined: A set or arrangement of elements that are organized to
accomplish some predefined goal by processing information
• The goal may be to support some business function or to develop
a product that can be sold to generate business revenue
• A computer-based system makes use of system elements
• Elements constituting one system may represent one macro
element of a still larger system
• Example
– A factory automation system may consist of a numerical control machine,
robots, and data entry devices; each can be its own system
– At the next lower hierarchical level, a manufacturing cell is its own
computer-based system that may integrate other macro elements
• The role of the system engineer is to define the elements of a
specific computer-based system in the context of the overall
hierarchy of systems

Computer-based System
(continued)
• A computer-based system makes use of the following four system
elements that combine in a variety of ways to transform
information
– Software: computer programs, data structures, and related work products
that serve to effect the logical method, procedure, or control that is required
– Hardware: electronic devices that provide computing capability,
interconnectivity devices that enable flow of data, and electromechanical
devices that provide external functions
– People: Users and operators of hardware and software
– Database: A large, organized collection of information that is accessed via
software and persists over time
• The uses of these elements are described in the following:
– Documentation: Descriptive information that portrays the use and
operation of the system
– Procedures: The steps that define the specific use of each system element
or the procedural context in which the system resides

4
 System Engineering Process
• The system engineering process begins with a world view; the business or product
domain is examined to ensure that the proper business or technology context can
be established
• The world view is refined to focus on a specific domain of interest
• Within a specific domain, the need for targeted system elements is analyzed
• Finally, the analysis, design, and construction of a targeted system element are
initiated
• At the world view level, a very broad context is established
• At the bottom level, detailed technical activities are conducted by the relevant
engineering discipline (e.g., software engineering)

"Always design a thing by considering it in its next larger context

– a chair in a room, a room in a house, a house in an
environment, and environment in a city plan"

System Engineering Hierarchy

World
View

Domain
View

Element
View

Component
View

5
 System Modeling
(at each view level)
• Defines the processes (e.g., domain classes in OO terminology)
that serve the needs of the view under consideration
• Represents the behavior of the processes and the assumptions
on which the behavior is based
• Explicitly defines intra-level and inter-level input that form
links between entities in the model
• Represents all linkages (including output) that will enable the
engineer to better understand the view
• May result in models that call for one of the following
– Completely automated solution
– A semi-automated solution
– A non-automated (i.e., manual) approach

Factors to Consider when

Constructing a Model
• Assumptions
– These reduce the number of possible variations, thus enabling a model to
reflect the problem in a reasonable manner
• Simplifications
– These enable the model to be created in a timely manner
• Limitations
– These help to bound the maximum and minimum values of the system
• Constraints
– These guide the manner in which the model is created and the approach
taken when the model is implemented
• Preferences
– These indicate the preferred solution for all data, functions, and behavior
– They are driven by customer requirements

Optimization of some of these factors may be mutually exclusive

6
 System Modeling with UML
• The Uniform Modeling Language (UML)
provides diagrams for analysis and design at both
the system and software levels
• Examples
– Use case diagrams
– Activity diagrams
– Class diagrams
– State diagrams

Business Process Engineering

• “Business process” engineering defines architectures that will
enable a business to use information effectively
• It involves the specification of the appropriate computing
architecture and the development of the software architecture for
the organization's computing resources
• Three different architectures must be analyzed and designed
within the context of business objectives and goals
– The data architecture provides a framework for the information needs of a
business (e.g., ERD)
– The application architecture encompasses those elements of a system that
transform objects within the data architecture for some business purpose
– The technology infrastructure provides the foundation for the data and
application architectures
• It includes the hardware and software that are used to support the applications
and data

7
 Product Engineering
• Product engineering translates the customer's desire for a set of defined
capabilities into a working product
• It achieves this goal by establishing a product architecture and a support
infrastructure
– Product architecture components consist of people, hardware, software, and data
– Support infrastructure includes the technology required to tie the components
together and the information to support the components
• Requirements engineering elicits the requirements from the customer and
allocates function and behavior to each of the four components
• System component engineering happens next as a set of concurrent activities
that address each of the components separately
– Each component takes a domain-specific view but maintains communication with
the other domains
– The actual activities of the engineering discipline takes on an element view
• Analysis modeling allocates requirements into function, data, and behavior
• Design modeling maps the analysis model into data/class, architectural,
interface, and component design

Product Engineering Hierarchy

Product Requirements
Engineering
System
Component
Human Hardware Software Database
Engineering Engineering Engineering Engineering Engineering

Data and
Analysis
Function Behavior Modeling
Classes

Design
Data/Class Architectural Interface Component
Design Design Design Design Modeling

Construction

8
 Software
Development Process

Engineering Process Model

• Specification: Set out the requirements and
constraints on the system.
• Design: Produce a model of the system.
• Manufacture: Build the system.
• Test: Check the system meets the required
specifications.
• Install: Deliver the system to the customer and
ensure it is operational.
• Maintain: Repair faults in the system as they
are discovered.

9
 The software process
• A structured set of activities required to develop a
software system.
• Many different software processes but all involve:
– Specification – defining what the system should do;
– Design and implementation – defining the organization of
the system and implementing the system;
– Validation – checking that it does what the customer wants;
– Evolution – changing the system in response to changing
customer needs.
• A software process model is an abstract representation
of a process. It presents a description of a process from
some particular perspective.

Software Engineering is Different

• Normally, specifications are incomplete.
• Very blurred distinction between
specification, design and manufacture.
• No physical realization of the system for
testing.
• Software does not wear out - maintenance
does not mean component replacement.

10
 Plan-driven and agile processes
• Plan-driven processes are processes where all of
the process activities are planned in advance and
progress is measured against this plan.
• In agile processes, planning is incremental and it
is easier to change the process to reflect changing
customer requirements.
• In practice, most practical processes include
elements of both plan-driven and agile
approaches.
• There are no right or wrong software processes.

Factors to Manage in Software

Development

11
 Software Quality Attributes
• Current Usefulness
– Quality attributes expected for the current system
by the user
– User friendliness, efficiency, usability (availability
of required applications/functions), security
• Potential Usefulness
– These qualities are concerned with the
improvements to the current system (Developers
point of view)
– Modifiability, portability (support for different
platforms), reusability

Software Life Cycle Models

• The goal of Software Engineering is to provide
models and processes that lead to the production
of well-documented maintainable software in a
manner that is predictable.
• “The period of time that starts when a software
product is conceived and ends when the product is
no longer available for use. The software life
cycle typically includes a requirement phase,
design phase, implementation phase, test phase,
installation and check out phase, operation and
maintenance phase, and sometimes retirement
phase”.

12
 What is a software process model?
• A simplified representation of a software process,
presented from a specific perspective
• Examples of process perspectives are
– Workflow perspective - sequence of activities
– Data-flow perspective - information flow
– Role/action perspective - who does what
• Generic process models
– Waterfall
– Evolutionary development
– Formal transformation
– Integration from reusable components

Software process models

• The waterfall model
– Plan-driven model. Separate and distinct phases of specification and
development.
• Incremental development
– Specification, development and validation are interleaved. May be plan-
driven or agile.
• Reuse-oriented software engineering
– The system is assembled from existing components. May be plan-driven
or agile.
• Formal Transformation
– A mathematical system model is formally transformed to an
implementation
• In practice, most large systems are developed using a process
that incorporates elements from all of these models.

13
 Waterfall Process Model

Development Plans
• Before commencing the project, following plans
should be developed
– Project Plan
– Quality Plan
– Test Plan
• Each stage will produce different documents which
have been discussed earlier
– SRS, Design spec, Source code, Test doc, Operation guides,
Maintenance plan

14
 Requirements Analysis and
Definition
The system's services, constraints and goals are established by
consultation with system users. They are then defined in a manner
that is understandable by both users and development staff.
This phase can be divided into:
v Feasibility study (often carried out separately)
v Requirements analysis
v Requirements definition
v Requirements specification

System and Software Design

System design: Partition the requirements to hardware
or software systems. Establishes an overall system
architecture
Software design: Represent the software system
functions in a form that can be transformed into one or
more executable programs
v Unified Modeling Language (UML)

15
 Programming and Unit Testing

The software design is realized as a set of

programs or program units. (Written
specifically, acquired from elsewhere, or
modified.)
Individual components are tested against
specifications.

Integration and System Testing

The individual program units are:

v integrated and tested as a complete system
v tested against the requirements as specified
v delivered to the client

16
 Operation and Maintenance
v Operation: The system is put into practical use.
v Maintenance: Errors and problems are identified
and fixed.
v Evolution: The system evolves over time as
requirements change, to add new functions or adapt
the technical environment.
v Phase out: The system is withdrawn from service.

Waterfall model phases

• There are separate identified phases in the
waterfall model:
– Requirements analysis and definition
– System and software design
– Implementation and unit testing
– Integration and system testing
– Operation and maintenance
• The main drawback of the waterfall model is the
difficulty of accommodating change after the
process is underway. In principle, a phase has to
be complete before moving onto the next phase.

17
 Waterfall model problems
• Inflexible partitioning of the project into distinct
stages makes it difficult to respond to changing
customer requirements.
– Therefore, this model is only appropriate when the
requirements are well-understood and changes will be
fairly limited during the design process.
– Few business systems have stable requirements.
• The waterfall model is mostly used for large systems
engineering projects where a system is developed at
several sites.
– In those circumstances, the plan-driven nature of the
waterfall model helps coordinate the work.

Discussion of the Waterfall Model

Advantages:
This method is good when requirements are clear and stable
v Process visibility
v Dependence on individuals
v Quality control
v Cost control
Disadvantages:
Each stage in the process reveals new understanding of the
previous stages, that requires the earlier stages to be revised.

18
Incremental Development Model

Incremental Time Frame

19
 Incremental development benefits
• The cost of accommodating changing customer requirements
is reduced.
– The amount of analysis and documentation that has to be redone is
much less than is required with the waterfall model.
• It is easier to get customer feedback on the development work
that has been done.
– Customers can comment on demonstrations of the software and see
how much has been implemented.
• More rapid delivery and deployment of useful software to the
customer is possible.
– Customers are able to use and gain value from the software earlier than
is possible with a waterfall process.

Incremental development problems

• The process is not visible.
– Managers need regular deliverables to measure
progress. If systems are developed quickly, it is not
cost-effective to produce documents that reflect
every version of the system.
• System structure tends to degrade as new
increments are added.
– Unless time and money is spent on refactoring to
improve the software, regular change tends to
corrupt its structure. Incorporating further software
changes becomes increasingly difficult and costly.

20
Reuse-oriented software engineering
• Based on systematic reuse where systems are
integrated from existing components or COTS
(Commercial-off-the-shelf) systems.
• Process stages
– Component analysis;
– Requirements modification;
– System design with reuse;
– Development and integration.
• Reuse is now the standard approach for
building many types of business system

Reuse-Oriented Software Engineering

(ROSE)

21
 Types of software component
• Web services that are developed according to
service standards and which are available for
remote invocation.
• Collections of objects that are developed as a
package to be integrated with a component
framework such as .NET or J2EE.
• Stand-alone software systems (COTS) that are
configured for use in a particular environment.

Process activities
• Real software processes are inter-leaved sequences
of technical, collaborative and managerial
activities with the overall goal of specifying,
designing, implementing and testing a software
system.
• The four basic process activities of specification,
development, validation and evolution are
organized differently in different development
processes. In the waterfall model, they are
organized in sequence, whereas in incremental
development they are inter-leaved.

22
 Software specification
• The process of establishing what services are required and
the constraints on the system’s operation and development.
• Requirements engineering process
– Feasibility study
• Is it technically and financially feasible to build the system?
– Requirements elicitation and analysis
• What do the system stakeholders require or expect from the
system?
– Requirements specification
• Defining the requirements in detail
– Requirements validation
• Checking the validity of the requirements

The requirements engineering process

23
 Software design and implementation
• The process of converting the system
specification into an executable system.
• Software design
– Design a software structure that realises the
specification;
• Implementation
– Translate this structure into an executable program;
• The activities of design and implementation are
closely related and may be inter-leaved.

A general model of the design process

24
 Design activities
• Architectural design, where you identify the
overall structure of the system, the principal
components (sometimes called sub-systems or
modules), their relationships and how they are
distributed.
• Interface design, where you define the interfaces
between system components.
• Component design, where you take each system
component and design how it will operate.
• Database design, where you design the system data
structures and how these are to be represented in a
database.

Software validation
• Verification and validation (V & V) is intended to
show that a system conforms to its specification
and meets the requirements of the system customer.
• Involves checking and review processes and
system testing.
• System testing involves executing the system with
test cases that are derived from the specification of
the real data to be processed by the system.
• Testing is the most commonly used V & V activity.

25
 Stages of testing

Testing stages
• Development or component testing
– Individual components are tested independently;
– Components may be functions or objects or coherent
groupings of these entities.
• System testing
– Testing of the system as a whole. Testing of
emergent properties is particularly important.
• Acceptance testing
– Testing with customer data to check that the system
meets the customer’s needs.

26
 Testing phases in a plan-driven
software process

Software evolution
• Software is inherently flexible and can change.
• As requirements change through changing
business circumstances, the software that supports
the business must also evolve and change.
• Although there has been a demarcation between
development and evolution (maintenance) this is
increasingly irrelevant as fewer and fewer systems
are completely new.

27
 System evolution

Requirement Changes
• During the software development process
requirements tends to be changed
• Various stages could be affected due to
changed requirements
• Make the process adaptability on requirement
changes is a challenge
• Cost increases when dealing with requirement
changes

28
 Coping with change
• Change is inevitable in all large software
projects.
– Business changes lead to new and changed system
requirements
– New technologies open up new possibilities for
improving implementations
– Changing platforms require application changes
• Change leads to rework so the costs of change
include both rework (e.g. re-analysing
requirements) as well as the costs of
implementing new functionality

Reducing the costs of rework

• Change avoidance, where the software process
includes activities that can anticipate possible
changes before significant rework is required.
– For example, a prototype system may be developed to
show some key features of the system to customers.
• Change tolerance, where the process is designed so
that changes can be accommodated at relatively low
cost.
– This normally involves some form of incremental
development. Proposed changes may be implemented in
increments that have not yet been developed. If this is
impossible, then only a single increment (a small part of
the system) may have be altered to incorporate the
change.

29
 Software prototyping
• A prototype is an initial version of a system
used to demonstrate concepts and try out design
options.
• A prototype can be used in:
– The requirements engineering process to help with
requirements elicitation and validation;
– In design processes to explore options and develop
a UI design;
– In the testing process to run back-to-back tests.

Benefits of prototyping
• Improved system usability.
• A closer match to users’ real needs.
• Improved design quality.
• Improved maintainability.
• Reduced development effort.
Other Considerations:
• The prototype may be a usable program but is not suitable
as the final software product.
• The code for the prototype is thrown away. However
experience gathered helps in developing the actual system.
• The development of a prototype might involve extra cost,
but overall cost might turnout to be lower than that of an
equivalent system developed using the waterfall model.

30
 The process of prototype
development

Prototype development
• May be based on rapid prototyping
languages or tools
• May involve leaving out functionality
– Prototype should focus on areas of the product
that are not well-understood;
– Error checking and recovery may not be
included in the prototype;
– Focus on functional rather than non-functional
requirements such as reliability and security

31
 Throw-away prototypes
• Prototypes should be discarded after
development as they are not a good basis for a
production system:
– It may be impossible to tune the system to meet
non-functional requirements;
– Prototypes are normally undocumented;
– The prototype structure is usually degraded through
rapid change;
– The prototype probably will not meet normal
organisational quality standards.

Generic Prototyping Cycle

Prototyping

32
 Rapid Application Development
(RAD)
• Developed by IBM in 1980
• User participation is essential
• Build a rapid prototype
• Give it to user for evaluation & obtain
feedback
• Prototype is refined

RAD

33
 RAD Features
• Not an appropriate model in the absence of user
participation.
• Reusable components are required to reduce
development time.
• Highly specialized & skilled developers are
required and such developers are not easily
available.

Incremental delivery

• Rather than deliver the system as a single delivery,

the development and delivery is broken down into
increments with each increment delivering part of
the required functionality.
• User requirements are prioritised and the highest
priority requirements are included in early
increments.
• Once the development of an increment is started, the
requirements are frozen though requirements for
later increments can continue to evolve.

34
 Incremental development and
delivery
• Incremental development
– Develop the system in increments and evaluate each
increment before proceeding to the development of the next
increment;
– Normal approach used in agile methods;
– Evaluation done by user/customer proxy.
• Incremental delivery
– Deploy an increment for use by end-users;
– More realistic evaluation about practical use of software;
– Difficult to implement for replacement systems as
increments have less functionality than the system being
replaced.

Incremental delivery

35
 Incremental delivery advantages
• Customer value can be delivered with each
increment so system functionality is
available earlier.
• Early increments act as a prototype to help
elicit requirements for later increments.
• Lower risk of overall project failure.
• The highest priority system services tend to
receive the most testing.

Incremental delivery problems

• Most systems require a set of basic facilities that are
used by different parts of the system.
– As requirements are not defined in detail until an increment
is to be implemented, it can be hard to identify common
facilities that are needed by all increments.
• The essence of iterative processes is that the
specification is developed in conjunction with the
software.
– However, this conflicts with the procurement model of
many organizations, where the complete system
specification is part of the system development contract.

36
 Boehm’s spiral model
• Models do not deal with uncertainly which is inherent to
software projects.
• Important software projects have failed because project risks
were neglected & nobody was prepared when something
unforeseen happened.
• Barry Boehm recognized this and tired to incorporate the
“project risk” factor into a life cycle model.
• The result is the spiral model, which was presented in 1986.
• Process is represented as a spiral rather than as a sequence of
activities with backtracking.
• Each loop in the spiral represents a phase in the process.
• No fixed phases such as specification or design - loops in the
spiral are chosen depending on what is required.
• Risks are explicitly assessed and resolved throughout the
process.

Boehm’s spiral model of the

software process

37
 Spiral model sectors
• The radial dimension of the model represents the cumulative costs.
Each path around the spiral is indicative of increased costs. The
angular dimension represents the progress made in completing each
cycle. Each loop of the spiral from X-axis clockwise through 360o
represents one phase. One phase is split roughly into four sectors of
major activities.
• Objective setting
– Specific objectives for the phase are identified.
• Risk assessment and reduction
– Risks are assessed and activities put in place to reduce the key risks.
• Development and validation
– A development model for the system is chosen which can be any of the
generic models.
• Planning
– The project is reviewed and the next phase of the spiral is planned.

Spiral model usage

• An important feature of the spiral model is that each phase is completed
with a review by the people concerned with the project (designers and
programmers)
• Spiral model has been very influential in helping people think about
iteration in software processes and introducing the risk-driven approach to
development.
• The advantage of this model is the wide range of options to accommodate
the good features of other life cycle models.
• It becomes equivalent to another life cycle model in appropriate
situations.
• In practice, however, the model is rarely used as published for practical
software development.
• The spiral model has some difficulties that need to be resolved before it
can be a universally applied life cycle model. These difficulties include
lack of explicit process guidance in determining objectives, constraints,
alternatives; relying on risk assessment expertise; and provides more
flexibility than required for many applications.

38
 The Rational Unified Process
• Developed by I.Jacobson, G.Booch and J.Rumbaugh.
• Software engineering process with the goal of producing good quality
maintainable software within specified time and budget.
• Developed through a series of fixed length mini projects called
iterations.
• Maintained and enhanced by Rational Software Corporation and thus
referred to as Rational Unified Process (RUP).
• A modern generic process derived from the work on the UML and
associated process.
• Brings together aspects of the all generic process models discussed
previously.
• Normally described from 3 perspectives
– A dynamic perspective that shows phases over time;
– A static perspective that shows process activities;
– A practical perspective that suggests good practice.

Phases in the Rational Unified Process

39
 RUP phases
• Inception
– Establish the business case for the system.
• Elaboration
– Develop an understanding of the problem domain and the system
architecture.
• How do we plan & design the project?
• What resources are required?
• What type of architecture may be suitable?
• Construction
– System design, programming and testing.
– the objectives are translated in design & architecture documents.
• Transition
– Deploy the system in its operating environment.
– involves many activities like delivering, training, supporting, and
maintaining the product.

RUP Iterations

40
 RUP iteration
• In-phase iteration
– Each phase is iterative with results developed
incrementally.
• Cross-phase iteration
– As shown by the loop in the RUP model, the
whole set of phases may be enacted
incrementally.

Static workflows in the Rational

Unified Process
Workflow Description
Business modelling The business processes are modelled using business
use cases.
Requirements Actors who interact with the system are identified and
use cases are developed to model the system
requirements.
Analysis and design A design model is created and documented using
architectural models, component models, object
models and sequence models.
Implementation The components in the system are implemented and
structured into implementation sub-systems.
Automatic code generation from design models helps
accelerate this process.

41
 Static workflows in the Rational
Unified Process
Workflow Description
Testing Testing is an iterative process that is carried out in conjunction
with implementation. System testing follows the completion of
the implementation.
Deployment A product release is created, distributed to users and installed in
their workplace.
Configuration and This supporting workflow managed changes to the system
change management
Project management This supporting workflow manages the system development

Environment This workflow is concerned with making appropriate software

tools available to the software development team.

Inception Phase
Inception phase has following objectives
• Gathering and analyzing the requirements.
• Planning and preparing a business case and
evaluating alternatives for risk management,
scheduling resources etc.
• Estimating the overall cost and schedule for the
project.
• Studying the feasibility and calculating
profitability of the project.

42
 Outcomes of Inception Phase

Elaboration Phase
Elaboration Phase has following objectives:
• Establishing architectural foundations.
• Design of use case model.
• Elaborating the process, infrastructure &
development environment.
• Selecting component.
• Demonstrating that architecture support the
vision at reasonable cost & within specified
time.

43
 Outcomes of Elaboration Phase

Construction Phase
Construction Phase has following objectives:
• Implementing the project.
• Minimizing development cost.
• Management and optimizing resources.
• Testing the product
• Assessing the product releases against
acceptance criteria

44
Outcomes of Construction Phase

Transition Phase
Transition Phase has following objectives:
• Starting of beta testing
• Analysis of user’s views.
• Training of users.
• Tuning activities including bug fixing and
enhancements for performance & usability
• Assessing the customer satisfaction.

45
 Outcomes of Transition Phase

Rational Unified Process (RUP)

92

46
 RUP good practice
• Develop software iteratively
– Plan increments based on customer priorities
and deliver highest priority increments first.
• Manage requirements
– Explicitly document customer requirements and
keep track of changes to these requirements.
• Use component-based architectures
– Organize the system architecture as a set of
reusable components.

RUP good practice

• Visually model software
– Use graphical UML models to present static
and dynamic views of the software.
• Verify software quality
– Ensure that the software meet’s organizational
quality standards.
• Control changes to software
– Manage software changes using a change
management system and configuration
management tools.

47
 Selection of Process Model
Selection of a model is based on:
• Requirements
• Development team
• Users
• Project type and associated risk

Based on Requirements

48
Based on Development Team

Based on Users’ Participation

49
 Based on Type of Project and
Associated Risk

Other Process Models

• WINWIN spiral model - defines negotiating activities and adds
anchor points to spiral model
• Concurrent process model—recognizes that different part of
the project will be at different places in the process
• Component-based development model—the process to apply
when reuse is a development objective
• Formal methods—the process to apply when a mathematical
specification is to be developed
• Cleanroom software engineering—emphasizes error detection
before testing

50
• Questions?

51