Recommended outline and guidelines for M.S. theses

Prof. Neil Rowe

Version of October 2026

Abstract (10-22 lines in one paragraph)

� Summarize the methods and results of the thesis, with particular emphasis on the methods and results.� Give some motivation for the work, but don�t write a second introduction.� Usually you need not describe prior work here unless it is really important.

� Many readers will read only the abstract and not the rest of the thesis, so the abstract should be self-contained.� Consistent with that, do not use specialized terms, acronyms, or citations in the abstract.�

Chapter 1:� Introduction (2 to 4 pages)

• Describe the need (problem) your thesis tries to address.� Convince the reader that it is important to solve (that is, motivate the reading of the thesis).� This requires finding relevant citations to publications of experts writing about the problem, and summarizing their points.� Do not just state your own opinions about why the problem is important, as experts should have a broader perspective.
• Explain why methodology, a system, or software can address this need.
• Explain why previous work (if any) hasn't solved this need, or else hasn't solved it completely.
• Explain what new ideas you had for solving this need.�
• Briefly describe the remaining chapters of the thesis.� This should usually be the only place in which you describe chapters.

Chapter 2: Previous attempts by other people not at NPS to solve this problem, and other problems like it, with computer programs or methodologies (4 to 12 pages)

• Describe other attempts to solve the problem or problems that you are trying to solve (�previous work�) using different methods than yours, by people not at NPS.� Give citations, but not names of papers, full author names, or other reference details that will be in the reference list.� Work done at NPS should be described in chapter 3.
• Generally, you need at least six examples of previous work from refereed publications (which are, generally speaking, conference proceedings, journals, and book chapters).� Web sites are usually unrefereed, so try to avoid referencing them unless they have key information (such as software details) not available elsewhere.� Key software downloads and relevant Web sites should be cited too, but they don�t count as one of the six publications.� Every publication in the reference list should have a specified author or authors; organizations can be authors too.
• Point out the key features of each example of previous work.� Usually one paragraph per reference is enough, but important references may require more.
• Describe any general mathematical background necessary for your program or methodology.� However, the specific methods you used should go in chapter 3 or 4.

Chapter 3: �More precise description of the problem you tried to solve, the general approach that your program or analysis took (3 to 20 pages)

• Describe the problems in the real world that your program or methodology will try to address.� Describe the setting of those problems, and note things that aren't done as well as they could be, either because they aren't using digital technology or they aren't using it the right way.� Focus on the problems, not the solution.
• Describe the major methods, software, and/or data you used in your work in sufficient detail so that readers can understand the rest of the thesis. This can cover work at NPS.� However, references to previous work on problems similar to yours that used methods different from yours should go in chapter 2, and details of your full experimental plan should go in chapter 4.
• Describe the specific assumptions you made in writing your program or formulating your methodology, as for instance the situations they try to address, the sort of people that will use the program or method, applicable orders and regulations that define the task environment, and so on.
• Focus mostly on to how your software or design works in its final configuration, not the steps you took in building it.

Chapter 4:� Description of your methodology or program (5 to 40 pages, plus some figures)

• Generally speaking, this chapter should give enough detail so that a reader could duplicate your work.� But if there are too many details, or you need to give lengthy detailed instructions necessary to install or run a program, those should be moved to appendices or separate �design� documents.� Minimize names of specialized software and design terms to keep your description clear.
• If you have created or modified a program, system, or methodology, say what computer your program runs on, what programming language it is written in, and what special facilities it requires.� But do not show any code (actual instructions) unless it is essential to explaining what you have done.
• Describe the input and output of your program, system, or methodology.
• If you have created or modified a program, system, or methodology, say what environment it assumes, what software it uses, and what special facilities it requires.
• Some theses focus this chapter on implementation rather than design.� If you do, understand that the word �implementation� refers to how your system is organized and what its components do, not the sequence of steps you took in building it.

Chapter 5:� Discussion of results (3 to 20 pages of text, plus 1 to 20 figures or tables)

• If your results can be quantified, summarize the performance of your program or methodology in whatever way is appropriate.� That usually includes statistics on how long it took to run or do, how much space or resources it required, and how accurate its results were.
• Use tables and figures wherever you can to simplify the discussion.� (Put actual computer runs in appendices.). Bear in mind there is a limit to how many tables and figures a reader can be expected to look at, particularly if they look similar.
• If your results are not quantifiable, discuss them and try to draw conclusions from them.� However, major conclusions should go in the last chapter.
• Discuss any insights you obtained from your data.� If your focus is on data analysis, categorize the data in a variety of ways and assess differences between the categories.
• If you experimented with more than one algorithm, program, or methodology, do the same thing above for the others.� This may be best done in separate chapters.

