All Units Ppts Walker Royce

Software Project Management
By Walker Royce
Part 1
Software Management RenaissanceTable of
Contents (1)
●The Old Way (Conventional SPM)

● The Waterfall Model
● Conventional Software Management Performance
●Evolution of Software Economics

● Software Economics
● Pragmatic Software Cost Estimation
"Software Project Management" Walker 2/112

Royce
Part 1
Software Management RenaissanceTable of
Contents (2)
●Improving Software Economics

● Reducing Software Product Size
● Improving Software Processes
● Improving Team Effectiveness
● Improving Automation through Software Environments
● Achieving Required Quality
● Peer Inspections: A Pragmatic View
●The Old Way and the New

● The Principles of Conventional Software Engineering
● The Principles of Modern Software Management
● Transitioning to an Iterative Process
Royce
The Old Way

Royce
Part 1The Old Way
●Software crisis
● “The best thing about software is its flexibility”

o It can be programmed to do almost anything.
● “The worst thing about software is also its flexibility”

o The “almost anything ” characteristic has made it difficult to plan,
monitor, and control software development.

Royce
Part 1
The Old WayThe Waterfall Model
System
requirements
Software
requirements
Analysis
Program
● Drawbacks
design
● Protracted integration
Coding
and late design breakage
● Late risk resolution
● Requirements - driven
Testing
functional decomposition
● Adversarial stakeholder relationships
● Focus on document Maintenance
and review meetings and reliance
Royce
Part 1
The Old Way Conventional Software Management Performance
1.Finding and fixing a software problem after delivery costs 100 times more
than finding and 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.
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.Walkthroughs catch 60% of the errors.
9.80% of the contribution comes from 20% of contributors.

Royce
Part 1
Evolution of Software Economics

Royce
Part 1Evolution of Software Economics
● Most software cost models can be abstracted into a
function of five basic parameters:
o Size (typically, number of source instructions)

o Process (the ability of the process to avoid non-value-adding
activities)
o Personnel (their experience with the computer science issues and
the applications domain issues of the project)
o Environment (tools and techniques available to support efficient
software development and to automate process)
o Quality (performance, reliability, adaptability…)

Royce
● Most software cost models can be abstracted into a
function of five basic parameters:
Effort=(personnel)(quality)(Environment)(size process)

Royce

Royce

Royce
Part 1Evolution of Software EconomicsThe
predominant cost estimation process
Three main things in any s/w cost estimation

• What cost estimation model should be used(cocomo,checckpoint)
• Whether to measure s/w size in SLOC or Functional points
• What constitute a good estimate

Royce
Part 1Evolution of Software EconomicsThe
predominant cost estimation process
Software manager,
software architecture manager,
software development manager,
software assessment manager
Cost modelers
Risks, options,
trade-offs,
alternatives
Cost estimate

Royce
Part 1Evolution of Software EconomicsPragmatic
software cost estimation
● A good estimate has the following attributes:

o It is conceived and supported by the project manager,
architecture team, development team, and test team
accountable for performing the work.
o It is accepted by all stakeholders as ambitious but realizable.
o It is based on a well defined software cost model with a
credible basis.
o It is based on a database of relevant project experience that
includes similar processes, technologies, environments, quality
requirements, and people.
o It is defined in enough detail so that its key risk areas are
understood and the probability of success is objectively
assessed.

Royce
Part 1 Improving Software Economics
● Five basic parameters of the software cost model:

1.Reducing the size or complexity of what needs to be
developed
2.Improving the development process
3.Using more-skilled personnel and better teams (not
necessarily the same thing)
4.Using better environments (tools to automate the
process)
5.Trading off or backing off on quality thresholds

Royce
Part 1
Improving Software EconomicsImportant trends in improving
software economics
Cost model parameters Trends

Higher order languages
Size (C++, Java, Visual Basic, etc.)
Abstraction and component Object-oriented
based development technologies (Analysis, design, programming)
Reuse
Iterative development
Commercial components
Process Process maturity models
Methods and techniques Architecture-first development
Acquisition reform
Training and personnel

Personnel skill development
People factors Teamwork
Win-win cultures
Integrated tools
Environment (Visual modeling, compiler, editor, etc)
Automation technologies and tools Open systems
Hardware platform performance
Hardware platform
Automation performance
of coding, documents,
Quality
"Software Project Management" Walker Demonstration-based
Performance, reliability, accuracy
assessment
testing, analyses 14/112
Royce Statistical quality control
Part 1
Improving Software EconomicsReducing Software Product
Size
“The most significant way

