Session 1

IS8060 – Information Systems Development Methods & Technologies

Instructor: Dr. Solomon Negash

Current Rate of Successful Projects

Study of 280,000 projects completed in 2000• Only about 1

in 4 was a success

Legal Implications of the Current Situation

2002 survey of information technology organizations• 78% have been involved in disputes that ended in

litigation

For the organizations that entered into litigation:• In 67% of the disputes, the functionality of the

information system as delivered did not meet not up to the claims of the developers

• In 56% of the disputes, the promised delivery date slipped several times

• In 45% of the disputes, the defects were so severe that the information system was unusable

What are systems?

A surgeon, a civil engineer and a software engineer were chatting at a bar. The discussion rolled around to whose profession was the oldest. The surgeon said that surgery was, since in the book of Genesis, God created Eve from one of Adam's ribs, and surely that involved surgery. The civil engineer countered by saying that before God created people, God created the heavens and the Earth from chaos, surely a feat of civil engineering. The software engineer just smiled and said “_________________________________?”• “Where do you think the chaos came from?” • Downloaded from

http://www.cis.gsu.edu/~shong/oojokes/ Jan 7, 2003

System Analysis and Design (Definition)

• The study of a ___________ prior to taking some __________ (DeMarco, 1978)

• The ___________ of establishing the services that the _________requires from a system and the ___________under which it operates and is developed (Summerville, 1995)

• A __________used to develop computer-based ______________________ (Hoffer, George, & Valachich, 1999)

What is a process?

• A step by step description of an activity.

• A process is often augmented with documentation about each step.

• How would you describe the process of making lunch?

A “Simple” Process for Making Lunch

1. Vision—Develop a Vision

2. Plan—Manage to the Plan

3. Risks—Mitigate Risks and Track Related Issues

4. Business Case—Examine the Business Case

5. Architecture—Design a Component Architecture

RUP – The Essentials

6. Prototype—Incrementally Build and Test the Product

7. Evaluation—Regularly Assess Results

8. Change Requests—Manage and Control Changes

9. User Support—Deploy a Usable Product

10. Process—Adopt a Process that Fits Your Project

RUP – The Essentials (continued)

In RUP, the Vision artifact captures very high-level requirements and design constraints, to give the reader an understanding of the system to be developed. It provides input to the project-approval process, and is therefore intimately related to the Business Case. It communicates the fundamental "why's and what's" related to the project and is a gauge against which all future decisions should be validated.

1. The Vision Artifact

Should answer the following questions: What are the key terms? (Glossary) What problem are we trying to solve? (Problem

Statement) Who are the stakeholders? Who are the

users? What are their needs? What are the product features? What are the functional requirements? (Use

Cases) What are the non-functional requirements? What are the design constraints?

The contents of the Vision

The essence of Project Management:• conceiving a new project;

• evaluating scope and risk;

• monitoring and controlling the project;

• planning for and evaluating each iteration and phase

Project Management: • Overview

2. Plan—Manage to the Plan

Project Management: Overview

It is essential to identify and attack the highest

risk items early in the project and track them, along with other related issues. The Risk List is intended to capture the perceived risks to the success of the project. It identifies, in decreasing order of priority, the events which could lead to a significant negative outcome.

Along with each risk, should be a plan for mitigating that risk. This serves as a focal point for planning project activities, and is the basis around which iterations are organized.

3. Risks—Mitigate Risks and Track Related Issues

Risk Magnitude: Most Damaging Description

• Areas of risk include the inability to deliver a solution that meets capacity requirements or to issue a page to a paging device. While the technology to provide such capability exists, the ability to send as many as 500,000 pages within 5 minutes will need to be proven.

Impacts • System not functional, probably resulting in loss of subscribers.

Indicators • Failed or delayed delivery of messages within established time frame of

5 minutes. Mitigation Strategy

• Context has provided similar pager capability for other projects, therefore this area of technical risk is relatively low. Context Integration must provide an estimate of time required to process and push information to subscribers based on average and maximum projected workloads, which are currently 200,000 to 500,000 subscribers. Context Integration will develop a scalable system. will provide hardware resources necessary to meet processing requirements. Context can not guarantee the ability of each paging gateway service to deliver service levels within the desired specifications.

Technical Risk : Capacity and Capability

The Business Case provides the necessary information, from a business standpoint, to determine whether or not this project is worth investing in.

The main purpose of the Business Case is to develop an economic plan for realizing the project Vision. Once developed, the Business Case is used to make an accurate assessment of the return on investment (ROI) provided by the project. It provides the justification for the project and establishes its economic constraints. It provides information to the economic decision makers on the project's worth, and is used to determine whether the project should move ahead.

