Part 2

A Software Management Process Framework

Table of Contents (2)

Model-based software Architectures

Architecture: A Management Perspective
Architecture: A Technical Perspective

Workflows of the Process

Software Process Workflows
Iteration Workflows

Checkpoints of the Process

Major Milestones
Minor Milestones
Periodic Status Assessments
"Software Project Management" Walker 32/112
Royce
 Part 2
A Software Management Process Framework
Table of Contents (2)

INTRODUCTION:

If there is a well defined separation between research and

development activities and production activities then the software
is said to be in successful development process.

Most of the softwares fail due to the following characteristics ,

1) An overemphasis on research and development.
2) An overemphasis on production.

"Software Project Management" Walker 32/112

Royce
 Part 2
Life-Cycle Phases
Engineering and Production Stages

Two stages of the life-cycle :

[Link] engineering stage driven by smaller teams doing
design and synthesis activities
2. The production stage driven by larger teams
doing construction, test, and deployment activities
LIFE-CYCLE ASPECT ENGINEERING STAGE PRODUCTION STAGE
EMPHASIS EMPHASIS
Risk reduction Schedule, technical feasibility Cost

Products Architecture baseline Product release baselines

Activities Analysis, design, planning Implementation, testing
Assessment Demonstration, inspection, Testing
analysis
Economics Resolving diseconomies of scale Exploiting economics of scale

Management Planning Operations

"Software Project Management" Walker 33/112
Royce
 Part 2
Life-Cycle Phases
Engineering and Production Stages

Attributing only two stages to a life cycle is too coarse

Spiral model [Boehm, 1998]

Engineering Stage Production Stage

Inception Elaboration Construction Transition

Idea Architecture Beta Releases Products

"Software Project Management" Walker 34/112

Royce
 Part 2
Life-Cycle Phases
Inception Phase

Overriding goal to achieve concurrence among stakeholders

on the life-cycle objectives

Essential activities :
o Formulating the scope of the project (capturing the
requirements and operational concept in an information
repository)
o Synthesizing the architecture (design trade-offs, problem space
ambiguities, and available solution-space assets are evaluated)
o Planning and preparing a business case (alternatives for risk
management, iteration planes, and cost/schedule/profitability
trade-offs are evaluated)

"Software Project Management" Walker 35/112

Royce
 Part 2
Life-Cycle Phases
Elaboration Phase

During the elaboration phase, an executable architecture

prototype is built

Essential activities :
o Elaborating the vision (establishing a high-fidelity understanding
of the critical use cases that drive architectural or planning
decisions)
o Elaborating the process and infrastructure (establishing the
construction process, the tools and process automation support)
o Elaborating the architecture and selecting components (lessons
learned from these activities may result in redesign of the
architecture)

"Software Project Management" Walker 36/112

Royce
 Part 2
Life-Cycle Phases
Construction Phase

During the construction phase :

All remaining components and application features
are integrated into the application
All features are thoroughly tested

Essential activities :
o Resource management, control, and process optimization
o Complete component development and testing against
evaluation criteria
o Assessment of the product releases against acceptance criteria
of the vision

"Software Project Management" Walker 37/112

Royce
 Part 2
Life-Cycle Phases
Transition Phase

The transition phase is entered when baseline is mature enough

to be deployed in the end-user domain
This phase could include beta testing, conversion of operational
databases, and training of users and maintainers

Essential activities :
o Synchronization and integration of concurrent construction into
consistent deployment baselines
o Deployment-specific engineering (commercial packaging and
production, field personnel training)
[Link] of deployment baselines against the complete
vision and acceptance criteria in the requirements set

"Software Project Management" Walker 38/112

Royce
 Part 2
Life-Cycle Phases
Evaluation Criteria :
Is the user satisfied?
Are actual resource expenditures
versus planned expenditures acceptable?

Each of the four phases consists of one or more iterations

in which some technical capability is produced in demonstrable
form and assessed against a set of the criteria
The transition from one phase to the nest maps more
to a significant business decision than to the completion of
specific software activity.

"Software Project Management" Walker 39/112

Royce
 Part 2
Artifacts of the Process
Requirements Design Set Implementation Deployment
Set Set Set
[Link] document
[Link] [Link] model(s) [Link] code [Link] product
model(s) [Link] model baselines executable baselines
[Link] architecture [Link] compile- [Link]
description time files run-time files
[Link] [Link] manual
executables

Management Set
Planning Artifacts Operational Artifacts
[Link] breakdown structure [Link] descriptions
[Link] case [Link] assessments
[Link] specifications [Link] change order database
[Link] development plan [Link] documents
[Link]

"Software Project Management" Walker 40/112

Royce
 Part 2
Artifacts of the Process
Management Artifacts

The management set includes several artifacts :

