CHAPTER 2: LITERATURE REVIEW
2.5 Feasibility Studies
A feasibility study in Software Engineering is a study to evaluate the feasibility of a proposed project or system. Feasibility studies are one of four important stages of the Software Project Management Process (Jena, 2020). As the name suggests feasibility studies are the feasibility analysis or measure of the software product, in terms of how beneficial the software development will be for the organisation from a practical point of view. Feasibility studies are carried out based on many purposes to analyse whether a software product will be right in terms of development, implementation, the contribution of a project to the organisation, etc. (Jena, 2020).
Multiple models are considered in order to identify the most suitable feasibility strategy for this research study.
2.5.1 Business Process Models
According to Issa (2007), Business Process Modelling (BPM) can be defined as the representation of one or more of the process perspectives to understand, analyse, and/or improve automated and/or non-automated business processes. Hence, the availability of business process models in any organisation is not tied to any corresponding software system. Rather, they may exist much before the automation of the business of any organisation. However, business process modelling can be used to contribute positively to the software development process (Issa, 2007).
Karner (1993) developed a use case points method that utilises the identified actors, uses cases to size the software project, and consequently estimates the predicted effort and time required to deliver an operational system. In addition, Issa et al. (2006) developed three use case-based software estimation methods regardless of the use-cases levels of detail. These cases include use-case rough estimation, use-case patterns catalogue estimation, and object points extraction using the anticipated system’s use-case model. The initial investigation for the results of these
new methods showed promising signs on the applicability of employing use case models for software cost estimation purposes (Issa, 2007).
Although performing early feasibility studies of software development projects using BPM provides a holistic overview, depending on the candidate use cases. It does not include project implementation components, where requirement engineering comes in.
2.5.2 Traditional Requirements Engineering (RE)
The scoping factors involved when creating bespoke software and therefore conducting traditional RE are; budget constraints, timeline issues and constraints, technical issues, and development issues. Analysts conducting traditional RE will consider whether the timeline and budget that have been set are feasible, and must ensure that the proposed software can meet the organisation’s objectives. Their main concern is whether the system that is developed will be
‘worthy’ for use (Jebreen, 2013).
Traditional RE and pre-implementation packaged software share similarities as both can be seen as comprised of the same kinds of elements, and as, to some degree the sharing of similar objectives and being influenced by similar business concerns and technical concerns.
2.5.3 Pre-implementation Packaged Software (PS)
Analysts engaging in pre-implementation RE must think about specific issues and decide whether any existing packages offered by their company can offer a solution. They will need to consider the time and cost involved with implementing a particular package and with making requested changes to that package, and they may well decide to refuse a request for a particular solution if that solution falls outside the scope of the company or the scope of their current products (Jebreen, 2013).
In this regard, pre-implementation PS RE differs strongly from traditional RE, as analysts practising traditional RE do not need to consider how to deal with requests for modifications to existing functions.
The critical requirement that is not covered in both cases is the components relative to business strategy development. With RE feasibility studies only focusing on the project implementation using the identified software. This requirement is identified by breaking up the feasibility components that will affect implementation strategy development.
2.5.4 TELOS
Sometimes a feasibility study is done as part of a systems development lifecycle, in order to drive precision for the implementation of technologies (Techopedia, 2020). Engineers might look at a five-point model called TELOS – this includes the following components:
i. Technical ii. Economic iii. Legal iv. Operational
v. Schedule
James A. Hall first presented the TELOS model in 2007 in his book, “Accounting Information Systems.” It has been adopted across a huge range of settings since then, because it offers a simple way to consider the most important issues related to feasibility, whether a multi-national pipeline or small business project is considered (Rudy, 2014).
The following components have been derived from Jena (2020):
i. Technical Feasibility
In technical feasibility, current resources both hardware and software, along with required technology are analysed/assessed to develop a project. This technical feasibility study reports on whether there exists correct required resources and technologies, which will be used for project development. Along with this, this study also analyses the technical skills and capabilities of the technical team, whether existing technology can be used or not, maintenance, and up-gradation viability for chosen technology, to name among a few aspects.
ii. Economic Feasibility
In economic feasibility studies, the cost and benefits of the project are analysed. This includes a detailed analysis of the related cost of the project development. This includes all required costs for final development like hardware and software resources, design and development cost, and operational cost. An economic feasibility study is a means for an organisation, to analyse whether a project will be financially beneficial for the said company.
iii. Legal Feasibility
In legal feasibility studies, a project is analysed from a legality point of view. This includes analysing barriers to the legal implementation of a project, data protection acts, project certificate,
license, copyright, etc. Overall, it can be said that a legal feasibility study is an analysis, to know whether a proposed project conforms to legal and ethical requirements within a company.
iv. Operational Feasibility
In operational feasibility studies, the ease of product operability and maintenance is analysed after deployment. Along with this, other operational scopes include determining the usability of the product, determining whether the suggested solution by the software development team is acceptable or not, etc.
v. Schedule Feasibility
In schedule feasibility studies, timelines/deadlines are mainly analysed for a proposed project.
This includes how much time teams will take to complete a final project, which might have a great impact on the organisation, as the purpose of the project may fail if it cannot be completed on time.
2.5.5 Feasibility Study Process
The steps below are carried out during the entire feasibility analysis.
i. Information collection ii. Information assessment iii. Report writing
iv. General information
2.5.6 Need for Feasibility Studies
Feasibility studies are an important stage of the Software Project Management Process, because it gives a conclusion of whether to go ahead with a proposed project (Jena, 2020). It provides a means to measure whether a project is practically feasible or to stop a proposed project as it is not feasible to develop.
Along with this, feasibility studies help in identifying risk factors involved in developing and deploying systems. Planning for risk analysis also narrows the business alternatives and enhances success rates, analysing different parameters associated with proposed project development.