- an attempt at refactoring WhatIsAnalysis
into a shorter, er... synthesis. ;)
Someone tells me you can't write programs without analysis, but I don't know what it is. Help me out - WhatIsAnalysis
Analysis is a process explicitly identified in some
models of software developments. Let's start with some models, or partial models, showing when Analysis occurs (or doesn't occur, in one case) in relation to other activities.
Note that none
of these models was explicitly intended as a "phasist" model - e.g. all of requirements gathering occurs before all of design activity. Indeed, TomStambaugh
remarks: I usually do all at the same time, and prefer environments that support each simultaneously.
After requirements, EVERYTHING is design.
Gather the user requirements
, that is, understand, the requirements. Design
a solution. Implement
defines the problem in the client's terms. Analysis
defines the the problem domain in engineering terms. Design
defines a solution to the problem in architectural terms.
Analysis is whatever process you use to know what UserStories
Analysis is a conceptual high level model of an application in the business domain. It can be explained to the customer in terminology they easily understand. Design is a detailed lower level model of an application suitable only for communication between people familiar with software development.
When I decide to think about a trading system as an assembly of some brokers, some managers, [etc.] 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
When I'm looking at the problems and the situation in which they occurs I'm doing some analysis
. Typically I'm trying to find out about the user's world and what is good and bad in that world. The world includes Purposes, Qualities, Ideas about the RealWorld
, the current way of doing things, and the techniques, tools, technology I can use to change things.
When I'm working on the system I'm doing some implementation
When I'm working on the project and doing neither of the above I'm
All three are executing in parallel (threads?) and my conciousness switches between them. They are connected so that a change in the situation triggers
a little analysis, triggering some design, and then some implementation. Often the changes I make (implementation
) change the situation so drastically that I've got new problems to fix...
A classification of intended meanings
I'll give you my personal take on "analysis", which has stood me in good stead for some years now. "Analysis" is the study of something that already exists, to answer some questions about it (implications: something already exists to study; you have questions to ask). That means, the development phase many software people call "analysis" is not analysis in my mind - in the sense I just mentioned.
There are requirements, and there is design. That's all there is. (e.g., programming language can be a requirement, or, it can be a design choice.) At this point, analysis fans go to one of three places:
- Group 1, Analysis as refining requirements or our understanding thereof
- Group 2, Analysis as initial design
- Group 3, Analysis as implementation-independent design
The latter is the only one I really disagree with, because I don't believe in such a thing, and especially don't trust giving it a truth-implying label.
. I fished the above models from the original pages as a potentially useful guide in refactoring them. I think I might be on to a good thing, in that there would appear to be "conventional" models with Analysis occurring before Design (and, where the model is complete, after Requirements); and the "oddbal" models: Alistair's "There isn't a thing properly termed Analysis, except in the vernacular sense of 'deeper understanding' of some other activity", and Ron's "Analysis occurs before everything else." I might try bringing in comments one by one from the two original pages on the basis of where they fit; and abandon the hypothesis if that turns out to be a ShoeHorn
I'd suggest keeping some of the other comments like JimCoplien's. I'd help out but I have TooMuchToDo lately. -- JasonYip