SDLC Details

7/31/2019 SDLC Details

1/51

Information System for Managers

SDLC Details


2/51

Content

Requirements

Analysis

Design

Development

Implementation

Operations & Maintenance

Review


3/51

Requirements

Handles What Part Requirements define what the deliverable will look

like and what it will do

Implied needs vs. Stated Needs (Requirements)

Objective: Project includes all the work required and

only the work requiredGetting clear requirements, is most critical and is key

to success / main reason to failure of the project

Requirements from all stakeholders

Functional

Technical

Cost

Quality


4/51

Pitfalls in Defining Needs

Inherently Fuzzy Needs

Identifying solutions before needs defined fully

Addressing needs of wrong customers

Multiple customer - Multiple needsSol: Establish priorities and need hierarchy. Finalize

priority with customer

Distorting Customer Needs

Gold-Plating of needs

Selective Filtering of customer needs

Father-knows-best approach


5/51

Pitfalls in Defining NeedsInherently Fuzzy Needs

Needs are dynamic (Changing players, budget,technology, business environment)

Customer not understanding / articulating

Customers know what they need, after they see it

Even if customer say they know exactly what they

need, they probably dontAs the deliverable develops and takes on a tangible

form, customers see new possibilities and try tochange the project accordingly

Customer must be taken seriously a project fails if

the deliverable is not used, underused, or misused bythe customer

Sol: Work closely with customer, involve customer inneed articulation, educate, proto-type / other model,

Awareness, Flexible Project Plan, Anticipated needs,


6/51

Scope Verification and ScopeChange

Scope Verification: Verifying actual product componentvs. scope baseline

Scope Change: Controlling changes to project scope.

Change control process, configuration management,version control


7/51

Questions

Who carries out the activities?What is carried out?

How is it carried out?

What is the output?What tools are used?


8/51

Requirements

Requirements and Test Plan: Verifiable Requirements Requirements Management

Requirements: Static and Evolving, Project Vs Product,

etc.

BRS (Business Requirements Specification), FS(Functional Specification) and SRS (System

Requirements Specification)


9/51

Table of Contents - BRS

1 Introduction1.1 Purpose of Document

1.2 Audience

1.3 Document Organization1.4 References


10/51


2 Overview2.1 Business Description

2.2 Stakeholders Requests

2.2.1 Establish Stakeholder Profile

2.2.2 Establish User or Customer Profile

2.2.3 Assessing the Problem

2.2.4 Understanding the User Environment

2.3 Process Schematic


11/51


3 Business Requirements3.1 Functional Requirement One

3.1.1 Description

3.1.2 Rationale

3.1.3 Source

3.1.4 Dependencies / Conflicts / Assumptions

3.1.5 Priority

3.1.6 Verification

3.1.7 Use Cases

3.2 Other Implicit Functionality


12/51


4 Technical Requirements4.1 Usability

4.2 Reliability

4.3 Performance

4.4 Security / Privacy4.5 Portability / Migration

4.6 Supportability

5 External Interfaces


13/51


Appendix A: Assumptions and DependenciesAppendix B: Glossary

Appendix C: Business Rules

Appendix D: UI Screens

Appendix E: Requirements Summary


14/51

STRUCTURED AND OBJECT ORIENTED MODELS

Events andEvent table

Things

Class diagramEntity-

relationshipdiagram

Interaction

Statechartdiagrams

Other OOmodels

Use casediagrams

Contextdiagram

DFD fragmentsOther

definitions

Diagram 0

Object-orientedapproach

Traditionalapproach

Nodes and locations diagram

Pseudocode

System controls

User-interface dialog, forms, and reports

Hybrid relational database scheme

Analysis

Design

System flowchart

Structure chart

Relationaldatabasescheme

Packagediagram

Designclass

diagram

Objectdatabasescheme


15/51

15

Systems Analysis

Detailing RequirementsSSAD

