LESSON 5 Information Systems Development II

MANAGEMENT INFORMATION SYSTEM

T O P I C S Learning Objectives
 Phases of System Development After completing this lesson, the learners
 System Development Life Cycle should be able to:
 Planning Phase
 Analysis Phase  explain the phases in the system
 Design Phase development life cycle
 Implementation Phase
 Operation and Maintenance Phase  identify the core activities in the
information systems development
process
 Alternative System-Building Approaches
 Prototyping
 describe the guidelines for system
 Application Software Package
development
 End-User Development
 Developing Systems with Teams: JAD and RAD  appraise other system-building
 Outsourcing alternatives
 Application Development for the Digital Firm

 Information System Security

Phases of System Development

System Development Life Cycle
Information systems development consists of phases, referred to collectively as the system development life cycle. The
system development life cycle (SDLC) is a very formal approach to building information systems and refers to all the activities
that go into producing an information systems solution to an organizational problem or opportunity. This methodology
assumes that an information system has a life cycle similar to that of any living organism, with a beginning, a working period,
and an end.

Figure 6. The system development

life cycle consists of five phases that
form a loop.

SDLC partitions the system

development process into
distinct phases and has an
organized set of activities that
Management Information System for an Educational Institution

guide people through the

development of an information
system. Some activities in the
SDLC may be performed at the
same time, while other activities
are performed sequentially.
Each activity involves interaction
with the organization.
Depending on the type and
complexity of the information
systems being developed, the
nature and duration of the
specific activities vary from one
system to the next. The activities
of the SDLC can be grouped into
the five major phases (Figure 6): planning, analysis, design, implementation, operation and maintenance. As shown in Figure
6, each phase in the system development cycle consists of a series of activities, and the phases form a loop. Information
systems development is an ongoing process for an organization. The phases in the SDLC form a loop, because when the
information system requires changing, which may happen for a variety of reasons such as information requirements of users
has changed or hardware and software become obsolete, the planning phases for a new or modified system begins and the 40
system development life cycle starts again. The goal of the SDLC is to keep the project under control and assure that the
information system developed satisfies the requirements. In theory, the five phases in the system development cycle often
appear sequentially, as shown in Figure 6. In reality, activities within adjacent phases often interact with one another--making
the system development cycle a dynamic iterative process. Members of the system development team follow established
guidelines during the entire system development cycle. They also interact with a variety of IT professionals and others during
the system development cycle.

Planning Phase
The initiation of a system development project may begin in many different ways. A system user requests a new or modified
information system for a variety of reasons, some external and some internal. An external reason is competition. For
example, once one bank offers Internet access to account information, others will have to follow suit, or run the risk of losing
customers. One internal reason for modifying an information system is to improve or enhance it. For example, if a school
wants to provide students with the ability to register for classes via the telephone, the school would have to modify the
existing registration system to include this enhancement. The most obvious internal reason for changing an information
system is to correct a business problem. For example, the stock-on-hand listed on a report may not match the actual stock-
on-hand in the warehouse. The planning phase for a project begins when the management receives a project request. If a
system project is called for, this phase identifies its general objectives, specifies the project’s scope, and develops a project
plan that can be shown to management. During the planning phase, five major activities are performed: (1) review and
approve the project request, (2) identify the objectives, (3) develop the project plan, (4) form a project team, and (5) allocate
resources such as money, people, and equipment to the approved project. If the management receives several projects
requests at the same time, the project requests should be prioritized. The projects that receive the highest priority are those
mandated by management or some other governing body. These requests are given immediate attention. The steering
committee evaluates the remaining project requests based on their value to the company. The steering committee approves
some projects and rejects others. Of the approved projects, it is likely that only a few will begin their system development
cycle immediately. Others will have to wait for additional funds or resources to become available.

Analysis Phase
System analysis is the analysis of the problem that the organization will try to solve with an information system. The analysis
phase consists of two major tasks: (1) conducting a preliminary investigation and (2) performing detailed analysis. The
detailed analysis further contains three activities: (a) study how the current system works; (b) determine the user's wants,
needs and requirements, and (c) recommend a solution. The preliminary investigation, also called the feasibility study, is a
user-oriented overview of the proposed information system's purpose and feasibility. The purpose of the preliminary
investigation is to define the problem or enhancement, identify its causes or sources, determine whether or not the problem
or enhancement identified is worth pursuing, and determine whether that projects is feasible, or achievable, given the
organization's resources and constraints. Should the company continue to assign resources to this project? To answer this
question, the systems analyst conducts a general study of the project and presents his or her findings in a report.

The most important aspect of the preliminary investigation is to define accurately the problem or enhancement. The
perceived problem or enhancement identified in the project request may or may not be the actual problem. In other words,
the actual problem may be different from the one suggested in the project request. For example, suppose the shipping
department complains that the marketing department takes too long to send customer names and addresses. An
investigation might reveal the marketing department is not the problem. The problem exists because the marketing
department does not have instant access to the customer names and addresses. The preliminary investigation begins with
an interview of the user who submitted the project request, and other users who will be affected by the project. In addition
to interviewing, members of the project team may use other data gathering techiques. During the preliminary investigation,
through examining documents and procedures, observing system operations, and interviewing key users, the development
Management Information System for an Educational Institution

