Stumpf and Teague Object-Oriented Systems Analysis and Design with UML . © 2005 Prentice Hall

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

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

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

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

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

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

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

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

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

Phases of the Unified Process Inception: Makes the business case Elaboration: Defines the system architecture Construction: Constructs the system 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

Core Disciplines of the Unified Process Business Modeling: Re-envisions and re-engineers the organization Requirements: Defines the user requirements Design: Designs the system Implementation: Writes the software Test: Tests the system © 2005 Prentice Hall

Core Disciplines of the Unified Process (continued) Deployment: Integrates the software into the using organization Configuration and Change Management: Manages the artifacts of the evolving system Project Management: Manages the development process Environment: Supports the development process with processes and tools © 2005 Prentice Hall

Typical Distribution of Resources © 2005 Prentice Hall

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 product by dividing it into these phased builds. © 2005 Prentice Hall

Timeboxing Timeboxing forces a development phase or cycle into a limited period of time (a timebox). © 2005 Prentice Hall

Participants in Systems Analysis and Design Users Analysts Designers Programmers Quality Assurance Specialists © 2005 Prentice Hall

Participants in Systems Analysis and Design © 2005 Prentice Hall

Participants in Systems Analysis and Design (continued) © 2005 Prentice Hall

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

Responsibilities of Users . © 2005 Prentice Hall

Responsibilities of Analysts © 2005 Prentice Hall

Responsibilities of Designers © 2005 Prentice Hall

Responsibilities of Programmers . © 2005 Prentice Hall

Responsibilities of Quality Assurance Staff © 2005 Prentice Hall

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

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

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

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

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

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

Economic Feasibility Analysis (continued) ( 2.18 ) © 2005 Prentice Hall

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