From Wikipedia, the free encyclopedia

In software engineering and project management, a methodology is a codified set of practices (sometimes accompanied by training materials, formal educational programs, worksheets, and diagramming tools) that may be repeatably carried out to produce software.

Software engineering methodologies span many disciplines, including project management, analysis, specification, design, coding, testing, and quality assurance. All of the methodologies guiding this field are collations of all of these disciplines.

Disagreement exists regarding the relationship between the terms method and methodology. In common use, the methodology is frequently substituted for method; seldom does the opposite occur. Some argue this occurs because methodology sounds more scholarly or important than method. A footnote to the word methodology in the 2006 American Heritage Dictionary notes that, "the misuse of methodology obscures an important conceptual distinction between the tools of scientific investigation (properly methods) and the principles that determine how such tools are deployed and interpreted." In academia, the distinction between practice (i.e., method) and the philosophical basis for the practice (i.e., methodology) tends to be more clearly delineated.

In Software Engineering in particular, the discussion continues. One could argue that a software engineering method is a recipe, a series of steps, to build software, while a methodology is a codified set of recommended practices, sometimes accompanied by training materials, formal educational programs, worksheets, and diagramming tools. In this way, a software engineering method could be part of a methodology. Also, some authors believe that in a methodology there is an overall philosophical approach to the problem. Using these definitions, Software Engineering is rich in methods, but has fewer methodologies. There are two main stream types of methodologies: Structured Methodology (Information Engineering, SSADM and others), which encompass many methods and software processes; and Object Oriented Methodology (OOA/OOD and others).

Algorithms for Programmers 1 

Many methodologies feel like an attempt to define algorithms for programmers to follow. This has the effect of making software more impersonal and less worth doing. This lowers motivation and job satisfaction for programmers. Programmers have resisted most rigid methodologies.

Counterargument: Most workers resist a contract when possible. A contract can be ego damaging when you fail to meet the terms. Nevertheless, it is a valid point that not all contracts should be accepted, especially when the contract is a boilerplate that does not fit the new job well. In this case, that means a programmer should be able to propose changes to any method or methodology they are given and be given explanation if such changes are not accepted.

Algorithms for Programmers 2 

If it were possible to define a methodology precisely, it should be encoded in a program, and the computer should carry it out. The reason methodologies do not work as programs is that they are too vague to be usefully defined.

Everyone already knows 

Most methodologies are composed of tools and practices that are widely known, such as using object-oriented languages and doing requirements before doing implementation. Many methodologies clearly enumerate the state of the art, but add nothing that is not widely known.

No more methodologies 

Recently, some (like Karl Weigers) have argued for no more methodologies. Methodologies tend to list the contemporary technologies and practices and insist that everyone use them. This advice is obvious for those who work on new systems and have the opportunity to use contemporary technologies and practices. This advice is useless for those who maintain legacy systems and must use legacy tools and must use older technologies and practice, due to circumstance. So, methodologies are not specifically useful, beyond identifying state of the art at a particular time. And methodologies must be updated as technologies and practices evolve.

Counterarguments: The maintainers of legacy systems are entirely free to use legacy methodologies. And every project has to have its ground rules; there is no one set of accepted rules or even one agreed vocabulary in some disciplines. Agreeing upon the rules, the tools and the vocabulary is adopting a methodology. All successful (and many unsuccessful) large teams do so.

Amplification: Methods and methodology should be assigned in a creative way that fits the project. They should not be blindly carried onwards to new projects nor retrofitted to legacy projects without consideration of the cost to bring old code and documentation up to the new standards.

Expectations 

Methodologies in and of themselves are meaningless without clear expectations. Expectations can include terminology, process, procedure, etc. It will not matter how a problem is approached, if the expectation was not managed and/or met, the solution is worthless. That said, methodologies are as much a matter of best practice as they are personal style. In this craft of software engineering, a certain amount of familiarity is necessary of best practices or similar such guidelines, while at the same time remaining flexible to personal styles or approaches to a problem. Then creativity is not stifled in the midst of the science.

Communications and Agreement and Maintenance 

First, there is almost a rule that the more efficient and clever an implementation, the more difficult it will be for an uninitiated programmer to maintain in the absence of a documented method embedded as source comments. But more importantly in terms of wasted time and money, often "everyone does not know" or at least "know" the same thing. Final testing is not the best place to find that out. At its simplest methods and methodology are merely documentation about what the coders are to accomplish and how they interact with other team members. Unfortunately, verbal handshakes or terse emails are the key source of miscommunication in human endeavor. In the absence of a description, the coder of any particular software segment may well have done the wrong job correctly. The same words without sufficient context often mean different things to two different people with different backgrounds. Additionally a code segment may even have restrictions on implementation due to things the coder may not be informed about, such as the form or quality of data coming in or going out or some external consideration like law. Or supervisors may want a way to confirm that the programmer does know the correct way to implement a given business process that is outside their experience.

Examples of methodologies in software engineering:

• Agile Unified Process (AUP)
• Constructionist design methodology (CDM)
• Dynamic Systems Development Method
• Enterprise Unified Process (EUP)
• Extreme Programming (XP) since 1999
• Flowcharting
• ICONIX Process (use case driven object modeling with UML)
• Information Engineering (IE/IEM)
• Jackson Structured Programming
• Metaprogramming, subject of Charles Simonyi's doctoral thesis
• MPMM
• Object Oriented Design using Prototype Methodology (OODPM) since 1994
• Open Unified Process
• Praxis
• Rational Unified Process (RUP)
• Scrum (development)
• Structured programming since 1969
• Structured Systems Analysis and Design Method (SSADM)
• System Development Methodology
• Top-down programming
• Virtual finite state machine (VFSM) since 1990's
• Waterfall model

• Software engineering
• Project management
• List of software engineering topics
• Software development process

• Full list of accredited graduate and undergraduate Project Management Degrees in the US and abroad. (list maintained by the International Project Management Commission)

• Software Methodologies Book Reviews An extensive set of book reviews related to software methodologies and processes