session 1 is8060 – information systems development methods & technologies instructor: dr....
TRANSCRIPT
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