Unit-4: Modern Approach to Software Project and Economics

4. 1 Modern project profiles:

Chapter 1 presented five recurring issues of conventional projects. A modern process
framework exploits several critical approaches for resolving these issues (problems):

• Protracted integration and late design changes are resolved by forcing integration into
the engineering stage. This is achieved through continuous integration of an architecture
baseline supported by executable demonstration of the primary scenarios.

• Late risk resolution is resolved by emphasizing an architecture-first approach, in which

the high-leverage elements of the system are elaborated early in the life cycle.

• Analysis paralysis due to requirements-driven functional decomposition is avoided by

organizing lower-level specification along the content of releases rather than along the
product decomposition (by subsystem, by component, etc)

• Adversarial stakeholder relationships are avoided by providing much more tangible and
objective results throughout the life cycle

• The conventional Focus on documents and review meeting rather than product replaced
by a focus on demonstrable results and well-defined sets of artifacts, with more-rigorous
notations and extensive automation supporting a paperless environment.

The ways in which healthy modern projects resolve these five issues are discussed in more detail
in this unit.

Basic Solution:
• Continuous integration.

• Early risk resolution.

• Evolutionary requirements.

• Teamwork among stakeholders.

Elements of Modern software projects and management principles:

4.1.1 Continuous integration
Iterative development produces the architecture first, allowing integration to occur as the
verification activity of the design phase and enabling design flaws to be detected and resolved
earlier in the life cycle.

1|P ag e
Unit-4: Modern Approach to Software Project and Economics
This approach avoids the big-bang integration at the end of a project by stressing continuous
integration throughout the project. Figure given illustrates the differences between the progress
profile of a healthy modern project and that of a typical conventional project. The architecture –
first approach forces integration into design phase through construction of demonstration.

Figure: Progress profile of a modern project

▪ 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.

2|P ag e
Unit-4: Modern Approach to Software Project and Economics
Table: 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%

The Table given identifies the differences in a modern process profile from the
perspective of the cost distribution among the various project workflows.

4.1.2 Early Risk Resolution:

Conventional projects usually do the easy stuff first; modern process attacks the important 20% of
the requirements, use cases, components, and risks. This is the most important principle:
architecture first.

Defining the architecture rarely includes simple steps for which visible progress can be achieved
easily. The effect of the overall life-cycle philosophy on the 80/20 lessons learned over the past 30
years of the software management experience 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.

3|P ag e
Unit-4: Modern Approach to Software Project and Economics
➢ 80% of the errors are caused by 20% of the components.

➢ 80% of software scrap and rework is caused by 20% of the changes.

➢ 80% of the resource consumption (execution, disk space, memory) is consumed by 20% of
the components.

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

Figure: Risk profile of a typical modern project across its life cycle

Figure given above compares the risk management profile of a modern project with profile for a
typical conventional project presented in figure.

4.1.3Evolutionary requirement:

❑ 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
4 | P a g elife-cycle progresses and the requirements understanding matures.
Unit-4: Modern Approach to Software Project and Economics

Figure: Organization of software components resulting from modern process

Top-level system requirements are retained as the vision, but lower level requirements are captured
in evaluation criteria attached to each intermediate release. These artifacts illustrated in figure are
intended to evolve along with the process.

4.1.4 Teamwork among Stakeholders

Many aspects of the classic development process cause stakeholder relationships to degenerate
into mutual distrust, making it difficult to balance requirements, product features, and plans.

The process with more-effective working relationships between stakeholders requires that
customers, users and monitors have both applications and software expertise, remain focused on
the delivery of a usable system.

It also requires a development organization that is focused on achieving customer satisfaction and
high product quality in a profitable manner.

The transition from the exchange of mostly paper artifacts to demonstration of intermediate results
is one of the crucial mechanisms for promoting team work among stakeholders. Major milestone
provide tangible results and feedback from a usage point of view. The tables below shows, designs
are now guilty until proven innocent: The project does not move forward until the objectives of
the demonstration have been achieved.

5|P ag e
Unit-4: Modern Approach to Software Project and Economics
Table: Results of major milestones in a modern process

APPARENT RESUTL REAL RESULT

Early demonstrations expose design issues and Demonstrations expose the important assets and
ambiguities in a tangible form risks of complex software systems early, when
they can be resolved within the context of life-
cycle goals.
The design is non-compliant (so far). Understanding of compliance matures from
important perspectives (architecturally
significant requirements and use cases).
Driving requirements issues are exposed, but Requirements changes are considered in balance
detailed requirements traceability is lacking. with design trade-offs.
The design is considered “guilty until proven Engineering process and issues are tangible, for
innocent.” incorporation into the next iteration’s plans.

