Part 6: Maintaining and Supporting Your Technology

Introduction to Maintaining and Supporting Technology in Education Organizations

Overseeing Technology
Considering Maintenance Services
Possible Indicators for Assessing Technology Maintenance
Establishing Maintenance Plans
Maintaining Software
Upgrading Software
Replacing and Re-deploying Equipment
Considering Support Services
Possible Indicators for Assessing Technology Support
Establishing a Help Desk
Developing and Maintaining an Acceptable Use Policy
Monitoring Regular Use of the System
Assessing Ongoing User Needs
Accepting (and Refusing) Donations
Utilizing Volunteers
Finding Qualified Help

Introduction to Maintaining and Supporting Technology in Education Organizations

At some point (after a great deal of planning and even more hard work), the new computer
technology will be up and running-the prospect of which sounds good, but can be anticlimactic.
Is life in the organization perfect now? Probably not. Is it better than it was before? Probably so.
But for this to be true, the technology has to be used, maintained, and supported properly. This
includes all equipment, software, and network connections. Moreover, ongoing training and
support must be provided to all user groups. Once these activities have been instituted, it is more
likely there will be a dramatic difference in the way the organization operates.
Overseeing Technology

Several groups of individuals probably contributed both energy and expertise throughout the
process of implementing the new or upgraded technology system. By now, it should be clear
which people in the organization have the most interest in, enthusiasm for, and knowledge about
technology. These are key people to help keep the system running smoothly after implementation
has been completed. and they are prime candidates to serve on the Technology Oversight
Committee.

A Technology Oversight Committee should be appointed to oversee system use,

maintenance, and ongoing improvement.
The Technology Oversight Committee should be a mix of users and technical staff who can help
keep the system running efficiently and effectively. At least some of the people who served on
the Project Team and the Steering Committee should be included on the Technology Oversight
Committee, as should representatives from the organization's technical staff, training staff,
current users, and potential users. In order to accommodate multiple voices, plan to rotate
committee members on a regular basis (i.e., one-fourth of the committee turns over annually).
There is no perfect schedule for committee turnover-just make sure that you don't find yourself
with only inexperienced and unhappy non-users on your committee.

Depending on the nature of the organization, there may be several oversight committees. For
example, if the organization is a school district, it may make sense to have a committee at each
school (e.g., an Instructional Technology Committee) as well as a district-wide committee that
includes representatives from all schools. Meetings should be scheduled regularly, but the group
shouldn't convene unless it has real work to do. Like you, committee members are busy people.
Don't expect to maintain their interest if there aren't meaningful agendas for their meetings.

back to top

Considering Maintenance Services

When discussing the maintenance of the physical aspects of the technology throughout its life
span (generally 3-5 years for most equipment and applications), it makes sense to think seriously
about what maintenance requirements actually entail. The term "maintenance" refers to those
preventive, diagnostic, updating, replacement, and repair procedures that an organization
undertakes to keep its technology working effectively and efficiently. Maintenance can be
provided either by persons who are employees of the organization or through outside contractors.
Maintenance items might include:

 replacing wear-and-tear parts and consumable supplies

 repairing or replacing faulty components
 cleaning equipment
 monitoring the condition and functionality of networks and equipment, including testing
website access and links
 redeploying equipment
 updating or upgrading hardware and software, including installing new versions of the
operating system
 adding or deleting users from a system, or modifying user rights and properties
 backing up stored files
 documenting trends and patterns in the use of applications or equipment
 removing and disposing of equipment and applications

When the network goes down in a school or district, the administrators, teachers, and students
sometimes have to wait for hours (or even days) until it comes back up. Lost information and
data may not be restorable. This type of outage in the business world can cost tens or hundreds of
thousands of dollars in costs or lost sales, but lost instructional time has not yet been valued in
the same way. However, as schools rely more on the use of technology both administratively and
instructionally, the loss of time and information is increasingly understood to be expensive and
disruptive to the learning process.

Possible Indicators for Assessing Technology Maintenance

1. Are equipment and infrastructure reliable?

a. How many maintenance incidents were there per workstation/server during the
 current academic year (by cause, category, and location)?
