Docstoc

implement

Document Sample
implement Powered By Docstoc
					                        Implementation and Operation

Systems implementation and operations phase is made up of the following steps:

      Coding
      Testing (unit, integration, system and UAT)
      Deployment or Installation
      Documentation (system and user documentation)
      Training
      Support
      Maintenance


Some of the steps in this phase such as program coding, program testing, and system installation
and maintenance are typically handled by other members of the development team. Other steps
however still fall under the system analyst’s responsibility domain. Those are steps such as
system testing, documentation, user training and support.


1) Program Coding
Program coding is the process of taking the physical model that was developed and documented
in the design phase (which in itself was the product of elaboration on the analysis phase) and
turned into computer code using a specific language by a programming team.

Coding is an involved, intense and laborious task. It is a time consuming and resource intensive
activity. The process is to take use case narratives, and other models such as class diagrams,
sequence diagrams, physical ER diagrams, and others, and write program code that supports the
step by step requirements of the use case.


2) Testing
As each program module is complete, it can be tested. This testing involves having the developer
test each module separately as it is completed. This is called program testing or unit testing

It is also the responsibility of the developer to ensure that after completing each program module
and thoroughly testing it, that it is properly integrated and tested within the overall system
(i.e. with other modules that have previously been completed and integrated within the system).
This aspect of testing is called integration testing or system testing.

Finally when all the modules have bee completed the analyst along with the users can perform
user acceptance testing (UAT) to ensure that the system fits the requirements specified.
                                      Implementation and Operation




3) Deployment or Installation
Installation is the process where the current system replaces the existing system. This step also
called “deployment to production”. The step involves moving or distributing the software to
production servers and to client desktops.

The step also includes converting and migrating production data from the old system structure
and storage mechanisms to the new system structure and most likely relational database. This
step should be planned with utmost care, and many practice runs should have been undertaken
to ensure proper conversion and data migration and reconciliation.

This steps also involves the replacing all the old procedures, business forms, and documents
and documentation with the equivalent ones which will be consistent with the newly developed
system


4) Documentation
Although the process of documentation is undertaken throughout the system development cycle
from inception to deployment, the documentation step gets a formal attention at this time. It is the
analyst responsibility to ensure proper documentation of all important aspects of the system.

The goals of documentation are to ensure that:

    1. Future developers or support staff responsible for the application will have all the
       necessary information of all aspects of the system. It is always easier to read about the
       functionalities, interactions and business rules that make up the inner processing of the
       system than to have to dig through the actual program code to unearth the inner working
       of the system.

    2. Current client users of the application will know how to properly interact with the
       application on a day-by-day basis to accomplish the required tasks the system was design
       to accomplish.


5) Training
It is often necessary to train the business client on the proper use of the application. If this is a
replacement system, and the functionalities are mainly similar, then training is typically
minimal, and is only directed towards new features and new user interfaces (i.e. screens).

If on the other hand this is a new system, then a much more intense level of training will be
needed. This will ensure that all prospective users know how to properly interact with any aspect
of the system they are involved with.



                                              Page 2 of 15
                                     Implementation and Operation


A systems analyst plays a key role in facilitating and providing the training needs. The
analyst is typically the one most knowledgeable of the entire system, and therefore most qualified
to translate between the system inner workings and the business client demands.


6) Support
Deploying a new system is often very trying and anxious time to many users. They often resist
the impending changes, and try to hold on to processes and procedures they are comfortable with..
The analyst must help the clients adjust to their new environment, and should help facilitate the
transition to the new system through good training, hand holding, and communication. .

The first few months of a new system is often the hardest time for clients. It is still a learning
phase to the client. Client will tend to make many mistakes. Some will be easily fixed through
the application, others will be more difficult to undo. The Analyst will often be called upon
during this time to explain the functionality of the system over and over again. The motto is
“Patience is virtue” through this phase of the deployment.


7) Maintenance
Ongoing maintenance of the system is a necessary step that ensures that the application
continues to support the business needs of the client in the future. Changes to keep up with
new business requirements, governmental compliance or industry shifts need to be implemented
within the system going forward. Depending on the volatility of the business at hand, it seems
that no sooner than you deploy a new system into production, that new requests begin to come in
to alter or extend the system.

System changes and alterations should be received via a System Service Request (SSR) forms.
Depending on the size, severity and impact to the application, the request form should include and
articulate all the benefits, and justification for the request in a way similar to a SSR request for a
new system. The SSR should once again be collected and presented to senior management (or
management committee) to ensure proper scheduling, prioritization and resource allocation.

