Unit III

Building Information Systems: Concepts of Systems Analysis and Design,

SDLC Approach, Prototyping, Spiral method. Role of End User, Logical and
Physical Design. Implementation Strategies of Information Systems.
Evaluation of Information Systems. (10 hours)

Concept of System Analysis

A system development is systematic process which includes includes

phases such as planning, planning, analysis, analysis, design, design,
deployment, deployment, and maintenance. We will primarily focus on –
1. Systems analysis
2. Systems design Systems Analysis

It is a process of collecting and interpreting facts, identifying the problems,

and decomposition of a system into its components. System analysis is
conducted for the purpose of studying a system or its parts in order to
identify its objective. It is a problem solving technique that improves the
system and ensures that all the components of the system work efficiently
to accomplish their purpose.

What is SDLC?
SDLC is a process followed for a software project, within a software
organization. It consists of a detailed plan describing how to develop,
maintain, replace and alter or enhance specific software. The life cycle
defines a methodology for improving the quality of software and the overall
development process.

The following figure is a graphical representation of the various stages of a

typical SDLC.
The systems development life cycle (SDLC) is a conceptual model used
in project management that describes the stages involved in an
information system development project, from an initial feasibility study
through maintenance of the completed application. SDLC can apply to
technical and non-technical systems. In most use cases, a system is an IT
technology such as hardware and software. Project and program managers
typically take part in SDLC, along with system and software engineers,
development teams and end-users.

Every hardware or software system will go through a development process

which can be thought as an iterative process with multiple steps. SDLC is
used to give a rigid structure and framework to define the phases and
steps involved in the development of a system.
SDLC is also an abbreviation for Synchronous Data Link Control and
software development life cycle. Software development life cycle is a very
similar process to systems development life cycle, but it focuses
exclusively on the development life cycle of software.

SDLC models
Various SDLC methodologies have been developed to guide the processes
involved, including the original SDLC method, the Waterfall model. Other
SDLC models include rapid application development (RAD), joint
application development (JAD), the fountain model, the spiral model, build
and fix, and synchronize-and-stabilize. Another common model today is
called Agile software development.

Frequently, several models are combined into a hybrid methodology. Many

of these models are shared with the development of software, such as
waterfall or agile. Numerous model frameworks can be adapted to fit into
the development of software.

In SDLC, documentation is crucial, regardless of the type of model chosen

for any application, and is usually done in parallel with the development
process. Some methods work better for specific kinds of projects, but in
the final analysis, the most crucial factor for the success of a project may
be how closely the particular plan was followed.

Steps in SDLC
SDLC can be made up of multiple steps. There is no concrete set number
of steps involved. Around seven or eight steps appear commonly; however,
there can be anywhere from five upwards to 12. Typically, the more steps
defined in an SDLC model, the more granular the stages are.

In general, an SDLC methodology follows these following steps:

1. Analysis: The existing system is evaluated. Deficiencies are identified.
This can be done by interviewing users of the system and consulting
with support personnel.

2. Plan and requirements: The new system requirements are defined. In

particular, the deficiencies in the existing system must be addressed
with specific proposals for improvement. Other factors defined include
needed features, functions and capabilities.

3. Design: The proposed system is designed. Plans are laid out concerning
the physical construction, hardware, operating systems, programming,
communications and security issues.

4. Development: The new system is developed. The new components and

programs must be obtained and installed. Users of the system must be
trained in its use.

5. Testing: All aspects of performance must be tested. If necessary,

adjustments must be made at this stage. Tests performed by quality
assurance (QA) teams may include systems integration and system
testing.

6. Deployment: The system is incorporated in a production environment.

This can be done in various ways. The new system can be phased in,
according to application or location, and the old system gradually
replaced. In some cases, it may be more cost-effective to shut down the
old system and implement the new system all at once.

7. Upkeep and maintenance: This step involves changing and updating the
system once it is in place. Hardware or software may need to be
upgraded, replaced or changed in some way to better fit the needs of
the end-users continuously. Users of the system should be kept up-to-
date concerning the latest modifications and procedures.
Other steps which may appear include project initiation, functional
specifications, detailed specifications, evaluation, end-of-life and other
steps that can be created by splitting previous steps apart further.

