1. Chapter 15, Software Life Cycle
Horizontal Sunrise, 11 o’clock in the morning, Cassin Ridge, Mt. McKinley, 1985, Picture by Bernd Bruegge

2. Outline of Today’s Lecture
Modeling the software life cycle
Sequential models
Pure waterfall model
V-model
Sawtooth model
Iterative models
Boehm’s spiral model
Unified Process
Entity-oriented models
Issue-based model
A profesional version, combining an iterative softwaer lifecycle model with a project management approach focusing the parallel definition of a plan and a software architecture is the unified process.

3. Definitions Software life cycle: Software development methodology:
Set of activities and their relationships to each other to support the development of a software system
Software development methodology:
A collection of techniques for building models applied across a software life cycle.
Development activities deal with the complexity by constructing and validating models of the application domain or the system. Development activities include: requirements elicitation, analysis, system design, object design. Implementation,. testing
A methodology is a collection of methods for solving a class of problems and specifies how and when each method should be used.
A seafood cookbook with a collection of recipes is a methodology for preparing seafood if it also contains advice on how ingredients should be used and what to do if not all ingredients are always available. Royce’s methodology [Royce, 1998], the Object Modeling Technique (OMT [Rumbaugh et al., 1991]), the Booch methodology [Booch, 1994], and Catalysis [D’Souza & Wills, 1999], are object-oriented methodologies for developing software.

4. Typical Software Life Cycle Questions
Which activities should we select for the software project?
What are the dependencies between activities?
How should we schedule the activities?
To find these activities and dependencies we can use the same modeling techniques we use for software development:
Functional Modeling of a Software Lifecycle
Scenarios
Use case model
Structural modeling of a Software Lifecycle
Object identification
Class diagrams
Dynamic Modeling of a Software Lifecycle
Sequence diagrams, statechart and activity diagrams

5. Functional Model of a simple life cycle model
<<include>>
Software development
Problem definition
System development
System operation
So far we used UML as a modeling language for describing and communicating about systems. In this chapter, we focus on models of the software development process, called software life cycle models.
Modeling the software life cycle is a difficult undertaking, because it is a complex and changing system. As software systems, software life cycles can be described by several different models.
Most proposed life cycle models have focused on the activities of software development and represented them explicitly as first class objects. This view of the software life cycle is called activity centered.
An alternative view of the software life cycle is to focus on the work products created by these activities. This alternate view is called entity centered. The activity-centered view leads participants to focus on how work products are created.
The entity-centered view leads participants to focus on the content and structure of the work products. This slide shows a simple life cycle for software development using three activities: Problem definition, System development, and System operation.
Client
Project manager
Developer
End user
Administrator

6. Activity Diagram for the same Life Cycle Model
This slide shows an activity-centered view of this simplistic life cycle model.
The associations between the activities show a linear time dependency, which is implied by the use of the activity diagram notation: The problem statement precedes system development, which in turn precedes system operation. Alternate time dependencies are possible
Software development goes through a linear progression of states
called software development activities

7. Another simple Life Cycle Model
System
upgrade
activity
Market
creation
development
For example, in the software life cycle shown in this slide, the activities System development and Market creation can be done concurrently
System Development and Market creation can be done in parallel.
They must be done before the system upgrade activity

8. Two Major Views of the Software Life Cycle
Activity-oriented view of a software life cycle
Software development consists of a set of development activities
All the examples so far
Entity-oriented view of a software life cycle
Software development consists of the creation of a set of deliverables.

9. Entity-centered view of Software Development
This slide shows an entity centered view of the model shown in the previous slides.
Software development produces four entities, a Market survey document, a Requirements specification document, an Executable system and a Lessons learned document
Software development consists of the creation of a
set of deliverables

10. Combining Activities and Entities in One View
The activity-centered view and the entity-centered view are complementary, as illustrated in this slide.
For every product there is one or more activity that generates it.
The Problem definition activity uses a Market survey document as input and generates a Requirements specification document.
The System development activity takes the Requirements specification document as input and produces an Executable system.
System operation generates a Lessons learned document that could be used during the development of the next product.
Alternatively, every activity generates one or more products.

