Introduction of Topic

SYSTEMS
DEVELOPMENT

Copyright © 2006 by The McGraw-Hill Companies, Inc. All rights reserved.

 What is Systems
Development?

• It refers to the set of activities that create

systems for the effective and efficient processing
of information.
• The structuring of hardware and software
to achieve the effective and efficient
processing of information. Information
systems are developed keeping in view the
needs to be met.

Copyright © 2006 by The McGraw-Hill Companies, Inc. All rights reserved.

 What is Systems
Development?

• Information System (IS) is a system that

gathers information and gives the related
output.
• The system will process the collection of
data and verified it to produce the related
output. The system will process by
following the instructions or procedures.

Copyright © 2006 by The McGraw-Hill Companies, Inc. All rights reserved.

 Reasons for Systems
Development:
 Need to solve problems with an
existing system
(Replacement/Improvement)
 A manual information system is to be
computerized.
 To exploit opportunities to gain
competitive advantage
 To increase competition

Copyright © 2006 by The McGraw-Hill Companies, Inc. All rights reserved.

 Reasons for Systems
Development:
 To make use of effective information
 To spur organizational growth
 To settle a merger or corporate
acquisition
 To address a change in the market or
external environment
 External pressures (Potential
lawsuits or terrorists attacks)

Copyright © 2006 by The McGraw-Hill Companies, Inc. All rights reserved.

Planning for Systems Development
Information Systems (IS) Planning
• IS Planning refers to the translation of
strategic and organizational goals into
systems development initiatives.

• Benefits of IS planning include a long

range view of Information Technology
use and better use of IS resources
 Planning (continued)
• Planning requires developing overall IS
objectives; identifying IS projects; Setting
priorities and selecting projects;
analyzing resource requirements; setting
schedules, milestones and deadlines;
and developing the IS planning
document.
• IS planning can result in a competitive
advantage through creative and critical
analysis.
 Planning (continued…)
• Establishing objectives for systems
development is a key aspect of any
successful project.
Planning Is Done By The Management
Regarding the Following Issues
• Scope of Systems development – certain
selected areas or the entire organization.
• How to get the project done – in-house
committee or hired consultants
• How much resource and time
commitment can be made
• Any written policy on which model is
needed to be followed for software
development
 Phases of IS planning
• Orientation
This start-up phase is required to
establish the scope of the plan and the
methodology and techniques to be
applied
• Assessment
Confirm business direction and drivers;
Review technology trends; outline future
requirements;
Inventory existing information systems;
• Assessment
 Confirm business direction and drivers
 Review technology trends
 outline future requirements
 Inventory existing information systems
 Develop an assessment of what is needed

In the concluding step of this phase there should

be a well-developed assessment of the current
and future business needs,
• Strategic Plan
This phase commences with developing the vision
and desired future positioning of information
technology within the organization.
• Tactical Plan
The selected strategies are divided into a series of
projects which are scheduled for implementation
depending upon relative priorities and resource
availability. The planning process is concluded by
recommending a monitoring and control
mechanism.
 The Systems
Development Life
Cycle
(SDLC)
It was started in the 1960s and 1970s as the
first
documented approach to computer systems
development. All the stages of the development
system are thought about, planned, monitored
and Completed. SDLC is the process by which
an Information System comes to life and
maintains its usefulness to a business as it
moves from inception to replacement.
The Seven Phases of SDLC
 Phase 1: Identifying problems,
opportunities, and objectives
• Requires that the analyst honestly
analyze what is occurring in a business.
• The analyst should check aspects of
information systems by addressing
specific problems or opportunities.
• The analyst should be able to see if
some aspects of information systems
applications can help the business reach
its objectives through addressing specific
problems or opportunities.
 Phase 1: Identifying problems,
opportunities, and objectives
Problem Analysis Steps:

