ISYS6338 – Testing and System
Implementation
Session 13:
Software Implementation
Learning Outcomes
• LO-3 : Apply the testing design plan and tools to the
testing process
• LO-4 : Describe the software implementation strategies
References
• Marchewka, Jack T. (2015). Information Technology
Project Management: providing measureable
organizational value. Wiley. USA. ISBN: 978-1-118-91101-
3
• [Link]
management
• [Link]
king
• [Link]
• [Link]
• [Link]
k-configuration-management
References
(Cont.)
• [Link]
ion
• http
://[Link]/topics/virtualization-man
agement/
• [Link]
t=3074&sponsorSelect=-1&rtypeSelect=6
• [Link]
[Link]
• [Link]
[Link]
• [Link]
t=3255&sponsorSelect=-1&rtypeSelect=6
References
(Cont.)
• Staten, James. 2015. Onboard The Business To Your Cloud
Strategy. Forrester. (White Paper)
• Enterprise Management Associates (EMA). 2015. Cloud
Migration: Thin Ice or Solid Ground?. (White Paper)
• [Link]
[Link]
Sub Topics
• Implementation Approaches
• Project Closure
• Project Evaluation
• Infrastructure Management (Supplement)
• Network Configuration (Supplement)
• Database Implementation (Supplement)
• Virtualization (Supplement)
• Cloud (Supplement)
Implementation Approaches
System Implementation
• At some point, testing is complete and the project
team and project manager then become responsible
for ensuring that the product or system is transferred
successfully from the development and test
environment to the operational environment of the
customer or organization.
• This transfer requires a tactical approach that is
defined during the planning stages of the project, but
the actual implementation activities can be a
stressful time for all the stakeholders involved.
• Choosing an inappropriate implementation approach
can negatively impact the project’s remaining schedule
and budget.
• In general, the project team can take one of three
implementation approaches: (a) direct cutover, (b)
parallel, and (c) phased.
Direct Cutover
Source: Marchewka (2015, pg. 307)
Direct Cutover
(Cont.)
• This approach, in short, the old product or system is
shut down and the new product or system is
released. In general, a target, or release, date is
agreed upon and the new product or system simply
replaces the old.
• This approach is also appropriate when releasing a
new product or system, when quick delivery is critical,
or when the existing product or system is so poor that
it must be replaced as soon as possible.
• Direct cutover may also be appropriate when a
system is not mission critical–that is, the system’s
failure will not have a major impact on the
organization.
Parallel
Source: Marchewka (2015, pg. 308)
Parallel
(Cont.)
• The parallel approach to implementation allows the old
and the new product or system to run concurrently for a
time.
• The parallel approach is appropriate when problems or
the failure of the product or system can have a major
impact on the organization.
• Before switching over completely to the new system, the
organization may run both systems concurrently in order
to compare the outputs of both systems. This approach
provides confidence that the new system is functioning
and performing properly before relying on it entirely.
Phased
Source: Marchewka (2015, pg. 309)
Phased
(Cont.)
• Following the phased approach, the product or
system is released in modules or in different parts
of the organization incrementally.
• The phased approach may be appropriate when
introducing a software system to different areas of
the organizations.
• A phased approach may also allow the project team to
learn from its experiences during the initial
implementation so that later implementations run
more smoothly.
Comparison of
Implementation
Direct Cutover Approaches Phased
Parallel
Implementation can be Provides a safety net or Allows for an organized
quick backup in case problems are managed approach for
encountered with the implementing product or
Can be risky if product or implementation of the new system modules in different
system is not fully tested product or system departments or
geographical locations.
Places more pressure on the Can increase confidence in
project team the new product or system Experience with early
when output of old system implementation can guide
and new system is and make later
compared. implementations go more
smoothly
Takes longer and may cost
more than direct cutover Takes longer and may cost
approach more than the direct
cutover approach and
Places more pressure on the problems encountered
customer or users of the during early phases can
product or system impact the overall project
schedule and budget
Project Closure
Five Circumstances for
Ending a Project
• A project that ends normally is one that is completed as
Normal planned
• Occasionally, a project team may be pushed to complete a
Premature project early even though the product or system may not
include all of the envisioned features or functionality.
• Some projects seem to take on a “life of their own” and are
Perpetual knows as runaway, or perpetual, projects. These project
never seem to end.
• Sometimes projects are just unsuccessful. In general, a
Failed project fails if insufficient attention is paid to the people,
processes, or technology.
Changed • In some circumstances, a project may be terminated as a
result of change in priorities. Financial or economic reasons
Priorities may dictate that resources ar no longer available.
Issues
Near Project Completion
• Team members are concerned about future
employment
• Bugs still exist
• Resources are running out
• Documentation attains paramount importance
• Promised delivery dates may not be met
• The players may posses a sense of panic
Final Project Report
Reports should include:
Project summary Outstanding issues
Project description Itemized list and expected completion
Project MOV Any ongoing support required and
duration
Scope, schedule, budget, and quality Project documentation list
objectives
Comparison of planned versus actual Product or systems documentation
Original scope and history of any User manuals
approved changes
Original scheduled deadline versus Training materials
actual completion date
Original budget versus actual cost of Maintenance documentation
completing the project
Test plans and test results
Final Meeting and
Presentation
Communicating that the project
is over
Transference of the product or
system
Acknowledge contributions
Getting formal signoff
Administrative Closure
• Requirements for administrative closure include:
– Verifying that all deliverables and open items are complete
– Verifying the project sponsor or customer’s formal
acceptance of the project
– Organizing and archiving all project deliverables and
documentation
– Planning for the release of all project resources (i.e.,
project team members, technology, equipment, facilities)
– Planning for the evaluations and reviews of the project
team members and the project itself
– Closing of all project accounts
– Planning a celebration to mark the end of a (successful)
project
Project Evaluation
Types of Project
Evaluations
• There are four types of project evaluations should be
conducted. There should be:
– An individual review of each team member’s performance
by the project manager
– A project close-out review (sometimes called a
postmortem review) by the project manager and project
team
– An audit of the project by an objective and respected
outside party
– An evaluation sometime after the product is released or
the system is implemented to determine whether the
project achieved its envisioned MOV.
Individual Performance
Review
• Begin with the individual evaluating his/her
performance.
• Avoid “why can’t you be more like …?”
• Focus on specific behaviors, not the individual
• Be consistent and fair
• Reviews should provide a consensus on improving
performance
Project Close-Out
(Postmortem) Review
• The focus of this review should include the following:
– Review the initial project’s MOV
– Review the project scope, schedule, budget, and
quality objectives
– Review each of the project deliverables
– Review the various project plans and the project and
product methodologies
– How well did the project team perform?
Project Audit
• To provide a more objective view of the project, an
audit or review by an outside party may be beneficial for
uncovering problem, issues, or opportunities for
improvement.
• The auditor or audit team should focus on how
well the project was managed and executed. This
may include the project plans, processes, and
methodologies. In addition, the auditor or audit team
should assess whether the project manager and team
acted in a professional and ethical manner.
Evaluating Project
Success – The MOV
• The MOV, or measureable organization value, was
defined at the beginning of the project. It provided
the basis for taking on the project and supported many of
the decision points throughout the project life cycle.
• Many of the benefits envisioned by the implemented
system may require and players may require weeks or
months before they are realized.
• The evaluation of the project’s MOV may be
intimidating–it can be the moment of truth as to
whether the project was really a success.
• However, a successful project that brings
measurable value to an organization provides a
foundation for organizational success.
Infrastructure Management
(Supplement)
Infrastructure
Management
• For an organization's information technology,
infrastructure management (IM) is the
management of essential operation components,
such as policies, processes, equipment, data, human
resources, and external contacts, for overall
effectiveness.
• Among other purposes, infrastructure management
seeks to:
– Reduce duplication of effort
– Ensure adherence to standards
– Enhance the flow of information throughout an information
system
– Promote adaptability necessary for a changeable
environment
– Ensure interoperability among organizational and external
entities
Categories of
Infrastructure
Management
• is the management of the information technology systems in an enterprise. This
Systems includes gathering requirements, purchasing equipment and software,
distributing it to where it is to be used, configuring it, maintaining it with
Management enhancement and service updates, setting up problem-handling processes, and
determining whether objectives are being met.
• is the construction, design, and use of a network, including the physical
Network (cabling, hub, bridge, switch, router, and so forth), the selection and use of
telecommunication protocol and computer software for using and managing
Management the network, and the establishment of operation policies and procedures
related to the network.
• is the management that related of the data storage usage in enterprise. Storage
Storage has been divided into primary storage (which holds data in memory) and
secondary storage (which holds data on hard disks, tapes, and other devices
Management requiring input/output operations).
Network Configuration
(Supplement)
Network Configuration
Management
• Network configuration management (NCM) is the
process of organizing and maintaining information
about all the components of a computer network.
• When a network needs repair, modification, expansion
or upgrading, the administrator refers to the network
configuration management database to determine the
best course of action.
• This database contains the locations and network
addresses of all hardware devices, as well as
information about the programs, versions and updates
installed in network computers.
• Network configuration management tools can be
vendor-neutral or vendor-specific. Vendor-neutral
tools, by far the more common, are designed for
networks containing hardware and programs from
multiple suppliers.
Network Configuration
Management
• Advantages of network configuration management
include:
– Streamlining the processes of maintenance, repair,
expansion and upgrading.
– Minimizing configuration errors.
– Minimizing downtime.
– Optimizing network security.
– Ensuring that changes made to a device or system
do not adversely affect other devices or systems.
– Rolling back changes to a previous configuration if
results are unsatisfactory.
– Archiving the details of all network configuration
changes.
FCAPS
• FCAPS is a network management framework
created by the International Organization for
Standardization (ISO)
• FCAPS categorizes the working objectives of network
management into five levels.
• The five levels are:
– Fault-management (F),
– Configuration level (C),
– Accounting level (A),
– Performance level (P), and
– Security level (S).
FCAPS
(Cont.)
• At the fault management level, network problems
are found and corrected. Potential future problems are
identified and steps are taken to prevent them from
occurring or recurring.
• With fault management, the network stays
operational, and downtime is minimized.
• At the configuration management level, network
operation is monitored and controlled. Hardware and
programming changes, including the addition of new
equipment and programs, modification of existing
systems, and removal of obsolete systems and programs,
are coordinated.
• At the C level, inventory of equipment and programs is
kept and updated regularly.
FCAPS
(Cont.)
• The accounting management level, which might
also be called the allocation level, is devoted to
distributing resources optimally and fairly among network
subscribers.
• This makes the most effective use of the systems
available, minimizing the cost of operation. The A
level is also responsible for ensuring that users are billed
appropriately.
• The performance management level is involved with
managing the overall performance of the network.
Throughput is maximized, network bottlenecks are
avoided, and potential problems are identified.
• A major part of the effort is to identify which
improvements will yield the greatest overall performance
enhancement.
FCAPS
(Cont.)
• At the security management level, the network is
protected against hackers, unauthorized users,
and physical or electronic sabotage.
• The confidentiality of user information is maintained
where necessary or warranted.
• Security systems also allow network
administrators to control what each individual
authorized user can (and cannot) do with the system.
Database Implementation
(Supplement)
Implementing a Database
• The implementation phase of a database project
requires careful management and there are key
practical and strategic issues to consider.
• By this stage, you’ve already spent time planning,
identified specific requirements, selected a supplier,
bought a package, made customizations and
identified any necessary improvements to your
ICT infrastructure. It’s time to implement your system.
• The key things to remember for a successful
implementation are:
– Take it slowly – rushing leads to error
– Pay attention to detail
– Clean up your data before you add it
– People are your biggest issue (and asset)
– Evaluate what you do
Implementing a Database
(Cont.)
• Before you install the system, make sure your ICT
system and infrastructure (server, network, PCs
etc.) is up to scratch.
• Will you be able to run all your software at once
(databases can be hungry for computer resources)?
Nearly is not good enough. Once you’re satisfied. It’s
time to install it.
• You must have someone in overall day-to-day charge
of the database (often called the Database Manager or
Database Administrator).
• They are the first point of call for problems, liaise
with the suppliers and keep an eye on issues and
developments. They should also link in to senior
management and recommend decisions on changes
and future expenditure.
– Appoint them before installation.
Implementing a Database
(Cont.)
• A shared database can be a culture shock.
Demonstrate what difference the database will make to
individuals as well as the organization.
• Listen to needs and concerns. You don’t want people
working around the system and not using it. Fear of
change is a big issue.
• Set practical, manageable expectations. The first
few weeks will be time consuming and problematic. Major
benefits take a little while.
• The biggest challenge is when a system offers a
big improvement to the organization but may have a
negative and demanding impact on specific users.
– Key point: People are the key to an effective
database.
Implementing a Database
(Cont.)
• However good your database is, you need to put
data in and get information out. It takes time and
effort and you’ll probably need a good spring clean of
what you have. (If you’ve never had a database before
and don’t intend adding old data you can skip this bit).
• List every source of data you have. Your colleagues
probably have an Excel spreadsheet each, perhaps a few
Access databases, an old ‘main’ database and contacts in
Outlook.
• Compile your list, collate the data and clean it
up. Imagine moving home – you don’t simply bundle
rubbish into boxes and pile it out again. Sort out, clean
up and throw away as you go along. A new database
won’t sort out bad data or tidy up a poor filing system.
– Key point: Only ever add clean data to a new
system.
Implementing a Database
(Cont.)
• When doing data migration:
– Decide what data structure you want (you’ll
probably have done this when you bought the system)
– Check your data (you can do this manually or have
suppliers write scripts [small computer programs that
match data and ask you to check problems])
– Throw away duplicates (e.g. someone with the
same name and three different phone numbers they
no longer have) and make sure the data is clean.
Implementing a Database
(Cont.)
• When doing testing:
– For any system, there are two ways to test – use both:
• Scripted or structured testing – you follow a
script/process and perform a key task e.g. adding a
contact, writing a report or managing an event
• Monkey testing – you try your best to break the system
and see what weird and wonderful things it can do (that
it shouldn’t)
– You’ll need to write test reports and have
someone to manage and oversee testing.
– After testing, you may need to redevelop parts of
the system or change your expectations or processes.
• Key point: The time and effort you invest now will
pay off quickly. Better to find the problems before
you use it for ‘mission critical’ work.
Implementing a Database
(Cont.)
• Most people in your organization probably get by
with simple software. Don’t assume they can do the
same with your database.
• You need everyone to use it the same way (more or
less). Investment in training is key to a successful system
because:
– People are happier with the system and are ‘bought in’ to
its success
– People work more effectively with it (and don’t go back
to their spreadsheets)
– Processes are done the ‘organizational’ way -
systematically
– People are more efficient and better able to get on with
their job
• Key point: Don’t ever install a new system without
training everyone who needs to use it. The users
Implementing a Database
(Cont.)
• When setting standards:
– The more people who use a system, the more
you need standards and agreed processes. It’s
important to set these in advance and make sure
everyone is signed up and agreed. A simple set of
principles will make a huge difference to data quality
and performance.
– Databases work best when well set up and
maintained and depend absolutely on quality
data. You must agree how to manage data.
• Key point: Agree standards and principles
and make sure someone senior oversees
them.
Implementing a Database
(Cont.)
• ‘Go live’ is the day you let users loose on the
system with real data to use for their day-to-day
work. If you can, let one department get to grips with
the database at a time - maybe phase the
implementation over a few days or even weeks.
• That way if there are any last minute issues, they
can be fixed before everyone finds them. There
comes a point when the whole organization will change
over to the new system. Make sure you’re ready and
have a fallback position in case things go wrong.
– Key point: Switch over carefully and be ready to
(temporarily) go back to the old way of working
if there’s a serious problem.
Implementing a Database
(Cont.)
• Just as an ICT system should have a support
contract, any serious investment in database
technology will need expert help, almost always
from the supplier.
• This usually comes in the form of a joint license/support
contract (or online help). It can be expensive (from 10 to
20% of the system cost) but is worth it. If it breaks, you
may end up with nothing.
• You should also consider:
– A reporting (change control) process – what changes are
wanted or needed and why? Are they improvements or bug fixes?
– Monitoring and evaluating how the system is working - what
could be improved? Do people and processes need to adapt?
– Identifying changes (opportunities) to working practices in the
organization and unexpected issues
– Longer term support costs for the system to be most effective
– Maintaining your database champion and project steering group
Virtualization
(Supplement)
Virtualization
• With the current technologies available,
virtualization is occurring both inside the IT
organization as well as at outsourced hosting providers.
• Virtualization provides a better business value than
traditional methods.
• Most businesses are migrating key servers and
applications to virtualized environments and these
businesses aren’t stopping at one or two of their
servers, but are virtualizing the vast majority of them.
• Virtualization is more than just a trend, it’s an
integral part of the IT organization’s infrastructure.
– While virtualization offers organizations the promise of
tremendous agility and flexibility at reduced costs, it also
includes complexities and requires new ways of monitoring
and managing environments.
Virtualization
Management
• Virtualization Management covers all aspects of
managing a modern virtual or software defined
data center.
• This includes:
– managing across virtualization platforms and clouds,
– monitoring the performance and availability of the
virtualization platforms (hypervisors) and the clouds,
– monitoring the capacity of the virtualization platforms and
clouds,
– monitoring the performance of the applications running on
these platforms and clouds,
– automatically provisioning these environments,
– securing these environments, and
– ensuring that the data in these environments is always
protected and available.
Virtualization
Management
• Activities relatedto
(Cont.)
virtual infrastructure
implementation:
– Network Configuration
– Storage Configuration
– Logical Partitioning Configuration
– Operating System (OS) Installation
– System Management Software (existing and future
versions of software)
– Knowledge Transfer
Cloud
(Supplement)
Begin to Cloud …
• The expected benefits of enterprise private cloud
include:
– Increased agility, including significantly reduced
provisioning times.
– Greater efficiency, including energy savings, due to
better resource utilization.
– High availability with minimal incremental cost, by
taking advantage of enhancements to industry-
standard hardware and software.
– Improved capacity management, taking
advantage of new business intelligence tools.
Begin to Cloud … (Cont.)
• Several attributes that distinguish cloud computing
from conventional computing.
• These attributes are:
– On-demand self-service
– Broad network access
– Resource pooling
– Rapid elasticity
– Measured service
– Sharing by multiple tenants
Begin to Cloud … (Cont.)
• There are three primary categories of cloud
computing service:
– Infrastructure as a service (IaaS). Computing
infrastructure, such as servers, storage, and network,
delivered as a cloud service, typically through
virtualization.
– Platform as a service (PaaS). Platforms that can be
used to develop and deploy applications.
– Software as a service (SaaS). Software deployed
as a hosted service and accessed over the Internet.
Begin to Cloud … (Cont.)
• Four key operational requirements that
organizations must meet to operate a private
cloud.
• Today’s technology management teams must:
1. Have standardized operating procedures for the most
common tasks in their virtualized environments, such as
provisioning,
2. Patching, monitoring, and evacuating workloads
from the pool;
3. Hand off these standard functions to automation
software to drive up the efficiency and predictability of
these tasks;
4. Provide a means of self-service to their developers so
that the most common requests can be fulfilled rapidly and
with as little human intervention as necessary
5. Be prepared to share the common cloud
infrastructure across business units and internal
Begin to Cloud … (Cont.)
Source: EMA (2015, pg. 2)
Private Cloud
Architecture
Source: Intel (2010, pg. 3)
Private Cloud
Architecture
as a Service
Source: Intel (2010, pg. 5)
Private Cloud
Infrastructure Capability
Phasing
Source: Intel (2010, pg. 9)
Thank