UNIT – V
5.1 CCPDS-R CASE STUDY
This represents a detailed case study of a successful software project that followed many of
the techniques.
Successful here means on budget, on schedule, and satisfactory to the customer.
The Command Centre Processing and Display System-Replacement(CCPDS-R) project was
performed for the U.S. Air Force by TRW Space and Defence in Redondo Beach, California.
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.
The schedule spanned 1987 through 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.
This case study therefore represents about one-sixth of the overall CCPDS-R project effort.
Although this case study does not coincide exactly with the management process presented in
this book nor with all of today's modern technologies,
It used most of the same techniques and was managed to the same spirit and priorities.
TRW delivered Key Points are
i) An objective case study is a true indicator of a mature organization and a mature project
process.
ii) The software industry needs more case studies like CGPDS-R.
iii) The metrics histories were all derived directly from the artifacts of the project's process.
iv) These data were used to manage the project and were embraced by practitioners,
managers, and stakeholders.
v) CCPDS-R was one of the pioneering projects that practiced many modern management
approaches.
1
vi) This case study provides a practical context that is relevant to the techniques, disciplines.
vii) 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.
5.2 MODERN PROJECT PROFILES
A modern process framework exploits several critical approaches for resolving these issues
1. Protracted integration and late design breakage are resolved forcing integration into
engineering stage. This achieved through continuous integration an architecture baseline
supported by executable demonstrations of the primary scenarious
early the cycle.
2. Late risk resolution is resolved by emphasizing architecture-first approach, which high -
leverage elements of the system are elaborated early the life cycle.
3. Requirements-driven functional decomposition is avoided organizing level specifications
along the content of releases rather along the product decomposition (by subsystem, by
component, etc.).
4. Adversarial stake holder relationships are avoided by providing much more tangible and
objective results throughout the life cycle.
5. The Conventional focus on documents and review meetings is replaced by a focus on
demonstrable results and well defined sets of artifacts and paperless automation environment
support.
5.2.1 CONTINUOUS INTEGRATION
Iterative development produces the architecture first approach.
It allows integration to occur at the verification activity of the design phase and enabling
design flaws to be detected and resolved earlier in the life cycle.
The architecture-first approach forces integration into the design phase through the
construction of demonstrations.
2
The demonstrations makes you to resolve design breakage issues efficiently.
Figure 5.1 Progress profile of a modern project
5.2.2 EARLY RISK RESOLUTION
The engineering stage of the life cycle (inception and elaboration phases) focuses on
confronting the risks and resolving them before the big resource commitments of the
production stage.
A modern process makes use of 80 to 20% parity principle to resolve many issues.
i) 80% of the engineering is consumed by 20% of the requirements.
Understand the driving requirements completely before committing resources to full-scale
development.
ii) 80% of the software cost is consumed by 20% of the components.
Elaborate the cost critical components first so that planning and control of cost drivers are well
understood early in the life cycle.
iii) 80% of the errors are caused by 20% of the components.
Elaborate the reliability critical components first so that assessment activities have enough time
to achieve the necessary level of maturity.
iv) 80% of software scrap and rework is caused by 20% of the changes.
3
Elaborate the change critical components first.
v) 80% of the resource consumption (execution time, disk space, memory) is consumed by
20% of the components.
Elaborate the performance critical components first so that engineering trade-offs with
reliability, changeability, and cost-effectiveness can be resolved as early in the life cycle as
possible.
vi) 80% of the progress is made by 20% of the people.
Make sure that the initial team for planning the project and designing the architecture is of the
highest quality.
An adequate plan and adequate architecture can then succeed with an average construction
team.
An inadequate plan or inadequate architecture will probably not succeed, even with an expert
construction team.
Figure 5.1 compares the risk management profile of a modern project with the profile for a
typical conventional project presented in Figure 1-3.
Figure 5.2 Risk profile of a typical modern project across its life cycle
5.2.3 EVOLUTIONARY REQUIREMENTS
4
Conventional approaches decomposed system requirements into subsystems, subsystem
requirements into component requirements, and component requirements into unit
requirements.
The organization of requirements was structured so that 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.
There are now complex relationships between requirements statements and design elements,
including 1 to 1, many to 1, 1 to many, conditional, time-based, and state-based.
Top level system requirements are retained as the vision, but lower level requirements are
captured in evaluation criteria attached to each intermediate release.
The artifacts, illustrated in Figure 5.2, are intended to evolve along with the process, with more
and more fidelity (loyalty or faithfulness) as the life cycle progresses and requirements
understanding matures.
This is a fundamental difference from conventional requirements management approaches, in
which this fidelity was pursued far too early in the life cycle.
Figure 5.3: Organization of software components resulting from a modern process
5
5.2.4 TEAMWORK AMONG STAKEHOLDERS
Iterative process focuses on more effective working relationships between stakeholders.
Focuses on more deliverables rather than agreements and paper documents.
The transition from the exchange of mostly paper artifacts to demonstration of intermediate.
Major milestones provides tangible results and feedback from a usage point of view.
Results is one of the crucial mechanisms for promoting teamwork among stakeholders.
5.3 TOP 10 SOFTWARE MANAGEMENT PRINCIPLES
The principles should be described in accordance with the modern project profile.
1. Base the process on an architecture-first approach:-
An early focus on the architecture results in a solid foundation for the overall success of the
project.
2. Establish an iterative life-cycle process that confronts risk early:-
A more dynamic planning framework supported by an iterative process results in better risk
management and more predictable performance.
3. Transition design methods to emphasize component-based development: -
The complexity of a software effort is mostly a function of the number of human-generated
artifacts.
Making the solution smaller reduces management complexity.
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:-
Automation enables teams to spend more time on engineering and less time on overhead tasks.
6. Capture design artifacts in rigorous, model-based notation:-
An engineering notation for design enables complexity control, objective assessment, and
automated analyses.
7. Instrument the process for objective quality control and progress assessment: -
Progress and quality indicators are derived directly from the evolving artifacts.
8. Use a demonstration based approach to assess intermediate artifacts: -
6
Integration occurs early and continuously throughout the life cycle. Intermediate results are
objective and tangible.
9. Plan intermediate releases in groups of usage scenarios with evolving levels of detail: -
Requirements, designs, and plans evolve in balance.
Useful software releases are available early in the life cycle.
10. Establish a configurable process that is economically scalable:-
Methods, techniques, tools, and experience can be applied straightforwardly to a broad domain,
providing improved return on investment across a line of business.
Note: The software project manager has to maintain proper balance of emphasis across the 10
principles.
Figure 5.4: Balanced application of modern principles to achieve economic results
5.4 SOFTWARE MANAGEMENT BEST PRACTICES
Many software management best practices have been captured by various authors and industry
organizations.
One such organization framed nine best practices.
We will have a comparative study of nine best principles with top 10 principles of Modern
practices
7
1. Formal risk management.
Use an iterative process risk can be confronted (faced)
2. Agreement on interfaces.
Different words may be used, but this is exactly the same intent as architecture – first
principle.
3. Formal inspections.
The assessment workflow throughout the life cycle, along with the other engineering
workflows and must balance several defect removal strategies.
4. Metric-based scheduling and management.
This directly related to model – based notation and objective quality control principles
5. Binary quality gates at the inch-pebble level (breakdown of each task into very small
components) .
Rather than inch pebbles, the author recommends establishing milestones in the engineering
stage followed by inch pebbles in the production stage.
This is matches with evolving levels of detail principle.
6. Programmable visibility of progress versus plan.
Open communications among project team members is necessary.
No top 10 principle matches with this. But it is a good practice
7. Defect tracking against quality levels.
This is directly related to architecture – first and objective quality control principles.
8. Configuration management.
It is similar to change management principle
9. People-aware management accountability.
No top 10 principle matches with this. But it is a good practice
Note: Some important principles are omitted here are configurability, component and model
based principles.
5.5 NEXT GENERATION SOFTWARE ECONOMICS
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.
8
Software experts hold widely varying opinions about software economics and its
manifestation in software cost estimation models:
The industry is having debates on above topics that should be used for cost estimation.
It will be difficult to improve empirical estimation models while the project data going into
these models are noisy (unstructured, meaningless, not able to interpret) or and highly
uncorrelated (not related) and are based on differing process and technology foundations.
Despite of much advancement still some cost estimation model vendors are using
conventional process only.
Some of the most popular cost estimation models are not well matched to an iterative process.
A next-generation software cost model should explicitly separate architectural engineering
from application production.
Next-generation software cost models should estimate large-scale architectures with
economies of scale.
The reason is that the larger the system, the more opportunity there is to exploit automation
and to reuse common processes, components, and architectures.
Next-generation environments and infrastructures are moving to automate and standardize
many of these management activities, thereby requiring a lower percentage of effort for
overhead activities as scale increases.
Reusing common processes across multiple iterations of a single project, multiple releases of a
single product, or multiple projects in an organization also relieves many of the sources of
diseconomy of scale.
Critical sources of scrap and rework are eliminated by applying precedent experience and
mature processes.
9
Establishing trustworthy plans and using reliable components reduce other sources of scrap
and rework.
While most reuse of components results in reducing the size of the production effort, the reuse
of processes, tools, and experience has a direct impact on the economies of scale.
Another important difference is the cost model is that architectures and applications have
different units of mass (scale Vs size) and are representations of the solution space.
Scale might be measured in terms of architecturally significant elements (classes, components,
processes, nodes), and size might be measured in SLOC or megabytes of executable code.
The cost estimation model must be governed by the basic parameters of a candidate solution.
Figure 5.5 Differentiating potential solutions through cost estimation
If none of the value propositions is an acceptable solution to the problem, further candidate
solutions need to be pursued or the problem statement needs to change.
The Required or expected two major improvements in next generation software cost
estimation models are
1. Separation of the engineering stage from the production stage will force estimators to
differentiate between architectural scale and implementation size. This will permit greater
accuracy and more-honest precision in life-cycle estimates.
10
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. These measures can
also be traced more straightforwardly into the costs of production.
Note: The two possible major breakthroughs in software industry in near future are
1. The availability of integrated tools that automate the transition of information between
requirements, design, implementation, and deployment elements. i.e Roundtrip engineering
implementation (it is Risky but straight forward)
2. Focus on converting today’s four sets of fundamental technical artifacts into three sets by
automating the activities associated with human-generated source code, thereby eliminating
the need for a separate implementation set (it is a major paradigm shift).
5.6 MODERN SOFTWARE ECONOMICS
These expected changes 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 finding
and fixing the problem in early design phases.
Modern processes, component-based development technologies, and architecture frameworks
are explicitly targeted at improving this relationship.
Advances in encapsulation techniques should reduce the impact on resources significantly.
Early insight into architecture will lead to risk confronting activities
2. You can compress software development schedule 25% of nominal, but no more.
This metric should remain valid for the engineering stage of the life cycle
3. For every $1 you spend on development, you will spend $2 on maintenance.
A mature iterative process and a good architecture can reduce scrap and rework levels
considerably
4. Software development and maintenance costs are primarily a function of the number of
source lines of code.
Commercial components, reuse, and automatic code generators can seriously pollute the
meaning of a SLOC.
Construction costs will still be driven by the complexity of the bill of materials.
11
The use of more components, more types of components, more sources of components, and
more custom components will necessitate more integration of labour and will drive up costs.
5. Variations among people account for the biggest differences in software productivity.
In case of engineering industry intellectual property is the real product, the dominant
productivity factors will be personnel skills, team work, and motivations
6. The overall ratio of software to hardware costs is still growing. In 1955; it was 15:85; in
1985, 85:15
The main impact of this metric on software economies is that hardware continues to get
cheaper. Processing cycles, storage, and network bandwidth continue to offer new
opportunities for automation.
Consequently, software environments are playing a much more important role.
7. Only about 15% of software development effort is devoted to programming.
The modern projects are programming at a much higher level of abstraction.
8. Software systems and products typically cost 3 times as much per SLOC as individual
software programs. Software system products cost 9 times as much.
This diseconomy of scale should be greatly relieved with a modern process and modern
technologies.
9. Walkthroughs catch 60% of the errors.
While the environment catches most of the first-level inconsistencies and errors, the really
important architecturally issues can be exposed only through demonstration and early testing
and resolved through human scrutiny.
10. 80% of the contribution comes from 20% of the contributors.
This relationship is timeless and constitutes the background philosophy to be applied
throughout the planning and conduct of a modern SPM process.
5.7 MODERN PROCESS TRANSITIONS
The transition to modern software processes and technologies necessitates several culture shifts
that will not always be easy to achieve.
Lessons learned to transitioning organizations to a modern process have exposed several
recurring themes of success that represent culture shifts from conventional practice.
12
Several culture shifts must be overcome to transition successfully to a modern software
management process
1. Lower level and mid-level managers are performers.
2. Requirements and designs are fluid and tangible
3. Ambitious demonstrations are encouraged
4. Good and bad project performance is much more obvious earlier in the life cycle
5. Early increments will be immature
6. Artifacts are less important early, more important later.
7. Real issues are surfaced and resolved systematically
8. Quality assurance is everyone’s job, not a separate discipline
9. Performance issues arise early in the life cycle
10. Investments in automation are necessary.
11. Good software organizations should be more profitable
10.
13