4.1.5 Top 10 Software Management Principles:

These principles describe the project expectation associated with the successful application of each
principle (i.e. Royce’ Top Ten Principles for a Modern Process)

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

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 assess 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

6|P ag e
Unit-4: Modern Approach to Software Project and Economics

Figure: Balanced application of modern principles to achieve economics result

From numerous perspectives, the software project manager’s paramount objective is to maintain
the proper balance of emphasis across 10 principles. Figure summarizes this balance theme in the
context of the fundamental software economics equation.

4.1.6 Software Management Best Practices

Many software management best practices have been captured by various authors and industry
organization.

The nine best practices are described here, with WALKER ROYCE commentary on how they
resonate with the process framework, management disciplines, and top 10 principles that
WALKER ROYCE have recommended.

1. Formal risk management

Using an iterative process that confront the risk

2. Agreement on interfaces
This is same as ROYCE architecture-first approach. Getting architecture base-lined forces the
project to gain agreement on various external interfaces.

3. Formal inspections

4. Metric-based scheduling and management:

This important principle is directly related to model-based notation and objective quality control

7|P ag e
Unit-4: Modern Approach to Software Project and Economics
principle. Without rigorous notations for artifacts, the measurement of progress and quality
degenerates into subjective estimates.

5. Binary quality gates at the inch-pebble level

When requirement changes, planning must be rebase-lined. A better approach would be to
maintain fidelity of the plan commensurate with an understanding of the requirements and the
architecture. Rather than inch pebbles, ROYCE recommend establishing milestones in the
engineering stage followed by inch pebbles in the production stage. This is primary message
behind ROYCE evolving level of detail principle.

6. Program-wide visibility of progress versus plan.

Open communication among project team member is obvious necessary.

7. Defect tracking against quality targets

This important principle is directly related to my architecture first and objective quality control
principles. The make-or-break defects and quality targets are architectural. Getting a handle on
these qualities early and tracking their trends are requirement of success.

8. Configuration management
The Airlie software council emphasized configuration management as key to controlling
complexity and tracking changes to all artifacts. The same reasoning behind ROYCE change
management principle.
9. People-aware management accountability

4.2 Next Generation Software Economics and cost Model

Next generation software economics is being practiced by some advanced software organizations.
Many of the techniques, processes and methods described in this books process framework have
been practiced for several years. However, a mature, modern process is nowhere near the state of
practice for average software organization. This chapter introduces several provocative hypotheses
about the future of software economics.

Key points:

Next generation software economics should reflect better economies of scale and improved ROI profile.
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 UML.

8|P ag e
Unit-4: Modern Approach to Software Project and Economics
4.2.1 Next-Generation Cost Models
Software experts hold widely varying opinions about software economics and its manifestation
in software cost estimation models:

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.

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.

4.2.2 Modern Software Economics

Changes that provide a good description of what an organizational manager should strive for in
making the transition to a modern process:

1. Finding and fixing a software problem after delivery

costs 100 times more than fixing the problem in early design phases
2. You can compress software development schedules 25% of nominal, but no more.

9|P ag e
Unit-4: Modern Approach to Software Project and Economics
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. 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.

4.3 Modern Process Transitions

Successful software management is hard work. Technical breakthroughs, process breakthroughs,
and new tools will make it easier, but management discipline will continue to be the crux of
software project success. New technological advances will be accompanied by new opportunities
for software applications, new dimensions of complexity, new avenues of automation, and new
customer with different priorities. Accommodating these changes will perturb many of our
ingrained software management values and priorities. However, striking a balance among
requirement, designs, and plans will remain the underlying objective of future software
management endeavors, just as today.

Key points:

The transition to modern software processes and technologies necessitates several culture shifts that
will not always be easy to achieve.

Lessons learned in transitioning organizations to a modern process have exposed several recurring
themes of success that represent important culture shifts from conventional practice.

A significant should be attempted on a significant project. Pilot projects do not generally attract top
talent and top talent is crucial to success of any significant transition.

4.3.1 Culture Shifts

Several culture shifts must be overcome to transition successfully to a modern software
management process:

● Lower level and mid-level managers are performers

● Requirements and designs are fluid and tangible

10 | P a g e
Unit-4: Modern Approach to Software Project and Economics
● 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

4.3.2 Denouement
Good way to transition to a more mature iterative development process that supports automation
technologies and modern architectures is to take the following shot:

Ready:

Do your homework. Analyze modern approaches and technologies.

Define your process. Support it with mature environments, tools, and components. Plan thoroughly.

Aim:

● Select a critical project. Staff it with the right team of complementary resources and
demand improved results.

Fire:

Execute the organizational and project-level plans with vigor and follow-through.

11 | P a g e