2013 International Conference on Open Source Systems and Technologies (ICOSST)

978-1-4799-2046-4/13/$31.00 ©2013 IEEE 46

Software Development Project States and Project Behavior

Rehan Akbar, Sohail Safdar

Faculty of Information and Communication Technology,

Universiti Tunku Abdul Rahman, Perak Campus, Kampar, Perak,

Malaysia.

Muhammad Aasim Qureshi Faculty of Information Technology

University of Central Punjab, Lahore Pakistan.

Mohd Fadzil Hassan, *Azrai Abdullah

Department of Computer and Information Sciences

*Department of Management and Humanities

Universiti Teknologi PETRONAS Tronoh, Perak, Malaysia.

Abstract– The behavior of software development projects is a characteristic phenomenon that is difficult to study and analyze. The behavior of a software project is a true indicator of its progress and condition. Unfortunately, very less attention has been given to this important aspect of the software projects and rarely any research study has been presented in this regard. The present study addresses this limitation of existing research work and analyzes the behavior of software development projects based on the project states. Project states and their sub-states for the first time in the present study have been derived from the project lifecycle phases. The behavior of the project states have been analyzed based on the risks faced by the projects and project client factors. A case study of real projects has been conducted to validate the project states and their behavior. The project states reflect the true behavior of the software development projects and determine the status and progress of the project. Initial findings of the study have been presented in this paper which will be followed by publishing more detailed findings on the project states in upcoming paper.

Keywords- Progress; Project behavior; Risks; States;

I. INTRODUCTION

A number of factors are involved in determining the behavior of software development projects but these factors have rarely been presented in the context of software project behavior in the existing research work. The behavior of the software development projects is a characteristic phenomena which is dependent on the factors such as risks, project client and team performance. These factors are qualitative in nature and can be analyzed through qualitative approaches. Among other factors, risks are the more critical factor that should be handled throughout the project life [1]. The existing literature focuses more on the process improvement and standardization, requirement management, risk management and project management practices. Unlike these areas, project progress, project qualitative characteristics, project behavior, condition and status have been found as the areas that require more attention and contribution from the software engineering research community.

The behavior and condition of the software development projects are the characteristics which are difficult to analyze and measure due to which prediction about the progress and status of the project is difficult to make. Nevertheless, project team performance risks [2] and project client are the important factors that contribute towards the analysis and determining the behavior of the software projects. Realizing the importance of the role of project manager in risk management, the behavior of management personnel in business and IT have been well explained [3] and is further discussed in [4] and [5]. [6] has emphasized on the project managers to learn from the success and failure stories. Less attention has been paid to these aspects of the software development projects.

To the best of our knowledge, rarely any software engineering research work has studied the behavior and progress of the software development projects. A number of research work such as [6], [7], [8] has been presented on the project lifecycles but this work has not developed the relationship between project lifecycle phases and behavior and progress of the software development projects. Such limitation of the existing work makes it difficult to determine the status and progress of a software project at a particular point in time.

The present study addresses this limitation and studies the behavior of the software development projects, derive the project states from the project lifecycle phases and analyze their behavior based on the risk factor in the projects. A project state is referred to as the condition or status of the software project at a particular point in time. Project states are derived from the project lifecycle phases [6], [7], [8].

The project states show the real behavior of the software

projects which help in determining the current state or condition of the project and project progress then can easily be determined.

2013 International Conference on Open Source Systems and Technologies (ICOSST)

47

II. SOFTWARE PROJECT STATES Every software development project passes through similar

stages called as beginning, middle and end of a project [6]. Various factors such as team performance [9], [10] completion of the working code, problems and satisfaction of the project client affect variably on the execution of these stages. The completion of work in terms of achievement of milestones is a good indicator of the project progress. Various approaches to measure the performance of the project team and progress of the project have been described in different research works such as [11], [12].

Each software project passes through various phases throughout its lifecycle. The lifecycle of each project has been divided into three main phases named as initiation, execution and closure. Nonetheless, in the existing research literature, different nomenclature has been used for various phases of the project lifecycle but their meanings are same as shown in Table 1 that shows some of the lifecycle phases described in different research works.

