Feasibility Study

A feasibility study is a preliminary study undertaken to determine and document a project's viability. The term feasibility study is also used to refer to the resulting document. These results of this study are used to make a decision whether to proceed with the project, or table it. If it indeed leads to a project being approved, it will - before the real work of the proposed project starts - be used to ascertain the likelihood of the project's success. It is an analysis of possible alternative solutions to a problem and a recommendation on the best alternative. It, for example, can decide whether an order processing be carried out by a new system more efficiently than the previous one.

A feasibility study could be used to test a proposal for new system, which could be used because:

The current system may no longer carry its purpose,
Technological advancement may have rendered the current system obsolete,
The business is expanding, allowing it to cope with extra work load,
Customers are complaining about the speed and quality of work the business provides,
Competitors are now winning a big enough market share due to an effective integration of a computerized system.

A feasibility study should examine three main areas:

-Market Issues
-Technical and Organizational Requirements
-financial overview

Needs Analysis

A needs analysis should be the first undertaking of a feasibility study as it clearly defines the project outline and the clients' requirements. Once these questions have been answered the person/s undertaking the feasibility study will have outlined the project needs definition. The following questions need to be asked to define the project needs definition: What is the end deliverable? What purpose will it serve? What are the environmental effects? What are the rules and regulations? What standards will we be measured against? What are the quality requirements? What is the minimal quality requirements allowed? What sustainability can we expect? What carry over work can we expect? What are the penalty clauses? How much do we need to outsource? How much do we need to insource?


Technical feasibility study
This involves questions such as whether the technology needed for the system exists, how difficult it will be to build, and whether the firm has enough experience using that technology.The assessment is based on an outline design of system requirements in terms of Input, Output, Fields, Programs, and Procedures.This can be qualified in terms of volumes of data,trends,frequency of updating,etc..in order to give an introduction to the technical system.


Schedule Feasibility study
This involves questions such as how much time is available to build the new system, when it can be built , whether it interferes with normal business operation, number of resources required, dependencies, etc.


Various Components of a Feasibility Study Report:

1. Executive Summary: the executive summary provides the reader with an overview of the feasibility study and will help them see the entire picture before with an overview of the feasibility study and will help them see the entire picture before they read the details. So e decision makers may only read the exetive summary. Thus, the executive summary should be concise.

2. Background Information: Some background on setting information is critical to provide the context of the feasibility study.

3. Proposed System: The following information needs to be included:

a. Description of the System.
b. Advantages and Disadvantages of the proposed system.
c. staffing
d. space requirements
e. basic layout of the central kitchen and satellite kitchens
f. equipment needs and costs.
g. computer software requirements
h. site possibilities

4. Comparison of current proposed systems: A comparison of the current and the proposed centralized foodservice system needs to be included. Comparisons are needed for staffing members/hours, staffing costs, food costs, equipment costs, building costs, and total costs. A discussion of building and equipment costs needed in the next ten years for the current system needs to be included.

5. Project schedule: A “best guess” schedule for the project would be included as a part of the feasibility study. Realistic dates for each phase of the project would be include. However, there often are delays during implementation of a project, particularly one with a major construction component.

6. Final Recommendation: A final recommendation is provided in the feasibility study based on the research conducted. This recommendation includes the rationale for the recommendation and financial evidence that supports the recommendation.




PROJECT MANAGEMENT

Project management is the discipline of organizing and managing resources (e.g. people) in such a way that the project is completed within defined scope, quality, time and cost constraints. A project is a temporary and one-time endeavor undertaken to create a unique product or service, which brings about beneficial change or added value. This property of being a temporary and one-time undertaking contrasts with processes, or operations, which are permanent or semi-permanent ongoing functional work to create the same product or service over and over again. The management of these two systems is often very different and requires varying technical skills and philosophy, hence requiring the development of project management.

The first challenge of project management is to make sure that a project is delivered within defined constraints. The second, more ambitious challenge is the optimized allocation and integration of inputs needed to meet pre-defined objectives. A project is a carefully defined set of activities that use resources (money, people, materials, energy, space, provisions, communication, etc.) to meet the pre-defined objectives.

Project management activities

Project management is composed of several different types of activities such as:

-Planning the work or objectives
-Analysis & design of objectives and events
-Assessing and controlling risk (or Risk Management)
-Estimating resources
-Allocation of resources
-Organizing the work
-Acquiring human and material resources
-Assigning tasks
-Directing activities
-Controlling project execution
-Tracking and reporting progress
-Analyzing the results based on the facts achieved
-Defining the products of the project
-Forecasting future trends in the project
-Quality Management
-Issues management
-Issue solving
-Defect prevention
-Identifying, managing & controlling changes
-Project closure
-Communicating to stakeholders
-Increasing/ decreasing a company's workers