to improve affordability and return on investment is
usually to produce a product that achieves the design
goals with the minimum amount of human-generated
source material.”
Reuse, object-oriented technology, automatic code production, and higher order
programming languages are all focused on achieving a given system with fewer lines
of human-specified source directives.

Royce
Part 1
Size - Languages
Language SLOC per UFP

UFP -Universal Function Points Assembly 320
The basic units of the function points
SLOC metrics
are external user inputs, C 128 are useful estimators for software
external outputs,
after a candidate solution is formulated
internal logic data groups, Fortran 77 105 and
external data interfaces,
an implementation language is known.
and external inquiries. Cobol 85 91
Ada 83 71
C++ 56
Ada 95 55
Java 55
Visual Basic 35

Royce
Part 1
Size – Object-Oriented Methods
● “An object-oriented model of the problem and its solution encourages a common
vocabulary between the end users of a system and its developers, thus creating a
shared understanding of the problem being solved.”
Here is an example of how object-oriented technology permits corresponding improvements in
teamwork and interpersonal communications.
● “The use of continuous integration creates opportunities to recognize risk early and
make incremental corrections without destabilizing the entire development effort.”
This aspect of object-oriented technology enables an architecture-first process, in which integration
is an early and continuous life-cycle activity.
● An object-oriented architecture provides a clear separation of concerns among
disparate elements of a system, creating firewalls that prevent a change in one part
of the system from rending the fabric of the entire architecture.”
This feature of object-oriented technology is crucial to the supporting languages and environments
available to implement object-oriented architectures.

Royce
Part 1
Size – Reuse
1 Project Solution: $N
and M months
Many-project solution:
2 Project Solution:
50% more cost and
Operating with high value per
100% more time
Development Cost
nd Schedule Resources unit investment, typical of
5 Project Solution:
125% more cost and
commercial products
150% more time
Number of Projects Using Reusable Components

Royce
Part 1
Size – Commercial Components
APPROACH ADVANTAGES DISADVANTAGES

Predictable license costs Frequent upgrades
Commercial Broadly used, mature
Up-front license fees
Recurring maintenance fees
components technology
Available now
Dependency on vendor
Run-time efficiency sacrifices
Functionality constraints
Dedicated support organization Integration not always trivial
Hardware/software No control over upgrades and maintenance
Unnecessary features that consume extra
independence
resources
Rich in functionality Often inadequate reliability and stability
Multiple-vendor incompatibility
Complete change freedom
Custom Smaller, often simpler

implementations
Expensive, unpredictable development
Unpredictable availability date
development Often better performance

Control of development and
Undefined maintenance model
Often immature and fragile
enhancement Single-platform dependency
Drain on expert resources
Royce
Part 1
Improving Software Economics
Improving Software Processes
Part 1
Improving Software Economics
Improving Software Processes
Attributes Metaprocess Macroprocess Microprocess
Subject Line of business Project Iteration
Project profitability Resource management

Objectives Line-of-business profitability
Risk management Risk resolution
Competitiveness
Project budget, schedule, quality Milestone budget, schedule,
quality
Acquisition authorities, customers Software project managers Subproject managers
Audience
Organizational management Software engineers Software engineers
Metrics Project predictability On budget, on schedule On budget, on schedule

Major milestone progress
Revenue, market share Major milestone success
Release/iteration scrap and
Project scrap and rework
rework
Concerns Bureaucracy vs. standardization Quality vs. financial Content vs. schedule
performance
Time scales 6 to 12 months 1 to many years 1 to 6 months
Three levels of processes and their attributes

Royce
Part 1
Improving Software EconomicsImproving Team Effectiveness
(1)
● The principle of top talent: Use better and fewer people.

● The principle of job matching: Fit the task to the skills an
motivation of the people available.
● The principle of career progression: An organization does best
in the long run by helping its people to self-actualize.
● The principle of team balance: Select people who will
complement and harmonize with one another.
● The principle of phase-out: Keeping a misfit on the team
doesn’t benefit anyone.

Royce
Part 1
Improving Software EconomicsImproving Team Effectiveness
(2)
Important Project Manager Skills:

