Скачать 64.8 Kb.
An Analysis of the History of Classical Software Development and Agile Development
Abstract. The ongoing debate over the merits of classical Software Engineering (SE) methodologies and agile methodologies has so far resulted in no clear benefits for the SE community. This paper uses the CHAPL1 framework proposed in our previous research to analyse the history of classical SE methodologies and agile methodologies. Our historical analysis focuses on the following three perspectives: the practices, the principles, and the technological context. The analysis reveals that both approaches to software development have similar roots and that their proponents have ample ground for constructive discussions. In fact, both approaches can be seen as complementary and their integration could contribute to project success.
Key words: software engineering, software process, traditional software engineering, agile development, historical analysis.
Significant effort has been invested over the last decades in identifying good practices, models and methods2 that lead to more efficient software development. The large number of methodologies has also led to heated debates amongst software developers who now tend to classify SE methodologies into two categories:
These two categories appear to have conflicting ideas and are supported by two groups of proponents that have rarely engaged in constructive discussions. With the continuous growth of size and complexity of software applications, we believe it is time to overcome differences and to systematically examine the relationships between the two categories and their associated development philosophies. Our initial research shows that there are multi-dimensional relationships between SE methodologies. The five dimensions that we use in our analysis are Contextual; Historical; Analysis by analogy; Phenomenological; and Linguistic . They are typical analysis methods used in philosophy [7; 8]. This paper focuses on the historical dimension.
We believe that a better understanding of the historical links between the different SE methodologies is of great value to the SE community. Klein states that historical analysis increases awareness of the shared history; and a shared history can reduce hostility, increase commitment and make communication easier across boundaries . It also supports reflection and avoids dogmatism as witnessed by many of us . Therefore, this paper makes an initial step towards addressing the historical link between the methodologies. To achieve this, we analysed over 100 papers and books on SE methodologies from the two categories discussed above focusing on the historical analysis of the practices, principles3 and technological context of each methodology.
The rest of the paper is organised as follows: The historical analysis of the practices used in classical SE and in agile development is presented in Section 2, and the principles in Section 3. Analysis of the technological context of SE methodologies is presented in Section 4. Related work is described in section 5. Conclusions and discussion of future work are summarised in Section 6.
2 Historical Analysis of the Practices Used in Classical SE and Agile Development
The terms “agile” and “agility” can be traced back to the manufacturing industry in 1991 when “lean development” emerged in manufacturing with the aim of eliminating waste, amplifying learning, delivering as fast as possible and empowering teams . Youssef  even coined the term “agile manufacturing” around that time. It therefore appears that at least some of the roots of agile methodologies can be traced back to traditional engineering disciplines.
The idea of iterative and incremental development used in most agile process models can be found as early as the 1930s when a quality expert at Bell Labs used this practice to improve product quality . A complete definition and explanation of this practice for software development is given by Basili in 1975 . Gladden and Gilb have proposed the practice of “delivering working software early” in the early 1980s [15, 16] to address the issue of late delivery of software products resulting in customer dissatisfaction. These practices can be directly mapped to the agile practice “frequent delivery”, and “continuous integration”.
The practice of using a prototype of working software as the primary measure of progress is one of the principles in agile modelling. A similar idea can be found in manufacturing as early as 1982 when Gladden stated that a physical object conveys more information than a written specification . It has been extensively used in classical SE for feasibility studies and elicitation of requirements. For instance, Rapid Application Development (RAD) is a development approach that is based on this principle .
Requirements engineering (RE) practices are a very important part of most engineering disciplines since having a good understanding of requirements is the first step towards delivering a product that meets customer expectations. However, RE is not an easy process; uncertainty and volatility of requirements are two problems that challenge developers in all disciplines. Joint Application Design (JAD) is a practice used in IBM Research Labs in Toronto in the late 1970’s . The fundamental objective of this practice is to get quality business requirements through active participation of stakeholders. Some ideas used in JAD are similar to stakeholder collaboration used in Dynamic Systems Development Method (DSDM) , another representative of agile methodologies.
The importance of having a work environment that helps improve communication among team members has been discussed in . Weinberg argued that face-to-face communication can help exchange information efficiently. The practice in XP of having an “open workspace” also emphasizes the importance of face-to-face communication.
The historical analysis of practices used in agile development and traditional SE shows that there are clear similarities and significant overlap in the use of practices. Our findings based on the historical analysis of practices is summarised in Table 1.
3 Historical Analysis of the Principles used in Classical SE and Agile Development
The ultimate goal of SE theories, techniques and methodologies is to help developers produce high-quality products in an economical and timely manner . However, there is not one ideal process that works in all situations. In fact, development processes and techniques tend to change at least slightly each time when a new product is designed and produced  even within the same company. Dijkstra states that any piece of software to be developed is new and its development process is an innovation process . Thus, the software process has to be customized according to the specific needs of the project .
In this section, we want to examine the fundamental principles used in classical SE and in agile development irrespective of the terminology used. This is because those SE principles tend to be enduring  and can be instantiated to different practices.
In  where the classical waterfall model was presented, Royce explicitly mentioned a fundamental principle “involves customers” and he emphasized that designer “must communicate with interfacing designers, with his management and the customers” and “maintain customer involvement in specification and certification”. This principle shares the same values with the practices of “Active user involvement” and stakeholder collaboration in DSDM , and “On-site customer” in XP. As another example, “using better and competent people in software development” is one of the prominent principles of agile, which has also been discussed as a principle in a lot of classical SE literature (e.g., [28; 29; 24]).
Furthermore, the underlying principle behind “Product backlog” and “Sprint backlog” in Scrum and “User story card” in XP is similar to requirements specification in waterfall, cleanroom  and spiral models. All of them assume that at least some requirements need to be known before implementation can start. However, there is significant disagreement in practice between the two schools of thought on the extent to which requirements have to be determined and documented. For a big project with high requirements availability and low requirements volatility it is useful to first get a clear picture of all system requirements. However, for a smaller or a medium sized project with uncertain requirements it makes sense to scale down requirements specification to its minimum format by using incremental and iterative processes that help discover requirements gradually.
Based on the analysis of the principles used in classical SE methodologies and agile methodologies, we can see that agile methodologies have at least some historical links to classical SE methodologies. This is a further indication that we should not dogmatically separate classical SE from agile development. Fig. 1 illustrates the results of our analysis of the historical links between the practices of two schools through the SE principles.
4 Historical Analysis of the Technological Context of Classical SE and Agile Development
In this section, we want to investigate how technology influenced the development and use of SE methodologies over the years. Some researchers have argued that context is the key reason for deciding which methodology will be suitable [10, 31]. One needs to consider historical, organisational, cultural and project contexts.
In this research, we have analysed the history of the technological context of several classical SE and agile methodologies. For the purpose of this paper, the discussion of context focuses on the technology available when a SE methodology was developed, used, and evolved. We will take several methodologies as examples.
4.1 Technological Context of the Waterfall Model
The waterfall model emerged in the late 1960s when programming languages were inefficient and hardware consisted of mainframe computers with slow CPUs and very limited memory. The waterfall model mainly addresses management issues which include well-defined development phases and some basic SE principles, such as involving customers and producing quality requirements specifications. It is suitable within the technological context at that time and for large, long-term projects that require extensive upfront contracts between developers and customers. However, after contracts have been established, requirements are not supposed to change any more. Technical writers would be hired to handle the large amount of documentation required for the project. A librarian would keep track of code libraries and other paper documents as electronic storage space was expensive and no document management systems were available . Having well-defined requirements documents was an important means for effective communication among developers in big teams . With the availability of configuration management and software documents tools nowadays, the instantiation of the waterfall model in practice has to change.
4.2 Technological Context of Evolutionary Development and the Spiral Model
Two methodologies that emerged during the mid-1980s and have impacted the SE community are: evolutionary development  and the spiral model . Both of these two methodologies are built on prototyping [34; 35]. Prototyping was first used for highly innovative defence projects, and the requirements of the project were very hard to get upfront. Consequently it leads to significant delays or cancelation of projects . The technological context of prototyping is the availability of interactive programming environments, graphical user interfaces (GUI), and fourth generation programming languages. This new technology enabled developers to build prototypes at much lower cost.
Evolutionary development and the spiral model emerged at a time when Personal Computers (PC) became popular and affordable by the general public, large hardware storage space and other high hardware facilities, such as high resolution monitors, became available. They allowed software engineers to solve more complex problems. However, the increased complexity and size of software projects resulted in risks that required methodologies able to handle them. As a risk-driven and plan-driven process model; the spiral model combines evolutionary development and the waterfall model thus providing means to tackle the risks involved in software projects .
4.3 Technological Context of Agile Methodologies
When agile methodologies emerged in software engineering, the technological landscape had drastically changed:
These advancements increased the ambitions of the software industry and enabled developers to deal with a wide range of applications from small software projects that need 2 to 3 developers for 3 to 6 months to extremely complicated and large problems that require hundreds or even thousands of developers. Over the last decade, software developers have found that it is hard to plan and monitor the entire system development process due to the fact that many systems, especially web-based or web-related systems, change and grow rapidly in their requirements, functionality and contents during their life cycle, much more than what they encountered before .
To deal with the challenge of rapid change, a set of agile-like methodologies were developed. They could immediately address some challenges of many small to medium-sized software projects. More importantly, these methodologies evolved and matured into a new category of SE technologies with tremendous possibilities to maximise developers’ potential . They were supported by new technologies that allowed them to:
Furthermore, the advent of J2EE, .NET and various other technologies provides support to developers to apply agile practices in software project.
The detailed analysis of the historical context of other SE methodologies has shown that the technological context and the project context play important roles in the emergence and evolution of SE methodologies. A summary of our research results is given in Table 2.
5 Related Work
Very little research, to our best knowledge, has investigated the historical links between classical SE methodologies and agile methodologies in depth. The closest related work was done by Abbas et. al.  who studied the roots of some agile practices. Abbas et. al. argued that some agile practices have their historical roots in older SE practices. However, their work did not investigate links between classical and agile SE considering the principles and the technological context.
nother related work is the work from Larman and Basili  who discussed the historical roots of the practice “iterative and incremental methodology” in great detail. Abrahamsson et. al. conducted a comparative analysis of several agile methodologies and their relationships . No historical analysis of the relationship between classical methodologies and agile methodologies is provided. Turner and Jain show that agile practices support 11 Process Areas and Generic Practices of CMMI which indicates some links between CMMI and agile development . We hope this paper provides a more comprehensive discussion on this issue.
6. Conclusion and Future Work
Unfortunately, all SE methodologies still have significant limitations . Thus, we should stand back and look at the origin of these methodologies, the philosophy behind the methodologies, and the technologies and social environment which supported the generation of these methodologies. Research into the historical links between classical SE methodologies and agile methodologies can help us understand the relationships between the practices in the two development philosophies. This paper presents our findings of the historical links from three perspectives: the practices, the principles, and the technological context.
A number of implications of this investigation are summarised below:
(1) There is significant evidence that practices used in SE methodologies and in agile methodologies have historical links. Moreover, many practices in both approaches have roots in other, and in traditional engineering discipline as shown in Table 1.
(2) A detailed analysis of the fundamental principles behind some practices used in agile methodologies shows that the same principles are used in the practices of classical SE methodologies i.e. we can see links between the fundamental principles behind practices in both categories of methodologies.
(3) The technological context has a significant impact on the emergence, evolution and change of methodologies. A methodology that works well in the context of one organization with its particular social, technological, managerial and cultural environment does not guarantee that it will also work well in another context. This means that any SE methodology has to be adapted to the context of its usage.
Historical links between existing methodologies indicate that classical SE methodologies and agile methodologies share the same values, and therefore, are all valuable assets of the SE discipline. This holistic view is very important since it will:
(1) provide information about the relationships between SE methodologies which can provide developers a good position to understand deeply, judge objectively and use SE methodologies wisely in practice
(2) allow developers to study valuable practices from all existing SE methodologies and integrate them to address today’s SE problems. The benefits of integrating practices used in classical SE and in agile methodologies have already been reported by Boehm in 
We argue that the disparities between SE methodologies reflect the facts that different practices are required to tackle the different challenges in a large array of software projects. The failure of a software project is not caused by a software methodology but by the development team that selected an inappropriate development methodology.
Already in 1996, Basili emphasized that we need models that help us reason about the suitability of SE practices and methodologies for a specific software project . However, still very little research has been done in this area . We argue that, based on an understanding of the relationships between classical SE and agile methodologies, it is possible and beneficial to SE to develop a reasoning mechanism that assists with the selection of best practices, techniques and methodologies for software projects.
1. Paulk, M. C. et al.: The Capability Maturity Model: Guidelines for Improving the Software Process. Addison-Wesley, Reading, Mass., (1995)
2. Beck, K. Andres, C. Extreme Programming Explained: Embrace Change. Addison-Wesley, Boston, 2005.
3. Cockburn, A.: Agile Software Development, The People Factor. Computer (Long Beach, Calif.), (0018-9162), 34 (11), p.131.
4. Jiang, L., Eberlein, A.: Towards a Framework for Understanding the Relationships Between Classical Software Engineering and Agile Methodologies. In: APSO 2008,:In conjunction with 30th International Conference on SE, Leipzig, Germany, 10 – 18, May (2008)
5. Floyd, C.: A Comparative Evaluation of System Development Methods. In Olle, T.W., Sol, H.S., and Verrijn-Stuart, A.A., (eds) (North-Holland, Amsterdam), pp. 19-54 (1986)
6. Jiang, L.: A Framework for Requirements Engineering Process Development. University of Calgary, PhD Thesis, Sept. (2005)
7. Dahlbom, B., Mathiassen, L.: Systems Development Philosophy. ACM SIGCAS, Computers and Society, Vol. 22 , Issue 1-4, pp: 12 – 23, (1992)
8. Mitcham, C.: The Importance of Philosophy to Engineering, Teorema XVII(3):pp. 27-47, (1998)
9. Klein, H., Hirschheim, R.: The Structure of the IS Discipline Reconsidered: Implications and Reflections from a Community of Practice Perspective. Information and Organization (1471-7727), 18 (4), p. 280. (2008)
10. Kruchten, P.: Voyage in the Agile Memeplex. ACM Queue: Tomorrow’s Computing Today, 5 (5):38–44, July (2007)
11. Poppendieck, M., Poppendieck, T.: Lean Software Development: An Agile Toolkit. Addison Wesley, The Agile Software Development Series, New York, NY. (2003)
12. Youssef, M.A.: Agile manufacturing: a necessary condition for competing in global markets. Industrial Engineering, Dec., 18(20), (1992)
13. Larman, C., Basili, V.R.: Iterative and Incremental Development: A Brief History. IEEE Computer Society 36(6): 47-56. (2003)
14. Basili, V., Turner J.: Iterative Enhancement: A Practical Technique for Software Development, IEEE Trans. Software Eng., pp. 390-396, (1975).
15. Gladden, G.R.: Stop the Life-cycle, I Want to Get off. 7(2): pp. 35-39 (1982)
16. Gilb, T.: Evolutionary Delivery versus the "waterfall model". ACM SIGSOFT Software Engineering Notes 10(3): pp. 49-61, (1985).
17. Bourque, P: Fundamental Principles of Software Engineering–A Journey. The Journal of Systems and Software (0164-1212), 62 (1), p. 59, (2002).
18. Martin, J.: Rapid Application Development, Macmillan Publishing, New York, (1991).
19. Wood, J., Silver, D.: Joint Application Development, John Wiley and Sons, NY. (1989).
20. Millington, D., Stapleton, J.: Developing a RAD standard. IEEE Software, 12(5), 54-56, (1995).
21. Weinberg, G.M.: The Psychology of Computer Programming. New York : Van Nostrand Reinhold, (1971)
22. Cugola, G., Ghezzi, C.: Software Processes: A Retrospective and A Path to the Future. Journal of Software Process - Improvement and practice, vol. 4, pp. 101-123, (1998).
23. Jarratt, T., Eckert C.: Clarkson P.J.: Pitfalls of Engineering Change, Change Practice during Complex Product Design, Advances in Design, Springer London, (2006).
24. Dijkstra, E.W.: The Humble Programmer. Communication of the ACM, 15(10): p. 859-866, (1972).
25. Glass, R.L.: Matching Methodology to Problem Domain. Communications of the ACM (0001-0782), 47 (5), p. 19, (2004).
26. Royce, W.: Managing the Development of Large Software Systems. Proceedings of Westcon, IEEE CS Press, pp. 328-339, (1970).
27. Stapleton, J.: Dynamic Systems Development Method, Addison Wesley, Longman, Reading, Mass., (1997)
28. Boehm, B.: Seven Basic Principles of Software Engineering. In Infotech State of The Art Report on SE Techniques, Infotech International Ltd., Mmdenhead, UK, (1976)
29. Zelkowitz, M.V.: Perspectives on SE. Computing Surveys. (ACM) 10(2), 197-216, (1978)
30. Prowell, S.J., Trammell, C.J., Linger, R.C., Poore J.H.: Cleanroom Software Engineering: Technology and Process. Addison-Wesley, (1999).
31. Jiang L., Eberlein, A. Far B.H.: A Case Study Validation of a Knowledge-Based Approach for the Selection of Requirements Engineering Techniques, Journal of Requirements Engineering, (2007)
32. Brooks, F.P.: The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition. Reading, MA: Addison-Wesley, (1995).
33. Boehm, B.: A Spiral Model of Software Development and Enhancement, Computer, May, pp. 61-72, (1988).
34. Gomaa, H, Scott D.B.H.: Prototyping as a Tool in the Specification of User Requirements. In: International Conference on Software Engineering (0270-5257), p. 333, (1981).
35. Gomaa, H.: The Impact of Rapid Prototyping on Specifying User Requirements". Software Engineering Notes (0163-5948), 8 (2), p. 17, (1983).
36. Ginige, A., Murugesan, S.: Web Engineering: An Introduction, IEEE Multimedia, Special Issues on Web Engineering, vol 8, no 1, pp 14-18, (2001)
37. Cowan, R.: Software Engineering Technology Watches. IEEE software (0740-7459), 19 (4), p. 123, (2002).
38. Abbas, N., Gravell, A., Wills, G.: Historical Roots of Agile Methods: Where did “Agile Thinking” Come from? In Proceedings of Agile processes and eXtreme Pogramming in Software Engineering, Limerick, Ireland, (2008).
39. Abrahamsson, P., Warstab, J., Siponenb, M.T., Ronkainena, J.: New Directions on Agile Methods: A Comparative Analysis, Proceedings of the 25th International Conference on Software Engineering, pp. 244–254, (2003).
40. Turner, R., Jain, A.: Agile Meets CMMI: Culture Clash or Common Cause? In D. Wells and L. Williams (Eds.): LNCS , XP/Agile Universe 2002, pp. 153–165, (2002).
41. Basili, V.R.: The Role of Experimentation in Software Engineering: Past, Current, and Future. In 18th International Conference on SE, Berlin, Germany, pp: 442 – 449, (1996)
42. Boehm, B.: Using Risk to Balance Agile and Plan- driven Methods". Computer (Long Beach, Calif.) (0018-9162), 36 (6), p. 57, (2003).
43. Thomke, S.: The Role of Flexibility in the Development of New Products: An Empirical Study. Research Policy 26:105–119 (1997)
44. Aoyama, M.: Agile Software Process and its Experience, April 1998, Proceedings of the 20th international conference on Software engineering ICSE '98, (1998).
45. Aoyama, M.: Web-Based Agile Software Development, IEEE Software, (0740-7459), 15 (6), p. 56., (1998).
46. Gilb, T.: Principles of Software Engineering Management, Addison-Wesley, Wokingham, UK, (1988).
47. Alexander, C.: The Timeless Way of Building, Oxford University Press, New York, (1979).
48. Takeuchi, H., Nonaka, I.: The New Product Development Game. Harvard Business Rev., Jan./Feb., pp. 137-146.(1986)
49. Bersoff, E., Henderson, V., Siegel, S.: Software Configuration Management, Prentice-Hall, Englewood Falls, NJ (1980).
50. Sommerville I. Software Engineering:, Addition Wesley, 6/e, (2000).
51. Bell T.E., Thayer T.A.: Software Requirements: Are They Really a Problem?. Proceedings of the 2nd International Software Engineering Conference, October (1976).
52. Paulk,M.C., Curtis, B., Chrissis, M.B.: Capability Maturity Model for Software, Software Engineering Institute, CMU/SEI-91-TR-24, ADA240603, August (1991)
53. Fagan, M.E.: Design and Code Inspections to Reduce Errors in Program Development. IBM System Journal 15(3), pp. 182–211. (1976)
54. Saint-Exupery, A.D.: Wind, Sand and Stars. London : Heinemann, (1954).
55. Dill, D.D.: The self-designing organization: structure, learning, and the management of technical professionals. in Technology Management: the New International Language (0-7803-0161-7, 978-0-7803-0161-0), (p. 33), (1991).
56. Smith, C, Comer D.: Self-organization in Small Groups: A Study of Group Effectiveness Within Non-equilibrium Conditions. Journal of Human Relations. 47:553–81, (1994.).
57. Imai, K., Nonaka, I., Takeuchi, H.: Managing the New Product Development Process: How Japanese Companies Learn and Unlearn. In K.B. Clark, R. H. Hayes. and C. Lorenz (eds.), The Uneasy Alliance: 337-376. Boston: Harvard Business School Press, (1985)
58. Schwaber, K.: Scrum Development Process. In 10th Annual ACM Conference on OOPSLA 1995, Austin, Texas, USA, 117-134. (1995)
59. Palmer, S.R., Felsing, J.M.: A practical guide to feature driven development. Upper Saddle River, NJ: Prentice Hall, (2002).
60. Davis, A.M.: Fifteen principles of software engineering, IEEE Software, Volume: 11, Issue: 6, pp: 94-96, 101, (1994)
61. Dahl O.J., Dijkstra, E.W., Hoare, C.A.R.: Structured Programming, Academic Press, London; New York, (1972)
62. Parnas, D.L.: Abstract Types Defined as Classes of Variables. ACM SIGPLAN Notices, vol. II, no. 2, pps. 149-154, (1976).
63. Liskov, B., Zilles, S.: Programming with Abstract Data Types. Proc. ACM SIGPLAN Symposium, ACM Press, pps. 50-59, (1974).
64. Jackson, M.A.: Principles of Program Design. London; NY : Academic Press, (1975).
65. Cameron, John R. JSP & JSD: the Jackson Approach to Software Development, Silver Spring, MD : IEEE Computer Society Press, (1983).
66. Humphrey, W.S.: Managing the Software Process, Addison-Wesley Longman Publishing Co., Inc. Boston, MA, USA, ISBN:0-201-18095-2 , (1989)
67. Paulk, M.C., Curtis B, Chrissis, M.B., Weber, C.V.: Capability Maturity Model, version 1.1". IEEE software (0740-7459), 10 (4), p. 18, (1993).
68. Hoyle, D.: ISO 9000 Quality Systems Handbook, 2nd ed. ,Oxford : Butterworth-Heinemann, (1994).
69. Jacobson, I.: Object-Oriented Software Engineering: A Use Case Drive Approach. Addison-Wesley, New York: ACM, ISBN: 0201544350, (1992).
70. Cusumano, M.A., Selby, R.W.: Microsoft secrets: How the World’s Most Powerful Software Company Creates Technology, Shapes Markets, and Manages People. The Free Press, (1995).
71. Beck K, Fowler M.: Planning extreme programming, Boston: Addison-Wesley, (2001).
72. Kruchten, P.: The Rational Unified Process, (2nd ed.), Addison Wesley, (2001).
73. Harrison, W., Ossher, H., Tarr, P.: Software Engineering Tools and Environments. In 22nd International Conference on Software Engineering, pp. 263–277, (2000).
74. Steinmueller, W.E, The U.S. Software Industry: An Analysis and Interpretative History, in David C. Mowery (ed.), "The International Computer Software Industry," Oxford University Press (1995).
75. Mockus, A., Fielding R.T., Herbsleb J. D.: Two Case Studies of Open Source Software Development: Apache and Mozilla". ACM transactions on Software Engineering and Methodology (1049-331X), 11 (3), p. 309., (2002).
76. Myers, B.: Past, Present, and Future of User Interface Software Tools". ACM Transactions on Computer-human Interaction (1073-0516), 7 (1), p. 3. (2000).
77. Raymond, E.: The Cathedral and the Bazaar. Knowledge, Technology, & Policy, 12 (3), p. 23, (1999).
78. Ambler S.: Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process, John Wiley & Sons, Inc., New York, NY, (2002)
1 See  for more information
2 For a detailed discussion on the differences between the terms SE method, SE methodology, software process model and software lifecycle, please see [5, 6].
3 According to the Webster English Dictionary, a principle is a comprehensive and fundamental law, doctrine, or assumption. In this paper, we define a principle as an idea, insight or objective behind a practice, while practices are the activities that carry out the principle. A good discussion about the differences between principle and practice can be found in .
|Msf for Agile Software Development 0||Published in Turchin P., Grinin L. E., de Munck, V. C. and Korotayev, A. V. (eds.), History & Mathematics: Historical Dynamics and Development of Complex|
Кочакова 1995. However, when we try to apply this scheme to the political development of the World System, it becomes evident that...
|Productivity and Quality in Software-Projects Psychological Analyses and Optimization of Work Processes in Software-Development||Dp united Nations Development Programme Arab Fund for Economic and Social Development arab human development report 2003|
|Cs-564 Software Development Tools & Processes||Cs-564 Software Development Tools & Processes|
|Business Case Analysis and Development||Business Case Analysis and Development|
|A history of Policy and Program Development||M14 Rifle History and Development|