Work Breakdown Structure vehicle for budgeting and collecting
costs.
The software project manager must have insight into project costs
and how they are expended.
If the WBS is structured improperly, it can drive the evolving design
in the wrong direction.

Business Case provides all the information necessary to determine

whether the project is worth investing in.
It details the expected revenue, expected cost, technical
and management plans.
"Software Project Management" Walker 41/112
Royce
 Part 2
Artifacts of the Process
Management Artifacts

Release Specifications
Typical release specification outline :
I. Iteration content
II. Measurable objectives
A. Evaluation criteria
B. Follow-through approach
[Link] plan
A. Schedule of activities
B. Team responsibilities
[Link] scenarios (use cases demonstrated)
A. Demonstration procedures
B. Traceability
Two importanttoforms
vision and business case :
of requirements
vision statement (or user need) - which captures the contract
between the development group and the buyer.
evaluation criteria defined as management-oriented requirements,
which may be represented by use cases, use case realizations
or structured text representations.
"Software Project Management" Walker 42/112
Royce
 Part 2
Artifacts of the Process
Management Artifacts

Software Development Plan the defining document for the projects

process.
It must comply with the contract, comply with the organization standards,
evolve along with the design and requirements.

Deployment depending on the project, it could include several document

subsets for transitioning the product into operational status.
It could also include computer system operations manuals,
software installation manuals, plans and procedures for cutover etc.

Environment A robust development environment must support

automation of the development process.
It should include :
requirements management
visual modeling
document automation "Software Project Management" Walker 43/112
automated regression testing Royce
 Part 2
Artifacts of the Process
Engineering Artifacts

In general review, there are three engineering artifacts :

Vision document supports the contract between the funding authority and
the development organization.
It is written from the users perspective, focusing on the essential features
of the system.
It should contain at least two appendixes the first appendix should describe
the operational concept using use cases,
the second should describe the change risks inherent in the vision statement.

Architecture Description it is extracted from the design model

and includes views of the design, implementation, and deployment sets
sufficient to understand how the operational concept of the requirements set
will be achieved.

"Software Project Management" Walker 44/112

Royce
 Part 2
Artifacts of the Process
Engineering Artifacts

Typical architecture description outline :

[Link] overview III. Architectural interactions
A. Objectives A. Operational concept under primary scenarios
B. Constraints B. Operational concept under secondary scenarios
C. Freedoms C. Operational concept under anomalous scenarios
[Link] views
A. Design view [Link] performance
B. Process view
C. Component view [Link], trade-offs, and other substantiation
D. Deployment view
Software User Manual it should include installation procedures,
usage procedures and guidance, operational constraints,
and a user interface description.
It should be written by members of the test team,
who are more likely to understand the users perspective than
the development team.
It also provides a necessary basis for test plans and test cases,
and for construction of automated test suites.
"Software Project Management" Walker 45/112
Royce
 Part 2
Artifacts of the Process
Pragmatic Artifacts

Over the past 30 years, the quality of documents become

more important than the quality of the engineering information
they represented.
The reviewer must be knowledgeable in the engineering notation.

Human-readable engineering artifacts should use rigorous notations

that are complete, consistent, and used in a self-documenting
manner.

Paper is tangible, electronic artifacts are too easy to change.

Short documents are more useful than long ones.

"Software Project Management" Walker 46/112

Royce
 Part 2
Model-Based Software Architectures
A Management Perspective

From a management perspective, there are three different

aspects of an architecture :
An architecture (the intangible design concept) is the design
of software system, as opposed to design of a component.

An architecture baseline (the tangible artifacts) is a slice

of information across the engineering artifact sets sufficient to
satisfy all stakeholders that the vision can be achieved within
the parameters of the business case (cost, profit, time, people).

An architecture description (a human-readable representation

of an architecture) is an organizes subsets of information
extracted from the design set model.
"Software Project Management" Walker 47/112
Royce
 Part 2
Model-Based Software Architectures
A Management Perspective

The importance of software architecture can be summarized

as follows:
Architecture representations provide a basis for balancing
the trade-offs between the problem space and the solution space.

Poor architectures and immature processes are often given as

reasons for project failures.

A mature process, an understanding of the primary requirements,

and a demonstrable architecture are important prerequisites for
predictable planning.

Architecture development and process definition are the intellectual

steps that map the problem to a solution
"Software withoutWalker
Project Management" violating 48/112
Royce
the constraints.
 Part 2
Model-Based Software Architectures
A Technical Perspective
The model which draws on the foundation of architecture
developed at Rational Software Corporation and particularly
Architecture
on Philippe Kruchtens concepts of software architecture :
Description
Document
An architecture is described through several views, Design view
which are extracts of design models that capture the Process view
significant structures, collaborations, and behaviors. Use case view
Component view
Deployment view
Other views (optional)
Use Case
View