The description should not delve deeply into the specifics of the problem, but rather it should create a compelling argument why the product is needed. It must be brief, however, so that it is easy enough for all project team members to understand and remember. At critical milestones, the Business Case is re-examined to see if estimates of expected return and cost are still accurate, and whether the project should be continued

4. Business Case—Examine the Business Case

1.  Introduction. [The introduction of the Business Case should provide an overview of the entire document. It should include the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Business Case.]

2.   Product Description. [To give a context to the reader, briefly describe the product that is to be developed. Include the name of the system and possibly an acronym, if one is used. Explain what problem it solves and why the development will be worth the effort. Refer to the Vision document.]

3.    Business Context. [Define the business context for the product. In which domain is it going to function (for example, telecom or bank) and what market—who are the users? State whether the product is being developed to fulfill a contract or if it is a commercial product. If it is a continuation of an existing project, this should also be mentioned.]

4.    Product Objectives. [State the objectives for developing the product— the reasons why this is worthwhile. This includes a tentative schedule, and some assessment of schedule risks. Clearly defined and expressed objectives provide good grounds for formulating milestones and managing risks; that is, keeping the project on track and ensuring its success.]

5.    Financial Forecast. [An example of a possible cost-benefit analysis table is shown below.]Financial Forecast - <n> years Value TotalsBenefits  [revenue enhancement] $  [expense reduction] $  [intangibles (good will, visibility)] $ $   Costs  [capital] $  [expense] $ $   ROI (benefits/costs)  % 

6.   Constraints. [Express the constraints under which the project is undertaken. These constraints impact risk and cost. They could be things like external interfaces that the system must adhere to, standards, certifications or a technical approach employed for strategic reasons, such as using a certain database technology or distribution mechanisms.]

Business Case Template – RUP

5. Architecture—Design a Component Architecture In the Rational Unified Process (RUP), the architecture

of a software system (at a given point) is the organization or structure of the system's significant components interacting through interfaces, with components composed of successively smaller components and interfaces. • What are the main pieces? • And how do they fit together?  • Do we have a framework on which the rest of the software

can be added?

6. Prototype—Incrementally Build and Test the Product

The RUP is an iterative approach of building, testing, and evaluating executable versions of the product in order to flush out the problems and resolve risks and issues as early as possible.

7. Evaluation—Regularly Assess Results Regular status assessments provide a mechanism for

addressing, communicating, and resolving management issues, technical issues, and project risks. In addition to identifying the issues, each should be assigned a due date, with a responsible person who is accountable for the resolution. This should be regularly tracked and updated as necessary.

8. Change Requests—Manage and Control Changes

Change Requests are used to document and track defects, enhancement requests and any other type of request for a change to the product. The benefit of Change Requests is that they provide a record of decisions, and, due to their assessment process, ensure that impacts of the potential change are understood by all project team members. The Change Requests are essential for managing the scope of the project, as well as assessing the impact of proposed changes.

9. User Support—Deploy a Usable Product The purpose of a process is to produce a usable product. 

All aspects of the process should be tailored with this goal in mind.  The product is typically more than just the software.  At a minimum, there should be a User’s Guide, perhaps implemented through online help.  You may also include an Installation Guide and Release Notes. Depending on the complexity of the product, training materials may also be needed, as well as a bill of materials along with any product packaging.

10. Process—Adopt a Process that Fits Your Project

It is essential that a process be chosen which fits the type of product you are developing. Even after a process is chosen, it must not be followed blindly — common sense and experience must be applied to configure the process and tools to meet the needs of the organization and the project.

Start

System Request

Problem Statement

Business Case Scenario

Feasibility Analysis Technical Feasibility Organizational Feasibility Economic Feasibility

Requirement Analysis

Process Flow Diagram

Use-case Diagram

Use-case Description

Business Architecture

Technical Architecture

Persistent Format

Sequence Diagram

State DiagramCRC Diagram

Class Diagram

Object Diagram Timing Diagram

User Interface Structure

Navigation Layout

Input/Output Design

Prototype

User Training

Documentation

End

Initiation

Analysis--Functional

Analysis—Structural Analysis–Behavioral

DesignImplementation

Process used in class:

Mapping project to RUP

RUP Process in Class

Vision Problem Statement/System Request

Plan Project Management/Scope

Risk Technical Feasibility

Management Issues dB

Business Case Business Case Scenario

Architecture Business/Tech Architecture

Prototype Prototype

Evaluation Management Issues dB

Change Requirements --open--

User Support --open--

Process Process