● Hiring skills. Few decisions are as important as hiring decisions. Placing the right person
in the right job seems obvious but is surprisingly hard to achieve.
● Customer-interface skill. Avoiding adversarial relationships among stake-holders is a
prerequisite for success.
● Decision-making skill. The jillion books written about management have failed to provide
a clear definition of this attribute. We all know a good leader when we run into one, and
decision-making skill seems obvious despite its intangible definition.
● Team-building skill. Teamwork requires that a manager establish trust, motivate
progress, exploit eccentric prima donnas, transition average people into top performers,
eliminate misfits, and consolidate diverse opinions into a team direction.
● Selling skill. Successful project managers must sell all stakeholders (including
themselves) on decisions and priorities, sell candidates on job positions, sell changes to
the status quo in the face of resistance, and sell achievements against objectives. In
practice, selling requires continuous negotiation, compromise, and empathy.

Royce
Part 1
Improving Software Economics Achieving Required Quality
Key practices that improve overall software quality:

● Focusing on driving requirements and critical use cases early in the life cycle,
focusing on requirements completeness and traceability late in the life cycle,
and focusing throughout the life cycle on a balance between requirements
evolution, design evolution, and plan evolution
● Using metrics and indicators to measure the progress and quality of an
architecture as it evolves from a high-level prototype into a fully compliant
product
● Providing integrated life-cycle environments that support early and continuous
configuration control, change management, rigorous design methods,
document automation, and regression test automation
● Using visual modeling and higher level language that support architectural
control, abstraction, reliable programming, reuse, and self-documentation
● Early and continuous insight into performance issues through demonstration-
based evaluations

Royce
Part 1 The Old Way and the New

Royce
Part 1
The Old Way and the New
The Principles of Conventional Software Engineering
1.Make quality #1.

2.High-quality software is possible.
3.Give products to customers early.
4. Determine the problem before writing the
requirements.
5.Evaluate design alternatives.
6.Use an appropriate process model.
7.Use different languages for different phases.
8.Minimize intellectual distance..
9.Put techniques before tools.
10.Get it right before you make it faster
Royce
Part 1
The Old Way and the NewThe Principles of Conventional Software
Engineering
1.Make quality #1. Quality must be quantified and mechanism put into place to motivate its achievement.
2.High-quality software is possible. Techniques that have been demonstrated to increase quality include involving the
customer, prototyping, simplifying design, conducting inspections, and hiring the best people.
3.Give products to customers early. No matter how hard you try to learn users’ needs during the requirements phase,
the most effective way to determine real needs is to give users a product and let them play with it.
4.Determine the problem before writing the requirements. When faced with what they believe is a problem, most
engineers rush to offer a solution. Before you try to solve a problem, be sure to explore all the alternatives and don’t be
blinded by the obvious solution.
5.Evaluate design alternatives. After the requirements are agreed upon, you must examine a variety of architectures and
algorithms. You certainly do not want to use an “architecture” simply because it was used in the requirements
specification.
6.Use an appropriate process model. Each project must select a process that makes the most sense for that project on
the basis of corporate culture, willingness to take risks, application area, volatility of requirements, and the extent to
which requirements are well understood.
7.Use different languages for different phases. Our industry’s eternal thirst for simple solutions to complex problems
has driven many to declare that the best development method is one that uses the same notation through-out the life
cycle. Why should software engineers use Ada for requirements, design, and code unless Ada were optimal for all these
phases?
8.Minimize intellectual distance. To minimize intellectual distance, the software’s structure should be as close as
possible to the real-world structure.
9.Put techniques before tools. An undisciplined software engineer with a tool becomes a dangerous, undisciplined
software engineer.
10.Get it right before you make it faster. It is far easier to make a working program run than it is to make a fast program
work. Don’t worry about optimization during initial coding.

Royce
Part 1
Engineering
1.Inspect code. .
2.Good management is more important than good
technology.
3.People are the key to success. .
4.Follow with care.
5.Take responsibility.
6.Understand the customer’s priorities.
7.The more they see, the more they need.
8.Plan to throw one away .
9.Design for change.
10.Design without documentation is not design.

Royce
Part 1
Engineering
1.Use tools, but be realistic.

2.Avoid tricks.
3.Encapsulate..
4.Use coupling and cohesion.
5.Use the McCabe complexity measure.
6.Don’t test your own software.
7.Analyze causes for errors..
8.Realize that software’s entropy increases.
9.People and time are not interchangeable.
10.Expert excellence

