2. 2
Course outline
• Unit 1: Software Engineering Basics
Unit 2: Process Models and Software Life Cycles
• Unit 3: Software Requirements
• Unit 4: Unified Modeling Language (UML)
• Unit 5: Design Basics and Software Architecture
• Unit 6: OO Analysis and Design
• Unit 7: Design Patterns
• Unit 8: Testing and Reliability
• Unit 9: Software Engineering Management and Economics
3. 3
Reference
• These slides are based on:
– Lecture slides by Ian Summerville, see
http://www.comp.lancs.ac.uk/computing/resources/ser/
4. 4
Overview
• Build-and-fix model
• Waterfall model
• Rapid prototyping model
• Incremental model
• Evolutionary
• Synchronize-and-stabilize model
• Spiral model
5. 5
Software Life-Cycle Models
• Life-cycle model (also, process model)
• The software development and operation
activities and their ordering
– Requirements elicitation
– Specification
– Design
– Implementation
– Integration
– Maintenance phase
– Retirement
– …
6. 6
New or changed
requirements
New or changed
system
Software Engineering
Process
What Is a Software Engineering
Process?
A process defines Who is doing What, When and How in
the development of a software system
– Roles and workflows
– Workproducts
– Milestones
– Guideline
– …
8. 8
An Effective Process ...
• Provides guidelines for efficient development of
quality software
• Reduces risk and increases predictability
• Captures and presents best practices
– Learn from other’s experiences
– Mentor on your desktop
– Extension of training material
• Promotes common vision and culture
• Provides roadmap for applying tools
• Delivers information on-line, at your finger tips
9. 9
Lightweight vs. Heavyweight
Processes
Document driven
Elaborate workflow definitions
Many different roles
Many checkpoints
High management overhead
Highly bureaucratic
Focus on working code
rather than documentation
Focus on direct communication
(between developers and
between developers and the customer)
Low management overhead
Heavyweight
e.g., V-Process
Customizable
Framework
e.g., Rational
Unified
Process (RUP)
Agile (Lightweight)
e.g., eXtreme
Programming (XP)
11. 11
Build and Fix Model
• Properties
– No planning or analysis
– The working program is the
only workproduct
• Advantage
– Appropriate for small programs
written by one person
• Disadvantage
– Understandability and
maintainability decrease rapidly
with increasing program size
– Totally unsatisfactory
– Need a life-cycle model
• “Game plan”
• Phases
• Milestones
12. 12
Waterfall Model
• Characterized by
– Sequential steps (phases)
– Feedback loops (between two phases in
development)
– Documentation-driven
• Advantages
– Documentation
– Maintenance easier
• Disadvantages
– Complete and frozen specification document
up-front often not feasible in practice
– Customer involvement in the first phase only
– Sequential and complete execution of phases
often not desirable
– Process difficult to control
– The product becomes available very late in
the process
13. 13
Rapid Prototyping Model
• Rapid prototyping phase
followed by waterfall
– Do not turn the rapid
prototype into the product
– Rapid prototyping may replace
the specification phase—never
the design phase
• Comparison:
– Waterfall model—try to get it
right the first time
– Rapid prototyping—frequent
change, then discard
14. 14
Advantages and Disadvantages
• Advantages
– Requirements better specified and validated
– Early feasibility analysis
– Strong involvement of the customer in the
prototyping phase
• Disadvantage
– Higher development effort
– Danger that due to schedule slip, the prototype
becomes part of the product
15. 15
Incremental
Design Coding Test Deployment
Design Coding Test Deployment
Design Coding Test Deployment
Requirements
Release 1
Release 2
Release 3
Each release adds more functionality,
i.e., a new increment
(Some call it iterative)
16. 16
Incremental Model (contd)
• Waterfall, rapid prototyping models
– Operational quality complete product at end
• Incremental model
– Operational quality portion of product within weeks
• Less traumatic
• Smaller capital outlay, rapid return on investment
17. 17
Evolutionary
Design Coding Test DeploymentRequirements
Design Coding Test DeploymentRequirements
Design Coding Test DeploymentRequirements
Feedback
Version 1
Version 1
Version 1
New versions implement new and
evolving requirements
(Some call it iterative)
18. 18
Evolutionary Model (contd)
• Advantages
– Constant customer involvement and validation
– Allows for good risk management
• Disadvantages
– Build-and-fix danger
– Contradiction in terms
19. 19
Spiral model
• Waterfall model plus risk analysis preceding each
phase and evaluation following each phase
• Prototyping for high-risk specifications
• Radial dimension: cumulative cost to date
• Angular dimension: progress through the spiral
• If all risks cannot be resolved, the project is
immediately terminated
• Appropriate only for big projects (high
management overhead)
21. 21
Process model risk problems
• Waterfall
– High risk for new systems because of specification
and design problems
– Low risk for well-understood developments using
familiar technology
• Prototyping
– Low risk for new applications because specification
and program stay in step
– High risk because of lack of process visibility
• Evolutionary and Spiral
– Middle ground between waterfall and prototyping
22. 22
Hybrid process models
• Large systems are usually made up of several
sub-systems
• The same process model need not be used for
all subsystems
• Prototyping for high-risk specifications
• Waterfall model for well-understood
developments
• Taylor the process to a problem
25. 25
Reference
• These slides are based on:
– Lecture slides by Ian Summerville, see
http://www.comp.lancs.ac.uk/computing/resources/ser/
26. 26
Rational Unified Process – Main
Characteristics
• Iterative and incremental
• Use-case-driven
• Architecture-centric
• Uses UML as its modeling notation
• Process framework
– Comprehensive set of document templates, process
workflow templates, and process guidelines
– Distributed by IBM/Rational on a CD
27. 27
Rational Unified Process Is Use-
Case-Driven
• Use cases are concise, simple, and understandable by a
wide range of stakeholders
– End users, developers and acquirers understand functional
requirements of the system
• Use cases drive numerous activities in the process:
– Creation and validation of the design model
– Definition of test cases and procedures of the test model
– Planning of iterations
– Creation of user documentation
– System deployment
• Use cases help synchronize the content of different models
28. 28
Rational Unified Process Is
Architecture-Centric
• Architecture is the focus of the elaboration phase
– Building, validating, and baselining the architecture constitute the
primary objective of elaboration
• The Architectural Prototype validates the architecture and
serves as the baseline for the rest of development
• The Software Architecture Description is the primary
artifact that documents the architecture chosen
• Other artifacts derive from architecture:
– Design guidelines including use of patterns and idioms
– Product structure
– Team structure
29. 29
Representing Architecture: The
4+1 View Model
Process
View
Deployment
View
Logical
View
Implementation
View
Programmers
Software management
Performance
Scalability
Throughput
System Integrators
System topology
Delivery, installation
communication
System Engineering
Use-Case
View
Structure
Analysts/
Designers End-user
Functionality
30. 30
InceptionInception ElaborationElaboration ConstructionConstruction TransitionTransition
Process Architecture - Lifecycle
Phases
The Rational Unified Process has four phases:
– Inception - Define the scope of project
– Elaboration - Plan project, specify features, baseline
architecture
– Construction - Build the product
– Transition - Transition the product into end user community
time
32. 32
Iterations and Phases
AnAn iterationiteration is a distinct sequence of activities with anis a distinct sequence of activities with an
established plan and evaluation criteria, resulting inestablished plan and evaluation criteria, resulting in
an executable release (internal or external)an executable release (internal or external)
PreliminaryPreliminary
IterationIteration
Architect.Architect.
IterationIteration
Architect.Architect.
IterationIteration
Devel.Devel.
IterationIteration
Devel.Devel.
IterationIteration
Devel.Devel.
IterationIteration
TransitionTransition
IterationIteration
TransitionTransition
IterationIteration
InceptionInception ElaborationElaboration ConstructionConstruction TransitionTransition
Minor Milestones: Releases
33. 33
Major Workflows Produce Models
Analysis &Analysis &
DesignDesign
Design
Model
Implementation
Model
Test
Model
realized by
implemented by
verified by
RequirementsRequirements
ImplementationImplementation
TestTest
Use-Case
Model
BusinessBusiness
ModelingModeling
Business Model
supported by
34. 34
RUP Overview
Management
Environment
Business Modeling
Implementation
Test
Architecture & Design
Preliminary
Iteration(s)
Iter.
#1
Phases
Process Workflows
Iterations
Supporting
Workflows
Iter.
#2
Iter.
#n
Iter.
#n+1
Iter.
#n+2
Iter.
#m
Iter.
#m+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Workflows group
activities logically
In an iteration,
you walk through
all workflows
35. 35
XP Overview
Characteristics
• Evolutionary development
• Collection of 12 „Best
Practices“
• Focus on working code that
implements customer needs
(rather than documents)
• Testing is a crucial element of
the process
• Focus on flexibility and
efficiency of the process
• Designed for small teams (<10)
Write tests
Planning
Test
Pair Programming
+ Refactoring
Integration
Min.
daily
Every 2-3
weeks
Release
36. 36
XP Practices (I)
• The planning game
– Stakeholder meeting to plan the next iteration
– Business people decide on business value of features
– Developers on the technical risk of features and predicted effort
per feature
• Small releases
– Start with the smallest useful feature set; release early and often,
adding a few features each time
• Metaphor
– Each project has an organizing metaphor, a providing easy to
remember naming conventions
37. 37
XP Practices (II)
• Simple Design
– Always use the simplest possible design that gets the job done
(runs the tests and states intentions of the programmer)
– No speculative genericity
• Testing
– Test-first: write test, then implement it
– Programmers write unit tests and customers write acceptance tests
• Refactoring
– Refactoring is done continuously; the code is always kept clean
38. 38
XP Practices (III)
• Pair programming
– All production code written by two programmers
– One programmer is thinking about implementing the current
method, the other is thinking strategically about the whole system
– Pairs are put together dynamically
• Collective code ownership
– Any programmer that sees an opportunity to add value to any
portion of the code is required to do so at any time
• Continuous integration
– Use of version and configuration management (e.g., CVS)
– All changes are integrated into the code-base at least daily
– The tests have to run 100% before and after the integration
39. 39
XP Practices (IV)
• 40-h week
– Programmers go home on time
– Overtime is a symptom of a serious problem
– No errors by tired developers; better motivated developers
• On-site customer
– Development team has continuous access to a real life
customer/user
• Coding standards
– Everyone codes to the same standards
– Ideally, you should not be able to tell by looking at it who has
written a specific piece of code
40. 40
XP Advantages
• Integrated, simple concept
• Low management overhead (no complicated procedures to
follow, no documentation to maintain, direct
communication, pair programming)
• Continuous risk management (early feedback from the
customer)
• Continuous effort estimation
• Emphasis on testing; tests help in evolution and
maintenance
41. 41
XP Disadvantages
• Appropriate for small teams (up to 10 developers)
only (does not scale)
• Large development groups may require more
structures and documents
• If maintainers are not the people that developed
the code, good documentation is necessary
• Generic design may be necessary to enable
expected future development
42. 42
Reading
• RUP
– Craig Larman, Applying UML and Patterns: An Introduction to Object-
Oriented Analysis and Design and the Unified Process, Prentice-Hall,
2002 (2nd edition)
– Kendall Scott. The Unified Process Explained. Addison Wesley, 2001
• Agile development
– Kent Beck, Extreme Programming: Explained, Addison-Wesley, 1999
– R. Jeffries, C. Hendrikson, A. Anderson, Extreme Programming Installed,
Addison-Wesley, 2001
• http://member.netease.com/~wooce/tip/se/
– Alistair Cockburn, Agile Software Development, Addison-Wesley 2002
• Online-Ressourcen
– http://www.xprogramming.com
– http://www.xprogramming.org
– http://groups.yahoo.com/group/extremeprogramming
– http://c2.com
The UML is a generic modeling language. With UML, you can produce blueprints for any kind of software system.
The Rational Unified Process (RUP) is a generic process that uses UML as a modeling language. RUP can be used for any kind of software system.
The focus of the process is the production of high-quality executables with a minimum of overhead, rather than what documents to produce.
By providing a “written-down”, very detailed set of procedures for developing software according to Rational’s six best practices, the process is easier to apply and repeatable. This results in software projects that are more predicable and successful.
Another feature of the Rational Unified Process is that it is not just theory. It instructs the developer on how to implement the activities using the tools the developer is using.
Finally, the process is available on-line as a Website. While hardcopy books have their place, most developers prefer to reference the process from their desktops when they need help. Both hardcopy and on-line versions are available.
Use of component-based architectures is one of the six best practices already discussed. Architecture is used in the Rational Unified Process as a primary artifact for conceptualizing, constructing, managing, and evolving the system under development. The Rational Unified Process emphasizes early development and validation of software architecture as a core concept. It defines two primary artifacts related to architecture: the Software Architecture Description (SAD) which describes the architectural views relevant to the project and the Architectural Prototype. The Rational Unified Process also defines a worker, called the Architect, who is responsible for the architecture. The bulk of the activities related to architectural design are described in the analysis and design workflow, but it spills over to the requirements workflow, the implementation workflow, and the project management workflow.
Many different parties are interested in the architecture (e.g., the system analyst, the designers, the end uses, etc.). To allow these parties or stakeholders to communicate, discuss and reason about architecture, we need to have an architectural representation that they understand. Because different stakeholders have different concerns and because architecture is quite complex, multiple views are required to represent architecture adequately. An architectural view is a simplified description (an abstraction) of a system from a particular perspective or vantage point, covering particular concerns,and omitting entities that are not relevant to this perspective.
While many views of architecture can be useful, the Rational Unified Process identifies 4+1 views as a standard set:
The logical view addresses the functional requirements of the system. It is an abstraction of the design model, identifying major design packages, subsystems and classes.
The implementation view describes the organization of static software modules in the development environment, in terms of packaging, layering, and configuration management.
The process view addresses the concurrent aspect of the system at run-time: tasks, threads or processes, and their interactions.
The deployment view shows how the various executables and other run-time components are mapped onto the underlying platforms or computing nodes.
The use-case view contains a few key scenarios or use cases that are used to drive the architecture and to validate it.
During Inception, we define the scope of the project, what is included, and what is not. This is done by identifying all the actors and use cases, and by drafting the most essential use cases (usually approximately 20% of the complete model). A business plan is developed to determine whether resources should be committed to the project.
During Elaboration, we focus on two things: get a good grasp of the requirements (90% complete) and establish an architectural baseline. If we have a good grasp of the requirements and the architecture, we can eliminate a lot of the risks and will have a good idea what amount of work remains to be done. Detailed cost/resource estimations can be made at the end of Elaboration.
During Construction, we build the product in several iterations up to a beta release.
During Transition, we transition the product to the end user and focus on end user training, installation, and support.
The amount of time spent in each phase varies. For a very complex project with a lot of technical unknowns and unclear requirements, Elaboration may include 3-5 iterations. For a very simple project where requirements are known and the architecture is simple, Elaboration may include only a single iteration.
At each of the major milestones,the project is reviewed and a decision made as to whether to proceed with the project as planned, to abort the project, or to revise it. The criteria used to make this decision vary by phase.
The evaluation criteria for the inception phase (LCO) include: stakeholder concurrence on scope definition and cost/schedule estimates; requirements understanding as evidenced by the fidelity of the primary use cases; credibility of cost/schedule estimates, priorities, risks, and development process; depth and breadth of any architectural prototype; actual expenditures versus planned expenditures.
The evaluation criteria for the elaboration phase (LCA) include: stability of the product vision and architecture; resolution of major risk elements; adequate planning and reasonable estimates for project completion; stakeholder acceptance of the product vision and project plan; acceptable expenditure level.
The evaluation criteria for the construction phase (IOC) include: stability and maturity of the product release (I.e., is it ready to be deployed?); readiness of the stakeholders for the transition; acceptable expenditure level.
At the end of the transition phase, a decision is made whether to release the product. This will be based primarily on the level of user satisfaction achieved during the transition phase. Often this milestone coincides with the initiation of another development cycle to improve or enhance the product. In many cases, this new development cycle by already be underway.
Within each phase, there is a series of iterations. The number of iterations per phase will vary. Each iteration results in an executable release encompassing larger and larger subsets of the final application.
An internal release is kept within the development environment and (optionally) demonstrated to the stakeholder community. An external release is provided to stakeholders (usually users) for installation in their own environment. External releases are much more expensive (they require user documentation and technical support) and normally occur only during the transition phase.
The end of an iteration marks a minor milestone. It is a point in time when technical results are assessed and future plans revised as necessary.
The Rational Unified Process is a model-driven approach. Several models are needed to fully describe the evolving system. Each major workflow produces one of those models. The models are developed incrementally across iterations.
The Business Model is a model of what the business processes are and the business environment. It can be used to generate requirements on supporting information systems.
The Use-Case Model is a model of what the system is supposed to do and the system environment.
The Design Model is an object model describing the realization of use cases. It serves as an abstraction of the implementation model and its source code.
The Implementation Model is a collection of components, and the implementation subsystems that contain them.
The Test Model encompasses all of the test cases and procedures required to test the system.
This graphic illustrates how phases and iterations, or the time dimension, relates to the development activities performed, or the workflow dimension. The relative size of the color area indicates how much of the activity is performed in each phase/iteration.
Each iteration involves activities from all workflows. The relative amount of work related to the workflows changes between iterations. For instance, during late Construction, the main work is related to Implementation and Test and very little work on Requirements is done.
Note that requirements are not necessarily complete by the end of Elaboration. It is acceptable to delay the analysis and design of well-understood portions of the system until Construction because they are low in risk.