Deployment
Design Process Component View
View View View

"Software Project Management" Walker 49/112

Royce
 Part 2
Model-Based Software Architectures
A Technical Perspective

The use case view describes how the systems critical use cases are realized
by elements of the design model.
It is modeled statically using case diagrams,
and dynamically using any of the UML behavioral diagrams.

The design view addresses the basic structure and the functionality
of the solution.
The process view addresses the run-time collaboration issues involved in
executing the architecture on a distributed deployment model,
including the logical software network topology, interprocess communication
and state management.
The component view describes the architecturally significant elements of
the implementation set and addresses the software source code realization
of the system from perspective of the project's integrators and developers.

The deployment view addresses the executable realization of the system,

"Software Project Management" Walker 50/112
including the allocation of logical processes in the distribution view
Royce to
 Part 2
Workflows of the Process
Software Process Workflows

The term workflow is used to mean a thread of cohesive and

most sequential activities.
There are seven top-level workflows:

1. Management workflow: controlling the process and ensuring win conditions for all
stakeholders
2. Environment workflow: automating the process and evolving
the maintenance environment
[Link] workflow: analyzing the problem space and evolving
the requirements artifacts
[Link] workflow: modeling the solution and evolving the architecture and
design artifacts
[Link] workflow: programming the components and evolving
the implementation and deployment artifacts
[Link] workflow: assessing the trends in process and product quality
"Software Project
[Link] workflow: transitioning theManagement" Walkerto the user
end products 51/112
Royce
 Part 2
Workflows of the Process
Software Process Workflows

Four basic key principles:

[Link]-first approach: implementing and testing
the architecture must precede full-scale development and testing
and must precede the downstream focus on completeness and quality of the
product features.
[Link] life-cycle process: the activities and artifacts of any given
workflow may require more than one pass to achieve adequate
results.
[Link] engineering: Raising the environment activities
to a first-class workflow is critical; the environment is the tangible
embodiment of the projects process and notations for producing
the artifacts.
[Link]-based approach: Implementation and assessment
activities are initiated nearly in the life-cycle, reflecting the emphasis on
constructing executable subsets of the involving architecture.
"Software Project Management" Walker 52/112
Royce
 Part 2
Workflows of the Process
Iteration Workflows

An iteration consist of sequential set of activities in various proportions,

depending on where the iteration is located in the development cycle.
An individual iterations workflow:

Allocated Results from the

usage scenarios Previous iteration

Management
Requirements
Design
Implementation
Assessment
Deployment

Results for the next

iteration

"Software Project Management" Walker 53/112

Royce
 Part 2
Workflows of the Process
Iteration Workflows

Inception and Elaboration Phases Construction Phase

Management Management
Requirements Requirements
Design Design
Implementation Implementation
Assessment Assessment
Deployment Deployment
Transition Phase

Management
Requirements
Design
Implementation
Assessment
Deployment

"Software Project Management" Walker 54/112

Royce
 Part 2
Checkpoints of the Process
It is important to have visible milestones in the life cycle , where
various stakeholders meet to discuss progress and planes.
The purpose of this events is to:
Synchronize stakeholder expectations and achieve concurrence on
the requirements, the design, and the plan.
Synchronize related artifacts into a consistent and balanced state

Identify the important risks, issues, and out-of-rolerance conditions

Perform a global assessment for the whole life-cycle.

"Software Project Management" Walker 55/112

Royce
 Part 2
Checkpoints of the Process
Three types of joint management reviews are conducted
throughout the process:
[Link] milestones provide visibility to systemwide issues, synchronize
the management and engineering perspectives and verify that the
aims of the phase have been achieved.
2. Minor milestones iteration-focused events,
conducted to review the content of an iteration in detail
and to authorize continued work.
3. Status assessments periodic events provide management with
frequent and regular insight into the progress being made.

"Software Project Management" Walker 56/112

Royce
 Part 3
Software Management Disciplines

"Software Project Management" Walker 57/112

Royce
 Part 3
Software Management Disciplines
Table of Contents (1)

Iterative Process Planning

Work Breakdown Structures
Planning Guidelines
The Cost and Schedule Estimating Process
The Iteration Planning Process
Pragmatic Planning
Project Organizations and Responsibilities
Line-of-Business organizations
Project Organizations
Evolution Organizations
Process Automation
Tools: Automation Building Blocks
The Project Environment
"Software Project Management" Walker 58/112
Royce
 Part 3
Software Management Disciplines
Table of Contents (2)

Project Control and Process Instrumentation

The Seven Core Metrics
Management Indicators
Quality Indicators
Life-Cycle Expectations
Pragmatic Software Metrics
Metrics Automation

Tailoring the Process

Process Discriminants
Example: Small-Scale Project Versus Large-scale Project

