O
IntroductIon
The software engineering process is concerned with the definition, implementation, measurement, change, and improvement of software processes.
This short article presents software engineering process knowledge along the lines of the software engineering body of knowledge (International Organization for Standardization & International Electrotechnical Commission [ISO/IEC], 2005b). The objective of the software engineering process is to implement new or better processes in current software engineering practice.
background
Software engineering is a young discipline, and many authors maintain that process engineering is crucial to its success, as well as being key to software quality assurance activities. This article presents generally accepted knowledge about the software engineering process. This knowledge has been adapted from industrial engineering, the management sci -ences, and human resources management. We have witnessed
the emergence of software engineering process literature during the past 20 years and watched as some process topics have appeared while others have disappeared. This article presents four key topics (see Figure 1) that represent the fundamental concepts that must be acquired by all software engineers.
process ImplementatIon and
eVolutIon
Process implementation and change concern the initial deployment of processes and ongoing changes designed to improve and develop a supporting infrastructure (software process assets). Software engineering process activities typically follow a life cycle in which some process models are used as a reference, and certain practical considerations must be considered to ensure their success.
The first section of this article introduces concepts relating to the initial deployment of processes and to the improve -ment of current processes. In both cases, existing software engineering practices have to evolve. If the evolution process is extensive, then the possibility of cultural changes within
Figure 1. Key topics in the software engineering process and its improvement
Software Engineering Process Process Implementation/ Evolution Process
Definition AssessmentProcess MeasurementProcess
An Overview of Software Engineering Process
and Its Improvement
Alain April
École de Technologie Supérieure, Montréal, Canada
Claude Laporte
École de Technologie Supérieure, Montréal, Canada
the organization may need to be addressed to lower the risk of resistance and failure.
Software process improvement typically follows an improvement life cycle composed of four activities: (a) Establish the process infrastructure and assets, (b) plan the implementation (or improvement), (c) implement and evolve the process, and (d) evaluate the process. Improve -ment is often a project in and of itself, requiring appropriate planning, resources, monitoring, and review. Completing these life cycle activities permits continuous feedback and improvement of the software process. The first activity, establishing the process infrastructure and assets, involves establishing commitment to the process implementation and change, and acquiring the appropriate resources and personnel. The objective of the second activity, planning the implementation (or improvement), is to describe and communicate the improvement project’s objectives and process needs following an assessment of the strengths and weaknesses of the current processes. The third activity, implementing and evolving the process, involves executing the planning step and deploying new processes or evolving existing processes, or both. This activity will often require piloting the new or enhanced processes. The last activity, evaluating the process, is concerned with measuring the resulting process and assessing how well it has achieved the initial objectives. This information is then used as input for subsequent improvement cycles.
The need for an appropriate software engineering infra-structure should always be considered in process improve -ment. This includes having the resources as well as a clear assignment of process ownership. Management commitment is essential to the success of the process improvement ef -fort. Having an individual or an isolated group develop and evolve the software engineering processes in isolation, sometimes using proven practice handbooks, may not be the best approach as it often creates the impression that the process has been imposed by an individual or a specific organization (like quality assurance). It would be better to establish mixed-group committees that are involved in the software engineering process definition and evolution as this will ensure better representation and involvement of all software engineering staff. Two examples of such commit -tees are the Software Engineering Process Group (Fowler & Rifkin, 1990) and the Experience Factory (Basili, Caldiera, McGarry, Pajerski, Page, & Waligora, 1992).
Moitra (1998) presents guidelines for process imple -mentation and evolution within software engineering orga -nizations. Hutton (1994) debates the importance of change agents in the case of major process evolution. Organizational change can also be viewed from the perspective of technology transfer (Rogers, 1983). Krasner (1999) presents examples of software definition and evolution initiatives.
process defInItIon
The defining of processes can be represented in models, as well as in the automated process infrastructure. In an organization, a process is often composed as a procedure, a policy, or a standard, and software engineering processes are defined to harmonize software engineering activities and communication, as well as to support process improvement and its automation. In the software engineering body of knowledge, a process is defined in terms of four perspectives: life-cycle models, software life-cycle processes, notations, and automation.
Life-cycle models serve as high-level definitions of the phases that occur during development, maintenance, and operations. They are not aimed at providing detailed definitions, but rather at highlighting the key activities and their interdependencies. Examples of life-cycle models in practice are the waterfall model, the prototyping model, the evolutionary model, incremental or iterative development, the spiral model, and the reusable software model, among others (Comer, 1997).
Definitions of life-cycle processes tend to be more detailed than framework models, and unlike the standards associated with the latter, life-cycle process standards do not attempt to order their processes in time. Therefore, in principle, life-cycle processes can be arranged to fit any of the life-cycle models. The main reference in this area is ISO/IEC (1995).
Other important standards providing process definitions include the following.
• Institute of Electrical and Electronics Engineers (IEEE) Standard 1074:developing software life cycle processes (IEEE, 1991)
• ISO/IEC Standard 14764: software maintenance (ISO/IEC, 2006)
• ISO/IEC Standard 19759: software measurement process (ISO/IEC, 2005b)
To meet some certification criteria, like ISO9001 (ISO, 2000), the CMMi (capability maturity model integration; Software Engineering Institute [SEI], 2006), or the Sar -banes-Oxley Act (SOX; Securities and Exchange Com -mission [SEC], 2002), the definition of software processes must be compliant with quality management standards and other reference guides. ISO9001 provides requirements for quality management processes. Specifically, for the soft -ware industry, ISO/IEC 90003 (ISO, 2004) interprets each ISO9001 clause, and ISO/IEC 20000-1 (ISO/IEC, 2005a) has recently been released to address the IT service quality management system.
Processes can be defined at different levels of abstrac -tion (Pfleeger, 2001). Various elements of a process can be
O
defined, for example, as roles and responsibilities, activities,controls, artifacts, and resources. Madhavji et al. made a pro -posal in 1994 that sets out the types of information required to define software engineering processes. In addition to the type of information, processes are always presented using a particular representation.
A number of representations are used to define processes (Software Productivity Consortium [SPC], 1992) and, more recently, the software domain ontology (Kitchenham et al., 1999). They vary as to the type of process structure and the components, symbols, and information they define, capture, and use. While these notations are gradually being normal -ized (Object Management Group [OMG], 2006), current approaches a software engineer should be aware of are data flow diagrams (Yourdon & DeMarco), state charts (Harel & Politi, 1998), and ETVX (Radice, Roth, O’Hara, & Ciarfella, 1985), and for representing business processes, DFD (Gane & Sarson, 1979), office support system analysis and design (OSSAD; Commission des Communautées Européennes, 1992), and more recently, BPMN (OMG).
Process automation supports human activities by means of a set of services describing the environment’s capabilities. The software engineering environment (SEE) is defined as “a set of tools providing full or partial automated support to software engineering activities.” Software process automa -tion is a new technology with significant promise (Christie, Levine, Morris, & Zubrow, 1996)
Automated tools either support the execution of the process definitions, or they provide guidance to humans per -forming the defined processes. There exist tools that support each notation, and these tools can execute the process defini -tions to provide automated support to the actual processes or to fully automate them in some instances. An overview of process modeling tools is presented by Finkelstein, Kramer, and Nuseibeh (1994), and one of process-centered environ -ments is given by Garg (Garg & Jazayeri, 1996).
process assessment
ISO/IEC 15504 (ISO/IEC, 2004) defines an exemplar as -sessment model and conformance requirements on other assessment models. Popular process assessment models available are the following.
• SW-CMMi for software development processes (SEI, 2006)
• S3M for small software maintenance processes (April & Bran, 2008)
• Information Technology Infrastructure Library (ITIL, 2007) and CMMi (SEI, 2007) for IT services (data center processes)
Many more capability maturity models have been devel -oped over the years. Process assessment using a capability maturity model is often referred to as process maturity assessment. In order to perform a maturity assessment, a specific assessment method needs to be followed to produce a quantitative score that characterizes the capability of the process (also referred to as the maturity of the organization). For example, SCAMPI (standard CMMi appraisal method for process improvement; SEI, 2000) focuses on assessments for the purpose of process improvement using the CMMi. The activities performed during an assessment, the distribution of effort on these activities, and the atmosphere during an assessment are different if the purpose is improvement and not a contract award.
ISO9001 is another process model that has been applied by software organizations. ISO9001 conformity is assessment using an audit process rather than an assessment method per se. There are five key differences between the maturity assessment and the ISO9001 audit.
a. Level of involvement: The organization’s level of involvement is greater with the maturity assessment. b. Review method: Maturity assessment reviews are per
-formed in small groups, which facilitates and stimulates communication. These reviews do not focus as much on quality documentation.
c. Results reporting: Maturity assessment results are presented in their initial and final form in a presenta -tion to all employees of the organiza-tional group that was evaluated. The ISO9001 audit report is presented to the management representative only.
d. Assessment: Maturity assessment requires a chief evaluator and an assessment team (five to nine people), whereas the ISO9001 audit requires one auditor. e. Certification of the evaluators: Who evaluates the
evaluators to ensure the quality of their evaluations? ISO/IEC prescribes four evaluator insurance levels: (a) ISO9001 auditor courses, (b) evaluation of audi -tor performance by the registrar, (c) evaluation of the registrars through accreditation, and (d) evaluation of the accreditation by the International Accreditation Forum. Maturity assessment, by contrast, has only three levels: (a) courses, (b) certification, and (c) reg -istration of the chief evaluators once they have been supervised for a few evaluations.
process measurement
Software engineering process measurement can be performed to support the initiation of process implementation and change, or to evaluate the consequences of process imple
mentation and change. Key terms on software measures and measurement methods have been defined in ISO/IEC 15939 (ISO/IEC, 2007).
Process measurement, as used here, means that quantita -tive information about the process is collected, analyzed, and interpreted. It can be used for process conformance assess -ment, process improve-ment, evaluation of suppliers’ process capability, and benchmarking with other organizations. Mea -surement is used to identify the strengths and weaknesses of processes, to assess conformance, and to evaluate processes after they have been implemented and/or changed. The steps for deploying a software engineering measurement program are described in ISO/IEC 15939 (ISO/IEC, 2007). Software engineering process measures can be aimed at many differ -ent outcomes: quality, progress, productivity, and reliability. Therefore, measurement programs tend to measure multiple process outcomes that are important to the organization’s business and to customer satisfaction.
Software process quality measures focus on error re -moval and its effectiveness. Progress measures report on the completion of milestones. Productivity measures represent the amount of work performed (in lines of code or function points) per person-month. A comparison of productivity can be achieved in a benchmarking exercise (International Soft -ware Benchmarking Standards Group [ISBSG], 2003).
In general, we are most concerned about process out -comes. However, in order to achieve the process outcomes that we desire (e.g., better quality, better maintainability, greater customer satisfaction), we have to measure the particular process.
Of course, it is not only the process that has an impact on outcomes. Other factors, such as the capability of the staff and the tools used, play an important role. Further -more, the extent to which the process is institutionalized or implemented (i.e., process fidelity) is also important as it may explain why good processes do not necessarily lead to the desired outcomes.
future trends
We have presented here an overview of current knowledge on software engineering process. Future trends are developing in five main directions: first, the ongoing debate regarding the use of lightweight and open-source life cycles (Agile, Open UP); second, the need for greater conformity of IT to rules and regulations (SOX, CobiT); third, the challenge of applying quality paradigms to software engineering processes (i.e., Six Sygma); fourth, the introduction of new international standards that will recommend the process support services for SEEs; and finally, we predict that there will be a consolida -tion of reference models for IT processes in the near future, and that simplicity and ease of use will prevail.
conclusIon
This short article has presented the software engineering process body of knowledge (ISO/IEC, 2005b).
references
April, A., & Abran, A. (2008). Software maintenance manage -ment: Evaluation and continuous improvement. In Software engineering best practice (Vol. 1). John Wiley & Sons. Basili, V., Caldiera, G., McGarry, F., Pajerski, R., Page, G., & Waligora, S. (1992). The software engineering laboratory: An operational software experience factory. In Proceedings of the International Conference on Software Engineering
(pp. 370-381).
Christie, A. M., Levine, L., Morris, E. J., & Zubrow, D. (1996). Software process automation: Experience from the trenches (Tech. Rep. No. CMU/SEI-96-TR-013). Carnegie Mellon University.
Comer, E. (1997). Alternative software life cycle models. In M. Dorfmann & R. Thayer (Eds.), Software engineering.
IEEE CS Press.
Commission des Communautées Européennes. (1992).
Of-fice support system analysis and design (OSSAD):Project
Esprit #285. Retrieved from http://dumas.univ-tln.fr/Ossad/ Appel%20vol%201.htm
Finkelstein, A., Kramer, J., & Nuseibeh, B. (1994). Soft-ware process modeling and technology. Research Studies Press Ltd.
Fowler, P., & Rifkin, S. (1990). Software engineering process group guide (Tech. Rep. No. CMU/SEI-90-TR-24). Software Engineering Institute. Retrieved from http://www.sei.cmu. edu/pub/documents/90.reports/pdf/tr24.90.pdf
Gane, C. P, & Sarson, T. (1979). Structured system analysis: Tools and techniques. Prentice Hall.
Garg, P., & Jazayeri, M. (1996). Process-centered software engineering environments: A grand tour. In A. Fuggetta & A. Wolf (Eds.), Software process. John Wiley & Sons. Harel, D., & Politi, M. (1998). Modeling reactive systems with statecharts: The statemate approach. McGraw-Hill. Hutton, D. (1994). The change agent’s handbook: A survival
guide for quality improvement champions. ASQC Quality Press.
Information Technology Infrastructure Library (ITIL). (2007). Central Computer and Telecommunications Agency
O
Majesty’s Stationery Office. Retrieved from http://www.itsmf.org/
Institute of Electrical and Electronics Engineers (IEEE). (1991). IEEE standard for developing software life cycle pro-cesses (IEEE Std 1074-1991). IEEE Computer Society. International Organization for Standardization (ISO). (2000).
ISO9001:2000, quality management systems: Requirements
(3rd ed.). Author.
International Organization for Standardization (ISO). (2004).
Software engineering: guidelines for the application of ISO9001:2000 to computer software. ISO/IEC Standard 90003:2004. International Organization for Standardization & International Electrotechnical Commission.
International Organization for Standardization & Interna -tional Electrotechnical Commission (ISO/IEC). (1995).
ISO/IEC 12207: Information technology. Software life cycle processes. Author.
International Organization for Standardization & Interna -tional Electrotechnical Commission (ISO/IEC). (2004).
ISO/IEC 15504-1: Information technology. Process assess-ment: Part 1. Concepts and vocabulary: ISO/IEC Standard 15504-1. Author.
International Organization for Standardization & Interna -tional Electrotechnical Commission (ISO/IEC). (2005a).
ISO/IEC 20000-1: 2005 information technology. Service
management: Part 1. Specification. Author.
International Organization for Standardization & Interna -tional Electrotechnical Commission (ISO/IEC). (2005b).
ISO/IEC TR 19759: 2005 information technology. Software measurement process. Author.
International Organization for Standardization & Interna -tional Electrotechnical Commission (ISO/IEC). (2006). ISO/ IEC 14764: Software engineering. Software maintenance: ISO/IEC Standard 14764. Author.
International Organization for Standardization & Internation -al Electrotechnic-al Commission (ISO/IEC). (2007). ISO/IEC 15939: 2007 software engineering. Guide to the software
engineering body of knowledge (SWEBOK). Author.
International Software Benchmarking Standards Group (ISBSG). (2003). Retrieved from http://www.isbsg.org Kitchenham, B., Guilherme, H., et al. (1999). Towards an ontology of software maintenance. Journal of Software Maintenance: Research and Practice, 11, 365-389. Krasner, H. (1999). The payoff for software process improve -ment: What it is and how to get it. In K. El-Emam & N. H. Madhavji (Eds.), Elements of software process assessment and improvement. IEEE CS Press.
Madhavji, N., et al. (1994). Elicit: A method for eliciting
process models. Paper presented at the Third International Conference on the Software Process.
Moitra, D. (1998). Managing change for software process improvement initiatives: A practical experience-based ap -proach. Software Process: Improvement and Practice, 4(4), 199-207.
Object Management Group (OMG). (2006). Business
process management initiative Version 1.0. Retrieved from http://www.bpmn.org
Pfleeger, S. L. (2001). Software engineering: Theory and practice (2nd ed.). Prentice Hall.
Radice, R., Roth, N., O’Hara, A. Jr., & Ciarfella, W. (1985). A programming process architecture. IBM Systems Journal,
24(2), 79-90.
Raghavan, S., & Chand, D. (1989). Diffusing software-en -gineering methods. IEEE Software, pp. 81-90.
Rogers, E. (1983). Diffusion of innovations. Free Press. Securities and Exchange Commission (SEC). (2002). SOX:
Sarbanes-Oxley Act (Pub. L. No. 107-204, 116 Stat. 745).
Retrieved from http://www.sec.gov/rules/interp/2007/33-8810.pdf
Software Engineering Institute (SEI). (2000). Standard
CMMi appraisal method for process improvement (SCAMPI):
Method description. Version 1.0 (Tech. Rep. No. CMU/ SEI-2000-TR-009). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University.
Software Engineering Institute (SEI). (2006). CMMI product development team: Capability maturity model integration for software engineering. Version 1.2 (Tech. Rep. No. CMU/ SEI-2006-TR-008). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University.
Software Engineering Institute (SEI). (2007). CMMi for services. Retrieved from http://www.sei.cmu.edu/cmmi/ models/CMMI-Services-status.html
Software Productivity Consortium(SPC). (1992). Process
definition and modeling guidebook (SPC-92041-CMC).
Author.
key terms
Audit: It is an independent examination of a work product or set of work products to assess compliance with specifica -tions, standards, contractual agreements, or other criteria.
Capability Maturity Model: The model is a descrip
-tion of the stages through which organiza-tions evolve as they define, implement, measure, control, and improve their processes.
Maturity Level: It is a well-defined evolutionary plateau toward achieving a mature software acquisition process. The typical five maturity levels are initial, repeatable, defined, quantitative, and optimizing.
Measurement Process: This is a set of interrelated resources, activities, and influences related to a measure -ment.
Measurement Program: A measurement program is
the set of related elements for addressing an organization’s measurement needs. It includes the definition of organiza
-tion-wide measurements, methods, and practices for col -lecting organizational measurements and analyzing data, and measurement goals for the organization.
Process Assessment: It isa disciplined evaluation of an organization’s software processes against a model compatible with the reference model.
Process Assets: They are a collection of items, maintained by an organization, for use by programs in developing, tailor -ing, maintain-ing, and implementing their processes.
Software Process Assets: They area collection of enti -ties, maintained by an organization, for use by projects in developing, tailoring, maintaining, and implementing their software processes.