b. What was the average number of downtime hours per workstation/server during
the current academic year?
c. What is the average number of calls to help desk/tech-support services per
workstation/server?
d. What is the average elapsed time between the receipt of a call to the help desk and
the response call to the end user?
e. What is the average elapsed time between the initial response call and the
notification of problem resolution?
2. Are appropriate preventive maintenance procedures in place?
a. Has a preventive maintenance schedule been established?
b. Has a preventive maintenance checklist been provided to all end-users?
c. Has access to frequently asked questions (FAQs) been provided to support staff
and end users alike?
d. Has access to user manuals been provided to end users?
e. Are file backup procedures in place?
f. Are disaster recovery procedures in place?
3. Are update and replacement procedures in place?
a. Has a replacement/upgrade schedule been established for hardware?
b. Has a replacement/upgrade schedule been established for software?
4. Are diagnostic and repair resources available?
a. Is help desk support software available (e.g., trouble ticketing, resolution
tracking)?
b. Is diagnostic software available (as appropriate)?
c. Are appropriate repair instruments/tools available on school premises?
d. Are basic replacement parts in stock?

Establishing Maintenance Plans

Automoblie manufacturers recommend having an engine tuned and oil changed regularly to keep
a car running as efficiently as possible. Similar maintenance is required of a computer system. It
is best not to wait until problems arise-avoid problems in the first place! An organization can
carry out much of its own routine, preventive maintenance (e.g., checking database size, purging
outdated records, and deleting idle user accounts), but in spite of efforts to deliver a high-quality
preventive maintenance program, problems will still occur. To deal with them, many
organizations have maintenance agreements with outside contractors for fix-it-when-it-breaks
service, particularly for hardware. The key factors in these agreements are response time to a
trouble call and the availability and proximity of spare parts. In other words, planners need to
know how long it will take to get the problems fixed when (not if) they arise.

One of the most feared expressions in modern times is "The computer is down."

--Norman Augustine
Maintenance agreements are like insurance policies. One needs to weigh the relative and
absolute risks to the organization before making an informed decision about buying into an
agreement. Some useful questions to ask before signing a maintenance agreement with an
outside vendor can be found in Figure 6.1.

As an alternative to a maintenance agreement with an external provider, an organization can

weigh the risks and benefits of in-house maintenance, assuming that expertise is available on
site. Paying for time and materials only as repairs are needed (as opposed to a monthly fee) can
save money. In other cases, the staff time necessary to complete repairs may make the in-house
solution more expensive than it first appears. Losing access to critical systems can be even more
"expensive" in non-financial terms. It is obvious that a payroll system cannot be down for long.
It's also obvious that a lost server at a school site can be disruptive to the educational program
and demoralizing to teachers learning to use a technology-enhanced classroom. Thus, it is
imperative that a cost-benefit analysis be performed before deciding whether to pay a vendor to
provide maintenance service (see Figure 6.2).

back to top

Maintaining Software

If the organization's computer system includes a commercial software package, it will probably
come with a maintenance agreement from the product's vendor. Product maintenance agreements
should be negotiated at the time of initial purchase or at the time that the software application is
being developed. Such agreements usually are scheduled to "begin" either when the software is
purchased or when the system is initiated, as long as the vendor continues to receive the
stipulated monthly or annual maintenance fee. In return for this fee, the client organization
typically receives application changes, additions, fixes (e.g., to errors), and other basic support.
Maintenance agreements can also provide for copies of new releases (upgrades) at no or at
reduced cost.

Upgrading Software

When dealing with commercial software packages, vendors typically offer a stream of new
releases of their product on a semi-regular cycle. "New" releases are more recent versions of a
software application that the developer has published, either to enhance features and functions or
to correct problems in an earlier release.

If the organization has been keeping up with its maintenance payments, it has the right to receive
to new releases when they become available. However, this does not necessarily mean that it
must, or even should, upgrade to new releases. Weighing this decision can be tricky and requires
the consideration of several factors. One thing to keep in mind is that upgrades should be
assessed relative to the organization's current system architecture, network architecture, and
other relevant guidelines. For an upgrade to be desirable, it must be consistent with established
standards and contribute toward the organization's overall vision for technology.

If an upgrade does pass the first test (i.e., it meets established standards), it still needs to be
approached with caution. Too often, the definition of an "upgrade" is simply a piece of software
that has had its old bugs removed and new ones put in their place. Yes, unfortunately, new
software sometimes gets distributed before all of its problems are resolved. When that is the
case, those who have chosen to use the new release may become unwilling participants in the
debugging process.