The similar project lifecycle phases having different names have already been presented but their fundamental basis are same as described in [6]. However, division of project lifecycle phases and their definitions vary from project to project. The division and definition of these phases are made according to the requirement and scope of the software projects. Infact phases of a project lifecycle are not the true indicators of actual project condition and do not describe the exact status of the project. Therefore, without exact identification of the condition or status of the software project, proper measures for smooth progress of the project are difficult to be carried out.

To address this limitation, the existing project lifecycle phases and their activities are adapted and rearranged to derive the states and sub-states of the software development projects. The derivation procedure is shown in Fig. 1. Following states and sub-states of the software development project are derived from the existing lifecycle phases, sub-phases and activities.

a. Takeoff

i. Pre Takeoff ii. Takeoff

b. Running

i. Running ii. Post running

c. Landing

i. Landing ii. Post landing

d. Hang up

i. Crawling

ii. Swing iii. Pre running

TABLE 1. PHASES OF PROJECT LIFECYCLE Westland [13] Stuckenbruck [14] Wideman [15] Webster [16] Initiation

Planning

Execution

Closure

Initiation

Growth

Production

Shut-down

Concept

Development

Implementation

termination

Concept

Development

Implementation

Termination

Figure1. Software Project States

2013 International Conference on Open Source Systems and Technologies (ICOSST)

48

The normal execution flow and sequence of these states is shown in Fig. 2. Normally every project starts its life (take off state), makes continuous progress and achieves the milestones (running state), faces the problems and enters into the hang up state and finally completes its life (landing state) as shown in Fig. 2.

This paper presents only the identification and derivation procedure of project states and sub-states. The detailed definitions of each state and sub-state, analysis of their behaviors and formulation of project states meta-model would be presented in the following paper after performing complete analysis and validation case study of real projects.

III. CASE STUDY APPROACH

A case study of real projects is performed to verify the existence of the project states in real projects. Analysis and validation of the project states and their behavior, and project states meta-model has also been performed which is currently at the final stage. Two qualitative methods such as observations and archival data approach have been applied in two real projects renamed as “A” and “B”. Both projects have been renamed due to the company’s privacy policy. The projects were web applications following agile based methodologies and were outsourced to a software development company. The company selected for the case study was USA based company working on the outsourced projects and one product. Overall the company was practicing agile methodologies in the distributed development environment where the project client and project team were geographically at two different locations. The data is collected related to the duration of each state, its description and problems or issues found in that state. Observations are made as participant observer in the projects, whereas documentation such as project planning, project scheduling, requirement management, project management, meeting minutes and other relevant documents are consulted and analyzed. Within case analysis and cross case analysis techniques are used to analyze the qualitative data to derive the evidences [17], [18].

Requirement management, project planning and scheduling, and interaction and communication processes are studied and analyzed during the case study analysis of the projects.

IV. RESULTS The case study has been completed while analysis is on the

final stage. The results show that average duration of takeoff state was approximately one month. The duration of running state in both projects was ranging from three to six months while of the hang up state was quite variable in both projects such that ranging from few days to one month. Similarly, duration of landing state has been found from one week to one month.

Project execution flow as shown in Fig 2 is the real flow of the software development projects, whereas the ideal execution flow without hang up state (means no problem) normally does not exist. Irrespective of severity, problems occur at any time and always exist in the software projects.

Only the basic initial results have been presented in this paper which verifies the existence of project states in the software development projects and shows their varying durations. The definitions of the project states, detailed case study findings and project state meta-model would be presented in the following research paper after completion of the complete analysis of data.

V. CONCLUSION Each software development project passes through various

states such as takeoff, running, hang up and landing during its whole life. These states truly reflect the current status and progress of the project. It is easy to determine the condition of the project in the presence of various factors such as risks, and client factor.

The initial findings show that behavior and duration of these states varies from one project to the other project. Determining the current status of the project helps in risk resolution and avoidance according to the requirements of the project.

Figure 2. Hang up state and sub-states

2013 International Conference on Open Source Systems and Technologies (ICOSST)

49

Software project states presented in this paper are believed to be the first work on project’s behavioral analysis and project states. The project states provides a deep insight into the behavior of software development projects, their requirements and responses to the various processes, practices, problems and factors.

