This provides guidelines to assist students in writing a project report if they elected to complete a project classified as Project Type #1 through #5 (see the Guidelines for Completing The Design Project in lieu of Thesis for the Masters of Science, Major in Computing & Information Systems document available on the web site).

This section provides guidance on preparing the written project thesis report.  The material provided in this section is NOT applicable to all projects.  It is your responsibility to select that material which is appropriate.  For special project situations, the material in this section may be totally irrelevant.  You can receive guidance on this from your committee chairperson.

The guidance herein specifies where it is appropriate to apply various information systems design techniques and tools to the project work effort.  Most design projects generally follow the traditional the systems development life cycle.  Similarly, the project report will generally contain five chapters which relate to the five phases of the systems development life cycle.  These are: Chapter 1. Feasibility Study; Chapter 2. Detailed Analysis; Chapter 3. Logical Systems Design; Chapter 4. Physical Systems Design; and Chapter 5. Systems Implementation.  This format may be altered as necessary to match the nature of the project, especially for projects involving the application of specialized information systems technology.  Each chapter is divided into sections which describe the typical topics and the extent of topical coverage appropriate for each section and chapter.  This guidance should not be construed to be limiting.  The inclusion of any or all of these topics will vary depending upon the nature of the design project. Similarly, the extent of topical coverage will vary.  The guiding rule is that the discussion of any given topic must be adequate for a trained CIS professional to completely understand the discussion.  Further, you must write the report such that there is a logical transition from one topic to the next.

The report may contain appendices where appropriate.  Examples of appendices are: application program code, screen designs, report layouts, database logical and physical definitions, data dictionaries, end-user training manuals, systems technical manuals, and other compendia as necessary to fully document the design effort.  A list of references (sources to which you refer in your project report), should be provided after the end of your last chapter and prior to any appendices.  Appendices should be numbered sequentially and be accompanied by an appropriate descriptive title.

You should present the chapters to your committee chairperson as the project is completed.  A common mistake, especially where actual coding or physical design work is being accomplished, is for students to "hurry up and get started writing code." This usually results in much wasted effort because such students may fail to develop an adequate logical systems design.  You are on the safest ground if you receive approval from your committee chairperson for the work completed at each phase prior to continuing with the project. Occasionally, a committee chairperson will be startled by a student who walks into the faculty members office and delivers the "completed" project report while announcing that "I have accepted a job and must move in the next few days."   Sometimes the Chairperson has not received even a draft of the report prior to this announcement. Such students may well be disappointed to find the project unacceptable and their degree incomplete.  We have had students actually leave the country without completing all degree requirements.  As in an operational information systems department where you are responsible to your supervisor to manage projects properly, we will expect you to manage your Master's thesis project to successful completion.
 

Background.

This section describes the environment in which the project is being designed. This section should illustrate the nature of the work system and will provide valuable information that is relevant to understanding the nature of the design problem.  Avoid the inclusion of facts which are irrelevant.  Tools which may help with the background description may include one or more organizational charts, figures, and various tables.  Organizational charts should only be provided whenever they assist in describing the environment and are relevant to understanding the situation.  Avoid including charts, figures, and tables where they serve no useful purpose. The background section is generally 1 to 3 pages in length.

Problem Description.

Use this section to describe the problem in sufficient detail for the reader to understand fully the basic requirements of the potential information system for end-users. It may be helpful to state the requirements in the form of a table. Your description should identify the components of the work system in which the information system will be one of the components. Additionally it may be helpful to identify other relevant information, for example potential pitfalls that need to be avoided or the nature of the computer skills or computer literacy level of potential end-users. This section will average two to five pages and may include figures and/or tables.

System Constraints. 

It is important to identify and describe constraints under which the system must be developed.  For example, an end-user may specify that the system be built using software technology and/or hardware components that the firm has already acquired.  As another example, small firms or individual departments within a university or college may specify that no money is available to support the project.  These may or may not be constraints within which you can work.  It is your responsibility to determine if the system can be reasonably developed within the constraints established by the end-user.  As you should realize, it is usually not possible to build successful systems when constraints are unreasonable. If you determine that the constraints are unreasonable, you should seek an alternative project.