Another consideration when assessing the usability of software upgrades is whether the new
release will require changes to other elements in the organization's technology environment, such
as the operating system, hardware, or network software. Also, if major changes are included, the
new release may be published as a new "version" or "edition" (rather than a release), which may
require a new purchase as well. above and beyond the organization's current maintenance
payments and/or budget.

Some organizations adopt a philosophy that they will never be the first to install a new version of
a software application. Others tend to stay one release behind the "leading" (or "bleeding") edge
to avoid such risk. Generally, these formal rules lower risk but may also delay appreciation of
those benefits provided by a useful upgrade.

To decide whether or not to upgrade, the Technology Oversight Committee needs to evaluate
whether the changes in the software provide more potential benefits than risks. Benefits should
be assessed based on:

 impact on user productivity

 ongoing costs/savings
 addition of useful functions
 addition of useful content

Risks and costs should be based on:

 costs for potential temporary loss of productivity

 costs for retraining
 new hardware, operating systems, or networks required by the upgrades

back to top

Replacing and Re-deploying Equipment

In addition to upgrading application software, upgrading hardware platforms on which the

applications run is also a key part of system maintenance. Computer hardware follows a life
cycle that is perhaps best described as "rapid, planned obsolescence" which refers to the fact that
hardware will be overtaken within three years by new models that are better, faster, and (adding
insult to injury) cheaper than existing models. This is especially true of desktop and laptop
computers, although it applies to printers, servers, modems, and other peripherals as well.

Some very old Pentium machines may not do much but teach kids keyboarding skills.
However, they still work. Moreover, when one breaks, it can be used for parts and
help keep other machines running beyond their original life expectancy.
There is no way to buck this trend. It simply has to be recognized and accounted for in long-term
technology plans. Ideally, the organization should develop its vision for system architecture (the
design and contents of its computer system) to help determine when equipment should be
upgraded or replaced and what type of new equipment or modifications to existing equipment
will be needed.

A reasonable rule of thumb is to set a budget to upgrade or replace one third of the computers
each year so that nothing more than three years old remains on site in the organization. It may be
painful to see "perfectly good" machines withdrawn from use after such a short period of time,
but the pace of change in the computer field is so rapid that three year-old machines are unlikely
to be doing their jobs efficiently. Another solution is to lease the computers for three years. At
the end of that time, either return the computers or lease new ones—in either case the
organization should never be paying for old machines.

Once a decision is made to replace a group of machines, the next decision is what to do with the
old equipment. Education organizations are typically multi-faceted, and there may be several
potential homes for "once-removed" machines within your organization. A common strategy is
to move machines from a student lab to an administrative office or vice versa. Internal
redeployment, however, is not as simple as it sounds. The disruption caused by "trickle down"
internal redeployment might actually exceed the cost of external replacement with new
machines. Does it really make sense to maintain and support three generations worth of
computer equipment? Some organizations establish clear policies that, while perhaps somewhat
arbitrary, provide rules for equipment disposal. For instance, one university has decided that it
will move equipment only once internally. The old equipment is then permanently disposed of
by selling it to staff or students or by donating it to other organizations. Figure 6.3 lists issues
that should be considered prior to making decisions about re-deployment.

Regardless of the plan for discarding old computers (be it internal re-deployment, external re-
deployment, storage, or even disposal), all files from old machines must be deleted. To be
confident of effective file removal, each hard disk should be erased completely, a process
referred to as "degaussing" by technical experts. Saving time by not fully erasing files is never
worth the risk of accidentally passing along information that shouldn't be shared. After all, think
of the possible repercussions should the organization mistakenly divulge individual student data,
sensitive financial records, or other private files.

back to top

Considering Support Services

As opposed to "maintenance", the term "support" refers to actions taken on behalf of users rather
than those taken on equipment and systems. Support denotes activities that keep users working or
help users improve the ways they work. Included under support might be such items as:

 providing "Help Desks" and other mechanisms for resolving problems and offering
guidance (e.g., automated information systems and searchable frequently-asked-question
(FAQ) databases)
 offering initial and ongoing training on equipment and software
 identifying external resources, including websites, consultants, and volunteers as
appropriate
 integrating instruction and technology, usually through observation and personal
interaction between a teacher and a technology coordinator
 integrating administration and technology, usually conducted through specialized
consultants or software/systems vendors

