This is a sample of how a “classic” development works. I’ve not learnt enough about “agile” methods to know how much this process can be upgraded.
Let’s say it works, and it’s enough to provide a sight of the different roles a developer can play in a development.
Needs or requirements
Someday the user says “I’m hungry”.
error: every “documented step” of a project must be short, but specific. “I’m hungry”, “I want to eat” and phrases like these ones just lead to disaster. Let’s suppose the analyst asks for a tool that delivers food to the user. The team works until delivers the tool. It’s a robot that leaves home, seeks for a restaurant, buys a three dishes menu and returns home with it. The user will say “I just wanted a bit of something, I don’t need a three dishes menu, and it exceeds my budget”.
The Analysis (old “functional analysis”)
When a project begins, the taks of the analyst is to determine in a certain concrete and clear way the needs of the user. In this case, it starts with a series of questions like “how much hungry you are?”, “sweet or salty?”, “cheap or expensive?”. This information exchange leads to the analysis: “we need chocolate”.
The Design (old “organic analysis”)
From the analysis, the designer builds on paper a set of items that allow the team to accomplish its goal. A good design leads to an efficient product (low resource consumption, easy of maintin, and so): “go to the shop and buy chocolate”.
The Program (old “program”)
It’s the final result, the most expected thing ever, that will allow the user to satisfy his need.
We need to be sure the program will fullfill the user needs, and that it will do it the best way possible. To do it, we will run a set (an undefined number of times) the tests.
In a wonderful world, the first set of tests will be done with the help of a “test data set”: a basic set of data and instructions that allow the programmer to check that the program does (or seems to do) satisfy the user needs. If the test data set says “it must provide chocolate”, and the tool retrieves bananas, the programmer must revise and fix (or re-do) anything needed until the program provides chocolate.
Once these first tests are done, the team will perform a deeper serie of tests, trying to break the tool showing its feeblenesses. Maybe the tool delivered chocolate because it’s the nearest product, what if we change the shop’s distribution? Maybe it will provide tomatos (or worse, tomatoes).
The Development Cylce
During my life as a developer, when lucky, the construction process has been more or less the described one, and always focusing in the production and delivery of the entire final product. But it’s not mandatory to do it that way. We can split the development in smaller parts, and repeat the workflow for each part. We can even, cycle the workflow (create, test, the user asks for improvements, rinse and repeat) for each part, been able to deliver the most complete tool possible.
A project is around 90% of paper and 10% of code. BUT the paper means “design” and not “documentation”. We’ll discuss it later.