Time is often a constraint. A local firm may specify that the project be completed by a certain date. This constraint applies only to delivery of the system -- not to your completion of the project requirements.  If a firm establishes a three month limit on a project and you elect to take on the project, this does not mean that your faculty committee will allow you to stop work at the end of three months. Regardless of the firm's time constraints, you must demonstrate Master's level competency.  If you cannot successfully complete the project requirements in three months, then it is your fault for having accepted the project.  Like any other type of constraint, if a time constraint is unreasonable, it is your responsibility to consider the selection of an alternative project.  Constraints are usually best presented in the form of a table.  The constraints section is usually limited to two to three pages.

Initial Feasibility Conclusions.

In this section you present an argument explaining why the project is amenable to computerization and why you feel that the project effort will be successful. You do not need to present detailed qualitative or quantitative cost benefit analyses; rather, you present a discussion which weighs the requirements of the end-user against the constraints of the situation.  If the project is not amenable to computerization, then the project is not acceptable for meeting the capstone course requirement.  This is generally a one or two- page section.  By completing this chapter, you have accomplished several objectives. You have produced a convincing document which can be presented to faculty members as evidence of your ability to judge the worth and feasibility of a design project.  You have also completed the first chapter of your project report.  During successive phases of the project, you should document your work by writing the relevant chapters as the work is completed.  A common mistake is to wait until the bulk of the project is completed before beginning to write the thesis report.  It is patently obvious to the faculty whenever this occurs because the report tends to lack the richness of detail that is produced whenever the report is prepared throughout the course of the project.
 

This chapter has multiple purposes. First, you will provide a detailed description of the existing work system in which you must operate. The work system may or may not include an existing computerized information system. Second, you identify and evaluate potential alternative system design options. Finally, you conclude by selecting a system design option.

Work System Description.

This section, if required, will provide a more detailed description of the overall work system than that given in Chapter 1. You may find, however, that your description in Chapter 1 is adequate. If included, this section will vary from one to four pages.

Existing Information System Description.

It is becoming rare to find a situation where an existing information system of some type or other does not exist to accomplish work tasks.  The system may be totally manual or may include an existing computer-based information system technology. Describe the system in detail.  Tools appropriate to this task include Data Flow Diagrams, Warnier-Orr Diagrams, and Data Structure Diagrams, among others. You are responsible to select the tools which are appropriate. Do n t include a figure simply because you feel that the faculty expects one -- the faculty do not have a priori expectations except that you will include whatever is appropriate to the task. Where figures are used, the figure must be accompanied by a thorough textual explanation. You may, for example, find it necessary to provide multiple level data flow diagrams. You should explain the top level diagram, then present lower level diagrams with their accompanying description.  Figures should be located within the document close to the point where they are discussed.  Generally, you either embed the figure within the document, or where a figure must be placed on a separate page, you p lace the figure on the page immediately following that where it is initially discussed.  This section will vary from four or five pages to as many as 20 or 25 pages in length.  The norm is about six to 10 pages.

Problems with the Existing System.

In this section you outline critical problems and shortcomings of the existing information system. This may best be accomplished by using a tabular format to list the problems. Provide an explanation as to why the problem is important. This section is usually one to three pages in length.

Alternative System Design Options.

Briefly outline at least two alternative system design options.  Do not arbitrarily restrict your list of alternative design options to a particular number -- you will be evaluated on your ability to identify all reasonable design options.  Describe each alternative in sufficient detail that the reader will adequately understand the nature of the alternative.  In an operational computing environment, one alternative is always to keep or improve upon an existing manual system. Since this design project must, by definition, involve the use of computer-based technology, this particular alternative is not acceptable as one of the two minimum alternatives.  As a Master's candidate, you should be capable of creativity with regard to systems design; therefore, you should experience no difficulty in identifying alternative design options that do not include the maintenance of an existing manual system. Examples of acceptable alternatives are too varied to list.  Usually they vary with respect to the degree to which a work system is computerized. We do, however, provide an example of a set of unacceptable alternatives.  Sometimes students identify different alternatives based on a variety of available physical design tools/programming languages.   These alternatives are unacceptable because they do not really represent alternatives.  This section varies from one to three pages in length.

Evaluation of Alternative Solutions.