ERD

DFD

Input / output details

OO Analysis


16/51

Modern Structured Analysis

1. Draw a context DFD to establish initial project scope.2. Draw a functional decomposition diagram to partition

the system into subsystems.

3. Create an event-response or use-case list for thesystem to define events for which the system must havea response.

4. Draw an event DFD (or event handler) for each event

5. Merge event DFDs into a system diagram

6. Draw detailed, primitive DFDs for the more complex

event handlers.7. Document data flows and processes in the data

dictionary.


17/51

Step 1: Context Diagram

Payroll SystemPersonnelDept

EmployeeDetail

EmployeeSalarySlip

F16

FinanceDept

SalarySummary

Tax Slab

TaxRate


18/51

Step 2: Functional Decomposition

Payroll System

MaintainEmployee Master Process Payroll Calculate Tax

AddEmployee

UpdateEmployee

DeleteEmployee

Calculate Salary

Print

Salary Slip


19/51

Step 3 Event List

Actor Trigger Event /

Use Case

Response

Personnel New Employee

fill joining form

Create

Employee

Employee record

created in Employee

Master

(Time) 1st of Month Calculate

Salary

Salary calculated,

salary slip printed

Finance Ask for

summary

Generate

Summary

Salary Summary

generated for a period

(Time) 1st of Year Calculate

Tax

Tax calculated, F16

printed

St 4 D t di f


20/51

Step 4 Draw event diagram foreach event

Event: 1st of Month

EmployeeMaster

Salary File

CalculateSalary

1st of Month

Print SalarySlip

Salary

Slip

Employee


21/51

Step 5 DFD Level 1

Personnel

MaintainEmployee

Master

Employee

Master

Employee

Detail

Tax SlabCalculate Tax

Salary File

1st of year

F16 Emp

ProcessPayroll

1st

ofMonth SalarySlip

ProcessPayrollGenerateSummary

Finance

SalarySummary

Step 6 DFD Le el 2 for Maintain


22/51

Step 6 DFD Level 2 for MaintainEmployee Master

PersonnelAdd

Employee

Employee

Master

New EmpRecord

Update

Employee

DeleteEmployee

ChangedDetail


23/51

23

Systems Design

Answers the question: how will the informationsystem solve a problem?

Results in a technical design

Details system outputs, inputs, and user interfaces

Specifies hardware, software, databases,

telecommunications, personnel, and procedures

Shows how these components are related


24/51

System Design

High Level Design Application Design(cont) Common Functionality

Functional Decomposition

System Flow

System Chart

File / Table Design

User Interface Design Detailed Design- Program Specification

Pseudo code Flow ChartDecision Table


25/51

25

Interface Design and Controls

Table 13.1: The Elements of Good Interactive Dialogue

Design of System Security and


26/51

26

Design of System Security and

Controls

Preventing, detecting, and correcting errors Enterprise-rights management software

Disaster planning and recovery Disaster planning:process of anticipating and

providing for disasters Disaster recovery: implementation of disaster plan

Approaches

Hot site

Cold site Incremental backup

Image log


27/51

27

The Design Report

Figure 13.9: A Typical Table of Contents for a Systems Design Report

Implementation


28/51

ImplementationContext

Implementation

Operations &Maintenance

In-HouseDevelopment

Acquisition


29/51

29

Systems Implementation

Figure 13.10: Typical Steps in Systems Implementation

Acquiring Hardware from an IS


30/51

30

Acquiring Hardware from an IS

Vendor

BuyingPurchasing used computer equipment

Leasing

RentingApplication service provider (ASP)


31/51

31

Acquiring Software: Make or Buy?

Make-or-buy decision: decision regardingwhether to obtain software from external or

internal sources



32/51

32


(continued)

Table 13.5: Comparison of Off the Shelf and Developed Software


33/51

33

User Preparation

Readying managers, decision makers,employees, other users, and stakeholders for