1. Identify stakeholders.
2. Understand the root causes.
3. Gain agreement on the problem definition.
4. Identify constraints on the system or project.
5. Identify and validate the solution against the
root causes.
6. Define the solution system boundary.
 Phase 1: Identifying problems,
opportunities, and objectives
• Personnel involved:
– Analyst.
– User management.
– Systems management.
 Phase 2: Determining Information
Requirements
• The analyst strives to understand what
information users need to perform their
jobs.
• Determining information requirements:
– Interview management, operations personnel.
– Gather systems/operating documents.
– Use questionnaires.
– Observe the system and personnel involved.
Phase 2: Determining Information
Requirements
• Understand how the business functions
and have complete information on the
people, goals, data, and procedures
Phase 2: Determining Information
Requirements
• The systems analyst needs to know the
details of current system functions:
– Who (the people who are involved)
– What (the business activity)
– Where (the environment in which the work
takes place)
– When (the timing)
– How (how the current procedures are
performed)
– Why (why the business uses the current
system)
Phase 2: Determining Information
Requirements
• Personnel involved:
– Analyst.
– User management.
– User operations workers.
– Systems management.
Phase 3: Analyzing Systems Needs

• Analyze system needs through the

following:
– Create data or process flow diagrams.
– Document procedural logic and narratives
for the diagrams.
– Complete the data dictionary.
– Make semi-structured decisions.
– Prepare and present the system proposal.
– Recommend the optimal solution to
management.
Phase 3: Analyzing Systems Needs

• Analyst makes recommendations to

management
• Management decides whether to
continue or not
• Personnel involved:
– Analyst.
– User management.
– Systems management.
Phase 4: Designing the Recommended
System
• The systems analyst uses the information
collected earlier in order to accomplish the
logical design of the information system.
• Designing the recommended system:
– Design the user interface.
• Design output.
• Design input.
– Design system controls.
– Design files and/or database.
– Produce program specifications.
– Produce decision trees or tables.
Phase 4: Designing the Recommended
System
• Personnel involved:
– Analyst.
– System designer.
– User management.
– User operations workers.
– Systems management.
Phase 5: Developing and Documenting
Software
• SA works with users and communicates
to the developers what needs to be
programmed and documented
• Developing and documenting software
involve:
– Documenting detailed design
– Walkthrough of program design
– Writing computer programs
– Document software with help files,
procedure manuals, and Web sites with
Frequently Asked Questions.
Phase 5: Developing and Documenting
Software
• SA works with users for the
development of worthwhile
documentation for software, including
procedure manuals.
• Personnel involved:
– Analyst.
– System designer.
– Programmers.
– Systems management.
Phase 6: Testing and Maintaining the
System

• A series of tests to pinpoint problems is

run first with sample data and eventually
with actual data from the current system.

• Testing and maintaining the system:

– Test and debug computer programs.
– Test the computer system.
– Enhance system.
Phase 6: Testing and Maintaining the
System
• Personnel involved:
– Analyst
– System designer
– Programmers
– Systems management
Phase 7: Implementing and Evaluating the
System
• Activities:
– Plan conversion.
– Train users.
– Purchase and install new equipment.
– Convert files.
– Install system.
– Review and evaluate system.
Phase 7: Implementing and Evaluating the
System
• This involves training users to use the
system
• A key criterion that must be satisfied is
whether the intended users are indeed
using the system.
• Review and evaluate system - whether
the intended users are indeed using the
system
Phase 7: Implementing and Evaluating the
System
• Personnel involved:
– Analyst.
– System designer.
– Programmers.
– User management.
– User operations workers.
– Systems management.
• Training:
– New system training must be performed.
– Analysts must consider:
• Who needs to be trained.
• Who will train them.
• Objectives of training.
• Methods of instruction to be used.
• Sites.
• Materials.
– Possible sources of training for users
of information systems include:
• Vendors.
• Systems analysts.
• External paid trainers.
• In-house trainers.
• Other system users.
A. Waterfall Model
 Waterfall Model

