Content deleted Content added
Line 43:
This assumes that the proposed project has been identified as a result of an exercise such as strategic <br />planning and sets out to evaluate the various technical, organisational, financial and business <br />options available. The aim is to establish the whether the direction and requirements of the project are feasible. <br />In essence this is a shortened, higher-level version of Stages 1 and 2 (requirements analysis and requirements specification).<br />
This should not be an expensive or time consuming exercise (maximum of one team working for 1/2 months). The aim is to evaluate the feasibility of the proposal, involving an analysis of the problem and determination of the best solution; usually a range of potential solutions are presented. Context diagrams, current physical DFDs, overview ERDs, a requirements catalogue, project management techniques such as activity networks and Gantt charts are produced. To pass this stage and go through to system development a proposal must demonstrate [Kendall&Kendall, 1988]:<br />
<br /><br />
Economic feasibility;<br />▼
Technical feasibility;<br />▼
Operational feasibility;<br />▼
Other types of feasibility may also require consideration, for example legal feasibility.<br />▼
▲Economic feasibility;
<br />
▲Technical feasibility;
<b><u>Economic Feasibility</b></u><br />▼
▲Operational feasibility;
<br />
▲Other types of feasibility may also require consideration, for example legal feasibility.<br />
▲Economic Feasibility<br />
The aim here is to assess the costs required for alternative systems and set them against the expected benefits. The types of alternatives that are frequently considered are the manual/computer boundaries as some tasks may benefit more than other s from computerization and non-functional characteristics such as the time delay between the real world and the different parts of the system: should we be looking at batch, on-line or real-time or a combination ? The system costs should also be estimated in terms of basic resources of money, people and time. For example, the following must be costed:
Systems development, for example in-house or management consultancy;
Line 59 ⟶ 58:
Hardware & software costs.
Set against the costs should be a quantifiable assessment of the expected benefits, for example reduced labour costs, improved customer service or predicted increase in orders. Economic feasibility is a bit of a 'black art', it's difficult to predict with any degree of certainty whether a system will in fact benefit an organisation. The most frequently missed cost is the cost of maintaining the system once it is installed.
<br />
<b><u>Technical Feasibility</b></u><br />
<br />
This is concerned with whether the solution can be implemented using existing technology. If it can then existing technology may require upgrading or adding to. If it can be done then the solution may require the integration of equipment or software that has not been combined before. Non-functional requirements such as batch or on-line processing, maximum response time for user-computer interaction, estimated frequency of transactions, maximum record and file sizes, networking loads and typical number of users are considered here. In addition, requirements of system expansion, security, data archiving and reliability are considered.
<br />
<b><u>Operational Feasibility</u></b><br />
<br />
This investigates factors such as the likely reaction of employees and union representatives to job and other proposed organisational changes. The main aim is to assess whether the solution will operate and be used after installation. For example, if users are happy with the current system and see no reason to change then there may be a high degree of resistance to the new proposal. Relevant factors here concern whether the solution has general management support and whether or not the users have been involved in the development of the proposal.
| |||