Chapter 2

Information Systems Development

This chapter provides an overview of the systems development life cycle model and an
overview of information systems development project management. It discusses three
fundamental information systems development strategies: systems acquisition, systems
construction, and outsourcing. It also introduces MERISE, a design and analysis method for
information systems.

2.1 Systems development life cycle

The systems development life cycle (SDLC) is a conceptual model of the phases an
information system goes through. The typical systems development life cycle model suggests
five fundamental phases of information systems development process: planning, analysis,
design, implementation, and maintenance, as depicted in Figure 2.1

Figure 2.1: Systems Development Life Cycle (SDLC)

The SDLC model provides a general guideline for the information systems development in
two aspects:

 The system development process of an information system must move through these
five phases. Although the pattern of how an information system goes through these
phases depends on the approach used for the information system development, as
discussed in detail in the following chapters of this book, a successful information
systems development process can never omit any of these five phases.
 Each of these five phases produces a set of products, called deliverable, which is used
as the input to its successor phase. Each phase elaborates on the work of its predecessor
 phase. The structures and forms of the deliverables of each phase can vary depending
on the approaches used for the information system development. The quality of the
deliverables affects the quality of the entire information system development project.
The planning phase is the process of preliminary investigation to understand why a new
information system should be created for the organization. The deliverable of the planning
phase includes a report of the feasibility study and the workplan for the new information system
development project. Once the organization decides to create a new information system, a full-
scale project of information system development is then started.
The analysis phase is the first stage of the full-scale information system development project
to investigate what the new information system will do. In this phase, the project team fully
investigates the current information system (or the as-is system) of the organization and the
specific business needs (or the system requirements) for the new information system. The new
information system that meets the system requirements is called the to-be system. The
deliverable of the analysis phase reports on the following major system analysis results.

 The differences between the as-is system and to-be system;

 The system requirements for the to-be system;
 The strategy of system development for the design phase.
The deliverable of the system analysis phase actually presents a blueprint for the new
information system.
The design phase determines how the to-be system will be created and how it
will operate in terms of hardware, software, networking, system personnel, and
operational procedures. The deliverables of the design phase are the detailed system
specifications of system infrastructure, hardware, software, and networking for the
implementation phase. The design phase actually provides the solution to the to-be
system.
The implementation phase builds the new information system based on the
system specifications provided by the design phase. The methods applied to the system
implementation phase vary depending on the strategies of systems development, as discussed
in detail later in this book. By the end of the implementation phase, the new information system
replaces the old information system. The business environment changes constantly. Also, the
newly built information system might need improvement. The maintenance phase improves the
new information system. Because of the innovation of information technology and significant
changes of the business environment, the cost of system maintenance
eventually becomes unjustified at a certain point. The next generation of information system in
the organization will be inevitable. The information system development starts a new cycle.

2.2 Management of Systems Development Project

The management of information systems development projects has unique
characteristics in some aspects in comparison with the management of other types of
projects, as discussed below.
2.2.1. Project sponsor and project approval
The sponsor is responsible for securing the financing and overall resource budget
approval and owns the opportunities and risks related to the financial outcome of the project.
They may be referred to as the 'business sponsor,' 'project sponsor,' or 'executive' and are usually
a senior manager with a direct interest in the business case behind the project.
Even though this implies that the project sponsor can be a group of people, it is usually
far better if there is one named individual who has been given this role. An effective sponsor
will be someone with the authority and personal drive to overcome major obstacles to
completing the project.

2.2.2. Project scope definition, project scale estimation, and risk assessment

Project scope is the part of project planning that involves determining and
documenting a list of specific project goals, deliverables, features, functions, tasks,
deadlines, and ultimately costs. In other words, it is what needs to be achieved and the
work that must be done to deliver a project. It is important to pin down the scope early in
a project’s life cycle as it can greatly impact the schedule or cost (or both) of the project
down the track.

Estimation of the size of software is an essential part of Software Project Management. It

helps the project manager to further predict the effort and time which will be needed to build
the project. Various measures are used in project size estimation. Some of these are:
 Lines of Code
 Number of entities in ER diagram
 Total number of processes in detailed data flow diagram
 Function points
Risk assessment is a term used to describe the overall process or method where you:

 Identify hazards and risk factors that have the potential to cause harm (hazard
identification).
 Analyse and evaluate the risk associated with that hazard (risk analysis, and risk
evaluation).
  Determine appropriate ways to eliminate the hazard or control the risk when the hazard
cannot be eliminated (risk control).

Risk assessments are very important as they form an integral part of an occupational health
and safety management plan.

2.2.3. Project team management

The project management team is usually a subset of the project team and is
responsible for the project management and leadership activities such as initiating,
planning, executing, monitoring & controlling, and closing the various project phases.
The number of people assigned to the project may change as the project progresses,
particularly when people are needed for their particular technical expertise. The project
team should be assigned to the project as early as possible so that they can take some
part in the planning process. Even though team members are not responsible for planning
as such, many of them will have specific expertise that can help to make the initial
estimates more accurate.
Another reason for involving team members in the early stages of planning is that it
strengthens commitment to the project, something that is vital for success but which is
often overlooked because it cannot be measured objectively and because it’s importance
only becomes apparent when the project hits problems.

2.2.4. Project control and coordination

Effective project management involves planning, coordinating, and managing resources to
ensure that a project successfully achieves its target goals within the given constraints.
Project coordination generally refers to planning and managing multiple tasks
simultaneously. Coordination is essential for a business that deals with two or more related
projects. Projects vary based on business objectives but may include launching a new product
or expanding services into new areas. A project coordinator often holds different roles and
responsibilities, depending on the industry, business size, and project goal. For example,
corporations might designate separate project coordinators to handle domestic and international
affairs; whereas, small businesses might weave basic project coordination duties into a
management role. Project coordinators can serve as decision makers or assistants to lead
managers.

2.3 Fundamental Strategies of Information Systems

Development
2.3.1 Systems acquisition
Information systems are a major corporate asset, with respect both to the benefits they
provide and to their high costs. Therefore, organizations have to plan for the long term when
acquiring information systems and services that will support business initiatives. At the same
time, firms have to be responsive to emerging opportunities. On the basis of long-term corporate
plans and the requirements of various individuals from data workers to top management,
essential applications are identified, and project priorities are set. For example, certain projects
may have to be carried out immediately to satisfy a new government reporting regulation or to
interact with a new customer’s information system. Other projects may be given a higher
priority because of their strategic role or greater expected benefits.
Once the need for a specific information system has been established, the system has to be
acquired. This is generally done in the context of the already existing information systems
architecture of the firm. The acquisition of information systems can either involve external
sourcing or rely on internal development or modification. With today’s highly developed IT
industry, companies tend to acquire information systems and services from specialized vendors.
The principal tasks of information systems specialists involve modifying the applications for
their employer’s needs and integrating the applications to create a coherent systems architecture
for the firm. Generally, only smaller applications are developed internally. Certain applications
of a more personal nature may be developed by the end users themselves.

2.3.2 Systems construction

When an information system is developed internally by an organization, one of two
broad methods is used: life-cycle development or rapid application development (RAD).
The same methods are used by software vendors, which need to provide more general,
customizable systems. Large organizational systems, such as enterprise systems, are
generally developed and maintained through a systematic process, known as a system life
cycle, which consists of six stages: feasibility study, system analysis, system design,
programming and testing, installation, and operation and maintenance. The first five stages
are system development proper, and the last stage is the long-term exploitation. Following
a period of use (with maintenance as needed), the information system may be either phased
out or upgraded. In the case of a major upgrade, the system enters another development life
cycle.

Figure 2.3: Information systems life cycle. The development phase of the life cycle for an information system
consists of a feasibility study, system analysis, system design, programming and testing, and installation.
Following a period of operation and maintenance, typically 5 to 10 years, an evaluation is made of whether
to terminate or upgrade the system.

The principal objective of a feasibility study is to determine whether the system is

desirable on the basis of long-term plans, strategic initiatives, and a cost-benefit-analysis.
System analysis provides a detailed answer to the question, what will the new system do? The
next stage, system design, results in an extensive blueprint for how the new system will be
organized. During the programming and testing stage, the individual software modules of the
system are developed, tested, and integrated into a coherent operational system. Further levels
of testing ensure continuing quality control. Installation includes final testing of the system in
the work environment and conversion of organizational operations to the new system,
integrating it with other systems already in place. The later stages of development include such
implementation activities as training users and modifying the organizational processes in which
the system will be used.
Life-cycle development is frequently faulted for its long development times and
voluminous documentation requirements—and, in some instances, for its failure to fulfil the
user’s requirements at the end of the long development road.

Increasingly, life-cycle development is being replaced by RAD. In various RAD

methodologies a prototype—a preliminary working version of an application—is built quickly
and inexpensively, albeit imperfectly. This prototype is turned over to the users, their reactions
are collected, suggested modifications are incorporated, and successive prototype versions
eventually evolve into the complete system. Formal processes for the collaboration between
system developers and users, such as joint applications development (JAD), have been
introduced by some firms. Sometimes RAD and life-cycle development are combined: a
prototype is produced to determine user requirements during the initial system analysis stage,
after which life-cycle development takes over. A version of RAD known as agile development
aims to dispense with the notion of a prototype: an initial version of the system is built, released
to users, and then subject to frequent modifications as needs arise.
Industrial methods of software production and reuse have been implemented in systems
development. Thus, reusable software components are developed, tested, and catalogued to be
deployed as parts of future information systems. A particularly important method of
component-based development is the use of Web services, which are software objects that
deliver a specific function (such as looking up a customer’s order in a database) and can be
stitched together into interorganizational information systems enabling business partners to
cooperate.
After an installed system is handed over to its users and operations personnel, it will almost
invariably be modified extensively over its useful life in a process known as system
maintenance. A large system will typically be used and maintained for some 5 to 10 years or
even longer. Most maintenance is to adjust the system to the organization’s changing needs and
to new equipment and other software, but inevitably some maintenance involves correcting
design errors and exterminating software “bugs” as they are discovered.

2.3.3 Outsourcing
There are several principal ways to acquire an information system from outside the
organization. Many firms have resorted to outsourcing their information systems. Outsourcing
entails transferring the major components of the firm’s systems and operations—such as data
centres, telecommunications, and software development and maintenance—to a specialized
company that provides its services under long-term contracts specifying the service levels (that
is, the scope and the quality of service to be provided). In some cases the outsourcing entails
moving the services abroad—i.e., offshoring in pursuit of the cost or expertise advantages.
Responsibility for the acquisition of new applications then falls to the outside company. In other
cases the company may outsource just the development or maintenance of their information
systems, with the outside company being a systems developer.
Cloud computing is increasingly being adopted as a source of information services. It offers
on-demand access via the Internet to services furnished by a provider that runs data centres with
the necessary software and other resources. The services can be provided at one of three levels:
as the infrastructure for running existing applications, as the platform for developing new
applications, or as software-as-a-service (SaaS) to be used by the firm over the network. In
particular, SaaS has become a cost-effective way to use enterprise systems. Generally, cloud
computing is provided by external vendors, although some firms implement their own private
clouds in order to share resources that employees can access over the network from a variety of
devices, often including smartphones. Scalability and avoidance of capital expenditures are
notable advantages of public clouds; the partial loss of control is a drawback.
Companies may choose to acquire an application by leasing a proprietary package from a
vendor under a license and having the software customized internally or externally by the
vendor or another outside contractor. Enterprise systems are generally leased in this way. An
alternative is to deploy an open-source application, whose program code is free and open for
all to modify under a different type of license that enforces the openness of the application in
perpetuity. Generally, the costs of the use of open-source software include the technical support
from specialized vendors.

2.4 Diversified Information System Construction