• The best-known and oldest process is

the waterfall model, where
developers follow these steps in
order. They state requirements,
analyze them, design a solution
approach, architect a software
framework for that solution, develop
code, test (perhaps unit tests then
system tests), deploy, and maintain.
 Waterfall Model
• After each step is finished, the process
proceeds to the next step, just as builders
don't revise the foundation of a house after
the framing has been erected. If iteration is
not included in the planning, the process
has no revision for correcting errors in
early steps , so the entire expensive)
engineering process may be executed to
the end, resulting in unusable or unneeded
software features.
 Waterfall Strengths
• Easy to understand, easy to use
• Provides structure to inexperienced staff
• Milestones are well understood
• Sets requirements stability
• Good for management control (plan, staff,
track)
• Works well when quality is more important
than cost or schedule
 Waterfall Deficiencies
• All requirements must be known upfront
• Deliverables created for each phase are
considered frozen – inhibits flexibility
• Can give a false impression of progress
• Does not reflect problem-solving nature of
software development – iterations of phases
• Integration is one big bang at the end
• Little opportunity for customer to preview the
system (until it may be too late)
When to use the Waterfall Model
• Requirements are very well known
• Product definition is stable
• Technology is understood
• New version of an existing product
• Porting an existing product to a new
platform.
B. V-Shaped SDLC Model
• A variant of the Waterfall
that emphasizes the
verification and validation
of the product.
• Testing of the product is
planned in parallel with a
corresponding phase of
development
• The V-model is an extension of the waterfall
model.
• Instead of moving down in a linear way, the
process steps are bent upwards after the coding
phase, to form the typical V shape.
• The V-Model demonstrates the relationships
between each phase of the development life
cycle and its associated phase of testing. The
horizontal and vertical axes represents time or
project completeness (left-to-right) and level of
abstraction (coarsest-grain abstraction
uppermost), respectively.
 V-Shaped Strengths
• Emphasize planning for verification and
validation of the product in early stages
of product development
• Each deliverable must be testable
• Project management can track progress
by milestones
• Easy to use
 V-Shaped Weaknesses
• Does not easily handle concurrent
events
• Does not handle iterations or phases
• Does not easily handle dynamic
changes in requirements
• Does not contain risk analysis activities
When to use the V-Shaped Model
• Excellent choice for systems requiring
high reliability – hospital patient control
applications
• All requirements are known up-front
• When it can be modified to handle
changing requirements beyond analysis
phase
• Solution and technology are known
 C. PROTOTYPE MODEL
• Prototyping is the process of quickly putting
together a working model in order to test
various aspects of a design, illustrate ideas
or features and gather early user feedback.
• Prototyping is often treated as an integral
part of the system design process, where it
is believed to reduce project risk and cost.
 PROTOTYPE MODEL

• Often one or more prototypes are made

in a process of incremental development
where each prototype is influenced by
the performance of previous designs, in
this way problems or deficiencies in
design can be corrected
 PROTOTYPE MODEL
START

PROTOTYPE
REQUIREMENT QUICK
BUILDING
ANALYSIS DESIGN

ENGINEER THE REDEFINE USER

PRODUCT PROTOTYPE EVALUATION

STOP
 Prototyping Model
 Developers build a prototype during the
requirements phase
 Prototype is evaluated by end users
 Users give corrective feedback
 Developers further refine the prototype
 When the user is satisfied, the prototype
code is brought up to the standards
needed for a final product.
 Prototyping Model Steps
 A preliminary project plan is developed
 A partial high-level paper model is created
 The model is source for a partial requirements
specification
 A prototype is built with basic and critical attributes
 The designer builds
 the database
 user interface
 algorithmic functions
 The designer demonstrates the prototype, the user
evaluates for problems and suggests
improvements.
 This loop continues until the user is satisfied
 PROTOTYPE MODEL

Advantages :
 Can be used when customer is not sure

