Teaching slides Chapter 3 Chapter 3 Feasibility Study

Teaching slides Chapter 3

Chapter 3 Feasibility Study Contents • Introduction • Feasibility study for software projects • Finding the economic feasibility of requirements – Build/buy decision – Budget instead of cost analysis • Finding the technical feasibility of requirements – Difficult to figure scenarios – When feasibility study not required • Prototyping – Throwaway prototyping – Evolutionary prototyping – Incorporating the prototyping in software development • Pilot projects

Chapter 3 Feasibility Study Introduction A feasibility study is conducted to find out if an idea is worth investing time and money for. For example if a bank wants to find out if a new service will be beneficial to its customers then the bank may conduct a market survey and figure out number of potential customers who may avail this service, costs of introducing and running this service and potential revenue which this service will bring to the bank. If the bank finds out that this new service will be viable after the feasibility study then it can introduce this service. If not then the bank may drop the idea. Feasibility study is carried out for all kinds of projects. A feasibility study can be economic or technical or both. For software projects, both economic and technical feasibility can be conducted. Technical feasibility study can be conducted after software requirements have been gathered. Feasibility study can also be done for software projects by building software prototypes and pilot projects.

Chapter 3 Feasibility Study Economic feasibility study for a software project can be done before or after commencement of the project. A market survey can be conducted to find out if it is profitable to build the software product which a company is thinking to build. Since at this stage, no software requirements have been collected, this market survey is based on demand for a specific type of software product. The cost to build such a software product is estimated from previous experience. A build or buy decision can also be made at this stage. If a software product is needed to be used by the company itself and if it is found that building such a software product is costly then the company may opt to buy a ready to use software product. For government software projects, an economic feasibility is mostly not needed. For these projects, the objectives may include increasing government reach to people for providing better services, national interests etc.

Chapter 3 Feasibility Study Technical feasibility study for a software project can be done only after software requirements have been gathered. A software requirement can be analyzed to find out if it is technically feasible to implement. Legacy systems become difficult to maintain due to obsolescence of software product parts. There could be newer systems available to replace these legacy systems. But fear of unforeseen failures in implementing new systems force companies to keep running their legacy systems. For well established software product vendors, technical feasibility study is not required when customers want to buy their software products. Customers already know case studies of implementation of these products at peer companies.

Chapter 3 Feasibility Study Prototyping

Chapter 3 Feasibility Study Prototyping involves developing a replica of the software product to be built. This replica or prototype should not involve much effort but still should be good enough to look like the software product to be built. Prototypes are used to show to end users to confirm if the prototype meets their requirements. If a prototype needs further improvement as per end user feedbacks then the project team makes appropriate changes and show the changed prototype to the end users again. This continues until the end users are fully satisfied. This process shows that prototype development is an iteration based activity. A software prototype can be a throw away prototype or an evolutionary prototyping. A throwaway prototype is developed when the project team should not invest too much effort in developing it. Once end user requirements become clear to the project team, the prototype can be thrown. An evolutionary prototype is developed when the prototype will be built with usable software components which can be used in building the software product itself.

Chapter 3 Feasibility Study Prototyping linked to Waterfall projects

Chapter 3 Feasibility Study A throwaway prototype is used on Waterfall projects. On waterfall projects, the prototype development is done before the software design is started. The objective of prototype development at this stage is to create a prototype which will have user interfaces with user input and output controls. The end users see these user interfaces and suggest how they will use them. Based on user feedback, the user interface is refined till end users are fully satisfied. Once a final prototype is developed then user requirements are created based on the prototype. The prototype itself is thrown as no business logic is implemented in the prototype.

Chapter 3 Feasibility Study Prototyping linked to agile projects

Chapter 3 Feasibility Study On agile projects evolutionary prototypes are used. The software development process on agile projects has short iteration. In each iteration, all software development processes of software requirement management, software design, software construction and software testing are carried out. All of these processes run almost in parallel to each other. Creating an evolutionary prototype in this environment is possible since the built prototype can be easily used in developing the actual software product.

Chapter 3 Feasibility Study Pilot projects are a good way to find out feasibility of a software product for a large organization. In principle, the management of a large organization may be convinced about a software product but how effectively it can be utilized across the entire organization is not clear. Using a pilot project, the software product can be implemented at one of the sites of the organization. The software product is used by end users at this site. The management analyzes if the software product is being used effectively and if any software defects are encountered. If the pilot project is successfully implemented then the management can signal for the complete implementation of the software product at all sites belonging to the organization. On the other hand if the pilot project fails then the software product will not be implemented at any other site of the organization.