As with maintenance, support can be delivered through a variety of mechanisms, including in-
house technology specialists, external volunteers, and outsourced contracts.
 Professional development and training are addressed in Part 7: Training for Your
Technology. Technology integration is addressed in Part 8: Integrating Your
Technology.
It is critical to determine the type of support and training the organization will need. Trial and
error can be a frustrating, costly, and risky way to learn how to use computer applications. It is
essential to have planned activities to help and support users when new technology is
implemented.

Support services, training, and certification must be ongoing to ensure successful post-
implementation use of technology. As time passes, personnel, organizational needs, and the ways
in which the technology is being used all change. Any and all of these changes must be taken
into account when planning for ongoing system support.

E-mail from a troubled user: "Canyoufixmyspacebar?"

Possible Indicators for Assessing Technology Support

1. Is technical support staffed adequately?

a. What is the number of dedicated persons assigned to technical support (at
building and organization-wide levels)?
b. What is the percent of FTE hours assigned to technical support at building
organization-wide levels? By primary area of responsibility?
2. What is the technical support workload?
a. What is the number of calls handled per FTE position?
b. What is the ratio of calls or incidents to FTE support staff hours?
c. What is the ratio of technical support staff to the numbers of
workstations/servers?
d. What is the ratio of technical support staff to end users?

Establishing a Help Desk

The most common way of providing user support is to create and staff a bank of telephones (or at
least one phone) or e-mail accounts with people who are capable of patiently and constructively
answering user questions. In large organizations such as universities, Help Desks may be
available 24 hours a day. For most education organizations, however, it should be sufficient to
have someone running the Help Desk for only part of the day, with the number of hours based on
how many users there are and how many questions are being asked. It may even be sufficient to
have someone check voice mail or e-mail twice a day to see if any questions have been
forwarded.

Four Ways to Ensure Quality Tech Support in Schools (by Richard M. Beattie)

As school technology systems get more complex, schools must further professionalize
their technical support departments. No longer can schools rely upon members of
their academic departments who have an interest in technology to perform major
system upgrades, maintenance, and troubleshooting. Anecdotal evidence shows a
rising level of burnout on the part of those educators who have added the informal
title of "computer expert" to their list of responsibilities within schools.

Unfortunately, schools have a long way to go. As a point of comparison, large

companies strive to have at least one professional computer support person for every
fifty computers (laptops or PCs) in use. Few, if any, schools enjoy a ratio this low.
With the demands for hiring additional instructional staff in most school systems, it's
no surprise that administrators can't focus on improving tech support departments.

Nevertheless, for technology to reach its potential in K-12 education, technology

experts-not just technophiles-must be intimately involved in ensuring that a school's
precious technology dollars are used to serve the school's mission and its unique
student body. Achieving these goals starts with a firm commitment to quality in
technical staff. This can be achieved in four ways:

1. Administrators should recognize that technology experts must be able to focus

on their roles on a full-time basis.
 2. Technical support staff must have an understanding of the educational process
in addition to computer technology.
3. Schools and districts must budget realistically not only to purchase
technology, but also to maintain and upgrade it on a regular basis so that it can
be used by students and teachers.
4. Technical staff must be committed to making themselves key members of the
school's planning process, not just crisis managers who keep the machines
running.

Reprinted with permission from Electronic School, Copyright © 2001 All Rights
Reserved.
When staffing a Help Desk, keep in mind that the person or people who work at a Help Desk
must be detail oriented and able to demonstrate extreme empathy and patience. Each caller's
problem must be treated diligently, even if it's the ninth (or ninetieth) time the same question or
problem has been reported. Some schools use students to run the Help Desk. If a school district
decides to use students to staff a Help Desk, it should assign a staff member to train, supervise,
and evaluate the service provided by the students. Also, the organization must be careful not to
ask students to help with sensitive equipment or files (e.g., grade reports of their peers).

In addition to solving user problems on a day-to-day basis, a Help Desk can also be valuable as a
mechanism for documenting trends and patterns regarding the use of an application or
equipment. Thus, it is important to track Help calls and responses. One effective way of doing so
is by using a software package that generates reports like "most frequent queries" or "call
distributions" (i.e., the distribution of callers who have the same problem). This information can
be used when developing new training materials or tailoring future training to better meet user
needs. Many users will find it helpful if frequently asked questions (FAQs) and their answers are
printed in a newsletter or made available via the network.

