Chapter Four

Information Systems
Development

1
 Information Systems development phases
• As the name suggests, information system
development or commonly known as SLC (Systems Life
Cycle) or SLDC (Software/Systems Development Life
Cycle) is a process of making and changing the system
and the model and methodology used.
• The methodology which named as systems-
development life cycle (SDLC) was first developed in
the 1960s to manage the large software projects
associated with corporate systems running on
mainframes.
• It is a very structured and risk-averse methodology
designed to manage large projects that included
multiple programmers and systems that would have a
large impact on the organization.
2
• In other words, an SDLC is the preparation of a
new system to replace the old system, both in
whole and only partially.
• Development of ISs is generally done because of
problems that cannot be accommodated by the
old system.
• As for carrying out an IS development, the related
team will consist of several personnel,
• namely the project coordinator, system analyst
and design, network designer, programmer,
technician (hardware), administrator, software
tester, graphic designer, and documentary.
3
• Various of the SDLC exist, but most contain the
following phases are the following:
• 1. Preliminary Analysis
• In this phase, a review is done of the request.
• Is creating a solution possible?
• What alternatives exist? What is currently being done
about it? Is this project a good fit for our
organization?
• A key part of this step is a feasibility analysis, which
includes an analysis of the technical feasibility (is it
possible to create this?), the economic feasibility (can
we afford to do this?), and the legal feasibility (are we
allowed to do this?).
• This step is important in determining if the project
should even get started.
4
• 2. System Analysis
• In this phase, one or more system analysts work
with different stakeholder groups to determine
the specific requirements for the new system.
• No programming is done in this step.
• Instead, procedures are documented, key
players are interviewed, and data requirements
are developed in order to get an overall picture
of exactly what the system is supposed to do.
• The result of this phase is a system-requirements
document.

5
• 3. System Design
• In this phase, a designer takes the system-
requirements document created in the previous phase
and develops the specific technical details required
for the system.
• It is in this phase that the business requirements are
translated into specific technical requirements.
• The design for the user interface, database, data
inputs and outputs, and reporting are developed
here.
• The result of this phase is a system-design document.
• This document will have everything a programmer will
need to actually create the system.
6
• 4. Programming
• The code finally gets written in the programming
phase.
• Using the system-design document as a guide, a
programmer (or team of programmers) develop
the program.
• The result of this phase is an initial working
program that meets the requirements laid out in
the system-analysis phase and the design
developed in the system-design phase.

7
• 5. Testing
• In the testing phase, the software program developed
in the previous phase is put through a series of
structured tests.
• The first is a unit test, which tests individual parts of
the code for errors or bugs.
• Next is a system test, where the different components
of the system are tested to ensure that they work
together properly.
• Finally, the user-acceptance test allows those that will
be using the software to test the system to ensure
that it meets their standards.
• Any bugs, errors, or problems found during testing
are addressed and then tested again.
8
• 6. Implementation
• Once the new system is developed and tested, it
has to be implemented in the organization.
• This phase includes training the users, providing
documentation, and conversion from any
previous system to the new system.
• Implementation can take many forms, depending
on the type of system, the number and type of
users, and how urgent it is that the system become
operational.

9
• 7. Maintenance
• This final phase takes place once the
implementation phase is complete.
• In this phase, the system has a structured support
process in place: reported bugs are fixed and
requests for new features are evaluated and
implemented;
• system updates and backups are performed on a
regular basis.

10
 Information Systems development methodologies