If the change request is small (example less than a few days of effort), then A full SSR should
not be necessary. A business liaison or IT director should approve such requests. This will
eliminate burdening senior managements or approval committees from having to deal with many
insignificant requests.

How many years should an organization maintain an existing system prior to deciding to
develop a new one? There is no quick answer to this question. Many factors play into this
question, and IT management focuses much effort in monitoring the expended level of support an
application needs. How long to keep an application is a matter of financial economics.

At some point in the future life of an application an analysis needs to be taken to determine
trade-offs of a keep versus redevelop decision.


                                             Page 3 of 15
                                     Implementation and Operation



Program Coding
As stated earlier program coding is a time consuming, resource intensive activity. The basic task
and process of program coding has not changed since the early days of programming. However,
newer high level languages, and various development tools and environments have all made it
possible to speed up the process of program coding and testing. Using languages such as Java, C#
or Visual Basic with development tools such as Eclipse, IntelleJ, or Visual Studio allows for faster
development of program code and creates an environment that facilitates the testing, debugging
and integration of newly created code.

Another approach to the traditional programming processing is called eXtreme programming.
This approach is based on an idea by Kent Beck (2000) that stipulates short, incremental
development cycles involving iterative coding and testing, with automated test scripts, and strong
involvement from the client. A main staple of eXtreme programming is its reliance on a 2 person
development team (called “pair programming”) working together to produce faster, better
quality, more robust program code. In addition, other benefits of pair programming include
better communication between developers, knowledge sharing and transfer, and better
compliance to standards.


Code Reuse
It was not uncommon a while back to develop an entire application by coding every single line of
code from scratch. Such an approach would be very expensive today. In today’s environment
of object oriented approaches, it is very common to build an application using components that
are already available to the developer. Such components would either exist because other
members of the same IT organization have already developed those components for a previous
project, or the components are available from external sources. These third party components
are either available free of change from the vast resources of the internet, or are proprietary to a
vendor (example Sterling Software), at which case a purchase or licensing arrangement must be
made to acquire the component(s).

Organizations have found that software reuse reduced the cost of development, speeds up
time to delivery, and improves the quality of the overall product. This is true because most
reusable components have already been thoroughly tested by their creators and through many
previous uses by others.

To take full advantage of component reuse, strict standardization must be adhered to ensure
proper fit of outside components with developed code. Organizations have developed the role
of a librarian to encourage, assemble, catalog, and publish reusable components that can be
shared within the organization.

Currently most object reuse has been in area of graphical user interfaces, but other component
frameworks are being developed to assist in various business domains.




                                             Page 4 of 15
                                      Implementation and Operation




Code Walkthroughs
A code walkthrough (or code review) is an informal group oriented session where one or more
IT staff (typically more senior staff members) assembles to review the code developed by the
programmer. The informality of the session tends to ease apprehension and defensiveness on the
part of the developer. The purpose of a code walkthrough is to detect defects and errors in
the code. It is not to critique the code, or correct the code. It is simply to find the errors, or bad
coding judgments.


Code walkthroughs should be done early (and throughout) the development process so that the
structure of proper code and coding techniques is well planted in the program. Before those
programs are propagated to subsequent programs


As mentioned earlier, there are many steps and artifacts that should be reviewed through a
structured walkthrough. Some such as system specification should be more formal, others such as
code reviews should be less formal, and could be as simple as one-on-one setting.


Code walkthroughs have proven effective in ensuring the quality and robustness of the code being
developed. In addition, a code walkthroughs also ensure that development staff is following
standard for coding practices set by the organization, as well as adherence to any technical
standards. Another main benefit of code reviews is the sharing and passing of knowledge
between the developer staff within the organization (typically senior to junior, but sometimes the
other way too).




                                              Page 5 of 15
                                     Implementation and Operation



Testing
A program is not complete unless it is fully tested. It is the responsibility of every developer
to thoroughly test their newly developed code. Testing is a time consuming process, and most
developer hate to spend much time on the process, yet testing is an essential and integral part
of developing code.

There are many different types of testing processes that needs to be performed to ensure overall
viability of the new created system. These are:

      Unit or program testing
      Integration testing
      System testing
      User acceptance testing


Unit Testing
Unit or program testing involves taking each completed program or module (called a class in
Object Oriented terminology) and testing it independently of all other component of the system.
The purpose of this testing process is to discover any logical or functional errors that exist in the
code. Errors encountered are such that responses by the system are either not exactly what the
developer had expected, or are not exactly as the use case or program specification has dictated.


