| Software Engineering Methodology |
Article Index for Software Engineering |
Website Links For Methodology |
Information AboutSoftware Engineering Methodology |
|
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 Discipline s, 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. METHODOLOGY VERSUS METHOD 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). 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 System s and must use Legacy Tool s 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 Examples of methodologies in Software Engineering :
SEE ALSO
EXTERNAL LINKS
|
|
|