1. Software Production Layout
Software Process
Software Process
Project
Project
instantiated by Project
Project
Project
Project
consists of consists of
Project Execution
Project Execution
Project Management ••Analysis
Analysis
Project Management ••Design
••Planning
Planning Design
••Control ••Implementation
Implementation
Control ••Test
Test
uses
uses
Project System of
Project
Management methods for
Management System of Software
Software
Methodology software product
Methodology methods for Development
Development
development
project Methodology
Methodology
is a management
is a
2. A Definition of Process
W. Humphrey and P. Feiler: "A process is a set of partially
W. Humphrey and P. Feiler: "A process is a set of partially
ordered steps intended to reach a goal..."(to produce and
ordered steps intended to reach a goal..."(to produce and
maintain requested software deliverables). A software process
maintain requested software deliverables). A software process
includes sets of related artifacts, human and computerized
includes sets of related artifacts, human and computerized
resources, organizational structures and constraints.
resources, organizational structures and constraints.
B
A D
C
Relationships
of all tasks (workflow)
PROCESS
Skills, Tools
Training,
Motivation, &
Management
3. Rational Unified Process®
• The Rational Unified Process® is a Software
Engineering Process. It provides a disciplined
approach to assigning tasks and responsibilities
within a development organization. Its goal is to
ensure the production of high-quality software that
meets the needs of its end-users, within a
predictable schedule and budget.
4. The Unified Process of Software
Development
• The key feature:Software development is done in a
series of fixed periods, for example, between 2 and
6 weeks. Each period is called as iteration.
• At the end of each iteration, we have an executable
system.
• Each iteration has its own requirement analysis,
design, coding and testing.
• The software development is incremental.
Implement New features added apart from the
User’s suggested changes.
5. Rational Unified Process (RUP)
time
Phases
Process Workflows Inception Elaboration Construction Transition
Business Modeling
t
conten
Requirements
Analysis & Design
Implementation
Test
Deployment
Supporting Workflows
Configuration & Change Mgmt
Project Management
Environment
Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1
Iterations
6. Spiral Development
Product:class Product: requirements
models + specifications
Step n:
Step n+1: Analyze
Design requirements
complete
targeted
requirements
Step n+2: Step n+3:
Implement Test
Product: code + Product: test results +
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
7. Incremental Development
Iteration No. 1 2 3 867 868
Update SPMP1
Test whole
Integrate Update Test documentation
Test units Update source code
Implement
Design Update SDD2
Analyze
requirements Update SRS3
1 2
Software Project Mangement Plan (chapter 2); Software Design Document (chapter 5);
3
Software Requirements Specification (chapter 3);
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
8. The Unified Software Development Process:
Classification of Iterations
• Inception iterations: preliminary interaction
with stakeholders
– primarily customer
– users
– financial backers etc.
• Elaboration iterations : finalization of what’s
wanted and needed; set architecture baseline
• Construction iterations : results in initial
operational capability
• Transition iterations : completes product
release
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
9. USDP vs. Standard Terminology ½ (Booch, Jacobson &
Rumbaugh)
Classification of iterations
Individual iteration
Inception Elaboration Construction Transition
Prelim. Iter. .. Iter. Iter. ….. Iter. Iter. … Iter.
iterations #1 #n #n+1 #m #m+1 #k
Requirements
Analysis
USDP calls these
“core workflows”
Design
Implemen- (Classically called
tation “phases”)
Test
10. Unified Process Matrix
Jacobson et al: USDP
Inception Elaboration Construction Transition
Prelim. Iter. .. Iter. Iter. ….. Iter. Iter. ….. Iter.
iterations #1 #n #n+1 #m #m+1 #k
Requirements Amount of effort expended
on the requirements phase
during the first Construction
Analysis iteration
Design
Implemen-
tation
Test
11. The Six USDP Models (Views of the
Application)
Use-case Test
model model
Analysis Implementation
model model
Design Deployment
model model
Graphics reproduced with permission from Corel.
12. Life of the Unified Process
Inception Elaboration Construction Transition
The seed idea for the The architecture The software is brought The software is
development is brought to is defined from an executable turned over to the
the point of being sufficiently architectural baseline user community
well founded to warrant ... ... to the point where it is
entering into the elaboration ready to be transitioned Iteration Iteration n
phase to the user community n-1
Iteration 1 Iteration 2 ... ...
...
Inception Elaboration Construction Transition Inception Elaboration Construction Transition
The seed idea for the The architecture The software is brought The software is Inception Elaboration Construction Transition Inception Elaboration Construction Transition
development is brought to is defined from an executable turned over to the The seed idea for the The architecture The software is brought The software is The seed idea for the The architecture The software is brought The software is The seed idea for the The architecture The software is brought The software is
the point of being sufficiently architectural baseline user community
w ell founded to warrant ... ... to the point where it is
development is brought to is defined from an executable turned over to the development is brought to is defined from an executable turned over to the development is brought to is defined from an executable turned over to the
the point of being sufficiently architectural baseline user community
entering into the elaboration
phase
ready to be transitioned
to the user community
Iteration
n-1
Iteration n
well founded to warrant ... ... to the point where it is
the point of being sufficiently
... ...
architectural baseline user community the point of being sufficiently
... ...
architectural baseline user community
... ... Iteration Iteration n well founded to warrant to the point where it is well founded to warrant to the point where it is
Iteration 1 Iteration 2 entering into the elaboration ready to be transitioned Iteration Iteration n Iteration Iteration n
n-1 entering into the elaboration ready to be transitioned entering into the elaboration ready to be transitioned
phase to the user community
phase to the user community n-1 phase to the user community n-1
... ...
Iteration 1 Iteration 2
Iteration 1 Iteration 2 ... ... Iteration 1 Iteration 2 ... ...
Cycles
Birth Death
12
13. Unified Process Models
Use Case Model
specified by Models Use Cases verified by
and their relationships to
users
Analysis Model Test Model
Refines the use cases and
Describes the test cases
makes an initial allocation of
that verify the use cases
behavior to set of objects
realized by distributed by
Design Model
Defines the static structure
of the system as Deployment Model
subsystems, classes and Defines the physical nodes
implemented by of computers and the
interfaces and defines the
use cases as collaborations mapping of the components
of subsystems, classes and to those nodes
interfaces Implementation
Model
Includes components
(representing source code)
and the mapping of classes to
components 13
14. The Four Ps in Software Development -
People, Project, Product and Process
• People - The architects, developers, testers and the supporting
management, users, customers, and stakeholders - Actual
Humans!
• Project - The organizational element through which software is
managed.
• Product - Artifacts that are created during the life of the project,
e.g., models, source code.
• Process - A definition of the complete set of activities needed to
transform users’ requirements into a product. A process is a
template for creating projects.
– Tools - Software that is used to automate the activities defined in the
process.
14
15. Cycles and Phases
Each cycle results in a new release of the system,
Each cycle results in a new release of the system,
and each is a product ready for delivery. This
and each is a product ready for delivery. This
product has to accommodate the specified needs.
product has to accommodate the specified needs.
The development cycle is divided in four consecutive
phases
• Inception: a good idea is developed into a vision of the
end product and the business case for the product is
presented.
• Elaboration: most of the product requirements are
specified and the system architecture is designed.
• Construction: the product is built – completed software
is added to the skeleton (architecture)
• Transition: the product is moved to user community
(beta testing, training …)
16. Inception phase
• Establishing the project's software scope and boundary
conditions, including an operational vision, acceptance
criteria and what is intended to be in the product and what is
not.
• Discriminating the critical use cases of the system, the
primary scenarios of operation that will drive the major
design tradeoffs.
• Exhibiting, and maybe demonstrating, at least one candidate
architecture against some of the primary scenarios.
• Estimating the overall cost and schedule for the entire project
(and more detailed estimates for the elaboration phase that
will immediately follow).
• Estimating potential risks (the sources of unpredictability)
• Preparing the supporting environment for the project.
17. Elaboration phase
• Defining, validating and baselining the architecture as rapidly
as practical.
• Refining the Vision, based on new information obtained
during the phase, establishing a solid understanding of the
most critical use cases that drive the architectural and
planning decisions.
• Creating and baselining detailed iteration plans for the
construction phase.
• Refining the development case and putting in place the
development environment, including the process, tools and
automation support required to support the construction
team.
• Refining the architecture and selecting components.
Potential components are evaluated and the make/buy/reuse
decisions sufficiently understood to determine the
construction phase cost and schedule with confidence. The
selected architectural components are integrated and
assessed against the primary scenarios.
18. Construction phase
• Resource management, control and process
optimization
• Complete component development and testing
against the defined evaluation criteria
• Assessment of product releases against
acceptance criteria for the vision.
19. Transition phase
• Executing deployment plans.
• Finalizing end-user support material.
• Testing the deliverable product at the development site.
• Creating a product release.
• Getting user feedback.
• Fine-tuning the product based on feedback.
• Making the product available to end users.
20. Rational Unified Process®
Best Practices:
• Develop software iteratively
• Manage requirements
• Use component-based architectures
• Visually model software
• Verify software quality
• Control changes to software
21. 1. Manage Your Requirements
• Elicit, organize, and document required
functionality and constraints
• Track and document tradeoffs and decisions
• Business requirements are easily captured and
communicated through use cases
• Use cases are important planning instruments
Use-Case Model
realization influenced by verifies
Design Model
Implementation Model Test Model
22. 2. Develop Software Iteratively
– An initial design will likely be flawed with
respect to its key requirements
– Late-phase discovery of design defects results
in costly over-runs and/or project cancellation
Requirements
Analysis & Design
Planning
Implementation
Initial
Planning Management
Environment
Deployment
Evaluation
Test
23. quirements
alysis
Waterfall Development
Design
T I M E
Code & Unit
Testing
Subsystem
Testing
System T
24. Requirements
Analysis
Design
Code & Unit
Testing
T I M E
Subsystem
Testing
System
Testing
Time
R
I
S
K
Waterfall Development: Risk vs.
25. Risk Profile of an Iterative
Development
Waterfall
Inception
Elaboration
Risk
Construction
Transition
Preliminary Architect. Architect. Devel. Devel. Devel. Transition Transition Post-
Iteration Iteration Iteration Iteration Iteration Iteration Iteration Iteration deployment
Time
26. Iterative Development
Characteristics
– Critical risks are resolved before making large
investments
– Initial iterations enable early user feedback
– Testing and integration are continuous
– Objective milestones provide short-term focus
– Progress is measured by assessing
implementations
– Partial implementations can be deployed
27. 3. Employ Component-based
Architecture
• Design, implement and test your architecture up-front!
• A systematic approach to define a “good” architecture
Resilient to change by using well-defined interfaces
By using and reverse engineering components
Derived from top rank use cases
Application-
specific
Business-
specific
Component-based Middleware
Architecture with
layers System-
software
28. 4. Model Software Visually
• Aiding understanding of complex systems
• Exploring and comparing design alternatives at
a low cost
• Forming a foundation for implementation
• Capturing requirements precisely
• Communicating decisions unambiguously
Sub Systems
Visual
Modeling Classes
raises the level
of abstraction Code
29. 5. Verify Software Quality
• Create tests for each key scenario to ensure that all
requirements are properly implemented
• Unacceptable application performance hurts as much
as unacceptable reliability
• Verify software reliability - memory leaks, bottle necks
• Test every iteration - automate test!
Deployment Development
Software
problems
Cost
are 100 to 1000
times
more costly to
find
30. 6. Control Changes to Software
• Control, track and monitor changes to enable iterative
development
• Establish secure workspaces for each developer
– Provide isolation from changes made in other
workspaces
– Control all software artifacts - models, code, docs,
etc.
• Automate integration and build management
Workspace Parallel
Management Development
CM is more
than just REPORTALERT
check-in and Process Build
check-out Integration Management
31. Summary: Best Practices of Software Engineering
• The result is software that is
– On Time
– On Budget
– Meets Users Needs
Analyst Performance
Engineer
Develop Iteratively
Manage
Requirements
Use Component Tester Developer
Best Architectures Project
Practices Model Visually Manager
Verify Quality
Control Release
Change
Engineer
32. Static Structure of the Process
• A process describes who is doing
what, how, and when using
certain modeling elements:
33. Elements of a process
• Workers (Roles) define the behavior and responsibilities of
an individual (designer, analyst, programmer ...), or a group
of individuals working together as a team.
• Artifacts are things that are produced, modified, or used by
a process (model, document, source code …).
• Activities are performed by workers to create or update
some artifacts (review design, compile code, perform test
…).
• Workflows are sequences of activities that produce results
of observable value (business modeling, implementation …).
33
34. Management and Technical
Artifacts
The most important kind of artifact are models.
A model is a simplification of reality, created to better
A model is a simplification of reality, created to better
understand the system being created.
understand the system being created.
Technical artifacts may be divided into:
• Requirements set: business, domain, use case, and
analysis models
• Design set: design, and test models
• Implementation set: implementation model, source
code, configuration, and data files
• Deployment set: deployment model, information about
the way software is actually packaged
35. Core Engineering Workflows
• Business modeling describes the structure and
dynamics of the organization
• Requirement describe the use case-based method
for eliciting requirements
• Analysis and design describe the multiple
architectural views
• Implementation takes into account sw
development, unit test, and integration
• Test describes test cases and procedures
• Deployment covers the deliverable system
configuration
36. Workflows and Models
Business Modeling Business Process Model Domain Model
Use Case Model UML diagrams
Requirements
provide views into
each model
Analysis Analysis Model
Design Desing Model Deployment Model
Implementation Implementation Model
Test Test Model
Each workflow is associated with
one or more models
38. Configuration & Change Management
• Supports development methods
• Maintains product integrity
• Ensures completeness & correctness of
configured product
• Provides stable environment within which to
develop product
• Restricts changes to artifacts based on project
policies
• Provides an audit trail on why, when & by whom
any artifact was changed
39. Project Management
• A framework for managing software-intensive
projects
• Practical guidelines for planning, staffing,
executing & monitoring projects
• A framework for managing risk
40. Environment
• Design, implement and manage the project’s required
technical environments
• Define the technical architectures for the development,
system validation, testing & staging/release
management environments
• When possible, standard architectural models for given
types of platforms should be utilized when defining the
production environment
41. Bringing It All Together... In an iteration,
you walk through
all workflows
Phases
Process Workflows Inception Elaboration Construction Transition
Business Modeling
Requirements
Analysis & Design
Implementation
Test
Deployment
Supporting Workflows
Configuration & Change Mgmt
Project Management
Environment
Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1
Iterations
42. Tools
• The success of process adoption is
significantly improved by the use of
appropriate supporting tools.
• Tool Mentors provide detailed descriptions of
how to perform specific process activities or
steps, or produce a particular artifact or report,
using one or more tools.
45. Choose Appropriate Life Cycle
• TCL is highly predictive
• Prototyping, Spiral and UP life cycle models are highly
adaptive
Predictive versus adaptive approaches to the SDLC
Hinweis der Redaktion
Inception Defines the scope of the project. A business plan is often created to determine whether resources should be committed or not. The model is 20% complete. Elaboration Plan project, specify features, baseline architecture. Requirements are firmed up, we’re now 80% complete. A detailed cost/resource estimation can be drawn up. Construction Build the product. Several iterations. Transition Move the product into and end user environment. Training, installation and support. An iteration is a distinct sequence of activities based on an established plan and evaluation criteria, resulting in an executable release (internal or external) A workflow shows all the activities you might go through to produce a particular set of artifacts – more later.