Advantages and disadvantages of SDLC

Benefits of abiding by a clearly defined SDLC model include:

1. Having a clear view of an entire project, workers involved, estimated

costs and timelines.

2. Gives project managers a projected base cost of the project.

3. Goals and standards are clearly defined.

4. Developers can move back a step if something does not go as

expected.

Disadvantages, however, can include:

1. Due to assumptions made at the beginning of a project, if an

unexpected circumstance complicates the development of a system,
then it may stockpile into more complications down the road. As an
example, if newly installed hardware does not work correctly, then it
may increase the time a system is in development, increasing the
cost.

2. Some methods are not flexible.

3. It can be complicated to estimate the overall cost at the beginning of

a project.

4. Testing at the end of development may slow down some

development teams.
What is prototyping model?
The prototyping model is a systems development method in which
a prototype is built, tested and then reworked as necessary until an
acceptable outcome is achieved from which the complete system or
product can be developed.

This model works best in scenarios where not all the project requirements
are known in detail ahead of time. It is an iterative, trial-and-error process
that takes place between the developers and the users.

Steps of the prototyping model

In most cases, the steps of the prototyping model are as follows:

1. The new system requirements are defined in as much detail as possible.

This usually involves interviewing a number of users representing all the
departments or aspects of the existing system.

2. A preliminary, simple design is created for the new system.

3. The first prototype of the new system is constructed from the

preliminary design. This is usually a scaled-down system and represents
an approximation of the characteristics of the final product.

4. The users thoroughly evaluate the first prototype and note its strengths
and weaknesses, what needs to be added and what should be removed.
The developer collects and analyzes the remarks from the users.

5. The first prototype is modified, based on the comments supplied by the

users and a second prototype of the new system is constructed.

6. The second prototype is evaluated in the same manner as the first

 prototype.

7. The preceding steps are iterated as many times as necessary, until the
users are satisfied that the prototype represents the final product
desired.

8. The final system is constructed, based on the final prototype.

9. The final system is thoroughly evaluated and tested. Routine

maintenance is carried out on a continuing basis to prevent large-scale
failures and to minimize downtime.
Types of prototype models
There are a few types of prototype models that can be implemented by
development teams based on their needs, such as the following:

 Rapid throwaway. This method involves exploring ideas by quickly

developing a prototype based on preliminary requirements that is then
revised through customer feedback. The name rapid throwaway refers
to the fact that each prototype is completely discarded and may not be a
part of the final product.

 Evolutionary. This approach uses a continuous, working prototype that

is refined after each iteration of customer feedback. This method saves
time and effort because each prototype is not started from scratch.

 Incremental. This technique breaks the concept for the final product
into smaller pieces and prototypes are created for each one. In the end,
these prototypes are merged into the final product.

 Extreme. This prototype model is used specifically for web development.

All web prototypes are built in an HTML format with a services layer and
are then integrated into the final product.
Advantages of the prototyping model
Using a prototype model can bring multiple advantages, including the
following:

 Customers get a say in the product early on, increasing customer

satisfaction.

 Missing functionality and errors are detected easily.

 Prototypes can be reused in the future, for more complicated projects.

 It emphasizes team communication and flexible design practices.

 Users have a better understanding of how the product works.

 Quicker customer feedback provides a better idea of customer needs.

Disadvantages of the prototyping model
The main disadvantage of this methodology is that it is more costly in
terms of time and money when compared to alternative development
methods, such as the spiral or Waterfall model. Since in most cases the
prototype is discarded, some companies may not see the value in taking
this approach.

Additionally, inviting customer feedback so early in the development

lifecycle may cause problems. One problem is that there may be an
excessive amount of change requests that may be hard to accommodate.
Another issue could arise if after seeing the prototype, the customer
demands a quicker final release or becomes uninterested in the product.

