What Is Analysis Continued

From WhatIsAnalysis.

Where I currently stand: I like your addition to the list of definitions, it certainly is different from Groups 0-4 (and it also has the dictionary behind it!). I'm undecided about the argument from Greek, I don't see the link to "breaking up". I think you don't really want to mean that AnalysisIsRefactoring, because of the back-and-forth action in Refactoring.

p.s. What does "the tracing of things to their source, resolving of knowledge into its original principles" mean in the context of the software development process? determine Cheers -- AlistairCockburn

I don't know about Englishmen deliberately plopping Greek words into the English language, but I still think 'analysis' is fundamentally about breaking things up (done well or done poorly), 'decomposition' if you like. In particular it is not composition or synthesis. Like you, I also was uncomfortable with a mental leap in the definition, but in the reverse order. When I initially tried to explain how 'getting to the roots' was a specialization of 'breaking up', I found that it could look more like the opposite: when you look at a vast array of symptoms and trace them back to a few systemic causes, for instance. Funny that we have stuck the prefix 're' in front of 'factoring' to invent that word. 'Analysis' needs the same treatment, it turns out. The only time you analyze something for the first time is when you have apprehended a new concept in your mind and now seek to express it in words. Expression is impossible without 'breaking up', unless the concept already has a one word name. It's not possible to use language (describe things) without analyzing. Hence all this verbiage we bat around is both the subject of (re)analysis and the object of some prior one. According to my strict definition of 'analysis', you cannot analyze my sentence without first synthesizing it into your own apprehension of (hopefully) my intended concept. You can then re-analyze and express, perhaps more powerfully, the original thought.

I'm not competing with your effort to document "what people mean when they say analysis". Rather, I'm trying to analyze software development (or just problem solving thinking process) to find a more satisfactory group of fundamental verbs, with a nice clear separation among their meanings. It's probably a humongous waste of time.

I think there are different species of 'getting to roots' as applied in software development. One instance from requirements analysis goes something like this: Customer: I need a car. Analyst: Why? Customer: To drive to Cleveland. Analyst: Could you fly there? Customer: Sure, why not. Analyst: So you need to get to Cleveland, why? ...

The above exchange is exploring for the essential value sought by the customer but not directly expressable by same.

Problem domain analysis (not looking at the requirement in particular, just the context in which it lurks), might have you analyzing a complex behavior in which some device emits a blip at seemingly random intervals. Let's say the requirement is going to be to respond to each blip with a prepared response that takes time to formulate. So the need to predict the next blip is crucial. Fourier analysis might reveal a harmonic structure to the timings. A program can be designed such that multiple threads each synchronize to a frequency, the runtime composition of which is the complex pattern observed. Getting to the roots of the observed pattern enabled a proactive strategy which would not have been possible otherwise.

In summary, most of what we take in is through already complex expression, whether already analyzed by a conscious being or not, and what we are seeking is a different way of breaking it down to get leverage over it. Therefore, synthesis and analysis are almost always going to occur closely coupled, just as consolidation and separation will occur in refactoring.

One final pitch for why 'resolving to roots' is a form of 'breaking up'. It's in the etymology of the word 'resolve', or just 'solve'. Check it out. cheers, --WaldenMathews

[Additional thoughts 6/14/00]

It seems that the kind of 'analysis' that gets you a more fundamental (powerful) understanding of something is technically a combination of analysis, synthesis and GoodFortune.

Analysis is ubiquitous. It's impossible to write, speak, describe or think without doing it. We seem to have somehow raised it to a priveleged activity in software development. It's worth keeping in mind that there is a continuum of analysis skill. This paragraph is an analysis of a concept that was in my mind.

Analytical thinking is really a process of decomposition, composition, evaluation, decomposition, etc.... The term 'analysis' has taken on a more practical usage to mean all of these activities. That's okay, because it's not very useful to do only one of them. But if we really want to get inside the creative/technical process, then it can be useful to regard analysis as its original meaning "to break [something] up into constituent pieces".

In problem solving, what other kinds of thinking are there besides analytical thinking?

Fortunately for the rest of the world, usually the target of analysis is just a model of the thing we're really interested in. (Literally speaking, to analyze my house is to demolish it!) Models exist in our wetware, and sometimes on more permanent media. Moving the model to a more permanent medium should be technically called 'design'. It corresponds to the archaic meaning of that term (to 'mark out'), and it properly represents an intention to do something (a plan) through demonstration of commitment.

Refactoring, in practice, bears a very close resemblance to the definition we like for 'analysis', being the discovery of origins and roots. It seems to be a combination of 1) break down what you have into small units, 2) discover similarity and thereby discover common origins, 3) restructure based on more powerful separation (factor). The factoring is a species of analysis/synthesis, or just "analysis" if you want.

The point from the above paragraph to take home is this: Take your code refactoring skills and learn to apply them earlier in the development process. The earlier you can successfully do this, the more skilled you become. -- WaldenMathews

I guess I'm woefully naive and ignorant about all this, but for me "Analysis" is the process of describing *what* a particular solution is and "Design" is the process of describing *how* an analysis is to be built.

When I decide to think about a trading system as an assembly of some brokers, some managers, some requests, some replies, some stacks, some queues, and some repositories, and then start to draw the result, I describe what I'm doing as "analysis".

When I start talking about classes, methods, instance variables, packages, interfaces, files, and so on, I describe what I'm doing as "design".

When I start typing Java at a development environment, I describe what I'm doing as "implementation".

I usually do all three at the same time, and prefer environments that support each simultaneously.

-- TomStambaugh

What guides you to characterize a queue as a "what" and a file as a "how"? thanks --WaldenMathews

I would suggest that analysis is the set of decisions made prior to the selection of a design team. Things like feasibility, architecture, and project size. You are addressing questions like the following:

  How many physical machines are needed and what communications links are between them?
  What existing systems and software need to be used?
  What existing systems and software could be used?
  What off the shelf systems and software could be used?
  How should the project be partitioned across machines?
  What programming skills and languages are required for the development team?
  How many people need to be assigned to the project for delivery within a specific time frame?

These questions seem more for ProjectManagementAnalysis? than SoftwareSystemAnalysis?

Most of these decisions are made prior to the selection of a design team. It certainly is possible to make some or all of these decisions after the selection of the design team and different projects may order things differently. Some decisions, however, do need to be made before you can write any code.

-- WayneMack