back to top

Developing and Maintaining an Acceptable Use Policy

The development of an Acceptable Use Policy (AUP) is a critical component of technology

planning. An AUP is important for all system users, including administrators, teaching staff,
other staff, students, parents, the community, and any other persons who will have access to the
system and its contents. Once developed, the AUP should be reviewed periodically by the
Technology Oversight Committee, the Instructional Technology Committee, and other bodies
responsible for oversight. The AUP should address the following areas:

 individual rights concerning access to the system

 individual responsibilities with regard to the system, its contents, and any connections
established through the system
 organizational rights relating to system oversight and monitoring
 organizational responsibilities with regard to the system, its contents, and any
connections established through the system

Protecting the privacy of sensitive information maintained within the system is essential.
Security and ethical standards also remain important as long as the system is in operation. Both
legal and technical staff should review the Acceptable Use Policy to ensure that appropriate
protections are in place.

Monitoring Regular Use of the System

Another aspect of supporting computer technology is keeping track of how, how much, and by
whom the technology is being used. For instance, if a school has a goal to increase technology
use in the classroom, it is important to review the amount of time students are using the
technology and what applications they are using, as well as routine teacher usage patterns.

Regular tracking of how, how much, and by whom technology is used can provide
input into training, maintenance, and long-term planning.
Most commercial software packages and well-designed custom computer systems have built-in
utility programs to collect usage information and turn out "canned" reports on use patterns and
volume. Every system should have a staff member assigned to review these reports on a regular
basis. Some commonly accepted indicators of usage to watch for include:
  volume of transactions processed
 number and average duration of user sessions
 database size (if relevant)
 volume of reports generated
 downtime

In addition to these routine indicators, exception reports should highlight unusual usage patterns
and/or any problems that occur (e.g., disk space constraints, database corruption, and interface
problems with other systems). The more serious of these should not wait until the regular cycle
to be reported-they should be addressed immediately so that no information is lost or damaged.

Assessing Ongoing User Needs

It may take a while before a new computer system is up and running at its maximum
effectiveness. A key maintenance function that can be addressed immediately, however, is the
development of a mechanism for collecting user suggestions (and complaints) about the system.
Having a process in place for collecting this type of information provides a measure of control
for an organization. It allows the organization to identify and document user problems, and helps
with decisions about priorities for future investments. Without such a process, requests for
change can build up without administrators realizing that problems are occurring.

To help set up a process for determining needed changes, consider using the following
procedures:

 develop paper or electronic forms for documenting requests and select a central point for
gathering the requests
 have the technology coordinator (or someone else) document and research the requests
and develop a list of possible solutions
 maintain a log that shows the date of each request, the source of the request, projected
cost and time estimates, who needs to respond to the request, the date(s) of all responses,
their priority, and disposition
 review and prioritize the requests and possible solutions in keeping with the
 organization's system architecture, technology goals, and long-range plans
 respond to all suggestions-if nothing else, simply acknowledge receipt of the comment

Make sure that all users understand the feedback process and that they feel free to use it. Where
suggested changes are involved, the user bears the responsibility of distinguishing between
needed changes and "nice to have" wish lists. Where new purchases are requested, the user
making the request should provide any additional information that might contribute to the
decision-making process.

back to top

Accepting (and Refusing) Donations

When companies replace their computer systems, they sometimes look to donate the equipment
and/or software to education organizations. It is tempting to say "yes" to anyone offering
something for free. On the other hand, a rule one might want to live by is: "Don't accept a gift
you have to feed." If your organization is confronted with this situation, weigh both the potential
benefits and consequences of every donation. Obviously, the organization benefits most from
donated equipment that fits its long-term plan for purchasing and replacing equipment. Thus,
when the organization is offered donations refer to an established plans and protocol that dictate
whether or not they should be accepted:

 Staff should screen potential donations to ensure compliance with standards adopted by
the organization. Donations can be useful to supplement available funds and equipment.
However, to avoid invalidating warranties and increasing future expenses for
maintenance and support, all donations should comply with the same standards that
would have been followed had the institution purchased the goods and services.
 Just as with purchases, donations come with associated costs for installation, training,
maintenance, power supplies, facilities, associated hardware or software, human
resources, etc. (For example, most donations come without an operating system, which
leads to the question of who will purchase the Windows or Mac OS?) In cases where
donations are not in compliance with established standards, the donor might be asked to
 underwrite the additional maintenance and support that the donation will require.

