1 / 64

Feasibility Analysis for a Software Project

Feasibility Analysis for a Software Project. Feasibility Analysis. “ A measure of how beneficial or practical the development of a software system will be to an organization. This analysis recurs throughout the life cycle. ”. Planning. Planned Project. Existing System. Support. Analysis.

karleigh-stein
Download Presentation

Feasibility Analysis for a Software Project

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Feasibility Analysis for a Software Project

  2. Feasibility Analysis “A measure of how beneficial or practical the development of a software system will be to an organization. This analysis recurs throughout the life cycle.”

  3. Planning Planned Project Existing System Support Analysis Production System Business Requirements Implementation Design Technical Design Feasibility Checkpoints “creeping commitment approach”

  4. Planning Planned Project Existing System Support Analysis Production System Business Requirements Implementation Design Technical Design Feasibility Checkpoints • systems analysis -- study • urgency? rough cost estimate • systems analysis -- definition • clearer scope, refined cost estimate • systems design -- selection • adjust scope, schedule, costs • systems design -- procurement • option check before letting contracts • systems design -- detail design • one last chance to cancel or downsize

  5. Planning Planned Project Existing System Support Analysis Production System Business Requirements Implementation Design Technical Design Feasibility Analysis • Technical • can system be developed? • Operational • can organization absorb the change? • Economic • what is business justification? • Schedule • can system be implemented in time available?

  6. People Technical Feasibility Technology • Is the technology or solution practical? • Do we currently possess the necessary technology? • Do we possess the necessary technical expertise?

  7. People Operational Feasibility • Is the problem worth solving? • Will the solution to the problem work? • How do the end-users and managers feel about the problem (or solution)?

  8. People Schedule Feasibility • Can the project deadlines be met? • What will it cost to accelerate development?

  9. Economic Analysis • Cost estimates • acquisition or development costs • operation and maintenance costs • Benefit estimates • tangible benefits • intangible benefits

  10. Estimating Costs • acquisition or development (one time) • operation and support (ongoing) • in these expense categories • personnel hours • computer usage • media and supplies • equipment and software

  11. Estimating Acquisition Cost • Shop the Vendors (informal) • Request for Proposal (RFP) • Request for Quote (RFQ)

  12. Estimating Development Cost • break project up into tasks • estimate SDLC tasks independently • use life cycle cost model • e.g., 1-3-3-3 model • take advantage of analogy/experience • how much have similar projects cost? • calculate function point metric • estimate “size” of project from inputs, outputs, etc. • apply productivity rate

  13. Estimating Operation and Support • client/user personnel • technical personnel • media and supplies • equipment and software support • repair • enhancement

  14. Estimating Tangible Benefits • reduced costs • manual operations • computer operations • programmed decisions • increased revenue • new services • differentiated product • faster delivery • better quality • larger market share

  15. Estimating Intangible Benefits • information quality • precision • timeliness • integration • presentation • job satisfaction • participative design • job enrichment • improved tools • external standing • responsiveness • corporate image

  16. Economic Analysis (continued) • traditional capital planning techniques apply • payback analysis • return on investment • net present value

  17. January 1996 Payback Analysis • determines how long it will take for accrued benefits to overtake accrued and continuing costs • most companies want quick payback • 3-5 years is typical

  18. % Return on Investment (ROI) • determines the lifetime profitability of different investments • ROI = (benefits - costs) / costs) • Annual ROI is common measure

  19. Net Present Value (NPV) • determines the lifetime profitability of different investments • NPV = discounted benefits - discounted costs • Preferred technique in many organizations

  20. Feasibility Matrix

  21. Benefit Profile Chart(for documenting intangibles)

  22. Things to remember • IT’S ALWAYS POLITICS • Find the political agendas • You cannot get new system approved unless you understand the environment • Ownership • Authority • Reduced responsibilities or workers

  23. Things to remember • You will have to SELL the new system • Possibly use a CONOPS (Concept of Operations)

  24. Developing and Using a Concept of Operations In Transportation Management Systems The Foundation for Effective System Development and Operations

  25. Purpose and Project Sponsor • Introduce the Concept of Operations and its role in transportation management systems • Provide an overview of guidance document

  26. Presentation Outline • What is a Concept of Operations? • Lessons Learned in Developing and Using a Concept of Operations In Transportation Management Systems • Available Resources to Support Concept of Operations Development and Use

  27. What is a Concept of Operations?

  28. Concept of Operations • The Concept of Operations should be a document available, and relevant, to all stakeholders in the system, no matter what their background or role within the system. It should be as readable and relevant to high-level decision makers as it is to the manager as it is to the operator. The Concept of Operations answers the who, what, when, where, why, and how for the new or existing system.

  29. Role Within Systems Engineering • Graphic provided by ASE Consulting LLC

  30. Mature Process for System Development Functional Analysis System Spec System Design Module Design User's Views Module Design System Design System Spec Reqts User Trial Plan Accept Test Plan Integ Test Plan Unit Test Plan module coding Integ System Coded Units Delivered System Modules System & int. testing Unit testing Acceptance testing DesignersView Developers View Users View Ould and Unwin 1986 “Testing in Software Development”

  31. Concept of OperationsCONOPS“The Big Picture”

  32. Common Problems • Typical Requirements Issues • Unable to identify “owners” • Security/Access Responsibility • Ownership of Process/Data/IT • Lack of formal Requirements Process • User Interface (too many “users”) • Responsiveness - Status tracking • What other Issues can you come up with?

  33. CONOPS1 Philosophy • Users Perspective • Holistic (operational) view of system • vs. individual pieces or functions or interfaces • First step of a development • identify user types and primary modes • Focus is on prioritizing user requirements at a VERY high level • Iterative • Results of ConceptualAnalysis 1 The Concept of Operations: The Bridge from Operational Requirements to Technical Specifications, Fairley & Thayer, 1996.

  34. Goals of a Concept of Operations • Stakeholder Identification and Communication • High-level System Definition • Foundation for Lower-level System Description • Definition of Major User Classes and User Activities

  35. Elements of a Concept of Operations

  36. Essential Elements • Description of current system or situation • Description of needs that motivate new system • Modes of operation • User classes / characteristics • Operational features of the new system

  37. Essential Elements • Priorities among proposed operational features • Operations scenarios for each operational mode and class of user • Limitations of proposed (new) system • Impact analysis

  38. What Questions Will the Concept of Operations Answer? • What – What are the known elements and the high-level capabilities of the system? • Where – What are the geographical and physical extents of the system? • When – What is the time-sequence of activities that will be performed? • How – What resources do we need to design, build, or retrofit the system? • Who – Who are the stakeholders involved with the system? • Why – What does your organization lack that the system will provide?

  39. How to write a CONOPS • From users’ perspective • Narrative prose (natural language) using users’ language • Should be organized to “tell a story” • Should place emphasis on user need, and maintaining tracability to those needs

  40. Roles for CONOPS • To communicate user and buyer needs to developers • To communicate developer understanding to user and buyer • To show different user viewpoints • To document consensus • Show system vs. software • To show common understanding between multiple system/software developers

  41. Additional roles • Verification mechanism for users • Stating desires and expectations, without making them quantifiable and testable • Show thoughts and concerns of possible solution strategies

  42. When do you build a CONOPS? • Before the decision is made to develop a system (to support decision) • Before RFP • After the award of contract, to help developer better understand user needs

  43. CONOPS Outline • Scope • References • Current system • Justification / nature of proposed changes • Concept of operations • Operational scenarios • Summary of impacts • Analysis of proposed system

  44. CONOPS Process • Determine objectives, roles, and team members • Tailor CONOPS document • Describe objectives and shortcomings of current system • Describe scope/boundary of current /new system • Describe current/new operational policies • Develop and validate operational scenarios • Prioritization • Analyze Operational Impacts

  45. CONOPTS • Overview of benefits, limitations, advantages, disadvantages • Develop scenarios, and walk-through them • Walk though scenarios with users • Obtain consensus on scenarios • Describe impacts (operational and organizational and political) of new system • Describe benefits, limitations, advantages and disadvantages of new vs. old system

  46. Living Document • CONOPS should be updated and maintained during the entire lifecycle. • Update to reflect new users, system design, operational policies, user needs. • Must be under configuration management

  47. Recommended Format 1. Scope 1.1 Identification 1.2 System overview 1.3 Document overview 2. Other referenced documents

  48. Scope • The Scope section will provide an overview of the entire Concept of Operations, including the following elements • Outline the Contents of the Document • Purpose for Implementing the System • Highlight Major Objectives and Goals • Identify the Intended Audience • Set Boundaries on the Scope of the System • Describe an Overarching Vision for the System

  49. Referenced Documents • Referenced Documents – this section identifies resources used when developing the document. Types of reference documents that are typically listed include: • Business Planning Documents • Concept of Operations for Related Systems • Requirements for Related Systems • Studies to Identify Operational Needs • System Development Meeting Minutes

  50. Recommended Format 3. Current system or situation 3.1 Background, objectives, scope 3.2 Operational policies and constraints 3.3 Description of current system 3.4 Modes of use of current system 3.5 User classes for current system 3.5.1 Organizational structure 3.5.2 Profiles of user classes 3.5.3 Interactions among user classes 3.6 Other involved personnel 3.7 Support Environment for current system

More Related