If you are about to embark on the task of developing a Master's thesis in Computer Science, then this document may be of interest to you. The scope of this document is very narrow and deals only with certain features of thesis development that are unique to the field of Computer Science. For more general information, you should consult sources such as Strunk and White's Elements of Style, Turabian's Student's Guide for Writing College Papers and the UoA Guide to Theses & Dissertations.
Before we get into the heart of the matter, you should ask yourself if you have the background and skills required to successfully complete a thesis in Computer Science. The next section lists some of the skills you will be expected to possess.
While there are no hard and fast rules that guarantee you have the background and skills required to complete a thesis in Computer Science, there are some indicators. Here is a list of some of these indicators.
Most theses in Computer Science consist of two distinct parts: (1) writing a significant program, and (2) writing a thesis that describes your program and why you wrote it. The intent of this document is to guide you in how to do these two things. Of course, you will need to have taken certain courses, read certain books and journal articles, and otherwise perform some basic research before you begin writing your program or thesis. If your thesis does not involve writing a program, but is theoretical, you can skip to section 3.
Presumably you have a thesis topic, and it is time to start developing a program that will implement or demonstrate your ideas about this topic. You have learned how to write programs in previous courses, but usually the program you will write for your thesis is more involved than other programs you have written. Thus, it is important to use good software engineering techniques.
The requirements document explains what your program is to do. Often the requirements will be quite vague. For example, ``the system must be fast,'' or ``the system must be user-friendly.'' You'll want to write a set of requirements that can serve as a contract specifying what is expected of your program. What's in a requirements document? Abstractly, the answer is very simple: a statement of valid input to the program and a statement of the corresponding output. Your software will operate on some data and derive computed data. The requirements document will clearly state what the input data and output data will be. The requirements document tells what your program will do from the user's perspective.
The specification document explains what the requirements are, but more precisely than the requirements document itself. It restates the requirements from the point of view of the developer. The specifications are explicitly and precisely stated. They are statements that you can design to and test for. Essentially, the specifications define a function from the set of all possible data input to the data output by your program.
The preliminary design document explains how you are going to fulfill the specifications. It is written before you write the program and should include a list of algorithms you will use, major data structures, a list of major functions, their inter-relationships, and the steps you will use to develop your program. Stepwise refinement and information hiding concepts should be used in developing the program, producing a detailed design document.
You will probably choose to use an established software engineering methodology, such as UML, and a CASE tool, such as Rational Rose, to help you with these tasks.
Additional documents are sometimes required for a program. These include a user's manual, a maintenance manual, and a test suite. Often these will appear as appendices in your thesis. The user's manual describes the user interface to your program. The maintenance manual describes how to change, augment, or port your program. The test suite offers some validation that your program will compute what was intended by describing test procedures and sample test inputs.
Most likely others will use your program. Writing a good user's manual will facilitate the use of your program. The important thing is to write for the naive user. It is best to assume that users of your program will know nothing about computers or their interfaces. A clear, concise, step-by-step description of how one uses your program can be of great value not only to others, but to you as well. You can identify awkward or misleading commands, and by correcting these, develop a much more usable product. Start from your requirements document to remind yourself what your program does.
If your work has lasting benefit, someone will want to extend the functionality of your code. A well thought-out maintenance manual can assist in explaining your code. The maintenance manual grows from your specification, preliminary design, and detailed design documents. The manual shows how your program is decomposed into modules, specifies the interfaces between modules, and lists the major data structures and control structures. It should also specify the effective scope of changes to your code.
How will you guarantee that your program meets its specifications? Formal verification is one ``proof'' technique, but it can be difficult to apply for large programs. You should be familiar with verification techniques and use them as you develop your code, but others are still going to want to see that your code gives expected results on a sample of test cases. Thus, you should develop a test suite that can be used to show your program works correctly under a variety of conditions by specifying testing procedures to be used and a variety of test cases to ``exercise'' the components of your program.
Your thesis documents your work and may serve as a basis for a publishable conference or journal paper. The most common mistake made by thesis students is to assume that the thesis itself will be easy to write. Consequently, they postpone writing until they have completed their programming. Important advice is to start writing early and ask your thesis supervisor for feedback on your writing. Equally important, do not plagiarize. Plagiarism can result in expulsion from University. You are expected to write your own thesis, not copy from what someone else has written. It is okay to use other people's ideas, even their own words, but you must clearly reference their work. Your thesis should describe what you did and why you did it.
Everyone makes spelling mistakes, but with spelling checker programs available this type of error should be eliminated. Always run your written work through a spelling checker before you ask someone else to read it. Also, you should find someone who can correct grammatical mistakes in your paper. If necessary, you can hire someone to proof read your work before you give it to your supervisor.
Also, use a professional document preparation system, for example, LATEX, troff, or Word, which allows you to print your document on a laser printer. There is an F.I.T. thesis style file that has been developed for LATEX, which will produce correct margins and other formats, plus automatically handle many details in the preparation of your thesis.
You MUST follow the instructions in the UoA Guide to Theses & Dissertations when formatting your thesis.
You will begin writing your thesis the first half of the first semester you are enrolled for thesis credit. You should write a thesis proposal that evolves into your thesis. Writing a good proposal is an important first step to success. Proposals will differ, but there are certain things that can be expected to be found in every one. There needs to a statement of (1) the problem to be studied, (2) previous work on the problem, (3) the software requirements, (4) the goals of the study, (5) an outline of the proposed work with a set of milestones, and (6) a bibliography.
The top-down approach, which is recommended for program development, carries over to the development of your thesis paper. Here, you should begin with an outline of each chapter. Although it is difficult to specify what should be included in each chapter of a thesis, the following outline is fairly general.
Your finished thesis must include a title page, signature page, abstract, and
bibliography.
See the UoA
Guide to Theses & Dissertations preparation for details.
Make sure you all ollow the ma formating instruction exactly.
You should be proud of your work and want others to know about it. One way to show that you have done quality work is to present it at a conference. Thus, you should write a short 5-10 page paper that concisely explains what you did and why it is new or important. This paper can then be submitted to appropriate conferences or even to a journal. The research you have done should provide you with a list of conferences and journals to which you can submit your work and you should discuss the possibility of submitting your work to a conference with your supervisor. Even if your work is not published you can include your paper in your thesis as an Appendix.
Below is a quick list of the guidelines that have been discussed in this document.