IMPROVING SOFTWARE PROCESSES

Process is an overloaded term. Modern software processes are iterative. For software -
oriented organizations, there are many processes and sub processes. There are three levels of
processes: metaprocess, macroprocess and microprocess.
Metaprocess: Metaprocess is the basic level which deals with an organization's policies,
procedures and practices for pursuing a software intensive line of business. The focus of this
process is an organizational economics and long-term strategies.
Macroprocess: Macroprocess is the second level which deals with projects policies,
procedures and practices for producing a complete software product. The focus of this process is
to create an instance of the metaprocess for a specific set of constraints.
Microprocess: Microprocess is the third level which deals with a project team's policies,
procedures and practices for achieving an artifact of the software process. The focus of this
process is on achieving an intermediate product baseline.
Although these three levels of processes overlap at a particular
circumstance, they differ in their attributes, such as objectives, audience, metrics, concerns and
time scales.

Three levels of process and their attributes

ATTRIBUTES METAPROCESS MACROPROCESS MICROPROCESS

Subject line of business project iteration
Objectives line of business, project profitability, resource management,
profitability, project budget, risk risk resolution, milestone
competitiveness management, schedule, budget, schedule, quality
quality
Audience acquisition software project subproject managers,
authorities, customers, managers, software software engineers
organizational engineers
management
Metrics project predictability on budget, on schedule, on budget, on schedule,
 revenue, market share major milestone success, major milestone progress,
project scrap and rework release / iteration scrap
and rework
Concerns bureaucracy vs., quality vs. financial content vs. schedule
standardization performance
Time scales 6 to 12 months 1 to many years 1 to 6 months

All project processes consists of productive activities and overhead activities. Productive
activities result in tangible progress towards the end product whereas overhead activities have an
intangible impact on the end product. Productive activities include prototyping, modeling,
coding, debugging and user documentation. Overhead activities include plan preparation,
documentation, progress monitoring, risk assessment, financial assessment, configuration
control, quality assessment, integration, testing, late scrap and rework, management, personnel
training, business administration and other tasks. Overhead activities require less effort and
productive activities require more effort. The objective of process improvement is to maximize
the allocation of resources to productive activities and minimize the impact of overhead activities
on resource such as personnel, computers and schedule.
The quality of the software process depends on the schedule for producing the software
product. Schedule improvement has at least 3 dimensions:
1. We could take an N-step process and improve the efficiency of each step.
2. We could take an N-step process and eliminate some steps so that it becomes only an M-
step process.
3. We could take an N-step process and use more concurrency in the activities being
performed or the resources being applied.
The primary focus of process improvement is on achieving an adequate solution in minimum no.
of iterations and eliminating as much scrap and rework as possible.
 IMPROVING TEAM EFFECTIVENESS

Teamwork is much more important than the sum of the

individuals. With software teams, a project manager needs to balance the team members. Team
management includes.
 A well-managed project can succeed with a nominal engineering team.
 A mismanaged project will almost never succeed, even with an expert team of engineers.
 A well-architected system can be built by a nominal team of software builders.
 A poorly architected system will be collapsed even with an expert team of builders.
The following are the five staffing principles given by Boehm for staffing a software project:
1. The Principle of Top Talent: Use better and fewer people.
The quality of the people is important. It is better to use less number of people with more
skills.
2. The Principle of Job Matching: Fit the tasks to the skills and motivation of the people
available.
The skill sets of people are different. A best programmer may not be suitable as an
architect or a manager. Similarly an architect or manager are not suitable as programmers.
Depending on their skill sets, tasks should be assigned to them. Moreover they should be
motivated to their jobs.
3. The Principle of Career Progression: An organization does best in the long run by helping
its people to self-actualize.
Organizational training programs having educational value and project training programs
are helpful for the individuals to develop their career.
4. The Principle of Team Balance: Select people who will complement and harmonize with
one another.
The psychology of the team members will balance the team. They should be friendly and
quickly mingle with their co-members of the team.
5. The Principle of Phase out: Keeping a-misfit on the team doesn't benefit anyone.
A misfit gives the reason to find a better person or to live with fewer people. A misfit
demotivates other team members, will not self-actualize and destroys the team balance.
Of the five principles, team balance and job matching are the primary objectives. The top
talent and phase out principles are the secondary objectives as they are applied within the context
of team balance.
Software project managers need many leadership qualities in order to improve team
effectiveness. The following are the attributes of successful software project manager:
1. Hiring skills- Placing the right person in the right job.
2. Customer - interface skills - Avoiding adversarial relationships among stakeholders.
3. Decision-making skill s- A good leader will take right decision - at the right time.
4. Team-building skills- Teamwork makes anything possible.
5. Selling skills- successful project managers should have this skill which requires
continuous negotiation and compromise.
 IMPROVING SOFTWARE QUALITY