Integration Testing
In Object Oriented programming it is difficult to test an individual module by itself since most
objects interact with one another to complete a task. Integration testing is the act of adding the
newly created module (class) to the other parts of the application, and testing the module again
with emphasis on interaction of the new component with other components of the system
(which is still a work in progress). Once again, it is the responsibility of the developer to ensure
that his/her newly created module “fits” and integrates well with the rest of the system, and all
functionality promised by this new component are correct with respect to the specifications.


System Testing
System testing is similar to integration testing. However, system testing is performed when most
(and subsequently when all) modules have been completed and well integrated into the whole
system. Emphasis is usually on functionality that spans multiple components. System testing
is also when tests are performed with external interfaces to ensure that the connections of the
system with outside systems are correct and are behaving according to the specifications. Here
again the responsibility for system testing lies with the lead developers to ensure that overall
system meets specified objectives.



                                             Page 6 of 15
                                     Implementation and Operation




User Acceptance Testing (UAT)
Once the system tests have been completed satisfactory, the system is deployed into a separate
user environment to allow the client to test the system. This phase of system testing is called
user acceptance testing. The goal of acceptance testing is to ensure that the client is satisfied
with the overall functionality of the system, and is ready to sign-off on it. Depending on the
complexity of the system, there could be many iterating of testing in this phase. These are called:

   Alpha testing – Alpha testing is first few iteration of tests using dummy or simulated data
   Beta testing – Testing that is performed after applying fixes to errors discovered in alpha testing,
                      and testing with production quality/level of data.

Beta testing would also typically include a selected set of users who would be early adopters who
will test the application in the ultimate production environment. In essence beta testing is viewed
as a rehearsal step.


Another goal of the User Acceptance Testing is to ensure the accuracy of migrated data. Here
the client needs to ensure that all data that was meant to be copied, restructured and migrated to
the new system is now in the new system. Care must be taken to ensure that both detail and
summary level data is accurate and is exactly what is expected. Ad-hoc queries against the new
database could ensure accuracy of the migrated data. Detail and summary reports from both
the old and the new systems should help in the data reconciliation effort.


User acceptance testing should also include testing by internal audit or quality assurance groups.
These tests usually focus on data security and recovery in the event of system failure. Tests should
force the system or various critical transactions to fail to determine how the system reacts to such
failure events.


Stress tests and performance testing should also be included in User Acceptance Testing. The
goal of these tests is to determine if the level of data throughput, data integrity and response time
are all acceptable to the client.


All of the above tests should be planned accordingly. A UAT test plan should be developed as
a joint effort between the analyst and one or more key clients. The UAT test plan should include
many test cases. A test case is written to follow a specific scenario or path within a use case.
Test cases should be written to test the “all goes well” scenario, and well as to test other critical
“not so well” scenarios. Test cases should draw on the requirement documents (use cases) to
ensure that the system meets or perhaps exceeds those requirement objectives.




                                             Page 7 of 15
                                    Implementation and Operation



Deployment or Installation

When User Acceptance Testing is complete, and the client is fully satisfied with the various
functionalities of the system, and data has been properly migrated and reconciled, it is time to
sign off on the testing and deploy the application to the production environment. Once
deployed, all users of the old system must cease to use the old system and begin to use the new
one. The old system is now no longer being used to capture production data, and all processing
should now be handled by the new system.


You can install an application is one of many ways:

Cutover Installation: This is when you install the new application all at once.
                      It is a low cost solution, but with big risk impact on operations, especially
                      if errors are encountered. It might be too costly to restore the old system.




                                                  New System
                          Installation

                 Old System

                                    Time 



Parallel Installation: This is when you install the system along side the old one for some time.
                        Resource intensive on the part of the users. Low impact if errors encountered
                        The new system can be verified against the old system to ensure accuracy.




                                                      New System
                          Installation        Parallel

                     Old System

                                    Time 



                                            Page 8 of 15
                                      Implementation and Operation




Pilot Installation: This is when you install the system in one location using a pilot approach.
                      The first location is considered a pilot to allow learning and minimize impact
                      Installation can be cutover or parallel.



                                                                New System
                                       Installation
                                                                     Subsequent locations
                      Old System




                                                        New System
                      Installation
                                                                     Pilot / First location
            Old System


                                                  Time 


Phased Installation: This is when you phase in the application a few modules at a time
                      Minimized error impact. Supports RUP incremental development approach.
                      Difficult to coordinate both from client perspective and from IT perspective.
                      The old and new system must be able to work together and share data



                                                                   New system
                                               Install          with module 1 & 2
                                              module 2

                                     New System
                Install              with module 1
               module 1

         Old System
                                    Old system
                                 without module 1                   Old system
                                                               without module 1 & 2
                                                  Time 


                                              Page 9 of 15
                                    Implementation and Operation



