©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities...
-
Upload
jemima-mitchell -
Category
Documents
-
view
213 -
download
1
Transcript of ©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities...
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 1
Software Processes
Coherent sets of activities for specifying, designing, implementing and testing software systems
Objectives• To introduce software lifecycle models
• To describe a number of different lifecycle models and when they may be used
• To describe outline process models for requirements engineering, software development, testing and evolution
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 2
Introduction
How do we produce software and why do we need a software process ?
Software development projects are large and complex A phased approach to control it is necessary A process may be defined as a method of developing or
producing software.
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 3
The importance of a process
Why do we need a process ? Software is very difficult to maintain. Software evolve and its requirements change. Software has too many failures. It is very difficult to accurately gauge the quality of the finished
product according to any independent assessment. Large software projects involve large groups of people.
Software development must be documented !!!!!
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 4
The importance of a process
What do we want our process to achieve?
Effectiveness. The process should help us determine what the customer needs, produce what the customer needs, and, crucially, verify that what we have produced is what the customer needs.
Maintainability. Predictability. It is important to predict accurately how long it
will take to develop the product and how much it will cost.
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 5
The importance of a process
What do we want our process to achieve?
Repeatability. If a process is discovered to work, it should be replicated in future projects. A closely related issue, is that of process re-use.
Quality. The process should provide a clear link between a customer's desires and a developer's product.
Improvement. No one would expect their process to reach perfection and need no further improvement itself. A goal of our defined process must then be to identify and prototype possibilities for improvement in the process itself.
Tracking. A defined process should allow the management, developers, and customer to follow the status of a project.
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 6
The software process A structured set of activities required to develop a
software system• Specification
• Design
• Validation
• Evolution
A software process model is an abstract representation of a process• presents a description of a process from some particular
perspective
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 7
Software lifecycle models:Generic software process models
The waterfall model• Separate and distinct phases of specification and development
Evolutionary development• Specification and development are interleaved
Formal systems development• A mathematical system model is formally transformed to an
implementation
Reuse-based development• The system is assembled from existing components
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 8
Waterfall modelRequirements
definition
System andsoftware design
Implementationand unit testing
Integration andsystem testing
Operation andmaintenance
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 9
Waterfall model problems Inflexible partitioning of the project into distinct
stages This makes it difficult to respond to changing
customer requirements This model is only appropriate when the
requirements are well-understood
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 10
Requirements Engineering yields a description of the desired system:
• which functions
• possible extensions
• required documentation
• performance requirements
includes a feasibility study
resulting document: requirements specification
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 11
Design earliest design decisions captured in software
architecture
decomposition into parts/components; what are the functions of, and interfaces between, those components?
emphasis on what rather than how
resulting document: specification
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 12
Implementation focus on individual components
goal: a working, flexible, robust, … piece of software
not a bag of tricks
present-day languages have a module and/or class concept
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 13
Testing does the software do what it is supposed to do?
are we building the right system? (validation)
are we building the system right? (verification)
start testing activities in phase 1, on day 1
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 14
Maintenance
correcting errors found after the software has been delivered
adapting the software to changing requirements, changing environments, ...
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 15
Global distribution of effort
testing 45%
coding 20%design 15%
requirementsengineering 10%
specification 10%
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 16
Kinds of maintenance activities
corrective maintenance: correcting errors
adaptive maintenance: adapting to changes in the environment (both hardware and software)
perfective maintenance: adapting to changing user requirements
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 17
Distribution of maintenance activities
corrective 21%
adaptive 25%
preventive 4%
perfective 50%
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 18
Evolutionary development Exploratory development
• Objective is to work with customers and to evolve a final system from an initial outline specification.
• Should start with well-understood requirements
Throw-away prototyping• Objective is to understand the system requirements
• Should start with poorly understood requirements
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 19
Evolutionary development
ValidationFinal
version
DevelopmentIntermediate
versions
SpecificationInitial
version
Outlinedescription
Concurrentactivities
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 20
Evolutionary development Problems
• Lack of process visibility
• Systems are often poorly structured due to lack of proper planning
• Special skills (e.g. in languages for rapid prototyping) 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
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 21
Formal systems development Based on the transformation of a mathematical
specification through different representations to an executable program
Transformations are ‘correctness-preserving’ so it is straightforward to show that the program conforms to its specification
Embodied in the ‘Cleanroom’ approach to software development• No need to test for defects
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 22
Formal systems development Problems
• Need for specialised skills and training to apply the technique
• Difficult to formally specify some aspects of the system such as the user interface
• Changes require new transformations and proofs
• Typically does not scale
Applicability• Critical systems (e.g., in terms of safety or security)
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 23
Reuse-oriented development Based on systematic reuse where systems are
integrated from existing components or COTS systems
Process stages• Component analysis
• Requirements modification
• System design with reuse
• Development and integration
Becoming important but still limited experience with it
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 24
Process iteration System requirements always evolve in the course of
a project Process iteration where earlier stages are reworked
is always part of the process for large systems Iteration can be applied to any of the generic
process models Two (related) approaches
• Incremental development
• Spiral development
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 25
Incremental development Development and delivery is broken down into
increments Each increment delivers part of the required
functionality 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• Requirements for later increments can continue to evolve
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 26
Incremental development advantages
System functionality is available earlier and customer does not have to wait as long
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
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 27
Agile Methodology
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 28
Agile Methodology
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 29
Agile Methodology
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 30
Agile Methodology
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 31
Agile Methodology
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 32
Spiral development 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
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 33
Spiral model of the software process
Riskanalysis
Riskanalysis
Riskanalysis
Riskanalysis Proto-
type 1
Prototype 2Prototype 3
Opera-tionalprotoype
Concept ofOperation
Simulations, models, benchmarks
S/Wrequirements
Requirementvalidation
DesignV&V
Productdesign Detailed
design
CodeUnit test
IntegrationtestAcceptance
testService Develop, verifynext-level product
Evaluate alternativesidentify, resolve risks
Determine objectivesalternatives and
constraints
Plan next phase
Integrationand test plan
Developmentplan
Requirements planLife-cycle plan
REVIEW
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 34
The Rational Unified Process A modern process model derived from the work
on the UML and associated process. Normally described from 3 perspectives
• A dynamic perspective that shows phases over time;
• A static perspective that shows process activities;
• A practive perspective that suggests good practice.
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 35
RUP phase model
Phase iteration
Inception Elaboration Construction Transition
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 36
RUP phases Inception
• Establish the business case for the system.
Elaboration• 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.
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 37
RUP good practice Develop software iteratively Manage requirements Use component-based architectures Visually model software Verify software quality Control changes to software
©Ian Sommerville 2000 , Mejia-Alvarez 2009 Slide 38
Key points Software processes are the activities involved in
producing and evolving a software system. They are represented in a software process model
General activities are specification, design and implementation, validation and evolution
Lifecycle models describe the organisation of software processes
Iterative process models describe the software process as a cycle of activities