Practices
  Home arrow Practices arrow Page 2 - The Art Of Software Development (part ...
Dev Shed Forums 
Administration  
AJAX  
Apache  
BrainDump  
DHTML  
Flash  
Java  
JavaScript  
Multimedia  
MySQL  
Oracle  
Perl  
PHP  
Practices  
Python  
Reviews  
Security  
Style-Sheets  
Web Services  
XML  
Zend  
Zope  
Forums Sitemap 
IBM® developerWorks 
Sun Developer Network 
Dedicated Servers 
E-Commerce Hosting 
Linux Web Hosting 
Managed Hosting 
Small Business Hosting 
Actuate Whitepapers 
VeriSign Whitepapers 
VPS Hosting 
Weekly Newsletter

 
Developer Updates  
Free Website Content 
SunQuest
 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? 
PRACTICES

The Art Of Software Development (part 5): Adding Value
By: Vikram Vaswani, (c) Melonfire
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: 5 stars5 stars5 stars5 stars5 stars / 2
    2002-10-15

    Table of Contents:
  • The Art Of Software Development (part 5): Adding Value
  • The Real World
  • Changing Things Around
  • Playing The Numbers
  • Going The Whole Nine Yards
  • Parting Shots

  • 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

    AT&T devCentral & BlackBerry(r) Webcast Series: BlackBerry and GPS -Build Location Awareness into your BlackBerry Applications, July 10th -1:00PM EST. Register Today!

    The Art Of Software Development (part 5): Adding Value - The Real World


    (Page 2 of 6 )

    Most often, the customer is represented by a small team during thesoftware development process; this team (sometimes just a single person)is responsible for interacting with the software vendor, approving keydeliverables, providing feedback on the progress of the project andmaking course corrections where required. Consequently, most of thefeatures and capabilities that make it into the final release are basedon the (largelysubjective) decisions of a very small group of people. These decisionsmay not be accurate, or even representative of the application's userbase; however, in the absence of more data, the development team has totake them into account when designing the software.

    Now, once the customer's software has been released and installed to thetarget environment, it will come under the scrutiny of a much largernumber of users, many of whom will have suggestions for improvement. Ifthe customer is interested in keeping his or her users happy, thesesuggestions will need to be taken seriously, and implemented in futureversions of the software wherever possible. Additionally, as thesoftware is used on a regular basis in a live environment, bugs hithertoundiscovered by the testing team will surface, and will need to berectified on a priority basis.

    Since the customer already has a pre-existing relationship with theoriginal developers of the software, and since those developers areintimately familiar with the inner mechanics of the application, itmakes sense for these change requests and bug fixes to come back to theoriginal development team for implementation. Thus begins a softwaremaintenance cycle, in which released software is upgraded to account forchanges, improvements and bugs on a periodic basis.

    The initial software development effort is always a focused one, whichtakes place on a fixed schedule over a specified period of time. Changerequests and bug notifications, however, take place on an ongoing basisafter the software has been delivered to the customer, and tend to occurover a much longer time period than the initial development effort.Thus, the post-release phase of a software project can continue on forweeks and months after the project has officially concluded, and caneven provide the vendor with an additional revenue stream in the form ofcharges for implementing changes.

    More Practices Articles
    More By Vikram Vaswani, (c) Melonfire


     

       

    PRACTICES ARTICLES

    - Finishing the System`s Outlines
    - The System in So Many Words
    - Basic Data Types and Calculations
    - What`s the Address? Pointers
    - Design with ArgoUML
    - Pragmatic Guidelines: Diagrams That Work
    - Five-Step UML: OOAD for Short Attention Span...
    - Five-Step UML: OOAD for Short Attention Span...
    - Introducing UML: Object-Oriented Analysis an...
    - Class and Object Diagrams
    - Class Relationships
    - Classes
    - Basic Ideas
    - Choosing the Right Team
    - Trees

    IBM developerWorks




    © 2003-2008 by Developer Shed. All rights reserved. DS Cluster 5 hosted by Hostway