Introduction to Software Process Improvement
by Janette Toral
Companies are now becoming more and more dependent with the use of computers in business, for business, and even as a business. At the heart of it is software developed or purchased for organization use.
With its increasing significance, companies began putting up their own management information system (MIS) or electronic data processing (EDP) departments whose role is to develop productivity applications, tools and maintain these systems.
People were hired in these departments based on their aptitude, attitude, and technical know-how. Development and technology tools were purchased based on its features and benefits to its users.
However, in most organizations today, the working structure and development methodology are informal. The working parameters of the team were solely based on the software development life cycle phases and the major deliverables. Most of the time, these are not clearly defined.
As a result, excellent output becomes dependent on the quality of the people hired, their level of experience, and commitment to the organization.
Risk-wise, if these people leave the organization, more often than not, the whole project collapses as no one is capable of continuing the job due to lack of process, procedures, training, and documentation.
Quality software is not strictly dependent on people and technology. Process plays a great role as these are practices established in the organization, to be performed, and achieve a given purpose.
As the software development department gain good and bad experience, processes or methodology evolves as well, formally or not. This change is referred to as software process improvement (SPI).
SPI usually takes place with the intent of not only making things better but help in achieving basic business goals or objectives today. Rather than being people or technology focused, organizations are encouraged to be process-focused in its software development methodology.
Being people-focused is not the answer for high quality output. People can only be as good as they are trained to be. Working harder through longer hours or days does not speak much on the quality of output. It becomes a reflection instead of poor schedule estimation in the process.
Purchasing expensive software is not the key as well. I've met organizations who bought case tools and the like that were not fully utilized, for the working environment bends all rules just to deliver products on its committed delivery date.
Defined software processes are important to minimize problems in people, systems, software or applications development, and maintenance. With process improvement, good practices get to be institutionalized in the organization and continuously improve.
SPI can only work if the following will be taken into consideration:
1. Make time.
Successful SPI efforts require stakeholders to adjust their schedules to devote time for improvement activities.
2. Gain knowledge.
There are a lot of books and seminars that tells you how to improve and do it right. It is better to look into proven process models for these are compilations of best practices. A process model can be used to help set improvement objectives and priorities. With proper and knowledgeable adoption, it can lead to well-directed efforts. People who have been participating in DigitalFilipino.com SPI workshops learn most from the lessons learned and best practices from fellow participants. Some even benchmark their current practices and evaluate whether it is being done right.
3. SPI for sustainable quality output and culture.
Don't undertake SPI for marketing or certification purpose alone. It will not last. Consider it like a marriage. You choose a partner because you want to stay, improve, and grow. Having a different criteria otherwise, like money or sex, can only last for so long.
4. Long-term commitment.
Executives and managers must be educated about the cost, benefit, and risk of software development and the role of SPI to help achieve business goals.
CMMI as a process model
The Software Engineering Institute (SEI) Capability Maturity Model® for Software (SW-CMM) describes a framework that organizations can use to determine their ability to develop and maintain software. It is a model for organizational improvement.
The SW-CMM is based on the process management work of W. Edwards Deming, Joseph M. Juran, and Phillip B. Crosby, and can be applied by organizations to improve their software process through a software process assessment. The SW-CMM is also applied to software vendors via contractor evaluation.
Certification or formal assessment is normally done in the presence of someone from Carnegie Mellon University - Software Engineering Institute who would play the Lead Assessor role. This person will form an evaluation or assessment team from selected experienced individuals from the organization who will be trained in the process model and in conducting the assessment.
As CMM sunset last December 2003, SEI earlier released the Capability Maturity Model Integrated® (CMMI) that builds on and extends the best practices of the SW-CMM and other models. Organizations now, instead of undergoing numerous training, implementation, and assessment on various models, can just look into one with CMMI.
The CMMI is a prescriptive process model as it describes what should be done during software development. This includes dealing problems when encountered and emphasizes the need to prepare for changing situations. It illustrates the tasks and documents that need to be produced and reviewed. It also requires the need for stakeholders to be involved and responsible in the process.
The CMMI is also used as a benchmark by large organizations in evaluating the competitiveness of suppliers. It serves as a guide for software process improvement initiatives by various industries that see their IT (information technology) systems as a critical component for the achievement of business goals.
High quality software processes are deemed critical especially to organizations that build systems that are meant to save lives. This can include:
- Software used in medical equipments to accurately predict a potential disease or even cure it.
- Weapon systems meant to defend one country.
- Software used to operate space shuttles or satellites. (It is hard imagining them to reboot their systems or having a software error in outer space)
There are more critical applications or use of software today that will be too long to detail here. My point of stating this is not to exaggerate but to highlight the importance of quality software processes. Thinking that having software errors is ok as they can be fixed is not appropriate for these applications. Having such thinking speaks so much on how we regard or view the importance of quality in our software development work.
The CMMI model has two representations:
1. Continuous - looks into a set of process areas relating to a single process area or practice. This representation provides flexibility for focusing on specific process areas that are important to one's organization.
In this representation, the process areas are spread in 4 categories or process groups. They are:
a. Project management composed of the following process areas:
- Project planning
- Project monitoring and control
- Supplier agreement management
- Integrated project management
- Integrated supplier management
- Integrated teaming
- Risk management
- Quantitative project management
b. Support with the following process areas:
- Configuration management
- Process and product quality assurance
- Measurement and analysis
- Causal analysis and resolution
- Decision analysis and resolution
- Organizational environment for integration
c. Engineering with the following process areas:
- Requirements management
- Requirements development
- Technical solution
- Product integration
- Verification
- Validation
d. Process management with the following process areas:
- Organizational process focus
- Organization process definition
- Organizational training
- Organizational process performance
- Organizational innovation and deployment
2. Staged - this representation looks into an established set of process areas across an organization. It also provides a guide for sequenced implementation. The process areas are spread into five maturity levels where each is a layer for continuous process improvement.
a. Level 1.
There are no CMMI stated process areas in this level. This is where most software development organizations are today.
Although there are informal and flexible processes performed in this level, it is likely to have less predictability, more rework, more defects, and more schedule slippage than those in a higher maturity. Usually, the organization's software development success is attributed to its people and so are its failures due to lack of established processes.
b. Level 2. Despite an organization having established software engineering procedures, without a well-followed project management processes, these procedures can be bend if project management dictates it.
This level addresses practices that contribute to the creation of a disciplined project management culture in the organization. It includes:
- Requirements management
- Project planning
- Project monitoring and control
- Supplier agreement management
- Configuration management
- Process and product quality assurance
- Measurement and analysis
c. Level 3. This level covers software engineering and contribute to the standardization of processes. It includes process areas such as:
- Requirements development
- Technical solution
- Product integration
- Verification
- Validation
- Organizational process focus
- Organizational process definition
- Organizational training
- Integrated project management
- Integrated supplier management
- Risk management
- Decision analysis and resolution
- Organizational environment for integration
- Integrated teaming
d. Level 4. This is where processes are measured and controlled. The establishment of process areas in Level 2 and 3 paves the way for this to take place. Process areas included are:
- Organizational process performance
- Quantitative project management
e. Level 5. The organization's software process improvement becomes part of its daily life as ways to innovate processes for the better becomes part of its culture. Its process areas are:
- Organizational innovation and deployment
- Causal analysis and resolution
For an organization to be considered having a CMMI Level 3 maturity, all process areas in levels 2 and 3 are being practiced in an organization. If an organization misses one process area, without proper justification, can result to non-consideration for an organization to be at such a level during the time of assessment.
Benefits of SPI
Organizations who have implemented SPI agree on the following benefits derived:
1. Predictability. With experience and measurements, organizations have improved their estimation of schedule and budget through time.
2. Quality. Program defects decrease as productivity increase.
3. Customer confidence. The establishment of processes gave customers security in terms of having its projects managed professionally and not being dependent on heroes as its applications scale. Note though that your first deployment of processes can result to resistance from customers as your flexibility in accommodating concerns will now have processes to be followed. With proper customer orientation, this can be managed accordingly.
4. Better employee morale. Employees gain higher morale in the process as they are much guided in their work through policies, training programs, and well-documented plans. Being part of an organization that practices SPI gives credibility and prestige to its people as well.
SPI takes time: the road ahead
Our effort to educate the community on SPI and CMMI on a bigger scale starts here. Definitely, this online workshop will not replace the value of face-to-face training. It can give you enough insight to get started and see whether SPI is worth pursuing in your organization.
We will look into the various process areas beginning the next lesson and your feedback will help us greatly in improving our content. Please download the CMMI-SE/SW guide or we popularly refer to as the CMMI bible at http://www.sei.cmu.edu/pub/documents/02.reports/pdf/02tr012.pdf.
Note that the presentation of the content of this book will be guided by the specific goals (SG) and practices (SP) of CMMI.
These goals and practices are used as a basis when evaluating adherence of organizations to the model.
From the next lesson on, the following CMMI generic goals (GG) and practices (GP) are expected to be performed in all process areas.
CMMI Practice-to-Goal Relationship Table
GG 2 Institutionalize a Managed Process
GP 2.1 Establish an Organizational Policy
GP 2.2 Plan the Process
GP 2.3 Provide Resources
GP 2.4 Assign Responsibility
GP 2.5 Train People
GP 2.6 Manage Configurations
GP 2.7 Identify and Involve Relevant Stakeholders
GP 2.8 Monitor and Control the Process
GP 2.9 Objectively Evaluate Adherence
GP 2.10 Review Status with Higher Level Management
1. An organizational policy will be established for all process in order for it to be carried out with proper guidance.
2. All processes will be planned for proper execution.
3. Resources will be provided for performing the planned process and delivering its output.
4. Personnel, with proper responsibility and authority, will be assigned to perform the planned process.
5. People performing the planned process should be adequately trained to do the task.
6. Place all planned process work-related products and documentation under configuration management control and monitoring.
7. For every planned process, stakeholders need to be identified and get involve.
8. All planned processes should be monitored and controlled for compliance against the plan and take corrective action when needed.
9. All planned processes should be objectively evaluated for adherence to process, standards, and resolve non-compliance.
10. Regularly review with higher-level management the status, activities, and results of planned processes areas and resolve issues, if any.
In CMMI assessments, you’ll be asked whether all the specific and generic practices in were practiced in your organization. In the classes that we conduct, some students from known mature organizations are often unaware of the policies in their organization. This is also true for companies who have processes that no one follows. It means that they are not communicated, monitored, and enforced.
Forum discussion (if you are not yet a member of PH-SPIN, join now for free)
1. Please explain your organization's current software development life cycle (SDLC). What policies, project plans, forms or templates in relation to your SDLC are in place at this time?
2. What are the challenges that you are encountering with your organization's SDLC? How are you overcoming those challenges?
