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 Improvised process If process exists, not followed rigorously Routinely exceed budgets and schedules Compromises made to meet deadlines No objective basis for product quality assessment Testing and QA suffer to meet deadlines MATURE Staff know what is expected of them Mandated documented process Method to update process Active broad based organizational involvement Quality is monitored Objective basis for quality of products and process
2

IST321 Ch3

Capability Maturity Model (CMM)

Developed by the Software Engineering Institute Process maturity is specified in 5 levels
Level Level Level Level Level 1 2 3 4 5 Initial Repeatable Defined Managed 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

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; dont 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 I E C E S need to improve performance need to improve information need to improve economics need to improve control or security need to improve efficiency of people and processes 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 projects 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 systems 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 systems 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