about what he wants

 Faster way of finalizing the requirements

 Useful for new technologies and

domains
 PROTOTYPE MODEL

Disadvantage :
 A prototype if used in a production

environment, may lack quality

 Overall maintainability may be

overlooked
 The customer may want the prototype

delivered.
 Process may continue forever (scope

creep)
• The spiral model is a software
development process combining elements
of both design and prototyping-in-stages,
in an effort to combine advantages of top-
down and bottom-up concepts.
• This model of development combines the
features of the prototyping model and
the waterfall model. The spiral model is
intended for large, expensive and
complicated projects.
• Construct a partial
implementation of a total
system
• Then slowly add increased
functionality
• The incremental model
prioritizes requirements of
the system and then
implements them in groups.
• Each subsequent release of
the system adds function to
the previous release, until all
designed functionality has
been implemented.
 Spiral Model Steps

Iterates cycles of these project phases:

1 Requirements definition
2 Risk analysis
3 Prototyping
4 Simulate, benchmark
5 Design, implement, test
6 Plan next cycle (if any)
Steps in the spiral model include:
• The new system requirements are defined.
This usually involves interviewing a number of
users representing all the end users of the
system.
• A preliminary system design is created.
• An initial prototype of the new system is
constructed from the preliminary design. This
is usually a scaled-down system, and
represents an approximation of the final
product’s characteristics.
• After evaluating the strengths, weaknesses
and risks of the first prototype, a second
prototype is developed and tested.
• If the risk is considered to be too great, the
client may choose to terminate the project at
this point. Risk factors to be considered
include development cost overruns, operating-
cost miscalculation, etc.
• Subsequent prototypes are developed until
the customer is satisfied that the latest
prototype represents the desired product.
• The system is constructed, based on the final
prototype.
• The final system is evaluated and tested.
Routine maintenance is carried out continually
to prevent large-scale failures and to minimize
downtime.
Structured Evolutionary Prototyping
Model
• Developers build a prototype during the
requirements phase
• Prototype is evaluated by end users
• Users give corrective feedback
• Developers further refine the prototype
• When the user is satisfied, the prototype
code is brought up to the standards
needed for a final product.
• Advantages of Spiral Model
1. Avoidance of Risk is enhanced.
2. Strong approval and documentation
control.
3. Implementation has priority over
functionality.
4. Additional Functionality can be added
at a later date.
• Disadvantages of Spiral Model
1. Highly customized limiting re-usability
2. Applied differently for each application

3. Risk of not meeting budget or

schedule
4. Possibility to end up implemented as
the Waterfall framework
 When to use Spiral Model
 When creation of a prototype is appropriate
 When costs and risk evaluation is
important
 For medium to high-risk projects
 Long-term project commitment unwise
because of potential changes to economic
priorities
 Users are unsure of their needs
 Requirements are complex
 New product line
 Significant changes are expected
(research and exploration)
Structured Evolutionary Prototyping
Steps
• A preliminary project plan is developed
• An partial high-level paper model is created
• The model is source for a partial requirements
specification
• A prototype is built with basic and critical attributes
• The designer builds
– the database
– user interface
– algorithmic functions
• The designer demonstrates the prototype, the user
evaluates for problems and suggests improvements.
• This loop continues until the user is satisfied
Structured Evolutionary Prototyping
Strengths
• Customers can “see” the system requirements
as they are being gathered
• Developers learn from customers
• A more accurate end product
• Unexpected requirements accommodated
• Allows for flexible design and development
• Steady, visible signs of progress produced
• Interaction with the prototype stimulates
awareness of additional needed functionality
Structured Evolutionary Prototyping
Weaknesses
• Tendency to abandon structured program
development for “code-and-fix” development
• Bad reputation for “quick-and-dirty” methods
• Overall maintainability may be overlooked
• The customer may want the prototype
delivered.
• Process may continue forever (scope creep)
 When to use