General Quality improvements with a modern process

Quality Driver Conventional Process Modern iterative process

Requirements Discovered late Resolved early
misunderstandings
Development risk Unknown until late Understood and resolved early
Commercial Mostly unavailable Still a quality driver, but trade offs must
components be resolved early in the life cycle.
Change management Late in the life cycle, Early in the life cycle, straight forward.
chaotic and malignant
Design errors Discovered late Resolved early
Automation Most error-prone manual Mostly automated, error-free evolution
procedures of artifacts
Schedules Over constrained Tunable to quality, performance and
technology
Resource adequacy Unpredictable Predictable
Target performance Paper-based analysis or Executing prototypes, early performance
separate simulation feedback, quantitative understanding.
Software process rigor Document based Managed, measured and tool-supported.

The overall software quality can be improved by means of 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 on balance between requirements evolution,
design evolution and plan evolution throughout the life cycle. The improvement of software
quality also includes the use of metrics and indicators to measure the progress and quality of
architecture, use of visual modeling and higher level languages that support reliable
programming and reuse.
The following chronology has to be followed in assessing the performance of a software project:
Project inception - The proposed design at low risk with adequate performance margin, based
on paper analysis.
Initial design review - The actual application algorithms and database sizes are known. But the
infrastructure including the operating system overhead, database management overhead, inter
process and network communications overhead are unknown.
Mid life-cycle design review - Early benchmarks and initial tests begin to expose.
Integration and test - Serious performance problems were not known.
In most large-scale distributed systems composed of many interactive components, a
demonstration based approach provides more-accurate assessments of performance issues.
 PEER INSPECTIONS

The key aspect of a quality system is the peer inspections. Peer reviews are the secondary
mechanisms to inspect the quality. The following are some of the primary quality mechanisms to
be emphasized in the management process:
 Transitioning engineering information from one artifact set to another
 Major milestone demonstrations
 Environment tools such as compilers, debuggers, analyzers, etc.
 Life-cycle testing
 Change management metrics
Inspections are a good vehicle for holding authors accountable for quality
products. All authors of software and documentation should have their products scrutinized as a
natural by-product of the process. Junior authors need to have a random component inspected
periodically by the senior author and they also can learn by inspecting the products of senior
authors. Varying levels of inspection are performed continuously when developers are reading or
integrating software with another author’s software, and during testing by independent test
teams. Significant design errors and architectural issues cannot be reviewed by the peer
inspections. Architectural issues are exposed only to the following activities.
 Analysis prototyping or experimentation
 Constructing design models
 Committing the current state of the design model to an executable implementation
 Demonstrating the current implementation strengths and weaknesses in context of use
cases.
 Incorporating lessons learned back into the models, use cases, implementations and plans
Peer inspections are not primary checkpoints. Focusing a large percentage of
projects resources on human inspections is not good. Quality assurance is everyone's
responsibility and should be integral to almost all process activities instead of separate discipline
performed by quality assurance specialists.
 PRINCIPLES OF CONVENTIONAL SOFTWARE
