HOME JOURNALS CONTACT

Information Technology Journal

Year: 2010 | Volume: 9 | Issue: 8 | Page No.: 1747-1753
DOI: 10.3923/itj.2010.1747.1753
Software Development Methodologies, Trends and Implications: A Testing Centric View
Xihui Zhang, Tao Hu, Hua Dai and Xiang Li

Abstract: The practice of software development has evolved steadily over the decades. Numerous methods and models (e.g., life cycle models and agile methods) have been proposed to enhance its efficiency and effectiveness. This study provides a testing centric view of software development practices. Specifically, it reviews software development methodologies (i.e., methods and models), identifies the latest trends in the industry and discusses their implications. The review of methodologies, the identification of these trends and the discussion of their implications will be useful to software development educators, students, practitioners and researchers.

Fulltext PDF Fulltext HTML

How to cite this article
Xihui Zhang, Tao Hu, Hua Dai and Xiang Li, 2010. Software Development Methodologies, Trends and Implications: A Testing Centric View. Information Technology Journal, 9: 1747-1753.

Keywords: agile methods, Software development methods and models, life cycle models and software testing

INTRODUCTION

As software is becoming critical to almost every organization, software development, the set of activities that produce software, has become an important topic to software development educators, students, practitioners and researchers. The practice of software development has steadily evolved from its beginning half a century ago. Numerous methods and models (e.g., life cycle models and agile methods), have been proposed to enhance software development efficiency and effectiveness. Currently, life cycle models are the predominant models used in software development, especially in large software development organizations; however, agile methods are on the rise, gaining ground on the life cycle models.

This study provides a testing centric view of software development practices. Specifically, it reviews software development methodologies (i.e., methods and models), identifies the latest trends in the industry and discusses their implications. The review of methodologies, the identification of these trends and the discussion of their implications will be useful to software development educators, students, practitioners and researchers.

SOFTWARE DEVELOPMENT METHODS AND MODELS

Here, we provide a review of software development methods and models, including the analysis-coding model, life cycle models and agile methods. For each method or model, its strengths and weaknesses are identified. Note that these methods and models are not mutually exclusive (Sommerville, 2007), indeed, they are often used together, especially for the development of large, complex, integrated and real-time systems.

Analysis-coding model: In the 1950s, the software development process had only two steps: an analysis step followed by a coding step, as shown in Fig. 1 (Royce, 1970). There was very little emphasis on testing. As such, there were no professional testers and testing was often carried out implicitly by developers or end users to ensure that the program could run and also meet the expectations. This analysis-coding model was useful for small programs, but it became practically ineffective and inefficient for larger programs (Royce, 1970).

Life cycle models: Subsequently, life cycle models were developed, with the intent to bring control and order into the software development process. Life cycle models divide the software development process into clear-cut phases, typically including steps such as analysis, design, coding, testing and implementation (McKeen, 1983).

Fig. 1: The analysis-coding model (Royce, 1970)

Depending on the workflows among the phases, life cycle models can be categorized into sequential models (e.g., waterfall model, traditional V model and PV model), progressive models (e.g., phased model) and iterative models (e.g., spiral model).

Sequential life cycle models are those that have well-defined phases, with the development effort progressing through these phases (IPL, 1997). Examples include the waterfall model, the traditional V model and the PV model.