Structured Evolutionary Prototyping
• Requirements are unstable or have to be
clarified
• As the requirements clarification stage of a
waterfall model
• Develop user interfaces
• Short-lived demonstrations
• New, original development
• With the analysis and design portions of
object-oriented development.
Rapid Application Model (RAD)
• Requirements planning phase (a workshop
utilizing structured discussion of business
problems)
• User description phase – automated tools
capture information from users
• Construction phase – productivity tools, such
as code generators, screen generators, etc.
inside a time-box. (“Do until done”)
• Cutover phase -- installation of the system,
user acceptance testing and user training
 RAD Strengths
• Reduced cycle time and improved productivity
with fewer people means lower costs
• Time-box approach mitigates cost and
schedule risk
• Customer involved throughout the complete
cycle minimizes risk of not achieving customer
satisfaction and business needs
• Focus moves from documentation to code
(WYSIWYG).
• Uses modeling concepts to capture
information about business, data, and
processes.
 RAD Weaknesses
• Accelerated development process must give
quick responses to the user
• Risk of never achieving closure
• Hard to use with legacy systems
• Requires a system that can be modularized
• Developers and customers must be
committed to rapid-fire activities in an
abbreviated time frame.
 When to use RAD
• Reasonably well-known requirements
• User involved throughout the life cycle
• Project can be time-boxed
• Functionality delivered in increments
• High performance not required
• Low technical risks
• System can be modularized
Incremental SDLC Model
• Construct a partial
implementation of a total
system
• Then slowly add increased
functionality
• The incremental model
prioritizes requirements of the
system and then implements
them in groups.
• Each subsequent release of
the system adds function to
the previous release, until all
designed functionality has
been implemented.
Incremental Model Strengths
• Develop high-risk or major functions first
• Each release delivers an operational product
• Customer can respond to each build
• Uses “divide and conquer” breakdown of
tasks
• Lowers initial delivery cost
• Initial product delivery is faster
• Customers get important functionality early
• Risk of changing requirements is reduced
Incremental Model Weaknesses
• Requires good planning and design
• Requires early definition of a complete
and fully functional system to allow for
the definition of increments
• Well-defined module interfaces are
required (some will be developed long
before others)
• Total cost of the complete system is not
lower
When to use the Incremental Model
• Risk, funding, schedule, program complexity, or
need for early realization of benefits.
• Most of the requirements are known up-front but
are expected to evolve over time
• A need to get basic functionality to the market
early
• On projects which have lengthy development
schedules
• On a project with new technology
Spiral SDLC Model
• Adds risk analysis,
and 4gl RAD
prototyping to the
waterfall model
• Each cycle involves
the same sequence of
steps as the waterfall
process model
 Spiral Quadrant
Determine objectives, alternatives and constraints

• Objectives: functionality, performance,

hardware/software interface, critical success factors, etc.
• Alternatives: build, reuse, buy, sub-contract, etc.
• Constraints: cost, schedule, interface, etc.
 Spiral Quadrant