Chapter 6:� Conclusion (1 to 3 pages)

• State the major achievements of your program or methodology.� Try to compare your program to similar previous work.� Avoid repeating statements made earlier, and try to give a new perspective based on the results you have obtained.
• Honestly admit the major weaknesses of your program or methodology, and how they might be fixed by future researchers.

Possible appendices

� Instructions on downloading and installing software you wrote.� If third-party software was important for this thesis and was not straightforward to download and install, give instructions for it too.

� Results of test runs or examples if interesting to the reader and too big to include earlier.� If there are several types of these, make them different appendices.

� Your input data is interesting to the reader (but this should not exceed 50 pages).� But do not include programs or code, nor anything not written by you.

Note: The page minima are for theses involving programming and large experiments.� A thesis focused on concepts should have more pages than that.

General guidelines for thesis writing

Thesis writing is a form of technical writing.� Technical writing tries to convey difficult concepts, and so it needs to be especially clear compared to other kinds of writing. That means sentences should be kept short and should use the minimum number possible of specialized words.

1. A thesis should represent 360 hours of work if you have three schedule slots for it (3 quarters * 12 weeks/quarter * 10 hours/week), and 480 hours of work if you have four schedule slots for it.

2. Generative AI should be avoided for writing the text of theses because it does a poor job with creating high-level coherence in thesis-length material.� It fails to define most terms before using them, and fails to include necessary cross references within the thesis.� It also typically lacks the specialized knowledge necessary to describe technical subjects, and that knowledge is usually unsuitable for retrieval-augmented generation.� Trying to post-edit the results of generative AI is usually more work than writing it without generative AI.

3. Include the date on which you finished editing a draft of the proposal or thesis in the name of the file containing it so your advisors can tell which is the latest version of a file.� Also delete the initials of your advisors when you make the last changes to a file.� If your advisors made changes or comments in the file, make each change or satisfy each comment if you accept it, and then delete the change or comment.� If you disagree, add a comment explaining what you did (or �reply� to an existing comment).

4. Use words you would use to explain things to fellow students who are not necessarily familiar with your field.� Avoid fancy words just because they sound �academic�.� A helpful resource on improving clarity of your language is http://plainlanguage.gov.

5. Try to use the same term for the same thing; don't try to be poetic. �A name can be a word or a phrase.� Using the same term repeatedly makes it easier for readers trying to understand the technical ideas.� However, if you are mentioning the same term quite a bit, a pronoun can provide variety when it clearly has only one meaning.

6. The purpose of a thesis is to describe interesting things you did. So don't spend many pages on other people�s work unless you need it to make points about it.� On the other hand, it is important to refer to at least some related work to show you understand how your work fits into a culture of academic inquiry.� So as a minimum, you should have at least six references to refereed papers by other researchers or academics.

7. Do not assume the reader remembers something you said earlier; cross-reference instead. Technical papers are not usually read in order.� Also, avoid repeating statements since readers can page backward if they need to.� Writing is different from spoken language, for which repetition is useful.

8. Avoid one-sentence paragraphs except for numbered or bulleted items of a list.� Similarly, avoid one-paragraph sections and subsections, though an acceptable exception can be the last paragraph of chapter 1 that describes the remaining chapters of the thesis.� Combine text as necessary to avoid these situations.

9. Section and subsection titles should fit on a single line if at all possible.� Just state the broad terms� describing what the section covers; don�t give details and reasons for the section, as that is the job of the text.

10. Use past tense to describe what you did.� Use "we", "us", "our", and "ours" so you can clarify what you did; �I� and �me� are not used in academic writing.� And prefer active voice for verbs, not passive, to make clear what work you did rather than someone else.� Some examples:

a. Replace "Results in path planning were investigated" by "We investigated path planning".

b. Replace "the code that was developed" by "our code".

c. Replace "Some examples are shown in Figure 3-1" by "Figure 3-1 shows some examples".

d. Some conferences and journals disagree with this and prefer you use passive voice to sound more scientific. But in a thesis, it is more important to identify what you did.