team can identify the problem area and objectives to be achieved by the solution. Upon completion of the preliminary
investigation, the systems analyst writes the feasibility report that presents his/her findings and a recommendation to the
steering committee. The feasibility report contains these major parts: introduction, review of existing system, benefits of a
new system, feasibility of a new system, and the recommendation. Three major areas of feasibility must be addressed in the
report:

i. Technical Feasibility: whether the proposed information system can be implemented with the available hardware,
software, technical resources, and human resource.
ii. Economic Feasibility: whether the benefits of the proposed information system outweigh the costs.
iii. Operational Feasibility: whether the proposed solution is desirable within the existing managerial and
organizational framework and culture.

Normally the feasibility study will identify several alternative solutions that can be pursued by the organization. The written
feasibility report will assess the feasibility of each alternative, describe the costs and benefits, advantages and disadvantages
of each alternative, and give a recommendation. However, it is up to the steering committee to determine which mix of
costs, benefits, technical features, and organizational impacts represents the most desirable alternative. In some cases, the
project team may recommend not to continue the project. In other words, the team considers the project infeasible. If the
steering committee agrees, the project ends at this point. If the project team recommends continuing and the steering
committee approves this recommendation, however, then detailed analysis begins. 41
 Figure 7. Establishing information requirements requires close cooperation
among system analyst, users, and other specialists throughout the system
analysis phase.

The detailed analysis defines the specific information requirements

that must be met by the system solution selected and develops a
detailed description of the functions that the new system must
perform. This analysis involves three major activities: (1) study the
existing system in depth so you thoroughly understand the current
operations, uncover all possible problems and enhancements, and
determine the causes and effects of these problems or enhancements;
(2) determine the user's requirements for the proposed system, which
includes who needs what information, and when, where, and how the
information is needed; and (3) present alternative solutions to the
problem or enhancement and then recommend a proposed solution.
Perhaps the most difficult task of the detailed analysis is to define the
specific information requirements that must be met by the system.
Faulty requirement analysis is a leading cause of system failure and
high system development costs. An important benefit from studying
the existing system and determining user requirements is that these
activities build valuable relationships among the systems analyst and
users. The systems analyst has much more credibility with users if
he/she understands how the users currently perform their job
responsibilities and respects their concerns (Figure 7).

While studying the current system and identifying user requirements, the systems analyst collects a great deal of data and
information. A major task for the systems analyst is to document these findings in a way that can be understood by everyone.
Both users and IT professionals refer to this documentation. Most system analysts use either a process modeling or object
modeling approach to analysis and design. Process modeling is an analysis and design technique that describes processes
that transform inputs into outputs. Tools that a systems analyst uses for process modeling include entity-relationship
diagrams, data flow diagrams, and the project dictionary.

Management Information System for an Educational Institution

Figure 8. The ERD shows the relationships among entities in a system.

An entity-relationship diagram (ERD) is a tool that graphically shows the connections among entities in a system. An entity
is an object in the system that has data. Each relationship describes a connection between two entities. For example, in the
ERD shown in Figure 8, a vendor supplies one or more computers. A customer may or may not use one of these computers.
A customer may or may not place an order. Some customers may place multiple orders. Each order contains one or more
items from the menu. It is important that the systems analyst reviews the ERD with the user. After users approve the ERD,
the systems analyst identifies data items associated with an entity. For example, the VENDOR entity might have these data
items: Vendor Number, Vendor Name, Address, City, State, Postal Code, Telephone Number, and E-mail Address. A data
flow diagram (DFD) is a tool that graphically shows the flow of data in a system. The key elements of a DFD are the data
flows, the processes, the data stores, and the sources (Figure 9). A data flow, indicated by a line with an arrow, shows the 42
input or output of data or information into or out from a process. A process, which is drawn as a circle, transforms an input
data flow into an output data flow. A data store, shown as a rectangle with no sides, is a holding place for data and
information. A source, drawn as a square, identifies an entity outside the scope of the system. Source send data into the
system or receive information from the system. Like ERDs, systems analysts often use EFDs to review processes with users.

Figure 9. The DFD shows the flow of data in a system.

The project dictionary, sometimes called the repository, contains all the documentation and deliverables of a project. The
project dictionary helps everyone keep track of the huge amount of details in a system. The dictionary explains every item
found on DFDs an ERDs. Each process, data store, data flow, and source on every DFD has an entry in the project dictionary.
Every entity on the ERD has an entry in the project dictionary. The dictionary also contains an entry for each data item
associated with the entities. The number of entries added to the dictionary at this point can be enormous. As you might
imagine, this activity requires a huge amount of time. The system analyst uses a variety of techniques to enter these items
in the project dictionary. Some of these include structured English, decision tables, decision trees, and the data dictionary,
as shown in Figure 10.

(a) Structured English

Management Information System for an Educational Institution

(b) Decision Table

(c) Decision Tree

43
 (d) Data Dictionary

Figure 10. System analyst uses these techniques to describe a process in the project dictionary.

