Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Software Process Documentation

 
harii haran
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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...
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Lasse's book recommendations are really good. Besides that, for small, colocated teams I like eXtreme Programming: http://www.extremeprogramming.org/
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
harii haran
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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):
  • Waterfall:

  • 111111111111111F222222222222222F333333333333333F444444444444444F555555555555555F...
  • Evolutionary:

  • 12345F12345F12345F12345F12345F12345F12345F12345F12345F12345F12345F12345F12345F...

    [ January 23, 2004: Message edited by: Lasse Koskela ]
     
    Lasse Koskela
    author
    Sheriff
    Posts: 11962
    5
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    ...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...).
     
    Scott Ambler
    author
    Ranch Hand
    Posts: 608
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    If you're looking for modeling and documentation related material, see www.agilemodeling.com
    If you're looking for data-oriented or enterprise-oriented material, see www.agiledata.org
    If you're looking for Unified Process material, see www.enterpriseunifiedprocess.com.
    - Scott
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic