Measuring Software Project Planning Practices Using Software Process Assessment Method

C S S R 0 8’ 0 9

14 - 15 March 2009

C O N F E R E N C E ON S C I E N T I F I C & S O C I A L R E S E A R C H

MEASURING SOFTWARE PROJECT PLANNING PRACTICES USING SOFTWARE PROCESS ASSESSMENT METHOD S. S. M. Fauzi1 , N. Ramli2 , M. H. N. Md Nasir3 1

Faculty of Computer Science and Mathematic, Universiti Teknologi MARA, Perlis Campus, 02600 Arau, Perlis, MALAYSIA [email protected]

2

Faculty of Information and Communication Technology Universiti Pendidikan Sultan Idris, 35900 Tg Malim, Perak, Malaysia Tel: +60-05-450 5076, E-mail: [email protected] 3

Department of Software Engineering, Faculty of Computer Science and Information Technology University of Malaya 50603 Kuala Lumpur, Malaysia Tel: +60-03-7967 6435 Fax: +60-03-2178 4965 E-mail: [email protected] ABSTRACT Software process assessment (SPA) is an examination of the software process based on the process model. The main purpose of the assessment is to identify how matured is the software process in the organization. Next, it also can help software organizations improve themselves by identifying their critical problems and establishing improvement priorities. One pilot project with 40 project members from various backgrounds has been selected in order to perform the assessment. Eight separate steps involve to perform the SPA. There are 1) select assessment team 2) developing the artifacts such as questionnaires, interview questions, checklist 3) conduct the assessment 4) formulate findings 5) present assessment findings 6) recommendation formulation 7) produce assessment report 8) post assessment follow-up. Based on the assessment, it shows that most of the practices for Software Project Planning (SPP) practices in that project have been performed. This paper will present an experience and result in SPA for SPP practices that have been conducted at a mid-size IT company. Keywords: Software Process Assessment, Software Process, Software Project Planning , Project Planning

1. INTRODUCTION Enterprises in all developed sectors of the economy – not just IT sectors are increasingly dependent on quality software-based IT systems. Such systems support management, production and service functions in diverse organizations. Furthermore, the products and services now offered by the non-IT sectors, for example the automotive industry or the consumer electronics industry increasingly contain a component of sophisticated software. The planning and execution of a cutting pattern in the garment industry is accomplished under software control, as are many safety-critical functions in the control such as airplanes, elevators, trains and electricity generating plants. Today, approximately 70% of all software developed in Europe is developed in the non-IT sectors of the economy. As the information age develops, software will become even more pervasive and transparent. Consequently, the ability to produce software efficiently, effectively and with consistently high quality will become increasingly important for all industries if they are to maintain and enhance their competitiveness. (M. Haug, E.W. Olsen, G.Cuevas, S.Rementeria, 2001). Paper number: 7702347

C S S R 0 8’ 0 9

14 - 15 March 2009

C O N F E R E N C E ON S C I E N T I F I C & S O C I A L R E S E A R C H

A promising approach out of this crisis is now growing up in the software engineering community. In today’s globalization era, we cannot win today’s market place if we still using yesterday’s processes. For that reason, Software Process Assessment (SPA) have become commonplace in the software industry. This paper will discuss about the experience and result in conducting SPA in one of the mid-size Malaysian IT Company. The second part of the paper will confer about the SPA model that we have in place. It will follow with the methodology in third section of this paper, the result and discussion in the fourth section of the paper and finally I will conclude the paper in the final phase; conclusion.

