IT 690 ISS capstone final class final paper

profiletruhar
final_project_template.doc

Final Report Template

PURPOSE OF THIS REPORT

The purpose of this report is to communicate the analyst’s findings upon completion of a detailed analysis of the current system. It also is intended to communicate the proposed approach to be used in continuing the project into the next phase. The student can select an existing company and identify improvements to a system or the student can use their own company.

IMPORTANT TEMPLATE FEATURES

This report includes suggestions and directions on how the student should complete the report. These suggestions/directions appear in the report template as text that is formatted as “hidden text”. Hidden text can only be viewed by toggling the “View Hidden Text” on. This can be done in WORD by selecting Tools, Options, and then toggling the Hidden Text option. For 2007 WORD, click on the round orange office button, go down to WORD options on the right, click display in the list on the left, then check “hidden text on the right.” When the hide text is activated, it will look blue. Thus, the student can read instructions on how to complete a section, subsequently turn off the instructions and begin writing that section or you can delete them. Be sure the font you want to appear is black. If it is blue that means that the hidden text was not turned off. Read the ending paragraph regarding pagination and spacing at the end of the report. Delete these instructional pages before you paginate. When a student wants to print their report, they have a choice of printing the report with or without the hidden text. They make this choice when they select File, Print, and then Print Options.

This template has been formatted for double spacing. Students must be take responsibility to proof spelling, page breaks, page numbering, formatting and alignment, and other report quality issues.

Finally, students should understand that this report is to be written TO THE USER(S)….not about the users, nor is it written to the Instructor. Thus, check to ensure that the report is written to the correct audience.

INFORMATION SYSTEMS STRATEGIC PLAN

ANALYSIS OF THE CURRENT <Insert the name of your system>

<Insert Your name >

<Insert Course Number and Name>

<Insert Instructor Name>

<Insert Date>

Proposal

ANALYSIS OF THE CURRENT <insert the name of your system>

Purpose

<insert the name of the system and the purpose of your evaluation>

History

<Insert a one to three paragraph description of the history of the existing system and the events that led to the project. >

Scope

<Insert a one or two paragraph description of the scope of the system that you will study in detail. In some cases, the scope is the same as identified in the Feasibility Survey and Project Overview Report written for the survey phase. In other cases, the scope has changed. If the scope has changed, explain the original scope, the new scope, and the rationale for changing the scope of the project.>

Part I

PROCEDURES AND METHODS USED DURING THIS INVESTIGATION

Procedures

The following is a list of methods and procedures followed in the subsequent detailed investigation of your system:<With lists and sublists, describe all activities. Be sure to define any buzzwords that you introduce>.

1. The following forms and reports were sampled:

a. <insert list>

2. The following existing documentation was studied:

a. <insert list>

3. <Subsequent numbered items should list any observation that was performed, people interviewed (sublist by name and title), surveys conducted, pictures or models drawn, walkthroughs conducted, analysis performed, etc. In other words, this list becomes a diary of your investigation.>

Methods

This report contains high-level pictures that diagram the flow of documents and data through your system. In the interest of brevity, this report only contains high-level pictures of the current system. The pictures use the following special symbols:

<The notation described below is for data flow diagrams (DFD). Modify the descriptions to explain any variations or situations which you feel may enhance the readability of your own DFDs. If you use a diagrammatic technique other than or in addition to DFDs, make appropriate revisions to the above paragraph and substitute or add a similar legend. Include the data flow diagram after the symbols are identified. >

A square represents a person, department, organization, or system that is beyond the scope of the system that we studied, but which provides input to or receives outputs from the system being studied. In other words, the squares define where the system begins and ends.

A rounded rectangle represents work that is performed in, by, or for the system. This includes work performed by people and machines.

An open-ended box represents data storage, either temporary or permanent. This includes in/out boxes, log sheets, reference books, manual files, and computer files.

An arrow represents the actual flow of documents, messages (possibly verbal), and reports through the system. Each arrow can be thought of as a pipeline through which one or more occurrences of the named flow travel.