Royce
Part 1
Engineering
1.Use tools, but be realistic. Software tools make their users more efficient.
2.Avoid tricks. Many programmers love to create programs with tricks- constructs that perform a function correctly, but in
an obscure way. Show the world how smart you are by avoiding tricky code.
3.Encapsulate. Information-hiding is a simple, proven concept that results in software that is easier to test and much
easier to maintain.
4.Use coupling and cohesion. Coupling and cohesion are the best ways to measure software’s inherent maintainability
and adaptability.
5.Use the McCabe complexity measure. Although there are many metrics available to report the inherent complexity of
software, none is as intuitive and easy to use as Tom McCabe’s.
6.Don’t test your own software. Software developers should never be the primary testers of their own software.
7.Analyze causes for errors. It is far more cost-effective to reduce the effect of an error by preventing it than it is to find
and fix it. One way to do this is to analyze the causes of errors as they are detected.
8.Realize that software’s entropy increases. Any software system that undergoes continuous change will grow in
complexity and become more and more disorganized.
9.People and time are not interchangeable. Measuring a project solely by person-months makes little sense.
10.Expert excellence. Your employees will do much better if you have high expectations for them.

Royce
Part 1
The Principles of Modern Software Management
Part 1
The Old Way and the NewThe Principles of Modern Software
Management
Architecture-first approach The central design element

Design and integration first, then production and test
Iterative life-cycle process The risk management element
Risk control through ever-increasing function, performance, quality
Component-based development The technology element
Object-oriented methods, rigorous notations, visual modeling
Change management environment The control element
Metrics, trends, process instrumentation
Round-trip engineering The automation element
Complementary tools, integrated environments

Royce
Part 1
The Principles of Modern Software Management
Part 2
A Software Management Process Framework

Royce
Part 2
A Software Management Process FrameworkTable of
Contents (1)
●Life-Cycle Phases
● Engineering and Production Stages
● Inception Phase
● Elaboration Phase
● Construction Phase
● Transition Phase
●Artifacts of the Process

● The Artifact Sets
● Management Artifacts
● Engineering Artifacts
● Pragmatic Artifacts
Royce
Part 2
A Software Management Process FrameworkTable 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
Royce
Part 2 Life-Cycle PhasesEngineering and Production Stages
● Two stages of the life-cycle :
1.The 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

Royce
Part 2 Life-Cycle PhasesEngineering 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

Royce
Part 2 Life-Cycle PhasesInception Phase
● To achieve concurrence among stakeholders on the life-cycle

objectives

Royce
● 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)

Royce

Royce
Part 2 Life-Cycle PhasesElaboration Phase
● During the elaboration phase, an executable architecture

prototype is built

Royce
● During the elaboration phase, an executable architecture

prototype is built
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)

Royce

Royce
Part 2 Life-Cycle PhasesConstruction Phase
● During the construction phase :

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

Royce
● During the construction phase :

All remaining components and application features are integrated
into the application All features are thoroughly tested
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

Royce

Royce
Part 2 Life-Cycle PhasesTransition Phase
● The transition phase is entered when baseline is mature enough

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

Royce

Royce
o Synchronization and integration of concurrent construction into
consistent deployment baselines
o Deployment-specific engineering (commercial packaging and
production, field personnel training)
1.Assessment of deployment baselines against the complete
vision and acceptance criteria in the requirements set

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.

Royce
Part 2
Artifacts of the Process
Requirements Design Set Implementation Deployment
Set Set Set
1.Vision document
2.Requirements 1.Design model(s) 1.Source code 1.Integrated product
model(s) 2.Test model baselines executable baselines
3.Software architecture 2.Associated compile- 2.Associated
description time files run-time files
3.Component 3.User manual
executables
Management Set
Planning Artifacts Operational Artifacts
1.Work breakdown structure 5.Release descriptions
2.Bussines case 6.Status assessments
3.Release specifications 7.Software change order database
4.Software development plan 8.Deployment documents
9.Enviorement

Royce
Part 2
Artifacts of the ProcessManagement 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.
Royce
Part 2
● Release Specifications
Typical release specification outline :
I. Iteration content
II. Measurable objectives
A. Evaluation criteria
B. Follow-through approach
1.Demonstration plan
A. Schedule of activities
B. Team responsibilities
2.Operational scenarios (use cases demonstrated)
A. Demonstration procedures
B. Traceability to vision and business case
Two important forms 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. Royce
Part 2
● Software Development Plan – the defining document for the project’s
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 automated regression testing

Royce
Part 2
Artifacts of the ProcessEngineering 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 user’s 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.
Royce
Part 2
Artifacts of the ProcessEngineering Artifacts
Typical architecture description outline :
1.Architecture 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
2.Architecture views
A. Design view 1.Architecture performance
B. Process view
C. Component view 2.Rationale, 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 user’s perspective than the development team.
● It also provides a necessary basis for test plans and test cases, and for onstruction
of automated test suites.
Royce
Part 2
Artifacts of the ProcessPragmatic 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.

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. Make/buy
decisions ,customer components are elaborated.
● 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.

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 without violating the constraints.