The spiral model combines the idea of iterative development with the
systematic, controlled aspects of the waterfall model. This Spiral model is
a combination of iterative development process model and sequential
linear development model i.e. the waterfall model with a very high
emphasis on risk analysis. It allows incremental releases of the product or
incremental refinement through each iteration around the spiral.
Spiral Model - Design
The spiral model has four phases. A software project repeatedly passes
through these phases in iterations called Spirals.
Identification
This phase starts with gathering the business requirements in the baseline
spiral. In the subsequent spirals as the product matures, identification of
system requirements, subsystem requirements and unit requirements are
all done in this phase.
This phase also includes understanding the system requirements by
continuous communication between the customer and the system analyst.
At the end of the spiral, the product is deployed in the identified market.

Design
The Design phase starts with the conceptual design in the baseline spiral
and involves architectural design, logical design of modules, physical
product design and the final design in the subsequent spirals.
Construct or Build
The Construct phase refers to production of the actual software product at
every spiral. In the baseline spiral, when the product is just thought of and
the design is being developed a POC (Proof of Concept) is developed in this
phase to get customer feedback.
Then in the subsequent spirals with higher clarity on requirements and
design details a working model of the software called build is produced
with a version number. These builds are sent to the customer for feedback.
Evaluation and Risk Analysis
Risk Analysis includes identifying, estimating and monitoring the technical
feasibility and management risks, such as schedule slippage and cost
overrun. After testing the build, at the end of first iteration, the customer
evaluates the software and provides feedback.
The following illustration is a representation of the Spiral Model, listing the
activities in each phase.
Based on the customer evaluation, the software development process
enters the next iteration and subsequently follows the linear approach to
implement the feedback suggested by the customer. The process of
iterations along the spiral continues throughout the life of the software.
Spiral Model Application
The Spiral Model is widely used in the software industry as it is in sync with
the natural development process of any product, i.e. learning with maturity
which involves minimum risk for the customer as well as the development
firms.
The following pointers explain the typical uses of a Spiral Model −
1. When there is a budget constraint and risk evaluation is important.
2. For medium to high-risk projects.
3. Long-term project commitment because of potential changes to
economic priorities as the requirements change with time.
4. Customer is not sure of their requirements which is usually the case.
5. Requirements are complex and need evaluation to get clarity.
6. New product line which should be released in phases to get enough
customer feedback.
7. Significant changes are expected in the product during the
development cycle.

Spiral Model - Pros and Cons

The advantage of spiral lifecycle model is that it allows elements of the
product to be added in, when they become available or known. This
assures that there is no conflict with previous requirements and design.
This method is consistent with approaches that have multiple software
builds and releases which allows making an orderly transition to a
maintenance activity. Another positive aspect of this method is that the
spiral model forces an early user involvement in the system development
effort.
On the other side, it takes a very strict management to complete such
products and there is a risk of running the spiral in an indefinite loop. So,
the discipline of change and the extent of taking change requests is very
important to develop and deploy the product successfully.
The advantages of the Spiral SDLC Model are as follows −
1. Changing requirements can be accommodated.
2. Allows extensive use of prototypes.
3. Requirements can be captured more accurately.
4. Users see the system early.
5. Development can be divided into smaller parts and the risky parts can
 be developed earlier which helps in better risk management.
The disadvantages of the Spiral SDLC Model are as follows −
1. Management is more complex.
2. End of the project may not be known early.
3. Not suitable for small or low risk projects and could be expensive for
small projects.
4. Process is complex
5. Spiral may go on indefinitely.
6. Large number of intermediate stages requires excessive
documentation.

What Is the Role of the End User

A computer system's database software acts as an efficient, secure

repository for an organization's data. The end user of a database typically
never sees the software or its files, and may be unaware of how the system
works. Because she uses the application software that interacts with the
database, however, the system programmer must build the setup to fit her
needs. The programmer discusses the system's goals with the user and
translates them into a working configuration.
Specifications
An engineer turns on her computer and retrieves a list of parts for a piece
of machinery. She does not see the database that stores the parts list, but
she sees its screens and printouts. To design the parts list system, a
programmer sits with the engineer and finds out what kinds of information
she needs, then creates the database, screens and reports from the user's
specifications. Over time, the programmer may revise the system in
response to user requests for new or reconfigured features.
Rules
End users may require that a software system follow specific rules that
represent the norms or enforce the prohibitions of a business, industry or
set of laws. For example, a parts system should block items that contain
lead from implementation in products designed for household use, or abide
by a rule requiring that the weight of a machine should never exceed 200
pounds. The programmer sets up database rules that automatically
enforce these restrictions.