Approaches
2.4.1 Waterfall approach
The waterfall model was introduced by Royce in 1970, specifically in the context of
spacecraft mission software design, and is one of the most popular methods of assessing the
evolution of a product or system. Essentially, it is a step-by-step sequential description of the
product’s life cycle that spans 7 different stages, originally denominated system requirements,
software requirements, analysis, program design, coding, testing and operations.
The essence of the waterfall model is that it attempts to provide a useful set of
guidelines for the development of new programs or systems. There are five key principles that
are essential for the successful development of large software systems.

 The first is “program design comes first.” It is essential to allow designers to be a

part of the initial process, because of their invaluable feedback regarding resources
and limitations.
 The second is “document the design.” Extensive documentation of the development
process is paramount, not just to facilitate management of the process, but to facilitate
performance assessments, making the eventual correction of mistakes more efficient.
  The third is “do it twice,” referring that the final version of the product should actually
be the second version, where all the stages have been performed and it is easier to
pinpoint strengths and weaknesses, to emphasize the first and correct the latter.
 The fourth is “plan, control and monitor testing”. Testing is a fundamental stage. It is
important to bring in specialists that did not participate in the earlier stages of the
process. It is also important to test every single aspect of the project, regardless of how
relevant it is.
 Finally, the fifth guideline is “involve the customer.” Having the insight, judgment, and
commitment of the customer taken into account during the development process is a
viable option that will greatly improve its potential for general acceptance.
The waterfall model is a sequential model. Each of its stages must be entirely concluded before
the next can begin. Similarly, to the flow of a waterfall, the development of the software is
regarded as continuously streaming downward throughout its different stages (see Figure 2.4).

Figure 2.4: An example of the waterfall life cycle model

2.4.2 Rapid application development (RAD) approach

Originally conceptualized in the 1970s, the rapid application development model was
substantially developed and formalized by James Martin in the early 1990s. As the name
suggests, it is driven by the idea that existing life cycle models are simply too rigid to permit
a fast project development; therefore, there is need for a framework that can account for fast
delivery while still maintaining high-quality standards. It is grounded on the principle that
step-by-step structured life cycles inevitably entail delays and errors, urging the need for an
alternative methodology. This issue became more relevant as businesses became
increasingly competitive and IT needed to keep up. When deadlines are the main priority
and the swiftness of software development is critical, RAD presents itself as a very plausible
solution.
RAD comprises a set of tools and guidelines that facilitate short-time deployment,
within a predefined time frame or “timebox.” The product is not developed in
successive steps until a final, complete delivery, but rather it evolves in successive
increments, following the priorities that are established by business—not technical
—necessities. Some of these tools and guidelines include planning methods, data and
process modelling, code generation, testing, and debugging.
It is important to note that both developers and customers are involved in all of
the increments. However, teams are generally small, highly skilled, and highly disciplined.
They are required to flexibly adapt to eventual changing requirements and feedback from
customers. Nevertheless, it is crucial to strike the proper balance between flexibility and
structural stability. Underlying models to the product’s design are still necessary, but not as
rigid step-by-step guides to be followed to the letter (Fig. 2.5).
RAD methodologies can follow three-stage or four-stage cycles. “The four-stage
cycle consists of requirements planning, user design, construction, and cutover,
while in the three-stage cycle, requirements planning, and user design are consolidated into
one iterative activity”.
During planning, it is possible to analyse requirements, alternatives, and opportunities,
as well as possible risks. This will form the basis for a definition of the project’s goals and
scope, and more importantly, it will allow for the establishment of the timebox, which is a
fixed period during which a specific increment of the product is going to be developed.
Each increment is then developed in a spiral-like model, through design, prototyping, and
testing. This method essentially pushes the team closer to the project’s business goals, by
providing key deadlines that can be determined by market forces.
While the advantages of the RAD are evident, due to its focus on swift delivery
and effective developer–client communication, there are still a number of issues raised by
this approach. One of the most obvious flaws is that it removes a great deal of emphasis on
minute planning and modelling at the start of the project, shifting that focus to the fluid
process of system construction. Another prominent issue is that in faster development
cycles, extensive quality testing will become less prioritized, reflecting in poorer quality
overall, which means that effective RAD methodologies should reserve space for skilled
individuals in quality control roles. It is also possible that managers and leader have
unrealistic expectations regarding the timeboxes, creating conflict with developing teams.
Thus, it is possible to assert that in order to be optimized, RAD life cycles must
necessarily be balanced and be open to moderating agents