See Figure 6.4 for additional considerations affecting the acceptance or rejection of donated
resources.

Utilizing Volunteers

Since the E-Rate program enables schools and districts to "wire" buildings at a greatly reduced
cost, reliance upon volunteer efforts may be less necessary than it once was. In any case, before
making arrangements for a volunteer to work on an education organization's technology, check
with insurance providers and other supervisory groups (e.g., the school district office) to
determine whether there are limitations to what types of tasks a volunteer can perform. Consider
that regardless of who performs the task, all work must adhere to relevant building codes.
Additionally, non-trivial issues such as asbestos and lead paint may be relevant. Thus, onsite
work can be a difficult issue that could create physical danger to students, volunteers, and others.
It must be handled with considerable forethought. and perhaps most safely by trained
professionals. See Figure 6.5 for additional considerations affecting the use of volunteers.

Volunteers can provide valuable services to organizations if they have relevant

experience and are willing to work within the organization's plans.
back to top

Finding Qualified Help

This document has focused on finding the right people with the right expertise to help decision-
makers. It has also acknowledged the necessity of having experts help install, implement,
monitor, and evaluate the system, and the importance of providing ongoing technical support and
staff training. But it has not discussed how to find these experts. There are numerous sources of
qualified help available. Some might include:

 professional organizations that provide relevant member services

 private or not-for-profit consulting organizations or individuals
 governmental agencies chartered to provide assistance
  technical and professional publications
 training programs
 university faculty or centers
 vendors who are willing to describe their solutions

Planners could also look for help in other organizations, such as peer districts within the state.
Talk to their decision-makers. Ask about the consultants they used, and use this information to
make better informed decisions. See Figure 6.6 for additional considerations when trying to
identify qualified help.

When dealing with consultants and organizations that have products to sell or who represent
specific products, make sure they disclose these relationships up front in order to avoid possible
conflicts of interest. The organization should determine in advance whether vendors,
organizations, and individuals who represent products would be appropriate sources of
assistance. If a product recommendation is not a part of the help requested, or if an open and
public bidding process will follow, vendors representing specific products may be able to
provide current and appropriate expertise.
Software maintenance is widely accepted part of SDLC now a days. It stands for all the
modifications and updations done after the delivery of software product. There are number of
reasons, why modifications are required, some of them are briefly mentioned below:

 Market Conditions - Policies, which changes over the time, such as taxation and newly
introduced constraints like, how to maintain bookkeeping, may trigger need for
modification.
 Client Requirements - Over the time, customer may ask for new features or functions in
the software.
 Host Modifications - If any of the hardware and/or platform (such as operating system)
of the target host changes, software changes are needed to keep adaptability.
 Organization Changes - If there is any business level change at client end, such as
reduction of organization strength, acquiring another company, organization venturing
into new business, need to modify in the original software may arise.

Types of maintenance
In a software lifetime, type of maintenance may vary based on its nature. It may be just a routine
maintenance tasks as some bug discovered by some user or it may be a large event in itself based
on maintenance size or nature. Following are some types of maintenance based on their
characteristics:

 Corrective Maintenance - This includes modifications and updations done in order to

correct or fix problems, which are either discovered by user or concluded by user error
reports.
 Adaptive Maintenance - This includes modifications and updations applied to keep the
software product up-to date and tuned to the ever changing world of technology and
business environment.
 Perfective Maintenance - This includes modifications and updates done in order to keep
the software usable over long period of time. It includes new features, new user
requirements for refining the software and improve its reliability and performance.
 Preventive Maintenance - This includes modifications and updations to prevent future
problems of the software. It aims to attend problems, which are not significant at this
moment but may cause serious issues in future.

Cost of Maintenance
Reports suggest that the cost of maintenance is high. A study on estimating software
maintenance found that the cost of maintenance is as high as 67% of the cost of entire software
process cycle.
On an average, the cost of software maintenance is more than 50% of all SDLC phases. There
are various factors, which trigger maintenance cost go high, such as:

Real-world factors affecting Maintenance Cost

 The standard age of any software is considered up to 10 to 15 years.

 Older softwares, which were meant to work on slow machines with less memory and
