Chapter 7: Systems Development

Objectives and Learning outcomes

- Objectives:
o To assess appropriate techniques for designing and implementing information
systems
o To assess appropriate controls for managing the risks inherent in information
systems development projects

- Learning outcomes:
o Identify the typical stages in an information systems project
o Identify the risks associated with typical phases of a project
o Understand approaches used by project managers to control projects
o Develop DFD, ERD and UML diagrams to design the information system
o Design and program small problems in Visual Basic

Management issues

Typical questions facing managers related to this topic:

o How can we avoid the high reported failure rates for IS implementations?
o Which specific risks are related to management of information management
projects?

Information System Defined

An Information System is a special case of system …

… which components are hardware, software, data, people and procedures …
… that work together interdependently under some means of control …
… to process data … OR … that interact …
… and provide information to … for the purpose of supporting and
users improving both day-to-day operations in a
business (data processing) …
… as well as supporting the problem solving
and decision making needs of management

1
Managing Systems Development

Project success rates – applications development

An Unsustainable Situation

- On one hand …
o People build information systems using no particular method
o People build fragile information systems
o People build inaccurate information systems
o Information system development is expensive
o Information system development requires considerable planning and effort

2
- On the other hand …
o Modern information systems are ever-increasing in sophistication
o Demands on information systems is always rising
o Information systems are what make a computing entity
o People consciously or unconsciously rely on software and information systems
for most of their social activities

Constraints on IS project management

The Communication Problem

Door te weinig / slechte communicatie loopt het fout

The Software Crisis

- The tension created by the conflicting interests gave rise to a software crisis
peaking in the late 70s / early 80s
- The software crisis threatened to cripple the progress of computing as a whole
- Effects of the crisis still linger in the form of software development always playing
“catch-up” to hardware development

Success measures

A KPMG (2002) survey showed that the most important measures of success were:
o Meeting business case requirements (46%)
o On-time delivery (21%)
o Within budget delivery (9%)
o Equal weighting to all thee measures (24%)

Critical Success Factors in Project Management

- Meeting the system requirements

3
 o Define how an information system will be used within the business through
detailed specification of the features
o The communication problem!
- Control of changes in requirements
o Requirements creep: incremental changes to the specifications of an
information system project during implementation
- Integration risk
o Potential project overruns caused by additional work involved with integrating
the output form separate activities

System Development Process: A brief History

- Unsystematic approaches:
o Focus was on finding the solution for the users’ problems
o Peter Drucker (management consultant): “efficiency is doing the job right, and
effectiveness is doing the right job”
o We need ways to investigate and understand our users’ business and the
problems they are having so that we can produce the right solution for the
right problem

- Output oriented methods

o Started late 1960s

Development Life Cycles and Approaches

- Systems Development Life Cycle

o Around 1970s

4
 Feasibility
study
Maintenance Analysis

Installation Design

Programming

Development process methods

- The SDLC covers the whole life of a system

- Several development methods exist:
o Waterfall (And Enhanced Waterfall)
o V-model ← Research independently
o Evolutionary Prototyping (aka Incremental)
o Throw-away Prototyping (aka Rapid)
o Rapid Application Development (RAD)
o Spiral ← Research independently
o Reuse-oriented
o …
- The selection of the appropriate model is important for the project

The waterfall model of systems development

- Applicability
o When the requirements are well-understood and changes will be fairly limited
during the design process

5
- Although it is still the root of many other models, it has many drawbacks:
o Each phase has to be completed before moving to the next one
→ Delay before system delivered
o All or nothing
- Sequential dependencies create delays forcing others to wait
o It assumes that the only role for users is in specifying requirements, and that
all requirements can be specified in advance
o Unfortunately, requirements grow and change throughout the process
and beyond, calling for considerable feedback and iterative consultation

- Disadvantages (Cont’d)
o Late tangible product maturity
o Late feedback
 To both customer and developer
o Minimal risk management
 For both customer and developer
o Late testing maturity

The incremental model

- Assumes independent sub-systems

- All requirements must be known
- Improves (by delivering smaller units):
o Feedback (in steps)
o Testing
- Systems must have “increments”
- Increments must be useful to users
- Overall, longer (much longer) development time
- Does not particular improve:

6
 o Development risk management
o Sequential nature (still present in sub-systems)

Development process methods

- Several other development methods exist

o Will be discussed later
- The selection of the appropriate model is important for the project

Methodologies to support the project management process

- Characteristics of many methodologies:

o Project is divided into manageable stages enabling regular progress
monitoring
o Responsibilities and roles within the project clearly defined
o Project planning is product-based (project plans to deliver results, not simply
planning activities)
o The project is driven by the business case which describes the organizations’
justification and commitment for the deliverable
o The methodology enables good communication between the project team and
the rest of the organization

Systems Development

- You are likely, in your future career, to find yourself involved in systems
development
o As an employee whose job is being re-organised, or
o As part of a team (as business analyst, …) involved in developing a new
system, or
o Adapting an existing system, or
o With responsibility for specifying requirements for a new system

7
Managing Systems Development

Project success rates – applications development

- Software crisis
o Costly mistakes in the development of large systems
o Problems with maintenance of existing systems
o Developments in hardware
o Users / clients calling for
o More more more
o Better software
o Cheaper software
o “We want it yesterday!”

8
Systems Development Life Cycle

Feasibility
study
Maintenance Analysis

Installation Design

Programming

Key activities in systems development:

o Systems initiation phase
o Systems analysis phase
o Systems design phase
o Systems development phase
o Systems implementation phase
o Systems maintenance phase

The initiation phase

- It aims are to evaluate whether the project is feasible and prepare a project plan
- Includes answers to following questions:
o What is to be carried out?
o Why is it being done?
o Who is going to do it?
o How is it to be accomplished?
o High level plan for the whole project
o When is it to be done?

Feasibility analysis
Feasibility type Purpose
Economic Costs of benefits of
different solutions
Technical Outline the best technical
solution
Operational Determine impact on
business processes
Organizational Assess fit with
organizational structure
and culture
Issues considered
Cost-benefit analysis
Make or buy decision
Produce shortlist of software,
suppliers and systems integrators
Integration with existing systems
Assess how well processes are
supported by new system. Identify
outline requirements
Outline approach for introducing
new system into organization

- The project initiation document

o Objectives

9
 o Business objectives (e.g to increase our market with 25%)
o Project objectives:
 Narrower
 Specify exactly what the project is to deliver
 E.g to implement an e-commerce trading system
o Scope
o What is included
o What is not included
o Constraints
o Hardware and software platform
o Time
o Resources

- The project initiation document (Cont’d)

o Authority
o Who is the customer, who can authorise it
o Resources
o People
o Money
o Equipment
o …

- Typical problems
o Insufficient time is devoted to it
o Team members are keen to proceed the work
o Insufficient gathering of requirements
o The activities, budget and timescal are underestimated
o Organizational, operational and technical risks may not be identified

Systems analysis phase

- Systems analysis determines the business and user requirements of an information

system. Fact-finding techniques are used to ascertain the users needs and these are
summarised using a range of documentation and diagramming methods
- System analysis
= Determination of information system requirements
- Defines what the system should do
- Output – Requirements specification

Key activities:
o Focus groups
o Document review
o Surveys
o Observation
o Interviews
o Prototyping
o Producing the requirements specification

10
Systems design phase

- Systems design
o Defines the overall structure of the system and its inputs and outputs
- Systems design phase
o Defines how the completed system will operate
- Output – Design specification

- Systems design activities:

o Software architecture
o Defines how different modules will work at the level of program code.
System modules or objects will be broken down further into individual
program functions or methods.
o Hardware architecture
o Defines the need for different hardware components or infrastructure of
the system
o Information architecture
o This specifies the data inputs and information outputs of the system
and defines the most efficient methods for capturing, storing and
modifying the data. Database design is part of the information
architecture
o Security design
o Defines how the information will be protected. This relates to
information architecture in that certain data items will usually have
access to different classes of users
o User interface design
o Defines the different screens that users will interact with including menu
options, data entry forms and other navigation elements

Typical problems of system design