Present tense is often OK when describing what a program or device does, or to identify what later parts of the thesis will describe.� Avoid future tense.� Subjunctive tense (e.g., �must�, �could�, and �should�) can be used for policy statements and proposed future work.

11. When you finish chapters, run the spelling corrector in your word-processing software, and then run the program in http://faculty.nps.edu/ncrowe/coursematerials/deadwood_program.zip.� This is a Python program that identifies over 18,000 instances of unnecessary wording in a text document. If you install a Python interpreter and unzip deadwood.zip, you can run deadwood.py from the command line as with one argument, the name of the text file.� It covers well-known problems like:

a. "utilize" (use "use" instead)

b. �employ the use of� (use �use� instead)

c. �employ� (use �use� instead)

d. �take advantage of� (use �use� instead)

e. �leverage� (use �use� instead)

f. �perform� (use �do� instead)

g. �be used to� (eliminate)

h. "in order to" (use "to" instead)

i. �as a way to� (use �to� instead)

j. "one of the" (use "one" instead)

k. "some of the" (use "some" instead)

l. �the entirety of� (use �all� instead)

m. "a kind of" (use "a" instead)

n. "a type of" (use "a" instead)

o. "in fact" (delete)

p. "actually" (delete)

q. �simply� (delete)

r. �vice� as a preposition (used �instead of� or �versus�)

s. �whether or not� (use �whether�)

t. �with regard to� (use �for� or �about�)

u. �for the purposes of� (use �to�)

v. �have the option to� (use �could�)

w. �have the ability to� (use �can�)

i. �are required to� (use �must�)

ii. �and/or� (use �or� since the default meaning in English is inclusive-or)

x. �a wide variety of� (use �many�)

y. �a large number of� (use �many�)

z. �a large fraction of� (use �most�)

i. �in such a way� (use �so�)

ii. �this paper� (use �this thesis�)

12. Colons and semicolons are more helpful in academic writing than elsewhere since they make it easier to see the sentence structure when conveying difficult concepts.� Try to use them when you can, but be sure you are using them properly.� Colons are used to introduce lists and closely related ideas; semicolons are like periods but where you want to group two related statements together.

13. Hyphenate a sequence of nouns functioning together as an adjective. For instance, in "large artificial-intelligence program" you should hyphenate the two middle words so a reader unfamiliar with your topic does not think you mean an "intelligence program" that is "large" and "artificial".� Some more examples:

a. computer-science department

b. Navy fighter aircraft

c. intelligent computer-aided instruction

d. ten-procedure fire-fighting program

e. problem-dependent forward-chaining Python code

f. large integrated nonbacktracking Java program

g. This means that the same sequence of words is sometimes hyphenated and sometimes not depending on whether it functions like an adjective.� For instance, you should write "I used artificial intelligence" but also "I used artificial-intelligence programs".

14. Vendors and some researchers like to invent their own terms for things that have perfectly good words and phrases already, as a way to seem more original.� Prefer to use established terms when you can.� An example is using the word �experience� for �history�, which fails to make clear that the experience was in the past and was recorded. ���������

15. Minimize acronyms as much as possible since they make a thesis harder to understand.

a. If you only need an acronym once or twice, write it out, and do not include it in the acronym list.� For example, write "NPS" as "Naval Postgraduate School" if it is only used once, or by its principal capitalized noun as "School".

b. An acceptable exception is for acronyms that are used many times in a thesis, like an acronym for the name of your subject or program that you refer to 20 times in the thesis.� Then it is acceptable to use the acronym.

c. Do not use acronyms in the title of the thesis, chapter names, or section/subsection names.� People often skim these without reading the rest of the thesis, and they cannot be expected to recognize acronyms.

d. Generally speaking, the acronym list at the front of the thesis should be no more than one page long.�

e. When you use an acronym in the text, write out its words in parentheses the first time you use it, but only the first time.

f. The plural of an acronym can be made by adding a lower-case �s� to its end, e.g. �ICSs� from �ICS� for �industrial control system�.� Do not use apostrophes in making plurals.

g. Do not make a hyperlink to an acronym table, though it is OK to have an acronym table.� Hyperlinks are difficult to navigate in PDF, your final thesis format.

16. Capitalization seems to be a problem for many students today.