Figure 3: Rapid application development entails a succession of increments or versions of the

product, each built on a predetermined timebox and following a cycle of 4 (or 3) steps
 2.4.3 Parallel approach
It is an approach wherein both the old and the new system operate simultaneously for
some time. The outputs from both the systems are compared and difference is reconciled.
The advantage of this approach is that it gives a high degree of protection to the organization
from the failure in the new system and has gained a wide spread popularity.

The disadvantage will be the costs associated with duplicating facilities and the
personnel to maintain the dual systems. This conversion is opposite of direct conversion.

In parallel conversion a target data should be set to indicate when this conversion can
be withdrawn, and the new system will operate on its own. If the differences occur between
the old and new systems, it should be verified with the same inputs to make sure of the
transaction.

2.5. Introduction to MERISE

To obtain quality software, it is important to master its elaboration process. Many

methods and tools exist to build software, among them MERISE, which is mainly used to
analyse and conceive information systems. MERISE is a set of initials which stand for Méthode
d’Étude et de Réalisation Informatique pour les Systèmes d’Entreprise. As stated before, it is a
method of analysis and design of software.
The analysis consists to:
 Study the existing system (solution);
 Understand the needs (make a diagnostic);
 Deduce the conceptual level: give a functional vision of the system.
The design consists to:
 Propose new organisational solutions;

2.5.1. The principles of the MERISE method

The MERISE method is based on the following principles:

1. Approach by levels

There are four levels of abstraction or description.

 The conceptual level: is about what to do. It answers to the question what?
 The organisational level is about the way to do. It answers to the questions who?
When? Where? How many?
 The logical level is about the choice of means and resources. It answers to the questions
which tools? What do we use?
 The physical level is about the means to implement the solution. It answers to the
question how?
 2. Data/processing/communication approach
The MERISE method leans on a description in the form of three aspects: communication, data
and processing.

3. Models
On each level of abstraction (conceptual, organisational, logical, physical), for each part (data,
processing), the information system is represented by a model (see table 1). Each model is
expressed in a using formalism of the adapted concepts. There are three basic groups of models:
 Models of communication (dataflow diagram, flow of actors’ diagram).
 Models of processing (conceptual model of processing, organisational model of
processing, logical model of processing).
 Data models (conceptual model of data or entity-association model, organisational
model of data, logical model of data)

Data Processing Communication

Conceptual CMP CMC
CMD
Conceptual Conceptual
Conceptual
Model of Model of OIS
Model of Data
Processing Communication Organisational
Organisational OMP OMC Information
OMD
Organisational Organisational System
Organisational
Model of Model of
Model of Data
Processing Communication
Logical LMC
LMD LMP
Logical Model
Logical Model of Logical Model
of CIS
Data of Processing
Communication Computerised
Physical PMC Information
PMD PMP
Physical Model System
Physical Model Physical Model
of
of Data of Processing
Communication

Table 1: Different Models of MERISE

4. Step by step progression

Building a software is a well described process that consists of
a continuation of steps, known as the life cycle of the software.

