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

2. © 2005 Prentice Hall2-2 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.

3. © 2005 Prentice Hall2-3 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.

4. © 2005 Prentice Hall2-4 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. Overview

5. © 2005 Prentice Hall2-5 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.

6. © 2005 Prentice Hall2-6 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.

7. © 2005 Prentice Hall2-7 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.

8. © 2005 Prentice Hall2-8 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.

9. © 2005 Prentice Hall2-9 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.

10. © 2005 Prentice Hall2-10 The Rational Unified Process for Software Development The Rational Unified Process is organized into four phases, nine core disciplines, and iterations within the phases.

11. © 2005 Prentice Hall2-11 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.

12. © 2005 Prentice Hall2-12 Core Disciplines of the Unified Process 1.Business Modeling: Re-envisions and re-engineers the organization 2.Requirements: Defines the user requirements 3.Design: Designs the system 4.Implementation: Writes the software 5.Test: Tests the system

13. © 2005 Prentice Hall2-13 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

14. © 2005 Prentice Hall2-14 Typical Distribution of Resources

15. © 2005 Prentice Hall2-15 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.

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

17. © 2005 Prentice Hall2-17 Participants in Systems Analysis and Design Users Analysts Designers Programmers Quality Assurance Specialists

18. © 2005 Prentice Hall2-18 Participants in Systems Analysis and Design

19. © 2005 Prentice Hall2-19 Participants in Systems Analysis and Design (continued)

20. © 2005 Prentice Hall2-20 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

21. © 2005 Prentice Hall2-21 Responsibilities of Users.

22. © 2005 Prentice Hall2-22 Responsibilities of Analysts

23. © 2005 Prentice Hall2-23 Responsibilities of Designers

24. © 2005 Prentice Hall2-24 Responsibilities of Programmers.

25. © 2005 Prentice Hall2-25 Responsibilities of Quality Assurance Staff

26. © 2005 Prentice Hall2-26 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.

27. © 2005 Prentice Hall2-27 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

28. © 2005 Prentice Hall2-28 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?

29. © 2005 Prentice Hall2-29 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?

30. © 2005 Prentice Hall2-30 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.

31. © 2005 Prentice Hall2-31 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.

32. © 2005 Prentice Hall2-32 Economic Feasibility Analysis (continued) ( 2.18 )

33. © 2005 Prentice Hall2-33 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.