11. IEEE Std 1074: Standard for Software Life Cycle Activities
Process Group
IEEE Std 1074
Project
Management
Pre-
Development
Develop-
ment
Post-
Development
Cross-
Development
(Integral Processes)
> Project Initiation
>Project Monitoring
&Control
> Software Quality
Management
> Requirements
> Design
> Implemen-
tation
> Installation
> Operation &
Support
> Maintenance
> Retirement
> V & V
> Configuration
Management
> Documen-
tation
> Training
> Concept
Exploration
> System
Allocation
The life cycle activities are defined by the IEEE 1074 standard [IEEE Std ].
This standard introduces precise definitions that enable project participants to understand and communicate effectively about the life cycle..
The goal of the standard is to establish a common framework for developing life cycle models and provide examples for typical situations. The main activities introduced by the standard can be described by using UML diagrams.
A process is a set of activities that is performed towards a specific purpose (e.g., requirements, management, delivery). The IEEE standard lists a total of 17 processes. The processes are grouped into higher levels of abstractions called process groups.
Examples of process groups are project management, pre-development, development, and post-development. Examples of processes in the development process group include:
the Requirements Process, during which the developers develop the system models
the Design Process, during which developers decompose the system into components
the Implementation Process, during which developers realize each componen
From the developers’ point of view, the first processes (i.e., the Project Management Processes, and the Predevelopment Processes) have often already been initiated before their involvement with the project.
Process

12. Object Model of the IEEE 1074 Standard
Software Life Cycle
Money *
Process Group
Time
Participant
Model of the software life cycle (UML class diagram).
A software life cycle consists of process groups, which in turn consist of processes.
A process accomplishes a specific purpose (e.g., requirements, design, installation).
A process consists of activities, which are in turn consists of sub-activities or tasks.
Tasks represent the smallest piece of work that is relevant to management.
Tasks consume resources and produces one or more work products. A project is an instance of a software life cycle
During planning, activities are decomposed into project specific tasks, are given a start and ending date
and assigned to a team or a project participant
During the project, actual work is tracked against planned tasks, and resources are reallocated to respond to problems *
Process *
Resource *
Work Unit
consumed by * *
Activity
Task
Work Product
produces

13. Life Cycle Modeling
Many models have been proposed to deal with the problems of defining activities and associating them with each other
The first model proposed was the waterfall model [Royce]
Spiral model [Boehm]
Objectory process [Jacobsen]
Rational process [Kruchten]
Unified process [Jacobsen, Booch, Rumbaugh]
Royce in 1970

14. The Waterfall Model of the Software Life Cycle
Requirements
Process
System
Allocation
Concept
Exploration
Design
Implementation
Installation
Operation &
Support Process
Verification
& Validation
The waterfall model was first described by Royse [Royce, 1970].
The waterfall model is an activity-centered life cycle model that prescribes a sequential execution of a subset of the development processes and management processes we have mentioned so far.
This slide shows UML activity diagram of the waterfall model adapted from [Royce, 1970] using IEEE 1074 names; project management and cross-development processes are omitted.
The requirements activities are all completed before the system design activity starts.
The goal is to never turn back once an activity is completed. The key feature of his model is the constant verification activity (called “verification step” by Royse) that ensures that each development activity does not introduce unwanted or deletes mandatory requirements.
This model provides a simple (or even simplistic) view of software development that measures progress by the number of tasks that have been completed.
The model assumes that software development can be scheduled as a step-by-step process that transforms user needs into code
adapted from [Royce 1970]

15. From the Waterfall Model to the V Model
System
Testing
Unit
Integration
Acceptance
Requirements
Engineering
Requirements
Analysis
System Design
Object Design
The V-model is a variation of the waterfall model that makes explicit the dependency between development activities and verification activities.
The difference between the waterfall model and the V model is that the latter makes explicit the notion of level of abstraction.
All activities from requirements to implementation focus on building more and more detailed representation of the system, whereas all activities from implementation to operation focus on validating the system. This slide shows origin of the V-model form the waterfall model.
Implemen-
tation
Integration Testing
System
Testing
Unit

