System Development Process
• A set of activities that applies to all software projects
regardless of their size or complexity
• Includes activities, methods, best practices, deliverables,
and tools that stakeholders use to develop and maintain
information systems and software
• There is no ‘ONE PROCESS STANDARD’
• Matured organizations have ‘more’ consistent processes
• Experience shows that ‘well managed’ software processes
lead to least cost software development
• One of the most well known framework is the CMM
IST321 Ch3 1
Why worry about software process?
• Need to move software from an art to science
IMMATURE MATURE
Improvised process Staff know what is expected of
them
If process exists, not followed Mandated documented process
rigorously
Routinely exceed budgets and Method to update process
schedules
Compromises made to meet Active broad based
deadlines organizational involvement
No objective basis for product Quality is monitored
quality assessment
Testing and QA suffer to meet Objective basis for quality of
deadlines products and process
IST321 Ch3 2
Capability Maturity Model (CMM)
• Developed by the Software Engineering Institute
• Process maturity is specified in 5 levels
– Level 1 Initial
– Level 2 Repeatable
– Level 3 Defined
– Level 4 Managed
– Level 5 Optimizing
• Level 5 indicates most matured software development
process
• Maturity level is considered as an effectiveness indicator
IST321 Ch3 3
What are these CMM Levels
• Initial -
– Adhoc and occasionally chaotic development process
– Few processes are formally defined
– Software is ‘successfully’ completed due to individual &
sometimes heroic effort
• Repeatable
– Basic Project Management practices are used including tracking
cost, and schedule
– Repeat previous success
• Defined
– Documented process of software management and engineering
– Standardization of process and engineering practices
IST321 Ch3 4
What are these CMM Levels
• Managed
– Detailed measurement of product quality and process
– Quantitative evaluation methods and tools
• Optimizing
– Continuous process improvement
– Defect prevention
– Technology change management
– Process change management
– Feedback loop
IST321 Ch3 5
Life Cycle and Methodology
• System Development Life Cycle - Development processes
are often derived from a system life cycle
– Provides a framework to organize a large number of activities that
the development process incorporates
– Usually divided into phases and each phase into activities
– Phases are usually presented as a sequential set with each phase
ending with a set of deliverables
– A number of life-cycle models exist: Waterfall Model, Spiral
model
– Each model has its own terminology even though they all strive to
present the same information
IST321 Ch3 6
Life Cycle and Methodology
• System Development Methodologies - Refer to tools and
techniques used to complete tasks of various phases.
– We may use structured design technique to design computer
programs; the technique would be a methodology where as system
design is a phase of the life cycle
– A matured organization should use methodologies such that its life
cycle process is at least repeatable and well defined
– A number of commercial tools are available to support system
development methodologies
• Information Engineering workbench
• Oracle Designer
• Arthur Anderson Method and Design tools
IST321 Ch3 7
Basic Success Factors of a System
Development
• System owners need to be champions of the proposed system
• Methodologies used should be geared towards problem solving
• Intermediate mile stones should be established and outcomes should be
measurable
• Project must adopt consistent standards for practice and documentation
- has a significant impact of the capability maturity of an organization
• Establish procedures for the revision of scope; don’t be afraid to cancel
or revise, if necessary
• Keep scalability and the ability to change in mind; all systems decay
(entropy)
• Systems should be justified as capital investment
IST321 Ch3 8
How systems get started and approved
• Can be classified into 3 categories
– Problem recognition
– Recognition of opportunity
– Legal or management fiat
• PIECES framework of James Wetherbe
– P need to improve performance
– I need to improve information
– E need to improve economics
– C need to improve control or security
– E need to improve efficiency of people and processes
– S need to improve service to customers, suppliers etc
IST321 Ch3 9
How systems get started and approved
• Many projects are initiated in an unplanned manner
• Approval of these projects often depend upon budget and
perceived contribution
• More systematic approach is through Strategic IS plan
• Strategic IS plan is made to support organizational
strategic plan
• The fit of a specific proposal is the basis of a project’s
approval
• Approval may be the responsibility of individuals, but
more often that of a steering committee
IST321 Ch3 10
Life Cycle Phases
• Preliminary Investigation phase
• Problem Analysis phase
• Requirement Analysis phase
• Decision Analysis phase
– Technical Feasibility
– Operational Feasibility
– Economic Feasibility
– Schedule Feasibility
– Risk Feasibility
• Design Phase
• Construction Phase
• Implementation Phase
IST321 Ch3 11
Cross Life Cycle Activities
• Activities that are common to many phases of the life
cycle
– Fact Finding - information gathering
– Documentation and Presentation
– Project Management
IST321 Ch3 12
Phase Principles
• Each phase is associated with a set of tasks
• Each phase has a set of deliverables
• Mile stones and budgets can be associated with
these deliverables
• Each phase has some participants with well defined
roles
• There are risks associated with each phase
• Output of one phase is generally the input to the
next phase
• Presented sequentially, in reality, not
IST321 Ch3 13
Preliminary Investigation Phase
• Consider the feasibility of the proposed system
– Technically? Financially? Organizationally? Timely?
• Determine scope, size, preliminary budget, time frame
• Gathering information is necessary - quickly done with
minimal determination
• The analyst often talks to key personnel at this stage -
system owner and technical leadership of IS organization
• Outcome: An initial feasibility report, with some
alternative solutions, and initial project parameters
• Should we carry out feasibility for all systems?
IST321 Ch3 14
Problem Analysis Phase
• Often the beginning of an analysis process
• Analyst need to understand the scope in detail
• System users and owners are integral part of the study
process, since only they have the complete information
• Results in an updated system scope definition
• System owners have an opportunity to reassess their
go/no go decision
• We will look at information gathering techniques next in
some detail before moving on to other phases
IST321 Ch3 15
Information Gathering
• Techniques
– Sampling of existing documentation
– Research and site visits
– Observation of the work environment
– Questionnaire
– Interviews
• Often, more than one techniques is used in a project
IST321 Ch3 16
Sampling of Documentation
• Objective is to understand policies, procedures,
techniques and data used to complete business operations
• Type of documents to be studied
– Standard reports, data gathering forms, procedure manuals
– Database and file system architectures
– Existing project dictionaries, documentation
– Organizational policies, plans as applicable
– No cook book approach exists, judgment is needed to select
• Sampling can be used to select documents, however it is
more desirable to have a ‘sample’ of every document
type
IST321 Ch3 17
Research and site visit
• Analyst can gain from the experience of others
• Site visit can lead to an understanding of the operational
environment
• Research resources may include
– Standard library search
– Use of the World Wide Web
– User groups
– Published reports of other comparable organizations
IST321 Ch3 18
Observation of the work environment
• Analyst can gain a first hand knowledge regarding the
operational practice or the setting in which the system
may be used
• Advantages
– Data gathered can be highly reliable
– Physical conditions of work, decision making etc
• Disadvantages
– Beware of the Hawthrone effect
– Observation time may not coincide with peak effort level
– Seasonality and cyclic patterns may be missed
IST321 Ch3 19
Observation of the work environment
• A detailed planning should be done for observation
– who should be observed?
– When do the observation take place?
– How does the schedule match with normal work flows
• Observation should not lead to work disruption
• Necessary authorization must exist for conducting an
observation session
IST321 Ch3 20
Questionnaire
• The best method to collect responses from a very wide
range of people
• Usually inexpensive, but one has to be careful about the
response rates
• Lacks the depth and intimacy of observation, but benefits
from the anonymity a respondent enjoys
• Questionnaires tend to be inflexible, and suffers from the
possibility of missing important details
• Lengthy questionnaires are ignored
• Bias in the questions are highly undesirable
IST321 Ch3 21
Questionnaire
• Questionnaires can be open-ended or structured
• Structured questions are easy to answer and analyze, but
often the depth of understanding is sacrificed
• Open-ended questions allow more in-depth information
gathering, but often prove difficult to analyze and
aggregate
IST321 Ch3 22
Interviews
• Perhaps the best method of information gathering since
each topic can be studied in detail
• Time-consuming and often expensive
• Interviewer bias, if any, can seriously taint the collected
data
• Format of interviews are similar to questionnaires -
open-ended vis-a-vis structured
• Interviewer should be well prepared, with subjects
defined ahead of time
• Objectives must also be clearly defined
IST321 Ch3 23
Requirement Analysis Phase
• Sometimes called Systems Analysis
• Objective is to define the scope of the system - what the
system must do and not how it will be done
– Desired capabilities
– Business requirements it must support
• Usually involves significant interaction with the user to
find DATA, PROCESS, INTERFACE, and
GEOGRAPHY requirements of the system
• Information gathering techniques are applied
• The information gathered is synthesized into a proposed
system requirement model
IST321 Ch3 24
Decision Analysis Phase
• What part of the requirement should be computerized?
• Make or buy decision
• Propose a preferred architecture with supporting
feasibility analysis
– technical
– operational
– econmic
– schedule
– risk
IST321 Ch3 25
Decision Analysis Phase
• Issues to be settled
– What portion of the system should be computerized
– What is the business process interface between the
computerized portion and others
– What is the proposed architecture of the system
• batch, online, realtime
• hardware boundaries
• Geographic boundaries - communication needs
• Centralized or decentralized database
IST321 Ch3 26
Design Phase
• Often considered as the detailed design phase
• Precondition: Approved system architecture and
system’s requirement specification
• Focus is on components to be developed or integrated
• Major activities include
– Detailed database design
– Detailed application program design
– Design of interfaces and dialogs
• Classical methodologies may be used: structured charts,
object-diagrams
• May employ CASE tools
• RAD or rapid application development is now being
preferred for many systems
IST321 Ch3 27
Construction Phase
• Detailed coding
• Unit testing
• Integration and System testing
IST321 Ch3 28
Implementation
• Install at customer premises
• Acceptance testing
• Minor tuning as necessary
Operation and Support
• Technical and user support
• Training
• Maintenance and minor enhancements
IST321 Ch3 29
Model-Driven Development
• A number of models are used during the life cycle phases
– Structured Analysis - a process-oriented technique used to model
a system’s requirements: Data Flow Diagrams
– Structured Design - A design tool used to transform structured
analysis model to structured design models: Structured Charts
– Object-oriented analysis and design (OOAD) - Model is
developed using ‘objects’ and their interaction
• Advantages
– Better planning and documentation of the requirements
– Extensive use of graphical tools - tends to improve
communication with users
– Alternative architectures are relatively easy to generate
• Disadvantages
– Tends to be complex for large projects
IST321 Ch3 30
RAD
• Often uses prototyping approach
• Prototyping technique require that we build a ‘prototype’
of the proposed system using modern tools rapidly
• The prototype itself may become the system, or may
serve as the model for the system
• Activities
– Define the scope
– Define, design, construct the database and UI
– Exercise the system
– Take feed back, modify, and reexercise
– Continue until users are satisfied
– Move on to the next level of scope and repeat process
• Drawbacks? Advantages?
IST321 Ch3 31