2. LITERATURE REVIEW An assessment is usually based on a process model (S. Zahran, 1998). The interest in software process improvement has created dozens of international software process models and standards. An important feature of software process improvement is that the effort starts with an assessment of the organization's current software process (Humphrey, 1989; McFeeley, 1996; Grady, 1997; Zahran, 1998). Performing an assessment brings about an understanding of how the current software process is performed, and what its strengths and weaknesses are. The concrete outcome of an assessment is usually an outline of an improvement strategy and perhaps even a draft of an improvement plan. Several assessment methods have been developed in recent years. Perhaps the most well known and common of these is the Capability Maturity Model (CMM) Based Appraisal for Internal Process Improvement (CBA IPI) from the Software Engineering Institute (Dunaway & Masters, 1996). In a recent time, Software Engineering Institute has established new model commonly known as CMMI with its own assessment method called as Standard CMMI Appraisal Method for Process Improvement (SCAMPI). Examples of other assessment methods are Bootstrap (Kuvaja et al. , 1994), SPICE (Rout, 1995), QBA (Arent & Iversen, 1996), & Progress Assessment (Daskalantonakis, 1994). The methods are based on the use of questionnaires, interviews, or a combination of the two. They have all been used in practice. All of these assessment methods are based on an underlying model of good software practice as well as a model of the improvement process itself. The CBA IPI, QBA and SCAMPI, for example, are both based on the CMM and CMMI. This model describes five (5) levels of software process maturity: from the initial, or chaotic, Level 1 to Level Five (5), which is characterized by extensive use of metrics to monitor and improve process and product quality. Each level apart from Level 1 is described by a set of institutionalized practices. An organization that has installed and followed all practices at a certain level and all the underlying levels is said to be at that level.Other models, for example the Bootstrap model (Kuvaja et al. , 1994), use a similar structure although the characterization of levels and the way an organization's level is found may vary across models and assessment methods. The models also provide a roadmap for the improvement process itself by recommending that an organization proceed through the levels from the lower levels to the higher levels. An organization at Level 1 commencing an SPI initiative should address issues related to Level 2 before trying to adopt the more advanced practices belonging to higher levels. Such models and the associated assessment methods obviously have a large potential to support the assessment and improvement processes. The organization is evaluated against known and stable criteria, and the levels provide prioritized improvements. The assessment process can thus be carried out in a systematic way, ensuring the reliability of findings. 3. METHODOLOGY In order to perform the research, one small scale software development project has been selected. The project comprise of 40 staffs including Head of Project, Project Manager, Project Leader, System Analyst, Programmer, Business Analyst and other personnel. I have alienated the SPA into eight phases as in Figure 1 below. There are 1) Select assessment team 2) developing the artifacts such as questionnaires, interview questions, checklist 3) Conduct the Paper number: 7702347

C S S R 0 8’ 0 9

14 - 15 March 2009

C O N F E R E N C E ON S C I E N T I F I C & S O C I A L R E S E A R C H

assessment 4) Formulate findings 5) Present assessment findings 6) Recommendation formulation 7) Produce assessment report 8) Post assessment follow-up. The description for each phases are as follows. Select assessment team – I have form an assessment team which consists of a team leader, organizational unit coordinator, librarian, facilitator, timekeeper, process area mini team and observer. Each assessment team should have deep knowledge in software process. Developing SPA artifacts – I then continues the assessment preparation by preparing several instruments such as questionnaires, process areas checklist and also interview question. The use of instruments to gather written or unwritten information from the project provides a relatively low-cost data collection technique. Conduct the assessment - I with the assessment team then conduct the interview with all the related staffs in project including the Head of Project. The primary purpose of the interviews is to give the assessment team a better understanding of the project’s software development practices and the project managers’ perceptions of strengths and weaknesses in the process.

Assessment Team Artifacts - Questionnaires - Interview questions - Checklist - Assessment Plan - Project Preparation Checklist

Guideline

Conduct Assessment - Interview - Document Review

Formulate Findings - Preliminary Finding Template

Present Assessment Findings - Assessment Findings Slide

Recommendation Formulation - Project Findings and Recommendation List

Assessment Final Report - Project Assessment Report

Post Assessment Follow up

Paper number: 7702347

C S S R 0 8’ 0 9

14 - 15 March 2009

C O N F E R E N C E ON S C I E N T I F I C & S O C I A L R E S E A R C H