Royce
Part 2
Model-Based Software Architectures A Technical
Perspective

Royce
Part 2
Perspective
The model which draws on the foundation of architecture

developed at Rational Software Corporation and particularly
Architecture
on Philippe Kruchten’s concepts of software architecture :
Description
An architecture is described through several views, Document
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

Royce
Part 2
Perspective
● The use case view describes how the system’s 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, inter-process 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, including the
allocation of logical processes in the distribution view to physical resources of the
deployment network.

Royce
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
3.Requirements workflow: analyzing the problem space and evolving
the requirements artifacts
4.Design workflow: modeling the solution and evolving the architecture and
design artifacts
5.Implementation workflow: programming the components and evolving
the implementation and deployment artifacts
6.Assessment workflow: assessing the trends in process and product quality
7.Deployment workflow: transitioning the end products to the user
51/112
"Software Project Management" Walker
Part 2
● Four basic key principles:

1.Architecture-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.
2.Iterative life-cycle process: the activities and artifacts of any given
workflow may require more than one pass to achieve adequate
results.
3.Roundtrip engineering: Raising the environment activities
to a first-class workflow is critical; the environment is the tangible
embodiment of the project’s process and notations for producing
the artifacts.
4.Demonstration-based approach: Implementation and assessment
activities are initiated nearly in the life-cycle, reflecting the emphasis on
constructing executable subsets of the involving architecture.
Royce
Part 2

Royce
Part 2

Royce
Part 2

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 iteration’s workflow:
Allocated Results from the

usage scenarios Previous iteration
Management
Requirements
Design
Implementation
Assessment
Deployment
Results for the next

iteration

Royce
Part 2

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.

Royce
Part 2
● Three types of joint management reviews are conducted
throughout the process:
1.Major 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.

Royce
Part 2

Royce
Part 2
Major milestones # MCheckpoints of the Process

Royce
Part 2
Minor milestones # Checkpoints of the Process

Royce
Part 2
Minor milestones # Checkpoints of the Process

Royce
Part 2
Status Assessment # Checkpoints of the Process

Royce
Part 2
Status Assessment # Checkpoints of the Process

Royce
Part 3
Software Management Disciplines

Royce
Part 3
Software Management DisciplinesTable 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
Royce
Part 3
Software Management DisciplinesTable 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

Royce
Part 3
Iterative Process PlanningWork 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.
Royce
Part 3
Iterative Process PlanningWork Breakdown Structures

Royce
Part 3
Conventional Work Breakdown Structures

Royce
Part 3
Evolutionary Work Breakdown Structures

Royce
Part 3
Iterative Process PlanningPlanning 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

Royce
Part 3
Iterative Process PlanningThe 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 as constraints.
Royce
Part 3
Iterative Process PlanningThe 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.

Royce
Part 3
Iterative Process PlanningThe Iteration Planning Process
Engineering Stage Production Stage

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 ● Fine-grained variance analysis of actual
actual vs. planned expenditures vs. planned expenditures
● Tuning the top-down project-independent
planning guidelines into project-specific
planning guidelines.
Royce
Part 3
Iterative Process Planning
The Iteration Planning Process

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

Royce
Part 3
Project Organizations and Responsibilities
Project Organizations

Royce
Part 3
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
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

Royce
Part 3
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
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

Royce
Part 3
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
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

Royce
Part 3
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
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

Royce
Part 3
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%
Inception Elaboration
nn
Transition Construction
Software Software
management management
10% 10%
Software Software Software Software
Software Software
architecture development development assessment
assessment architecture
5% 35% 50% 30%
50% 10%

Royce
Part 3
Process Automation

Royce
Part 3
Process Automation

Royce
Part 3
Round Trip Engineering

Royce
Part 3
Change Management # Software Change Order

Royce
Part 3
Change Management # Configuration Baseline

Royce
Part 3
Change Management # Configuration Baseline

Royce
Part 3
Change Management # Organization Policy

Royce
Part 3
Project Environment

Royce
Part 3
Project Control and Process Instrumentation
Goals of Software metrics

Royce
Part 3
7-Core Metrics

Royce
Part 3
7-Core Metrics

Royce
Part 3
7-Core Metrics
Management Indicators Work and Progress

