1. Project Risks and Feasibility Assessment Advanced Systems Analysis and Design

2. Project Risk Factors

3. Project Risk Classification

4.  Feasibility is the measure of how beneficial or practical the development of an information system will be to an organization.  Feasibility analysis is the process by which feasibility is measured.  Feasibility should be measured throughout the life cycle.  The scope and complexity of an apparently feasible project can change after the initial problems and opportunities are fully analyzed or after the system has been designed.  Thus, a project that is feasible at one point in time may become infeasible at a later point in time.

5. Feasibility Assessment  Why feasibility assessment?  Information systems are major investments  IS projects are subject to the same cost justifications as any other capital investments  Business value paradox  Avoid "black hole" projects

7. Feasibility Analysis  Feasibility Checkpoints During Analysis  Systems Analysis -Survey Phase  ``Do the problems (or opportunities) warrant the cost of a detailed study of the current system?''  Systems Analysis - Study/Definition Phase  Better estimates of development costs and the benefits to be obtained from a new system.  Requirements often prove to be more extensive that originally stated.  If feasibility is in question, scope, schedule, and costs must be rejustified.  Systems Analysis - Selection Phase  A major feasibility analysis evaluating options for the target systems design.  Typical options that are evaluated include Do nothing! Leave the current system alone. Reengineer the (manual) business processes, not the computer-based processes. Enhance existing computer processes. Purchase a packaged application.

8. Four Tests for Feasibility  Operational feasibility is a measure of how well a specific solution will work in the organization. It is also a measure of how people feel about the system/project.  Does management support the system?  How do the end-users feel about their role in the new system?  What end-users or managers may resist or not use the system? Can this problem be overcome? If so, how?  Usability analysis Ease of use, Ease of learning, User satisfaction  Technical feasibility is a measure of the practicality of a specific technical solution and the availability of technical resources and expertise.  Is the proposed technology or solution practical? Is the technology mature?  Do we currently possess the necessary technology?  Do we possess the necessary technical expertise, and is the schedule reasonable?  Schedule feasibility is a measure of how reasonable the project timetable is.  Economic feasibility is a measure of the cost-effectiveness of a project or solution. This is often called a cost-benefit analysis.

12.  Developed by Barry Boehm (1981)  Predicts the effort & duration of a project  Based on size of the system & a number of “cost drivers,” Constructive Cost Model (COCOMO)

13. WM = Work-Months; TDEV = Time of Development KDSI = Thousands of delivered source instruction TDEV= 2.5(MM) 0.32 WM= 3.6(KDSI) 1.20 Very Large Size, Contractor developed Embedded TDEV= 2.5(MM) 0.35 WM= 3.0(KDSI) 1.12 Intermediate-Large Size, Partial In-house & contracted Semidetached TDEV= 2.5(MM) 0.38 WM= 2.4(KDSI) 1.05 Small-Medium Size, In-house Dev. Organic ScheduleEffortDescriptionMode CoCoMo Basic Equations

14. Cost Drivers in COCOMO  Product attributes  software reliability, database size, software complexity  Hardware/platform attributes  execution time constraints, main storage constraints, virtual machine volatility, turnaround time  Personnel attributes  Analyst capability, applications experience, programmer capability, virtual machine experience, language experience  Project attributes  use of modern programming practices, use of software tools, development schedule constriants

15. Factors not Included in COCOMO  Application type  Language level  Requirements volatility  Personnel continuity  Management quality  Customer interface quality  Amount of documentation  Hardware configuration  Security and privacy restrictions

16. Function Point Analysis  Developed by Allan Albrecht at IBM (1979)  Based on estimation of inputs, outputs, queries, interfaces, and files  Main advantages  Possible to estimate function points early in the development life cycle  Can be estimated by non-technical personnel

17. Function Point Analysis FC = Count * Weight 643Applications Interfaces 1075Files 15107Inquires 754Output (eg, reports, screens) 643Input ComplexAverageSimple Basic Equation: FP = FC (PCA) PCA = 0.65 + (0.01) Σc i PCA – Processing Complexity Adjustment; C – Complexity Factors

18. Feasibility Analysis of Candidate Systems  Candidate Systems Matrix  The candidate systems matrix documents similarities and differences between candidate systems; however, it offers no analysis.  The columns of the matrix represent candidate solutions.  The rows of the matrix represent characteristics that serve to differentiate the candidates. The breakdown is as follows:  TECHNOLOGY  INTERFACES  DATA  PROCESSES  GEOGRAPHY

21. Feasibility Analysis of Candidate Systems  Feasibility Analysis Matrix  This matrix complements the candidate systems matrix with an analysis and ranking of the candidate systems. It is called a feasibility analysis matrix.  The columns of the matrix correspond to the same candidate solutions as shown in the candidate systems matrix.  Some rows correspond to the feasibility criteria presented in this chapter.  Rows are added to describe the general solution and a ranking of the candidates.  The cells contain the feasibility assessment notes for each candidate.

22. Feasibility Analysis of Candidate Systems  Feasibility Analysis Matrix  Each row can be assigned a rank or score for each criteria (e.g., for operational feasibility, candidates can be ranked 1, 2, 3, etc.).  After ranking or scoring all candidates on each criteria, a final ranking or score is recorded in the last row.