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 the
software development process; this team (sometimes just a single person)
is responsible for interacting with the software vendor, approving key
deliverables, providing feedback on the progress of the project and
making course corrections where required. Consequently, most of the
features and capabilities that make it into the final release are based
on the (largely
subjective) decisions of a very small group of people. These decisions
may not be accurate, or even representative of the application's user
base; however, in the absence of more data, the development team has to
take them into account when designing the software.
Now, once the customer's software has been released and installed to the
target environment, it will come under the scrutiny of a much larger
number of users, many of whom will have suggestions for improvement. If
the customer is interested in keeping his or her users happy, these
suggestions will need to be taken seriously, and implemented in future
versions of the software wherever possible. Additionally, as the
software is used on a regular basis in a live environment, bugs hitherto
undiscovered by the testing team will surface, and will need to be
rectified on a priority basis.
Since the customer already has a pre-existing relationship with the
original developers of the software, and since those developers are
intimately familiar with the inner mechanics of the application, it
makes sense for these change requests and bug fixes to come back to the
original development team for implementation. Thus begins a software
maintenance cycle, in which released software is upgraded to account for
changes, improvements and bugs on a periodic basis.
The initial software development effort is always a focused one, which
takes place on a fixed schedule over a specified period of time. Change
requests and bug notifications, however, take place on an ongoing basis
after the software has been delivered to the customer, and tend to occur
over a much longer time period than the initial development effort.
Thus, the post-release phase of a software project can continue on for
weeks and months after the project has officially concluded, and can
even provide the vendor with an additional revenue stream in the form of
charges for implementing changes.
