Planning Alternative and Feasibility

Determination of Feasibility

The main aim of the feasibility study activity is to determine whether it would be financially and technically feasible to develop the product. The feasibility study activity involves the analysis of the problem and collection of all relevant information relating to the product such as the different data items which would be input to the system, the processing required to be carried out on these data, the output data required to be produced by the system as well as various constraints on the behavior of the system.



Technical Feasibility

This is concerned with specifying equipment and software that will successfully satisfy the user requirement. The technical needs of the system may vary considerably, but might include:

• The facility to produce outputs in a given time.
• Response time under certain conditions.
• Ability to process a certain volume of transaction at a particular speed.
• Facility to communicate data to distant locations. 

In examining technical feasibility, configuration of the system is given more importance than the actual make of hardware. The configuration should give the complete picture about the system’s requirements. How many workstations are required, how these units are interconnected so that they could operate and communicate smoothly? What speeds of input and output should be achieved at particular quality of printing.

Economic Feasibility

Economic analysis is the most frequently used technique for evaluating the effectiveness of a proposed system. More commonly known as Cost / Benefit analysis, the procedure is to determine the benefits and savings that are expected from a proposed system and compare them with costs. If benefits outweigh costs, a decision is taken to design and implement the system. Otherwise, further justification or alternative in the proposed system will have to be made if it is to have a chance of being approved. This is an outgoing effort that improves in accuracy at each phase of the system life cycle.

Operational Feasibility

This is mainly related to human organizational and political aspects. The points to be considered are:

• What changes will be brought with the system?
• What organizational structure are disturbed?
• What new skills will be required? Do the existing staff members have these skills? If not, can they be trained in due course of time? 

This feasibility study is carried out by a small group of people who are familiar with information system technique and are skilled in system analysis and design process. Proposed projects are beneficial only if they can be turned into information system that will meet the operating requirements of the organization. This test of feasibility asks if the system will work when it is developed and installed.

Feasibility Report

 The feasibility study results in a written document called the Feasibility Report. The purpose of the feasibility report is to present the project parameters and define the potential solutions to the defined problem, need, or opportunity. The following outline for the Feasibility Report.

1. Cover Sheet
2. Executive Summary - Management Summary and Recommendations
   A summary of important findings and recommendations for further system development. Should be maximum of one page and self contained, i. e., no references to tables or figures.
3. Introduction
   A brief statement of the problem, the computing environment in which the system is to be implemented and constraints that affect the project. The scope of the problem should be defined.
4. Background
   Discuss what others have done in relation to the problem. Define terms and other information which will be needed as background in order for the reader to understand the report.
5. Alternatives
   A presentation of alternative system configurations; state the criteria that were used in selecting the final approach.
6. System Description
   An abbreviated statement of scope of the system. Feasibility of allocated elements.
7. Cost-Benefit Analysis
   An economic justification for the system.
8. Evaluation of Technical Risk
   A presentation of technical feasibility.
9. Legal Ramifications
10. Other Project-Specific Topics

System Development

Systems development is the process of defining, designing, testing, and implementing a new software application or program. It could include the internal development of customized systems, the creation of database systems, or the acquisition of third party developed software. Written standards and procedures must guide all information systems processing functions. The organization’s management must define and implement standards and adopt an appropriate system development life cycle methodology governing the process of developing, acquiring, implementing, and maintaining computerized information systems and related technology.

System development activities

Planning

Planning is an objective of each and every activity, where we want to discover things that belong to the project. An important task in development of system is extracting the requirements or requirements analysis. Customers typically have an abstract idea of what they want as an end result, but not what software should do. Skilled and experienced software engineers recognize incomplete, ambiguous, or even contradictory requirements at this point. Frequently demonstrating live code may help reduce the risk that the requirements are incorrect.

Implementation, Testing and Documenting

Implementation is the part of the process where software engineers actually program the code for the project.

Software testing is an integral and important phase of the software development process. This part of the process ensures that defects are recognized as soon as possible.

Documenting the internal design of software for the purpose of future maintenance and enhancement is done throughout development.

Deployment and Maintenance