o Although the design phase is based on the requirements specification
document, there is a lot of overlap between analysis and design phases
o Designers may find that the requirements specification does not prescribe in
enough detail what is needed from the system, or they will make additional
suggestions for improvements. At this point, it will be necessary to consult the
users of the system for clarification
o This may cause major delays if the channels of communication between the
designers, the analysts and the users are not established. One of the benefits
of prototyping and methods such as DSDM is that they recognise and enable
the need for continued consulting with the users
o As with many of the phases of the system development lifecycle, insufficient
time may be spent on the design phase. This may require re-work at later
stage

Systems development phase

- At the systems development stage the physical system is created by technical staff
through programming, database management and configuration

11
Activities:
1. Programming individual system modules and fixing errors or ‘bugs’ in the
system
2. Creating the database structures and data manipulation functions such as
database triggers and stored procedures
3. Creating the user interface for access through web browsers
4. Testing the database, programmes and interface
5. Writing system documentation for the users and future developers

Problems:
o The main difficulty with the development phase is the introduction of bugs or
errors into the system by developers. The problem is that developing a major
system requires tens or hundreds or millions of lines of code. Each line
represents an opportunity to include an error which can potentially ‘bring the
system down’. Even experienced programmers may produce around 10
defects per thousand lines of code
o Changes to specification is also a major issue

Systems implementation

- Systems implementation involves introducing the system into the business. This
starts with providing test versions of the system and then once test results are
satisfactory rolling out the changeover from the old system to the new system
- Migration or changeover from a previous information system to a new system is
particularly important for mission-critical e-business systems where errors in
management of changeover will result in a negative customer experience or
disruption to the supply chain

Activities:
o Changeover
o Migrating the system
o Data migration
o Data conversion (‘populating the database’)
o Testing

Options:
Option
1. Immediate cutover
Straight form old to new
system on a single date
2. Parallel running
Old and new system run side-
by-side for a period
3. Phased implementation
Different modules of the
system are introduced
sequentially
4. Pilot system
Trial implementation occurs
Main advantages Main disadvantages
Rapid, lowest cost High risk. Major disruption
if serious errors with
system
Lower risk than Slower and higher cost
immediate cutover than immediate cutover
Good compromise Difficult to achieve
between methods 1 technically due to
and 2 interdependencies
between modules
Essential for Has to be used in
multinational or combination with the other

12
before widespread deployment national rollouts methods

Problems:
o They are many cases of systems failing at the changeover phase (see for
example case study 7.2)
o Failure at this stage may be due to unexpected problems when the system
goes live which were not tested in the test environment. For example, the load
on a live system could be higher than that in the test environment. A further
problem is that there is a reluctance to delay the live date despite the system
not being fully tested

System maintenance

- Systems maintenance involves managing the system once it is live. Problems with
the system must be fixed. Since there is also time to reflect on the project overall,
some organizations will look to learn from their experiences on the project through a
project closedown review

Activities:
o A key activity is responding to errors as they are found. If serious, the
problems will have to be solved immediately through issuing a ‘patch’ release
to the system; otherwise they will be recorded for a later release. A system is
required for promptly reporting and reviewing errors
o A formal review may occur after the end of projects, this is the post-
implementation review. This assesses the success of the systems
development projects and lessons are recorded for further projects

Problems:
o Problems with the maintenance phase tend to be a consequence of
maintenance not being part of the overall project, so processes for reporting,
reviewing, fixing and notifying problems may not be in place
o A project closedown review is often omitted in organizations that do not have a
project quality management system in place since it all too easy to move on to
the next project and put problems with the project ‘under the carpet’

Specific issues of Internet-content projects

- Initiation
o Education to explain the purpose of the intranet and the importance of
updating is particularly important. Care must taken in calculating the return on
investment with information-based projects
- Analysis and design
o Specialist methods of mapping the information requirements are used as
described in chapter 9 on information architectures
- Development
o The design phase is relatively limited compared to most bespoke applications
since a content management system, existing CRM application or e-
commerce server will be used to setup structures for data storage.
Development of the web-based user interface needs specific skills which differ

13
 somewhat from non web-based applications. These issues are also covered in
chapter 9
- Implementation
o A lot of work will be required to populate the system with information. Since
much of the information will already be available, methods of integrating with
other systems such as exporting the information from other systems and then
importing this information may be necessary
- Maintenance
o The maintenance phase is particularly important in these types of projects
since content needs to be kept up-to-date. Responsibilities and update
mechanisms for this are required. The usage of different information types in
web-based systems can be readily tracked and evaluated to check the
relevance of information. Controls need to be in place to maintain the quality
of information and these controls are referred to in chapter 10 which is
devoted to managing information quality