Q. Define RAD& JAD. Explain it in detail. Compare RAD & JAD?

Rapid application development (RAD), is a software development process developed initially by James Martin in the 1980s. The methodology involves iterative development, and the construction of prototypes. Traditionally the rapid application development approach involves compromises in usability, features, and/or execution speed. It is described as a process through which the development cycle of an application is expedited. Rapid Application Development thus enables quality products to be developed faster, saving valuable resources.

Pros
Increased speed of development through methods including rapid prototyping, virtualization of system related routines, and other techniques.
Decreased end-user functionality (arising from narrower design focus), hence reduced complexity
Larger emphasis on simplicity and usability of GUI design

Cons
Reduced Scalability, and reduced features when a RAD developed application starts as a prototype and evolves into a finished application
Reduced features occur due to time boxing when features are pushed to later versions in order to finish a release in a short amount of time
The data needs to already exist

JAD
Joint Application Development (JAD) is a popular fact-finding technique that brings users into the development process as active participants.

The JAD process is based on four simple ideas:

People who actually do a job have the best understanding of that job.
People who are trained in information technology have the best understanding of the possibilities of that technology.
Information systems and business processes rarely exist in isolation -- they transcend the confines of any single system or office and affect work in related departments. People working in these related areas have valuable insight on the role of a system within a larger community.
The best information systems are designed when all of these groups work together on a project as equal partners.

The JAD process does for computer systems development what Henry Ford did for the manufacture of automobiles (a method of organizing machinery, materials, and labor so that a car could be put together much faster and cheaper than ever before – the assembly line). The goal in systems development is to identify what the users really need and then set up a system or process that will provide it. Traditional methods have several built-in delay factors that get worse as more people become involved.

Compared with traditional methods, JAD may seem more expensive and can be cumbersome if the group is too large relative to the size of the project. Many companies find, however, that JAD allows key users to participate effectively in the requirements modeling process. When users participate in the systems development process, they are more likely to feel a sense of ownership in the results, and support for the new system. When properly used, JAD can result in a more accurate statement of system requirements, a better understanding of common goals, and a stronger commitment to the success of the new system.
A drawback of JAD is that it opens up a lot of scope for inter-personal conflict.


PROTOTYPING

Prototyping is the process of quickly putting together a working model (a prototype) in order to test various aspects of a design, illustrate ideas or features and gather early user feedback. Prototyping is often treated as an integral part of the system design process, where it is believed to reduce project risk and cost. Often one or more prototypes are made in a process of iterative and incremental development where each prototype is influenced by the performance of previous designs, in this way problems or deficiencies in design can be corrected. When the prototype is sufficiently refined and meets the functionality, robustness, manufacturability and other design goals, the product is ready for production.
Software prototyping

The prototyping model is a software development process that begins with requirements collection, followed by prototyping and user evaluation. Often the end users may not be able to provide a complete set of application objectives, detailed input, processing, or output requirements in the initial stage. After the user evaluation, another prototype will be built based on feedback from users, and again the cycle returns to customer evaluation. The cycle starts by listening to the user, followed by building or revising a mock-up, and letting the user test the mock-up, then back.

Advantages of prototyping

· May provide the proof of concept necessary to attract funding
· Early visibility of the prototype gives users an idea of what the final system looks like
· Encourages active participation among users and producer
· Enables a higher output for user
· Cost effective (Development costs reduced)
· Increases system development speed
· Assists to identify any problems with the efficacy of earlier design, requirements analysis and coding activities
· Helps to refine the potential risks associated with the delivery of the system being developed
Disadvantages of prototyping
· User’s expectation on prototype may be above its performance
· Possibility of causing systems to be left unfinished
· Possibility of implementing systems before they are ready.
· Producer might produce a system inadequate for overall organization needs
· Producer might get too attached to it (might cause legal involvement)
· Often lack flexibility
· Not suitable for large applications
· Project management difficulties





User Interface Design

User interface design or user interface engineering is the design of computers, appliances, machines, mobile communication devices, software applications, and websites with the focus on the user's experience and interaction. Where traditional graphic design seeks to make the object or application physically attractive, the goal of user interface design is to make the user's interaction as intuitive as possible—what is often called user-centered design. Where good graphic/industrial design is bold and eye catching, good user interface design is to facilitate finishing the task at hand over drawing attention to itself. Graphic design may be utilized to apply a theme or style to the interface without compromising its intuitive usability. The intuitiveness of an interface may depend on zymology from an artistic perspective as much as functionality from a technical engineering perspective.

User Interface design is involved in a wide range of projects from computer systems, to cars, to commercial planes; all of these projects involve much of the same basic human interaction yet also require some unique skills and knowledge. As a result, user interface designers tend to specialize in certain types of projects and have skills centered around their expertise, whether that be software design, user research, web design, or industrial design.