storage capacity cannot keep themselves challenging against newly coming enhanced
softwares on modern hardware.
 As technology advances, it becomes costly to maintain old software.
 Most maintenance engineers are newbie and use trial and error method to rectify
problem.
 Often, changes made can easily hurt the original structure of the software, making it hard
for any subsequent changes.
 Changes are often left undocumented which may cause more conflicts in future.

Software-end factors affecting Maintenance Cost

 Structure of Software Program

 Programming Language
 Dependence on external environment
 Staff reliability and availability

Maintenance Activities
IEEE provides a framework for sequential maintenance process activities. It can be used in
iterative manner and can be extended so that customized items and processes can be included.

These activities go hand-in-hand with each of the following phase:

 Identification & Tracing - It involves activities pertaining to identification of

requirement of modification or maintenance. It is generated by user or system may itself
report via logs or error messages.Here, the maintenance type is classified also.
 Analysis - The modification is analyzed for its impact on the system including safety and
security implications. If probable impact is severe, alternative solution is looked for. A
set of required modifications is then materialized into requirement specifications. The
cost of modification/maintenance is analyzed and estimation is concluded.
 Design - New modules, which need to be replaced or modified, are designed against
requirement specifications set in the previous stage. Test cases are created for validation
and verification.
 Implementation - The new modules are coded with the help of structured design created
in the design step.Every programmer is expected to do unit testing in parallel.
 System Testing - Integration testing is done among newly created modules. Integration
testing is also carried out between new modules and the system. Finally the system is
tested as a whole, following regressive testing procedures.
 Acceptance Testing - After testing the system internally, it is tested for acceptance with
the help of users. If at this state, user complaints some issues they are addressed or noted
to address in next iteration.
  Delivery - After acceptance test, the system is deployed all over the organization either
by small update package or fresh installation of the system. The final testing takes place
at client end after the software is delivered.

Training facility is provided if required, in addition to the hard copy of user manual.

 Maintenance management - Configuration management is an essential part of system

maintenance. It is aided with version control tools to control versions, semi-version or
patch management.

Software Re-engineering
When we need to update the software to keep it to the current market, without impacting its
functionality, it is called software re-engineering. It is a thorough process where the design of
software is changed and programs are re-written.

Legacy software cannot keep tuning with the latest technology available in the market. As the
hardware become obsolete, updating of software becomes a headache. Even if software grows
old with time, its functionality does not.

For example, initially Unix was developed in assembly language. When language C came into
existence, Unix was re-engineered in C, because working in assembly language was difficult.

Other than this, sometimes programmers notice that few parts of software need more
maintenance than others and they also need re-engineering.

Re-Engineering Process
  Decide what to re-engineer. Is it whole software or a part of it?
 Perform Reverse Engineering, in order to obtain specifications of existing software.
 Restructure Program if required. For example, changing function-oriented programs
into object-oriented programs.
 Re-structure data as required.
 Apply Forward engineering concepts in order to get re-engineered software.

There are few important terms used in Software re-engineering

Reverse Engineering

It is a process to achieve system specification by thoroughly analyzing, understanding the

existing system. This process can be seen as reverse SDLC model, i.e. we try to get higher
abstraction level by analyzing lower abstraction levels.

An existing system is previously implemented design, about which we know nothing. Designers
then do reverse engineering by looking at the code and try to get the design. With design in hand,
they try to conclude the specifications. Thus, going in reverse from code to system specification.

Program Restructuring

It is a process to re-structure and re-construct the existing software. It is all about re-arranging
the source code, either in same programming language or from one programming language to a
different one. Restructuring can have either source code-restructuring and data-restructuring or
both.

Re-structuring does not impact the functionality of the software but enhance reliability and
maintainability. Program components, which cause errors very frequently can be changed, or
updated with re-structuring.

The dependability of software on obsolete hardware platform can be removed via re-structuring.

Forward Engineering

Forward engineering is a process of obtaining desired software from the specifications in hand
which were brought down by means of reverse engineering. It assumes that there was some
software engineering already done in the past.

Forward engineering is same as software engineering process with only one difference – it is
carried out always after reverse engineering.
Component reusability
A component is a part of software program code, which executes an independent task in the
system. It can be a small module or sub-system itself.

Example

The login procedures used on the web can be considered as components, printing system in
software can be seen as a component of the software.

Components have high cohesion of functionality and lower rate of coupling, i.e. they work
independently and can perform tasks without depending on other modules.

