INFO415 Evaluating Alternatives

1. INFO415 Evaluating Alternatives

2. Tropic Fish Tales • What is the issue facing Robert Holmes? • Why do you suppose the 6 proposals for a new system are difficult to compare? • What are some of the major differences in the proposals? • What do you think Robert needs to do in order to compare the alternatives?

3. Systems Analysis and Design in a Changing World, 6th Edition The Adaptive SDLC used in this Text • Shows core processes, not phases, plus iterations in a sequence for management checkpoints • Based on the Unified Process SDLC

4. Overview • Even with the adaptive approach, it is always necessary to manage scope, prioritize requirements and to make ‘big picture’ decisions regarding the deployment environment and implementation approach for the new system. • In this section, we: • Describe a simple method for prioritizing functional requirements • Outline a method for controlling scope • Discuss architectural decisions that must be made • Provide a framework for identifying and evaluating implementation alternatives

5. Time Cost Quality Human resources Procurement Communications Risk Project Management Perspective Regardless of the development approach, (predictive or adaptive), the overall goal is to precisely define scope and to specify how system will be implemented. This allows the project manager to quantify and control the following dimensions of the project:

6. Project management triangle • All projects have 3 (maybe 4) constraints • A change one constraint impacts at least one other • A balancing act that PMs need to be good at • Expectation management! Quality means free from defects, but it also relates to level of automation Scope is the number of functions performed by the system – managed through prioritization

7. Deciding on Scope and Level of Automation (Quality) • Scope determines which business functions (events) will be included in system • Level of automation is how much automated computer support exists for functions included in scope • Aim is to precisely define functions in scope and level of automation for each function to avoid scope creep • Requests for addition of system functions after requirements have been defined and decision has been made • To avoid, formalize the process • Get key stakeholders to participate and sign off

8. Finalizing Scope (functions/level of automation) • Finalizing scope in terms of functions and level of automation for each function overlaps with and requires information from: • Defining target deployment environment • Defining implementation alternatives • e.g., build vs. buy • General Approach for including/excluding functions: • Functions deemed mandatory are in scope. • Include as many important functions as budget and schedule allow • Desirable features: delay to later ‘release’ of system

9. Finalizing Scope (functions/level of automation) • Need to revisit feasibility analysis. Now have much more information to work with. • Economic feasibility • What set of functions give us an optimal return on investment? • What set of functions can we afford? • Schedule and resource feasibility • What can be implemented in time available? • What can be implemented given human and other resources? • Technological feasibility • What can be practically implemented given state of technology and organizations knowledge and experience? • Operational, organizational, and cultural feasibility • What can our organization handle/accept? • How much change is required?

10. Prioritizing Requirements • Assume that Event = Function • Use an expanded Event Table • Typically, priority is defined when Event table is built, then refined • Priority: Mandatory, Important, Desirable

11. Prioritization How do you decide if something is mandatory, important or desirable?

12. Prioritization: use specific, tangible criteria

13. Defining Level of Automation • High • System takes over processing of business function … does most of the work …. Applies business logic / rules • Ask the question: how should this function be done ideally • Medium • Midrange point which combines features from low and high alternatives • Low • Simple computer records keeping • Often involves automating existing, manual tasks

14. Exercise – Student Registration • Define potential levels of automation for each function

15. Information Systems Architecture • Information Systems Architecture is the process of making the key choices that are essential to the development of an information system. Architecture includes: • Guiding Principles: • Approaches/philosophies • “Logical” representations of a system • Deployment environment • It is key, when making these choices that they are: • Requirements driven • Take into consideration operational, technical and financial feasibility • Made within an architectural framework

16. Systems Analysis and Design in a Changing World, 6th Edition Where should architectural decisions be made?

17. Corporate Politics Business Plan System Qualities Current Systems Emerging Technologies End User Requirements Architecture Drivers There are many drivers of Architecture Architecture

18. Architecture to Design to Implementation Architecture can be Described as Highest Level Choices Business Strategy Line of Code / Process Step Employee / Computer Removal of Choices Architecture Design Implementation

19. How is Architecture Different from Design? • Its not – Architecture can be considered ‘high-level’ design • Architecture includes those aspects of the design that are essential to the information system • Architecture Example: • Users must be able to self-serve (guiding principle) • “We will use a “hub and spoke” design where data will be placed in a central data warehouse, then be propagated to one or more data marts. (approach) • We will normalize data in the central warehouse and use a dimensional design in the data marts (approach) • We will use Oracle 8i as our DBMS (technical architecture)

20. Architecture vs Design • Not Architecture: • The Order subject area will be composed of the following tables: order_fact, customer_dim, product_dim and time_dim • The customer_dim table will have the following attributes…….

21. The Value of Architecture • Communication: • To business sponsors, and business users • Between members of the project team • Planning: • Cross Check for Project Plan • Ensure that all important components of the system are accounted for • Flexibility and Growth • Thinking about overall architecture will reduce risk associated with the ‘success’ of the system • Learning • Productivity and Reuse

22. Application Deployment Environment • What is the technical environment in which system will be implemented? • Deployment environment consists primarily of: • Hardware • Networks • System software • Development software • Development methodology and tools • Technical requirements define constraints regarding deployment environment • Organization’s current environment/standards typically drive deployment options

23. Choosing Implementation Alternatives • Many variations on obtaining a system • Facilities management solutions • Software as a service • Packaged, turnkey, software systems • Custom software development - consultants • In-house development

24. Implementation Alternatives ASPs Salesforce. com MySAP.com ERP SAP Oracle Off the shelf packages Simply Accounting We build, consultants build or blended approach

25. Comparing Alternatives • Comparisons difficult • Different proposed implementation approaches have strengths in different areas • Need a consistent framework for comparison of alternatives • Criteria • Weights • Scores • Three areas to consider • General requirements • Non-functional requirements • Functional requirements

26. General Requirements • General requirements include considerations that are important but not directly associated with the computer system itself. • Related to feasibility assessment – alternative must be feasible to be chosen • General requirements examples: • Performance record of the provider • Level of technical support from the provider • Warranties and support services (from outside vendor) • Availability of experienced staff • Length of time (schedule) until deployment • Requirements for internal expertise • Organizational impacts (retraining, skill levels) • Cost

27. Non-functional Requirements • Constraints under which system must operate • Defined by technical requirements identified during information gathering • Categories: • Performance (response time/throughput, etc) • Security and Control • User interface (ease of use, etc.) • Service (number/location of users to be supported) • Operating environment • etc.

28. Functional Requirements • Functional requirements • Activities the system must perform • Information the system must maintain • Based on procedures and business functions • Documented in analysis models

29. Evaluation Framework • Organize by the three categories • Within each category, list each individual requirement as simply and clearly as possible • Identify binary criteria – Y/N • Typically cost or ‘showstopper’ functional requirements • A ‘No’ on a binary criteria eliminates an alternative • Assign relative weights to: • Each category • Each requirement in each category • Review potential solutions based on binary criteria first • Do detailed evaluation of alternatives that survive binary criteria

30. Evaluation Framework Relative Weight – importance of criteria vs other criteria Alternatives considered Evaluation Criteria Total 49 Total 42 Score * Weight Score

31. Weighting requirements • After identifying key requirements, the most important exercise is identifying the weights • Most effective approach: use relative weights. • Do this by using percentages • Within each category total weight must = 100% • Forces evaluators to consider the value of each requirement in relation to all others. • Note: also assign relative weights to requirement categories … why?

32. Exercise • Each team: assign weights to each of the following requirements for a student registration system • Assume this is all of the functional requirements • Total weight: 100