CCPDS-R Case Study and Future Software Project Management Practices

• This appendix presents a detailed case study of a successful software project

that followed many of the techniques presented in this book. Successful here
means on budget, on schedule, and satisfactory to the customer.
• The Command Center Processing and Display System-Replacement
(CCPDS-R) project was performed for the U.S. Air Force by TRW Space and
Defense in Redondo Beach, California, for missile warning system.
• The entire project included systems engineering, hardware procurement,
and software development, with each of these three major activities
consuming about one-third of the total cost( 1987 – 1994)
• The software effort included the development of three distinct software systems
totaling more than one million source lines of code.
• This case study focuses on the initial software development, called the
Common Subsystem, for which about 355,000 source lines were
developed.
• The Common Subsystem effort also produced a reusable architecture, a
mature process, and an integrated environment for efficient development
of the two software subsystems of roughly similar size that followed.
• This case study therefore represents about one-sixth of the overall CCPDS-R
project effort.
• The metrics histories were all derived directly from
the artifacts of the project's process.
• These data were used to manage the project and were
embraced by practitioners, managers, and stakeholders.
• CCPDS-R was one of the pioneering projects that
practiced many modern management approaches.
This appendix provides a practical context that is relevant
to the techniques, disciplines, and opinions provided
throughout this book.
• The system on budget and on schedule, and the users got
more than they expected.
• TRW was awarded the Space and Missile Warning
Systems Award for Excellence in 1991 for "continued,
sustained performance in overall systems engineering
and project execution" .
• A project like CCPDS-R could be developed far more
efficiently today. By incorporating current technologies
and improved processes, environments, and levels of
automation, this project could probably be built today with
equal quality in half the time and at a quarter of the
cost.
• 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 modern project profile .
• A next- generation software cost model should explicitly
separate architectural engineering from application
production.
• Two major improvements in next-generation software cost
estimation models:
1. Separation of the engineering stage from the
production stage will force estimators .(differentiate
between architectural scale and implementation size.)
2. 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.
Modern Software Economics: Changes that provide a good
 Preliminary design
walkthrough-PDW
Critical design walkthrough-
CDW
Turnover Review-TOR
 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
5. Variations among people account for the biggest differences in
software productivity.
6.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.
Next-Generation Software Economics
• Next-generation software economics is being practiced by
some advanced software organizations.
• Many of the techniques, processes, and methods described in
this book's process framework have been practiced for several
years.
• A general structure is proposed for a cost estimation model that
would be better suited to the process framework.
• New approach would improve the accuracy and precision of
software cost estimates, and would accommodate dramatic
improvements in software economies of scale.
• Such improvements will be enabled by advances in software
development environments. Boehm's benchmarks of
conventional software project performance and describe, in
objective terms, how the process framework should improve the
overall software economics achieved by a project or organization
Key Points
• Next-generation software economics should reflect better
economies of scale and improved return on investment
profiles. These are the real indicators of a mature industry.
• Further technology advances in round-trip engineering are
critical to making the next quantum leap in software
economics.
• Future cost estimation models need to be based on better
primitive units defined from well-understood software
engineering notations such as the Unified Modeling Language.
Modern Project Profiles
• Integration and design issues are reduced by
testing and combining parts early in the project.
• Risks are handled early by focusing first on the
system’s main structure (architecture).
• Requirements confusion is avoided by planning
releases based on the system’s parts, not just
documents.
• Stakeholder conflicts are reduced through clear,
measurable results and progress.
• Less paperwork — focus on showing working results
and using automation instead of long meetings and
documents.
1. Continuous Integration:
2. Early Risk Resolution:

20% of requirements take 80% of the engineering effort —

understand key needs first.
20% of components use 80% of the software cost — plan and control
these early.
20% of components cause 80% of errors — focus on testing these first.
20% of changes cause 80% of rework — manage major changes early.
20% of components use 80% of resources — handle performance-
heavy parts first.
20% of people make 80% of the progress — start with a skilled
core team and strong architecture.
3. Team work among stakeholders:
4. Top 10 management principles:

1. Architecture-first approach – Focus first on the system’s main

structure to make the project stable and reduce rework later.

2. Iterative life-cycle process – Work in repeated cycles to find

and fix risks early, leading to smoother progress and fewer surprises.
3. Component-based development – Build the system in smaller,
reusable parts to make it easier to manage and reduce complexity.

4.Change management – Control and track changes properly when many

teams work together.

5.Automation tools – Use tools to reduce manual work and save time.
6. Model-based design – Use visual models for clear, controlled,
and automated design.

7. Quality control – Measure progress and quality using real

project data.

8.Demonstration-based approach – Test and show working

results early and often.

9.Intermediate releases – Release useful parts of the software

early with growing detail.

10.Configurable process – Use flexible and scalable methods to

save cost and improve business results.
Software Management Best Practices
1. Formal risk management
2. Agreement on interfaces
3. Formal inspections
4. Metric-based scheduling 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
Modern Process Transitions

Culture Shifts
• To move to modern software management, organizations must
change their culture.
• Managers as Performers:
Lower and mid-level managers should actively take part in
project work, not just supervise. They should help create and
understand the project plan, not just approve it.
• Clear and Tangible Results:
Instead of focusing only on documents and reports, teams
should focus on building working software. Progress should be
shown through working parts of the product, not paperwork.
• Ambitions Become Shared:
(Implied in continuation) Teams should have shared goals and
work together towards them.
•Good and bad performance show early:
In modern development, early stages decide success or failure.
Good planning and architecture with the right team lead to success.
Poor early work causes future problems.

•Early increments may be imperfect:

Initial versions of software may have flaws, but that’s normal.
Improvement happens step by step in later versions.

•Artifacts matter later:

Detailed documentation (artifacts) like traceability or completeness
can come later. The main focus early on should be on working
software, not paperwork.
Denouement

• The old software process worked in a step-by-step way:

• Went from requirements → design → coding → testing.
• Tried to make each stage 100% complete before moving on.
• Treated all parts (requirements, design, code) as equally
important.
• Focused on keeping clear links (traceability) between all
stages.
Modern Iterative Development Process
• Modern software development is continuous and flexible, not
step-by-step.
• Work goes back and forth between requirements, design,
coding, and testing.
• Focus is on understanding key goals early and managing risks first.
• Detailed checking for completeness happens later in the process.
• Main idea:
Modern methods improve efficiency and reduce time, cost, and
resources.
They reuse existing components and allow smaller teams to build
software faster —
50% less time, 50% fewer people, and 50% less effort than
old methods.
• Figure meaning:
The chart shows that modern projects progress faster and
reach better results compared to the old, conventional process.
Adopting New Techniques
• Moving to new methods or technologies can be risky, but
staying the same can also fail.
• Common advice is to test new ideas on small projects, but
such pilots often don’t create big changes because they
lack top talent and resources.
• Real success happens when key projects with skilled
people adopt the new approach seriously.
• To make a smooth transition:
• Ready: Study and plan your process improvements carefully.
• Aim: Choose an important project and build a strong team.
• Fire: Execute the plan confidently and completely.