Teaching slides Chapter 4

1. Teaching slides Chapter 4

2. Chapter 4: software feasibility study Contents • Financial feasibility study - Technical feasibility study : Throwaway prototyping : Evolutionary prototyping

3. Chapter 4: software feasibility study Financial feasibility study Any kind of project faces many types of risks. If any of these risk strikes then the project will fail and cost incurred on the project will be lost. It is also possible that the product or service created during the project; may not be lucrative enough to generate profits and so offset the costs of the project. So before commencement of any project, it is advisable to conduct a feasibility study to know if it will be worthwhile to go for the project or not.

4. Chapter 4: software feasibility study Financial feasibility study If a company has been buying some goods and finds them costly then it can think of building them instead of buying them. But it is better to find out if the cost of the project will be less than the cost of buying. If not then it will be better to keep buying instead of making it. A financial feasibility study can be conducted for this purpose. For example if a company buys goods worth $10,000 per year and the project cost comes at $41,000 then it will take more than 4 years to recover the cost. Company will have think if it will be worthwhile to institute the project at all.

5. Chapter 4: software feasibility study Financial feasibility study If a company is instituting projects to create goods or services which can be sold in the market then the company may need to find out potential sales versus the cost incurred on the project. Software vendors create software products so that they can sell these software products in the market. If cost of the project to create a software product turns to be high and potential sales of the software product is not good enough then the software vendor may incur losses. As part of a feasibility study, a software vendor may conduct market survey to find out potential sales revenues. The vendor may also do some research to find out cost of the project. Based on the estimated cost and potential revenue the vendor can decide whether to go ahead with the project or shelve the idea.

6. Chapter 4: software feasibility study Technical feasibility study A software vendor may have some fantastic idea to build a software product. The financial feasibility study indicate that the revenue potential is promising. But still some risks may be involved in going ahead with the project. It may be due to the fact that some technical problems may not allow the project to progress and thus the project may need to be shelved. So technical feasibility studies are also conducted to ensure technical problems are not encountered during the project. Conducting such technical feasibilities studies are very common for software projects. There are many ways, technical feasibility studies can be conducted. But the most common methods include building a prototype of the software product. A software prototype is a miniature replica of the actual software product which can be built quickly and without much effort. Some of the most common types of software prototypes include throwaway prototypes and evolutionary prototypes. In the next slide, a prototyping cycle is depicted where preliminary software requirements are used to create a prototype and this cycle is repeated until a final prototype is approved by the customer.

7. Chapter 4: software feasibility study Technical feasibility study

8. Chapter 4: software feasibility study Throwaway prototyping Throwaway prototyping is used to create prototypes fast and cheaply. Throwaway prototyping is used on Waterfall projects. The customer provides preliminary software requirements to the project team. The project team builds a prototype based on these preliminary requirements. The project team uses basic user interfaces and instead of writing source code to create business logic, uses some dummy navigation to show as to how the software product will work. This prototype is then shown to the customer. The customer will evaluate and find if any changes are needed. These required changes are then incorporated in the prototype and shown to the customer again. This cycle continues till the customer gets fully satisfied. Once this happens then the project team will create final software requirements based on this final prototype. Since no business logic was written for the prototype, it is useless in building the actual software product. So the prototype is discarded. This is why it is known as throwaway prototype. A throwaway prototype cycle is depicted on the next slide.

9. Chapter 4: software feasibility study Throwaway prototyping

10. Chapter 4: software feasibility study Evolutionary prototyping Evolutionary prototyping is used to create prototypes which can be used in building the actual software product. Evolutionary prototyping is used on Agile projects. The customer provides preliminary software requirements (user story) to the project team for a Sprint. The project team builds a prototype based on these preliminary requirements for each user story. The project team creates user interfaces and writes source code to create business logic. This prototype is then shown to the customer. The customer will evaluate and find if any changes are needed. These required changes are then incorporated in the prototype and shown to the customer again. This cycle continues till the customer gets fully satisfied. Once this happens then the project team will create final user stories based on this final prototype. Since business logic was written for the prototype, it can be used in building the actual software product. So the prototype evolves into a fully developed software product. This is why it is known as evolutionary prototype. An evolutionary prototype cycle is depicted on the next slide.

11. Chapter 4: software feasibility study Evolutionaryprototyping