Waterfall model: The waterfall model includes a set of sequential phases that flow downwards like a waterfall. These phases vary but typically include phases such as requirements analysis, program design, coding, testing and operations, as shown in Fig. 2 (Royce, 1970). Waterfall models have well-defined boundaries and responsibilities for the stakeholders. The development process is normally well-documented because documents generated in the previous phase are required to be signed off before the development proceeds to the next phase (Sommerville, 2007). The major problem of the waterfall model is its inflexibility. It is especially ineffective and inefficient in responding to changing customer requirements (Sommerville, 2007). With a waterfall model, testing normally gets started only after coding is complete. When defects are found, previous phases have to be revisited in order to fix them. This tends to cause a project to run over time and over budget (Tsai et al., 1997)
Traditional V model: The phases in a traditional V model are similar to those in a waterfall model. However, with the traditional V model, each testing activity is mapped to some development activity, as shown in Fig. 3 (Pyhajarvi and Rautiainen, 2004). On the left side, development activities, including requirements analysis, high-level design, low-level design and coding, proceed from top to bottom. On the right side, testing activities, including unit testing, integration testing, system testing and acceptance testing, are completed in a bottom-up fashion. Traditional V models have the same advantages and disadvantages as those of waterfall models
PV model: A PV model is similar to a traditional V model. However, the PV model separates each testing activity into two parts: test planning and test execution. Test plans (e.g., test specifications) are developed along with each development activity and the tests will be executed in reverse order after coding is complete, as shown in Fig. 4 (Sommerville, 2007). Compared to traditional V models, PV models have an additional advantage in that the test plans can be completed earlier in the process, resulting in shortened overall development and testing time

A progressive development life cycle model (also known as phased implementation or incremental delivery), shortens the time to market by delivering interim versions of the software with reduced functionality, a tradeoff that is often made in software development, as shown in Fig. 5 (IPL, 1997).

Fig. 2: The waterfall model (Royce, 1970)

Fig. 3: The traditional V model (Pyhajarvi and Rautiainen, 2004)

Fig. 4: The PV model (Sommerville, 2007)

Each individual phase within a progressive development life cycle may use a waterfall, traditional V, or PV model for its own development life cycle (IPL, 1997). Progressive development life cycle models provide the following major advantages (Sommerville, 2007): (1) customers can use the software after the first delivery and therefore, refine their requirements and (2) the highest priority functionality and features of the system are delivered first and therefore, receive the most testing. However, with a progressive development life cycle model, it can be hard to define the interim versions of the software, especially when the user requirements are not specified in detail.

A simplified iterative life cycle model consists of four major sequential phases: requirements analysis, design, implementation and test and review (IPL, 1997). This model starts with requirements analysis and proceeds through design, implementation and test just as the waterfall model does. However, for each cycle, a decision is made on whether the software meets all the requirements and is ready to release. If it is, the software will be tagged for final delivery; otherwise, the cycle will continue.

Spiral model: The spiral model, proposed in 1986 and refined by Boehm (1988), is one of the most renowned iterative life cycle models. The driving force behind the spiral model is evolutionary development and its major goal is risk management. Each cycle of spiral involves a progression that addresses the same sequence of steps (i.e., requirements analysis, design, implementation and test), along with objective setting, risk assessment and reduction, development and validation and planning, as shown in Fig. 6 (Boehm, 1986, 1988). With the spiral model, the highest priority features are defined and developed first and then more features are added, refined and implemented, incorporating feedback from end users during each cycle of the spiral. The spiral model is effective at minimizing risks which helps to decrease the project's probability of schedule and cost overruns (Sommerville, 2007). However, the spiral model must heavily rely upon risk-assessment expertise. Furthermore, it must be highly customized to each individual software development project, limiting its re-usability across projects

Fig. 5:The progressive development life cycle model (IPL, 1997)

Fig. 6: The spiral model (Boehm, 1986, 1988)

Table 1: Principles behind the agile manifesto