In OOP, the objects are designed are very specific to their concern and have fewer chances to be
used in some other software.

In modular programming, the modules are coded to perform specific tasks which can be used
across number of other software programs.

There is a whole new vertical, which is based on re-use of software component, and is known as
Component Based Software Engineering (CBSE).

Re-use can be done at various levels

 Application level - Where an entire application is used as sub-system of new software.

 Component level - Where sub-system of an application is used.
 Modules level - Where functional modules are re-used.

Software components provide interfaces, which can be used to establish communication

among different components.

Reuse Process
Two kinds of method can be adopted: either by keeping requirements same and adjusting
components or by keeping components same and modifying requirements.

 Requirement Specification - The functional and non-functional requirements are

specified, which a software product must comply to, with the help of existing system,
user input or both.
 Design - This is also a standard SDLC process step, where requirements are defined in
terms of software parlance. Basic architecture of system as a whole and its sub-systems
are created.
 Specify Components - By studying the software design, the designers segregate the
entire system into smaller components or sub-systems. One complete software design
turns into a collection of a huge set of components working together.
 Search Suitable Components - The software component repository is referred by
designers to search for the matching component, on the basis of functionality and
intended software requirements..
 Incorporate Components - All matched components are packed together to shape them
as complete software.
Upgrade

Updated: 06/02/2020 by Computer Hope

With computer hardware, an upgrade is a term that describes adding new hardware in a
computer that improves its performance. For example, with a hardware upgrade, you could
replace your hard drive with an SSD or upgrade the RAM, providing a boost in performance and
efficiency.

 Advantages of a hardware upgrade.

 Disadvantages of a hardware upgrade.

 What is a software upgrade?

 Differences between software upgrades and updates.

 Benefits of a software upgrade.

 Risks of not doing a software upgrade.

 How can I upgrade my computer system?

 Related pages.
Advantages of a hardware upgrade

1. Performance increase, which makes the overall computer run faster and more smoothly.

2. Capacity increase. For example, adding a larger hard drive allows the computer to store
more information. Adding more memory increases the computers ability to run more
programs efficiently.

3. It may be necessary to upgrade the computer to meet a program or games system

requirements.

 How to install computer hardware.

Disadvantages of a hardware upgrade

Although the benefits always outweigh the disadvantages of a hardware upgrade, it's still worth
noting the following disadvantages of doing hardware upgrades.

1. Damage during install. It's possible, if not done correctly (e.g., not taking ESD
precautions) or using to much force, you may damage the new hardware during the
upgrade.

2. When upgrading major computer components, such as a hard drive or motherboard, you
may need to reinstall all your software, which is a significant time investment.

What is a software upgrade?

When referring to software, a software upgrade refers to any major upgrade to the software that
adds significant or completely new changes to the program. An example of a software upgrade is
upgrading your version of Windows. For example, if you had Microsoft Windows XP and
upgraded to Windows 7, it would be considered a software upgrade.

Differences between software upgrades and updates

An update and upgrade are two different things. Updates are usually free and often very small.
An upgrade is usually not free and much larger. For example, if you have Windows XP and want
Windows 7 you would "upgrade" to Windows 7. However, if you had Windows 7 and needed to
install fixes for security vulnerabilities or other problems you would "update" Windows. See the
update definition for information on this term.

Benefits of a software upgrade

1. New features not available or found in previous versions.

2. Often, the new version of a program has better stability and increased performance.

3. Support for newer computer hardware.

4. After so long, an older software program will be discontinued and often no longer
supported.

Tip

Some software upgrades are not free. However, most software updates are small and often free
because they fix bugs with a program.

Risks of not doing a software upgrade

Almost all software developers release small software updates to help keep a program secure and
stable. If the program is successful the company may release a software upgrade, which is a new
version of the program. After releasing a new upgrade, the previous versions eventually reaches
EOL (end of life) and stops being supported. For most software programs, this is not a problem
as long as you no longer need support from the developer. However, for operating systems and
software programs that could have potential security vulnerabilities, not upgrading may leave
your computer vulnerable to attacks.

How can I upgrade my computer system?

Upgrading the computer all depends on the type of computer you have and what you hope to
achieve with the upgrade. For example, the most common upgrade to a computer is upgrading
the computer memory to achieve better performance and greater memory capacity.