a. Generally speaking, words and phrases should only be capitalized if they comprise a �proper noun� or something of which there is only one instance in the world, like �NPS�, �Python�, �Internet�, and �Web� (a shortened form of �World Wide Web�).� Names of computer programs, subroutines, and protocols are proper nouns and should be capitalized no matter what the vendor or creator does.� On the other hand, names of algorithms, parameters and fields, and disciplines like �computer science� when appearing alone should not be capitalized because there are many instances of them.

b. Although acronyms are written with capital letters, the words on which an acronym is based are not necessarily capitalized when written out, and only if the phrase is a proper noun (refers to a single instance in the real world).� �For instance, you should write out the acronym �AI� as �artificial intelligence�, not �Artificial Intelligence�, and �ICS� as �industrial control system�, but �HTTP� should be written as �Hypertext Transfer Protocol� since there is only one such protocol.

17. About fonts:

a. Commands to an operating system or software that are to be typed online should be given in Courier New font or other fixed-width font.

b. Academic usage is to avoid italic and boldface fonts for emphasis. �However, it is traditional in academic writing to use italics to define a specialized term, and boldface to give names of software objects like packages and subroutines.

18. Avoid hyperbolic (exaggerating) language (e.g. �vast�, �incredibly�, and �disaster�), emotional language (e.g. �terrible� and �peril�), and exclamation points, because academic writing tries to be neutral and objective about its subject.

19. Some nouns in English like �software�, �mail�, and �traffic� are always plural (what are called �mass nouns�) and should not have an �s� on the end.� �Data� is a usually plural mass noun, but it does have a singular of �datum� if you need it.

20. Bulleted items are good way to organize a list of resources or options.� When you use them, make sure the items are grammatically and typographically similar.� For instance, if some items are sentences with a subject and present-tense verb, then all items should have a subject and present-tense verb.� Similarly, if some items end in periods, then all items should end in periods.

21. About figures, tables, and equations:

a. Put them just after the first paragraph in which they are referenced.� If you need additional paragraphs to describe them, put the paragraphs after the figure or table.

b. All figures and tables should have a single numbered and centered caption no more than two lines long.� Captions go below a figure but above a table.� In Microsoft Word, use the �Insert Caption� under the �References� tab so Word can automatically create a list of them.� If you have more to say about a figure or table than fits in one or two lines of a caption, put it in a separate text paragraph after the figure or table.

c. All figures and tables should be referenced (e.g. �Figure 3�) at least once in the text. In Microsoft Word, use the �Cross-Reference� under the �Insert� tab and select the particular figure of table. This allows automatic creation of lists of figures and tables, permits automatic renumbering when you insert or delete figures and tables.�

d. Only include figures or tables not created by you if they are very necessary, since a thesis is intended to show your own work.

22. The Thesis Processing Office is generally unfamiliar with citations and references used in computer science, so do not necessarily follow their advice.

a. Standard citation formats in computer science and related fields are either in the APA format of parenthesized of author_last_name-year pairs (e.g. "(Rowe, 2008)") or the IEEE format of numbers in brackets (e.g. "[7]") where the number is that of an item in your reference list.� I prefer APA format in a thesis because it is clearer and more flexible, and because a reader may want to know the name of the author without having to go to the reference list.� Neither format uses footnotes, so do not use them.

b. Try to avoid reference-management tools like Zotero since they are more trouble than they are worth for science and engineering disciplines, making mistakes that are work to correct.� If you must use Zotero, note that an important mistake it makes is putting a period after the name of an author that is an organization when using APA format.

c. A citation should usually go at the end of the first sentence referring to the ideas contained in the reference, and should occur before the period ending the sentence with a space before it.� However in a long sentence, an earlier location in the sentence is acceptable and may be better.

d. Citations of papers in APA format with more than two authors should use �et al.� after a comma and the last name of the second author.

e. Citations of two or more references related to the same idea should preferably go in the same pair of parentheses in APA format, separated by semicolons.

f. Do not cite the same reference more than once in the same paragraph.� The practice in science and engineering writing is to assume that a citation refers to everything in its paragraph until the next citation.

g. Do not abbreviate names of journals and conferences in the reference list.� You want to make it easy for readers to locate the reference, and abbreviations like �Comput� can mean �computer�, �computers�, �computation�, or �computability�.

h. Technical-writing practice is not to use names of authors and organizations outside of citations and reference lists, since you should focus on ideas and not people.� Similarly, you should usually not give publication years in the text outside of citations.

i. Your reference list must be consistent with the citations.� That means that the author name you use in the citation must match exactly the author name in the reference list; do not use abbreviations in one place and not the other.� This is an easy mistake to make when organizations are authors and they have acronyms.