Another approach systems analysts can use is the object modeling, sometimes called object-oriented (OO) analysis and
design, which combines the data with the processes that act on that data into a single unit, called an object. An object is an
item that can contain both data and the procedures that read or manipulate that data. For example, a Customer object might
contain data about a customer (Customer ID, First Name, Last Name, Address, and so on) and instructions about how to print
a customer's record or the formula required to compute a customer's amount due. Each data element is called an attribute
or property. The procedure in the object, called an operation or method, contains activities that read and manipulate the
data. Object modeling can use the same tools as those used in process modeling. Many systems analysts, however, choose
to use tools defined in the UML (Unified Modeling Language). Although used in all types of business modeling, the UML has
been adopted as a standard notation for object modeling and development. The UML is a graphical tool that enables analysts
to document a system. It consists of many interrelated diagrams. Each diagram conveys a view of the systems. A popular tool
on the market today that uses the UML is the Rational Unified Process, which uses case diagram and class diagram, as shown
in Figure 11. After having studied the current system and determined all user requirements, the systems analyst
communicates possible solutions for the project in a system proposal. The purpose of the system proposal is to assess the
feasibility of each alternative solution and then recommend the most feasible solution for the project. The systems analyst
presents the system proposal to the steering committee. If the latter approves a solution, the project enters the design
phase.

Management Information System for an Educational Institution

(a) Case Diagram (b) Class Diagram

Figure 11. The case diagram and class diagram are two common tools in the UML.

Design Phase
Information analysis describes what an information system should do to meet information requirements, while information
systems design shows how the system will fulfill this objective. The design of an information system is the overall plan or
model for that system, which consists of all the specifications that give the system its form and structure. These specifications
should address all of the managerial, organizational, and technological components of the system solution. The design phase
consists of two major activities: logical design and physical design. Logical design lays out the logical model that describes
the components of the system and their relationship to each other as they would appear to the users. It describes inputs and
outputs, processing functions to be performed, business procedures, data models and controls. Controls specify standards
for acceptable performance and methods for measuring actual performance in relation to these standards. After the systems
analyst identifies the data and process requirements, the next step is to develop detailed specifications for the components
in the proposed solutions. A detailed design sometimes is called a physical design. Physical design is the process of translating
the abstract logical model into the specific technical design for the new system. It produces the specifications for hardware,
44
software, physical databases, input/output media and format, networking, manual procedures, and specific controls.
Physical design develops all of the details of the information system to be implemented with respect to functionality,
features, and performance. To obtain these specifications, the systems analyst researches using a variety of techniques such
as talking with other analysts, visiting vendor's stores, surfing the Web, and reviewing written technical materials. Many
trade journals, newspapers, and magazines provide some or all of their printed content as e-zines. An e-zine, or electronic
magazine, is a publication available on the Web.

Figure 12. This input screen is a mockup for users to review and approval.

Management Information System for an Educational Institution

Figure 13. This is the layout chart for the mockup in Figure 12.

During database design, the system analyst builds upon the data dictionary developed during the analysis phase. The systems
analyst works closely with the database analysts and database administrators to identify those data elements that currently
exist within the company and those that are new. With relational database systems, the systems analyst defines the structure
of each table in the system, as well as relationships among the tables. The systems analyst also addresses user access
privileges. That is, the systems analyst defines which data elements each user can access, when they can access the data
elements, what actions they can perform on the data elements, and under what circumstances they can access the elements.
The result of database design is called a data model. During the input and output design, the systems analyst carefully
designs every menu, screen, and report specified in the requirements. The outputs often are designed first because they
help define the requirements for the inputs. Thus, it is very important that outputs are identified correctly and that users
agree to them. The systems analyst typically develops two types of designs for each input and output: a mockup and a layout
chart. A mockup is a sample of the input or output that contains actual data (Figure 12). The systems analyst shows mockups
to users for their approval. Because users will work with the inputs and outputs of the system, it is crucial to involve users
during input and output design. After users approve the mockup, the systems analyst develops a layout chart for the 45
programmer. A layout chart is more technical and contains programming-like notations for the data items (Figure 13). Other
issues that must be addressed during input and output design include the types of media to use (paper, video, audio); formats
(graphical or narrative); and data entry validation techniques, which make sure the entered data is correct. During program
design, the systems analyst prepares the program specification package, which identifies the required programs and the
relationship among each program, as well as the input, output, and database specifications. Many people should review the
detailed design specifications before they are given to the programming team. Reviewers should include users, systems
analysts, managers, IT staff, and members of the system development team. One popular review technique is an inspection.
An inspection is a formal review of any system development cycle deliverable. A team of four or five people examines the
deliverables, such as reports, diagrams, mockups, layout charts, and dictionary entries. The purpose of an inspection is to
identify errors in the item being inspected. Any identified errors are summarized in a report so they can be addressed and
corrected. Once again, the systems analyst reevaluates feasibility to determine if it still beneficial to proceed with the
proposed solution. If the steering committee decides the project still is feasible, which usually is the case, the project enters
the implementation phase.

Implementation Phase
Once the design is completed, the project enters the implementation phase. The implementation phase converts the system
specifications established during systems analysis and design phases into a fully operational information system. The purpose
of this phase is to construct the new or enhanced system and then deliver it to the users. Five major activities are performed
in this phase: (1) acquire necessary hardware and software; (2) develop computer programs if necessary; (3) install and test
the new system; (4) train and educate users; and (5) convert to the new system. According to the specifications in the system
design, the system analyst sends either a request for quotation or a request for proposal to prospective hardware and
software vendors. A request for quotation (RFQ) is used when you know which products you want. The vendor quotes prices
for the specified products. A request for proposal (RFP) is used when you want the vendor to select the products that meets
your requirements and them quote the prices. Systems analysts have a variety of ways to locate vendors. Many publish their
product catalogs on the Web. These online catalogs provide up-to-date information on and easy access to products, prices,
technical specifications, and ordering information. Another source for hardware and software products is a value-added
reseller. A value-added reseller (VAR) is a company that purchases products from manufacturers and then resells these
products to the public--offering additional services with the product. Examples of additional services include user support,
equipment maintenance, training, installation, and warranties. Instead of using vendors, some companies hire IT consultants;
that is, they outsource this task. An IT consultant is a professional who is hired based on computer expertise, including service
and advice. IT consultants often specialize in configuring hardware and software for businesses of all sizes.

