Information System for Managers

SDLC Details

Content

Requirements Analysis Design Development Implementation Operations & Maintenance Review

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 required Getting 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

Pitfalls in Defining Needs

Inherently Fuzzy Needs Identifying solutions before needs defined fully Addressing needs of wrong customers Multiple customer - Multiple needs Sol: 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

Pitfalls in Defining Needs Inherently 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 dont As the deliverable develops and takes on a tangible form, customers see new possibilities and try to change the project accordingly Customer must be taken seriously a project fails if the deliverable is not used, underused, or misused by the customer Sol: Work closely with customer, involve customer in need articulation, educate, proto-type / other model, Awareness, Flexible Project Plan, Anticipated needs,

Scope Verification and Scope Change

Scope Verification: Verifying actual product component vs. scope baseline Scope Change: Controlling changes to project scope. Change control process, configuration management, version control

Questions
Who carries out the activities? What is carried out? How is it carried out? What is the output? What tools are used?

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)

Table of Contents - BRS

1 Introduction 1.1 Purpose of Document 1.2 Audience 1.3 Document Organization 1.4 References

Table of Contents - BRS

2 Overview 2.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

Table of Contents - BRS

3 Business Requirements 3.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

Table of Contents - BRS

4 Technical Requirements 4.1 Usability 4.2 Reliability 4.3 Performance 4.4 Security / Privacy 4.5 Portability / Migration 4.6 Supportability 5 External Interfaces

Table of Contents - BRS

Appendix A: Assumptions and Dependencies Appendix B: Glossary Appendix C: Business Rules Appendix D: UI Screens Appendix E: Requirements Summary

STRUCTURED AND OBJECT ORIENTED MODELS

Events and Event table

Things

Class diagram

Object-oriented approach
Interaction Use case diagrams

Entityrelationship diagram

Traditional approach
Diagram 0

Context diagram

Statechart diagrams

Other OO models

DFD fragments

Other definitions

Analysis Design
Package diagram Object database scheme Design class diagram System flow chart Structure chart

Hybrid relational database scheme User-interface dialog, forms, and reports System controls Pseudocode Nodes and locations diagram

Relational database scheme

Systems Analysis
Detailing Requirements SSAD

ERD DFD Input / output details

OO Analysis

15

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 the system to define events for which the system must have a 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.

Step 1: Context Diagram

Personnel Employee Payroll System Detail Dept Tax Rate

Salary Slip F16

Salary Summary

Employee

Tax Slab

Finance Dept

Step 2: Functional Decomposition

Payroll System Maintain Employee Master

Process Payroll
Calculate Salary

Calculate Tax
Print Salary Slip

Add Employee

Update Employee

Delete Employee

Step 3 Event List

Actor Personnel Trigger Event / Use Case Response Employee record created in Employee Master Salary calculated, salary slip printed

New Employee Create fill joining form Employee 1st of Month Calculate Salary

(Time)

Finance
(Time)

Ask for summary

1st of Year

Generate Summary
Calculate Tax

Salary Summary generated for a period

Tax calculated, F16 printed

Step 4 Draw event diagram for each event

Event: 1st of Month

Employee Master

Calculate Salary 1st of Month Print Salary Slip

Employee Salary Slip

Salary File

Step 5 DFD Level 1

Personnel

Employee Detail Calculate Tax

Maintain Employee Master F16 Salary Slip

Employee Master Emp

Tax Slab

1st of year

1st of Process Month Payroll

Finance
Salary Summary

Salary File

Process Generate Payroll Summary

Step 6 DFD Level 2 for Maintain Employee Master

Personnel

Add Employee

New Emp Record Changed Detail

Employee Master

Update Employee Delete Employee

Systems Design
Answers the question: how will the information system 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

23

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 Chart Decision Table

Interface Design and Controls

Table 13.1: The Elements of Good Interactive Dialogue

25

Design of System Security and Controls

Preventing, detecting, and correcting errors

Enterprise-rights management software Disaster planning: process of anticipating and providing for disasters Disaster recovery: implementation of disaster plan Approaches Hot site Cold site Incremental backup Image log
26

Disaster planning and recovery

The Design Report

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

27

Implementation
Context

In-House Development

Acquisition

Implementation

Operations & Maintenance

Systems Implementation

Figure 13.10: Typical Steps in Systems Implementation

29

Acquiring Hardware from an IS Vendor

Buying Purchasing used computer equipment Leasing Renting Application service provider (ASP)

30

Acquiring Software: Make or Buy?

Make-or-buy decision: decision regarding whether to obtain software from external or internal sources

31

Acquiring Software: Make or Buy? (continued)

Table 13.5: Comparison of Off the Shelf and Developed Software

32

User Preparation
Readying managers, decision makers, employees, other users, and stakeholders for new systems Training users

33

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

34

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 used with new computer software and systems INSTLLATION Process of physically placing computer equipment on the site and making it operational
35

Testing
Unit testing: testing of individual programs Interface testing: System: testing all related systems together Acceptance testing: conducting any tests required by user Alpha testing: testing an incomplete or early version of system Beta testing: testing a complete and stable system by end users
36

Start-Up
Process of making the final tested information system fully operational Approaches

Direct conversion (plunge, direct cutover) Phase-in approach (piecemeal) Module-wise Functionality-wise Customer Segment-wise Parallel start-up

37

Start-Up (continued)

Figure 13.13: Start-Up Approaches

38

Start-Up (continued)

Figure 13.13: Start-Up Approaches (continued)

39

User Acceptance
User acceptance document: formal agreement signed by user that states that a phase of installation or the complete system is approved

Legal document that removes or reduces IS vendors liability

40

Maintenance Context

Implementation
Maintenance Review Objective Satisfied? Develop & Implement New System Retire This System

Systems Operation and Maintenance

Systems operation: use of a new or modified system

Help desk provides support

Systems maintenance: checking, changing, and enhancing the system to make it more useful in achieving user and organizational goals

42

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

Reasons for Maintenance

Changes in business processes New 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
44

Types of Maintenance
Slipstream upgrade: minor upgrade Patch: fix a problem or make small enhancement Release: significant program change requiring new documentation Version: major program change with new features

45

Change Control Procedure

Change Request Form Review

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-in Implement Changes

46

The Financial Implications of Maintenance

Total maintenance expenditures increase in time and 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 a system

Costs more to fix than replace system

47

The Financial Implications of Maintenance (continued)

Figure 13.14: Maintenance Costs as a Function of Age

48

The Relationship Between Maintenance and Design

More time and money spent on design means less time and money spent on maintenance

Figure 13.15: The Value of Investment in Design

49

Systems Review
Analysis of systems to make sure that they are operating as intended Often compares performance and benefits of designed system with actual performance and benefits of operational system

50

Types of Review Procedures

Table 13.6: Examples of Review Types

51