"Software Project Management" Walker 59/112

Royce
 Part 3
Iterative Process Planning
Work Breakdown Structures

The development of a work breakdown structure

is dependent on the project management style,
organizational culture, customer preference, financial
constraints and several other hard-to-define parameters.
A WBS is simply a hierarchy of elements that decomposes
the project plan into the discrete work tasks.
A WBS provides the following information structure:
A delineation of all significant work
A clear task decomposition for assignment of responsibilities
A framework for scheduling, budgeting, and expenditure
tracking.
"Software Project Management" Walker 60/112
Royce
 Part 3
Iterative Process Planning
Planning Guidelines

Two simple planning guidelines should be considered

when a project plan is being initiated or assessed.
FIRST-LEVEL DEFAULT
WBS ELEMENT BUDGET

Management 10% DOMAIN INCEPTION ELABORATION CONSTRUCTION TRANSITION

Environment 10%
Effort 5% 20% 65% 10%
Requirements 10%

Design 15% Schedule 10% 30% 50% 10%

Implementation 25%
The second guideline prescribes the allocation
Assessment 25%
of effort and schedule across the life-cycle phases
Deployment 5%

Total 100%

The first guideline prescribes a default

allocation of costs among the first-level
WBS elements

"Software Project Management" Walker 61/112

Royce
 Part 3
Iterative Process Planning
The Cost and Schedule Estimating Process

Project plans need to be derived from two perspectives.

Forward-looking:
1. The software project manager develops a characterization
of the overall size, process, environment, people,
and quality required for the project
2. A macro-level estimate of the total effort and schedule is developed using a
software cost estimation model
3. The software project manager partitions the estimate for the effort into a top-
level WBS, also partitions the schedule into major milestone dates and partitions
the effort into a staffing profile
4. At this point, subproject managers are given the responsibility
for decomposing each of the WBS elements into lower levels using
their top-level allocation, staffing profile, and major milestone dates
"Software Project Management" Walker 62/112
as constraints. Royce
 Part 3
Iterative Process Planning
The Cost and Schedule Estimating Process

Backward-looking:

1. The lowest level WBS elements are elaborated into detailed tasks,
for which budgets and schedules are estimated by the responsible
WBS element manager.
2. Estimates are combined and integrated into higher level budgets
and milestones.
3. Comparisons are made with the top-down budgets and schedule milestones.
Gross differences are assessed and adjustments are made in order to converge
on agreement between the top-down and the bottom-up estimates.

"Software Project Management" Walker 63/112

Royce
 Part 3
Iterative Process Planning
The Iteration Planning Process

Engineering Stage Production Stage

Inception Elaboration Construction Transition

Feasibility iterations Architecture iterations Usable iterations Product releases

Engineering stage Production stage

planning emphasis: planning emphasis:
Macro-level task estimation for production- Micro-level task estimation for production-
stage artifacts stage artifacts
Micro-level task estimation for engineering Macro-level task estimation for
artifacts engineering artifacts
Stakeholder concurrence Stakeholder concurrence
Coarse-grained variance analysis of actual Fine-grained variance analysis of actual
vs. planned expenditures vs. planned expenditures
Tuning the top-down project-independent
planning guidelines into project-specific
planning guidelines.
"Software Project Management" Walker 64/112
Royce
 Part 3
Project Organizations and Responsibilities
Line-of-Business Organizations

Default roles in a software line-of-business organizations

Organization
Manager
Software Engineering Project Review
Process Authority Authority

Process definition Project compliance

Process improvement Periodic risk assessment

Software Engineering
Infrastructure
Environment Authority

Process automation Project administration

Engineering skill centers
Professional development

Project A Project B Project N

Manager Manager Manager

"Software Project Management" Walker 65/112

Royce
 Part 3
Project Organizations and Responsibilities
Project Organizations

Software Management Team

Systems Engineering
Financial Administration
Artifacts Quality Assurance Responsibilities
Business case Resource commitments
Vision Personnel assignments
Software development plan Plans, priorities,
Work breakdown structure Stakeholder satisfaction
Status assessments Scope definition
Requirements set Risk management
Life-Cycle Focus
Project control
Inception Elaboration Construction Transition
Elaboration phase planning Construction phase planning Transition phase planning Customer satisfaction
Team formulating Full staff recruitment Construction plan optimization Contract closure
Contract base lining Risk resolution Risk management Sales support
Architecture costs Product acceptance criteria Next-generation planning
Construction costs

"Software Project Management" Walker 66/112

Royce
 Part 3
Project Organizations and Responsibilities
Project Organizations

Software Architecture Team

Demonstrations
Use-case modelers
Artifacts Design modelers Responsibilities
Architecture description Performance analysts Requirements trade-offs
Requirements set Design trade-offs
Design set Component selection
Release specifications Initial integration
Technical risk solution