After you receive completed quotations and proposals from the potential vendors, you must evaluate vendor proposals and
then select the best one. It is a difficult task. It is important to be as objective as possible while evaluating each proposal. A
popular technique is to establish a scoring system that you can use to rate each proposal. System analysts use many
techniques to test the various software products from vendors. They obtain a list of user references from the software
vendors. They also talk to current users of the software to solicit their opinions. Some vendors will give a demonstration of
the product specified. Other vendors provide demonstration copies to test the software themselves. Demonstration copies
usually are free and have limited functionality. Trial versions are free or have minimal fees and provide full functionality for
a set time. In some cases, the demonstration copies and trial versions are available to download from the Web.

Sometimes it is important to know whether the software can process a certain volume of transactions efficiently. In this case,
the systems analyst conducts a benchmark test. A benchmark test measures the performance of hardware or software. For
example, a benchmark test could measure the time it takes a billing program to print 50 billing statements. Some computer
magazines conduct benchmark tests while evaluating hardware and software and then publish these results for consumers
to review. Having rated the proposals, the systems analyst presents a recommendation to the steering committee. The
recommendation could be to award a contract to a vendor or to not make any purchases at this time. If the project
development team decides to write custom software, instead of purchasing packaged software, then the programmers will
Management Information System for an Educational Institution

develop programs from the program specification package created during analysis and design. It is here, called programming,
that system specifications are translated into program code, the actual instructions for the machine. Like the system
development life cycle, program development also follows an organized set of activities, called program development life
cycle (PDLC). The PDLC is an important part of the implementation phase. If new hardware was acquired, the hardware must
be installed and tested at this point. Both packaged software and custom software programs have to install on the hardware.
It is extremely important that the hardware and software be tested thoroughly. Inadequate system testing will lead to serious
problems or even disaster to the organization. Just as you test individual programs, you must test the entire information
system to ensure that the programs and hardware operate together to accomplish the desired functions. System tests
frequently uncover inconsistencies among programs as well as inconsistencies in the original hardware or software
specification. It is better to find errors so you can correct them before putting the system into production; that is delivering
it to the users. Testing an information system can be broken down into four types of activities:

1. Unit Testing: test each program separately in the system. The purpose of such testing is to guarantee that programs
are error-free.
2. System Testing: test the functioning of the information system as a whole and verify that all programs in the system
work together properly.
3. Integration Testing: verify that the information system works well with other systems.

46
 4. Acceptance Testing: provide the final certification that the system is ready to be used in a production setting.
System tests are evaluated by users and reviewed by management. When all parties are satisfied that the new
system meets their standards, the system is formally accepted for the conversion.

For an information system to be effective, users must be trained properly on its functionality. They must be trained on how
to use both the hardware and the software. According to a recent study, poor user training is one of the top ten reasons why
system development projects fail. Users must be trained properly on a system's functionality. Training is the process of
ensuring that system users know what they need to know about both the work system and the information system. Training
shows the users exactly how they will use the new hardware and software in the system. Training may take place as
classroom-style lectures or Web-based training that is a self-directed, self-paced online instruction method. The training
format depends on user backgrounds and the purpose and features of both work system and the information system.
Companies can also provide education to the users. Education is the process of learning new principles or theories that help
users understand the system. For example, many companies do their businesses electronically. In this case, employees need
to be educated on the concepts and practices of E-commerce. The final implementation activity is to change from the old
system to the new system. This process is called a conversion. This conversion can take place using one or more of the
following conversion strategies (Figure 14):

Figure 14. Converting from the old system to the new system usually follows one of these strategies.

 Direct cutover strategy: With direct cutover strategy, users stop using the old system and begin using the new
system on a certain date. The advantage of this strategy is that it requires no transition costs and is a quick
implementation technique. The disadvantage is that it is extremely risk and can disrupt operations seriously if the
Management Information System for an Educational Institution

new system does not work correctly, since there is no other system to fall back on.
 Parallel strategy: Both the old system and its potential replacement are running together for a specified time
period until it is assured that the new one functions correctly. The advantage of this strategy is that any problems
with the new system can be solved before the old system is terminated. The disadvantage is that it is very expensive
since additional staff or resources may be required to run the extra system.
 Phased strategy: This strategy introduces the new system in stages, either by functions or by organizational units.
Each function or organizational unit is converted separately at different times using either a direct cutover or
parallel conversion. This strategy is often used with larger systems that are split into individual sites.
 Pilot strategy: This strategy introduces the new system to only a limited area of the organization, such as a single
department or operating unit. When this pilot version is complete and working smoothly and correctly, it is
installed throughout the rest of the organization, using one of the aforementioned conversion strategies.