Evaluate alternatives, identify and resolve risks
• Study alternatives relative to objectives and
constraints
• Identify risks (lack of experience, new technology,
tight schedules, poor process, etc.
• Resolve risks (evaluate if money could be lost by
continuing system development
 Spiral Quadrant
Develop next-level product
• Typical activites:
– Create a design
– Review design
– Develop code
– Inspect code
– Test product
 Spiral Quadrant
Plan next phase
• Typical activities
– Develop project plan
– Develop configuration management plan
– Develop a test plan
– Develop an installation plan
 Spiral Model Strengths
• Provides early indication of insurmountable
risks, without much cost
• Users see the system early because of rapid
prototyping tools
• Critical high-risk functions are developed first
• The design does not have to be perfect
• Users can be closely tied to all lifecycle steps
• Early and frequent feedback from users
• Cumulative costs assessed frequently
 Spiral Model Weaknesses
• Time spent for evaluating risks too large for small or low-
risk projects
• Time spent planning, resetting objectives, doing risk
analysis and prototyping may be excessive
• The model is complex
• Risk assessment expertise is required
• Spiral may continue indefinitely
• Developers must be reassigned during non-development
phase activities
• May be hard to define objective, verifiable milestones
that indicate readiness to proceed through the next
iteration
 When to use Spiral Model
• When creation of a prototype is appropriate
• When costs and risk evaluation is important
• For medium to high-risk projects
• Long-term project commitment unwise
because of potential changes to economic
priorities
• Users are unsure of their needs
• Requirements are complex
• New product line
• Significant changes are expected (research
and exploration)
Systems Development Life Cycle
• Phase 1: preliminary investigation
This phase is ground level and
initial phase of SDLC.it is too much time
consuming phase, almost half of the
time to complete the SDLC is taken by
this pahse.The main objectives of this
phase are:
 Conduct the preliminary analysis
 Propose alternative solution
 Describe the costs and benefits
 Submit the report
Systems Development Life Cycle
1-Conduct the preliminary investigation

To find the objectives of organization

Nature and scope of problem
To see the faults of older system
Make the ideas for the new system
Systems Development Life Cycle
2-Propose the alternative solution

 No change
 Little change
 Totally change
Systems Development Life Cycle
3-Describe cost and benefits
• Whichever the alternative is chosen,
it will have cost and benefits. in this
step, you need to indicate these.

4-Write a report
Submission of prepared
report about new software. this report is
also called the feasibility report.
• In this report you should describe the
solution,cost,benefits etc
Systems Development Life Cycle
Phase 2: Systems analysis
After preparation of the feasibility
report the system is analyzed
accordingly.
• The main objectives of this phase are
– Gather data
– Analyze the data
– Write a report
Systems Development Life Cycle
1-Gather data:--
data is gathered through the
different written documents, interview
employees and managers, develop
questionnaires and by observing people.

2-Analyze data:--
Once the data has been
gathered, many analytical or modeling
tools are used.
Systems Development Life Cycle
Modeling tools:-
Modeling tools enable a
system analyst to present representation
of a system. There are different tools for
analyzing data these are:
 DFD (data flow diagram)
 ERD (entity relationship diagram)
 CASE (computer aided software
engineering)
Systems Development Life Cycle
DFD (data flow
diagram)
it is
a modeling tool
which shows the
flow of data through
a system. some
symbols are used in
DFD
Systems Development Life Cycle
• DFD (data flow diagram)

• Provide a logical map of the problem

• Defines the data stores and
processes
• Shows how data moves and changes
Example Flow Chart Symbols

Alternate Data
Process Decision
Process

Predefined Document Preparation

Terminator
Process

Manual Manual Display

Input Operation Off page
Connector Connector

Merge
Delay Data
Extract Storage
Systems Development Life Cycle
• Example
Systems Development Life Cycle
• Phase-3 Design the system

 Do the preliminary design

 Do a detail design
 Write a report
Systems Development Life Cycle
• Do the preliminary design
prototyping is often done at
this stage.
. Prototyping
prototyping refers to using
workstations,CASE tools and other
software applications to build working
models of system components so that
they quickly tested and evaluated.Thus
a prototype is a limited working system.
•
Systems Development Life Cycle
• Analysis concentrates on what the
purposed system should do, design
concentrates on how the system will
accomplish those goals.
Systems Development Life Cycle
• Translating alternative solution generated by
analysis phase into detailed logical and
physical system specifications.
– Logical design: not tied to any hardware
or software platform
– Physical design: specific programming
languages, databases, architectures
System development life cycle
– Define database, load with data, and review
with users
– Define inputs, and review with users
– Define outputs, and review with users
– Define interfaces, and review with users
– Define other controls, and implement.
Conclusion
End of topic

Copyright © 2006 by The McGraw-Hill Companies, Inc. All rights reserved.