• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Software Process Documentation

 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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...
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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/
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Posts: 11962
    5
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • 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...).
     
    author
    Posts: 608
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • 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
     
    Don't get me started about those stupid light bulbs.
    reply
      Bookmark Topic Watch Topic
    • New Topic