1 / 22

Session 1

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.

mahina
Télécharger la présentation

Session 1

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Session 1 IS8060 – Information Systems Development Methods & Technologies Instructor: Dr. Solomon Negash

  2. Current Rate of Successful Projects • Study of 280,000 projects completed in 2000 • Only about 1 in 4 was a success

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

  4. 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

  5. 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)

  6. 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?

  7. A “Simple” Process for Making Lunch

  8. RUP – The Essentials • Vision—Develop a Vision • Plan—Manage to the Plan • Risks—Mitigate Risks and Track Related Issues • Business Case—Examine the Business Case • Architecture—Design a Component Architecture

  9. RUP – The Essentials (continued) • Prototype—Incrementally Build and Test the Product • Evaluation—Regularly Assess Results • Change Requests—Manage and Control Changes • User Support—Deploy a Usable Product • Process—Adopt a Process that Fits Your Project

  10. 1. The Vision Artifact 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.

  11. The contents of the Vision 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?

  12. 2. Plan—Manage to the Plan • 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

  13. Project Management: Overview

  14. 3. Risks—Mitigate Risks and Track Related Issues • 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.

  15. Technical Risk : Capacity and Capability • 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.

  16. 4. Business Case—Examine the Business Case • 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

  17. Business Case Template – RUP 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 Totals Benefits   [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.]

  18. 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.

  19. 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.

  20. 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.

  21. Process used in class:

  22. Mapping project to RUP

More Related