Operation and Maintenance Phase

After the new system is installed and conversion is complete, the system is said to be in production or operation. The
information systems specialists maintain the information system and provide its users with ongoing assistance during its
operation period. This phase consists of four major activities: (1) conducting a post-implementation system review; (2)
47
correcting errors; (3) identifying enhancements; and (4) monitoring system performance. One of the first activities the
company performs is to meet with users. The purpose of this meeting, called the post-implementation system review, is to
discover whether the information system is performing according to the users' expectations. Both users and technical
specialists will review the information system to determine how well it has met its original objectives and to decide whether
any revisions or modifications are in order. If the system is not meeting the users' expectations, the systems analyst must
determine what must be done to satisfy the users--back to the planning phase. Sometimes users identify errors in the system
when the program does not produce correct results. Problems with design (logic) usually are the cause of these errors. For
example, the total of a column might be incorrect on a daily order summary. These types of errors require investigation--
back to the planning phase. If the users would like the system to do more, that is, they have additional requirements, the
system analyst must decide how to enhance the existing system to satisfy the users. System enhancement involves modifying
or expanding an existing information system--back to the planning phase. The system analyst monitors the system to
determine if the system is inefficient at any point and if the inefficiency is causing a problem. Changes in hardware, software,
documentation, or procedures to an existing system to correct errors, meet new requirements, or improve processing
efficiency means that we begin planning all over again. Thus, the loop forms in the system development life cycle.

CASE Tools
Many systems analysts use computer software to assist in the SDLC. Computer-aided software engineering (CASE) software
tools are designed to support a variety of activities of the SDLC. CASE tools typically include diagrams to support both process
and object modeling. Some CASE tools exist separately. One program might be a dictionary and another might allow you to
create drawings. The most effective tools are integrated (see Figure 15).

Figure 15. CASE tools can assist systems and developers in their development processes.

The purpose of these tools is to increase the efficiency and productivity of the project development team. Usually an
integrated CASE product includes the following capabilities:

 Graphics -- Enables the drawing of diagrams.

Management Information System for an Educational Institution

 Modeling -- Creates models of the proposed system.

 Code Generators -- Create actual computer programs from design specifications.
 Project Repository -- Stores diagrams, specifications, descriptions, programs, and any other deliverable generated
during the SDLC.
 Quality Assurance -- Analyzes deliverables, such as graphs and the data dictionary for accuracy.
 Housekeeping -- Establishes user accounts and provides backup and recovery functions.

Alternative System-Building Approaches

Systems differ in terms of their size and technological complexity, and in terms of the organizational problems they are meant
to solve. Because there different kinds of systems, a number of methods have been developed to build systems. This sections
describes these other alternative methods: prototyping, application software packages, end-user development, JAD/RAD,
and outsourcing.

48
Prototyping
A major problem with the traditional SDLC is that the user does not use the solution until the system is nearly complete. The
traditional approach is also inflexible -- changes in user requirements cannot be accommodated during development. One
of alternative approaches to system development is the prototyping. Prototyping takes an iterative approach to the systems
development process. During each iteration, requirements and alternative solutions to the problem are identified and
analyzed, new solutions are designed, and a portion of the system is implemented. Users are then encouraged to try the
prototype and provide feedback. The prototype is a working version of an information system or part of the system, but it
meant to be only a preliminary model. During the development process, the prototype will be further refined until it
conforms precisely to users' requirements. For many applications, a prototype will be extended and enhanced many times
before a final design is accepted. Once the design has been finalized, the prototype can be converted to a polished production
system.

Figure 16. Prototyping is a popular technique in systems

development. Each generation of prototype is a refinement
of the previous generation based on user feedback.

Prototyping is less formal than the development life

cycle method. Instead of generating detailed
specifications and sign-off documents, prototyping
quickly generates a working model of a system.
Requirements are determined dynamically as the
prototype is constructed. Systems analysis, design,
and implementation all take place at the same time.
The process of building a preliminary design, trying
it out, refining it, and trying again has been called an
iterative process of systems development because
the steps required to build a system can be repeated
over and over again. Figure 16 shows a model of the
prototyping process. Prototyping process consists of
the following steps:

1. Determine requirements: The system

developer works with users to identify the users'
basic information needs.
2. Develop a working prototype: The system
developer creates a preliminary model of a major
subsystem or a scaled-down version of the entire
system.
3. Use the prototype: The developer let users
work with the working prototype to determine how well the prototype meets their needs and to make suggestions
for improving the prototype.
4. Revise and enhance the prototype: The developer refines the prototype according to the users' requests. After
the prototype has been revised, the cycle returns to step 3. The steps 3 and 4 are repeated until the user is satisfied.
When no more iteration is required, the approved prototype then becomes an operational system.

Prototyping is most useful when there is some uncertainty about requirements or design solutions. Requirements may be
difficult to specify in advance or they may change substantially as implementation progresses. This is particularly true of
decision-oriented applications, where requirements tend to be very vague. Prototyping is also valuable for the design of the
Management Information System for an Educational Institution

end-user interface of an information system (the part of the system that end users interact with, such as online display and
data entry screens, reports, or Web pages). User needs and behaviors are not entirely predictable and are strongly dependent
on the context of the situation. Because prototyping encourages intense end-user involvement throughout the systems
development process, it is more likely to produce systems that fulfill user requirements. However, rapid prototyping can
gloss over essential steps in systems development. If the completed prototype works reasonably well, management may not
see the need for reprogramming, redesign, or full documentation and testing to build a polished production system. Some
of these hastily constructed systems may not easily accommodate large quantities of data or a large number of users in a
production environment.