User- Interface design is governed by several design principles. Fundamental principles compiled by Talin in 1998 for designing user interfaces include the following:

1. Principle of user profiling – Know your User first.
2. Metaphor – Borrow behaviors from systems familiar to your users.
3. Feature Exposure – Let the user see clearly what functions are available.
4. Coherence – the behavior of the program should be coherent, i.e. internally and externally consistent.
5. State Visualization – changes in behavior should be reflected in the appearance of the program.
6. Shortcuts – provide both concrete and abstract ways of getting a task done.
7. Focus – Some aspects of the User Interface (UI) attract attention more than others do.
8. Grammar – A user interface is a kind of language – know what the rules are.
9. Help – understand the different kinds of help a user needs.
10. Safety – let the user develop confidence by providing a safety net.
11. Context – limit the user activity to one well defined context unless there’s a good reason not to do.
12. Aesthetics – create a program of beauty
13. User testing – recruit help in spotting the inevitable defects in your design.
14. Humility – listen to what ordinary people have to say.

User Interface Design Elements:

The following are the important elements of user interface design:
- Menus
- Modes
- Elementary operations
- Dialog window
- Color
- Sound

Qualities of a good UID

- Simplicity
- Consistency
- Intuitiveness
- Graphic interface design
- Aesthetics





Q. Compare and contrast file management system and database management system.

Ans. Files vs. DBMS

Application must stage large datasets between main memory and secondary storage (e.g., buffering, page-oriented access, 32-bit addressing, etc.). There is a need to protect data from inconsistency due to multiple concurrent users. Crash recovery, security and access control should be taken into account. Database management systems were developed to handle the following difficulties of typical file-processing systems supported by conventional operating systems.

• Data redundancy and inconsistency
• Difficulty in accessing data
• Data isolation - multiple files and formats
• Integrity problems
• Atomicity of updates
• Concurrent access by multiple users
• Security problems

When a computer user wants to store data electronically they must do so by placing data in files. Files are stored in specific locations on the hard disk (directories). The user can create new files to place data in, delete a file that contains data, rename the file, etc -- all known as file management; a function provided by the Operating System (OS).

If the user wishes to perform some operation on the data he has placed in the file, such as viewing a list of his friends that celebrate their birthday in June, he has to scroll through all the data by himself in order to see the data he is interested in. Moreover, he has to know where he put the files that contain the data, and if there are multiple files he has to remember to go through each one of them.

A Database Management System is intended to remove this burden of manually locating data, and having to scroll through it by allowing the user to create a logical structure for the data beforehand, and then allowing the user to place the data in the database that the DBMS is managing. In this way the DBMS abstracts away the physical concerns of organising files, and provides the user with a logical view of the data.
Note, that the DBMS will still -- behind the scenes though -- place the data in files on the hard-disk.





What is a System?
A system is a group of interrelated components working together toward a common goal by accepting inputs and producing outputs in an organized transformation process. System will have the following basic interacting components (functions):
1. Input
2. Processing
3. Output
4. Feedback
5. Control





Q. What do you understand by system development life cycle?

Systems Development Life Cycle (SDLC) or sometimes just (SLC) is defined by the U.S. Department of Justice (DoJ) as a software development process, although it is also a distinct process independent of software or other information technology considerations. It is used by a systems analyst to develop an information system, including requirements, validation, training, and user ownership through investigation, analysis, design, implementation, and maintenance. SDLC is also known as information systems development or application development. An SDLC should result in a high quality system that meets or exceeds customer expectations, within time and cost estimates, works effectively and efficiently in the current and planned information technology infrastructure, and is cheap to maintain and cost-effective to enhance. SDLC is a systematic approach to problem solving and is composed of several phases, each comprising multiple steps:

1. Initiation Phase: the initiation of a system begins when a need or opportunity is identified. A project manager should be appointed to manage the project. This business need is documented in a Concept Proposal. After the Concept Proposal is approved, the System Concept Development Phase begins.

2. System Concept Development Phase: once a business need is approved the approaches for accomplishing the concept are reviewed for feasibility and appropriateness. The Systems Boundary Document identifies the scope of the system and requires senior official approval and funding before the planning phase.

3. Planning Phase: the concept is further developed to describe how the business will operate once the approved system is implemented, and to access how the system will impact employee and customer privacy. To ensure the products and/or services provide the required capability on-time and within budget, project resources, activities, schedules, tools, and reviews are defined. Additionally, security certification and accreditation activities begin with the identification of system security requirements and the completion of a high level vulnerability assessment.