Life-Cycle Focus
Inception Elaboration Construction Transition
Architecture prototyping Architecture base lining Architecture maintenance Architecture maintenance
Make/buy trade-offs Primary scenario demonstration Multiple-component issue Multiple-component issue
Primary scenario definition Make/buy trade-offs base lining resolution resolution
Performance tuning Performance tuning
Architecture evaluation criteria
Quality improvements Quality improvements
definition

"Software Project Management" Walker 67/112

Royce
 Part 3
Project Organizations and Responsibilities
Project Organizations

Software Development Team

Component teams

Artifacts Responsibilities
Design set Component design
Implementation set Component implementation
Deployment set Component stand-alone test
Component maintenance
Component documentation

Life-Cycle Focus
Inception Elaboration Construction Transition
Prototyping support Critical component design Component design Component maintenance
Make/buy trade-offs Critical component Component implementation Component documentation
implementation and test Component stand-alone test
Critical component base line Component maintenance

"Software Project Management" Walker 68/112

Royce
 Part 3
Project Organizations and Responsibilities
Project Organizations

Software Assessment Team

Release testing
Change management
Deployment Responsibilities
Artifacts
Environment support Project infrastructure
Deployment set
SCO database Independent testing
User manual Requirements verification
Environment Metrics analysis
Release specifications Configuration control
Release descriptions Change management
Life-Cycle Focus
Deployment documents User deployment
Inception Elaboration Construction Transition
Infrastructure planning Infrastructure base lining Infrastructure upgrades Infrastructure maintenance
Primary scenario prototyping Architecture release testing Release testing Release base lining
Change management Change management Change management
Initial user manual User manual base line Deployment to users
Requirements verification Requirements verification

"Software Project Management" Walker 69/112

Royce
 Part 3
Project Organizations and Responsibilities
Evolution of Organizations

Software Software
management management
50% 10%
Software Software Software Software Software Software
architecture development assessment architecture development assessment
20% 20% 10% 50% 20% 20%

Inceptio Elaboration
n
Transition Constructio
Software Software
management n management
10% 10%
Software Software Software Software Software Software
architecture development assessment architecture development assessment
5% 35% 50% 10% 50% 30%

"Software Project Management" Walker 70/112

Royce
 Part 3
Process Automation
Computer-aided software engineering

Computer-aided software engineering (CASE) is software to

support software development and evolution processes.
Activity automation
o Graphical editors for system model development;
o Data dictionary to manage design entities;
o Graphical UI builder for user interface construction;
o Debuggers to support program fault finding;
o Automated translators to generate new versions of a program.

"Software Project Management" Walker 71/112

Royce
 Part 3
Process Automation
Computer-aided software engineering (CASE) Technology

Case technology has led to significant

improvements in the software process. However,
these are not the order of magnitude
improvements that were once predicted
o Software engineering requires creative thought - this is
not readily automated;
o Software engineering is a team activity and, for large
projects, much time is spent in team interactions. CASE
technology does not really support these.

"Software Project Management" Walker 72/112

Royce
 Part 3
Process Automation
CASE Classification

Classification helps us understand the different types of

CASE tools and their support for process activities.
Functional perspective
o Tools are classified according to their specific function.
Process perspective
o Tools are classified according to process activities that are
supported.
Integration perspective
o Tools are classified according to their organisation into
integrated units.

"Software Project Management" Walker 73/112

Royce
 Part 3
Process Automation
Functional Tool Classification

"Software Project Management" Walker 74/112

Royce
 Part 3
Process Automation
CASE Integration

Tools
o Support individual process tasks such as design
consistency checking, text editing, etc.
Workbenches
o Support a process phase such as specification or design,
Normally include a number of integrated tools.
Environments
o Support all or a substantial part of an entire software
process. Normally include several integrated
workbenches.

"Software Project Management" Walker 75/112

Royce
 Part 3
Process Automation
Tools, Workbenches, Environments

"Software Project Management" Walker 76/112

Royce
 Part 3
Project Control and Process Instrumentation
The Core Metrics

METRIC PURPOSE PERSPECTIVES

Work and progress Iteration planning, plan vs. actuals, SLOC, function points, object points,
management indicator scenarios, test cases, SCOs

Budget cost and expenditures Financial insight, plan vs. actuals, Cost per month, full-time staff per
management indicator month, percentage of budget expended

Staffing and team dynamics Resource plan vs. actuals, hiring rate, People per month added, people per
attrition rate month leaving

Change traffic and stability Iteration planning, management Software changes

indicator of schedule convergence

Breakage and modularity Convergence, software scrap, quality Reworked SLOC per change, by type, by
indicator release/component/subsystem