new systems

Training users


34/51

34

IS Personnel: Hiring and Training

Personnel that might be needed for new system IS manager

Systems analysts

Computer programmers

Data-entry operators

Training programs should be conducted for IS

personnel who will be using the system


35/51

35

Site, Data Preparation & Installation

SITE PREPARATION Preparation of the location of a new system. May involve

Making room for a computer in an office

Special wiring and air conditioning

Renovation of entire room Special floor

Additional power circuits

DATA PREPARATION (Data Entry & Conversion)

Ensuring all files and databases are ready to be usedwith new computer software and systems

INSTLLATION

Process of physically placing computer equipment on thesite and making it operational


36/51

36

Testing

Unit testing: testing of individual programsInterface testing:

System: testing all related systems together

Acceptance testing: conducting any testsrequired by user

Alpha testing: testing an incomplete or earlyversion of system

Beta testing: testing a complete and stablesystem by end users


37/51

37

Start-Up

Process of making the final tested informationsystem fully operational

Approaches

Direct conversion (plunge, direct cutover)

Phase-in approach (piecemeal)

Module-wise

Functionality-wise

Customer Segment-wise Parallel start-up


38/51

38

Start-Up (continued)

Figure 13.13: Start-Up Approaches


39/51

39

Start-Up (continued)

Figure 13.13: Start-Up Approaches (continued)


40/51

40

User Acceptance

User acceptance document: formal agreementsigned by user that states that a phase of

installation or the complete system is approved

Legal document that removes or reduces IS vendors

liability

Maintenance


41/51

MaintenanceContext

Maintenance

Implementation

ObjectiveSatisfied?

Review

Y N

Develop &ImplementNew System

RetireThisSystem

Systems Operation and


42/51

42

Systems Operation and

Maintenance

Systems operation: use of a new or modifiedsystem

Help desk provides support

Systems maintenance: checking, changing,and enhancing the system to make it more

useful in achieving user and organizational goals

S t M i t (C t)


43/51

System Maintenance (Cont)

Maintenance Manage Changes - Requires high discipline (Strict

SCM including Change Control, Testing) Involves error correction & enhancements

Longest Phase (Hopefully!)

All Benefits in this phase Major cost in this phase Stable & Profitable business for third party Most time critical and demanding

Hated by many developers

R f M i t


44/51

44

Reasons for Maintenance

Changes in business processesNew requests from stakeholders, users, and

managers

Bugs or errors in program

Corporate mergers and acquisitions

Government regulations

Change in operating system or hardware on

which the application runs

Unexpected events

T f M i t


45/51

45

Types of Maintenance

Slipstream upgrade: minor upgrade

Patch: fix a problem or make small

enhancement

Release: significant program change requiringnew documentation

Version: major program change with new

features

Ch C t l P d


46/51

46

Change Control Procedure

Change Request FormReview

Identifies programs to be changed

Determines programmer to be assigned to task

Estimates expected completion date

Develops a technical description of change

Approval

Check-out, Do changes, Testing, Check-inImplement Changes

The Financial Implications of


47/51

47


Maintenance

Total maintenance expenditures increase in timeand money as programs age

For older programs, total cost of maintenance can be

up to five times greater than total cost of development

Determining factor in decision to replace asystem

Costs more to fix than replace system



48/51

48

e a c a p cat o s oMaintenance (continued)

Figure 13.14: Maintenance Costs as a Function of Age

The Relationship Between


49/51

49

pMaintenance and Design

Figure 13.15: The Value of Investment in Design

More time and money spent on design means less

time and money spent on maintenance

S stems Re ie


50/51

50

Systems Review

Analysis of systems to make sure that they areoperating as intended

Often compares performance and benefits of

designed system with actual performance and

benefits of operational system

Types of Review Procedures


51/51

Types of Review Procedures

Table 13.6: Examples of Review Types

Documents

SDLC Details