4. Requirements Analysis Phase: Functional user requirements are formally defined and delineate the requirements in terms of data, system performance, security, and maintainability requirements for the system. All the requirements are defined to a level of detail sufficient for system design to proceed. All requirements need to be measurable and testable and relate to the business need or opportunity identified in the initiation phase.

5. Design Phase: the physical characteristics of the system are designed during this phase. The operating environment is established, major subsystems and their inputs and outputs are defined, and processes are allocated to resources. Everything requiring user input or approval must be documented and reviewed by the user. The physical characteristics of the system are specified and detailed design is prepared. Subsystems identified during design are used to create a detailed structure of the system. Each subsystem is partitioned into one or more design units or modules. Detailed logic specifications are prepared for each software module.

6. Development Phase: the detailed specifications produced during the design phase are translated into hardware communications and executable software. Software shall be unit tested, integrated and retested in a systematic manner. Hardware is assembled and tested.

7. Integration and Test Phase: the various components of the system are integrated and systematically tested. The user test the system to test the functional requirements, as defined in the functional requirements document, are satisfied by the developed or modified system. Prior to installing and operating the system in a production environment, the system must undergo certification and accreditation activities.

8. Implementation Phase: the system or system modifications are installed and made operational in a production environment. The phase is initiated after the system has been tested and accepted by the user. This phase continues until the system is operating in production in accordance with the defined user requirements.

9. Operations and Maintenance Phase: the system operation is ongoing. The system is monitored for continued performance in accordance with the user requirements, and needed system modification requirements are incorporated. The operational system is periodically assessed through in-process reviews to determine how the system can be made more efficient and effective. Operations continue as long as the system can be effectively adapted to respond to an organization’s needs. When modification or changes are identified as necessary, the system may reenter the planning phase.

10. Disposition Phase: the disposition activities ensure the orderly termination of the system and preserve the vital information about the system so that some or all of the information may be reactivated in the future if necessary. Particularly emphasis is given to proper preservation of the data processed by the system, so that the data is effectively migrated to another system or archived in accordance with applicable records management regulations and policies, for potential future access.






Structure charts

Structure charts are used to specify the high-level design, or architecture, of a computer program. As a design tool, they aid the programmer in dividing and conquering a large software problem, that is, recursively breaking a problem down into parts that are small enough to be understood by a human brain. The process is called top-down design, or functional decomposition.

Programmers use a structure chart to build a program in a manner similar to how an architect uses a blueprint to build a house. In the design stage, the chart is drawn and used as a way for the client and the various software designers to communicate. During the actual building of the program (implementation), the chart is continually referred to as the master-plan. Often, it is modified as programmers learn new details about the program. After a program is completed, the structure chart is used to fix bugs and make changes (maintenance). It is especially important in this stage, because often the original “architect” is long gone, and a programmer new to the project uses the chart as a navigational tool into the often huge set of source code files. If you've ever experienced the joy of modifying someone else's program, you know how important this blue print can be.

The first step in creating a structure is to place Class::main in the root of an upside-down tree which forms the structure chart. The next step is to conceptualize the main sub-tasks that must be performed by the program to solve the problem. These sub-tasks are placed in nodes below the root, and connecting lines are drawn from the root to each sub-task. Next, the programmer focuses on each sub-task individually, and conceptualizes how each can be broken down into even smaller tasks. Eventually, the program is broken down to a point where the leaves of the tree represent simple methods that can be coded with just a few program statements.

Once the structure chart has been designed, it is used to drive the software implementation. Branches of the tree are assigned as modules to be programmed by various members of the development team. Often, a process called bottom-up implementation and testing is used to implement each module. This process will be discussed in detail later in this document.







Change Management

It is not uncommon for scope to grow out of control when a properly completed statement of work was agreed on early in the planning process.

"Change is frequently a point of contention between the customer and the information systems organization, because they disagree on whether a particular function is a change or a part of the initial agreement.”

Change management is intended to protect the project manager and their team from being held responsible for schedule and budget overruns that were driven by the change scope.

Change can be the result of various events and factors including:
- An omission in defining initial scope.
- A misunderstanding of the initial scope.
- An external event such as government regulations that create new requirements.
- Organizational changes, such as mergers, acquisitions and partnerships, that create new business problems and opportunities.
- Availability of better technology.
- Shifts in planned technology that force unexpected changes to the business organization and/or processes.
- Management’s desire to have the system do more than was originally requested or agreed on.
- Reduced funding for the project or imposition of earlier deadline.

Change management system results in a collection of procedures for documenting a change request and define the steps necessary to consider the change based on the expected impact of the change.

Change requests are considered by Change Request Board CCB, which is responsible for approving or rejecting all change requests.

The CCBs composition typically includes members of the project team and outsiders who may have an interest or stake in the project.

The CCBs decision should be based on impact analysis.