16. Activity Diagram of the V Model
Is validated by
precedes
This model is a UML activity diagram of the V-Model (adapted from [Jensen & Tonies, 1979]). It shows 2 types of dependencies: Precedes (which is a temporal dependency) and “is validated by” which shows
The horizontal object flow denotes the information flow between activities of same abstraction level. The V-shape layout of the activities was conserved to reflect the original drawing. However, the layout of the activities has no semantics in UML.
Higher levels of abstractions of the V-model deal with the requirements in terms of elicitation and operation. The middle-part of the V-model focuses on mapping the understanding of the problem into a software architecture. The lower level of the V-model focuses on details such as the assembly of software components and the coding of new ones.
For example, the goal of the Unit Test activity is to validate units against their description in the detailed design. The Component Integration and Test activity validates functional components against the preliminary (or high-level) design. In many aspects, the waterfall model and its variants are simplistic abstractions of the software development process.
The V-model, for example, does not distinguish between the developers and the users perception. It basically asks the user to follow the developer all the way into the abyss of detailed design and implementation! One attempt, to deal with the different levels of abstraction was the Sawtooth Model.
Problem with the V-Model:
Developers Perception =
User Perception

17. Properties of Waterfall-based Models
Managers love waterfall models
Nice milestones
No need to look back (linear system)
Always one activity at a time
Easy to check progress during development: “The system is 90% coded”, “We have done 20% of our tests”
However, software development is non-linear
While a design is being developed, problems with requirements are identified
While a program is being implemented, design and requirement problems are found
While a program is tested, coding errors, design errors and requirement errors are found.
In practice, software development is not sequential
The development stages overlap
The tendency to freeze parts of the development leads to systems the client does not want and which are badly structured as design problems are circumvented by tricky coding

18. Spiral Model 18
The spiral model focuses on addressing risks incrementally, in order of priority.
It consists of the following set of activities
Determine objectives and constraints
Evaluate alternatives
Identify risks
Resolve risks by assigning priorities to risks
Develop a series of prototypes for the identified risks starting with the highest risk
Use a waterfall model for each prototype development
If a risk has successfully been resolved, evaluate the results of the round and plan the next round
If a certain risk cannot be resolved, terminate the project immediately
This set of activities is applied to a couple of so-called rounds.
Boehm’s spiral model [Boehm, 1987] is an activity-centered life cycle model that was devised to address the source of weaknesses in the waterfall model, in particular, to accommodate infrequent change during the software development. It based on the same activities as the waterfall model, however, it adds several activities such as risk management, reuse, and prototyping to each activity.
These extended activities are called cycles or rounds.

19. Rounds in Boehm’s Spiral Model
Concept of Operations
Software Requirements
Software Product Design
Detailed Design
Code
Unit Test
Integration and Test
Acceptance Test
Implementation
For each round go through these activities:
Define objectives, alternatives, constraints
Evaluate alternatives, identify and resolve risks
Develop and verify a prototype
Plan the next round.
Each round follows the waterfall model and includes the following activities:
Determine objectives
Specify constraints
Generate alternatives
Identify risks
Resolve risks
Disccourse on Prototyping

20. Diagram of Boehm’s Spiral Model
The spiral model focuses on addressing risks incrementally, in order of priority.
Boehm’s spiral model distinguishes the following rounds: Concept of Operation, Software Requirements, Software Product Design, Detailed Design, Code, Unit Test, Integration and Test, Acceptance Test, Implementation
Each round is composed of four phases.
The first 3 rounds are shown in a polar coordinate system.
The polar coordinates r = (l, a) of a point indicate the resource spent in the project and the type of activity

21. Round 1, Concept of Operations: Determine objectives,alternatives & constraints
Project
Start
During the first phase (upper left quadrant), developers explore alternatives, define constraints, and identify objectives.

22. Round 1, Concept of Operations: Evaluate alternatives, identify & resolve risks
Risk Analysis
During the second phase (upper right quadrant), developers manage risks associated with the solutions defined during the first phase and specify a prototype to be built in the next phase

23. Round 1, Concept of Operations: Develop and validate
During the third phase (lower right quadrant), developers realize and validate a prototype or the part of the system associated with the risks addressed in this round.
Round: Concept of Operation
Activity: Develop and Validate

24. Round 1, Concept of Operations: Prepare for Next Activity
The fourth phase (lower left quadrant) focuses on the planning of the next round based on the results produced in the current round.
Requirements and
Life cycle Planning

