Background:

For many organizations like ours, the interim target of achieving ISO 9001 or CMM levels
is a daunting task. Discipline is no fun Organizations readily acknowledge that striving
to address projects according to ISO 9001 or CMM guidelines requires the creation of new
procedures. It is vital to the success of improvement efforts to realize that process
change entails cultural change and its human nature to resist change. Numerous social
and technical barriers must be overcome to effect lasting improvement.

My organization aimed for ISO 9001 certification and then CMM level 2 and Level 3
assessment approximately one and half year back and knew that it would be grilled
thoroughly by the ISO auditors and CMM assessors. For Software Process Improvement first
we need to know your strengths and weaknesses so that the management can scope the
improvement effort. Only with this knowledge can we customize an infrastructure for
process improvement. We have had success with plans tailored according to the Software
Engineering Institute s CMM model. This includes formation of Software Process
Engineering Group, who know their roles, responsibilities, charters, and action plans,
which helps you develop a charter and vision and to establish a clear match to
organizational goals and objectives. They will be much more effective if they receive
the right formal and informal training. One pivotal decision was “not to reinvent the
wheel”, but seriously consider Industry Best Practices.

Later we saw that, Process improvement always pays dividends for those with the
discipline to do it right.

Process Improvement Project

The Strategic Plan

A clear vision is essential to the success of process improvement project. Senior
management in our case had the vision that Process is Product and was committed to
sponsor and support improvement efforts. We were responsible for mobilizing people and
resources to try and make it happen, but process improvement was a new endeavor for my
group and everyone was unsure how to get started and get organized My organization went
for strategic planning using Total Quality Management’s Plan-Do-Check-Act cycle.

We developed a vision to use the best practices of software development teams and the
eleven best practices were identified:

* Develop iteratively (incremental development life cycle) * Use component-based
architecture * Visually model the product using the Unified Modeling Language (UML) *
Formal Risk Management * Agreement on Interfaces * Formal Inspections * Metric-based
Scheduling and Management * Program-wide Visibility of Progress Vs Plan * Defect
Tracking Against Quality Targets * Configuration Management * People-aware Management
Accountability

In the planning model we tried to analyze the current projects keeping the insight of
ISO/CMM through rigorous reviews. Next, we conducted organizational Gap Analysis between
its current state and the vision we were seeking. The ISO 9001 status feedback itself
became the catalyst for develop tactical plans by providing the team leaders with the
required control mechanism for project tracking and oversight.

Our organization tried to Treat Software Process Improvement also like a development
project! Senior management sponsored to recruit a corresponding project team (Software
Quality Assurance team or the Software Process Engineering Group), selected a project
leader, and established a repository to store process documentation and other process
artifacts. We followed the plan as: Start by discovering and understanding current
practice throughout the group. Find existing process documentation and talk to
practitioners to understand how tasks are performed. Reconcile any differences between
actual and espoused processes. Document and review the newly characterized process. Then
iteratively and incrementally improve the process and ensure that the documentation is
updated appropriately. Project Planning, Software Configuration Management, and Software
Quality Assurance, project tracking, Software Tools usage were the key areas where our
organization concentrated more for process improvement. We tried to customize Rational
Unified Process for our working environment and automated tools in process was also
taken up.

We also ensured that the visibility of the project to upper management and the rest of
the organization were comparable to that of other important projects.

Culture and Resistance

Process improvement affects more than just the processes used by practitioners to
perform their work. Process change means culture change, replete with all the
difficulties inherent in changing the perceptions, values, and normative behaviors of a
community. Some of the forces that make such improvement efforts difficult are:

Resistance to change (often due to a perceived threat of losing power, control,
familiarity, or social status)

The existing tolerance and readiness for change present within the current
organizational climate

Process change imposes a learning curve, which typically makes things appear to get
worse before they get better.

Improvement efforts consume time and resources, which many would prefer to spend on
their particular development projects.

In my organization we tried to solve the above problem by bringing our improvements from
the Local Heroes itself (Involve Everyone!!). These people should be “all-stars in the
family”: respected members of the organization with proven track records as developers
or managers. Emphasize the importance of having the “local hero” be part of the Software
Process Engineering Group and try to hold out for the “real thing” if you can manage it
(this is another one of those times when senior and middle management support may be
needed). We documented our local technical procedures by choosing the se champions/local
heroes to write that procedure by using SEI-CMM key practices. Software Quality
Assurance team was the center of guidance and support for all the process improvement
activities. The SQA was the primary authoritative body for conducting and organizing
improvement efforts in the organization. The entire practitioner community was regularly
informed of the status of improvement efforts. It is also desirable to solicit input and
feedback on process improvement issues from the practitioner community. We chose one
pilot project so that we could discuss and test how software process improvement really
helps in current scenario.

Benefits of Process Improvement

The clearest textbook definitions of Return on Investment (ROI) is, as described by
Lawrence Putnam “Investing to improve [productivity] involves foregoing the use of those
funds for other purposes. In time the payback from the future stream of gains from
operations returns the capital invested.” The ROI may not always be in dollars, Quality
and schedule issues as a return are nearly as important to the participants as are the
cost issues. Our measurement set spanned the following eight categories of metrics:
effort, process, productivity, progress, quality, schedule, stability, and staffing. We
asked our research participants to indicate which metrics from our set they maintained
and add to our list any additional metrics they used. We also solicited the starting and
ending phase of the software lifecycle over which each metric was maintained. When we
analyzed the participants’ measurement data across maturity levels against the eight
metric categories, each maturity level showed, on average, a consistent growth pattern.
We also tried to relate any immeasurable benefits we experienced from their process
improvement program. The benefit most frequently noted by the research participants
concerned attitudinal changes. The morale and confidence of the developers improved
significantly, and software development experienced increased attention and respect from
organizations external to the software organization. Participants also attributed less
overtime, less employee turnover, improved competitive advantage, and increased
cooperation between functional groups as benefits that resulted from process improvement
initiatives.

Conclusion

Software Process Improvement is crucial as any organization attempts to take on and
deliver larger projects. The lack of well-defined software processes can be very costly.
Support from all staff, especially top management, is a prerequisite for any serious SPI
initiative. As a great philosopher once said, “It won’t happen overnight, but it will
happen”. Many improvement efforts fail or falter during the initial phases of process
improvement. My organization was successful at rapidly reaching ISO 9001/CMM because it
made a point of applying lessons learned by others. But this cannot be the end for
process improvement in any organization, our journey towards process improvement will
always continue.

References

1. Carnegie Mellon University/Software Engineering Institute, The Capability Maturity
Model: Guidelines for Improving the Software Process, Addison-Wesley, Reading, Mass.,
1995.

2. Roger S. Pressman, Software Engineering: A Practitioner’s Approach, 4th ed.,
McGraw-Hill, 1996

3. Watts Humphrey, Managing the Software Process, Addison-Wesley, 1989

Name: Deepty B. Chauhan

Qualifications: Bachelor s in Electronics Engineering, Post Graduate Diploma in
Marketing Management. Total experience of Nine years in area of software quality and
testing.

Corporate responsibilities: Given the responsibility to lead a group in Software Quality
Assurance and Software Verification and Validation. This includes software process
improvement through implementing ISO 9001/CMM in organization, customizing Rational
Unified Process to cater the needs of my organization, bringing quality in the product
through software testing, automating software quality assurance activities.

Email address: deeptychauhan@gmail.com

Article Source: http://EzineArticles.com/?expert=Deepty_Chauhan

Subscribe To Our RSS Feed
You can trackback from your own site.

Leave a Reply

You must be logged in to post a comment.