Feasibility study in Software Engineering ppt

View Discussion

Improve Article

Save Article

  • Read
  • Discuss
  • View Discussion

    Improve Article

    Save Article

    Feasibility Study in Software Engineering is a study to evaluate feasibility of proposed project or system. Feasibility study is one of stage among important four stages of Software Project Management Process. As name suggests feasibility study is the feasibility analysis or it is a measure of the software product in terms of how much beneficial product development will be for the organization in a practical point of view. Feasibility study is carried out based on many purposes to analyze whether software product will be right in terms of development, implantation, contribution of project to the organization etc. 

    Types of Feasibility Study : 
    The feasibility study mainly concentrates on below five mentioned areas. Among these Economic Feasibility Study is most important part of the feasibility analysis and Legal Feasibility Study is less considered feasibility analysis. 

    1. Technical Feasibility – 
      In Technical Feasibility current resources both hardware software along with required technology are analyzed/assessed to develop project. This technical feasibility study gives report whether there exists correct required resources and technologies which will be used for project development. Along with this, feasibility study also analyzes technical skills and capabilities of technical team, existing technology can be used or not, maintenance and up-gradation is easy or not for chosen technology etc. 
    2. Operational Feasibility – 
      In Operational Feasibility degree of providing service to requirements is analyzed along with how much easy product will be to operate and maintenance after deployment. Along with this other operational scopes are determining usability of product, Determining suggested solution by software development team is acceptable or not etc. 
    3. Economic Feasibility – 
      In Economic Feasibility study cost and benefit of the project is analyzed. Means under this feasibility study a detail analysis is carried out what will be cost of the project for development which includes all required cost for final development like hardware and software resource required, design and development cost and operational cost and so on. After that it is analyzed whether project will be beneficial in terms of finance for organization or not. 
    4. Legal Feasibility – 
      In Legal Feasibility study project is analyzed in legality point of view. This includes analyzing barriers of legal implementation of project, data protection acts or social media laws, project certificate, license, copyright etc. Overall it can be said that Legal Feasibility Study is study to know if proposed project conform legal and ethical requirements. 
    5. Schedule Feasibility – 
      In Schedule Feasibility Study mainly timelines/deadlines is analyzed for proposed project which includes how many times teams will take to complete final project which has a great impact on the organization as purpose of project may fail if it can’t be completed on time. 
       

    Feasibility Study Process : 
    The below steps are carried out during entire feasibility analysis. 
     

    1. Information assessment
    2. Information collection
    3. Report writing
    4. General information

    Need of Feasibility Study : 
    Feasibility study is so important stage of Software Project Management Process as after completion of feasibility study it gives a conclusion of whether to go ahead with proposed project as it is practically feasible or to stop proposed project here as it is not right/feasible to develop or to think/analyze about proposed project again. 

    Along with this Feasibility study helps in identifying risk factors involved in developing and deploying system and planning for risk analysis also narrows the business alternatives and enhance success rate analyzing different parameters associated with proposed project development.
     

    Feasibility study in Software Engineering ppt
    Download

    Feasibility study in Software Engineering ppt

    Skip this Video

    Loading SlideShow in 5 Seconds..

    Feasibility Analysis for a Software Project PowerPoint Presentation

    Feasibility study in Software Engineering ppt
    Feasibility study in Software Engineering ppt

    Download Presentation

    Feasibility study in Software Engineering ppt

    Feasibility Analysis for a Software Project

    - - - - - - - - - - - - - - - - - - - - - - - - - - - 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

    What is a feasibility study in software engineering?

    Feasibility study is one of stage among important four stages of Software Project Management Process. As name suggests feasibility study is the feasibility analysis or it is a measure of the software product in terms of how much beneficial product development will be for the organization in a practical point of view.

    What is feasibility study and types of feasibility study?

    There are different types of studies to check feasibility, such as technical feasibility, market feasibility, organization feasibility, and financial feasibility, that help a company determine the viability of a business plan.

    What is feasibility study in software engineering Tutorialspoint?

    Feasibility study This study analyzes whether the software product can be practically materialized in terms of implementation, contribution of project to organization, cost constraints and as per values and objectives of the organization.

    What are the 3 parts of feasibility study?

    Contents of a Feasibility Study Technology Considerations. Product or Service Marketplace. Identification of Specific Market.