Documentation

Although documentation should be performed throughout the life cycle of the development of
a system, it gets a more formal mention at this stage. This is because no system should be
delivered without proper documentation.

Documentation takes on many forms. It could be a collection of all the diagrams that were
created in the analysis and design phases. It could be use case narratives. It could be screen shots
and report templates. All these artifacts should be assembled properly to enable future staff (both
IT and clients) to understand the purpose and functionality of the system.


Documentation can be broken into 2 types. System documentation, and User documentation.

      System Documentation: This is all the detail documents and artifacts that were created
       in the planning, analysis, design and implementation phases of the project. It is the
       detailed information about a system’s design specifications, its inner workings, and its
       functionality.

       System documentation can be internal or external.

       Internal system documentations are ones that are created alongside the program code.
       They are the comments that the developer added to the code while coding the programs.
       It could also be documentation that is generated by Javadoc or some other programs that
       automatically create program documentation by inspecting the code or the comments that
       were inserted by the developer alongside the code.

       External system documentations are all the documents, diagrams and other artifacts
       manually created by the development team as part of development life cycle of the system.
       A shared system documentation folder should be created to house all these documents.
       The folder should be organized into subfolders each housing different types of documents.


      User Documentation: This is typically a user’s guide or manual explaining the
       various interactions with the system. User documentations are typically written in the
       user’s terminology, and describe step by step approaches of how to interact with the
       system to complete a specific function. User guides often include visual information such
       as screen shots before and after transaction entry.

       Sometimes a user manual is also converted into an online guide. This could be loaded
       into a sophisticated online user help facility that is connected to the application with
       context sensitive help and searches, or could simply be converted into web html format
       that can be accesses with any desktop browser. .




                                           Page 10 of 15
                                     Implementation and Operation



Training and Support
Training and support are critical to the success of any new system. Training and support help
ensure that people use the system as it was intend it to be used. Without proper training and the
opportunity to ask questions and gain further knowledge of the system users will misuse or
under utilize the application, and as a result waste valuable resources.

Training and support provide on-going educational and problem solving assistance to
information system users. Training materials must be design for targeted audiences of the
associated system


Training
One of the best ways to train users is by utilizing a local resident expert. This is the most effective
and most commonly used way to train users. A resident expert could be the systems analyst or the
system designer of the application. A resident expert could also be the client liaison who worked
with the IT staff to provide requirements and to help develop and test the application. Using a
resident expert has proven to be the most effective of all training techniques, and is least costly.
In addition users are most likely to turn to a local expert for help than to a formal instructor.

One effective technique to train many users is to train a few key users, and then let those few
trained users go further and train all other users. This is technique is called “train the trainer”
and has proven to also be a very effective training strategy with low overall cost.

Another effective strategy for training is to customize the training to targeted groups of users.
It often makes no sense to perform detail training to all users. If the user playing one specific role
with the application has nothing to do with the other area of the application, detail discussion of
that area, tend to disengage the client and make him/her lose attention. When targeted training is
presented however, it is important to ensure that prior to focusing on the individual area of
concern, a general and broad level explanation of the application and its overall purpose is
done prior to digging into the detail of the area.

Other types of training such as computer aided instructions, formal courses, help systems and
others are also possible, but these methods have proved less effective, and more costly.


Support
Supporting the ongoing user is another area that an IT organization needs to be concerned with.
Most IT organizations have created a single point of contact in the form of a help desk center.
This center provides users with first line of assistance in helping them with their computer or
application needs. Help center staff are training across many applications, and hardware platforms.
When a help center staff in unable to resolve the problem, or the problem is more application based
question, then he/she will contact the right IT staff to resolve the user query or problem.



                                             Page 11 of 15
                                    Implementation and Operation



System Maintenance
A significant amount of IT budget is typically devoted to the maintenance of existing systems.
Once an application has been deployed into the production environment, the development cost of
the application stops, and the maintenance cost begins.


There are many types and reasons for maintenance, these are:

Corrective Maintenance
This refers to changes made to repair design and coding or implementation flaws. Most of the
corrective maintenance issues will surface soon after the application is deployed into production.
When corrective maintenance problems arise, they are typically urgent and need immediate
mitigation.


Adaptive Maintenance
This refers to changes made to add functionality to the system to keep up with the changing
business requirements. This type of maintenance is less urgent than corrective maintenance, and
occurs over time and throughout the life of the application. This type of maintenance adds value
to the application, and ensures that the application remains a viable tool to help support the
business and the users of the application.