Models in Systems Development

- To understand the users’ world adequately, we need:

o Modeling notations
o To document and communicate all that we learn from our users
o Modeling techniques
o That ensure we use these notation tools properly to produce an
accurate picture of the users’ business
o People sensivity
o (interviewing and listening skills) to ensure that we gather all relevant
information, so that our models form a complete and accurate picture of
the users’ business

Modeling systems. Why?

- Models are often built in the context of business and IT systems in order to better
understand existing or future systems. However, a model never fully corresponds to
reality. Modeling always means emphasizing and omitting:
o Emphasizing essential details
o Omitting irrelevant ones
- But what is essential and what is irrelevant? There is no universal answer to this
question. Rather, the answer depends on what the goals of the model are and who is
viewing or reading it
- The more information a model is supposed to give, the more complex and difficult it
becomes
o A map of Europe, for example, that simultaneously contains political,
geographical, demographic, and transportation-related information is hardly
legible. The solution to this problem is to convey the different types of
information on individual maps
- Different views are formed of the objects under consideration. These views are
interconnected in many ways. Generally, if one view is changed, all other views have
to be adjusted as well. If, for instance, in the Netherlands new land is reclaimed from
the North Sea, all views – meaning all maps – have to be updated

14
If we change the object, we have to change each view

- Models are abstractions that portray the essentials of a complex problem or

structure by filtering out nonessential details
- Describing a system at a high level of abstraction:
o A model of the system
o Used for requirements and specifications
- Models help us organize, visualize, understand, and create complex things
- Is it necessary to model software systems?
- Visual modeling is a way of thinking about problems using models organized
around real-world ideas
- Models are useful for
o Understanding problems
o Communicating with everyone involved with the project (customer, domain
expert, analyst, designers, etc)
o Modeling enterprises
o Preparing documentation
o Designing programs and databases

Methods and Modeling Languages

- Methodology:
o An organized, documented set of procedures and guidelines for one or more
phases of the software life cycle, such as analysis or design
o Many methodologies include
o A diagramming notation for documenting the results of the procedure
o A step-by-step “cookbook” approach for carrying out the procedure
o An objective (ideally quantified) set of criteria for determining whether
the results of the procedures are of acceptable quality
- A model
o Is a representation

15
 o Captures the important aspects of the thing being modelled from a certain
point of view and simplifies or omits all the rest
- A model of a software system is made in a modeling language
- A model has both semantics and notation

What is Modeling? Why should we Model?

- A model is a simplified representation of a complex reality, usually for the purpose

of understanding that reality and having the features of that reality necessary for the
current task or problem
- Modelling is the act of drawing one or more graphical representations (or pictures)
of a system
- Model-driven development techniques emphasize the drawing of models to help
visualize and analyze problems, define business requirements, and design
information systems
- The written word is a wonderful vehicle for communication, but it is not necessarily
the best way to represent the requirements for computer software

Different points of view

Process oriented

Data oriented Event oriented

Information flow diagrams (IFD)

- A simple high-level diagram illustrating information flows

- IFD’s are drawn when the analysts need to know / understand how information
flows around (inside) the business or between the business and the outside world
- The diagram will illustrate source and destinations

Information flow diagram key

Source or
destination Information flow

Simple information flow illustration

Airline Airline booking

customer department

Customer booking details

- Information flows are single headed arrows. Unlabeled arrows are meaningless

16
 Customer Sales
department
Product order

- Two way information flow

o Double headed arrows should not be used
o As it is not possible to clearly show in which direction each piece of
information flows

Product order
Customer Sales
department

Order confirmation

Customer Sales
department
Product order en
Order confirmation
- Model information, not paper

Dispatch Accounting
department
Products dispatched

Dispatch Accounting
department
Dispatch notes

- Paper reports can carry several different pieces of information, wowing the name of
the report doesn’t tell us what information is actually needed by the destination entity
- Modeling the flow on paper

Dispatch Accounting
department
Products dispatched
Dispatch
notes

17