Methodology (software engineering)
|
|
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 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.
| Contents |
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.
- Hybrid
- 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. Programmers have resisted most rigid methodologies.
- 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 the rules, the tools and the vocabulary is adopting a methodology. All successful (and many unsuccessful) large teams do so.
- Expectations
- Methodologies in and of themselves are meaningless without clear expectations. Expectations can include terminology, process, procedure, etc. It won't matter how a problem is approached, if the expectation wasn't 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.
Examples
Examples of methodologies in software engineering:
- Flowcharting
- Structured programming since 1969
- Structured Systems Analysis and Design Methodology (SSADM)
- Top-down programming
- Jackson Structured Programming
- Dynamic Systems Development Method
- Object-Oriented Programming (OOP)
- Rational Unified Process (RUP)
- Extreme Programming since 1999
- Virtual finite state machine (VFSM) since 1990's