Agile methods: Agile software development methods are basically iterative development approaches that focus on incremental specification, design and implementation (Sommerville, 2007), while requiring full integration of testing and development (Talby et al., 2006). According to the Manifesto for Agile Software Development (http://agilemanifesto.org), agile methods value: (1) individuals and interactions over processes and tools, (2) working software over comprehensive documentation, (3) customer collaboration over contract negotiation and (4) responding to change over following a plan. The intent is to produce high quality software in a cost effective and timely manner and in the meantime, meet the changing needs of the end users. To fulfill these goals, the authors of the Agile Manifesto suggest us to follow 12 principles, as shown in Table 1 (http://www.agilemanifesto.org/principles.html).

There are many agile software development methods, with eXtreme Programming (XP) being the most prominent. Other agile methods include crystal methods, lean development, scrum, adaptive software development, dynamic systems development methods and feature driven development (Highsmith and Cockburn, 2001; Sommerville, 2007). After a short planning stage, XP goes through analysis, design and implementation stages quickly, as shown in Fig. 7 (Dennis et al., 2005). A timebox, usually spanning one to four weeks, is used to ensure that new, enhanced software is ready to be delivered at the end of each iteration. XP principles and practices include incremental planning, small releases, simple design, test-first development, refactoring, pair programming, collective ownership, continuous integration, sustainable pace and the presence of an on-site customer (Beck and Andres, 2005; Sommerville, 2007).

Fig. 7: An XP-based agile method (Dennis et al., 2005)

Test-driven development (TDD), the notion of “writing test cases that then dictate or drive the further development of a class or piece of code” (Murphy, 2005), is an integral core practice of XP. For instance, at Parasoft Corporation (http://www.parasoft.com), at least one test should be written before coding for every task (Binstock, 2009). TDD’s ability to change a class’s implementation and re-test it with very little effort and time makes it a powerful tool for meeting changing client requirements during the course of a project (Murphy, 2005). Beck and Andres (2005) noted that XP encourages communication, simplicity, feedback, courage and respect. With quantitative and qualitative data, Talby et al. (2006) prove that agile software development improves development quality and productivity. For maximal success when using agile methods for software development projects, they suggest that an organization should (1) pay more attention to test design and activity execution, (2) work with professional testers, (3) plan for quality activities and (4) manage defects.

TRENDS

Drawing upon previous reviews of software development methods and models, we identify three major trends in the software development practice. First, agile software development methods are gaining ground on life cycle models. Compared to life cycle models, agile methods offer several advantages. Agile methods can deliver working software faster. Agile methods are better at dealing with changing user requirements. And finally, agile methods promote better working relationships among all stakeholders, including business analysts, developers, testers, end users and project managers. Martens and Gat (2009) express it in the following way: “Agile is a systemic change. It drives cost down, quality up and service levels higher by making the entire process leaner, the entire staff more responsible and the customer more involved”. Moreover, empirical studies indicate that: (1) the traditional life cycle models are too inefficient and ineffective for the development of large, complex systems (Robey et al., 2001) and (2) more recent software development methodologies, such as agile methods and prototyping, can significantly improve development quality and productivity (Talby et al., 2006). Indeed, many large software development organizations, who generally use established life cycle models, are experimenting more and more with agile methods (Crispin and Gregory, 2009; Lee, 2008).

Second, software testing is becoming an integral activity in the software development process. Software testing is indispensible in ensuring software quality (Cohen et al., 2004). Traditionally, testing has been viewed as a separate and distinct stage at the end of the software development process. However, the evolution of software development methodologies indicates that testing is no longer the culminating activity of the development process. Pyhajarvi and Rautiainen (2004) argue that testing is an integral activity in software development and they recommend that testing should be included early in software development. Schach (1996) also suggests that testing should be performed throughout the software life cycle.

Third, software testers are playing a more important role in software development as a direct result of the second trend described above. The tester's role has expanded in two ways. (1) The responsibilities of testers have progressed from error finding (Myers, 1979) to quality assurance (Hetzel, 1983) to code verification and validation (Bentley, 2005). (2) Testers are engaged earlier and throughout the software development process, which has been proven to be beneficial to a project team’s performance. For instance, Waligora and Coon (1996) present quantitative evidence that, by starting testing earlier in the development process, project performance, in terms of cost and cycle time, is improved without sacrificing the overall quality of the software. Gillenson et al. (2007) developed six models for engaging testers early and throughout the software development process. They also compared the models and address the advantages and disadvantages for each. Engaging testers earlier also enables the team to catch defects earlier in the software development process. This helps to cut development costs, because fixing a defect detected in later phases tends to increase costs by one or more orders of magnitude (Tyran, 2006). In the same vein, Yang et al. (2009) conceptualize software testing as a service, including a service to developers and a service to end users.

IMPLICATIONS

The trends in software development methodologies identified above have important implications, especially to the IS research community. First, as more software development organizations adopt agile methods (Trend 1), empirical studies are needed to clarify the impact of using those methods. Research questions may include: (1) Does the use of agile methods lead to a better quality product? (2) Does the use of agile methods lead to higher job satisfaction for the development team members? (3) Does the use of agile methods lead to improved working relationships among team members? (4) Does the use of agile methods lead to improved adherence to project budgets and schedules? (5) Does the use of agile methods lead to a higher level of project success? A better understanding of these questions and their answers would help any software development organization make critical decisions about adopting agile methods. Examples of research address the above questions include Zhang and Dhaliwal (2009) and Zhang et al. (2010). In Zhang and Dhaliwal (2009), they analyze the impact of testing within agile and life cycle software development methodologies. In Zhang et al. (2010), they address the governance issues pertaining to how software testing is organized at strategic, tactical and operational levels. Specifically, they explore the impact of three specific governance mechanisms, including the existence of a distinct corporate testing unit, developers and testers reporting to different executives and the existence of one-to-one matching between developers and testers, on a set of dependent variables comprising organizational, group and individual outcomes.

Second, as software testing is becoming an integral activity in software development (Trend 2), empirical studies are needed to explore the following research questions: (1) What are the best approaches to integrating testing into development? (2) How much, how often and how intense should testing be done? (3) What will be the impact of adopting these approaches on overall project success?.

Third, as software testers are playing a more important role in the software development process (Trend 3), empirical studies are needed to investigate the following: (1) How does the more important role that testers are playing in the software development process impact the working life of the testers? (2) How does this change impact the working relationship between testers and developers? For instance, will this change increase or decrease interpersonal conflict between them? Zhang et al. (2008) is a good example of research that addresses this specific question. (3) What additional skills are needed for these testers to be better prepared for this newly expanded role?

Table 2: Software development trends and implications

The software development trends and their corresponding implications are summarized in Table 2 below. Note that by no means the lists of the research questions are exhaustive. Software development practitioners and researchers are encouraged to pursue additional questions that are more relevant to their experiences, interests and objectives.

CONCLUSION

In this study, we have provided a testing centric view of software development practices. Specifically, we have reviewed software development methodologies, identified the latest trends in the industry and discussed their implications. The contribution of this paper is threefold. The review of software development methodologies can help software development educators and students gain a solid understanding of the subject. The identification of the latest trends within the practice can help software development practitioners make better strategic and tactical development and career decisions. The implications discussed can serve to guide interested software development researchers in future research. It is our hope that this paper will instill knowledge, inspire creativity and generate actions that are related to improved software development.

REFERENCES

  • Beck, K. and C. Andres, 2005. Extreme Programming Explained: Embrace Change. 2nd Edn., Addison-Wesley, Boston, MA


  • Bentley, J.E., 2005. Software testing fundamentals-concepts, roles and terminology. Proceedings of SAS Conference, April 10-13, Philadelphia, PA., pp: 1-12.


  • Binstock, A., 2009. Integration watch: Seriously pragmatic agility. Software Development Times. http://www.sdtimes.com/INTEGRATION_WATCH_SERIOUSLY_PRAGMATIC_AGILITY/By_Andrew_Binstock/About_AGILE/33985.


  • Boehm, B.W., 1986. A spiral model of software development and enhancement. Software Eng. Notes, 11: 14-24.
    Direct Link    


  • Boehm, B.W., 1988. A spiral model of software development and enhancement. Computer, 21: 61-72.
    CrossRef    Direct Link    


  • Cohen, C.F., S.J. Birkin, M.J. Garfield and H.W. Webb, 2004. Management conflict in software testing. Commun. ACM, 47: 76-81.
    Direct Link    


  • Crispin, L. and J. Gregory, 2009. Agile Testing: A Practical Guide for Testers and Agile Teams. Addison-Wesley, Boston, MA


  • Dennis, A., B.H. Wixom and R.M. Roth, 2005. Systems Analysis and Design. 3rd Edn., Wiley, NY


  • Gillenson, M.L., X. Zhang and S. Richardson, 2007. Engaging testers early and throughout the SDLC. Proceedings of 1st International Research Workshop on Advances and Innovations in Software Testing, May 6-8, Memphis, TN.


  • Hetzel, W.C., 1983. The Complete Guide to Software Testing. QED Information Sciences, Wellesley, MA


  • Highsmith, J. and A. Cockburn, 2001. Agile software development: The business of innovation. IEEE Comput., 34: 120-122.
    Direct Link    


  • IPL, 1997. Software Testing and Software Development Lifecycles. Information Processing Ltd., UK


  • Lee, E.C., 2008. Forming to performing: Transitioning large-scale project into agile. Proceedings of AGILE 2008, Aug. 4-8, Toronto, Ontario, Canada, pp: 106-111.


  • Martens, R. and I. Gat, 2009. Guest view: Wrestling with scaling software agility. Software Development Times. http://www.sdtimes.com/link/33988.


  • McKeen, J.D., 1983. Successful development strategies for business application systems. MIS Q., 7: 47-56.
    Direct Link    


  • Murphy, C., 2005. Improving application quality using test-driven development (TDD). Methods Tools, 13: 2-17.
    Direct Link    


  • Myers, G.J., 1979. The Art of Software Testing. John Wiley and Sons, NY


  • Pyhajarvi, M. and K. Rautiainen, 2004. Integrating testing and implementation into development. Eng. Manage. J., 16: 33-39.
    Direct Link    


  • Robey, D., R. Welke and D. Turk, 2001. Traditional, iterative, and component-based development: A social analysis of software development paradigms. Inform. Technol. Manage., 2: 53-70.
    CrossRef    


  • Royce, W.W., 1970. Managing the development of large software systems. Proceedings of the IEEE Wescon, August 1970, The Institute of Electrical and Electronics Engineers, pp: 1-9.


  • Schach, S.R., 1996. Testing: Principles and practice. ACM Comput. Survey, 28: 277-279.
    Direct Link    


  • Sommerville, I., 2007. Software Engineering. 8th Edn., Addison-Wesley, Boston, MA


  • Talby, D., A. Keren, O. Hazzan and Y. Dubinsky, 2006. Agile software testing in a large-scale project. IEEE Software, 23: 30-37.
    Direct Link    


  • Tsai, B.Y., S. Stobart, N. Parrington and B. Thompson, 1997. Iterative design and testing within the software development life cycle. Software Qual. J., 6: 295-310.
    CrossRef    


  • Tyran, C.K., 2006. A software inspection exercise for the systems analysis and design course. J. Inform. Syst. Educ., 17: 341-351.
    Direct Link    


  • Waligora, S. and R. Coon, 1996. Improving the software testing process in NASA's software engineering laboratory: NASA's software engineering laboratory. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.46.5909&rep=rep1&type=pdf.


  • Yang, Y., C. Onita, J. Dhaliwal and X. Zhang, 2009. TESTQUAL: Conceptualizing software testing as a service. Proceedings of the 15th Americas Conference on Information Systems, Aug. 6-9, San Francisco, California, pp: 1-9.


  • Zhang, X. and J. Dhaliwal, 2009. An analysis of impact of testing within agile and lifecycle development methodologies. Proceedings of 3rd International Research Workshop on Advances and Innovations in Software Testing, May 4-5, Memphis, TN., pp: 1-14.


  • Zhang, X., J. Dhaliwal, M.L. Gillenson and G. Moeller, 2008. Sources of conflict between developers and testers in software development. Proceedings of 14th Americas Conference on Information Systems, Aug. 14-17, Toronto, Ontario, Canada, pp: 1-12.


  • Zhang, X., C. Onita and J. Dhaliwal, 2010. Governance of software testing: Impact of distinct testing unit, reporting structure and one-to-one matching. Proceedings of 4th International Research Workshop on Advances and Innovations in Software Testing, May 3-4, Memphis, TN., pp: 1-27.

  • © Science Alert. All Rights Reserved