Stan Kurkovsky
Software Engineering Software Engineering
Software Processes Software Processes
Based on Software Engineering, 7thEdition by Ian Sommerville
Objectives Objectives
• • To introduce software process models To introduce software process models
•
• To describe three generic process models and when they may be us To describe three generic process models and when they may be used ed
• • To describe outline process models for requirements engineering, To describe outline process models for requirements engineering, software development, testing and evolution
software development, testing and evolution
•
• To explain the Rational Unified Process model To explain the Rational Unified Process model
•
• To introduce CASE technology to support software process activit To introduce CASE technology to support software process activities ies
Stan Kurkovsky
The software process and process models The software process and process models
• • A structured set of activities required to develop a A structured set of activities required to develop a software system
software system
•• SpecificationSpecification
•• DesignDesign
•• ValidationValidation
•
• EvolutionEvolution
• • A software process model is an abstract representation of a proc A software process model is an abstract representation of a process. ess.
It presents a description of a process from some particular It presents a description of a process from some particular perspective.
perspective.
•• The waterfall modelThe waterfall model
•• Separate and distinct phases of specification and development.Separate and distinct phases of specification and development.
•
• Evolutionary developmentEvolutionary development
•• Specification, development and validation are interleaved.Specification, development and validation are interleaved.
•
• Component-Component-based software engineeringbased software engineering
•
• The system is assembled from existing components.The system is assembled from existing components.
Waterfall model Waterfall model
Phases Phases
•• Requirements analysis and definitionRequirements analysis and definition
•• System and software designSystem and software design
•• Implementation and unit testingImplementation and unit testing
•• Integration and system testingIntegration and system testing
•• Operation and maintenanceOperation and maintenance
The main drawback of the waterfall model The main drawback of the waterfall model is the difficulty of accommodating change is the difficulty of accommodating change after the process is underway. One phase after the process is underway. One phase has to be complete before moving has to be complete before moving onto the next phase.
onto the next phase.
Problems Problems
•• Inflexible partitioning of the project Inflexible partitioning of the project into distinct stages makes it difficult into distinct stages makes it difficult to respond to changing customer to respond to changing customer requirements.
requirements.
•• Therefore, this model is only Therefore, this model is only appropriate when the requirements appropriate when the requirements are well
are well--understood and changes will understood and changes will be fairly limited during the design be fairly limited during the design process.
process.
•
• Few business systems have stable Few business systems have stable requirements.
requirements.
•• The waterfall model is mostly used The waterfall model is mostly used for large systems engineering for large systems engineering projects where a system is developed projects where a system is developed at several sites.
at several sites.
Stan Kurkovsky
Evolutionary development Evolutionary development
•
• Exploratory development Exploratory development
•• Objective is to work with customers Objective is to work with customers and to evolve a final system from an and to evolve a final system from an initial outline specification. Should initial outline specification. Should start with well
start with well--understood understood requirements and add new features requirements and add new features as proposed by the customer.
as proposed by the customer.
•
• ThrowThrow--away prototypingaway prototyping
•• Objective is to understand the system Objective is to understand the system requirements. Should start with requirements. Should start with poorly understood requirements to poorly understood requirements to clarify what is really needed.
clarify what is really needed.
•
• ProblemsProblems
•• Lack of process visibilityLack of process visibility
•• Systems are often poorly structuredSystems are often poorly structured
•
• Special skills (e.g. in languages for Special skills (e.g. in languages for rapid prototyping) may be required rapid prototyping) may be required
•
• ApplicabilityApplicability
•
• For small or mediumFor small or medium--size interactive size interactive systems
systems
•
• For parts of large systems (e.g. the For parts of large systems (e.g. the user interface)
user interface)
•
• For shortFor short--lifetime systemslifetime systems
Component
Component- -based software engineering based software engineering
• • Based on systematic reuse where systems are integrated from exis Based on systematic reuse where systems are integrated from existing ting components or COTS (Commercial
components or COTS (Commercial- -off off- -the the- -shelf) systems. shelf) systems.
•
• Process stages Process stages
•• Component analysis;Component analysis;
•
• Requirements modification;Requirements modification;
•• System design with reuse;System design with reuse;
•
• Development and integration.Development and integration.
• • This approach is becoming increasingly used as component standar This approach is becoming increasingly used as component standards ds have emerged.
have emerged.
Stan Kurkovsky
Process iteration Process iteration
•
•
Change is inevitable!Change is inevitable!•
• System System requirements ALWAYS evolve requirements ALWAYS evolve in the course of a project so in the course of a project so process iteration where earlier stages are reworked is always pa
process iteration where earlier stages are reworked is always part of the rt of the process for large systems.
process for large systems.
•
• Iteration can be applied to any of the generic process models. Iteration can be applied to any of the generic process models.
• • Two (related) approaches: Two (related) approaches:
•• Incremental deliveryIncremental delivery
•
• Spiral developmentSpiral development
Incremental delivery Incremental delivery
•• Rather than deliver the system as a Rather than deliver the system as a single delivery, the development and single delivery, the development and delivery is broken down into
delivery is broken down into increments with each increment increments with each increment delivering part of the required delivering part of the required functionality.
functionality.
•
• User requirements are prioritised and User requirements are prioritised and the highest priority requirements are the highest priority requirements are included in early increments.
included in early increments.
•
• Once the development of an Once the development of an increment is started, the increment is started, the requirements are frozen though requirements are frozen though requirements for later increments can requirements for later increments can continue to evolve.
continue to evolve.
•• AdvantagesAdvantages
•• Customer value can be delivered with Customer value can be delivered with each increment so system
each increment so system functionality is available earlier.
functionality is available earlier.
•
• Early increments act as a prototype Early increments act as a prototype to help elicit requirements for later to help elicit requirements for later increments.
increments.
•
• Lower risk of overall project failure.Lower risk of overall project failure.
•• The highest priority system services The highest priority system services tend to receive the most testing.
tend to receive the most testing.
•• Extreme ProgrammingExtreme Programming
•
• An approach to development based An approach to development based on the development and delivery of on the development and delivery of very small increments of functionality.
very small increments of functionality.
•
• Relies on constant code Relies on constant code
improvement, user involvement in the improvement, user involvement in the development team and pair
development team and pair programming.
programming.
Stan Kurkovsky
Spiral development Spiral development
•
• Process is represented as a spiral rather Process is represented as a spiral rather than as a sequence of activities with than as a sequence of activities with backtracking.
backtracking.
•• Each loop in the spiral represents a phase Each loop in the spiral represents a phase in the process.
in the process.
•
• No fixed phases such as specification or No fixed phases such as specification or design
design --loops in the spiral are chosen loops in the spiral are chosen depending on what is required.
depending on what is required.
•• Risks are explicitly assessed and resolved Risks are explicitly assessed and resolved throughout the process.
throughout the process.
•
• Objective settingObjective setting
•
• Specific objectives for the phase are identified.Specific objectives for the phase are identified.
•
• Risk assessment and reductionRisk assessment and reduction
•
• Risks are assessed and activities put in place Risks are assessed and activities put in place to reduce the key risks.
to reduce the key risks.
•
• Development and validationDevelopment and validation
•
• A development model for the system is chosen A development model for the system is chosen which can be any of the generic models.
which can be any of the generic models.
•
• PlanningPlanning
•
• The project is reviewed and the next phase of The project is reviewed and the next phase of the spiral is planned.
the spiral is planned.
1 2
3
4
1 2
3 4
Risk analysis Risk analysis Risk analysis
Risk analysis Proto-
type 1 Prototype 2
Prototype 3 Opera- tional protoype
Concept of Operation
Simulations, models, benchmarks
S/W requirements
Requirement validation
Design V&V
Product design Detailed
design Code Unit test Integration Acceptance test Service test Develop, verify
next-level product Evaluate alterna tives, identify, resolve risks Determine objecti ves,
alternatives and constraints
Plan next phase Integration and test plan Development plan Requirements plan
Life-cycle plan REVIEW
Software process activities Software process activities
• • Software specification Software specification
•
• Software design and implementation Software design and implementation
• • Software validation Software validation
•
• Software evolution Software evolution
•
• Applicable to ANY software process Applicable to ANY software process
Stan Kurkovsky
Software specification Software specification
•
• The process of establishing what services are required and the The process of establishing what services are required and the constraints on the system
constraints on the system’ ’s operation and development s operation and development
• • Requirements engineering process Requirements engineering process
•
• Feasibility studyFeasibility study
•• Requirements elicitation and analysisRequirements elicitation and analysis
•
• Requirements specificationRequirements specification
•• Requirements validation (check for realism, consistency and completeness)Requirements validation (check for realism, consistency and completeness)
• • Requirements engineering Requirements engineering
Software design and implementation Software design and implementation
•• The process of converting the system The process of converting the system specification into an executable specification into an executable system
system
•• Software designSoftware design
•• Design a software structure that Design a software structure that realises the specification realises the specification
•• ImplementationImplementation
•
• Translate this structure into an Translate this structure into an executable program
executable program
•
• The activities of design and The activities of design and implementation are closely related implementation are closely related and may be inter
and may be inter--leavedleaved
Structured methods Structured methods
•
• Systematic approaches to developing Systematic approaches to developing a software design
a software design
•• The design is usually documented as The design is usually documented as a set of graphical models
a set of graphical models
•• Possible models (UML)Possible models (UML)
•• Object modelObject model
•
• Sequence modelSequence model
•• State transition modelState transition model
•• Structural modelStructural model
•
• DataData--flow modelflow model
Stan Kurkovsky
Implementation: Programming and debugging Implementation: Programming and debugging
•
• Translating a design into a program and removing errors from tha Translating a design into a program and removing errors from that t program
program
• • Programming is a personal activity Programming is a personal activity - - there is no generic programming there is no generic programming process
process
•
• Programmers carry out some program testing to discover faults in Programmers carry out some program testing to discover faults in the the program and remove these faults in the debugging process
program and remove these faults in the debugging process
• • Debugging process Debugging process
Software verification and validation Software verification and validation
• • Verification and validation (V & V) is intended to show that a s Verification and validation (V & V) is intended to show that a system ystem conforms to its specification and meets the requirements of the
conforms to its specification and meets the requirements of the system system customer.
customer.
•
• Verification: Are we building the product right?Verification: Are we building the product right?
•• Validation: Are we building the right product?Validation: Are we building the right product?
•
• Involve checking and review processes and system testing.Involve checking and review processes and system testing.
• • System testing involves executing the system with test cases tha System testing involves executing the system with test cases that are t are derived from the specification of the real data to be processed derived from the specification of the real data to be processed by the by the system.
system.
Stan Kurkovsky
Software testing Software testing
• • Testing process Testing process
•
• Component or unit testing Component or unit testing
•
• Individual components are tested independently Individual components are tested independently
•
• Components may be functions or objects or coherent groupings of these Components may be functions or objects or coherent groupings of these entities
entities
• • System testing System testing
•
• Testing of the system as a wholeTesting of the system as a whole
•
• Testing of emergent properties is particularly importantTesting of emergent properties is particularly important
•
• Acceptance testing Acceptance testing
•• Testing with customer data to check that the system meets the customerTesting with customer data to check that the system meets the customer’’s s needs
needs
Software evolution Software evolution
• • Software is inherently flexible and can change Software is inherently flexible and can change
•
• As requirements change through changing business circumstances, As requirements change through changing business circumstances, the the software that supports the business must also evolve and change software that supports the business must also evolve and change
• • Although there has been a demarcation between development and Although there has been a demarcation between development and evolution (maintenance) this is increasingly irrelevant as fewer
evolution (maintenance) this is increasingly irrelevant as fewer and fewer and fewer systems are completely new
systems are completely new
Stan Kurkovsky
The Rational Unified Process (RUP) The Rational Unified Process (RUP)
•
• A modern process model derived A modern process model derived from the work on the UML and from the work on the UML and associated process.
associated process.
•
• Normally described from Normally described from 3 perspectives
3 perspectives
•• A dynamic perspective that shows A dynamic perspective that shows phases over time
phases over time
•• A static perspective that shows A static perspective that shows process activities
process activities
•
• A practice perspective that suggests A practice perspective that suggests good practices
good practices
•
• RUP PhasesRUP Phases
•• Inception: Establish the business case Inception: Establish the business case for the system
for the system
•
• Elaboration: Develop an Elaboration: Develop an
understanding of the problem domain understanding of the problem domain and the system architecture
and the system architecture
•• Construction: System design, Construction: System design, programming and testing programming and testing
•
• Transition: Deploy the system in its Transition: Deploy the system in its operating environment
operating environment
•
• RUP good practicesRUP good practices
•• Develop software iterativelyDevelop software iteratively
•• Manage requirementsManage requirements
•
• Use componentUse component--based architecturesbased architectures
•• Visually model softwareVisually model software
•
• Verify software qualityVerify software quality
•
• Control changes to softwareControl changes to software
RUP Static workflows RUP Static workflows
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.
Testing Testing is an iterative process that is carried out in conjunction with implementation. System testing follows the completion of the implementation.
Stan Kurkovsky
Computer
Computer- -aided software engineering (CASE) aided software engineering (CASE)
•
• ComputerComputer--aided software engineering (CASE) is software to support softwaraided software engineering (CASE) is software to support software e development and evolution processes.
development and evolution processes.
•
• Activity automationActivity automation
•
• Graphical editors for system model developmentGraphical editors for system model development
•• Data dictionary to manage design entitiesData dictionary to manage design entities
•• Graphical UI builder for user interface constructionGraphical UI builder for user interface construction
•
• Debuggers to support program fault findingDebuggers to support program fault finding
•• Automated translators to generate new versions of a programAutomated translators to generate new versions of a program
• • Case technology has led to significant improvements in the softw Case technology has led to significant improvements in the software are process. However, these are not the order of magnitude improveme process. However, these are not the order of magnitude improvements nts that were once predicted
that were once predicted
•• Software engineering requires creative thought -Software engineering requires creative thought -this is not readily automatedthis is not readily automated
•
• Software engineering is a team activity and, for large projects,Software engineering is a team activity and, for large projects,much time is much time is spent in team interactions. CASE technology does not really supp
spent in team interactions. CASE technology does not really support theseort these
CASE Classification CASE Classification
•
• Classification helps us understand the different types of CASE tClassification helps us understand the different types of CASE tools and their ools and their support for process activities.
support for process activities.
•• Functional perspectiveFunctional perspective
•• Tools are classified according to their specific function.Tools are classified according to their specific function.
•• Process perspectiveProcess perspective
•
• Tools are classified according to process activities that are supported.Tools are classified according to process activities that are supported.
•• Integration perspectiveIntegration perspective
•
• Tools are classified according to their organisation into integrated units.Tools are classified according to their organisation into integrated units.
Tool type Examples
Planning tools PERT (Program Evaluation and Review Technique) tools, estimation tools, spreadsheets Editing tools Text editors, diagram editors, word processors
Change management tools Requirements traceability tools, change control systems Configuration management tools Version management systems, system building tools Prototyping tools Very high-level languages, user interface generators Method-support tools Design editors, data dictionaries, code generators Language-processing tools Compilers, interpreters
Program analysis tools Cross reference generators, static analysers, dynamic analysers
Stan Kurkovsky
CASE integration CASE integration
•
• Tools Tools
•• Support individual process tasks such as design consistency checking, text Support individual process tasks such as design consistency checking, text editing, etc.
editing, etc.
• • Workbenches Workbenches
•• Support a process phase such as specification or designSupport a process phase such as specification or design
•
• Normally include a number of integrated tools.Normally include a number of integrated tools.
•
• Environments Environments
•• Support all or a substantial part Support all or a substantial part of an entire software process of an entire software process
•
• Normally include several Normally include several integrated workbenches integrated workbenches
Summary Summary
•
• Software processes are the activities involved in producing and Software processes are the activities involved in producing and evolving a evolving a software system.
software system.
•• Software process models are abstract representations of these prSoftware process models are abstract representations of these processes.ocesses.
•
• General activities are specification, design and implementation,General activities are specification, design and implementation,validation and validation and evolution.
evolution.
•• Generic process models describe the organisation of software proGeneric process models describe the organisation of software processes. cesses.
Examples include the waterfall model, evolutionary development a
Examples include the waterfall model, evolutionary development and componentnd component-- based software engineering.
based software engineering.
•• Iterative process models describe the software process as a cyclIterative process models describe the software process as a cycle of activities.e of activities.
•• Requirements engineering is the process of developing a softwareRequirements engineering is the process of developing a softwarespecification.specification.