In this section you provide a quantitative or qualitative analysis or both for each alternative design option.  As a result of this analysis, you may discover that a particular alternative, although attractive, is not feasible because of a previously identified constraint set by an end-user. This is perfectly acceptable. Your analysis will result in your selection of the best, feasible solution.  A commonly used quantitative analysis tool includes the traditional cost benefit analysis. A common mistake is to analyze only the selected design option.  It should be patently obvious that the purpose of the analysis is to aid in selection among the options.  If you analyze only one option, then the cost benefit analysis serves no useful purpose.  Another typical mistake in completing a cost benefit analysis is to create dollar figures that appear to arise out of thin air!  This results whenever the analysis is based too heavily upon assumptions.  For example, you might assume that a secretarial labor rate is $8.00 per hour. This, however, is an unacceptable assumption when it is fairly easy to research actual secretarial labor rates.  As another example, you might assume that an alternative will save 10 hours per week.  You can expect the faculty to ask how you determined this particular savings rate just as your supervisor would question the figure in an operational Information Systems department.  If you cannot fully justify the figures used, then the analysis is worthless. Just as you would expect your supervisor to look unfavorably upon such poor work, so will your Chairperson send you back to rethink and rewrite your analysis prior to proceeding with the project.

It is rare for a cost benefit analysis to be the only means by which alternative design options are evaluated. Qualitative factors often weigh heavily on an alternative selection decision. Qualitative factors may best be presented in tabular form. For example, you might list end-user qualitative requirements down the left side of a table and list the alternative design options across the top, thereby creating a matrix type table which can be used to indicate the degree to which a specific alternative design option satisfies a qualitative factor. The length of this section varies with the number of tables or figures included. A common length is four to eight pages, although both shorter as well as longer analyses are common.

Selection of a Design Option.

This section is usually a short one or two page discussion where you weigh the relative merits of the design options in light of your analysis and selection the best feasible option.
 

This chapter describes in as much detail as possible the logical system design. This may include a description and figure examples of screen designs, report layouts, data structure diagrams and accompanying database file structures and data dictionaries, program hierarchy charts, data flow diagrams, as well as other design tools.  As before, the tools selected should be appropriate to the task.  No a priori list of required figures or diagrams exists.  We do not attempt to describe the contents of this particular chapter since it will vary considerably from project to project.  We merely advise that your report of the logical design description should flow in a logical manner, for example from a general to detailed description or from a logical abstract description to the resulting detailed specific design details.

Table 2 provides a partial checklist of items to consider in completing the physical design.  Often students have difficulty categorizing project tasks as either logical or physical.  As a general definition, physical tasks as those which involve the use of a computer language or design tool to create part of a working information system based upon previous planning of the task during this logical design phase; therefore, the layout design of a computer screen or menu is clearly a logical design task.  Actually developing the computer code or using a tool to implement the screen design is a physical task.  With the use of CASE tools, it becomes difficult to categorize a particular task.  For example, the screen design mentioned above seems to be a logical task, but is it still a logical task when the screen is simultaneously designed and generated through the use of a CASE tool?  In fact it is.  Place the material within your report by using common sense in the absence of other guidelines.  As a general rule, all logical design tasks should be completed prior to the initiation of any physical design tasks.  In practice, however, where a large project is being developed by a design work team, the project tasks may be subdivided in such a manner that some physical design tasks are initiated prior to completion of the logical design for the entire project.  Even in this case, all logical design tasks related to specific physical design tasks must be completed and approved prior to initiating the subsequent physical design tasks.  To do otherwise may result in wasted physical design efforts since the logical design is subject to change.

TABLE 2

A Logical Design Task Checklist

1. Have you identified required software packages and hardware components as well as the intended acquisition source?

2. Are all: -file layouts designed? -database files designed where appropriate? -report layouts designed?

3. Have you completed computations to insure that the hardware off-line storage components are sufficient for file storage, especially where the system will operate on a microcomputer or server in a client-server environment.

4. If the system includes batch processing, are all: -error conditions and appropriate error processing procedures specified? -audit trail procedures specified? -security procedures specified?

5. If the system includes interactive processing, are all: -menus and other screens designed? -interactive processing procedures specified? -error conditions and appropriate error processing procedures specified? -common processing procedures identified? -audit trail procedures specified? -security procedures specified?

6. If the system involves processing on a computer-based communications network, are: -additional software and hardware components identified and an acquisition source specified? -additional security procedures specified?

7. Have you written specific backup and storage procedures?

8. Have you specified recovery procedures in the event of a system failure?

There is no typical length for this chapter. Lengths vary from as few as ten pages to as many as 25 pages not including accompanying figures and charts.  Usually screen designs or data dictionaries are included in appendices.  Data flow diagrams or data structure diagrams are usually embedded within the chapter for ease in reading the document.  You may wish to discuss the placement of logical system detailed figures and diagrams with your committee chairperson.
 