25. Round 2, Software Requirements: Determine Objectives,Alternatives & Constraints
Start
of Round 2
The last phase of the round is usually conducted as a review involving the project participants, including developers, clients, and users. This review covers the artifacts developed during the previous and current rounds and the plans for the next round.

26. Comparison of Projects
Project P1
To summarize, The spiral model focuses on addressing risks incrementally, in order of priority.
Boehm’s spiral model distinguishes the following rounds: Concept of Operation, Software Requirements, Software Product Design, Detailed Design, Code, Unit Test, Integration and Test, Acceptance Test, Implementation
Each round is composed of four phases. The first 3 rounds are shown in a polar coordinate system.
The polar coordinates r = (l, a) of a point indicate the resource spent in the project and the type of activity
The size of the arrow indicates the type of current activity in of the project (where are we?) as well as the resources spent in the project (how much money did we spend so far?), which would allow a comparison of projects based on their location in the diagram. Project P1 is currently in risk analysis and has not spent as many resources as Project P2 which is currently developing and evaluating a prototype.
Project P2

27. Outline of Today’s Lecture
Modeling the software life cycle
Sequential models
Pure waterfall model
V-model
Sawtooth model
Iterative models
Boehm’s spiral model
Unified Process
Entity-oriented models
Issue-based model
A profesional version, combining an iterative softwaer lifecycle model with a project management approach focusing the parallel definition of a plan and a software architecture is the unified process.

28. Unified Process The Unified Process is another iterative process model
There are 4 states of a software system developed with the Unified Process
Inception, Elaboration, Construction, Transition
Several Artifacts Sets
Management Set, Engineering Set
Several Workflows (7)
Management, Environment, Requirements, Design, Implementation, Assessment, Deployment
Each iteration is managed as a software project
Project participants are called stakeholders.
Where are we? So far we have looked at the software lifecycle from a project’s point of view:
“Hey, we have to do this, what activities should we use?”
Today, we look at an industrial strenght software lifecycle process from a business point of view
Example: A company doing research and producing software commercially.
Purpose: Distinguish between research systems (“prototypes”) and real products
States of a software project managed with the Unified Process:
Inception, Elaboration, Construction, Transition
Artifacts Sets:
Management Set, Engineering Set
Workflows:
Management, Environment, Requirements, Design, Implementation, Assessment, Deployment
Iterations

29. The Unified Process The Unified Process supports the following
Evolution of project plans, requirements and software architecture with well-defined synchronization points
Risk management
Evolution of system capabilities through demonstrations of increasing functionality
Big emphasis on the difference between engineering and production
This difference is modeled by introducing two major stages:
Engineering stage
Production stage.
Historical note: The Unified Process is based on Ivar Jacobsen’s Objectory, a CASE Tool developed by Ericsson.
Emphasis on the difference between research/development and production
In the Unified Process this difference is modeled by introducing two major stages.
Engineering Stage
Production Stage
This is shown on the next slide

30. Difference: Engineering vs. Production
Engineering Stage:
Focuses on analysis and design activities, driven by risks, unpredictable issues, smaller teams
Production Stage:
Focuses on construction, test and deployment, driven by more predictable issues, artifacts and quality assessment, larger teams
Focus Factor
Risk
Activities
Artifacts
Quality Assessment
Engineering Stage
Schedule, technical feasibility
Planning, Analysis, Design
Requirement Analysis and System Design Documents
Demonstration, Inspection
Production Stage
Cost
Implementation, Integration
Baselines, Releases
Testing

31. Phases in the Unified Process
The 2 major stages are decomposed into 4 phases
Engineering stage
Inception phase
Elaboration phase
Production phase
3. Construction phase
4. Transition phase
Inception
Elaboration
Note: Stages and phases are nothing else but arbitrary names of the states
(actually superstates and states) of a project.
Transition from
engineering to
production stage
Construction
Transition
The phases describe states of the software system to be developed.