Import/Export
Users frequently maintain records in small spreadsheet files, tracking
projects, creating charts and performing other daily tasks. A database
programmer can set up an application that allows for customized export
from the system, which the end users can open in a spreadsheet program.
In this situation, a database system process combs through the data and
writes select records into a spreadsheet format. To move data in the
opposite direction, the programmer sets up data-import routines that feed
the database from user-generated files.
Schedule
Some types of database management software process data automatically
on a schedule. This type of time-sensitive process can help a manager who
needs a daily report that summarizes the previous day's work. Running
overnight, a scheduled routine can generate this information. Other
scheduled database processes can create reports or export files for the
week, month or quarter. Once users describe and quantify their recurring
data needs, the programmer can set up the necessary processes.
Security
Database security must reflect users' organizational roles. Database
application configurations provide the flexibility to assure that information
reaches only those people with the need and the right to see it. For example,
an engineer receives full access to her parts database but can't read
records from the payroll database. Conversely, a human resources user
may gain full access to payroll data but lack the privileges necessary to
reach the parts database.

Logical Database Design has a low-level description of entities that are

defined and how they are related to each other and what kind of data is to
be stored. This model determines if all the requirements of the business
have been gathered.
Physical Database Design deals with how the data will be stored in the
database using suitable DBMS and this design is generally created by
database administrators and developers.
Logical vs. Physical

If you are reading this guide, it is likely that your organization has already
decided to build a data warehouse. Moreover, it is likely that the business
requirements are already defined, the scope of your application has been
agreed upon, and you have a conceptual design. So now you need to
translate your requirements into a system deliverable. In this step, you
create the logical and physical design for the data warehouse and, in the
process, define the specific data content, relationships within and between
groups of data, the system environment supporting your data warehouse,
the data transformations required, and the frequency with which data is
refreshed.

The logical design is more conceptual and abstract than the physical
design. In the logical design, you look at the logical relationships among
the objects. In the physical design, you look at the most effective way of
storing and retrieving the objects.

Your design should be oriented toward the needs of the end users. End
users typically want to perform analysis and look at aggregated data, rather
than at individual transactions. Your design is driven primarily by end-user
utility, but the end users may not know what they need until they see it. A
well-planned design allows for growth and changes as the needs of users
change and evolve.

By beginning with the logical design, you focus on the information

requirements without getting bogged down immediately with
implementation detail.

Create a Logical Design

A logical design is a conceptual, abstract design. You do not deal with the
physical implementation details yet; you deal only with defining the types of
information that you need.

The process of logical design involves arranging data into a series of

logical relationships called entities and attributes. An entity represents a
chunk of information. In relational databases, an entity often maps to a
table. An attribute is a component of an entity and helps define the
uniqueness of the entity. In relational databases, an attribute maps to a
column.

You can create the logical design using a pen and paper, or you can use a
design tool such as Oracle Warehouse Builder or Oracle Designer.

While entity-relationship diagramming has traditionally been associated

with highly normalized models such as online transaction processing
(OLTP) applications, the technique is still useful in dimensional modeling.
You just approach it differently. In dimensional modeling, instead of
seeking to discover atomic units of information and all of the relationships
between them, you try to identify which information belongs to a central
fact table(s) and which information belongs to its associated dimension
tables.

One output of the logical design is a set of entities and attributes

corresponding to fact tables and dimension tables. Another output of
mapping is operational data from your source into subject-oriented
information in your target data warehouse schema. You identify business
subjects or fields of data, define relationships between business subjects,
and name the attributes for each subject.

The elements that help you to determine the data warehouse schema are
the model of your source data and your user requirements. Sometimes, you
can get the source model from your company's enterprise data model and
reverse-engineer the logical data model for the data warehouse from this.
The physical implementation of the logical data warehouse model may
require some changes due to your system parameters--size of machine,
number of users, storage capacity, type of network, and software.
Data Warehousing Schemas