Perfective Maintenance
This refers to changes made to perfect or add “bells and whistles” to the application. This for
example involves enhancement to improve performance, improve the functionality of a user
interface, or to make the code more reusable. This type of maintenance is typically not urgent at
all, and often gets lowest priority. It is the type of maintenance that one will attempt to do in
between other projects.


Preventive Maintenance

This refers to changes made to safeguard against the chances of future system failures. For
example, ensuring that the database size or indexes are appropriate beyond current capacity, to
anticipate and to reflect future increases in the volume of data. Y2K is an example of preventive
maintenance. Depending on urgency, this type of maintenance is typically not urgent. It is the
type of maintenance that one will do in between other projects.




                                           Page 12 of 15
                                      Implementation and Operation



Measuring and Controlling Maintenance
Measuring the times between failures provides the basis for calculating mean time between failures
(MTBF). This measure tracks the average length of time between failures. When a new application
is deployed to production, the MTBF for the first few months will be low (short time between
failures). However, it is expected that the MTBF value should measurably increase after all
corrective maintenance have been addressed. If the MTBF is not increased rapidly within the
first few months, it is an indication that the quality of the application is shoddy.


Another revealing method measure and examine the type and frequency of the same failures.
If there is a pattern of failures, this will clue IT staff and management to the proper mitigation
action. Action could be a rewrite of a particular part of application with the help of a more senior
staff, or could simply be more training of the users.


An important part of measuring and controlling maintenance is the tracking and logging of
system failures and their resolutions. Tracking and logging failures is an invaluable tool to
help expedite and resolve ongoing and future problem. Tracking is also useful to measure
effectiveness of ongoing support. Has support been effective? Has is improved over time?


Certain types of maintenance that are urgent such as corrective maintenance need to be handled
immediately as data corruption is possible and/or data has already been corrupted and need to be
corrected quickly before more adverse impact to the system. Other types of maintenance, such
as enhancements (adaptive and perfective maintenance) need to be formalized through an SSR
(system service request form). They should be evaluated, categorized, prioritized and need to go
through the same approval process along with other system needs and enhancements requested
by other business clients.


Managing the queue of pending enhancements is an important task. It is not uncommon to
hear of a backlog of open system m enhancements. A log of all requested and incomplete
enhancements should be maintained. This log should be prioritized. Some enhancements may
never rise to the top due to low priority and resource constraints. Some enhancements might be
eliminated if the need is no longer needed due to a shift in business directions. Once an
enhancement is ready to be implemented and is next on the priority list, it should go through the
evaluation and approval mentioned in the previous paragraph.


Changes are usually made in batches. This allows for a structured SDLC process of analysis,
design, implementation, testing and re-deployment of the application. The application is usually
given a new version or release number, and the prior version or release is archived (but should
be easily re-accessible) in the event there is a need to restore to it, if the new software release is
immediately found to be faulty.




                                             Page 13 of 15
                                      Implementation and Operation



Maintenance Cost Factors
Information systems maintenance costs take a significant portion of the overall IT staff budget.
In some organization this could be as much as 60 percent or more of the overall programming
budget. This percent has risen of late, as more organizations find themselves having to maintain
more and more older legacy type systems. Numerous factors influence maintenance cost.
These are:

Latent defects
This is the number of unknown errors existing in the system after it is installed. Corrective
maintenance mitigates these errors. Because of the urgency and the possible data correction
corrective maintenance is resource intense, and is costly.

Number of users for the system
In general, the greater the number of users is, the greater the cost of maintenance. This is because
more users mean more potential for error discovery and reporting. More error reporting means
more corrective action, which leads to more cost. Also more users mean more false alarms, as
users might think that the system is faulty (due to lack of training) when in fact it is not, but time to
research and report is expended on false alarms.

Size of the system
Systems that are large tend to be complex in nature, and tend to support a critical business
areas The larger the system the more future maintenance and enhancement it will require to
maintain its viability, and its role in support of the critical client area.

Quality of Documentation

Without good documentation maintenance will be higher, and will increase over time.
Quality documentation makes it easy to read and understand program process and functions
without having to investigate the code. Quality documentation makes it easier to evaluate where
and how to insert new enhancements to the system, and why certain alternatives are better feasible
than others. This reduces time and decreases cost.

Quality of Staff

In some organization junior staff is dedicated to maintenance. They often take more time to
implement maintenance, and might introduce more errors into the code.

Well structured programs
Well designed and structured programs are easier to maintain, and as such reduce future
maintenance and enhancement costs


                                             Page 14 of 15
                    Implementation and Operation




  Maintenance in relation to the System Development Cycle




System maintenance and enhancements operate as repeated
         miniature system development cycles




                           Page 15 of 15

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:11
posted:10/14/2011
language:English
pages:15