32. Inception Phase: Objectives
Establish the project’s scope
Define acceptance criteria
Identify the critical use cases and scenarios
Demonstrate at least one candidate software architecture
Estimate the cost and schedule for the project
Define and estimate potential risks
Establish the project’s scope, in particular what is included and what is not included in the project to develop the system.
Define acceptance criteria for the software system
Identify the critical use cases of the system and primary scenarios of operation that will drive the major design trade-offs.
Demonstrate at least one candidate software architecture against some of the core scenarios
Estimate the cost and schedule for the entire project (including detailed estimates for the elaboration phase)
Define and estimate potential risks (sources of unpredictability)

33. Elaboration Phase: Objectives
At the end of this phase, the “engineering” of the system is complete
A decision must be made:
Commit to production phase?
Move to an operation with higher cost risk and inertia (i.e. bureaucracy)
Main questions:
Are the system models and project plans stable enough?
Have the risks been dealt with?
Can we predict cost and schedule for the completion of the development for an acceptable range?
Most critical of the four phases
At the end of this phase, the “engineering” of the system is complete, and the organization faces the decision:
- Shall we commit to the production phase?
Shall we go from a low cost risk to an operation with higher cost risk and substantial inertia (i.e. bureaucracy).
The main question is: Can the organization commit to a fixed-price construction phase?
- Are the system models and project plans stable enough?
- Have the risks been dealt with?
- Can we predict cost and schedule for the completion of the development for an acceptable range?
acceptable: % of the predicted cost
not acceptable: 100% above predicted cost

34. Construction Phase: Objectives
Minimize development costs by optimizing resources
Avoid unnecessary restarts (modeling, coding)
Achieve adequate quality as fast as possible
Achieve useful version
Alpha, beta, and other test releases
Minimize development costs by optimizing resources and avoiding unnecessary “scrap and rework”
Achieve adequate quality as rapidly as practical
Achieve useful version (alpha, beta, and other test releases)

35. Transition Phase The transition phase is entered
when a baseline is mature enough that it can be deployed to the user community
For some projects the transition phase is
the starting point for the next version
For other projects the transition phase is
a complete delivery to a third party responsible for operation, maintenance and enhancement of the software system.
The transition phase is entered
when a baseline is mature enough that it can be deployed to the user community
This typically requires that a usable subset of the system has been built with acceptable quality levels and user documents.
For some projects the transition phase coincides with the lifecycle starting point for the next version of the software system.
For other projects the transition phase coincides with a complete delivery of the information sets to a third party responsible for operation, maintenance and enhancement of the software system.

36. Transition Phase: Objectives
Achieve independence of users
Produce a deployment version is complete and consistent
Build a release as rapidly and cost-effectively as possible.
Achieve independence of users
users can support themselves
Deployment baselines are complete and consistent with the evaluation criteria of the vision contained in the problem statement.
Final baselines can be built as rapidly and cost-effectively as possible.

37. Iteration in the Unified Process
Each of the four phases introduced so far (inception, elaboration, construction, transition) consists of one or more iterations
An iteration represents a set of activities for which
milestones are defined (“a well-defined intermediate event”)
the scope and results are captured with work-products called artifacts.

38. Artifact Sets Artifact set
A set of work products that are persistent and in a uniform representation format (natural language, Java, UML,…)
Every element in the set is developed and reviewed as a single entity
The Unified Process distinguishes five artifact sets:
Management set
Requirements set
Design set
Implementation set
Deployment set
To make the development of complex systems manageable,
the Unified Process organizes work products produced during the development into artifacts sets.
The Unified Process distinguishes the following five sets
Also called Engineering set.

39. Artifact Sets in the Unified Process
Requirements Set
1. Vision document (“problem statement”)
2. Requirements model(s)
Design Set
1. Design model(s)
2. Test model
3. Software architecture
Implementation Set
1. Source code baselines
2. Compile-time files
3. Component executables
Deployment
Set
1. Integrated pro- duct executable
2. Run-time files
3. User
documentation
Management Set
Planning Artifacts
1. Work breakdown structure
2. Business Case
3. Release specifications
4. Software Project Management Plan
Operational Artifacts
1. Release descriptions
2. Status assessments
3. Software change order database
4. Deployment documents
5. Environment

40. Focus on Artifact Sets during Development
Each artifact set is the predominant focus in one stage of the unified process
Inception
Elaboration
Construction
Transition
Management
Set
Requirements
Set
Design Set
Implementation
Set
Deployment
Set