Overview of Current System Operations

In this section of the report, we present our understanding of your current system operations.

System Participants and Interested Parties

<List the direct users and the people or departments who are affected by this system. Be sure to include their titles. Remember, this list may have changed since the project began.>

<Begin by listing all managers and supervisors, beginning with the key client contact and his/her immediate supervisor.>

1. Management - Direct Users

a. <name>, <title>

b. <name>, <title>

<Repeat the above list pattern for all management users who are direct users of the system. Next, list all non-management participants. Non-management participants include clerks, secretaries, office help, administrative assistants, any anybody else who works within the system being studied.>

2. Other Direct Users

a. <name>, <title>

b. <name>, <title>

<Repeat the above list pattern for all non-management users who are direct users of the system. Next, list the names of people or departments who may be affected by or interested in the system that will be studied and/or modified.>

3. People or Departments Affected by or Interested in the System (but not necessarily a direct user of the system) <This may include people who either provide net inputs to, or receive net outputs from, the system.>

a. <name>, <title>

b. <name>, <title>

<Repeat the above list pattern for all people or departments who are affected by the system.>

System Environment

The system we studied can be conveniently broken down into the following subsystems:

<Insert a bulleted list and brief explanation of the subsystems>

These systems are organized as illustrated in Figure <insert #>. <It is recommended that this figure be a decomposition diagram .>

System Interfaces Context. <Provide an appropriate introduction that makes references to one or more figures that depict the context of system and it’s subsystems. The intro should explain the purpose of the diagram(s). In addition, for each figure provide a brief narrative description. The narratives should only describe the system flow (most importantly, the interfaces), not analyze the system flow.>

System Data Context. <Provide an appropriate introduction that makes references to a figure containing a data model that communicates the current systems is storing data about . The intro should explain the purpose of the diagram. In addition, follow the intro paragraph up with a narrative description.>

Part II

ANALYSIS OF THE CURRENT SYSTEM

<Analyze the current system, describing and analyzing problems, opportunities, and constraints.>

<It is a good idea to also state what is “good” about the system and where the system performs well. This can help temper user/client reception to problems. Opportunities are generally better received than problems since they only represent ideas for improvement, not things that are being done wrong. FINALLY, USE TACT WHEN PRESENTING PROBLEMS. MAKE SURE THAT THE PRESENTATION IS CRITICAL OF THE SYSTEM AND NOT THE PEOPLE IN THE SYSTEM.>

Performance Analysis

<Important: Analyze all transactions. State current performance parameters. If performance problems don't exist or opportunities to further improve performance don't exist, say so. Remember to analyze opportunities for their business benefit -- that's how you determine if it's important enough to include as an opportunity.>

Transaction: <name>

Throughput: <average quantity per time period, average quantity during peak period, and average quantity during low (or valley) period - be sure to designate when peak and valley periods occur>

Response Time: <average time required to process a single transaction during normal workload period, average time to process during peak workload period, and average time to process during low (or valley) workload period - be sure to designate when peak and valley periods occur>

Anticipated Growth: <percent growth per time period>

Problem: <is throughput or response time bad or unacceptable?>

Cause: <delete if no problem>

Effect: <delete if no problem>

Opportunity: <is throughput or response time acceptable, but could be improved?>

Benefit: <delete if no opportunity>

Constraint: <is there an existing or anticipated situation that may constrain any improved system that we may recommend? if so, state rationale for not being able to change the constraint. delete if not applicable>

Possible Improvements:

<describe possible solutions to problems or ways to fulfill opportunity>

<Repeat the above pattern for all transactions.>

Information and Data Analysis

<Information analysis examines the outputs of a system. Outputs include reports and inquiry responses. Data analysis examines the data stored within a system.

Information Analysis. Information analysis initially identifies those net outputs produced by or for the system. Each output is analyzed for the following possible problems or opportunities:

Information overload. Either too many outputs are produced or outputs contain too much information, limiting their usefulness.

Information accuracy. Information contains errors or possible errors.

Information timeliness. Information is not received fast enough to be useful.

Information format. Information is in a format that is either not useful or must be modified to become useful.

Information redundancy. Multiple outputs contain much of the same information.

Lack of information. Information is not available to aid in decision making.>

The outputs are listed and identified as follows:

Output: <name>

Format: <current format>

Frequency: <how often produced>

Problem: <is the output unacceptable relative to one or more of the above problem categories?>

Cause: <delete if no problem>

Effect: <delete if no problem>

Opportunity: <do the users view the report acceptable according to the above problem categories, yet it could be improved?>

Benefit: <delete if no opportunity>

Constraint: <is there an existing or anticipated situation that may constrain any improved system that we may recommend? if so, state rationale for not being able to change the constraint. delete if not applicable>

Possible Improvements:

<describe possible solutions to problems or ways to fulfill opportunity>

<Repeat the above pattern for all net outputs.>

Data Analysis. Data analysis describes the degree to which data is redundantly stored within the system, the ease (or lack thereof) of access to data (e.g. how easy or difficult it is to produce information and outputs from the data), and the accuracy and consistency of stored data.

<Describe problems and opportunities. Examples should be stated, especially for problems and opportunities. One interesting way to do redundancy analysis is to include a "Data Analysis Matrix" as a figure. This matrix is very simple to construct. The columns are data stores (manual and computerized). The rows are data elements. Xs' indicate the elements contained in stores. Redundancy can be seen at a glance.>

The stored data are listed and identified as follows.

Data Stored: <name>

Number of records: <average>

Anticipated growth: <percentage growth per time period - typically estimate over 5 year period>

Medium: <physical storage medium>

Organization: <how are records organized?>

Problem: <is the data unacceptable relative to one or more of the above problem categories?>

Cause: <delete if no problem>

Effect: <delete if no problem>

Opportunity: <is the stored data acceptable according to the above problem categories, yet could be improved?>

Benefit: <delete if no opportunity>

Constraint: <is there an existing or anticipated situation that may constrain any improved system that we may recommend? if so, state rationale for not being able to change the constraint. delete if not applicable>

Possible Improvements:

<describe possible solutions to problems or ways to fulfill opportunity>

<Repeat the above pattern for all data storage.>

Economic Analysis

Economic analysis examines the system for cost problems (e.g. excessive costs or insufficient cost controls) or cost reduction opportunities. It can also be used to present budget constraints.

<Cost problems, opportunities, and constraints should be presented in list format. Try to estimate the current costs. For problems, try to estimate the portion of the costs that can be reduced. At the very least, describe "how" costs can be reduced>.

Problem: <is the cost excessive and unacceptable or are costs unknown or untraceable to source?>

Cause: <delete if no problem>

Effect: <delete if no problem>

Opportunity: <is the cost and cost monitoring acceptable but could be improved?>

Benefit: <delete if no opportunity>

Constraint: <is there an existing or anticipated situation that may constrain any improved system that we may recommend? if so, state rationale for not being able to change the constraint. delete if not applicable>

Possible Improvements:

<describe possible solutions to problems or ways to fulfill opportunity>

<Repeat the above pattern for all costs.>

Control and Security Analysis

Controls analysis examines how the system ensures that it is properly operating. Security analysis is concerned with both facility and data security. The system was examined both for excessive controls and lack of controls. Controls are measures taken to eliminate mistakes and tampering. Controls can also have performance implications.

<Present control problems and opportunities in list format. Be sure to describe specific causes and effects (for problems) and benefits (for opportunities).>

Problem: <are the controls and security excessive or lacking?>

Cause: <delete if no problem>

Effect: <delete if no problem>

Opportunity: <could controls and security be improved?>

Benefit: <delete if no opportunity>

Constraint: <is there an existing or anticipated situation that may constrain any improved system that we may recommend? if so, state rationale for not being able to change the constraint. delete if not applicable>

