An Overview of Software Engineering Process and Its Improvement

Transcription

1 An Overview of Software Engineering and Its Improvement O Alain April École de Technologie Supérieure, Montréal, Canada Claude Laporte École de Technologie Supérieure, Montréal, Canada 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 sciences, 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 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 improvement 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 Implementation/ Evolution Definition Assessment Measurement Copyright 2009, IGI Global, distributing in print or electronic forms without written permission of IGI Global is prohibited.

2 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. Improvement 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 infrastructure should always be considered in process improvement. 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 effort. 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 committees are the Software Engineering Group (Fowler & Rifkin, 1990) and the Experience Factory (Basili, Caldiera, McGarry, Pajerski, Page, & Waligora, 1992). Moitra (1998) presents guidelines for process implementation and evolution within software engineering organizations. 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 Sarbanes-Oxley Act (SOX; Securities and Exchange Commission [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 software industry, ISO/IEC (ISO, 2004) interprets each ISO9001 clause, and ISO/IEC (ISO/IEC, 2005a) has recently been released to address the IT service quality management system. es can be defined at different levels of abstraction (Pfleeger, 2001). Various elements of a process can be

3 defined, for example, as roles and responsibilities, activities, controls, artifacts, and resources. Madhavji et al. made a proposal 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 normalized (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). 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 automation 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 performing the defined processes. There exist tools that support each notation, and these tools can execute the process definitions 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 environments is given by Garg (Garg & Jazayeri, 1996). process ASSESSMENT ISO/IEC (ISO/IEC, 2004) defines an exemplar assessment 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 developed over the years. 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 performed 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 presentation to all employees of the organizational 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 auditor 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) registration 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- O

4 mentation and change. Key terms on software measures and measurement methods have been defined in ISO/IEC (ISO/IEC, 2007). measurement, as used here, means that quantitative information about the process is collected, analyzed, and interpreted. It can be used for process conformance assessment, process improvement, evaluation of suppliers process capability, and benchmarking with other organizations. Measurement 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 (ISO/IEC, 2007). Software engineering process measures can be aimed at many different 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 removal 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 Software Benchmarking Standards Group [ISBSG], 2003). In general, we are most concerned about process outcomes. 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. Furthermore, 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 consolidation 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 management: 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 ). 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). Office support system analysis and design (OSSAD): Project Esprit #285. Retrieved from Appel%20vol%201.htm Finkelstein, A., Kramer, J., & Nuseibeh, B. (1994). Software 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 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). -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 (Version 3). Norwich, United Kingdom: Controller of Her

5 Majesty s Stationery Office. Retrieved from itsmf.org/ Institute of Electrical and Electronics Engineers (IEEE). (1991). IEEE standard for developing software life cycle processes (IEEE Std ). IEEE Computer Society. International Organization for Standardization (ISO). (2000). ISO9001:2000, quality management systems: Requirements (3 rd 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. Electrotechnical Commission (ISO/IEC). (1995). ISO/IEC 12207: Information technology. Software life cycle processes. Author. Electrotechnical Commission (ISO/IEC). (2004). ISO/IEC : Information technology. assessment: Part 1. Concepts and vocabulary: ISO/IEC Standard Author. Electrotechnical Commission (ISO/IEC). (2005a). ISO/IEC : 2005 information technology. Service management: Part 1. Specification. Author. Electrotechnical Commission (ISO/IEC). (2005b). ISO/IEC TR 19759: 2005 information technology. Software measurement process. Author. Electrotechnical Commission (ISO/IEC). (2006). ISO/ IEC 14764: Software engineering. Software maintenance: ISO/IEC Standard Author. Electrotechnical 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 Kitchenham, B., Guilherme, H., et al. (1999). Towards an ontology of software maintenance. Journal of Software Maintenance: Research and Practice, 11, Krasner, H. (1999). The payoff for software process improvement: 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. Moitra, D. (1998). Managing change for software process improvement initiatives: A practical experience-based approach. Software : Improvement and Practice, 4(4), Object Management Group (OMG). (2006). Business process management initiative Version 1.0. Retrieved from Pfleeger, S. L. (2001). Software engineering: Theory and practice (2 nd ed.). Prentice Hall. Radice, R., Roth, N., O Hara, A. Jr., & Ciarfella, W. (1985). A programming process architecture. IBM Systems Journal, 24(2), Raghavan, S., & Chand, D. (1989). Diffusing software-engineering methods. IEEE Software, pp Rogers, E. (1983). Diffusion of innovations. Free Press. Securities and Exchange Commission (SEC). (2002). SOX: Sarbanes-Oxley Act (Pub. L. No , 116 Stat. 745). Retrieved from 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 models/cmmi-services-status.html Software Productivity Consortium (SPC). (1992). definition and modeling guidebook (SPC CMC). Author. Key Terms Audit: It is an independent examination of a work product or set of work products to assess compliance with specifications, standards, contractual agreements, or other criteria. O

6 Capability Maturity Model: The model is a description of the stages through which organizations 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 : This is a set of interrelated resources, activities, and influences related to a measurement. Measurement Program: A measurement program is the set of related elements for addressing an organization s measurement needs. It includes the definition of organization-wide measurements, methods, and practices for collecting organizational measurements and analyzing data, and measurement goals for the organization. Assessment: It is a disciplined evaluation of an organization s software processes against a model compatible with the reference model. Assets: They are a collection of items, maintained by an organization, for use by programs in developing, tailoring, maintaining, and implementing their processes. Software Assets: They are a collection of entities, maintained by an organization, for use by projects in developing, tailoring, maintaining, and implementing their software processes.