41. Management of Artifact Sets
Some artifacts are changed only after a phase
Other artifacts are updated after each minor milestone, i.e. after an iteration
The project manager is responsible
to manage and visualize the sequence of artifacts across the software lifecycle activities
This visualization is often called artifact roadmap.
In each phase of the life cycle, new artifacts (“work products”) are produced and
previously developed artifacts are updated to incorporate lessons learned and to capture further depth and breadth of the solution.

42. Artifact Set Roadmap: Focus on Models
Informal
Baseline
Inception
Elaboration
Construction
Transition
Management Set
1. Vision
2. WBS
3. Schedule
4. Conf. Management
5. Project Agreement
6. Test cases
Requirements Set
This is an artifact road map with the focus on the creatio of models.
Is this a good road map?
1. Analysis Model
Design Set
1. System Design
2. Interface Specification
Implementation Set
1. Source code
2. Test cases
Deployment Set
1. Alpha-Test
2. Beta-Test

43. Artifact Set Roadmap: Focus on Documents
Informal
Baseline
Inception
Elaboration
Construction
Transition
Management Set
1. Problem Statement
2. WBS
3. SPMP
4. SCMP
5. Project Agreement
6. Test plan
Requirements Set
1. RAD
Design Set
1. SDD
2. ODD
Implementation Set
1. Source code
2. Test cases
Deployment Set
1. User Manual
2. Administrator Manual

44. Models vs. Documents Documentation-driven approach
The production of the documents drives the milestones and deadlines
Model-driven approach
The production of the models drive the milestones deadlines
Focus of a modern software development project is model-driven
Creation of models and construction of the software system
The purpose of documentation is to support this goal.
Many manager are tempted to pay too much attention on the production of documents.
Extremely important: Distinguish between
the information inherent in the system models (functional models, dynamic models, object models)
and the paper on which it is written (or the “bits on the screen”).
The main goal of a software development project is the creation of models and the construction of the software system.
The purpose of documentation is to support this goal.

45. Reasons for Documentation-Driven Approach
No rigorous engineering methods and languages available for analysis and design models
Language for implementation and deployment is too cryptic
Software project progress needs to be assessed
Documents represent a mechanism for demonstrating progress
People want to review information
but do not understand the language of the artifact
People wanted to review information,
but do not have access to the tools to view the information.
In the 60-90s a lot of time was spent on developing, formatting, reviewing, updating and distributing documents. Why?
1) No rigorous engineering methods and languages was available for analysis and design models. Consequently, paper documents with ad hoc text were the default format.
2) Conventional languages for implementation and deployment were highly cryptic. To present the details of software structure and behavior to other project participants (testers, managers, maintainers), a more human-readable format was needed.
3) Software project progress needed to be assessed (managers, stakeholders needed “status”). Documents represented a tangible but misleading mechanism for demonstrating progress.
4) People wanted to review information, but did not understand the language of the artifact.
5) People wanted to review information, but did not have access to the tools to view the information.

46. Model-Driven Approach
Provide document templates at project start
Project specific customization
Instantiate documents automatically from these templates
Enriches them with modeling information generated during the project
Automatically generates documents from the models. Examples:
Schedule generator
Automatic requirements document generator
Automatic interface specification generator
Automatic analysis and design documents generator
Automatic test case generator
Regression tester.
Provide templates for documents at the start of the project.
Instantiate documents automatically from these templates
Enriching them with modeling and artifact information generated during the project.
Tools automatically generate documents from the models. State of the art:
Schedule generator (Microsoft Project)
Automatic requirements document generator (Request)
Automatic Interface specification generator (Javadoc)
Automatic generation of analysis and design documents: Existing CASE Tools (Rationale Rose, Together-J)
Automatic test case generation (J_Unit)

47. Workflows in the Unified Process (1)
Management workflow
Planning of the project (Creation of problem statement, SPMP, SCMP, test plan)
Environment workflow
Automation of process and maintenance environment. Setup of infrastructure (communication infrastructure, configuration management, build environment).
Requirements workflow
Analysis of application domain and creation of requirements artifacts (analysis model).
Design workflow
Creation of solution and design artifacts (system design model, object design model).