Deployment starts after the code is appropriately tested, approved for release, and sold or otherwise distributed into a production environment. This may involve installation, customization (such as by setting parameters to the customer's values), testing, and possibly an extended period of evaluation.

Software training and support is important, as software is only effective if it is used correctly.
Maintaining and enhancing software to cope with newly discovered faults or requirements can take substantial time and effort, as missed requirements may force redesign of the software.

Cost Determination

Early estimation of project size and completion time is essential for successful project planning and tracking. Multiple methods have been proposed to estimate software size and cost parameters. Suitability of the estimation methods depends on many factors like software application domain, product complexity, availability of historical data, team expertise etc.

The software cost estimation technique is also an essential part of the foundation for the good software management. There are several approaches used by models to estimate software development cost (effort to produce the software). Some are based on analogy, some on theory, and others on statistics, but all of them consider size of the software product as the most influential factor in predicting effort

Software Size Estimation Techniques

Lines of Code Counting

Lines of Code (LOC) counting is the simplest way to estimate the size of a software product. It provides simple and well understood metric. Usually LOC estimation is performed by software developers experienced in similar projects. The experts analyze the work packages and based on their own experience, they derive the LOC estimate needed to fulfill the requirements of each work package.

Function Point Analysis

Function points are useful estimators since they are based on information that is available early in the project life cycle. To calculate the function value delivered to the user, the number of inputs, outputs, inquires, and files (including interfaces to the other programs) from the user perspective is counted, weighted, and summed. The user function types should be identified, as defined below:

• External Input (Inputs) – Count each unique user data or user control input type that (i) enters the external boundary of the software system being measured and (ii) adds or changes data in a logical internal file.
• External Output (Outputs) – Count each unique user data or control output type that leaves the external boundary of the software system being measured.
• Internal Logical File (Files) – Count each major logical group of user data or control information in the software system as a logical internal file type. Include each logical file (e.g., each logical group of data) that is generated, used, or maintained by the software system.
• External Interface Files (Interfaces) – Files passed or shared between software systems should be counted as external interface file types within each system.
• External Inquiry (Queries) Count each unique input-output combination, where an input causes and generates an immediate output, as an external inquiry type.

Use-Case Points

Use-case Points are counted from the use-case analysis of a system. They are counted during the early phases of an object-oriented project that captures its scope with use cases. Each use-case is scaled as easy, medium, or hard to produce a point count. The use-case points can be also adjusted for the project’s technical and personnel attributes, and then directly converted to hours in order to obtain a rough idea of a nominal project schedule.

Object Points

Object Point estimation matched to the application composition phase of software product development. It is also a good match to associated prototyping efforts, based on the use of a rapid composition Integrated Computer Aided Software Environment (ICASE) providing graphic user interface builders, software development tools, and large, composable infrastructure and applications components. In these areas, it has compared well to Function Point estimation on a nontrivial (but still limited) set of applications.

PRICE Systems

PRICE related the basic costs of engineering and production to parameters that included a specification profile of units to be built, amount of work to be performed, the allowed schedule and resources available. It relied on the use of parametric relationships obtained through curve-fitting procedures that had been performed on a historical repository of significant cost data.

Development of System Proposal

System development or Software engineering proposal is a document that a software developer submits to a business customer for acceptance. The proposal describes the problem to be solved and explains the resulting benefits to the customer. Writing a solid software proposal requires a major effort

How to Write System Development or Software engineering Proposal

To write system development or software engineering proposal, follow these steps:

Problem Diagnosis:

Describe the problem domain; describe clearly what kind of issues exists in the current practice that you would like to address. Be as specific as you can and provide as many details and examples as possible. Describe the problem domain and the problem that you’re planning to solve. People usually make a mistake of describing at a very high level the problem, too generic, and then make a huge leap and dive deep into the tiny detail of their own solution. You must make effort to bridge this gap incrementally. Start with a brief description of high-level context, and then describe some specific issues that you’re interested in, and then provide more specific details about the sub-issues that your work will tackle.

The best approach is to observe personally the current practice, so that you know what you are talking about. Another useful approach is to interview “domain experts,” people who are working in your target domain and who will be your potential customers.

Proposed Treatment:

Describe how you propose to address the diagnosed problems. What specific interventions will you introduce?  What kind of metrics will you use to evaluate your success in solving the targeted problems? How will you know that you achieved your objective? Discuss thebusiness value of your proposed solution. What will your customer and users gain from your proposed system that they are lacking now?

Be as specific as possible in describing the envisioned benefits of your proposed solution. Provide example scenarios of how your proposed system will be used and explain how this solution is better than the current practice.

Plan of Work:

Make a convincing case that you know how to achieve the proposed goal. Step-by-step, go in details about what needs to be accomplished, how long it will take, and how it relates to other parts. You cannot know all the details yet, because you haven’t even started, but your plan should outline the main steps so that it is clear that you have a plan. Do not just copy a generic plan from a textbook, because that looks lame. Describe your team. What are the strengths and expertise of each team member? Explain why your team size is adequate to tackle the problem, and why the problem size requires your team and not fewer people.

Your proposal must be written in lay language, plain English, and you should avoid any engineering terminology (unless your problem domain is an engineering process, i.e., you will develop software to improve an engineering process).