Figure 1: The SPA Phases Formulate findings - The findings represent the assessment team’s view of the software process currently faces the organization. The findings are based on the questionnaires responses, discussion with the assessment participants in the interview session and discussions among the assessment team members. From the checklist the assessment team have the idea on which practices is not really follow by the project. The mapping process is quite difficult for the reason that there is a lot of information that should be cover. The findings represent the starting point for formulating recommendations. The assessment team should have achieve a team consensus for the assessment findings and complete the preliminary findings presentation. Present assessment findings - To validate the assessment findings, it has been presented to the head of the project, project managers and also project leader. The presentation session serve the purpose of getting the project managers’ commitment to undertake specific improvement initiatives as part of their next software development project. Recommendation formulation - After the findings presentation, the head of project and the assessment team leader hold an executive meeting to discuss next steps. The purpose of the meeting is to confirm the time for the recommendations presentation and final report, to discuss the importance of forming the action plan team and to develop the action plan, and address any questions or concerns of management. Assessment final report - The assessment team then prepare a final report of the assessment findings and recommendations. The purpose of the final report is to document the assessment findings, describe the key findings, and make specific recommendations to the project based on the findings. Besides, the assessment report also consist the characterization for each process areas assessed. The assessment team use the formal characterization in SCAMPI such as Fully Implemented (FI), Largely Implemented (LI), Partially Implemented (PI) and Not Implemented (NI). The intent of this characterization is very effective in order to summarize the assessment team’s judgment and to prioritize process areas where further investigation or corroboration might be necessary. Post assessment follow-up - Although the goal of an assessment is to accurately characterize the current state of the software process that is practiced in the project and identify the key software issues, the ultimate intent is to be catalyst for software process improvement in the assessed project. Following the recommendations, the assessed project have to prepare an action plan that specifies how, when and by whom each recommendations to be implemented. Each action that addresses a recommendation is call an action task. The purpose of the action plan is to identify and plan the work effort for each action task, identify responsibility and resources, and provide a mechanism for tracking and reporting on task status. 4. RESULT AND DISCUSSION The purpose of Project Planning is to establish reasonable plans for performing the software engineering activities and for managing the software project. Software Project Planning involves developing estimates for the work to be performed, establishing the necessary commitments, and defining the plan to perform the work. Figure 2 shows the percentage questionnaires result summary for Software Project Planning practices in that organization.

Paper number: 7702347

C S S R 0 8’ 0 9

14 - 15 March 2009

C O N F E R E N C E ON S C I E N T I F I C & S O C I A L R E S E A R C H

Report Summary for Project Planning Process Area 100%

Result

80% Yes No Not Apply Don’t Know

60% 40% 20% 0% Q1

Q2

Q3

Q4

Q5

Q6

Q7

Question

Figure 2: Result Summary for Software Project Planning Based on the result, it can be conclude that: i. The estimation on size, cost and schedule of the project is based on the expert judgment. The estimation is pretty consistent, therefore can derive into estimation guideline. ii. The respondents in that project agreed that the activities performed in a project have been properly documented in Project Plan. iii. All the affected groups and individuals also agreed to their commitments related to the project. iv. Even though, only half of the respondents has a fair knowledge or agreed that the project in that organization has follow a written organization policy for planning a project. This is maybe because, not all respondents in that project have been well exposed to the organization policy. v. Half of respondents reacted that there is not enough resources for the project. The project maybe lack of individual who has strong expertise in technical areas. Because of that, many of the staffs in that project have to do multitasking task. vi. In term of measurement, there is a report that has been sent to higher management in order to keep track the project status. Based on the interview session, questionnaires, observation, and by analysing work artifacts and other available documents, we have map the result obtained with the CMMI Generic Goals. Table 1 shows the result obtained. Table 1: Mapping Result for Software Project Planning Goal

Findings

Establish Estimates




There were several sections in Project Plan, which indicate High Level Work Plan, Related Projects High Level Budget, and Cost Benefit Analysis. The Project had used ‘expert judgment’ to estimate on size, cost and schedule.