48. Workflows in the Unified Process (2)
Implementation workflow
Implementation of solution, source code testing, maintenance of implementation and deployment artifacts (source code).
Assessment workflow
Assess process and products (reviews, walkthroughs, inspections, unit testing, integration testing, system testing, regression testing)
Deployment workflow
Transition the software system to the end user.

49. Workflows vs Phases Inception Elaboration Construction Transition
Management
Workflow
Environment
Workflow
Requirements
Workflow
Design Workflow
Implementation
Workflow
Assessment
Workflow
Deployment
Workflow

50. Workflows vs Phases A Phase describes the status of a software system
Inception, elaboration, construction, transition
Workflows can consist of one or more iterations per phase
“We are in the 3rd iteration in the design workflow”, “We are in the 3rd iteration during design”
Workflows create artifacts (models, documents) for the artifact sets
Management set, engineering set.

51. Managing Projects in the Unified Process
How should we manage the construction of software systems with the Unified Process?
Treat the development of a software system with the Unified Process as a set of several iterations
Some of these can be scheduled in parallel, others have to occur in sequence
Define a single project for each iteration
Establish work break down structures for each of the 7 workflows.

52. The term “Process“ is overloaded in the Unified Process
Meta Process (Also called “Business process”)
The policies, procedures and practices in an organization pursuing a software-intensive line of business.
Focus: Organizational improvement, long-term strategies, and return on investment (ROI)
Macro Process (“Lifecycle Model”)
The set of processes in a software lifecycle and dependencies among them
Focus: Producing a software system within cost, schedule and quality constraints
Micro Process
Techniques for achieving an artifact of the software process.
Focus: Intermediate baselines with adequate quality and functionality, as economically and rapidly as practical.
The term Process is overloaded in the Unified Process. It uses 3 types of processes:
Metaprocess (“Business process”). An organizations’s policies, procedures and practices for pursuing a software-intensive line of business.
Focus: Organizational improvement, long-term strategies, and return on investment (ROI).
Macroprocess (“Lifecycle Model”). The set of processes in a software lifecycle and dependencies among them.
Focus: Producing a software system within cost, schedule and quality constraints.
Microprocess (“Process”). Policies, and practices for achieving an artifact of the software process.
Focus: Intermediate baselines with adequate quality and adequate functionality as economically and rapidly as practical.

53. Phase vs. Iteration
A phase creates formal, stake-holder approved versions of artifacts (“major milestones”)
A phase to phase transition is triggered by a business decisions
An iteration creates informal, internally controlled versions of artifacts (“minor milestones”)
Iteration to iteration transition is triggered by a specific software development activity.
The transition from one phase to another phase is triggered by a significant business decision
and not by the completion of a specific software development activity.

54. Limitations of Waterfall and Iterative Models
Neither of these models deal well with frequent change
The Waterfall model assumes that once you are done with a phase, all issues covered in that phase are closed and cannot be reopened
The Spiral model can deal with change between rounds, but do not allow change within a round
The Unified Process model can deal with change in an iteration, but it has problems to deal with change within a iteration
What do we do if change is happening more frequently?
“The only constant is the change” (Hammer & Champy, Reengineering)

55. Frequency of Change and Choice of Software Lifecycle Model
PT = Project Time, MTBC = Mean Time Between Change
Change rarely occurs (MTBC » PT)
Waterfall Model
Open issues are closed before moving to next phase
Change occurs sometimes (MTBC ≈ PT)
Boehm’s Spiral Model, Unified Process
Change occurring during phase may lead to iteration of a previous phase or cancellation of the project
Change is frequent (MTBC « PT)
Issue-based Development (Concurrent Development)
Phases are never finished, they all run in parallel.

56. An Alternative: Issue-Based Development
A system is described as a collection of issues
Issues are either closed or open
Closed issues have a resolution
Closed issues can be reopened (Iteration!)
The set of closed issues is the basis of the system model
SD.I1:Closed
I1:Open
A.I1:Open
SD.I3:Closed
I3:Closed
I2:Closed
A.I2:Open
SD.I2:Closed
Planning
Requirements Analysis
System Design

57. Waterfall Model: Analysis Phase
I1:Open
A.I1:Open
I2:Open
I3:Open
A.I2:Open
SD.I1:Open
Analysis
Analysis
SD.I3:Open
SD.I2:Open

