- Email: [email protected]
An adaptive software development process model
Available online at www.sciencedirect.com
Advances in Engineering Software 39 (2008) 654–658 www.elsevier.com/locate/advengsoft
An adaptive software development process model M. Rizwan Jameel Qureshi *, S.A. Hussain Department of Computer Science, Comsats Institute of Information Technology, Lahore, Pakistan Received 7 September 2006; received in revised form 24 August 2007; accepted 31 August 2007 Available online 24 October 2007
Abstract The concept of agile process models has gained great popularity in software (SW) development community in past few years. Agile models promote fast development. This property has certain drawbacks, such as poor documentation and bad quality. Fast development promotes use of agile process models in small-scale projects. This paper modifies and evaluates extreme programming (XP) process model and proposes a novel adaptive process mode based on these modifications. 2007 Elsevier Ltd. All rights reserved. Keywords: XP; Adaptive software development; SDLC; OSSD; CBD
1. Introduction Agile process models stress on agility for software development. Agility means responding to changes quickly and efficiently. Possible changes required in software projects are in requirements, budget, schedule, resources, technology and team. These are ‘‘reacting’’ changes on which agile models stress for a successful software project. The agile golden principles defined in agile alliance meeting in 2001 [1] are: 1. Satisfy customer through early and continuous increments. 2. Deploy first increment within couple of weeks and the whole software within couple of months. 3. Customer and agile teams must work jointly daily throughout the project. 4. Agile team and customer must have face-to-face meetings. 5. Welcome requirements even in late phases of the system development.
*
Corresponding author. Tel.: +92 42 5431602; cell: +92 3334492203. E-mail addresses: [email protected] (M. Rizwan Jameel Qureshi), [email protected] (S.A. Hussain). 0965-9978/$ - see front matter 2007 Elsevier Ltd. All rights reserved. doi:10.1016/j.advengsoft.2007.08.001
6. Trust and respect must be maintained among agile team members. 7. Velocity of the project must be measured after delivery of each increment. 8. Emphasis should be on good design to increase agility. 9. Best architecture and design always come out from self-organization. 10. Adjust and tune according to the situation. 11. Whole development process must follow keep it simple (KIS) principle. 12. Agile project needs consistent work until completion. The objective of above mentioned principles is to have adaptive software development only for simple and small size software projects. There is no indication to make process model adaptive according to the nature of projects. An analyst has to select traditional software process models if the software is complex in nature (such as spiral and rational unified process models). Section 2 of the paper describes related work about agile models. Section 3 covers the motivation for adaptive process models. Section 4 proposes an adaptive process model for agile and traditional software development. Section 5 describes how adaptive process model is better than the agile models.
M. Rizwan Jameel Qureshi, S.A. Hussain / Advances in Engineering Software 39 (2008) 654–658
2. Related work According to Highsmith et al. [2], all the agile process models stress on the need of quality design. Extreme programming (XP) is the most widely used model among all agile models, such as dynamic system development methodology (DSDM), adaptive software development (ASD), Scrum, Crystal and feature-driven development (FDD). The prominent phases of XP model are planning, design, coding and testing. Agile models focus on delivering the first increment in couple of weeks and complete SW in couple of months. The main features of all models are fast development and cost saving. Fast development leads to poor quality SW and incorporates all disadvantages of rapid application development (RAD) process model. Lycett et al. in [3] have maintained that, developers are confused to shift from traditional process models to agile process models. Software organizations have invested huge amounts of money to achieve quality standards (International Organization for Standardization (ISO) 9000 and Capability Maturity Model (CMM)), by using standardized process models. The authors are of the view that agile development models have challenged suitability and effectiveness of standard process models. Main disadvantages of agile models are poor quality product, poor design and improper documentation. The authors in this paper portray disadvantages of agile models as their advantages. The comparative analysis in [4] is performed by means of method’s life-cycle coverage, project management support, practical guidance, fitness-for-use and empirical evidence. An agile process model deals with all main phases of system development life cycle (SDLC) and most of them do not provide enough support for project management. Empirical results in this paper are incomplete and are not enough for a complete hypothesis. Lan Cao [5] has modeled dynamics of agile software development process and has explored the implementation and usefulness of agile methods. The research also investigates influence of agile process models on functioning of software from quality, schedule, cost, and customer’s satisfaction perspective. Highsmith et al. in [6], mention function of agile teams for success of software projects. Main characteristics of agile teams are competency, problem solving, decision-making, collaboration, common scope, trust, respect and self-organization. Agile process models are not appropriate to develop all types of software [6]. These process models are not suitable for large teams and less experienced developers. The authors have made these claims without any sound reasons. Agile software development and component based software engineering are two different domains [7]. The authors proposed a model using an integrated approach for agile component development. It is not for agile software development; rather it introduces agility in component based development (CBD). Kuppuswami et al. [8], conducted a study to examine effects of extreme programming (XP) process model on
655
development effort. They developed a simulation model to deduce their results. Fifty user stories were simulated with this model. The results showed that an increase in usage level of individual XP practices reduces development cost. The hypothesis made by the authors yet needs to be proved in real life environments. Agile process models can be adapted to incorporate software standards such as ISO and CMM [9]. Even after confirming the standards, SW process keeps agile property. The adaptation process is an attempt to bridge the gap between traditional and agile process models. Heavy documentation required to achieve SW quality standards is against the principles of agile software development. Production of heavy documentation is a time consuming activity. It delays the increments, which ultimately delays the whole project release time. The model in [10] reduces the threats and risks of agile process models for certain projects. Agile models are well suited for specific nature of projects but are not suitable for all types of projects. Noble et al. in [11] believe that software engineering process models have moved from heavy weight methodologies, such as RUP, to light weight methodologies, such as agile. The authors used agile process models in students’ projects. Results showed that students developed software with less effort compared with traditional process model approach. The research examined ways of introducing agile methodologies more steadily in initial courses of their degree programs. Hazzan et al. [12], have made two suppositions. • Changes payback to societies and groups that accept it. • Change is a basic aspect of worldwide system development. These two suppositions are based on factors such as sex, supervision etc. [12]. The other factors not considered are; requirements, budget, schedule, resources and technology. These changes mentioned have significant impact on agile software development. Cohan et al. in [13], have proved that a transition from traditional process models to agile process models have an affect not only on software engineering group but also on other groups, departments and management. The common recommendations to initiate an agile process model are [13] are: Developers: Developers who are too excited for changes or oppose changes cause an agile project to fail. Managers: Managers who do not interact with their members on daily basis also cause a project to fail. Managers should remove all problems reported by team members. Shift from traditional to agile process model: There should be a steady shift from traditional process model to agile process model otherwise there is a risk of failure. Distributed development: Companies should avoid distributed development sites after shifting to an agile process model for at least first two to three months.
656
M. Rizwan Jameel Qureshi, S.A. Hussain / Advances in Engineering Software 39 (2008) 654–658
Agile team: The main characteristics of an agile team are competency, problem solving, decision-making, collaboration, common scope, trust and respect and self-organization. An agile project team should have these characteristics. Testers: Testers and programmers should be separated to gain full advantages of agile process models. Top management: Top management should not make any commitment to customer regarding delivery of software project that their team will not be able to fulfill. Agile teams should take top management in confidence to achieve success. These recommendations are just guidelines. Agile projects are based on changes at runtime. No manager exactly knows that what kind of situation will emerge during switching from traditional to an agile process. Success of initiating agile projects lies in the fact that how quickly agile teams adjust and react to changes they face during life cycle of projects. Baumeister et al. [14], have proposed modified XP agile process model for developing diagnostic knowledge system. The main phases of this model are System Metaphor, Planning, Implementation and Integration. It’s a hybrid approach consisting of process model to develop expert systems (ESs) and XP model. The objective is to initiate agility in expert systems. It is too early to forecast that this model will meet its objectives. Medium to large software development organizations tackled problems related to magnitude, technology and ambiguous requirements [15]. Agile process models are gaining popularity to address most of these problems. Twelve golden principles to use agile process models provide solutions for most of these problems and remaining of the problems can be solved during adaptation stage. The authors did not provide any proof to authenticate their claim that agile process models are suitable to develop medium and large-scale software. Agile process models are only proposed to develop small-scale software within couple of months. The paper also discusses open source software development (OSSD). Main reasons of OSSD popularity among developers are openness, teamwork and remoteness. There are few commonalities and differences in agile and OSSD approaches. The hybrid approach consists of a mixture of agile and OSSD approaches. Software process engineering meta (SPEM) model has been used to illustrate the hybrid methodology. The process model proposed is very vague and needs to be tested in development environment. OSSD does not follow any process model. It has been developed without passing through proper analysis and design phases.
• • • • • •
distributed development teams; subcontracting; reusable component based development (CBD); sizeable development teams; safety critical projects; development of large and complicated software. There are few more limitations of agile models.
• No proper documentation. • Poor quality software due to faster development. • Heavily reliance on customer’s representative sometimes causes the project to fail. It also can result in less efficient software. Agile process models do not have proper analysis phase. This is the main fault that introduces most of the limitations mentioned above. Agile process models are cyclic and not evolutionary because they are not suitable for development of large scale and complex projects. 4. Adaptive process model for agile development Adaptive process model is a modified approach of XP model, which is the most widely used agile model. The main phases of adaptive process model are shown, in Fig. 1. • • • •
Communication and planning. Analysis. Design and development. Testing and deployment.
Project specification or proposal document is prepared during the planning phase by communicating to the customer. Project specification or proposal document is composed of feasibility and risk assessments that are performed to prepare a cost benefits analysis (CBA) sheet. CBA sheet helps to estimate that whether the SW project is feasible for customers or not. Analysis phase is only started if a customer approves the proposal. Analysis phase improves quality of software through proper documentation. This is the phase where an analyst gathers detailed requirements.
3. Motivation for adaptive process model Turk et al. [16], have mentioned certain drawbacks of agile process models. Agile process models are not suitable for:
Fig. 1. Adaptive process model.
M. Rizwan Jameel Qureshi, S.A. Hussain / Advances in Engineering Software 39 (2008) 654–658
Software requirement specification (SRS) document is produced at the end of analysis phase. Main contents of SRS are: summary of requirements, requirements modeling and data modeling. Requirements either could be structured or object oriented (OO). Entity relationship diagram (ERD) is drawn in case of structured development and object diagram is created for object-oriented development. Design and development phases of XP model are merged to incorporate agility in the proposed adaptive process model. Adaptive process model uses the prototype approach to verify the design and requirements. Software is developed incrementally as customer approves prototypes. Test cases are prepared for each increment at the start of testing and deployment phase. Each module is tested on a unit basis. Integration test is then conducted to check integration among the modules. System test is the next phase to validate the whole increment as one unit. Acceptance testing is the last test to verify increment from the customer. Tested increment is then maintained and deployed. Adaptive process model is cyclic and evolutionary till whole software is developed. Main activities of deployment are installation, training and security. 5. Features of adaptive process model Main features of the adaptive process model are as follows. • • • •
Incorporation of analysis phase. Merging of design and development phases. Merging of testing and deployment phases. Evolutionary in nature.
Analysis phase results in a more comprehensive user requirements, modeling and documentation. SRS is the end product of analysis phase. Better analysis always results in better design and good results for high quality software. Design and development phases of XP process model have been merged in the proposed adaptive model. The objective is to achieve agility in the proposed model. Prototype approach helps to verify the design and requirements. Merging of design and development also improves efficiency of software. Testing and deployment phase is another difference between the proposed and agile process models. One of the main objective of adaptive process model is to eliminate prominent limitations of agile process models and especially of XP. Adaptive process model is proposed to support CBD, large teams, complex and safety critical project development. All of these issues are resolved due to the addition of proper analysis phase and by making the proposed model evolutionary. The addition of proper analysis phase also helps an analyst to consider the factor of reuse during modeling of the proposed system. CBD helps to reuse components frequently in similar applications resulting in time and cost savings. It also results in efficient process design. Documentation and quality are sig-
657
nificantly improved because of the incorporation of these changes. Removal of one limitation eliminates all since all of these limitations are interlinked. Analyst can adapt the cyclic and evolutionary proposed model according to the nature of software projects. The proposed adaptive model can be implemented for agile, large and complex projects. 6. Conclusion This paper supports practice of agile software development by proposing an adaptive process model that can be adapted according to the requirements of the software project. Adaptive process model is better than agile models because it eliminates the limitations of development of reusable components, large development teams, documentation, quality, average and complex software development. From these discussions it is concluded that the proposed model is adaptive and suitable for development of simple, average and complex software projects. References [1] Agile Alliance, Principles behind the Agile Manifesto, http://agilemanifesto.org/principles.html. Visited September 1, 2006. [2] Highsmith J, Cockburn A. Agile software development: the business of innovation. IEEE Comput 2001;34(9):120–7. [3] Lycett M, Macredie RD, Patel C, Paul RJ. Migrating agile methods to standardized development practice. IEEE Comput 2003;36(6): 79–85. [4] Abrahamsson Pekka, Warsta Juhani, Siponen Mikko T, RonKainen Jussi. New directions on agile methods: A comparative analysis. In: Proc of IEEE of computer society, May 3–10, Portland, Oregon, USA, 2003. [5] Cao Lan. Modeling dynamics of agile software development. In: Proc of the 19th annual ACM conference on object-oriented programming, systems, languages, and applications, October 24–28, British Columbia, Canada, Vancouver, 2004. [6] Highsmith J, Cockburn A. Agile software development: the people factor. IEEE Comput 2001;34(11):131–3. [7] Radinger Wolfgang, Michael Goeschka Karl. Agile software development for component based software engineering. In: Proc of the 18th annual ACM SIGPLAN conference on object-oriented programming, systems, languages, and applications, October 26–30, California, USA, 2003. [8] Kuppuswami S, Vivekanandan K, Ramaswamy P, Rodrigues P. The effects of individual XP prctices on software development effort. ACM SIGSOFT software engineering notes ACM press 2003;28(6):6–6. [9] Morkel Theunissen WH, Kourie Derrick G, Watson Bruce W, Standards and agile software development. In: Proc of the SAICSIT 2003, September 30–3 October 2003, South Africa, p. 178–188. [10] Highsmith J, Cockburn A. What is agile software development. J Def Softw Eng 2002. [11] Noble James, Marshall Stuart, Marshall Stephen, Biddle Robert. Less extreme programming. In: Proc of the sixth Australasian computing education conference, January 18–22, Dunedin, New Zealand, 2004, p. 217–226. [12] Hazzan Orit, Dubinsky Yael. Can diversity in global software development be enhanced by agile software development? In: Proc of the 2006 international workshop on global software development for the practitioner, May 23, Shanghai, China. ACM Press; 2006. p. 58–61.
658
M. Rizwan Jameel Qureshi, S.A. Hussain / Advances in Engineering Software 39 (2008) 654–658
[13] Cohan M, Ford D. Introducing an agile process to an organization. IEEE Comput 2003;36(6):74–8. [14] Baumeister J, Puppe F, Seipel D. An agile process for developing diagnostic knowledge systems. KI Journal: Special Issue on AI and Software Engineering 2004;3:12–6. [15] Morkel Theunissen WH, Boake Andrew, Kourie Derrick G. In search of the sweet spot: agile open corporate software development. In:
Proc of the SAICSIT 2005, White River, South Africa, September 20– 22, 2005. p. 268–277. [16] Turk Dan, France Robert, Rumpe Bernhard. Limitations of agile software processes. In: Proc of the 3rd international conference on eXtreme programming and agile processes in software, Alghero, Sardinia, Italy, May 2002.
Advances in Engineering Software 39 (2008) 654–658 www.elsevier.com/locate/advengsoft
An adaptive software development process model M. Rizwan Jameel Qureshi *, S.A. Hussain Department of Computer Science, Comsats Institute of Information Technology, Lahore, Pakistan Received 7 September 2006; received in revised form 24 August 2007; accepted 31 August 2007 Available online 24 October 2007
Abstract The concept of agile process models has gained great popularity in software (SW) development community in past few years. Agile models promote fast development. This property has certain drawbacks, such as poor documentation and bad quality. Fast development promotes use of agile process models in small-scale projects. This paper modifies and evaluates extreme programming (XP) process model and proposes a novel adaptive process mode based on these modifications. 2007 Elsevier Ltd. All rights reserved. Keywords: XP; Adaptive software development; SDLC; OSSD; CBD
1. Introduction Agile process models stress on agility for software development. Agility means responding to changes quickly and efficiently. Possible changes required in software projects are in requirements, budget, schedule, resources, technology and team. These are ‘‘reacting’’ changes on which agile models stress for a successful software project. The agile golden principles defined in agile alliance meeting in 2001 [1] are: 1. Satisfy customer through early and continuous increments. 2. Deploy first increment within couple of weeks and the whole software within couple of months. 3. Customer and agile teams must work jointly daily throughout the project. 4. Agile team and customer must have face-to-face meetings. 5. Welcome requirements even in late phases of the system development.
*
Corresponding author. Tel.: +92 42 5431602; cell: +92 3334492203. E-mail addresses: [email protected] (M. Rizwan Jameel Qureshi), [email protected] (S.A. Hussain). 0965-9978/$ - see front matter 2007 Elsevier Ltd. All rights reserved. doi:10.1016/j.advengsoft.2007.08.001
6. Trust and respect must be maintained among agile team members. 7. Velocity of the project must be measured after delivery of each increment. 8. Emphasis should be on good design to increase agility. 9. Best architecture and design always come out from self-organization. 10. Adjust and tune according to the situation. 11. Whole development process must follow keep it simple (KIS) principle. 12. Agile project needs consistent work until completion. The objective of above mentioned principles is to have adaptive software development only for simple and small size software projects. There is no indication to make process model adaptive according to the nature of projects. An analyst has to select traditional software process models if the software is complex in nature (such as spiral and rational unified process models). Section 2 of the paper describes related work about agile models. Section 3 covers the motivation for adaptive process models. Section 4 proposes an adaptive process model for agile and traditional software development. Section 5 describes how adaptive process model is better than the agile models.
M. Rizwan Jameel Qureshi, S.A. Hussain / Advances in Engineering Software 39 (2008) 654–658
2. Related work According to Highsmith et al. [2], all the agile process models stress on the need of quality design. Extreme programming (XP) is the most widely used model among all agile models, such as dynamic system development methodology (DSDM), adaptive software development (ASD), Scrum, Crystal and feature-driven development (FDD). The prominent phases of XP model are planning, design, coding and testing. Agile models focus on delivering the first increment in couple of weeks and complete SW in couple of months. The main features of all models are fast development and cost saving. Fast development leads to poor quality SW and incorporates all disadvantages of rapid application development (RAD) process model. Lycett et al. in [3] have maintained that, developers are confused to shift from traditional process models to agile process models. Software organizations have invested huge amounts of money to achieve quality standards (International Organization for Standardization (ISO) 9000 and Capability Maturity Model (CMM)), by using standardized process models. The authors are of the view that agile development models have challenged suitability and effectiveness of standard process models. Main disadvantages of agile models are poor quality product, poor design and improper documentation. The authors in this paper portray disadvantages of agile models as their advantages. The comparative analysis in [4] is performed by means of method’s life-cycle coverage, project management support, practical guidance, fitness-for-use and empirical evidence. An agile process model deals with all main phases of system development life cycle (SDLC) and most of them do not provide enough support for project management. Empirical results in this paper are incomplete and are not enough for a complete hypothesis. Lan Cao [5] has modeled dynamics of agile software development process and has explored the implementation and usefulness of agile methods. The research also investigates influence of agile process models on functioning of software from quality, schedule, cost, and customer’s satisfaction perspective. Highsmith et al. in [6], mention function of agile teams for success of software projects. Main characteristics of agile teams are competency, problem solving, decision-making, collaboration, common scope, trust, respect and self-organization. Agile process models are not appropriate to develop all types of software [6]. These process models are not suitable for large teams and less experienced developers. The authors have made these claims without any sound reasons. Agile software development and component based software engineering are two different domains [7]. The authors proposed a model using an integrated approach for agile component development. It is not for agile software development; rather it introduces agility in component based development (CBD). Kuppuswami et al. [8], conducted a study to examine effects of extreme programming (XP) process model on
655
development effort. They developed a simulation model to deduce their results. Fifty user stories were simulated with this model. The results showed that an increase in usage level of individual XP practices reduces development cost. The hypothesis made by the authors yet needs to be proved in real life environments. Agile process models can be adapted to incorporate software standards such as ISO and CMM [9]. Even after confirming the standards, SW process keeps agile property. The adaptation process is an attempt to bridge the gap between traditional and agile process models. Heavy documentation required to achieve SW quality standards is against the principles of agile software development. Production of heavy documentation is a time consuming activity. It delays the increments, which ultimately delays the whole project release time. The model in [10] reduces the threats and risks of agile process models for certain projects. Agile models are well suited for specific nature of projects but are not suitable for all types of projects. Noble et al. in [11] believe that software engineering process models have moved from heavy weight methodologies, such as RUP, to light weight methodologies, such as agile. The authors used agile process models in students’ projects. Results showed that students developed software with less effort compared with traditional process model approach. The research examined ways of introducing agile methodologies more steadily in initial courses of their degree programs. Hazzan et al. [12], have made two suppositions. • Changes payback to societies and groups that accept it. • Change is a basic aspect of worldwide system development. These two suppositions are based on factors such as sex, supervision etc. [12]. The other factors not considered are; requirements, budget, schedule, resources and technology. These changes mentioned have significant impact on agile software development. Cohan et al. in [13], have proved that a transition from traditional process models to agile process models have an affect not only on software engineering group but also on other groups, departments and management. The common recommendations to initiate an agile process model are [13] are: Developers: Developers who are too excited for changes or oppose changes cause an agile project to fail. Managers: Managers who do not interact with their members on daily basis also cause a project to fail. Managers should remove all problems reported by team members. Shift from traditional to agile process model: There should be a steady shift from traditional process model to agile process model otherwise there is a risk of failure. Distributed development: Companies should avoid distributed development sites after shifting to an agile process model for at least first two to three months.
656
M. Rizwan Jameel Qureshi, S.A. Hussain / Advances in Engineering Software 39 (2008) 654–658
Agile team: The main characteristics of an agile team are competency, problem solving, decision-making, collaboration, common scope, trust and respect and self-organization. An agile project team should have these characteristics. Testers: Testers and programmers should be separated to gain full advantages of agile process models. Top management: Top management should not make any commitment to customer regarding delivery of software project that their team will not be able to fulfill. Agile teams should take top management in confidence to achieve success. These recommendations are just guidelines. Agile projects are based on changes at runtime. No manager exactly knows that what kind of situation will emerge during switching from traditional to an agile process. Success of initiating agile projects lies in the fact that how quickly agile teams adjust and react to changes they face during life cycle of projects. Baumeister et al. [14], have proposed modified XP agile process model for developing diagnostic knowledge system. The main phases of this model are System Metaphor, Planning, Implementation and Integration. It’s a hybrid approach consisting of process model to develop expert systems (ESs) and XP model. The objective is to initiate agility in expert systems. It is too early to forecast that this model will meet its objectives. Medium to large software development organizations tackled problems related to magnitude, technology and ambiguous requirements [15]. Agile process models are gaining popularity to address most of these problems. Twelve golden principles to use agile process models provide solutions for most of these problems and remaining of the problems can be solved during adaptation stage. The authors did not provide any proof to authenticate their claim that agile process models are suitable to develop medium and large-scale software. Agile process models are only proposed to develop small-scale software within couple of months. The paper also discusses open source software development (OSSD). Main reasons of OSSD popularity among developers are openness, teamwork and remoteness. There are few commonalities and differences in agile and OSSD approaches. The hybrid approach consists of a mixture of agile and OSSD approaches. Software process engineering meta (SPEM) model has been used to illustrate the hybrid methodology. The process model proposed is very vague and needs to be tested in development environment. OSSD does not follow any process model. It has been developed without passing through proper analysis and design phases.
• • • • • •
distributed development teams; subcontracting; reusable component based development (CBD); sizeable development teams; safety critical projects; development of large and complicated software. There are few more limitations of agile models.
• No proper documentation. • Poor quality software due to faster development. • Heavily reliance on customer’s representative sometimes causes the project to fail. It also can result in less efficient software. Agile process models do not have proper analysis phase. This is the main fault that introduces most of the limitations mentioned above. Agile process models are cyclic and not evolutionary because they are not suitable for development of large scale and complex projects. 4. Adaptive process model for agile development Adaptive process model is a modified approach of XP model, which is the most widely used agile model. The main phases of adaptive process model are shown, in Fig. 1. • • • •
Communication and planning. Analysis. Design and development. Testing and deployment.
Project specification or proposal document is prepared during the planning phase by communicating to the customer. Project specification or proposal document is composed of feasibility and risk assessments that are performed to prepare a cost benefits analysis (CBA) sheet. CBA sheet helps to estimate that whether the SW project is feasible for customers or not. Analysis phase is only started if a customer approves the proposal. Analysis phase improves quality of software through proper documentation. This is the phase where an analyst gathers detailed requirements.
3. Motivation for adaptive process model Turk et al. [16], have mentioned certain drawbacks of agile process models. Agile process models are not suitable for:
Fig. 1. Adaptive process model.
M. Rizwan Jameel Qureshi, S.A. Hussain / Advances in Engineering Software 39 (2008) 654–658
Software requirement specification (SRS) document is produced at the end of analysis phase. Main contents of SRS are: summary of requirements, requirements modeling and data modeling. Requirements either could be structured or object oriented (OO). Entity relationship diagram (ERD) is drawn in case of structured development and object diagram is created for object-oriented development. Design and development phases of XP model are merged to incorporate agility in the proposed adaptive process model. Adaptive process model uses the prototype approach to verify the design and requirements. Software is developed incrementally as customer approves prototypes. Test cases are prepared for each increment at the start of testing and deployment phase. Each module is tested on a unit basis. Integration test is then conducted to check integration among the modules. System test is the next phase to validate the whole increment as one unit. Acceptance testing is the last test to verify increment from the customer. Tested increment is then maintained and deployed. Adaptive process model is cyclic and evolutionary till whole software is developed. Main activities of deployment are installation, training and security. 5. Features of adaptive process model Main features of the adaptive process model are as follows. • • • •
Incorporation of analysis phase. Merging of design and development phases. Merging of testing and deployment phases. Evolutionary in nature.
Analysis phase results in a more comprehensive user requirements, modeling and documentation. SRS is the end product of analysis phase. Better analysis always results in better design and good results for high quality software. Design and development phases of XP process model have been merged in the proposed adaptive model. The objective is to achieve agility in the proposed model. Prototype approach helps to verify the design and requirements. Merging of design and development also improves efficiency of software. Testing and deployment phase is another difference between the proposed and agile process models. One of the main objective of adaptive process model is to eliminate prominent limitations of agile process models and especially of XP. Adaptive process model is proposed to support CBD, large teams, complex and safety critical project development. All of these issues are resolved due to the addition of proper analysis phase and by making the proposed model evolutionary. The addition of proper analysis phase also helps an analyst to consider the factor of reuse during modeling of the proposed system. CBD helps to reuse components frequently in similar applications resulting in time and cost savings. It also results in efficient process design. Documentation and quality are sig-
657
nificantly improved because of the incorporation of these changes. Removal of one limitation eliminates all since all of these limitations are interlinked. Analyst can adapt the cyclic and evolutionary proposed model according to the nature of software projects. The proposed adaptive model can be implemented for agile, large and complex projects. 6. Conclusion This paper supports practice of agile software development by proposing an adaptive process model that can be adapted according to the requirements of the software project. Adaptive process model is better than agile models because it eliminates the limitations of development of reusable components, large development teams, documentation, quality, average and complex software development. From these discussions it is concluded that the proposed model is adaptive and suitable for development of simple, average and complex software projects. References [1] Agile Alliance, Principles behind the Agile Manifesto, http://agilemanifesto.org/principles.html. Visited September 1, 2006. [2] Highsmith J, Cockburn A. Agile software development: the business of innovation. IEEE Comput 2001;34(9):120–7. [3] Lycett M, Macredie RD, Patel C, Paul RJ. Migrating agile methods to standardized development practice. IEEE Comput 2003;36(6): 79–85. [4] Abrahamsson Pekka, Warsta Juhani, Siponen Mikko T, RonKainen Jussi. New directions on agile methods: A comparative analysis. In: Proc of IEEE of computer society, May 3–10, Portland, Oregon, USA, 2003. [5] Cao Lan. Modeling dynamics of agile software development. In: Proc of the 19th annual ACM conference on object-oriented programming, systems, languages, and applications, October 24–28, British Columbia, Canada, Vancouver, 2004. [6] Highsmith J, Cockburn A. Agile software development: the people factor. IEEE Comput 2001;34(11):131–3. [7] Radinger Wolfgang, Michael Goeschka Karl. Agile software development for component based software engineering. In: Proc of the 18th annual ACM SIGPLAN conference on object-oriented programming, systems, languages, and applications, October 26–30, California, USA, 2003. [8] Kuppuswami S, Vivekanandan K, Ramaswamy P, Rodrigues P. The effects of individual XP prctices on software development effort. ACM SIGSOFT software engineering notes ACM press 2003;28(6):6–6. [9] Morkel Theunissen WH, Kourie Derrick G, Watson Bruce W, Standards and agile software development. In: Proc of the SAICSIT 2003, September 30–3 October 2003, South Africa, p. 178–188. [10] Highsmith J, Cockburn A. What is agile software development. J Def Softw Eng 2002. [11] Noble James, Marshall Stuart, Marshall Stephen, Biddle Robert. Less extreme programming. In: Proc of the sixth Australasian computing education conference, January 18–22, Dunedin, New Zealand, 2004, p. 217–226. [12] Hazzan Orit, Dubinsky Yael. Can diversity in global software development be enhanced by agile software development? In: Proc of the 2006 international workshop on global software development for the practitioner, May 23, Shanghai, China. ACM Press; 2006. p. 58–61.
658
M. Rizwan Jameel Qureshi, S.A. Hussain / Advances in Engineering Software 39 (2008) 654–658
[13] Cohan M, Ford D. Introducing an agile process to an organization. IEEE Comput 2003;36(6):74–8. [14] Baumeister J, Puppe F, Seipel D. An agile process for developing diagnostic knowledge systems. KI Journal: Special Issue on AI and Software Engineering 2004;3:12–6. [15] Morkel Theunissen WH, Boake Andrew, Kourie Derrick G. In search of the sweet spot: agile open corporate software development. In:
Proc of the SAICSIT 2005, White River, South Africa, September 20– 22, 2005. p. 268–277. [16] Turk Dan, France Robert, Rumpe Bernhard. Limitations of agile software processes. In: Proc of the 3rd international conference on eXtreme programming and agile processes in software, Alghero, Sardinia, Italy, May 2002.