Rework and adoptability Convergence, software rework, quality Average hours per change, by type, by
indicator release/component/subsystem

"Software Project Management" Walker 77/112

Royce
 Part 3
Tailoring the Process
Process Discriminants

The two primary dimensions of process variability

Higher technical complexity
Embedded, real-time, Average software project
distributed, fault-tolerant 5 to 10 people
High-performance, portable 10 to 12 months
Unprecedented, architecture re- 3 to 5 external interfaces
engineering Some unknowns, risks

Lower management complexity Higher management complexity

Smaller scale Large scale
Informal Contractual
Few stakeholders Many stakeholders
Products Projects

Lower technical complexity

Straightforward automation, single
thread
Interactive performance, single
platform
Many precedent systems, application
re-engineering

"Software Project Management" Walker 78/112

Royce
 Part 3
Tailoring the Process
Example: Small-Scale Project vs. Large-Scale Project

Differences in workflow priorities between small and large projects

Rank Small Commercial Large Complex Project

Project
Design Management
1
Implementation Design
2
Deployment Requirements
3
Requirements Assessment
4
Assessments Environment
5
Management Implementation
6
Environment Deployment
7
"Software Project Management" Walker 79/112
Royce
 Part 4
Looking Forward

"Software Project Management" Walker 80/112

Royce
 Part 4
Looking Forward
Table of Contents

Modern Project Profiles

Continuous Integration
Early Risk Resolution
Evolutionary Requirements
Teamwork Among Stakeholders
Top 10 Software Management Principles
Software Management Best Practices

Next-Generation Software Economics

Next-Generation Cost Models
Modern Software Economics

Modern Process Transitions

Culture Shifts
Denouement
"Software Project Management" Walker 81/112
Royce
 Part 4
Modern Project Profiles
Continuous Integration

Differences in workflow cost allocations between

a conventional process and a modern process
SOFTWARE CONVENTIONAL MODERN
ENGINEERING PROCESS PROCESS
WORKFLOWS EXPENDITURES EXPENDITURES
Management 5% 10%

Environment 5% 10%

Requirements 5% 10%

Design 10% 15%

Implementation 30% 25%

Assessment 40% 25%

Deployment 5% 5%

Total 100% 100%

"Software Project Management" Walker 82/112

Royce
 Part 4
Modern Project Profiles
Continuous Integration

The continuous integration inherent in an iterative

development process enables better insight into
quality trade-offs.

System characteristics that are largely inherent

in the architecture (performance, fault tolerance,
maintainability) are tangible earlier in the process,
when issues are still correctable.

"Software Project Management" Walker 83/112

Royce
 Part 4
Modern Project Profiles
Early Risk Resolution

Conventional projects usually do the easy stuff first,

modern process attacks the important 20%
of the requirements, use cases, components, and risks.
The effect of the overall life-cycle philosophy
on the 80/20 lessons provides a useful risk management
perspective.
80% of the engineering is consumed by 20% of the requirements.
80% of the software cost is consumed by 20% of the components.
80% of the errors are caused by 20% of the components.

80% of the progress is made by 20% of the people.

"Software Project Management" Walker 84/112

Royce
 Part 4
Modern Project Profiles
Evolutionary Requirements

Conventional approaches decomposed system requirements

into subsystem requirements, subsystem requirements into
component requirements, and component requirements into
unit requirements.
The organization of requirements was structured
so traceability was simple.
Most modern architectures that use commercial components,
legacy components, distributed resources and
object-oriented methods are not trivially traced
to the requirements they satisfy.
The artifacts are now intended to evolve along with the process,
with more and more fidelity as the life-cycle progresses and
the requirements understanding matures.
"Software Project Management" Walker 85/112
Royce
 Part 4
Modern Project Profiles
Teamwork among stakeholders

Many aspects of the classic development process cause

stakeholder relationships to degenerate into mutual distrust,
making it difficult to balance requirements, product features,
and plans.
The process with more-effective working relationships between
stakeholders requires that customers, users and monitors have both
applications and software expertise, remain focused on the delivery
of a usable system
It also requires a development organization that is focused
on achieving customer satisfaction and high product quality
in a profitable manner.
The transition from the exchange of mostly paper artifacts
to demonstration of intermediate results is one of the crucial
mechanisms for promoting teamwork among stakeholders.
"Software Project Management" Walker 86/112
Royce
 Part 4
Modern Project Profiles
Top 10 Software Management Principles

1. Base the process on an architecture-first approach rework rates remain

stable over the project life cycle.
2. Establish an iterative life-cycle process that confronts
risk early
3. Transition design methods to emphasize component-based
development
4. Establish a change management environment the dynamics
of iterative development, including concurrent workflows by
different teams working on shared artifacts, necessitate highly controlled baselines

5. Enhance change freedom through tools that support