• The whole purpose of system development is the
enhancement of the productivity of the organization
and the group of people working in that organization,
• as system development got bigger there was a need to
systemize the process of system development and
come up with a set of steps that are required for any
system development.
• The system development life cycle is a common
methodology used in all most every organization,
• as the system development projects got bigger and
the discipline of software engineering begun to set
some standards to its own a lot of methodologies have
seen light and were put together by organizations
seeking success according to their own measurement
of success.
11
• Before we get to further details about various system
development methodologies, we would like to give a
basic definition of a system development
methodology.
• It's " a standard process followed by an organization to
conduct all the steps necessary to analyze, design,
implement, and maintain information systems“.
• A methodology is also defined as follows " A method
describes the activities involved in defining, building,
and implementing a system; a method is a
framework”.
• Since a method is a logical process for constructing
systems (process), it is known as a meta-process (a
process for modeling processes).
12
• The definition does not mention the reason why the organizations want
to follow those steps in system development,
• but it seems very obvious that one of the goals was to facilitate tracking
problems whenever they might occur, and build better and successful
systems.
• A methodology has micro and macro components.
• The macro components define the overall flow and time-sequenced
framework for performing work.
• The micro components include general design rules, patterns and rules of
thumb.
• General design rules state properties to achieve or to avoid in the design
or general approaches to take while building a system.
• Patterns are solutions that can be applied to a type of development
activity;
• they are solutions waiting for problems that occur during an activity in a
method.
• Rules of thumb consist of a general body of hints and tips.
• A rule of thumb is a rule or principle that you follow which is not based
on exact calculations, but rather on experience and common sense..

13
• The SDLC methodology is sometimes referred to as the
waterfall methodology to represent how each step is a
separate part of the process; only when one step is
completed can another step begin.
• After each step, an organization must decide whether to
move to the next step or not.
• This methodology has been criticized for being quite rigid.
• For example, changes to the requirements are not allowed
once the process has begun.
• No software is available until after the programming phase.
• Again, SDLC was developed for large, structured projects.
Projects using SDLC can sometimes take months or years to
complete.
• Because of its inflexibility and the availability of new
programming techniques and tools, many other software-
development methodologies have been developed.
• Many of these retain some of the underlying concepts of
SDLC but are not as rigid. 14
15
• The RAD methodology consists of four phases:
• Requirements Planning.
• This phase is similar to the preliminary-analysis, system-
analysis, and design phases of the SDLC.
• In this phase, the overall requirements for the system are
defined, a team is identified, and feasibility is determined.
• User Design.
• In this phase, representatives of the users work with the
system analysts, designers, and programmers to interactively
create the design of the system.
• One technique for working with all of these various
stakeholders is the so-called JAD session.
• JAD is an acronym for joint application development.
• A JAD session gets all of the stakeholders together to have a
structured discussion about the design of the system.
• Application developers also sit in on this meeting and
observe, trying to understand the essence of the
requirements. 16
• Construction.
• In the construction phase, the application developers,
working with the users, build the next version of the
system.
• This is an interactive process, and changes can be made
as developers are working on the program.
• This step is executed in parallel with the User Design
step in an iterative [the repetition of a process in order
to generate an outcome] fashion, until an acceptable
version of the product is developed.
• Cutover.
• In this step, which is similar to the implementation step
of the SDLC, the system goes live.
• All steps required to move from the previous state to
the use of the new system are completed here. 17
• As you can see, the RAD methodology is much more
compressed than SDLC.
• Many of the SDLC steps are combined and the focus is
on user participation and iteration.
• This methodology is much better suited for smaller
projects than SDLC and has the added advantage of
giving users the ability to provide feedback throughout
the process.
• SDLC requires more documentation and attention to
detail and is well suited to large, resource-intensive
projects.
• RAD makes more sense for smaller projects that are
less resource-intensive and need to be developed
quickly.
18
• Agile Methodologies
• Agile methodologies are a group of
methodologies that utilize incremental changes
with a focus on quality and attention to detail.
• Each increment is released in a specified period of
time (called a time box), creating a regular release
schedule with very specific objectives.
• While considered a separate methodology from
RAD, they share some of the same principles:
iterative development, user interaction, ability to
change.
• The agile methodologies are based on the “Agile
Manifesto,” first released in 2001. 19
• The characteristics of agile methods include:
• small cross-functional teams that include
development-team members and users;
• daily status meetings to discuss the current state of
the project;
• short time-frame increments (from days to one or
two weeks) for each change to be completed; and
• at the end of each iteration, a working project is
completed to demonstrate to the stakeholders.
• The goal of the agile methodologies is to provide
the flexibility of an iterative approach while
ensuring a quality product.
20
 Lean Methodology
