Embedded Files
Using Hermeneutics in Systems Analysis
Hermeneutics is the “scholarly” way of analyzing a text, and more recently of analyzing any mode of communication. In computer systems development there is little said about hermeneutics or the use of hermeneutics in the system analysis process. I believe that hermeneutics (or hermeneutic concerns) need to be dealt with in any such analysis (say, of the documents of the system inquiry). The textbooks on the structured method rarely mention hermeneutics. Agile textbooks, there are a few, are too busy describing the details of the particular methodology to mention much about hermeneutics either.
I have had extensive training in hermeneutics, and extensive experience with both structured and agile systems methods, I feel it is time someone ventured into the use of hermeneutics in systems analysis and design in a detailed way. From my perspective systems analysis and design by any method is using some kind of hermeneutics. Hermeneutics is just a type of thing you do as you are analyzing text, or any communication. Calling it hermeneutics is just a way of formalizing what you are doing.
My plan in this discussion is to is to define modern textual interpretation or hermeneutics in general. Then I will define structured hermeneutics and post-structural hermeneutics. At that point I will use that discussion as a basis for describing hermeneutics and structured software design methodologies. I will then continue the discussion into hermeneutics and agile systems design methodologies. I will cover those issues as I see them today. I am hopeful of convincing my audience that hermeneutics and particularly knowledge of how to use hermeneutics will be of advantage when you are doing systems analysis and design.
Hermeneutics
Hermeneutics is formalize interpretation of a text. More recently it includes not just text but all methods of communication. This includes any communications of any kind that are related enough to a problem to be analyze meaningfully through formalized analysis.
The first principle of hermeneutics is that the meaning of the text is related to the context of the text. The problem is that we need to use context in the interpretation is that a text can have many contexts. Note that In different contexts the meaning of a text would be different.
To interpret a text (or communication) you first need to clarify the context. But in most communications the context is not fixed. Context often changes between paragraphs (that is why we change paragraphs). Context can change between sentences.
Determining Context
In hermeneutics the form of the text is used to determine where there are context breaks in the text. Most context breaks become quite obvious when you are looking for them. The context breaks are recognized in the fact that the form of separate statements demonstrates that they refer to obviously different issues. The goals of the text, and the assumptions of the text are guides to drawing conclusions about context and context changes.
In separating text sections by context the goal is to find the essential basic units, or true atoms of the text. In structured computer systems design these atoms must be central to the division of the system into functionality. The very division into context reveals the characteristics of procedural relationship that can demonstrate data relationships, where data is involved in the process. In normal hermeneutics functionality has little to do with the process since most communication is not based on function but on clarification.
Structured Hermeneutics
Structured hermeneutics is a conception of Bultmann and others. The idea is to understand the meaning of a word in a text from tracing the word to its origin or first use. The form of the text is used to determine where there are context breaks in the text. The context breaks, again, should be quite obvious when you are looking for them. The context breaks are recognized in the fact that the form of separate statements demonstrates that they come from obviously different sources. Style, person, or assumed context are guides to this conclusion.
Some late structuralist hermeneutics considered that the context could change (and from their perspective did) change from word to word. In my view this was both awkward and unrealistic. Their issue here was atomicity, and many structured schools’ believed that word meanings were (had to be) immutable and atomic. Word meanings could not change (over time or a text) and were specific to the expression itself.
Once the pericopes were defined the process continued by examining earlier writings that use this same expression. The goal is to trace back in history to find the original (first use) of the text. The structured concept of meaning is that the meaning of a word or text is immutable and atomic. That was a defining characteristic of structural thought. So the first use is the ultimate definition of the word or text. Further use (after first use) is then stuck with that first meaning regardless of time (thousands of years) or any other context associated with the text in between. [Wittgenstein: The meaning of a word is in its use].
The point of this analysis is to place a concept of history onto the documents involved. Understanding history and the development of thought through history is a part of hermeneutic analysis. This process was a form of what we now call archeology of texts. But the post-structuralist version emphasizes the changes in meaning of words and concepts through the archeological process.
Understanding the surrounding culture and politic is also needed to understand a particular text. A text written in 1620 would be looked at differently than one written in 1920. Considering all the variables involved in the development of context is an important part of hermeneutics. The question is: “What was the author thinking as they wrote this?” There is also a need to limit the scope of the inquiry. You need to define the context in a way that allows you to develop meaningful results in a reasonable time.
Hermeneutics in Structured System Design
Hermeneutics in structured design is stylized through the use of Data Flow Diagrams. The basic rules for doing the DFDs have to do with the rules for cohesion and coupling. Ultimately you picture (using the Data Flow Diagram) the functionality by recognizing functional sub-processes of the overall process (or as close to functions as possible).Then each sub-process of the first overall process is treated the same way, so the system is broken down into sub-processes based on function. This process continues until a process cannot be subdivided. That particular process is then declared atomic. Any non-atomic processes continue to be processed until all are declared atomic.
During the analysis you need to define data flows that are into and out of the processes you define. That is the meaning of Data Flow Diagram. This provides for the data context of the process. The functional context is aided by making the description used for all processes as functional as possible. The best descriptions look like code so they are called pseudocode.
So we have the functional context and the data context for our hermeneutics. There is a set of descriptions, defined by Yourdon, of how functional a process is (from least functional to most functional): coincidental, logical, temporal, procedural, communicational, sequential, functional. Most older systems analysis text list these descriptions and give details on what they mean and how they are rated for functionality. Functional is the best context to use to design with. When we do systems analysis this way we were not really able to consider other contexts as in normal hermeneutics. That forces you to develop “functional” (and only functional) code for the system.
Post-Structuralist Hermeneutics
Post -structuralism contains a large number of different authors who have many different ideas and attitudes. The point is to escape from the difficulties of structuralism without destroying the entire literate accumulation of ideas. Post-structuralist hermeneutics questions what knowledge is and how it is established. To structuralists knowledge is contained in the language and in particularly in the structure of language.
In my view, as a post-structuralist, knowledge is an aggregate of the details of the narrative. To the extent that the structure forces a specific aggregation on the system, knowledge is confined and distorted; particularly if a the structure is strongly enforced. One of the problems in the standard structural systems methodology is that function and functional aggregation was the only possibility; which was enforce at every stage of the process.
Post-structuralist hermeneutics is based on deconstruction. That is exactly what systems analysis should be. We deconstruct the problem space so we can rebuild it in our new system space.
There is also the inclination in post-structuralism that the problem space is not just the texts and discourse of the system being analyzed. All parts of the system are a part of the “text” of the problem to be analyzed. this should be the standard in systems analysis.
Ultimately post-structuralism realizes that we cannot have truth (meaning absolute truth), as an abstract. We can have meaning but not final meaning as a final meaning would be a truth claim. Meaning is always in the abstract. In particular, deconstruction is meant to reveal this problem with truth, and requires a reconstruction of the system that recognizes that change (which is one key issue of the failure of any truth claim) is a necessary and a never ending part of every system.
Hermeneutics in Agile Systems
The ability, of agile systems development, to change as new information arises is more akin to an interactionist viewpoint. Here the activity is not to obtain a truth (the immutable requirements), but to seek solutions that solve the problem the user has. The interaction with the users holds the meaning.
The effort is not to create a structure that is the immutable truth, but to understand the sum of all the interactions that are relevant. That can only be done in a Just in Time basis. Meaning, or the meaning of the system, is created in the interaction with all the stakeholders of the system. Development is done incrementally on the next process in the system which is the JIT process.
Agile analysis rejects the structured method of requirements analysis but does not reject the systems approach. That is, agile analysis recognizes the fact that the system is more than the sum of the parts, but that is why systems solutions require an iterative analysis.
The biggest problem with agile methodology is the minimization of documentation and the difficulty of establishing clear contractual obligations before the work begins.
Agile Systems Methods are Post-Structuralist
The aim of post-structuralism is to reveal the weaknesses and failures of structural methodologies. Agile is then definitely post-structuralist by definition.
Using linguistic concepts from a post-structuralist viewpoint expands the available tools of system development. The deconstruction of post-structuralism contributes to a broadly, language-based, approach to systems development methodology. The solutions are obtained through deconstructing the system structure. This deconstruction is done through a discourse with the users and stakeholders of the system. In this discourse the system itself is present as a prototype during the process. The refactoring process is also a discourse between developers and the code of the system. This in itself is deconstruction.
The definition of agile methodology, is expressed in the Agile Manifesto: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan. These are in line with post-structuralist ideas. This list is a deconstruction of the structured methodology. The solutions from such methodology would not necessarily or even likely to be structured in character.
The agile methodologies are definitely post-structuralist. Agile methodologies is presently the most practical (pragmatic) use for post-structuralist thought.
Dr. Jerome Heath
Google Books: Hermeneutics in Agile System Development
#Hermeneutics, #Agile, #AgileDevelopment, #PostStructuralist, #StructuredSystemsDesign, #Context, #Pragmatic, #AgileSystems, #AgileManifesto.
Seven Covers
Page updated
Google Sites
Report abuse