Application Software Packages

Information systems can be built using software from application software packages. There are many applications that are
common to all business organizations--for example, payroll accounts receivable, general ledger, or inventory control. For
such universal functions with standard processes that do not change a great deal over time, a generalized system will fulfill
the requirements of many organizations. If a software package can fulfill all of an organization's requirements, the company
does not have to write its own software. The company can save time and money by using the prewritten, predesigned,
pretested software programs from the package. Package vendors supply much of the ongoing maintenance and support for
the system, including enhancements to keep the system in line with ongoing technical and business developments. If an
49
organization ahs unique requirements that the package does not address, many packages include capabilities for
customization. Customization features allow a software package to be modified to meet an organization's unique
requirements without destroying the integrity of the package software. If a great deal of customization is required, additional
programming and customization work may become so expensive and time consuming that they eliminate many of the
advantages of software packages.

When a system is developed using an application software package, system analysis will include a package evaluation effort.
The most important evaluation criteria are the functions provided by the package, flexibility, user-friendliness, hardware and
software resources, database requirements, installation and maintenance effort, documentation, vendor quality, and cost.
The package evaluation process often is based on a Request for Proposal (REP). When a software package solution is
selected, the organization no longer has total control over the system design process. Instead of tailoring the system design
specifications directly to user requirements, the design effort will consist of trying to mold user requirements to conform to
the features of the package. If the organization's requirements conflict with the way the package works and the package
cannot be customized, the organization will have to adapt to the package and change its procedures. Even if the
organization's business processes seem compatible with those supported by a a software package, the package may be too
constraining if these business processes are continually changing. A new company that was just being set up could adopt the
business processes and information flows provided by the package as its own business processes. But organizations that
have been in existence for some time may not be able to easily change the way they work to conform to the package.

End-User Development
One of the most difficult steps in creating any new system is determining the user requirements. What does the system need
to do and how will it work? This step is crucial. If the designers make a mistake here, the system will either be useless or will
need expensive modifications later. SDLC and prototyping take different approaches to this problem. With SDLC, analysts
talk with users and write reports that describe how the system will operate. User examine the reports and make changes.
This approach is time consuming and difficult for users because they only see paper notes of the proposed system.
Prototyping overcomes some of the problems by letting users work with actual screens and reports. But use of prototyping
is hard to expand beyond one or two users.

Designing and developing systems is much easier if the entire system can be built by one person. In fact, that is one of the
strengths of recent tools -- they enable a single person to build more complex systems. The term end-user development
simply means that users do all of the development work themselves. Using fourth-generation languages, graphics languages,
and PC software tools, end users can access data, create reports, build business models, and develop entire information
systems on their own, with little or no help from professional systems analysts or programmers. Many of these end-user
developed systems can be created much more rapidly than the traditional systems life cycle. Clearly the main advantage is
that users get what they want without waiting for an IS team and without the difficulty of trying to describe the business
problems to someone else. Two basic reasons explain why end-user development is increasingly popular. First, most IS teams
are facing a two- or three-year backlog of projects. That means that if you bring a new project to the IS team, the designers
will not even start on it for at least two years. The second reason is that software tools are getting more powerful and easier
to use at the same time. Today, it is possible for managers to create a business model and solve a business problem with a
spreadsheet in a few hours that 10 years ago would have taken IS programmers a month to build with third-generation
languages. As tools become more powerful and more integrated, it becomes possible to create even more complex systems.

Many organizations have reported gains in application development productivity by using end-user computing approach that
in a few cases have reached 300 to 500 percent. Allowing users to specify their own business needs improves requirements
gathering and often leads to higher level of user involvement and satisfaction with the system. However, end-user computing
still cannot replace conventional methods for some business applications because the end users cannot easily handle the
complexity of large transactions or applications with extensive procedural logic and updating requirements. The potential
problems of end-user development are not always easy to see. Most of them arise from the fact that users generally lack the
Management Information System for an Educational Institution

training an experience of systems analysts and programmers. For instance, systems produced by end users tend to be written
for only one person to use. They are oriented to working on stand-alone personal computers. The systems are often
customized to fit the needs of the original users. The systems lack security controls and are hard to modify.

Other problems stem from the bottom-up approach inherent in end-user development. People in different areas of the
company will wind up working on the same problem, when it could have been solved once by IS teams. Data tends to be
scattered throughout the company, making it hard to share and wasting space. Not following standards generates
incompatibilities among systems, making it difficult to combine systems created by different departments or even by people
within the same department. The end-user computing poses organizational risks because it occurs outside of traditional
mechanisms for information system management and control. When systems are created rapidly, without a formal
development methodology, testing and documentation may be inadequate. Control over data can be in systems outside the
traditional information systems department. The last, and possibly most import, complication is that end-user development
takes time away from the user's job. Some users spend months creating and modifying systems that might have been created
by IS programmers in a fraction of the time. One of the reasons for creating an IS department is to gain efficiency from using
specialists.