ENGINEERING
Conventional software engineering has numerous well-established principles. Many are
still valid and others are obsolete.
1. Make quality #1
Quality must be quantified and mechanisms must be used to motivate its achievement.
But it is not possible to specify or manage the achievement of quality in the conventional
software management until the trade-offs among features, quality, cost and schedule are
understood. But this understanding can be achieved only in the modern software management.
2. High-quality software is possible
The quality of the software can be increased by using the techniques which include
involving the customer, prototyping, simplifying design, conducting inspections and hiring the
best people.
3. Give products to customers early
It is difficult to know the user's needs during the requirements phase. Due to this it may
take time to design the product. But the most effective way is to determine the real needs of the
user and give the product as early as possible.
4. Determine the problem before writing the requirements
When a problem occurs many engineers come forward with the solution. Before
accepting it as a solution blindly, all the alternatives should be explored to make it obvious. The
parameters of the problem become more tangible as a solution evolves. So understand the
problem first and then go for the requirements.
5. Evaluate design alternatives
After the requirements are specified the next step is to go for a variety of architectures
and algorithms. Architecture should not be used because it was used in the requirements
specification. The requirements should precede the architecture rather than evolving together.
Also, the architecture should be incorporated in the requirements specification.
6. Use an appropriate process model
No individual process is universal. The processes should be flexible rather than a single
rigid instance. Each project must select a process so that it is based on 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
Many of the software engineers use Ada for requirements, design and coding so that they
can get simple solutions even for complex problems. But it is not a fair way. The best
development method is to use the same notation throughout the life cycle.
8. Minimize intellectual distance
This principle is the primary motivation for the development of object-oriented
techniques, component-based development and visual modeling. To minimize intellectual
distance the structure of the software should be as close as possible to the real-world structure.
9. Put techniques before tools
An undisciplined software engineer with a tool will become a dangerous, undisciplined
software engineer. A disciplined software engineer with good tools will become disciplined
software expert with no tools.
10. Get it right before you make it faster
Having something executing early helps to understand the performance issues. It is very
easier to make a working program run faster than it is to make a fast program work. One should
not worry about optimization during initial coding.
11. Inspect code
Inspections are very effective for resolving problems. Inspecting the detailed design and
code is a much better way to find errors than testing.
12. Good management is more important than good technology
Good management motivates people to do their best. The best technology will not
compensate for poor management and a good management can produce great results even with
less resources. A well-managed team can do great things with a less budget and schedule. Good
management and low qualified team are mutually exclusive because a good manager will attract,
configure and retain a quality team.
13. People are the key to success
Highly skilled people with appropriate experience, talent and training are the key to
success. The right people even with insufficient tools, languages and process will succeed. The
wrong people although with appropriate tools, languages and process will fail.
14. Follow with care
It is not right to sit idle just because everybody is doing something. Its applicability
should be assessed to the current environment. Techniques such as object orientation,
measurement, reuse, process improvement will increase the quality, decrease the cost and
increase user satisfaction.
15. Take responsibility
In any engineering discipline, best methods will be used to produce awful designs and
antiquated methods to produce elegant designs. But this is not good. Progress can be forwarded
with good methods, goods tools, good components, good people, good management and a
learned culture.
16. Understand the customer's priorities
Understanding the customer's priorities is important but only in balance with other
stakeholder priorities. The customer would tolerate even if 90% of the functionality is delivered
late only when at least 10% of it is delivered on time.
17. The more they see the more they need
The more functionality is provided to the user, the more functionality the user wants. The
more the users see, the better they understand. The better they understand the more they need.
But the stakeholders have only limited resources and they cannot reach up to user's expectations.
18. Plan to throw one away
New applications, architectures, interfaces or algorithms rarely work for the first time.
Plan to evolve a product from an immature prototype to a mature baseline rather than planning to
throw one away.
19. Design for change
The architectures, components and specification techniques that are used must
accommodate change. The future must be predicted and the framework should be constructed in
such a way that changes can be accommodated.
20. Design without documentation is not design
Documentation should not be separated from the software itself. With visual modeling
and higher order programming languages, it is very difficult to maintain separate documents for
the purpose of describing the software design. Whenever possible, documentation should be
done simultaneously along with design.
21. Use tools, but realistic
Software tools make their users more efficient. A mature process must be well
established, automated and instrumented. Iterative development projects require extensive
automation.
22. Avoid tricks
Tricks are the constructs that perform a function correctly, but in an obscure way. Many
programmers love to create programs with tricks. But one should show his/her talent by avoiding
tricky code.
23. Encapsulate
Component-based design, object-oriented design and modern design must maintain
information-hiding. Information-hiding is a simple, proven concept which makes software easier
to test and maintain.
24. Use coupling and cohesion
Coupling between modules is the strength of interconnections between modules or a
measure of interdependence modules among modules. Cohesion of a module represents how
tightly bound the internal elements of the module are to one another. The greater the cohesion of
each module in the system, the lower the coupling between modules is. Coupling and cohesion
are the best ways to measure software's inherent maintainability and adaptability but they are
difficult to measure.
25. Use McCabe complexity measure
The cyclomatic complexity measure proposed by Tom McCabe considers each decision
in the program as a single unit. Here, the complexity is measured as an interval rather than a
single value. The lower bound of the interval is he number of decisions plus one or the
cyclomatic complexity of the program. Cyclomatic complexity is one, in which complexity of a
module is the number of independent cycles in the flow graph of the module. The upper bound of
the interval is the number of individual conditions plus one.
26. Don't test your own software
 Software developers should never be the primary testers of their own software. It should