Royce
Part 3
7-Core Metrics
Management Indicators
Budget Cost and Expenditure

Royce
Part 3
7-Core Metrics

Royce
Part 3
7-Core Metrics

Royce
Part 3
7-Core Metrics
Staff and team dynamics

Royce
Part 3
7-Core Metrics
Quality Indicators
Breakage and modularity

Royce
Part 3
7-Core Metrics
Quality Indicators
MTBF and Maturity

Royce
Part 3
7-Core Metrics

Royce
Part 3
Tailoring the ProcessProcess Discriminants
The two primary dimensions of process variability

Higher technical complexity
● Embedded, real-time, distributed, Average software project
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

Royce
Part 3
Tailoring the ProcessExample: 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
Royce
Part 4
Looking Forward

Royce
Part 4
Looking ForwardTable 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
Royce
Part 4
Modern Project ProfilesContinuous 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%

Royce
Part 4
Modern Project ProfilesContinuous 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.

Royce
Part 4
Modern Project ProfilesEarly 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.

Royce
Part 4
Modern Project ProfilesEvolutionary 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.
Royce
Part 4
Modern Project ProfilesTeamwork 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.
Royce
Part 4
Modern Project ProfilesTop 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

Royce
Part 4
Modern Project ProfilesTop 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

Royce
Part 4
Modern Project ProfilesSoftware 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

Royce
Part 4
Next-Generation Software EconomicsNext-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.
Royce
Part 4
Next-Generation Software EconomicsNext-Generation
Cost Models
● Some of today’s 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.
Royce
Part 4
Next-Generation Software EconomicsModern 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.

Royce
Part 4
Next-Generation Software EconomicsModern 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.
Royce
Part 4
Modern Process TransitionsCulture 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 everyone’s 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
Royce
Part 4
Modern Process TransitionsDenouement
● 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.

Royce
Appendix

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.
Royce
Appendix
What’s 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

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.

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

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.

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

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
Royce
Appendix
Sample Use Case Model Survey

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 we’re going to do,
not HOW we’re going to do it (Design Model). But what we’re 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

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 ‘bird’s 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
developer’s 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.

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:

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

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.

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

Royce

All Units Ppts Walker Royce

Uploaded by

Copyright:

Available Formats

You might also like

All Units Ppts Walker Royce

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

All Units Ppts Walker Royce

Uploaded by

Copyright:

Available Formats

Software Project Management

●The Old Way (Conventional SPM)

●Evolution of Software Economics

"Software Project Management" Walker 2/112

●Improving Software Economics

●The Old Way and the New

"Software Project Management" Walker 4/112

● “The best thing about software is its flexibility”

● “The worst thing about software is also its flexibility”

"Software Project Management" Walker 5/112

The Old Way Conventional Software Management Performance

"Software Project Management" Walker 7/112

"Software Project Management" Walker 8/112

o Size (typically, number of source instructions)

"Software Project Management" Walker 9/112

"Software Project Management" Walker 9/112

"Software Project Management" Walker 9/112

"Software Project Management" Walker 9/112

Three main things in any s/w cost estimation

"Software Project Management" Walker 11/112

"Software Project Management" Walker 11/112

● A good estimate has the following attributes:

"Software Project Management" Walker 12/112

● Five basic parameters of the software cost model:

"Software Project Management" Walker 13/112

Cost model parameters Trends

Training and personnel

“The most significant way

"Software Project Management" Walker 15/112

Language SLOC per UFP

"Software Project Management" Walker 16/112

"Software Project Management" Walker 17/112

150% more time

Number of Projects Using Reusable Components

"Software Project Management" Walker 18/112

APPROACH ADVANTAGES DISADVANTAGES

Custom Smaller, often simpler

development Often better performance

Attributes Metaprocess Macroprocess Microprocess

Subject Line of business Project Iteration

Project profitability Resource management

Metrics Project predictability On budget, on schedule On budget, on schedule

Three levels of processes and their attributes

● The principle of top talent: Use better and fewer people.

"Software Project Management" Walker 22/112

Important Project Manager Skills:

"Software Project Management" Walker 23/112

Key practices that improve overall software quality:

"Software Project Management" Walker 24/112

"Software Project Management" Walker 25/112

1.Make quality #1.

"Software Project Management" Walker 26/112

"Software Project Management" Walker 27/112

1.Use tools, but be realistic.

"Software Project Management" Walker 28/112

"Software Project Management" Walker 28/112

Architecture-first approach The central design element

"Software Project Management" Walker 29/112

"Software Project Management" Walker 30/112