POS 370
Jeremy Vigil
Mike Bates
Mike Holton
Nick Santilli
Programming concepts
Week 2
Instructor
John Bauer
May 8th 2002
Change management is very
useful. It will help to correct errors
and resolve conflict. No matter how
much error checking is done something will need to be corrected after the final
release. A process is needed to adapt
to changes in the business as well as changes in the employees. More technology will be available so change
management will organize the implementation of future technologies.
With out software
maintenance your system will grind to a halt.
Everyday use will find problems and create new ones. Things like bandwidth and latency are best
tested in a real world scenario.
Procedures need to be put in place to fix the everyday headaches.
We all like to believe we
are perfect but because we are not Software maintenance and change management
are necessary. Our goal will be to hope
for the best but plan for the worst. These
procedures will help to enhance effientcy, which will help the bottom
line. We also want to help reduce the
frustration from buggy software. We
will make cosmetic changes but real problems like outages will take
priority. These procedures will also be
open to change like the software itself
The
organization’s software maintenance program will have three stakeholders, each
with a different level of involvement.
These three groups are the tester, user, and developer. The role of the tester is to identify
problems or bugs with the software before the organization releases a final
version of the product for use by employees.
Only in a perfect world will a test team be able to find every problem
within a piece of software so it is up to the individual users to find any
problems that slip through the vigorous testing and quality control
inspections. These problems usually
equate to potential enhancements to the software but there are the occasional
bugs that require a patch. The third
group within the organization is the developer. The development team is responsible for implementing those bug
fixes and enhancements that are requested by the users and testers.
The
process for change requests will be submitted to the development team by a
locally generated form called a Software Maintenance Work Order to be filled
out by the individual or agency that discovers the problem. The work order will also be used to submit
possible enhancements or bells and whistles to the software. This form can be emailed of faxed to the
development team.
There
will be three levels of classifications for problems found in the
software. Level 1 will be cosmetic
problems and will have a one week turnaround upon receiving the assignment. Level 2 will be major problems to the
software that cause complications but not complete shutdown or an outage. The turnaround time for this category will
be 2-3 days depending on the severity.
Finally, Level 3 will be catastrophic problems. These problems cause damage to the hardware
or total ineffectiveness of the software itself. The turnaround time a Level 3 problem will be 24 hours. The development team must be notified of the
problem immediately regardless of time of day.
Defining
the roles of all stakeholders and defining the process for change requests will
implement an effective method of software maintenance. All suggestions for the software maintenance
program will be welcome and considered.
Change
Management
In order to keep a strict
history and process for revisions of our software code, we have chosen to use a
sort of Content Management solution.
There are certain considerations to keep in mind when working with
software and the code that created it.
The developers/owners of the code need to be very mindful of keeping a
full history of each implementation of code, and they need to ensure that
version control is strictly enforced.
Our solution is somewhat more basic than many of the options out there,
yet still focused on the above points.
The process for editing code
would go something like this:
1 – write code for
application
2 – when finished, check
code into system (locking the version) for safekeeping
*A version of the code
checked-in would be implemented in a production environment.
3 – to edit that code, a
developer would ‘check it out’ of the system (this would lock the file
specifically for that developer’s use)
4 – make code changes
5 – save the new version of
the code into the system as a new file (ex: v1.2)
6 – check original code back
in (unlocking it)
7 – export new code revision
to testing/production environment
Checking the code into the system will effectively
lock it off from anyone being able to come along and tinker with the code. It keeps a safe history of the code for
developers to look at anytime they wish.
The process of locking that file/code once it has been checked-out by a
developer, ensures that only one person will be editing the code at a time, and
therefore requiring a new version for each developer’s changes which will forcibly
be made one at a time.
The beauty of this process
is two-fold. One, with only one
developer working at a time, all code changes will be logged. Otherwise, two developers could edit the
code simultaneously, making different changes, and the person who saves the
code back in first, will have their changes over-written by the developer who
saves over top it afterward. The other
high point is that each version is saved so that if a new implementation
blows-up in a production environment, the code can be backed-out of the
environment, and a previous version is still available in our revision history.
Only developers can decide
if a change is necessary. A change
management form will be needed. This
form will be sent the by the same method as the software maintenance form.
Conclusion