round-trip engineering

"Software Project Management" Walker 87/112

Royce
 Part 4
Modern Project Profiles
Top 10 Software Management Principles

6. Capture design artifacts in rigorous, model-based notation

7. Instrument the process for objective quality control and progress

assessment
8. Use a demonstration-based approach to asses intermediate artifacts

9. Plan intermediate releases in groups of usage scenarios with evolving

levels of detail
10. Establish a configurable process that is economically
scalable

"Software Project Management" Walker 88/112

Royce
 Part 4
Modern Project Profiles
Software Management Best Practices

There is nine best practices:

1. Formal risk management
2. Agreement on interfaces
3. Formal inspections
4. Metric-based scheduling and management
5. Binary quality gates at the inch-pebble level
6. Program-wide visibility of progress versus plan.
7. Defect tracking against quality targets
8. Configuration management
9. People-aware management accountability

"Software Project Management" Walker 89/112

Royce
 Part 4
Next-Generation Software Economics
Next-Generation Cost Models

Software experts hold widely varying opinions about software economics and its
manifestation in software cost estimation models:
source lines of code function points

productivity quality
measures VERSUS measures
Java C++

object-oriented functionally oriented

It will be difficult to improve empirical estimation models while

the project data going into these models are noisy
and highly uncorrelated, and are based on differing process
and technology foundations.
"Software Project Management" Walker 90/112
Royce
 Part 4
Next-Generation Software Economics
Next-Generation Cost Models

Some of todays popular software cost models are not well matched
to an iterative software process focused an architecture-first approach
Many cost estimators are still using a conventional process experience
base to estimate a modern project profile
A next-generation software cost model should explicitly separate
architectural engineering from application production,
just as an architecture-first process does.
Two major improvements in next-generation software
cost estimation models:
Separation of the engineering stage from the production stage
will force estimators to differentiate between architectural scale and implementation
size.
Rigorous design notations such as UML will offer an opportunity
to define units of measure for scale that are more standardized and
therefore can be automated and tracked.
"Software Project Management" Walker 91/112
Royce
 Part 4
Next-Generation Software Economics
Modern Software Economics

Changes that provide a good description of what an organizational manager

should strive for in making the transition to a modern process:

1. Finding and fixing a software problem after delivery

costs 100 times more than fixing the problem in early design phases

2. You can compress software development schedules 25% of nominal, but

no more.
3. For every $1 you spend on development,
you will spend $2 on maintenance.
4. Software development and maintenance costs are primarily
a function of the number of source lines of code.

"Software Project Management" Walker 92/112

Royce
 Part 4
Next-Generation Software Economics
Modern Software Economics

5. Variations among people account for the biggest differences

in software productivity.
6. The overall ratio of software to hardware costs
is still growing in 1955 it was 15:85; in 1985 85:15.

7. Only about 15% of software development effort

is devoted to programming.
8. Software systems and products typically cost 3 times
as much per SLOC as individual software programs.
9. Walkthroughs catch 60% of the errors.

10. 80% of the contribution comes from 20% of the

contributors.
"Software Project Management" Walker 93/112
Royce
 Part 4
Modern Process Transitions
Culture Shifts

Several culture shifts must be overcome to transition successfully to a

modern software management process:
Lower level and mid-level managers are performers
Requirements and designs are fluid and tangible
Good and bad project performance is much more obvious earlier
in the life cycle
Artifacts are less important early, more important later
Real issues are surfaced and resolved systematically
Quality assurance is everyones job, not a separate discipline
Performance issues arise early in the life cycle
Investments in automation is necessary
Good software organization should be more profitable
"Software Project Management" Walker 94/112
Royce
 Part 4
Modern Process Transitions
Denouement

Good way to transition to a more mature iterative development process

that supports automation technologies
and modern architectures is to take the following shot:
Ready.
Do your homework. Analyze modern approaches and technologies.
Define your process. Support it with mature environments, tools,
and components. Plan thoroughly.

Aim.
Select a critical project. Staff it with the right team
of complementary resources and demand improved results.
Fire.
Execute the organizational and project-level plans with vigor and
follow-through.

"Software Project Management" Walker 95/112

Royce
 Appendix

"Software Project Management" Walker 96/112

Royce
 Appendix
Use Case Analysis
What is a Use Case?
o A sequence of actions a system performs that
yields a valuable result for a particular actor.
What is an Actor?
o A user or outside system that interacts with the
system being designed in order to obtain some
value from that interaction
Use Cases describe scenarios that describe the interaction
between users of the system and the system itself.
Use Cases describe WHAT the system will do, but never HOW it
will be done.
"Software Project Management" Walker 97/112
Royce
 Appendix