be done by a separate independent test team.
27. Analyze causes for errors
Prevention is better than cure. It is very effective to prevent an error rather than finding it
and correcting it. One way to do this is to analyze the causes of errors as they are detected so that
they can be prevented in the later stages.
28. Realize that software's entropy increases
Any software system that undergoes continuous change will grow in complexity and will
become more and more disorganized. Entropy increases when interfaces are changed.
29. People and time are not interchangeable
It is not good to measure a project solely by person-months. This principle is timeless.
30. Expect excellence
Employees will do much better if high expectations are kept on them.
 PRINCIPLES OF MODERN SOFTWARE ENGINEERING
Or
10 SOFTWARE MANAGEMENT PRINCIPLES
A modern process is an iterative software development process that develops architecture
first, and then evolves useful releases of capability within that architecture until an acceptable
product release is achieved. A modern software management process will incorporate many
conventional principles but will also transition to some substantially new approaches.
1. Architecture-first approach
This is the central design element. The process should be based on an architecture first
approach. Demonstrable balance should be achieved among the requirements, design decisions
and the life-cycle plans before the production and testing are committed for full scale
development.
2. Iterative life-cycle process
This is the risk management element. An iterative life-cycle process should be
established that confronts risk early. The iterative process refines the problem understanding, an
effective solution and an effective plan. Risks can be controlled through ever-increasing
function, performance and quality. Major risks must be addressed early to increase predictability
and for avoiding scrap and rework.
3. Component- based development
This is the technology element. The design methods are to be transitioned to emphasize
component-based development. A component is a cohesive set of preexisting lines of code with a
defined interface. Component-based development can be achieved through object-oriented
methods, rigorous notations and visual modeling.
4. Change management environment
This is the control element. Change management environment should be established.
This can be done by means of metrics, trends and process instrumentation.
5. Round-trip engineering
This is the automation element. Change freedom has to be enhanced through tools that
support round-trip engineering. Round-trip engineering is both forward engineering and reverse
engineering. Round-trip engineering is the environment support necessary to automate and
synchronize engineering information in different formats. Change freedom is a necessity in an
iterative process and in establishing integrated environment.
These are the top 5 principles of a modern process.
6. Model-based notation
Design artifacts are captured in rigorous, model-based notation. A model-based approach
supports the evaluation of semantically rich graphical and textual design notations. Visual
modeling with rigorous notations is to be used.
7. Objective quality control
The process has to be instrumented for objective quality control. Life-cycle assessment of
the progress and the quality of all intermediate products must be integrated into the process.
8. Demonstration-based approach
Demonstration-based approach has to be used to assess intermediate artifacts. Artifact is
a discrete, cohesive collection of information, developed and reviewed as a single unity. The
current state-of-the-product artifacts are transitioned into executable demonstration of relevant
scenarios.
9. Evolving levels of detail
Intermediate releases in groups of usage scenarios with evolving levels of detail should
be planned. Cohesive usage scenarios are the primary mechanism for organizing requirements,
defining iteration content, assessing implementations and organizing acceptance testing.
10. Configurable process
A configurable process should be established which is economically scalable. No single
process is suitable for all software developments. The process must ensure that there is economy
of scale and return on investment.
The top five principles of a modern process
 TRANSITIONING TO AN ITERATIVE PROCESS