Possible Improvements:

<describe possible solutions to problems or ways to fulfill opportunity>

<Repeat the above pattern for control and security analysis.>

Efficiency Analysis

Efficiency analysis is sometimes confused with economic analysis. Efficiency analysis examines the system for problems and opportunities related to how resources (e.g. people, facilities, money, etc.) are being used. Efficiency problems and opportunities usually target resources that could be better used (not eliminated).

<Important: This is a dangerous category. Be careful not to call people "inefficient." In fact, it is often better to describe all items in this category as "opportunities," not "problems." When dealing with efficiency of personnel, it is generally appropriate to phrase the opportunity in terms of the benefit to the person whose time might be better used accomplishing other tasks.>

<Present efficiency opportunities in list format with appropriate descriptions, causes, effects, and benefits.>

Problem: <are resources being efficiently utilized? if not, is it unacceptable?>

Cause: <delete if no problem>

Effect: <delete if no problem>

Opportunity: <although the resource utilization efficiency is acceptable, can it be improved?>

Benefit: <delete if no opportunity>

Constraint: <is there an existing or anticipated situation that may constrain any improved system that we may recommend? if so, state rationale for not being able to change the constraint. delete if not applicable>

Possible Improvements:

<describe possible solutions to problems or ways to fulfill opportunity>

<Repeat the above pattern for resource efficiency analysis.>

Service Analysis

Service analysis takes on several forms. The following list is not exhaustive:

Processing and data accuracy (manual and computer). Especially for computerized systems, is data being properly edited prior to file updates?

Reliability of the system. Are transactions and situations handled consistently?

Recoverability of the system. Especially for computerized systems, is data being periodically backed up?

Maintainability of the system. Especially for computerized systems, has the system been properly maintained? Can it be maintained? How good is the documentation?

Ease of use. For both computerized and manual systems or subsystems, is the system easy to learn and use?

Flexibility. Are the situations or conditions that the system cannot handle?

Coordination. Do the people in the system appear to coordinate their activities? Do actions or decisions ever contradict? Do people understand how their fellow workers interface to their jobs?

Customer and/or employee goodwill or morale.

<Present problems and opportunities in list format. Be very specific in your presentation. Also, be tactful where necessary.>

Problem: <is one or more of the above problem categories unacceptable?>

Cause: <delete if no problem>

Effect: <delete if no problem>

Opportunity: <while currently acceptable, could it (see problem categories listed above) be improved?>

Benefit: <delete if no opportunity>

Constraint: <is there an existing or anticipated situation that may constrain any improved system that we may recommend? if so, state rationale for not being able to change the constraint. delete if not applicable>

Possible Improvements:

describe possible solutions to problems or ways to fulfill opportunity>

<Repeat the above pattern each service analysis.>

Miscellaneous Analysis

<This category is provided as a catch-all for any problems or opportunities that you want to identify. It is also the category into which most constraints should be classified. Once again, use list format but be specific. If you have nothing for this section, it should be deleted from the report.>

Part III

RECOMMENDATIONS

Recommendations and Proposal

< This section should include:

Facts about the business requirements

Define the document and data storage for the new system

Define and document essential inputs needed for an improved system

Define and document essential outputs needed for an improved system

Define and document the business processes for an improved system

Define and document the geographic support requirements for an improved system

Develop a comprehensive business requirements statement that will guide the future project phase.>

Schedule for Completion of Definition Phase

<(GANTT charts.)>

Conclusion

Briefly describe your findings, usually to confirm that the problems and opportunities are worthy of solution.>

<It is recommended that hidden text remain visible until the final report is ready to be produced. At that time, make the hidden text invisible, check spelling, go to single spacing, add page numbers, repaginate (carefully looking for widow lines and headings), print, and carefully proof the final document. Remember, impressions about your credibility are established with this report (much in the same manner as a resume' creates an initial impression with an employer).>

Appendix A

<title>