j. The reference list should be in alphabetical order of the first author's last name.

k. Every item in a reference list must list an author; use the name of the organization responsible as the author if no human author is listed.� Never allow a title first in the reference; Zotero has trouble with this.

l. Prefer to cite refereed publications rather than unrefereed publications.� That means that the best references are to journal papers, conference papers, and chapters in books where different people write each chapter; references to entire books are OK but not quite as good.� Avoid using Google and Google Scholar lookups to find references, as many of the results are of low quality.� High-quality references are mostly found in the ACM and IEEE digital libraries, which you can access through the NPS library site.�

m. Avoid citing Web pages as much as possible since their quality varies widely.� Avoid citing Web pages for which authors and publication dates are not listed, like Wikipedia and product sites. �An exception is that a Web page can be cited if it has the only available information about software or a concept. Avoid citing technical reports and papers from sites like Archiv and Queos that post unpublished material; you want to cite things that have been refereed.� Do not cite generative AI output.� In some cases you may get critical information just from talking to or getting email from someone, and you should cite that as a �personal communication�, but minimize such references.

n. When you have a final draft, check that every citation in your text is matched by a reference in the reference list at the end of the thesis, and every reference in the reference list is matched by at least one citation in the text. �The Deadwood programs can check for this automatically.

23. The plagiarism checker run by the Thesis Processing Office (currently IAuthenticate) flags word sequences found elsewhere online.� It is overly suspicious, and you do not need to change everything it finds.� Standard definitions, names of organizations, names of documents, statements of statistics, and short strings do not need to be changed.��

24. Minimize quotations and graphics from other people; more than five quotations in a thesis is usually too much.� A thesis is supposed to be original work, and if you are quoting other people or copying their pictures, you are not doing original work.� It is better to paraphrase.� If you do use quotations, enclose them in quotation marks and give a formal citation at their end.� This is important because universities treat plagiarism seriously. �Also try to avoid using other people�s figures since plagiarism can involve figures too.� But you can make an exception for a few figures that are difficult to draw yourself if you cite them properly.

25. You may need to refer to software products, but you need not believe everything the producer says about their product.� Subject their claims to the same scrutiny as any scientific hypothesis.� If they claim the product is fast, effective, or easy to use, try to test it and report what you discovered rather than repeating what they said about it.� You also do not need to follow nonstandard punctuation of products, if it violates the usual rule of capitalization of proper nouns, so use �IPhone�, not �iPhone�.

26. Programs you wrote go in appendices.� Detailed output, figures, and tables that would make the results chapter too long also should go in appendices.� Appendices should not contain programs or documents that someone else wrote.� Appendices should be limited to no more than fifty pages.

27. Changes and comments entered into your thesis document by your advisors and readers should be deleted once you have answered them if you agree with them.� If you disagree, keep the original change or comment and write your own comment after it about why you disagree.

28. Repetition is a thesis is bad; use instead a cross-reference to the first time some concept is expressed.� Unlike in spoken language where it is useful to repeat concepts introduced earlier, academic readers can be expected to skip around in reading a thesis, so they do not need repeats.

29. You have a choice of explaining a program or architecture top-down (wholes to parts) or bottom-up (parts to wholes).� Chapters 1 and 2 are usually top-down, but chapters 4 and 5 are usually bottom-up.� That means chapters 4 and 5 should first describe the necessary details like data input and experimental setup to understand the rest of the chapter, then describe the processes used or followed.

30. Most thesis advisors and second readers only want to read and edit a chapter twice: Once by itself when you first write it, and once again when the entire thesis is complete, to check for consistency.� Do not submit partially written chapters.� Run the spell and grammar checkers on your material, and the deadwood program if your advisor wants you to use it, before submitting it to advisors.

31. Do not assume that once a thesis is checked and edited by your advisors or the Writing Center that it is fine.� It takes multiple passes to fix a thesis.� Check everything yourself after others have looked at it.� Important things to check on the final draft are extra words, missing words, whether every citation has a reference, and whether every reference has a citation.� Also check for missing definitions of terms, something you can often only see when you have assembled the entire thesis.� Other things to check for are missing explanations, unnecessary repetition, captions too short, and overuse of acronyms.

32. The Thesis Processing Office and the Writing Center only make suggestions.� Your advisors and second readers can overrule them.