To help organizations maximize the benefits of end-user applications development, management should control the
development of end-user applications by requiring cost justification of end-user information system projects and by
establishing hardware, software, and quality standards for user-developed applications. Some organizations use information
50
centers to promote standards for hardware and software so that end users could not introduce many disparate and
incompatible technologies into the firm. Information centers are special facilities housing hardware, software, ad technical
specialists to supply end users with tools, training, and expert advice so they can create information system applications on
their won or increase their productivity. The role of information centers is diminishing as end-users become more computer
literate, but organizations still need to closely monitor and manage end-user development.

Developing Systems with Teams: JAD and RAD

Many information systems, especially those that affect the entire organization, require teams of IS workers. As soon as
multiple designers, analysts, and programmers are involved, we encounter management and communication problems. MIS
researchers have measured the effects of these problems. For example, one study by Jones showed that team activities
accounted for 85 percent of the development costs. These seem to be substantial areas for improvement in systems
development by focusing on teamwork.

A technique known as joint application design (JAD) was created to accelerate the generation of information requirements
and to develop the initial systems design. With JAD the main system is designed in an intense three- to five-day workshop.
Users, managers, and systems analysts participate in a series of intense meetings to design the inputs and outputs needed
by the new system. By putting all of the decision makers in one room at the same time, conflicts are identified and resolved
faster. Users and managers gain a better understanding of the problems and limitations of technology. The resulting system
has greater value for users and managers because it more closely matches their needs. There is less need for changes later,
when they become more expensive, so the system is cheaper to create. Properly prepared and facilitated, JAD sessions can
significantly speed the design phase while involving users at an intense level.

The biggest drawback to JAD is that it requires getting everyone together at the same time for an extended period of time.
Even for moderately complex system, the meetings can run eight hours a day for three to five days. Most managers and
users find it difficult to be away from their jobs for that length of time. Higher-level managers are also needed at these
meetings to ensure the system provides the appropriate reports and information. Finally, the meetings can only succeed if
they are led by a trained facilitator. The facilitator keeps the discussions moving in the right direction, minimizes conflicts,
and encourages everyone to participate. At the end of the sessions, the systems development team should have a complete
description of the proposed system.

By providing advanced development tools, pre-built objects, and collaboration tools, some companies have found it is
possible to reduce the overall development time. The key is to target steps that can overlap and be performed by multiple
teams. By improving the collaboration tools, more steps can be compressed. Many e-commerce projects were developed
with rapid application development (RAD) techniques. RAD is used to describe the process of creating workable systems in a
very short period of time. RAD can include the use of visual programming and other tools for building graphical user
interfaces, iterative prototyping of key system elements, the automation of program code generation, and close teamwork
among end users and information systems specialists. RAD applies the value of teamwork to the developers. Firms are
concerned about being the first in the market and feel they need to develop software rapidly. Systems often can be
assembled from pre-built components. The process does not have to be sequential, and key parts of development can occur
simultaneously. The techniques of using small groups of programmers using advanced tools, collaboration, and intense
programming sessions was relatively successful at quickly producing thousands of new applications.

Outsourcing
If a firm does not want to use its internal resources to build or operate information systems, it can hire an external
organization that specializes in providing these services to do the work. The process of turning over an organization's
computer center operations, telecommunications networks, or applications development to external vendors is called
Management Information System for an Educational Institution

outsourcing. The application service providers (ASPs) are one form of outsourcing. Subscribing companies would use the
software and computer hardware provided by the ASP as the technical platform for their system. In another form of
outsourcing, a company would hire an external vendor to design and create the software for its system, but that company
would operate the system on its own computer. Outsourcing has become popular because some organizations perceive it
as more cost effective than maintaining their own computer center or information systems staff. The provider of outsourcing
services benefits from economies of scale (the same knowledge, skills, and capacity can be shared with many different
customers) and is likely to charge competitive prices for information systems services. Outsourcing allows a company with
fluctuating needs for computer processing to pay for only what it uses rather than to build its own computer center, which
would be underutilized when there is no peak load. Some firms outsource because their internal information systems staff
cannot keep pace with technological change or innovative business practices or because they want to free up scarce and
costly talent for activities with higher payback.

Not all organizations benefit from outsourcing, and the disadvantages of outsourcing can create serious problems for
organizations if they are not well understood and managed. Many firms underestimate costs for identifying and evaluating
vendors of information technology services, for transitioning to a new vendor, and for monitoring vendors to make sure they
are fulfilling their contractual obligations. These "hidden costs" can easily undercut anticipated benefits from outsourcing.
When a firm allocates the responsibility for developing and operating its information systems to another organization, it can
lose control over its information systems function. If the organization lacks the expertise to negotiate a sound contract, the
firm's dependency on the vendor could result in high costs or loss of control over technological direction. Firms should be 51
especially cautious when using an outsourcer to develop or to operate applications that give it some type of competitive
advantage.

Application Development for the Digital Firm

Increasingly, companies are converting at least some portion of their business to run over the Internet, intranets, or
extranets. An important trend in systems development is that business applications are been moving to the Internet to
support selling products to customers, placing orders with suppliers, and letting customers and/or suppliers access
information about production, inventory, orders, or accounts receivable. Internet technology provides a platform for
applications that enables companies to extend their transaction processing systems beyond the boundaries of the
organization to their customers, suppliers, and partners. This enables companies to conduct business much faster, interact
with more people, and try to keep one step ahead of the competition.