58. Waterfall Model: Design Phase
I1:Closed
A.I1:Open
I2:Closed
I3:Open
A.I2:Open
SD.I1:Open
Analysis
Analysis
SD.I3:Open
SD.I2:Open
Design

59. Waterfall Model: Implementation Phase
I1:Closed
A.I1:Closed
I2:Closed
I3:Closed
A.I2:Closed
SD.I1:Open
Analysis
SD.I3:Open
SD.I2:Open
Design
Implementation

60. Waterfall Model: Project is Done
I1:Closed
A.I1:Closed
I2:Closed
I3:Closed
A.I2:Closed
SD.I1:Open
Analysis
SD.I3:Open
SD.I2:Open
Design
Implementation

61. Issue-Based Model: Analysis Phase
I1:Open
D.I1:Open
I2:Open
I3:Open
Imp.I1:Open
Analysis:80%
Design: 10%
Implemen-tation: 10%

62. Issue-Based Model: Design Phase
I1:Closed
SD.I1:Open
I2:Closed
I3:Open
SD.I2:Open
Imp.I1:Open
Analysis:40%
Design: 60%
Implemen-tation: 0%
Imp.I3:Open
Imp.I2:Open

63. Issue-Based Model: Implementation Phase
I1:Open
A.I1:Open
I2:Closed
I3:Closed
A.I2:Closed
SD.I1:Open
Analysis:10%
Design: 10%
Implemen-tation: 60%
SD.I3:Open
SD.I2:Closed

64. Issue-Based Model: Prototype is Done
I1:Closed
A.I1:Closed
I2:Closed
I3: Pending
A.I2:Closed
SD.I1:Open
SD.I3:Closed
SD.I2: Unresolved

65. Summary Unified Process
Unified Process: Iterative software lifecycle model
Emphasis on early construction of a software architecture
Emphasis on early demonstrations of the system
Definitions
4 phases: Inception, Elaboration, Construction, Transition
7 workflows: Management, environment, requirements, design, implementation, assessment, deployment.
5 artifact sets: Management set, requirements set, design set, implementation set, deployment set
Iteration: Repetition within a workflow.
A unified process iteration should be treated as a software project.
The Unified Process is an iterative software lifecycle model with emphasis on the early construction of
a software architecture and early demonstrations of the system.
It consists of phases, workflows and iterations that produce artifacts.
Definitions
Phase: Status of the software system.
4 phases: Inception, Elaboration, Construction, Transition
Workflow: Mostly sequential activity that produces artifacts
7 workflows: Management, environment, requirements, design, implementation, assessment, deployment.
5 artifact sets: Management set, requirements set, design set, implementation set, deployment set
Iteration: Repetition within a workflow.
A unified process iteration should be treated as a software project.

66. Summary Software life cycle models Prototyping Sequential models
Pure waterfall model and V-model
Iterative model
Boehm’s spiral model
Unified process
Entity-oriented models
Issue-based model
Sequential models can be modeled as special cases of the issue-based model
Prototyping
A specific type of system model
Illustrative, functional and exploratory prototypes
Revolutionary and evolutionary prototyping
Time-boxed prototyping is a better term than rapid prototyping.

67. Additional References
Walker Royce
Software Project Management, Addison-Wesley, 1998.
Ivar Jacobsen, Grady Booch & James Rumbaugh
The Unified Software Development Process, Addison Wesley, 1999.
Jim Arlow and Ila Neustadt
UML and the Unified Process: Practical Object-Oriented Analysis and Design, Addison Wesley, 2002.
Philippe Kruchten
Rational Unified Process, Addison-Wesley, 2000.
Note: The Rational Unified Process is a commercial product of the Unified Process.

68. Additional and Backup Slides

69. OOSE-Book: Development activities and their products
problem statement
Requirements
elicitation
use case diagram
functional model
nonfunctional requirements
The analysis Object model is often called briefly the object model, if the context specifies that it is the model created during analysis.
Analysis
statechart diagram
class diagram
object model
dynamic model
sequence diagram
System design

70. OOSE- Development activities (cont’d)
System design
subsystem decomposition
design goals
Object design
object design model
class diagram
source
code
Implemen-tation
Testing
deliverable system