Most project reports include a physical systems design chapter as it is usually necessary to specify a physical design test plan.  In describing the physical design of the system, this chapter may be divided into two sections. The first section focuses on the programming or code generation tasks.  For certain projects, such as a situation where you are implementing a system using a software package, you may not require this first section. As before, you are responsible for determining whether or not it is appropriate to exclude a particular section from the thesis report.  The second section of this chapter explains the system test plan.  Due to differences in design projects, there is no normal expected length for either of the sections of this chapter.

Programming/Code Generation Tasks.

The primary tool used to control and describe these tasks include system hierarchy charts, program hierarchy charts, and project control tools such as Gantt charts.  The system hierarchy chart can be used to describe the order of development of programs or program modules which comprise a system.  Upper level programs or modules are normally developed first.  It is also common to develop modules which are common to multiple programs very early in the physical design phase.  Similarly, a program hierarchy chart can be used to track the completion and testing of program modules.  Another approach is to divide the physical design tasks among project team members where a work team is involved.  In this type of project it is necessary to describe your reasons for dividing the project tasks and the extent to which you feel this was ultimately successful or detrimental to project success.

Newer software development tools, such as Visual C++, Visual Basic, and PowerBuilder require documentation that follows an object-oriented perspective.  The course work you completed in these areas will provide textbooks that describe current object-oriented documentation techniques.

System Test Plan.

It is acceptable to include this section either here in the physical design chapter or earlier in the logical design chapter.  The actual development of a systems test plan is a task that ordinarily is accomplished as soon as the logical design is complete.  Thus the development of a test plan falls within a fuzzy area with regard to whether it is a logical or physical design task.  We place it here because the test plan is normally updated and modified as the physical design phase proceeds. T he actual testing of a system is normally spread throughout the physical design phase and does not usually occur as a single task.  Developing an adequate test plan is a common weak area for Master's projects.  If you fail to test a system adequately, the end result is usually an information system which abends shortly after implementation.  This reflects poorly upon the CIS program as well as yourself.  This is to be avoided.

The test plan must identify a method for adequately controlling and testing all components of the working information system.  This means testing not only computerized processes, but manual processes as well.  In testing manual processes, it is advisable to include end-users in the test plan.  In testing computerized processes, you must identify a subset of data that is sufficient to test all program modules. Further, where multiple programs comprise a system, the plan must specify the testing of the modules in all possible combinations of execution. You should also plan the method to be used to correct errors found in computer code or other areas of the physical design.  In some cases, it is necessary to loop back in the system development process to an earlier phase, such as the logical design phase and rework part of the logical design.
 

This chapter includes a description of the system implementation plan and implementation results, a discussion of the end-user training plan, and a post-implementation analysis of the successes and failures of the information system and project.

Implementation Plan.

Describe the implementation plan including the amount of time required for implementation, the problems that were encountered, and the implementation approach (immediate, phased, or overlapped) that was used. Justify your selection of an implementation plan.  This section will generally vary from two to three pages, but may be longer as needed for larger projects.

End-User Training Plan.

Discuss the procedure used to train end-users.  Describe the effort in terms of the number of hours or days required to complete the training, and the method used for training (hands-on, lectures, computerized training modules, etc.).  How effective was the training?  How will end-users be trained on the use of the system as new individuals are hired by the firm?  Other information may be provided as appropriate.  If an end-user training manual is written as part of the project, you may elect to include it as an appendix.  This section is usually one to four pages, but may be longer as required.

Post-Implementation Analysis.

This section will vary from two to six pages as necessary.  Every system should have a post-implementation audit, even if it is conducted only a few days after project implementation.  Explain the audit procedure used for this project and your findings.  This section also serves as a place for you to describe on lessons learned during the course of the project.  By reflecting back on the project, you will be able to identify successes and failures which you encountered.  Elaborating on these successes and failures will help you learn more from your project experience.  Your written record may enable some future reader to profit from your experience.  What unexpected problems were encountered and how did you handle them?  What techniques were particularly useful to you as a prospective project team manager and why?  Which techniques were not useful and why? You can best determine which questions are appropriate to your specific project.  Do not hesitate to describe the strengths of your approach t o the project.  While we can learn from our mistakes, it is often more important to remember what was done correctly and why it worked.

END OF HANDOUT