Whats in a Use Case?
Define the start state and any preconditions that accompany it
Define when the Use Case starts
Define the order of activity in the Main Flow of Events
Define any Alternative Flows of Events
Define any Exceptional Flows of Events
Define any Post Conditions and the end state
Mention any design issues as an appendix
Accompanying diagrams: State, Activity, Sequence Diagrams
View of Participating Objects (relevant Analysis Model Classes)
Logical View: A View of the Actors involved with this Use Case, and any
Use Cases used or extended by this Use Case

"Software Project Management" Walker 98/112

Royce
 Appendix
Use Cases Describe Function not Form
Use Cases describe WHAT the system will do, but never HOW it will be done.
Use Cases are Analysis Products, not Design Products.

"Software Project Management" Walker 99/112

Royce
 Appendix
Use Cases Describe Function not Form
Use Cases describe WHAT the system
should do, but never HOW it will be done
Use cases are Analysis products, not design
products

"Software Project Management" Walker 100/112

Royce
 Appendix
Benefits of Use Cases
Use cases are the primary vehicle for requirements capture in RUP
Use cases are described using the language of the customer
(language of the domain which is defined in the glossary)
Use cases provide a contractual delivery process (RUP is Use
Case Driven)
Use cases provide an easily-understood communication
mechanism
When requirements are traced, they make it difficult for
requirements to fall through the cracks
Use cases provide a concise summary of what the system should
do at an abstract (low modification cost) level.

"Software Project Management" Walker 101/112

Royce
 Appendix
Difficulties with Use Cases
As functional decompositions, it is often difficult to make the
transition from functional description to object description to class
design
Reuse at the class level can be hindered by each developer
taking a Use Case and running with it. Since UCs do not talk
about classes, developers often wind up in a vacuum during object
analysis, and can often wind up doing things their own way, making
reuse difficult
Use Cases make stating non-functional requirements difficult
(where do you say that X must execute at Y/sec?)
Testing functionality is straightforward, but unit testing the particular
implementations and non-functional requirements is not obvious

"Software Project Management" Walker 102/112

Royce
 Appendix
Use Case Model Survey
The Use Case Model Survey is to illustrate, in
graphical form, the universe of Use Cases that the
system is contracted to deliver.
Each Use Case in the system appears in the
Survey with a short description of its main function.
o Participants:
Domain Expert
Architect
Analyst/Designer (Use Case author)
Testing Engineer
"Software Project Management" Walker 103/112
Royce
 Appendix
Sample Use Case Model Survey

"Software Project Management" Walker 104/112

Royce
 Appendix
Analysis Model
In Analysis, we analyze and refine the requirements described in the
Use Cases in order to achieve a more precise view of the
requirements, without being overwhelmed with the details
Again, the Analysis Model is still focusing on WHAT were going to do,
not HOW were going to do it (Design Model). But what were going to
do is drawn from the point of view of the developer, not from the point
of view of the customer
Whereas Use Cases are described in the language of the customer,
the Analysis Model is described in the language of the developer:
o Boundary Classes
o Entity Classes
o Control Classes

"Software Project Management" Walker 105/112

Royce
 Appendix
Why spend time on the Analysis Model,
why not just face the cliff?
By performing analysis, designers can inexpensively come to a better
understanding of the requirements of the system
By providing such an abstract overview, newcomers can understand
the overall architecture of the system efficiently, from a birds eye
view, without having to get bogged down with implementation details.
The Analysis Model is a simple abstraction of what the system is going
to do from the point of view of the developers. By speaking the
developers language, comprehension is improved and by
abstracting, simplicity is achieved
Nevertheless, the cost of maintaining the AM through construction is
weighed against the value of having it all along.

"Software Project Management" Walker 106/112

Royce
 Appendix
Boundary Classes
Boundary classes are used in the Analysis Model to model
interactions between the system and its actors (users or external
systems)
Boundary classes are often implemented in some GUI format
(dialogs, widgets, beans, etc.)
Boundary classes can often be abstractions of external APIs (in the
case of an external system actor)
Every boundary class must be associated with at least one actor:

"Software Project Management" Walker 107/112

Royce
 Appendix
Entity Classes
Entity classes are used within the Analysis
Model to model persistent information
Often, entity classes are created from
objects within the business object model
or domain model

"Software Project Management" Walker 108/112

Royce
 Appendix
Control Classes
The Great Et Cetera
Control classes model abstractions that coordinate, sequence,
transact, and otherwise control other objects
In Smalltalk MVC mechanism, these are controllers
Control classes are often encapsulated interactions between other
objects, as they handle and coordinate actions and control flows.

"Software Project Management" Walker 109/112

Royce
 Literature
Software Project Management
A Unified Framework
Walker Royce
Software Processes
Ian Sommerville 2004
Process and Method:
An Introduction to the Rational Unified
Process

"Software Project Management" Walker 110/112

Royce