5. Different actors
The choice of people to assign to a project according to their
competences and experience is primordial. MERISE enables one to identify the different
actors of an information system and their attributions.
2.5.2. Design Stages using the MERISE method
The design of an information system is done by stages, to lead to a functional
information system reflecting a physical reality. It is thus a question of validating one after the
other each stage by considering the results of the preceding phase. In addition, data being
separated from processing, it is necessary to check the concordance between data and
processing to check that all necessary data with the processing are present and that there are no
superfluous data.
This succession of stages is called cycle of abstraction for the design of information
systems: the expression of the needs leads to CMC (Conceptual Model of Communication)
which defines flows of information to consider. The following stage consists in developing the
CMD (Conceptual Model of Data) and the CMP (Conceptual Model of Processing) describing
the rules and the constraints to be considered.
The organisational model consists in defining the LMD (Logical Model of Data) which
represents a software choice for the information system and the OMP (Organisational Model
of Processing) describing the constraints due to the environment (organisational, spatial and
temporal).
Lastly, the physical model reflects a material choice for the information system.
At the conceptual level, the conceptual model of data (CMD) formalizes the significance of
information on which the information system rests, without technical constraint nor economic.
The conceptual model of processing (CMP) formalizes the activity of the approached field,
without specifying the resources nor their organization.
At the organisational level, the organisational model of processing (OMP) describes the
operation of the field by specifying human and material resources mobilized as well as the
organization of these resources in time and space. The organisational model of data (OMD)
specifies which are among the definite data at the conceptual level (CMD) those which are
considered by the future computerized system, where these data are localised (distribution by
organisational site), their confidentiality for each speaker of the company.

At the logical level, the logical model of data (LMD) provides a description of data by taking
in account computer means, storage capacities and their conditions of use by the processing.
The logical model of processing (LMP) describes how the computerized tasks defined in the
preceding OMP are conceived in terms of software.

At the physical level, the physical model of data (PMD) is a description of data bases or the
unit of the files, expressed in the syntax of the adopted data base management system (DBMS)
or file management system (FMS). Lastly, the physical model of processing (PMP) specifies,
for the realization, the technical specifications of the various modules defined in the logical
model of processing. These modules could be carried out either in fourth generation languages,
or in a more traditional way in a third-generation language (COBOL, C…).
 The construction of an information system, relative with only reasoning, results in a
sequence of the various reasoning based on the use of the models and formalisms: the cycle of
abstraction. This process must make it possible to answer the following questions:
 How to work out and express the various models?
 How to pass from a level of abstraction to the following and to transform the various
models?
 How to confront data and processing to ensure a coherent system?
This course of the cycle of abstraction will bring into play diversified competences and
interests. In particular, managers - users and data computer specialists will be turn by turn
concerned with the development of the various models.

We have already seen this difference of culture and concern in the distinction between the
organisational information system (OIS) and the computerized information system (CIS).
Without instituting a barrier between manager partners and computer partners, the implication,
and the contribution of each one will be very different according to part (OIS or CIS):
 The development of the organisational information system requires the implication of
the manager (user); tackled problems and the solutions to be proposed concern primarily
its choice. Formalisms used for the expression of the models will have to take it into
account.
 The development of the computerized information system depends only on the expertise
of the computer specialists. Formalisms used in models will largely call upon computer
concepts.

This distribution of the poles of interests between managers and computer specialists do not
prejudge an organization of the working groups; the distribution of roles and contributions will
be regulated by the cycle of decision.
The way in which these preoccupations, poles of interests and competences emerge in the
cycle of abstraction is illustrated in the figure below:
 Conceptual Model of Data Conceptual Model of

Conceptual level
Processing
CMD
CMD
Meaning of information
without technical or economic Activities of the domain
Organisational

constraints without précising the resources

Information
System

or their organisation

Organisational Model of Data Organisational Model of

Organisational level

Processing
OMD
OMP
Meaning of information with
organisational and economic Operation of the field with the
constraints resources used and their
OIS organization

Logical Model of Data Logical Model of Processing

CIS
Logical level

LMD LMP
Description of data taking into Operation of the domain with
account their conditions of use the resources and their
Computerised

by their processing computer organisation

Information
System

Physical Model of Data Physical Model of Processing

LMD LMD
Physical level

Description of databases in the Technical architecture of

syntax of the DBMS or FMS software

Preoccupations of the Preoccupations of the

manager-user computer specialist