Or
PROCESS DISCRIMINANTS
In tailoring the management process to a specific domain or project, there are two
dimensions of discriminating factors: technical complexity and management complexity. A
process framework is not a project-specific process implementation with a well-defined recipe
for success. The process framework must be configured to the specific characteristics of the
project. The process discriminants are organized around six process parameters - scale,
stakeholder cohesion, process flexibility, process maturity, architectural risk and domain
experience.
1. Scale: The scale of the project is the team size which drives the process configuration more
than any other factor. There are many ways to measure scale, including number of sources lines
of code, number of function points, number of use cases and number of dollars. The primary
measure of scale is the size of the team. Five people are an optimal size for an engineering team.
A team consisting of 1 member is said to be trivial, a team of 5 is said to be small, a team of 25 is
said to be moderate, a team of 125 is said to be large, a team of 625 is said to be huge and so on.
As team size grows, a new level of personnel management is introduced at each factor of 5.
Trivial - sized projects require almost no management overhead. Only little
documentation is required. Workflow is single-threaded. Performance is dependent on personnel
skills.
Small projects consisting of 5 people require very little management overhead. Project
milestones are easily planned, informally conducted and changed. There are a small number of
individual workflows. Performance depends primarily on personnel skills. Process maturity is
unimportant.
Moderate-sized projects consisting of 25 people require very moderate management
overhead. Project milestones are formally planned and conducted. There are a small number of
concurrent team workflows, each team consisting of multiple individual workflows. Performance
is highly dependent on the skills of key personnel. Process maturity is valuable.
 Large projects consisting of 125 people require substantial management overhead.
Project milestones are formally planned and conducted. A large number of concurrent team
workflows are necessary, each with multiple individual workflows. Performance is highly
dependent on the skills of the key personnel. Process maturity is necessary.
Huge projects consisting of 625 people require substantial management overhead. Project
milestones are very formally planned and conducted. There are a very large number of
concurrent team workflows, each with multiple individual workflows. Performance is highly
dependent on the skills of the key personnel. Project performance is still dependent on average
people.
2. Stakeholder Cohesion or Contention: The degree of cooperation and coordination
among stakeholders (buyers, developers, users, subcontractors and maintainers) significantly
drives the specifics of how a process is defined. This process parameter ranges from cohesive to
adversarial. Cohesive teams have common goals, complementary skills and close
communications. Adversarial teams have conflicting goals, competing and incomplete skills,
and less-than-open communication.

Modern based formats include the following:

Programming Languages, UML, Visual Modeling.
Round Trip engineering support needed to establish change freedom sufficient for evolving
design representations.

3. Process Flexibility or Rigor: The implementation of the project's process depends on

the degree of rigor, formality and change freedom evolved from projects contract (vision
document, business case and development plan). For very loose contracts such as building a
commercial product within a business unit of a software company, management complexity is
minimal. For a very rigorous contract, it could take many months to authorize a change in a
release schedule.
(Or)
Process flexibility deals with two important concepts one is change management and
another one is configurable process. Change management tells tracking changes to the technical
artifacts inorder to
 1) Maintain control and understand the true technical
2) Progress and quality trends towards delivering
3) Acceptable end product or interim release.
Configurable process is a life cycle frame work suitable for a broad spectrum of applications.

4. Process Maturity: The process maturity level of the development organization is the key
driver of management complexity. Managing a mature process is very simpler than managing an
immature process. Organization with a mature process have a high level of precedent experience
in developing software and a high level of existing process collateral that enables predictable
planning and execution of the process. This sort of collateral includes well-defined methods,
process automation tools, trained personnel, planning metrics, artifact templates and workflow
templates.
(Or)
Objective quality control is important concept of software process maturity. Life cycle
assessment of the process and all intermediate products using well defined measures derived
directly from the evolving engineering artifacts and integrated into all activities and teams.

5. Architectural Risk: The degree of technical feasibility is an important dimension of

defining a specific projects process. There are many sources of architecture risk. They are (1)
system performance which includes resource utilization, response time, throughout and accuracy,
(2) robustness to change which includes addition of new features & incorporation of new
technology and (3) system reliability which includes predictable behavior and fault tolerance.
(Or)
Architecture first is an approach that requires a balance of driving requirements, significant
design decisions, and life cycle plans before resources for full scale development or committed.
Component based development approach is emphasizing on the use of existing components over
the development of custom components. Demonstration based assessment is also important.

6. Domain Experience: The development organization's domain experience governs its

ability to converge on an acceptable architecture in a minimum no of iterations.
 SPM Questions
1. Discuss clearly how to improve software process and Team effectiveness
2. What is meant by software quality? Discuss how to achieve required quality?
3. Explain the principles of modern software management.
4. Explain how the modern software process evolved with the use of technology. How
did software industry practiced the conventional software process?
5. Identify different levels of process in improving software process. Also discuss their
attributes.
6. How do you improve overall quality in a software project? Illustrate.
7. Write about peer inspections
8. Explain the procedure for reducing software product size?
9. Explain the principles of conventional software engineering