Building a dynamic core business application that runs over the Web is much more complicated. Such applications must meet
special business needs. They must be able to scale up to support highly variable transaction throughput from potentially
thousands of users. Ideally, they can scale up instantly when needed. They must be reliable and fault tolerant, providing
continuous availability while processing all transactions accurately. They must also integrate with existing infrastructure,
including customer and order databases, existing applications, and enterprise resource planning systems. Development and
maintenance must be quick and easy, as business needs may require changing applications on the fly. In the digital firm
environment, organizations need to be able to add, change, and retire their technology capabilities very rapidly. Companies
are adopting shorter, more informal development processes for many of their e-commerce and e-business applications,
processes that provide fast solutions that do not disrupt their core transaction processing systems and organizational
databases. They are relying more heavily on fast-cycle techniques such as JAD, prototypes, and reusable standardized
software components that can be assembled into a complete set of services for e-commerce and e-business.

In summary, systems development can be a difficult task. Many projects have failed because they cost much more than
anticipated or they did not produce useful systems. All development methods introduced in this chapter involve five basic
steps: feasibility and planning, systems analysis, design, implementation, and maintenance. Prototyping and end-user
development typically focus on the design stage. However, managers need to remember that implementation problems can
arise with any new system, regardless of how it was created. The following table compares the advantages and disadvantages
of each of the system-building alternatives.

Approach Features Advantages Disadvantages

 Sequential step-by-step  Necessary for large  Slow and expensive
Systems life
formal process complex systems and  Discourages changes
cycle
 Written specification projects  Massive paperwork to
and approvals manage
 limited role of users
 Requirements specified  Rapid and relatively  Inappropriate for large,
dynamically with inexpensive complex systems
experimental system  Useful when  Can gloss over steps in
 Rapid, informal, and requirements uncertain analysis,
Prototyping iterative process or when end-user documentation, and
 Users continually interface is very testing
interact with the important
prototype  Promotes user
Management Information System for an Educational Institution

participation
 Commercial software  Design, programming,  May not meet
eliminates need for installation, and organization's unique
internally developed maintenance work requirements
software programs reduced  May not perform many
Applications  Can save time and cost business functions well
software when developing  Extensive customization
package common business raises development
applications costs
 Reduces need for
internal information
systems resources
 Systems created by end  User control systems-  Can lead to
users using forth- building proliferation of
End-user
computing
generation software  Saves development time uncontrolled
tools and cost information systems
 Rapid and informal and data
52
  Minimal role of  Reduces application  Systems do not always
information systems backlog meet quality assurance
specialists standards
 Systems built and  Can reduce or control  Loss of control over the
sometimes operated by costs information systems
external vendor  Can produce systems function
Outsourcing when internal resources  Dependence on the
are not available or technical direction and
technically deficient prosperity of external
vendors

Information System Security

Most organizations must deal with complex system security issues. All elements of an information system--hardware,
software, data, people, telecommunications, and procedure--must be secure from threats both inside and outside the
enterprise. For example, users should be allowed access only to the data and information for which they are authorized,
which typically is limited to the amount necessary to do their job. Data should be secure so intruders cannot alter, damage,
or steal data. Networks need safeguards to prevent them from being compromised.

Companies today often have a chief security officer (CSO) who is responsible for physical security of a company's property
and people and also is in charge of securing computing resources. It is critical that the CSO is included in all system
development projects to ensure that all projects adequately address information security. The CSO uses many techniques to
maintain confidentiality or limited access to information, ensure integrity and reliability of systems, ensure uninterrupted
availability of systems, ensure compliance with laws, and cooperate with law enforcement agencies. An important
responsibility of the CSO is to develop a system security plan. A system security plan summarizes in writing all of the
safeguards that are in place to protect a company's information assets. A system security plan should do the following:

1. Identify all information assets of an organization, including hardware, software, documentation, procedures,
people, data, facilities, and supplies.
2. Identify all security risks that may cause an information asset loss. Rank risks from most likely to occur to least
likely to occur. Place an estimated value on each risk, including the value of lost business. For example, what is
the estimated loss if customers cannot access computers for one hour, one day, or one week?
3. For each risk, identify the safeguards that exist to detect, prevent, an recover from a loss.

The CSO should evaluate the system security plan annually or more frequently for major changes in information assets, such
as the addition of a new computer or the implementation of a new application. In developing the plan, the CSO should
recognize that some degree of risk is unavoidable; the more secure a system is, the more difficult it is for everyone to use.
The goal of a system security plan is to match an appropriate level of safeguards against the identified risks.

Management Information System for an Educational Institution

53
Study Guide for Lesson 5
What are the phases of
system development? Cite
a particular organization
for its application.

What are the advantages

and disadvantages of
planning the core
activities in IS
development process?

Your company’s financial

needs are almost the same
as those of all the other
companies in the industry.
Would you recommend
that your company
purchase an existing
system or build a custom
system? Discuss its
consequences.

Depending on the needs of

your organization, what
are the suitable guidelines
for developing an
information system?

What happens after the

Management Information System for an Educational Institution

system is implemented?
What can you do to ensure
the system continues to
meet the knowledge
workers’ needs?

A S S I G N M E N T
Connect to the Internet and several sites that offer freeware and shareware on human resource management. Install and
try it in your computer. Explain on how did it answered the computing needs of your company.
54