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 methodologies span many disciplines, including project management, analysis, specification, design, coding, Software testing, and quality assurance. All of the methodolgies guiding this field are collations of all of these disciplines.

=Methodology versus Method=

There is a discussion in . They are widely used as synonyms, although many authors believe to be important to draw a difference between the two.

In Software Engineering, in particular, the discussion continues. One could argue that a method (software engineering) is a recipe, a series of steps, to build software, where a methodology is a is a codified set of recommended practices, sometimes accompanied by training materials, formal educational programs, worksheets, and diagramming tools. In this way, a method (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 of methods, but have fewer methodologies. We could say that there are two main stream types of methodologies: Structured Methodology (SSADM and others), which encompass many methods and software processes; and Object Oriented Methodology (OOA/OOD and others) .

=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

=See also=

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