A schema is a collection of database objects, including tables, views,

indexes, and synonyms. There are a variety of ways of arranging schema
objects in the schema models designed for data warehousing. Most data
warehouses use a dimensional model.

Star Schemas

The star schema is the simplest data warehouse schema. It is called a star
schema because the diagram of a star schema resembles a star, with
points radiating from a center. The center of the star consists of one or
more fact tables and the points of the star are the dimension tables shown
in:

Figure 2-1 Star Schema

Unlike other database structures, in a star schema, the dimensions are

denormalized. That is, the dimension tables have redundancy which
eliminates the need for multiple joins on dimension tables. In a star
schema, only one join is needed to establish the relationship between the
fact table and any one of the dimension tables.

Software Implementation and Evaluation

Structured Programming
In the process of coding, the lines of code keep multiplying, thus, size of
the software increases. Gradually, it becomes next to impossible to
remember the flow of program. If one forgets how software and its
underlying programs, files, procedures are constructed it then becomes
very difficult to share, debug and modify the program. The solution to this
is structured programming. It encourages the developer to use subroutines
and loops instead of using simple jumps in the code, thereby bringing
clarity in the code and improving its efficiency Structured programming
also helps programmer to reduce coding time and organize code properly.
Structured programming states how the program shall be coded.
Structured programming uses three main concepts:
 Top-down analysis - A software is always made to perform some
rational work. This rational work is known as problem in the software
parlance. Thus it is very important that we understand how to solve
the problem. Under top-down analysis, the problem is broken down
into small pieces where each one has some significance. Each
problem is individually solved and steps are clearly stated about how
to solve the problem.
 Modular Programming - While programming, the code is broken down
into smaller group of instructions. These groups are known as
modules, subprograms or subroutines. Modular programming based
on the understanding of top-down analysis. It discourages jumps
using ‘goto’ statements in the program, which often makes the
program flow non-traceable. Jumps are prohibited and modular
format is encouraged in structured programming.
 Structured Coding - In reference with top-down analysis, structured
coding sub-divides the modules into further smaller units of code in
the order of their execution. Structured programming uses control
structure, which controls the flow of the program, whereas structured
coding uses control structure to organize its instructions in definable
patterns.

Functional Programming
Functional programming is style of programming language, which uses the
concepts of mathematical functions. A function in mathematics should
always produce the same result on receiving the same argument. In
procedural languages, the flow of the program runs through procedures, i.e.
the control of program is transferred to the called procedure. While control
flow is transferring from one procedure to another, the program changes
its state.
In procedural programming, it is possible for a procedure to produce
different results when it is called with the same argument, as the program
itself can be in different state while calling it. This is a property as well as a
drawback of procedural programming, in which the sequence or timing of
the procedure execution becomes important.
Functional programming provides means of computation as mathematical
functions, which produces results irrespective of program state. This
makes it possible to predict the behavior of the program.

Functional programming uses the following concepts:

 First class and High-order functions - These functions have capability
to accept another function as argument or they return other functions
as results.
 Pure functions - These functions do not include destructive updates,
that is, they do not affect any I/O or memory and if they are not in use,
they can easily be removed without hampering the rest of the
program.
 Recursion - Recursion is a programming technique where a function
calls itself and repeats the program code in it unless some pre-
defined condition matches. Recursion is the way of creating loops in
functional programming.
 Strict evaluation - It is a method of evaluating the expression passed
to a function as an argument. Functional programming has two types
of evaluation methods, strict (eager) or non-strict (lazy). Strict
evaluation always evaluates the expression before invoking the
function. Non-strict evaluation does not evaluate the expression
unless it is needed.
 λ-calculus - Most functional programming languages use λ-calculus
as their type systems. λ-expressions are executed by evaluating them
as they occur.

Common Lisp, Scala, Haskell, Erlang and F# are some examples of

