Writing a Culminating Experience Report (CER)

In this section we will outline what constitutes an outstanding culminating experience report (CER) whether it is Thesis or a Project; what constitutes unacceptable one; and also outline our general recommendations for the CER outline and content of each chapter. The focus here is on the write-up part of the CER, namely how to communicate it in the written form (i.e. CER), and not on the culminating experience project itself. Please note that the final decision and guidance on this comes from your Culminating Experience Committee Chair and committee members, but we believe that the material in this section is general enough to set you on the right path. Finally, we will reiterate some recommendations on your oral presentation of CER.

More details on what kinds of CER exist (Thesis or Project) are located at: Department M.S. Culminating Experience Requirments Web Page.

Steps in completing the Culminating Experience are located at: Department Writen and Oral Defense Information Web Page

To help you improve your writing skills, all of our students are encouraged to take an online writing course such as the one offered through Coursera at Stanford Univeristy, titled "Writing in the Sciences" offered during the Fall semester. For more information: Stanford Writing in the Sciences Course Information Web Page

Very good resources on how to write technical reports are here:
Colubia Web Page: Writing Technical Articles
Columbia Web Page: Common Bugs in Writing

Before we start, let us reiterate that completing culminating experience (both the project and the report) is primarily the responsibility of the student and hence the student has to drive it. It is not expected from the faculty to fully participate in writing the CER or in very extensive editing except to give necessary feedback and comments. We strongly recommend that high level CER outline be agreed between student and faculty before the writing commences.

Let us first see what constitutes an outstanding CER and what constitutes an unacceptable CER. While the definitions below touch upon the project work itself, please focus for now on the suggestions that refer to the ways on how to write about it.


What constitutes an outstanding CER?

(Adapted from AAUP Rubric for Dissertations but we believe it also applies to CERs). Note that outstanding CER should have many but may not have all of these satisfied.

  1. Is original and significant, ambitious, brilliant, clear, clever, coherent, compelling, concise, creative, elegant, engaging, exciting, interesting, insightful, persuasive, sophisticated, surprising, and thoughtful.
  2. Is very well written and organized
  3. Is synthetic and interdisciplinary
  4. Connects components in a seamless way
  5. Exhibits mature, independent thinking
  6. Has a point of view and a strong, confident, independent, and authoritative voice
  7. Asks new questions or addresses an important question or problem
  8. Clearly states the problem and why it is important
  9. Displays a deep understanding of a massive amount of complicated literature
  10. Exhibits command and authority over the material
  11. Argument is focused, logical, rigorous, and sustained
  12. Is theoretically sophisticated and shows a deep understanding of theory
  13. Has a brilliant research design
  14. Uses or develops new tools, methods, approaches, or types of analyses
  15. Is thoroughly researched
  16. Has rich data from multiple sources
  17. Analysis is comprehensive, complete, sophisticated, and convincing
  18. Results are significant
  19. Conclusion ties the whole thing together
  20. Is publishable in top-tier journals
  21. Is of interest to a larger community and changes the way people think
  22. Pushes the disciplines boundaries and opens new areas for research
  23. Provides relevant referenced material with proper credits (work of others)
  24. Outlines clearly the benefits to users and motivation (market needs, use cases, user testimonials etc.)
  25. Proves the claims either theoretically or experimentally or by doing usability analysis (whichever applies)


What is unacceptable CER 

(adapted from the same source)

  1. Is poorly written
  2. Has spelling and grammatical errors
  3. Has a sloppy presentation
  4. Plagiarizes or deliberately misreads or misuses sources
  5. Does not understand basic concepts, processes, or conventions of the discipline
  6. Lacks careful thought
  7. Looks at a question or problem that is trivial, weak, unoriginal, or already solved
  8. Does not understand or misses relevant literature
  9. Has a weak, inconsistent, self-contradictory, unconvincing, or invalid argument
  10. Does not handle theory well, or theory is missing or wrong
  11. Relies on inappropriate or incorrect methods
  12. Has data that are flawed, wrong, false, fudged, or misinterpreted
  13. Has wrong, inappropriate, incoherent, or confused analysis
  14. Includes results that are obvious, unexplained, or misinterpreted
  15. Has unsupported or exaggerated interpretation
  16. Does not make a contribution
  17. Does not give proper references to the relevant work (be war: plagiarism is very serious offense)
  18. Claims of usefulness, ease of use, accuracy, speed etc, not substantiated with proofs such as experiments, performance analysis, usability analysis


Suggested CER Outline

Here we outline some general ideas about the outline and composition of CERs. Again, your advisor has the main influence here, but what we present is a good start. Our recommendations here are substantiated with our experience of reading many CERs for the last several years and observing some problem patterns that need correction. Note that section titles should not be taken literary but adapted to your project. Your CER may have all or subset of the above items (each CER must have abstract, introductions and conclusions though). Proper formats as specified in SFSU bulletin also must be followed. For each section we provide minimum information that we believe should be addressed. The rest will depend on your particular project and input from your advisor. As said before, we strongly recommend that high level CER outline be agreed between student and faculty before the writing commences.

Our suggestion is that the CER write-up should be self sufficient and readable to a person with average knowledge of computer science who is not an expert in your particular area. Thus, the CER has to contain all the necessary motivation and definitions (except very basic computer science terms) as well as explicit list of your contributions. (Note, the CER is about what you have done so it perfectly OK and in fact necessary to be very clear and up front about it). For detailed content of CER, please consult your Committee Chair and see our suggestions below.

