61a8cb7168758856ce8139b2e0cfa94e.ppt
- Количество слайдов: 33
Stumpf and Teague Object-Oriented Systems Analysis and Design with UML . © 2005 Prentice Hall 1
Learning Objectives • Describe the overall structure of the Rational Unified Process for information system development. • Name and explain the phases of the Rational Unified Process. • Describe how its nine core disciplines contribute to the Rational Unified Process. • Explain the difference between incremental and iterative system development and discuss why the system development process should be both incremental and iterative. © 2005 Prentice Hall 2
Learning Objectives (continued) • Identify the different types of users of information systems. • Discuss the principal roles and responsibilities of the participants in the system development process. • Appreciate the skills required of successful systems analysts and designers. • Explain the important categories of system feasibility. • Prepare an economic feasibility analysis as part of a business plan. © 2005 Prentice Hall 3
Overview This chapter presents a simplified version of the Rational Unified Process for information system development assuming a new, custom-made system. The Unified Process consists of four phases – Initiation, Elaboration, Construction, and Transition. Each phase comprises several iterations. Each iteration adds capability or refinement to the system. © 2005 Prentice Hall 4
Overview (continued) The development is carried out by specialists in nine core disciplines – Business Modeling, Requirements, Design, Implementation, Test, Deployment, Configuration and Change Management, Project Management, and Environment. The Unified Process, like all generic descriptions of system development, must always be tailored to the circumstances of each specific project. © 2005 Prentice Hall 5
Overview (continued) There are two principal groups of participants in systems analysis – users and analysts. In planning for system development, analysts must take into consideration the different interests of different types of users. © 2005 Prentice Hall 6
Overview (continued) Systems analysts are responsible primarily for understanding, modeling, and communicating the requirements for a new system. Successful systems analysts possess interpersonal and communication skills as well as analytical and technical skills. © 2005 Prentice Hall 7
Overview (continued) System designers are responsible for the technical quality of the system design. They must assure that the system is designed to satisfy all the requirements. Programmers are responsible for construction of the system. © 2005 Prentice Hall 8
Overview (continued) Quality assurance staff monitor the development process and provide measurements and tests which are independent of the development team. The business case for a proposed development project incorporates an analysis of the project’s feasibility – incorporating technical, resource, organizational, schedule, and economic perspectives. © 2005 Prentice Hall 9
The Rational Unified Process for Software Development The Rational Unified Process is organized into four phases, nine core disciplines, and iterations within the phases. © 2005 Prentice Hall 10
Phases of the Unified Process 1. Inception: Makes the business case 2. Elaboration: Defines the system architecture 3. Construction: Constructs the system 4. Transition: Integrates the system with the using environment Each phase terminates in a milestone and results in the delivery of a defined set of work products or artifacts. © 2005 Prentice Hall 11
Core Disciplines of the Unified Process 1. Business Modeling: Re-envisions and reengineers the organization 2. Requirements: Defines the user requirements 3. Design: Designs the system 4. Implementation: Writes the software 5. Test: Tests the system © 2005 Prentice Hall 12
Core Disciplines of the Unified Process (continued) 6. Deployment: Integrates the software into the using organization 7. Configuration and Change Management: Manages the artifacts of the evolving system 8. Project Management: Manages the development process 9. Environment: Supports the development process with processes and tools © 2005 Prentice Hall 13
Typical Distribution of Resources © 2005 Prentice Hall 14
Iterative and Incremental System Development Iterative development allows a part of the system to be reworked. It improves the product by revising any part of the design or implementation that is flawed. Incremental development organizes the process as a series of builds. It improves the process by dividing it into these phased builds. © 2005 Prentice Hall 15
Timeboxing forces a development phase or cycle into a limited period of time (a timebox). © 2005 Prentice Hall 16
Participants in Systems Analysis and Design • • • Users Analysts Designers Programmers Quality Assurance Specialists © 2005 Prentice Hall 17
Participants in Systems Analysis and Design © 2005 Prentice Hall 18
Participants in Systems Analysis and Design (continued) © 2005 Prentice Hall 19
Types of Users • System owner: A high-level manager and decision-maker for the business area supported by the system • Responsible user: A lower-level manager with operational responsibility for the business functions supported by the system • Hands-on user: A person who interacts directly with the system input and output devices • Beneficial user: A person who has no direct contact with the automated system but provides input or receives output © 2005 Prentice Hall 20
Responsibilities of Users. © 2005 Prentice Hall 21
Responsibilities of Analysts © 2005 Prentice Hall 22
Responsibilities of Designers © 2005 Prentice Hall 23
Responsibilities of Programmers . © 2005 Prentice Hall 24
Responsibilities of Quality Assurance Staff © 2005 Prentice Hall 25
System Change Information system change often introduces significant organizational change. Analysts need to understand the interests of each type of user and work with the users to plan for change. The plan should incorporate appropriate incentives for each type of user. © 2005 Prentice Hall 26
System Feasibility The Initiation and Elaboration phases focus on whether a proposed system development project can or should be started and taken to completion. Feasibility analysis makes explicit: • • The constraints on the system – what conditions must be satisfied for the system to be acceptable A feasible system satisfies all the constraints. The criteria for comparative analysis of alternatives © 2005 Prentice Hall 27
System Feasibility `(continued) Analysis of the feasibility of a system addresses these questions: • What benefits is the system expected to provide for its users and major stakeholders? • What specific objectives is the system supposed to achieve? • What are some promising alternatives for an architecture of the new system? • What is it likely to cost to develop the new system? © 2005 Prentice Hall 28
Categories of Feasibility • Technical: Can the proposed system be built? • Resource: Are the required resources available when they are needed? • Organizational: Can the system work in the culture and power structure of the organization? • Economic: Is the system a worthwhile investment? • Schedule or temporal: Can the system be developed and deployed in time to meet the business needs of the organization? © 2005 Prentice Hall 29
Economic Feasibility Analysis Measures of economic feasibility: • Net present value: A measure over time of the costs and benefits of the project. Their future values are discounted to account for the time value of money. • Break-even point: The time at which all the costs of the system will have been recovered. • Return on investment: The ratio of the net present value of the system to the net present value of the costs. © 2005 Prentice Hall 30
Economic Feasibility Analysis (continued) Present Value Formula PV = FV / (1 + i )n where PV is the present value of a cost or benefit for time period n. FV is the future value of a cost or benefit in time period n. i is the interest rate for discounting future costs or benefits. 1 / (1 + i ) n is the discount factor, dependent only on i and n. © 2005 Prentice Hall 31
Economic Feasibility Analysis (continued) ( 2. 18 ) © 2005 Prentice Hall 32
Summary Best practice in system development uses a process which is iterative and incremental, such as the Rational Unified Process. The major participants in the process are: users, systems analysts, system designers, programmers, and quality assurance specialists. © 2005 Prentice Hall 33
61a8cb7168758856ce8139b2e0cfa94e.ppt