Development Cycles
  Home arrow Development Cycles arrow Page 2 - Practising Best Practises in Your Software...
Dev Articles Forums 
ADO.NET  
Apache  
ASP  
ASP.NET  
C#  
C++  
ColdFusion  
COM/COM+  
Delphi-Kylix  
Design Usability  
Development Cycles  
DHTML  
Embedded Tools  
Flash  
Graphic Design  
HTML  
IIS  
Interviews  
Java  
JavaScript  
MySQL  
Oracle  
Photoshop  
PHP  
Reviews  
Ruby-on-Rails  
SQL  
SQL Server  
Style Sheets  
VB.Net  
Visual Basic  
Web Authoring  
Web Services  
Web Standards  
XML  
Mobile Linux 
App Generation ROI 
IBM® developerWorks 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid 
Request Media Kit
Contact Us 
Site Map 
Privacy Policy 
Support 
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
DEVELOPMENT CYCLES

Practising Best Practises in Your Software Development Process
By: Simon White
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: 4 stars4 stars4 stars4 stars4 stars / 38
    2003-10-28

    Table of Contents:
  • Practising Best Practises in Your Software Development Process
  • What is a Software Development Process?
  • Why You Need a Process
  • Why a Learning Organisation is Not Enough
  • The Knowing-Doing Gap
  • Bridging the Knowing-Doing Gap in Software Development
  • Conclusion

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      Del.ici.ous Digg
      Blink Simpy
      Google Spurl
      Y! MyWeb Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article
     
     
    ADVERTISEMENT


    Practising Best Practises in Your Software Development Process - What is a Software Development Process?


    (Page 2 of 7 )

    It cannot be stated too often that if you are developing software, you need a process. By process, I mean a guideline description of a repeatable procedure that both describes and prescribes the way that your organisation develops software. It describes the process because the process that works best for your organisation is different to the process that works best for another organisation. So the process says something about how your organisation works. It prescribes the way that your organisation develops software because it is the process that will be applied to the development of future projects

    It is not sufficient just to say that the process is simply:

    Requirements->
      Design->
        Implementation->
          Testing->
            Documentation->
              Maintenance

    as this leaves far too many questions open to interpretation by customers, managers, and developers alike. For example, what kinds of requirements are gathered in the first phase? How detailed is this analysis? Does the design phase wait until the requirements phase is completed before it starts? How is the usability of the end-product ensured? How is the assessment of usability represented in the phases given above?

    Of course, every organisation will have its own answers to these and other questions. The answers to such questions should be recorded in some sort of a document; say a process manual. Then, if a potential customer asks the (almost inevitable) question "How do you develop software?", you can then demonstrate not only that you have thought about it, but that you have a well documented, mature process that works for you.

    Different organisations have different requirements for their processes, so there is not one "correct" process. That's why, in this document, I can't tell you what your process should be. In a sense, it doesn't really matter what your process is, as long as you are confident that it works for you. To be more precise, all the stakeholders in the process need to be confident that it will help them to achieve their goals. In bespoke development projects, the customer needs to respect that this process is the one that best suits your organisation, people, and products. The managers in your organisation need to believe that it works for them, so that they continually refer to the process and do not allow the project to be diverted. The developers also need to believe in the process so that they can work together as a team, respecting the boundaries between different parts of the process and the implications of the process on their roles in the overall development.

    A process can be lightweight to offer flexibility and minimal overhead to a small development team, or it can be more heavyweight to provide firmer expectations of the way that the project will be run.

    More Development Cycles Articles
    More By Simon White


     

    DEVELOPMENT CYCLES ARTICLES

    - Division of Large Numbers
    - Branch and Bound Algorithm Technique
    - Dynamic Programming Algorithm Technique
    - Genetic Algorithm Techniques
    - Greedy Strategy as an Algorithm Technique
    - Divide and Conquer Algorithm Technique
    - The Backtracking Algorithm Technique
    - More Pattern Matching Algorithms: B-M
    - Pattern Matching Algorithms Demystified: KMP
    - Coding Standards
    - A Peek into the Future: Transactional Memory
    - Learning About the Graph Construct using Gam...
    - Learning About the Graph Construct using Gam...
    - Learning About the Graph Construct using Gam...
    - How to Strike a Match







    © 2003-2010 by Developer Shed. All rights reserved. DS Cluster 1 Hosted by Hostway
    For more Enterprise Application Development news, visit eWeek