VI. FUTURE WORK The case study to validate the derived project states has

been completed and analysis is being made on the data. The detailed results of the case study describing existence of project states, their technical definitions, duration, effect on project progress and their flow as well as role of risks and client factor in determining and existence of these states would be presented in detail in the following publication.

Determining average time that a project remains in a particular state and micro level project management when project is in a particular state are the potential research areas that need to investigated further.

REFERENCES [1] H. Sertic, R. Filjar, and Z. Pozgaj, “Efficient Software Development

Organisation Based on Unified Process,” 46th International Symposium Electronics in Marine, ELMAR 2004, 16-18 June 2004, Zadar, Croatia., 16-18 June 2004, 2004.

[2] J. Verner, J. Sampson, and N. Cerpa, “What Factors Lead to Software Project Failure?,” Second International Conference on Research Challenges in Information Sciences, 2008, RCIS, IEEE Explore, pp. 71-80, 2008.

[3] G. S. Kearns, and R. Sabherwal, “Antecedents and Consequences of Information Systems Planning Integration,” IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 54, NO. 4,, vol. 54, no. 4, pp. 629 - 643, 2007.

[4] W. J. Doll, “Avenues for Top Management Involvement in Successful MIS Development,” MIS Quarterly, vol. 9, no. 1, pp. 17-35, 1985.

[5] R. D. Galliers, “Information Systems Planning in the United Kingdom and Australia - A Comparison of Current Practices,” Oxford Surveys in Information Technology, Oxford University Press, Inc., pp. 223-255, 1987.

[6] J. Favaro, “Guest Editor's Introduction: Renewing the Software Project Management Lifecycle,” IEEE Software vol. 27, no. 1, pp. 17-19, 2010.

[7] R. D. Archibald, Managing High-Technology Programs and Projects, 3rd ed.: Wiley Publishers, New York, 2003.

[8] J. Westland, “The Project Management Life Cycle A Complete Step-by-Step Methodology for Initiating, Planning, Executing & Closing a Project Successfully ” Kogan Page Limited, 2006.

[9] P. J. Guinan, J. G. Cooprider, and S. Faraj, “Enabling Software Development Team Performance During Requirements Definition: a Behavioral Versus Technical Approach,” Info. Sys. Research, vol. 9, no. 2, pp. 101-125, 1998.

[10] N. Gorla, and Y. W. Lam, “Who Should Work with Whom? : Building Effective Software Project Teams ” Comunications of the ACM, vol. 47, no. 6, pp. 79-82, 2004.

[11] V. Ambriola, R. Conradi, and A. Fuggetta, “Assessing Process-Centered Software Engineering Environments,” ACM Transactions on Software Engineering and Methodology, vol. 6, no. 3, pp. 283 - 328, 1997.

[12] A. Farooq, and R. R. Dumke, “Research Directions in Verification & Validation Process Improvement,” ACM SIGSOFT Software Engineering Notes, vol. Volume 32 Number 4, 2007.

[13] J. Westland, “The Project Management Lifecycle,” The Project Management Lifecycle A Complete Step by Step Methodology For Initiating, Planning, Executing & Closing a Project Successfully 2007.

[14] L. C. Stuckenbruck, The Implementation of Project Management: The Professional's Handbook, p.^pp. 254: Addison Wesley, 1981.

[15] R. M. Wideman, “The Role of the Project Lifecycle (Life Span) in Project Management,” Available: http://www.maxwideman.com/papers/index.htm, 2004.

[16] F. M. Webster, "What Project Management is All About," The AMA Handbook of Project Management, P. C. Dinsmore and J. Cabanis-Brewin, eds., p. 544: AMACOM Div American Mgmt Assn, 2010.

[17] C. B. Seaman, “Qualitative Methods in Empirical Studies of Software Engineering,” IEEE Transactions on Software Engineering, vol. 25, no. 4, pp. 557-572, July/August, 1999.

[18] P. Runeson, and M. Host, “Guideline for Conducting and Reporting Case Study Research in Software Engineering,” Empirical Software Engineering, vol. 14, no. (2009):14, pp. 131-164, 2009.