Methodology (software engineering)

From Wikipedia, the free encyclopedia

This does not cite its references or sources.
Please help improve this article by introducing appropriate citations. (help, get involved!) This article has been tagged since June 2006.

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.

1 Methodology versus method
2 Criticisms
3 Examples
4 See also
5 External links

[edit] Methodology versus method

There is a discussion in science in general about these two words: method and methodology. They are widely used as synonyms, although many authors believe it to be important to draw a difference between the two.

Some authors use method as a recipe and methodology as the studying of one or several methods. That is because the authors fail to consider the etymology of the words. Both words are derived from Greek, "methodos" = following after, pursuit and "ology" = the study of.

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, where 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).

[edit] Criticisms

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.