INTRODUCTION TO SYSTEM DEVELOPMENT LIFE CYCLES
WHAT IS AN INFORMATION SYSTEM (IS)?
Hardware, software, data, people, and procedures that
work together to produce quality information
System—Set of components that interact to achieve
common goal
Businesses use many types of systems
WHAT ARE THE PHASES OF THE SYSTEM DEVELOPMENT CYCLE?
Phase 1. Planning
Phase 2. Analysis
Phase 3. Design
Phase 4. Implementation
Phase 5. Support
Review project requests Prioritize project
requests Allocate resources Identify project
development team
Conduct preliminary investigation Perform detailed analysis activities:
Study current systemDetermine user requirementsRecommend solution
Acquire hardware and software, if necessary
Develop details of system
Develop programs, if necessary Install and test new system Train users Convert to new system
Conduct post-implementation system review
Identify errors and enhancements Monitor system performance
WHO PARTICIPATES IN THE SDLC?
WHAT IS A SYSTEMS ANALYST?
Responsible for designing Responsible for designing and developing and developing
information systeminformation system
Liaison between users Liaison between users and IT professionalsand IT professionals
WHAT IS THE PROJECT TEAM?
Consists of users, systems analyst, and other IT professionals
Formed to work on project from beginning to end
Project leader—one member of the team who manages and controls project budget and schedule
WHAT IS FEASIBILITY?
Measure of how suitable
system development will be to the
company
Operational feasibility
Schedule feasibility
Four feasibility tests:
Technical feasibility
Economic feasibility
(also called cost/benefit feasibility)
WHAT IS DOCUMENTATION?
Includes reports, diagrams, programs, and other deliverables
Collection and summarization of data and information
WHY CREATE (OR MODIFY) AN INFORMATION SYSTEM?
Competition can lead to change
To improve existing system
Outside group may mandate change
To correct problem in existing system
WHAT IS A REQUEST FOR SYSTEM SERVICES? Formal request for
new or modified information system Also called
project request
PLANNING PHASE
Begins when steering committee receives project request
Steering Steering committeecommittee——
decision-making decision-making body for the body for the
companycompany
Function of committee:
Review and Review and approve project approve project
requestsrequests
Allocate Allocate resourcesresources
Form project Form project development development team for each team for each
approved approved projectproject
Prioritize Prioritize project requestsproject requests
ANALYSIS PHASE
Conduct preliminary Conduct preliminary investigation, also investigation, also
called feasibility called feasibility studystudy
Perform detailed Perform detailed analysisanalysis
PRELIMINARY INVESTIGATION Determine exact nature of problem or improvement
and whether it is worth pursuing Findings are presented in feasibility report, also known as a feasibility study
DETAILED ANALYSIS
Sometimes called logical design
2. Determine user’s wants, needs, and requirements
3. Recommend solution
1. Study how current system works
SYSTEM PROPOSAL
Presented to Presented to steering steering
committee, committee, which decides which decides
how system will how system will be developedbe developed
Assesses Assesses feasibility feasibility
of each of each alternative alternative solutionsolution
Recommends Recommends the most the most feasible feasible
solution for solution for the projectthe project
IDENTIFY POSSIBLE SOLUTIONS
Buy packaged software—prewritten software available for purchase
Outsource—have outside source develop software
Write own custom software—software developed at user’s request
Vertical market software—designed
for particular industry
Horizontal market software—meets
needs of many companies
DESIGN PHASE
Acquire hardware and software
Develop all details of new or modified information system
Visit vendors’ storesVisit vendors’ stores
ACQUISITIONWhat is needed to acquire new hardware and software? Identify all hardware and software requirements of new or modified system
Surf WebSurf Web
Read print and Read print and online trade journals, online trade journals,
newspapers, and newspapers, and magazinesmagazines
Talk with other Talk with other systems analystssystems analysts
HOW TO TEST SOFTWARE PRODUCTS?
References from vendor Talk to current users of product Product demonstrations Trial version of software Benchmark test measures performance
DETAILED DESIGN
Includes several activities
Database design
Input and output design
Program design
Detailed design specifications for components in proposed solution
PROTOTYPING TOOLS/METHODS: MOCKUP Sample of input or output that contains actual data
PROTOTYPING TOOLS/METHODS: PROTOTYPE
Working model of proposed system
Beginning a prototype too early may lead to
problems
PROTOTYPING TOOLS/METHODS: CASE CASE (Computer-Aided Software Engineering) tools
support activities of the SDLC
Convert to new systemConvert to new system
IMPLEMENTATION PHASE Purpose is to construct, or build, new or modified
system and then deliver it to users
Train usersTrain users
Install and test new systemInstall and test new system
Develop programsDevelop programs
TESTINGThree kinds of tests performed by system developers:
Verifies application works with other
applications
Systems test
Integration Test
Unit Test
Verifies each individual program
works by itself
Verifies all programs in application work
together
TRAINING Showing users exactly how they will use new
hardware and software in system
SUPPORT PHASE
Conduct post-implementation system review—meeting to find out if information system is performing according to expectations
Identify errors
Identify enhancements
Monitor system performance
Providing ongoing assistance after the system is implemented
FEASIBILITY Every organization which performs system
development, or has it done for them, needs a way to choose which projects are worth the effort
Feasibility study is a common approach to make such decisions thoughtfully
Basis for feasibility study is generally the problems and opportunities analysis
PROBLEMS & OPPORTUNITIES We can look for problems and opportunities
in many parts of our organization, and the existing systems which are supported Track maintenance costs for existing systems Measure existing processes to determine their
cost, and compare to industry standards Monitor availability of support for existing
system components Look for signs of unhappy employees
Check quality of work products (outputs) Listen to customers, vendors, and suppliers
Both complaints and suggestions Measure customer satisfaction Monitor competitor’s offerings and plans Monitor changes in technology which could help Don’t forget obvious measures of success, like
sales, profit, or number of contracts awarded
PROBLEMS & OPPORTUNITIES
PROJECT SELECTION Selection of projects is based on many
factors – cost, urgency, the systems affected, etc.
From the organization’s perspective, choosing projects is kind of like shopping There’s generally a limited amount of funds
and people available to work on the possible projects, and management needs to choose which projects to support
There are five typical requirements for a project to be supported Management support for the project Appropriate timing of commitment to the project Relevance to helping meet organizational goals Project must be practical and feasible Project must be worthwhile compared to other
possible expenditures Are we getting enough ‘bang for our buck?’
PROJECT SELECTION
PROJECT OBJECTIVES Based on the problems and opportunities
identified for a project, we can set objectives for the project These not only help the feasibility study which
follows, but set goals against which we can later test the system
Objectives should not only address the type of improvement sought, but set a desired level of improvement
Examples of objectives might include Improve customer satisfaction 10% within 1 year Reduce the response time for customer
complaints by 15% Get a new feature to market before competitors Reduce error rate for data entry from 2% to 0.5% Improve sales to new customers by 5% Reduce voluntary employee turnover by 10%
PROJECT OBJECTIVES
FEASIBILITY ANALYSIS
Feasibility consists of several types we want to assess for each candidate project Technical feasibility
Can the project be done with existing technology? Are people available to use the technologies needed?
Economic feasibility How much does the system cost to develop? Maintain?
How long will it be usable? Some add schedule feasibility – how long will it take
to create the system?
Operational feasibility What impact will the new system have on how we do
business? Will there be changes to where or how processes are performed?
Will there be changes to employee skills needed? Changes to employee training?
Are existing users amenable to a new system? These types of feasibility can be measured
for each project, and compared to determine which is most feasible
FEASIBILITY ANALYSIS
Like voting or buying a car, feasibility analysis is rarely completely logical or quantifiable
Many other issues can also affect it Political climate State of the US and/or global economy Preferences of the decision makers – favored
vendors, technologies, types of projects, etc.
FEASIBILITY ANALYSIS
PLANNING ACTIVITIES To help structure development activities, we
use a life cycle model to identify the major sets of activities, called life cycle phases
There are many kinds of life cycle models The Waterfall model is the oldest, and uses
phases like Requirements Analysis, High Level Design, Low Level Design, Coding, and Testing
The Rational Unified Process has Inception, Elaboration, Construction, and Transition phases
Each life cycle phase is broken down into more and more specific activities, until the time needed for each activity can be reliably estimated
Then the tasks are put into a Gantt chart or Pert chart to show when they occur relative to each other Tasks might occur sequentially, have to start
or end together, or wait for some other tasks to be completed
PLANNING VIA THE SDLC
Tasks for a project often include the acts of creating specific documents or work products, approving things or making decisions; such as ‘Prepare system test plan’ ‘Approve system release’ ‘Conduct user satisfaction survey’ ‘Approve system requirements specification’
So the life cycle model provides guidance on the types of activities needed, but the tasks provide authority for people to do them
PLANNING VIA THE SDLC
WATERFALL MODEL
FEATURES OF A WATERFALL MODEL
A waterfall model is easy to follow. It can be implemented for any size project. Every stage has to be done separately at the right
time so you cannot jump stages. Documentation is produced at every stage of a
waterfall model allowing people to understand what has been done.
Testing is done at every stage.
ADVANTAGES OF A WATERFALL MODEL
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
DISADVANTAGES OF A WATERFALL MODEL
All requirements must be known up front 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.
AGILE SDLCS
Speed up or bypass one or more life cycle phases
Usually less formal and reduced scope Used for time-critical applications Used in organizations that employ disciplined
methods
AGILE MANIFESTO
SOME AGILE METHODS Adaptive Software Development (ASD) Feature Driven Development (FDD) Crystal Clear Dynamic Software Development
Method (DSDM) Rapid Application Development (RAD) Scrum Extreme Programming (XP) Rational Unify Process (RUP)
EXTREME PROGRAMMING - XP
For small-to-medium-sized teams developing software with vague or rapidly changing requirements
Coding is the key activity throughout a software project
Communication among teammates is done with code
Life cycle and behavior of complex objects defined in test cases – again in code
XP PRACTICES (1-6)
1. Planning game – determine scope of the next release by combining business priorities and technical estimates
2. Small releases – put a simple system into production, then release new versions in very short cycle
3. Metaphor – all development is guided by a simple shared story of how the whole system works
4. Simple design – system is designed as simply as possible (extra complexity removed as soon as found)
5. Testing – programmers continuously write unit tests; customers write tests for features
6. Refactoring – programmers continuously restructure the system without changing its behavior to remove duplication and simplify
XP Practices (7 – 12)
7. Pair-programming -- all production code is written with two programmers at one machine
8. Collective ownership – anyone can change any code anywhere in the system at any time.
9. Continuous integration – integrate and build the system many times a day – every time a task is completed.
10. 40-hour week – work no more than 40 hours a week as a rule
11. On-site customer – a user is on the team and available full-time to answer questions
12. Coding standards – programmers write all code in accordance with rules emphasizing communication through the code
XP is “extreme” because
Commonsense practices taken to extreme levels
If code reviews are good, review code all the time (pair programming)
If testing is good, everybody will test all the time If simplicity is good, keep the system in the simplest design that
supports its current functionality. (simplest thing that works) If design is good, everybody will design daily (refactoring) If architecture is important, everybody will work at defining and
refining the architecture (metaphor) If integration testing is important, build and integrate test
several times a day (continuous integration) If short iterations are good, make iterations really, really short
(hours rather than weeks)
SUMMARY
This has been a (very) quick tour through the life cycle of a system.
You will have to do—to some extent—all of these activities for your project.