Software Process Documentation

Hi, I have recently joined a small software company, where they haven't been following usual software process, about which I have been reading through text books. I have made a suggestion that atleast we should write what we want to accomplish the following and how we should do and also we are noting down the time that it takes to complete the task. (in word file ) Is there any website that would give some insight on how we should do it or books to refer or your personal experiences.. thanks, harii

Are there any particular symptoms caused by the lack of an explicit process? I'm afraid that this "usual process" you referred to was a waterfall (first design, then code, then test)? I guess most university text books still today on software engineering assume a waterfall process but practically every authority has been saying how waterfall is broken for the past 20 years. Even DoD dropped the preference for a waterfall process (and replaced it with a preference to iterative and incremental) from their policies soon after the original waterfall paper was published. Too bad nobody noticed that anymore at that stage when the devil was already loose My suggestion would be to obtain a copy of Alistair Cockburn's "Agile Software Development" or Boehm & Turner's Balancing Agility and Discipline and read it/them from cover to cover before starting to define a process for your company. The smaller company you are, the more damage can exaggerated documentation do to your projects...

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus

Harii, that's a great kick-off from the guys. Please keep us posted as you read, study and implement something. That gang here loves to argue the fine points so you will surely never go away hungry

A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi

harii haran

Greenhorn

Posts: 11

posted 14 years ago

Thanks a lot for your replies. I only know about waterfall model (spec, design, code, test, maintain).. I didn't know that there are other models too.. can you explain me little more about how the process goes other than waterfall model.. I will try to read those books. thanks again.

Lasse Koskela

author
Sheriff

Posts: 11962

5

posted 14 years ago

Originally posted by harii haran: can you explain me little more about how the process goes other than waterfall model.

The fundamental idea is to shorten the feedback loop from 12 months to 12 days (just an example, of course) and thus improve your chances of success. The waterfall is still there, but split into small enough pieces to allow that feedback. In other words (using numbers 1..5 to represent activities such as requirements gathering, design, coding, testing, etc. and "F" for an opportunity for getting feedback):

...and the order of "12345" may not be exactly that all the time. For example, there's a very useful technique called Test-Driven Development, in which you write a test first, and only then write the application code to satisfy that test (and then go back to write another test, write code, test, code...).