Methodology (software engineering)
In software engineering and project management, a methodology is a codified set of recommended practices, sometimes accompanied by training materials, formal educational programs, worksheets, and diagramming tools.
Software engineering methods span many disciplines, including
project management, analysis, specification, design, coding, testing, and quality assurance. All of the methods guiding this field are collations of all of these disciplines.
Examples
Examples of methodologies in software engineering and project management include
(In approximate order of oldest first to latest last):
Thick versus thin
Software design methods can be informally classified into thick and thin.
- Thick
- Thick methods include a large amount of formal process paperwork and documentation. Well-known thick methods include Cleanroom, ISO 9000, and CMM.
- Rational Unified Process (RUP) is a hybrid of thick and thin method, as it is an iterative process with feedback points which are taken by agreement between developer and client. Thus, if the feedback points are weekly, RUP is thin; if the feedback points are yearly, the developers can even revert to the waterfall model.
- Thin
- Thin methods eschew formal process paperwork and documentation. Well-known thin methodologies include Extreme Programming (XP) and other agile software development methodologies.
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.
- 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.
- 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 Software engineering