functional programming languages.
Programming style
Programming style is set of coding rules followed by all the programmers
to write the code. When multiple programmers work on the same software
project, they frequently need to work with the program code written by
some other developer. This becomes tedious or at times impossible, if all
developers do not follow some standard programming style to code the
program.
An appropriate programming style includes using function and variable
names relevant to the intended task, using well-placed indentation,
commenting code for the convenience of reader and overall presentation of
code. This makes the program code readable and understandable by all,
which in turn makes debugging and error solving easier. Also, proper
coding style helps ease the documentation and updation.

Coding Guidelines
Practice of coding style varies with organizations, operating systems and
language of coding itself.
The following coding elements may be defined under coding guidelines of
an organization:
 Naming conventions - This section defines how to name functions,
variables, constants and global variables.
 Indenting - This is the space left at the beginning of line, usually 2-8
whitespace or single tab.
 Whitespace - It is generally omitted at the end of line.
 Operators - Defines the rules of writing mathematical, assignment
and logical operators. For example, assignment operator ‘=’ should
have space before and after it, as in “x = 2”.
 Control Structures - The rules of writing if-then-else, case-switch,
while-until and for control flow statements solely and in nested
fashion.
 Line length and wrapping - Defines how many characters should be
there in one line, mostly a line is 80 characters long. Wrapping defines
how a line should be wrapped, if is too long.
 Functions - This defines how functions should be declared and
invoked, with and without parameters.
 Variables - This mentions how variables of different data types are
declared and defined.
 Comments - This is one of the important coding components, as the
comments included in the code describe what the code actually does
and all other associated descriptions. This section also helps creating
help documentations for other developers.
Software Documentation
Software documentation is an important part of software process. A well
written document provides a great tool and means of information
repository necessary to know about software process. Software
documentation also provides information about how to use the product.
A well-maintained documentation should involve the following documents:
 Requirement documentation - This documentation works as key tool
for software designer, developer and the test team to carry out their
respective tasks. This document contains all the functional, non-
functional and behavioral description of the intended software.
Source of this document can be previously stored data about the
software, already running software at the client’s end, client’s
interview, questionnaires and research. Generally it is stored in the
form of spreadsheet or word processing document with the high-end
software management team.
This documentation works as foundation for the software to be
developed and is majorly used in verification and validation phases.
Most test-cases are built directly from requirement documentation.
 Software Design documentation - These documentations contain all
the necessary information, which are needed to build the software. It
contains: (a) High-level software architecture, (b) Software design
details, (c) Data flow diagrams, (d) Database design
These documents work as repository for developers to implement the
software. Though these documents do not give any details on how to
code the program, they give all necessary information that is required
for coding and implementation.
 Technical documentation - These documentations are maintained by
the developers and actual coders. These documents, as a whole,
represent information about the code. While writing the code, the
programmers also mention objective of the code, who wrote it, where
will it be required, what it does and how it does, what other resources
the code uses, etc.
The technical documentation increases the understanding between
various programmers working on the same code. It enhances re-use
capability of the code. It makes debugging easy and traceable.
There are various automated tools available and some comes with
the programming language itself. For example java comes JavaDoc
 tool to generate technical documentation of code.
 User documentation - This documentation is different from all the
above explained. All previous documentations are maintained to
provide information about the software and its development process.
But user documentation explains how the software product should
work and how it should be used to get the desired results.
These documentations may include, software installation procedures,
how-to guides, user-guides, uninstallation method and special
references to get more information like license updation etc.
Software Implementation Challenges
There are some challenges faced by the development team while
implementing the software. Some of them are mentioned below:
 Code-reuse - Programming interfaces of present-day languages are
very sophisticated and are equipped huge library functions. Still, to
bring the cost down of end product, the organization management
prefers to re-use the code, which was created earlier for some other
software. There are huge issues faced by programmers for
compatibility checks and deciding how much code to re-use.
 Version Management - Every time a new software is issued to the
customer, developers have to maintain version and configuration
related documentation. This documentation needs to be highly
accurate and available on time.
 Target-Host - The software program, which is being developed in the
organization, needs to be designed for host machines at the
customers end. But at times, it is impossible to design a software that
works on the target machines.