Develop a Project Plan




For Project Planning Process Area, the project generally had a Project Plan, which consists of several sections such as Project Scope, Project Management Approach, Project Organization, High Level Work Plan, Related Projects High Level Budget, and Cost Benefit Analysis. However, there was an area, which has not been covered by




Paper number: 7702347

C S S R 0 8’ 0 9

14 - 15 March 2009

C O N F E R E N C E ON S C I E N T I F I C & S O C I A L R E S E A R C H

the project. The project should identify, list and monitor the risks in the Risk List. The project also should come up with Risk Mitigation and Risk Contingency Plan.

Obtain Commitment to the Plan




The Project Manager, Quality and Technical Reviewers and also Project Sponsor had properly signed off the Project Plan. In term of work breakdown structure, it had been prepared at the early stage of development




There was no staffing requirement included in the Project Plan

From the mapping process in Table 1, we have used the characterization indicator to indicate the level of the software project planning practices. The intent of this characterization is very effective in order to summarize the assessment judgment. Table 2 shows the characterization for the process areas assessed. Table 2: Formal Characterization Process Area Characterization Software Largely Implemented Project Planning We have made some recommendation for the project. For example, the project should establish proper guideline for Project Plan document and the project also should establish a proper estimation guideline. 5. CONCLUSIONS In order for software to be consistently well engineered, its development must be conducted in an orderly process. It is sometimes possible for a small software product to be developed without a well-defined process. However, for a software project of any substantial size, involving more than a few people, an excellent software process particularly in Software Project Planning is essential. The good process in Software Project Planning can be viewed as a road map by which the project participants understand where they are going and how they are going to get there. REFERENCES

Arent, J. , and Iversen, J. (1996). Udvikling af metode til modenhedsm & linger i softwareorganizationer baseret p& The Capability Maturity Model (Development of a CMMBased Method for Maturity Evaluations) unpublished M. Sc. report, University of Aalborg, Aalborg, Denmark. Daskalantonakis, M. K. (1994). Achieving Higher SEI Levels, IEEE Software, Vol. 11, No. 4, pp. 17-24. Dorling. A. , (1993) SPICE: Software Process Improvement and Capability dEtermination. Software Quality Journal 2, 209-224. Dunaway, D. K. , and Masters, S. (1996). CMM-Based Appraisal for Internal Process Improvement (CBA IPI): Method Description. CMU/SEI-96-TR-007, Pittsburgh, PA: Software Engineering Institute.

Grady, R. B. (1997). Successful Software Process Improvement. Upper Saddle R!ver, NJ: Prentice Hall PTR. Humphrey, Watts S. Managing the Software Process. Reading, MA: Addison-Wesley, 1989. Paper number: 7702347

C S S R 0 8’ 0 9

14 - 15 March 2009

C O N F E R E N C E ON S C I E N T I F I C & S O C I A L R E S E A R C H

Kuvaja, P. , Similia, J. , Krzanik, L. , Bicego, A. , Saukkonen, S. , and Koch, G. (1994). Software Process Assessment and Improvement – The BOOTSTRAP Approach. Blackwell. M. Haug, E.W. Olsen, G.Cuevas, S.Rementeria (2001). Managing the Change:Software Configuration and Change Management. Germany: Springer. McFeeley, B. (1996). IDEAL: A User's Guide for Software Process Improvement. CMU/SEI-96LHB-001, Pittsburgh, PA: Software Engineering Institute.., McGuire. E. G. , and Randall. K. A. , Process Improvement Competencies for IS Professionals: A Survey of Perceived Needs. Proceedings ACM SIGCPR Conference, Boston, 1998.

Rout, T. P. (1995). SPICE: A Framework for Software Process Assessment. Process - Improvement and Practice, Pilot Issue,Vol. 1, pp. 57-66.

Software

Zahran, S. (1998). Software Process Improvement: Practical Guidelines for Business Success. Essex, England: Addison Wesley.

Paper number: 7702347