Upload
loganathan-ramasamy
View
1.834
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Software process
Citation preview
Software Processes
Loganathan RLoganathan R
1Prof. Loganathan R., CSE, HKBKCE
Objectives
• Understand the concept of software processmodels
• Understand three generic process models andwhen they may be used
• Understand the activities involved in• Understand the activities involved inrequirements engineering, softwaredevelopment, testing and evolution
• Understand the Rational Unified Process model• Introduce the CASE technology to support
software process activities
2Prof. Loganathan R., CSE, HKBKCE
The Software Process
• Common fundamental activities to all Software processes are:
– Specification;
– Design;
– Validation;
– Evolution.– Evolution.
• A software process model is an abstract representation of aprocess. It presents a description of a process from someparticular perspective.
3Prof. Loganathan R., CSE, HKBKCE
Generic software process models
• The waterfall model– Separate and distinct phases of specification and development.
• Evolutionary(Iterative) development– Specification, development and validation are interleaved.
• Component-Based Software Engineering• Component-Based Software Engineering– The system is assembled from existing components.
• There are many variants of these models e.g. formaldevelopment where a waterfall-like process is used but thespecification is a formal specification that is refined throughseveral stages to an implementable design.
4Prof. Loganathan R., CSE, HKBKCE
Waterfall Model
System andSoftware Design
RequirementsDefinition
Implementation
5Prof. Loganathan R., CSE, HKBKCE
Implementationand Unit Testing
Integration andSystem Testing
Operation andMaintenance
Waterfall Model phases
• Requirements analysis and definition• Services, constraints & goals are established & Defined
• System and software design• Establishes overall System architecture ,identifies & describes
the software system abstractions & their relationships• Implementation and unit testing
Design is realised as program units. Unit testing involves• Implementation and unit testing
• Design is realised as program units. Unit testing involvesverifying each unit meets its specification
• Integration and system testing• Program unit are integrated and tested as a system to ensure it
meets the requirement specification.• Operation and maintenance
• System is installed & put in use. Maintenance involvescorrecting errors, improving implementation & enhancing withnew requirements as discovered
6Prof. Loganathan R., CSE, HKBKCE
Waterfall model problems• The main drawback of the waterfall model is the difficulty of
accommodating change after the process is underway. Onephase has to be complete before moving onto the next phase.
• Inflexible partitioning of the project into distinct stages makesit difficult to respond to changing customer requirements.
• Therefore, this model is only appropriate when the• Therefore, this model is only appropriate when therequirements are well-understood and changes will be fairlylimited during the design process.
• Few business systems have stable requirements.
• The waterfall model is mostly used for large systemsengineering projects where a system is developed at severalsites.
7Prof. Loganathan R., CSE, HKBKCE
Evolutionary developmentConcurrentactivities
Specification InitialVersion
8Prof. Loganathan R., CSE, HKBKCE
ValidationFinal
Version
Development IntermediateVersions
OutlineDescription
Evolutionary development
• Develop an initial implementation and expos touser comment and then refine it through manyversions.
• Types:• Exploratory development• Exploratory development
– Objective is to work with customers and to evolve a finalsystem from an initial outline specification. Should start withwell-understood requirements and add new features asproposed by the customer.
• Throw-away prototyping– Objective is to understand the system requirements. Should
start with poorly understood requirements to clarify what isreally needed.
9Prof. Loganathan R., CSE, HKBKCE
• Problems– Lack of process visibility;
– Systems are often poorly structured;
– Special skills (e.g. in languages for rapid
Evolutionary development
– Special skills (e.g. in languages for rapidprototyping) may be required.
• Applicability– For small or medium-size interactive systems;
– For parts of large systems (e.g. the user interface);
– For short-lifetime systems.
10Prof. Loganathan R., CSE, HKBKCE
Component-based software engineering
RequirementsSpecifications
ComponentAnalysis
System Designwith Reuse
RequirementsModifications
11Prof. Loganathan R., CSE, HKBKCE
Developmentand Integration
SystemValidation
Component-based software engineering
• Based on systematic reuse where systems are integratedfrom existing components or COTS (Commercial-off-the-shelf) systems.
• Process stages– Component analysis :- Search for components for given
specification– Requirements modification :- Analyse the requirements using– Requirements modification :- Analyse the requirements using
the discovered component information and modify to reflectthe available components
– System design with reuse :- Framework of the system isdesigned or existing framework is reused
– Development and integration :- non available components aredeveloped and integrated with COTS system to create therequired system
• This approach is becoming increasingly used as componentstandards have emerged.
12Prof. Loganathan R., CSE, HKBKCE
Process Iteration
• System requirements ALWAYS evolve in thecourse of a project so, process iteration whereearlier stages are reworked is always part ofthe process for large systems.
• Iteration can be applied to any of the genericprocess models.
• Two (related) approaches– Incremental delivery;
– Spiral development.
13Prof. Loganathan R., CSE, HKBKCE
Incremental delivery
Design SystemArchitecture
Define OutlineRequirements
Assign Requirementsto Increments
14Prof. Loganathan R., CSE, HKBKCE
ValidateIncrement
Develop systemIncrement
IntegrateIncrement
ValidateSystem
System Incomplete
FinalSystem
Incremental delivery
• Rather than deliver the system as a single delivery, thedevelopment (Specification, design & implementation)and delivery is broken down into increments with eachincrement delivering part of the required functionality.
• User requirements are prioritised and the highest• User requirements are prioritised and the highestpriority requirements are included in early increments.
• Once the development of an increment is started, therequirements are frozen though requirements for laterincrements can continue to evolve.
15Prof. Loganathan R., CSE, HKBKCE
• Advantages
– Customer value can be delivered with eachincrement so system functionality is availableearlier.
Incremental delivery
earlier.
– Early increments act as a prototype to help elicitrequirements for later increments.
– Lower risk of overall project failure.
– The highest priority system services tend toreceive the most testing.
16Prof. Loganathan R., CSE, HKBKCE
Extreme programming
• Variant of incremental delivery.
• Based on the development based on thedevelopment and delivery of very smallincrements of functionality.increments of functionality.
• Relies on constant code improvement, userinvolvement in the development team andpair wise programming.
17Prof. Loganathan R., CSE, HKBKCE
Spiral development
• Process is represented as a spiral rather thanas a sequence of activities with backtracking.
• Each loop in the spiral represents a phase inthe process.the process.
• No fixed phases such as specification ordesign - loops in the spiral are chosendepending on what is required.
• Risks are explicitly assessed and resolvedthroughout the process.
18Prof. Loganathan R., CSE, HKBKCE
Spiral model of the software process
Risk
analysis
Risk
analysis
Risk
analysis
Prototype 2
Prototype 3Oper a-
tional
protoype
Evaluate alterna tives,
identify , resolve risks
Deter mine objecti ves,
alterna tives and
constr aints
19Prof. Loganathan R., CSE, HKBKCE
Risk
analysis Proto-
type 1
Prototype 2 protoype
Concept of
Oper ation
Simulations , models , benchmarks
S/W
requir ements
Requir ement
validation
Design
V&V
Product
design Detailed
design
Code
Unit test
Integ ration
testAcceptance
testService Develop , verify
next-level pr oduct
Plan ne xt phase
Integ ration
and test plan
Development
plan
Requir ements plan
Life-cycle plan
REVIEW
Spiral model Sectors
• Objective setting
– Define the Specific objectives for that phase. Identify theconstraints on the process/product and project risk. Plan forconstraints & find alternate for risk or resolve.
• Risk assessment and reduction– Risks are analysed & assessed and take steps to reduce the risks.– Risks are analysed & assessed and take steps to reduce the risks.
• Development and validation– A development model for the system is chosen which can be any
of the generic models. Example for UI risk use evolutionaryprototyping, for safety risk use formal transformation, for sub-system risk Waterfall model
• Planning– The project is reviewed and the next phase of the spiral is planned.
20Prof. Loganathan R., CSE, HKBKCE
Process activities
• 1. Software specification
• 2. Software design and implementation
• 3. Software validation
• 4. Software evolution• 4. Software evolution
21Prof. Loganathan R., CSE, HKBKCE
1. Software specification• Software Specification or requirements engineering is the process of
understanding and defining what services are required and identifyingthe constraints on the system’s operation and development.
• Requirements engineering process
– Feasibility study:- Estimate whether the current h/w & s/w technology will
satisfy user needs & cost-effective. Feasibility study should be cheap &quick.
– Requirements elicitation and analysis :- Derive the requirements by
observing existing system, discussing with users, task analysis & so on. Producesystem models & prototypes
– Requirements specification :- Translate the previous activity information
into requirements document. Types of requirements:
• User requirements :- for customer & end user
• System requirements : - detailed description of the required functionality
– Requirements validation :- Checks the requirements for realism consistency
& completeness.22Prof. Loganathan R., CSE, HKBKCE
The requirements engineering process
FeasibilityStudy
RequirementsElicitation and
Analysis
RequirementsSpecification
RequirementsFeasibility
23Prof. Loganathan R., CSE, HKBKCE
RequirementsValidation
FeasibilityReport
SystemModels
User and SystemRequirements
RequirementsDocument
2. Software Design and Implementation
• The process of converting the systemspecification into an executable system.
• Software design– is a description of software structure, data, interfaces
and algorithms used in the system that realises theand algorithms used in the system that realises thespecification;
• Implementation– Translate design structure into an executable
program;
• The activities of design and implementation areclosely related and may be inter-leaved.
24Prof. Loganathan R., CSE, HKBKCE
The software design process
RequirementSpecification
Design activities
25Prof. Loganathan R., CSE, HKBKCE
ArchitecturalDesign
AbstractSpecificatio
n
InterfaceDesign
ComponentDesign
DataStructureDesign
AlgorithmDesign
SystemArchitecture
SoftwareSpecification
InterfaceSpecification
ComponentSpecification
DataStructure
Specification
AlgorithmSpecification
Design products
Software Design process activities
• Architectural designSubsystem making up the system & their relationships are identified & documented
• Abstract specificationAbstract specification of subsystem services & its operating constraints are produced
• Interface design• Interface designSubsystem interfaces with other subsystem is designed unambiguously & documented
• Component designComponent services are allocated & its interfaces also designed
• Data structure designThe data structures used in the implementation is designed & specified
• Algorithm designAlgorithm to provide services are designed & specified
26Prof. Loganathan R., CSE, HKBKCE
Design methods• In Agile method, design process output is represented
in the code of the program• The Structured methods produces graphical models
and code generated automatically from that. Includesdesign process model, design notations, report formats& design guidelines.
• Structured methods supports the following models:• Structured methods supports the following models:– Object model :Shows object classes & their dependencies– Sequence model :Shows how objects interact when system is
executing– State transition model :Shows system states & triggers for
transition from one state to another– Structural model :System Components & their aggregations
are documented– Data-flow model :System is modelled using transformations
that takes place as it is processed
27Prof. Loganathan R., CSE, HKBKCE
Programming and Debugging
• Translating a design into a program andremoving errors from that program.
• Programming is a personal activity - there isno generic programming process.no generic programming process.
• Programmers carry out some program testingto discover faults in the program and removethese faults in the debugging process.
28Prof. Loganathan R., CSE, HKBKCE
The Debugging Process
Locate Design Error Repair Retest
29Prof. Loganathan R., CSE, HKBKCE
LocateError
Design ErrorRepair
RepairError
RetestProgram
3. Software validation
• Verification and validation (V & V) is intendedto show that a system conforms to itsspecification and meets the requirements ofthe system customer.
• Involves checking and review processes and• Involves checking and review processes andsystem testing.
• System testing involves executing the systemwith test cases that are derived from thespecification of the real data(customer data)to be processed by the system.
30Prof. Loganathan R., CSE, HKBKCE
The Testing Process
Component System Acceptance
31Prof. Loganathan R., CSE, HKBKCE
ComponentTesting
SystemTesting
AcceptanceTesting
Testing process stages• Component or unit testing
– Individual components are tested independentlyfor correct operation;
– Components may be functions or objects orcoherent groupings of these entities.
• System testing• System testing– Testing of the system as a whole to validate
functional & non-functional requirements. Testingof emergent properties is particularly important.
• Acceptance testing– Testing with customer data to check that the
system meets the customer’s needs &performance.
32Prof. Loganathan R., CSE, HKBKCE
Testing phases in a Software processRequirementsSpecification
SystemSpecification
SystemDesign
DetailedDesign
Module / UnitCode and Test
Sub-systemIntegrationTest Plan
SystemIntegrationTest Plan
AcceptanceTest Plan
33Prof. Loganathan R., CSE, HKBKCE
• Alpha testing : Acceptance testing
• Beta testing : For marketed products, involves deliveringsystem to potential customers who agree to use
ServiceAcceptance
TestSystem
Integration TestSub-system
Integration Test
4. Software evolution
• Software is inherently flexible and can change.
• As requirements change through changingbusiness circumstances, the software thatsupports the business must also evolve andsupports the business must also evolve andchange.
• Although there has been a demarcationbetween development and evolution(maintenance) this is increasingly irrelevant asfewer and fewer systems are completely new.
34Prof. Loganathan R., CSE, HKBKCE
System evolution
Assess existingDefine system Propose system Modify
35Prof. Loganathan R., CSE, HKBKCE
Assess existingsystems
Define systemrequirements
Propose systemchanges
Modifysystems
Newsystem
Existingsystems
The Rational Unified Process
• A modern process model derived from the work onthe UML and associated Unified SoftwareDevelopment process.
• It is a Hybrid process model : Combines the elementsof generic process models, supports iteration &of generic process models, supports iteration &illustrates good practices in specification & design
• Normally described from 3 perspectives
– A dynamic perspective that shows phases over time;
– A static perspective that shows process activities;
– A practice perspective that suggests good practice.
36Prof. Loganathan R., CSE, HKBKCE
RUP phase model
Phase iteration
37Prof. Loganathan R., CSE, HKBKCE
Inception Elaboration Construction Transition
RUP phases
• Inception– Establish the business case for the system.
• Elaboration– Develop an understanding of the problem domain– Develop an understanding of the problem domain
and the system architecture.
• Construction– System design, programming and testing.
• Transition– Deploy the system in its operating environment.
38Prof. Loganathan R., CSE, HKBKCE
RUP good practice
• Develop software iteratively
• Manage requirements
• Use component-based architectures
• Visually model software• Visually model software
• Verify software quality
• Control changes to software
39Prof. Loganathan R., CSE, HKBKCE
Static workflowsWorkflow Description
Business modelling The business processes are modelled using business use cases.
RequirementsActors who interact with the system are identified and use cases aredeveloped to model the system requirements.
Analysis and designA design model is created and documented using architectural models,component models, object models and sequence models.
ImplementationThe components in the system are implemented and structured intoimplementation sub-systems. Automatic code generation from design
40Prof. Loganathan R., CSE, HKBKCE
Implementation implementation sub-systems. Automatic code generation from designmodels helps accelerate this process.
TestTesting is an iterative process that is carried out in conjunction withimplementation. System testing follows the completion of theimplementation.
DeploymentA product release is created, distributed to users and installed in theirworkplace.
Configuration andChange management
This supporting workflow managed changes to the system
Project management This supporting workflow manages the system development
EnvironmentThis workflow is concerned with making appropriate software toolsavailable to the software development team.
Computer-aided software engineering
• Computer-aided software engineering (CASE) is software tosupport software development and evolution processes.
• Activity automation
– Graphical editors for system model development;
– Data dictionary to manage design entities;– Data dictionary to manage design entities;
– Graphical UI builder for user interface construction;
– Debuggers to support program fault finding;
– Automated translators to generate new versions of a program.
41Prof. Loganathan R., CSE, HKBKCE
Case technology
• Case technology has led to significantimprovements in the software process. However,these are not the order of magnitudeimprovements that were once predictedimprovements that were once predicted
– Software engineering requires creative thought - thisis not readily automated;
– Software engineering is a team activity and, for largeprojects, much time is spent in team interactions.CASE technology does not really support these.
42Prof. Loganathan R., CSE, HKBKCE
CASE classification
• Classification helps us understand the different types of CASEtools and their support for process activities.
• Functional perspective
– Tools are classified according to their specific function.
• Process perspective• Process perspective
– Tools are classified according to process activities that aresupported.
• Integration perspective
– Tools are classified according to their organisation into integratedunits.
43Prof. Loganathan R., CSE, HKBKCE
Functional tool classificationTool type Examples
Planning tools PERT 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
44Prof. Loganathan R., CSE, HKBKCE
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 toolsCross reference generators, static analysers, dynamicanalysers
Testing tools Test data generators, file comparators
Debugging tools Interactive debugging systems
Documentation tools Page layout programs, image editors
Re-engineering tools Cross-reference systems, program re-structuring systems
Activity-based tool classification
Re-engineering tools
Testing tools
Debugging tools
Program analysis tools
Language-processing tools
45Prof. Loganathan R., CSE, HKBKCE
Specification Design Implementation Verification &Validation
Method support tools
Prototyping tools
Configuration managementtools
Change management tools
Documentation tools
Editing tools
Planning tools
CASE integration
• Tools– Support individual process tasks such as design
consistency checking, text editing, etc.
• Workbenches– Support a process phase such as specification or– Support a process phase such as specification or
design, Normally include a number of integratedtools.
• Environments– Support all or a substantial part of an entire
software process. Normally include severalintegrated workbenches.
46Prof. Loganathan R., CSE, HKBKCE
Tools, workbenches, environments
EnvironmentsWorkbenchesTools
CaseTechnology
47Prof. Loganathan R., CSE, HKBKCE
Single-methodWorkbenches
General-purposeWorkbenches
Multi-methodWorkbenches
Language-specificWorkbenches
Programming TestingAnalysis and
Design
Integrated
EnvironmentsProcess-centred
EnvironmentsFile ComparatorsCompilersEditors