My Database Managment System Project

Blogs to track my database managment system project. The main target of this project is learning. I am not planning to compete with SQL server - At least not now!

My Photo
Name:
Location: Cairo, Egypt

I am an Eyptian developer @ optimize software company.

Friday, June 10, 2005

Requirements: The stage with the long lasting effect

If I was asked to summarize the science of software engineering in one statement, it would be this:
Software is not just writing code.

In small projects, you can only just write code, without an architectural design, without formal requirements, etc. But as the size of the project increases, those other things are a must.

As a developer, I feel a need to bypass this boring stage which reminds me of the governmental routine work. A lot of developers and specially managers who don't understand the importance of requirements specification may override this stage. So if you spend some time in requirements specification, you may have your manager screaming at you: "you have been working for 2 weeks and you didn't write any code?"

This phenomenon is called WISCA syndrome, which is a short form for "Why Isn't Sam Coding Anything?” and as the word tells, if this phenomenon happens, it is considered a disease in the company.

As a fact, as the size of the project increases, the stage of writing code becomes smaller compared to all stages of the project.

For example, in small sized projects as I mentioned before, the stage of code writing takes 100% of the project. For medium sized projects, it may take 60% of the project. For very big projects and systems, it may take much less than this.

In his excellent book Mythical Man-Month, Fred Brooks (on of the designers of the OS/360 operating system of IBM) says that in very big projects such as building operating systems, the estimated work becomes like this:

1/3 planning (requirements specification, design, etc).
1/6 Coding.
1/4 Module testing.
1/4 System testing.

He also says that on such big projects, the developer can only write 1000 lines of debugged code yearly.

Well, I agree with the principle, but I don't agree with this 1000 lines. Note that in the past when Fred wrote that operating system, the coding and debugging tools were not advanced as today's tools.

I consider my project as a very large project, because my previous knowledge about it are small and the number of developers working on it is small too ( I am working on this project alone).So I expect to spend 1/3 of the project time in the requirements and design stages.

In his book "Code Complete", Steve McConnell says that if fixing a requirements error discovered in the requirements stage costs 1$, it may cost 3 dollars if it was discovered in the architectural design stage, 5-10$ if discovered in the coding stage, 10$ if discovered in the system test stage, 10-100$ if discovered in the post release stage.

This means that the cost of error fixing grows exponentially through the program stages, it doesn't grow linearly, and the effect of the requirements specification stage will have an effect on all the project stages.

I started my database project with the process of requirements specification: what are the features and aspects of advanced database engines? And which of these can I implement in my project?

I wanted to know in detail the features that I am not going to implement, to put a design that may allow for adding them in the future. This is a starting point in the design process (which I didn't start yet): define what is going to change and what is not.

So I start my requirements document by writing a list of points that need to be studied. Of course as work on the project, this list will expand. These are the points that I have ( until now):
1-Security.
2-The query language I am going to use.
3-File system.
4- Maximum size of the database.
5-processes and threads and their responsibilities.
6-Query optimizer.
7-Cached execution path.
8-Triggers.
9-Views.
10-Stored procedures.
11-Cursors.
12-Constraints.
13-Table formats.
14-replication.
15-Data types.
16-Transactions.
17- The memory model I am going to use.

Of course I am not going to implement all these points (or even half of them!) , but as I said before, I want at least to put a design that can be modified to support them in the future.

Next time (God willing); I will talk about Security, so keep up with me.

0 Comments:

Post a Comment

<< Home