WorkInProgress - an attempt at refactoring WhatIsAnalysis and WhatIsAnalysisContinued into a shorter, er... synthesis. ;)
BillTrost asked: 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.
AlistairCockburn's model
After requirements, EVERYTHING is design.
JeffGrigg's model
Gather the user requirements. Analyze, that is, understand, the requirements. Design a solution. Implement it.
PeterMerel's model
Requirements 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.
RonJeffries's model
Analysis is whatever process you use to know what UserStories to write.
GregVaughn's model
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.
TomStambaugh's model
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.
DickBotting's model Circa 1990
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 doing design.
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:
[DeleteMe. 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