ACM Logo





Invitation
Ubiquity - The ACM IT Magazine and Forum




Is Your Software Process Staying With You?
By Sunil Tadwalkar


It takes a village to build a process-oriented culture within an organization.



Most software developing organizations today have one mark or other of achieving software quality standards. While doing business development they may boast that they are ISO-certified or CMM Level X companies. Organizations establish frameworks and organization wide processes related to these standards to guide their work forces while on the job.

However, there seems to be a problem in percolation of this message. Often, the message is better understood by project managers, project leaders and quality teams than by software developing teams. Organizations tend to publicize the importance of quality through media such as posters, screen savers, desktop banners, wallpapers and Intranets. Organizations today are still looking for a mechanism to evaluate the quality message and eventually judge the acceptance of quality initiatives by individuals.

When I was working as a quality manager in a strategic business unit, I rarely saw anyone really take charge of the process, by way of planning and executing all the necessary activities. Generally, a quality leader would come and tell how to use the process, then the developing team would take it as an academic activity to read the process, use some formats, and check a list here and there. This happens even in organizations certified for quality standards such as ISO and CMM. This is not being "on board" with the process.

Team members should look at the process as a vehicle to take them safely and successfully through the software development journey. Currently there may not be an organization wide drive for personal software process (PSP) but individuals are required to take ownership of the process. Individuals assigned to a project should

  1. Get aligned with the process, looking at its coherence and suitability to the development activity.
  2. Quickly decide which activities will be governed through the process.
  3. Determine what additional activities need to be planned apart from process requirement.
  4. Determine if it possible to introduce any innovative technique or tool to represent additional requirements of the project.
  5. Make the process work or question its credibility for a given project scope.
  6. Determine if the process addresses your product quality problems.
  7. Keep the project leader/manager and QA person informed of the usefulness or uselessness of the process for the given scope. If necessary, seek an alternate action plan.
Ensuring that a process works for you is more a matter of usability than that of pride. A void in the process is like a bubble, which develops a similar void in the product under development, which might turn out to be a defect tomorrow. When you are a part of a development team and a separate group is doing testing, your attention should be on developing a testable product. Check how your process can deliver a testable product.

At times during your development cycle you must get your alignment of process to your work products verified through a quality assurance representative (QAR). Provide the QAR confidence on how best a process addresses your development needs. If a process doesn't work, demand an alternate way of doing the job. Develop a new artifact in the form of guidelines or standards that address the missing elements of the process.

Role of SQA

It is well understood in process-oriented organizations that software quality assurance (SQA) plans, controls and manages quality aspects of projects. SQA organizes review meetings, audits, collects data and reports to the quality head. But this is not enough. Today SQA responsibility goes beyond the walls of process compliance. SQA should proactively do the following.

  1. Make sure that everybody in the unit understands and follows the process, which will help in understanding the project well.
  2. Make sure that each process is usable in the current project.
  3. Meet with the development team to make sure it understands how processes address much of the project work and what can be done for the rest of it, or how the current process can be modified.
  4. Determine what product attributes should be addressed by current processes
  5. Determine if the project needs introduction of a new standard or tool.
  6. Seek input from team on what new and more stringent norms they can achieve. Find out if the current measurement technique is accurate.
  7. Find out if and what quality assurance activities should be planned based on technology and the complexity of the project.
  8. Use innovative techniques when needed to support the project.
  9. Determine how to maintain the bonding of project activities with processes.
  10. Determine if new team members need to be trained on processes.
  11. Make sure everyone understands recent changes in processes.
Role of SEPG

In the process world software engineering process groups (SEPG) are characterized as holders of the umbrella of organization processes. They are generally found busy with common sense jobs such as collecting and analyzing metrics data, organizing process changes, introducing new tools and practices, looking after suggestions, etc. Neither the development community nor top management is well aware of what SEPG can do for them. It is important for SEPG to develop its credentials in both communities. In today's organization SEPG has critical roles to play.

  1. Sustain and enhance quality culture in different projects of the organization.
  2. Accelerate process acceptance and usability by all elements of projects.
  3. Measure project and take new commitments to achieve better quality norms.
  4. Review redundant, out-dated and unused processes periodically and remove or change the processes.
  5. Access the benefits derived by the project teams in using processes.
  6. Add dynamism and keep freshness of process by making it current.
  7. Meet with team periodically to check effectiveness of project.
  8. Provide status to senior management on returns achieved by the project in using or changing software processes.
Role of Senior Management

Senior management generally shows a keen interest in the initial period until the achievement of quality norms (ISO, CMM) by the organization. Thereafter the role of management should not be limited to overseeing just the operations taking place in quality departments. Management should ensure that all operations of the organization are driven by the process-oriented culture. Some of the aspects that need management attention are listed below.

  1. A long-term plan of maintaining quality norms.
  2. Periodic review of the quality aspects of project and setting of stringent standards for achieving quality of product, process and its services.
  3. Setting new business objectives to provide new challenges for defining and improving software processes.
  4. Reviewing with SEPG status of achieving goals and problems encountered.
  5. Providing business concerns to address new areas of processes.
  6. Ensuring that all business risk is well addressed by organization processes.
  7. Encouraging and introducing new quality standards that make business sense.
  8. Reviewing major customer complaints, customer satisfaction reports and lost customer reports with quality group to understand organizational weaknesses and providing necessary directions.
Organizations that have achieved quality standards and developed frameworks for their projects to perform should remain alert in order to keep their organizational processes dynamic and workable to expect better returns on their quality spending. The processes should be further innovated to address forthcoming business needs and concerns. Organizations need to maintain a culture to ensure that process becomes part of everybody's way of working in the organization.


Forum



Sunil Tadwalkar is a senior consultant with Satyam Computer Services Ltd, Andhra Pradesh, India


[Home]   [About Ubiquity]   [The Editors]  

Ubiquity welcomes the submissions of articles from everyone interested in the future of information technology. Everything published in Ubiquity is copyrighted ©2001 by the ACM and the individual authors.