We will now outline major sections of CER with brief description of what each section should contain at minimum. Note that your section titles may vary although all CERs have to have Abstract, Introduction, and Conclusion.

Please also make sure to follow all the proper and required formats as specified by SFSU.


1. Abstract

Abstract is in a way a short form of introduction section (see more on introduction below). It is limited in size, and for CER it is up to one page. The role of abstract is to efficiently inform and motivate the prospective reader so it has to contain: motivation, description of the problem addressed, what was done and what is so special about it. Treat is as your “home page”, “store window” or “executive summary” whose purpose is to attract and motivate the reader to read your report. We suggest that the abstract be written at the end. For CER abstract should be reviewed and then submitted to CS office by CER Committee Chair.


2. Introduction

  • Motivation: why is this work important (can be intellectual curiosity, marketing/business need, need to solve an important problem irrespective of any business value (environment, health etc.), useful SW application etc.).
  • Very brief description of what was the problem and what was done as well as approach taken. Mention whether you invented something, whether you implemented and tested it, how did you prove that it worked (theory, experiment, performance analysis etc.)
  • Very clear outline of specific contributions and what is special or unique about it. Examples: is the developed method or system the fastest, or offers unique functionality, or easiest to use etc. This is often forgotten, probably because students believe that their report will be read only by those familiar with their work.
  • How this compares with work of others or state of the art in the area
  • Outline of the rest of the report i.e. content of each CER scetion


3. Theory or Requirements or Problem Statement

  • Explain the problem you are solving in detail and how important it is. What are the key unsolved issues not resolved until now (speed, accuracy, precision, new application…)
  • What was the approach used (high level). For complex systems, explain at high level the overall algorithm used so that reader can get overall idea. You can use block diagram, pseudo code, UML etc. Use the most appropriate means to explain the solution at high level.
  • Some projects need theoretical foundations here, some need use cases and requirements etc. Use what applies to explain how you identified the problem and how you came up with your solution.
  • Explain why you did what you did, what were the tradeoffs and what are pros and cons of your solution


4. Literature Review or Relevant Work

  • List the relevant works (including one from SFSU like past CERs)
  • Comment and compare how your work relates to the referenced ones.


5. Implementation, Design or Methods

Here you should explain in detail what was designed and developed and how. In most cases it is very useful to present pros and cons and tradeoffs that influenced the design. For algorithmic contribution state the algorithm clearly and provide some measures of goodness. For SW oriented projects explain the flow, UI, architecture and SW complexity as well as the SW infrastructure and tools. For performance contributions explain how you identified the bottlenecks and how you achieved improvements etc.

For SW oriented project a section outlining what SW Engineering methodology was applied can be very useful.


6. Experimental Results and Analysis; Or Evaluation

Every claim made in your work has to be proven in an appropriate way. For theoretical works this is mathematical proofs or complexity analysis etc. For SW oriented projects this can be user testimonials, the fact that the SW is used in real life, usability assessment etc. For performance oriented work it is performance measures. For projects dealing with providing some new methods of measurement or decision making (i.e. in AI, search) it is the accuracy, false negatives, false positive ratios etc.

Be sure to explain: a) the evaluation metrics (what measures were used to evaluate); b) the methods used (e.g. what instruments, HW or SW, what test databases, how was the “ground truth” established etc.); and c) the results themselves.

Please provide some analysis of results that is understood clearly to an average CS educated person. Just providing many charts is not enough.


7. Conclusions and Future Work

First repeat what was the problem you were solving, motivation and then your contributions.

Then outline work that you believe should be done next, and try to prioritize it.


8. References

Here you list all the relevant work that you used. Each item mentioned here must be referenced in the text. Be very careful to reference ALL relevant work you used (even private communications), otherwise you are going into forbidden territory of plagiarism. If in doubt, cite it. Use the approved formats here and in the text of the CER when you refer to citations.


9. Appendix

Here you can put some material that has background value such as supporting data and images, charts, UI screens not shown in the main portion of CER, mathematical proofs, detailed algorithm descriptions, data definitions etc.

We do not recommend using this for source code printout, please do it on the CD ROM.


A word on oral presentations for Culmination Project defense

Please note that the purpose of your oral presentation of the Culminating Experience is to defend your work and not to educate the Committee about the subject in a general sense. Therefore you have to clearly explain the problem you worked on and to list all your contributions. As in the CER, it has to be clear:

  • Why you undertook this work
  • What have you done

Now, as in CER, do not assume that all members of the audience know about your work, so introduce it clearly and cover all the basic assumptions and definitions.

The oral presentation generally follows the outline of the CER. However, one strategy, often overlooked but very effective, is to do an early brief demo (usually after the first few slides). The purpose of this is to explain to audience early on what is the problem and what you have accomplished, and then go into details. This can save you a lot of time in answering some basic questions from the audience not deeply familiar with your work. You can then show more detailed demo toward the end of your talk. This works much better than starting from low level details only to show the final results at the end. As in the case of CER, please consult your advisor for specific details.

Your talk should be between 30 and 40 minutes. Please allocate about 2 minutes per slide on average. Please check the equipment (laptop, network connection, any special hardware) prior to the presentation in an exact configuration that you plan to use.

Some good general resources to help you with oral presentation are here: Department Preparing Oral Presentation Web Page

Again, please involve your advisor in reviewing your oral presentation too.


Best of luck!


Prof. D. Petkovic
Chair, CS Department, SFSU