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