• One last methodology we will discuss is a relatively new concept taken
from the business bestseller The Lean Startup, by Eric Reis.
• In this methodology, the focus is on taking an initial idea and developing
a minimum viable product (MVP).
• The MVP is a working software application with just enough
functionality to demonstrate the idea behind the project.
• A MVP is the first form of a product that you can release to users.
• It provides core functionality without any additional features.
• Once the MVP is developed, it is given to potential users for review.
• Feedback on the MVP is generated in two forms:
• (1) direct observation and discussion with the users, and
• (2) usage statistics gathered from the software itself.
• Using these two forms of feedback, the team determines whether they
should continue in the same direction or rethink the core idea behind the
project, change the functions, and create a new MVP.
• This change in strategy is called a pivot.
• Several iterations of the MVP are developed, with new functions added
each time based on the feedback, until a final product is completed.

21
• The biggest difference between the lean
methodology and the other methodologies is that
the full set of requirements for the system are not
known when the project is launched.
• As each iteration of the project is released, the
statistics and feedback gathered are used to
determine the requirements.
• The lean methodology works best in an
entrepreneurial environment where a company is
interested in determining if their idea for a
software application is worth developing.
•
22
 Sidebar: The Quality Triangle
• Quality triangle, also known as a
project management triangle, iron
triangle, or project triangle.
• When developing software, or any
sort of product or service, there
exists a tension between the
developers and the different
stakeholder groups, such as
management, users, and investors.
• This tension relates to how quickly
the software can be developed
(time), how much money will be
spent (cost), and how well it will be
built (quality).
• The quality triangle is a simple
concept. It states that for any
product or service being
developed, you can only
address two of the following: time,
cost, and quality.
23
• So what does it mean that you can only address two
of the three? It means that you cannot complete
a low-cost, high-quality project in a small amount of
time.
• However, if you are willing or able to spend a lot of
money, then a project can be completed quickly with
high-quality results (through hiring more good
programmers).
• If a project’s completion date is not a priority, then it
can be completed at a lower cost with higher-quality
results.
• Of course, these are just generalizations, and
different projects may not fit this model perfectly.
• But overall, this model helps us understand the
tradeoffs that we must make when we are
developing new products and services. 24
Criteria for system development methodologies comparison
• In the following section we would list and define some criteria that
would be helpful for any IS professional involved in a system
development project to choose among the existing methodologies
to determine which one would fit the project he/she is working on
based on a predefined objective.
• So, all the criteria would be related to a component of a
methodology or one of its phases.
• As stated in the definition above, a methodology is a set of steps
to follow for a system development.
• One of the difference between the step by step methodologies
and the SCURM methodology is that the latter has only two defined
processes planning and closure,
• whereas the waterfalls admit that all processes are defined and
well known, and the various step are implemented in a linear
fashion.
– note: SCURMis an agile development methodology used in the
development of Software based on an iterative and incremental
processes

25
• Processes definition
• By process definition we mean does the methodology assume that every
step in the development life cycle is well known? and that there is no
room for environmental changes ? or does the methodology allow a big
deal of flexibility in all stages of the development cycle to incorporate
those changes that needs to be incorporated in the project before its
closure.
• Final product determination
• Another criteria would be related to the final product. Does the
methodology define the final product early on in the planning stage or
does it define it during the project and close to project closure time.
• Project cost
• This criterion is related to the estimation of the cost of the project and at
what stage of the project it's done.
• Project completion date
• Estimation of a schedule of deliverable based on the estimation of the
tasks to be accomplished. Is that done up front or as the project
progresses?
• Responsiveness to environment
• This criterion measures the flexibility that the methodology allows to
incorporate changes during the project, changes due to the environment,
technology, competition or other. 26
• Team dynamic and creativity
• The steps predefined by the methodology could be an obstacle to creativity
among teams, as the linear model suggests that some work needs to be
done first by a small group and then the project moves to the next stage.
• This criterion try to measure the ability of allowing some team work and
interactions among the team members.
• Role of the upper management
• Is management an obstacle in creating a better system, or is the role of
management to empower the team by taking care of any obstacles that
impact the team performance.
• Training and knowledge
• Does the methodology steps allow training and knowledge transfer during
the project or does it put a limitations to what a team member can do and
learn.
• Probability of success
• This criterion measures the probability of success of a project using a
certain methodology by embracing a certain degree of complexity and
unpredictability.
• (a successful project is defined as a system that is useful when delivered).

27