Structure for computer science research paper

Question

I'm writing my first undergraduate research paper for computer science and I think my lack of experience is starting to get on my supervisor's nerves. I've written a program that collects video metadata and attempts to organise videos into a coherent sequence using the metadata. The program has also been tested by a panel of users.

The supervisor has given me the following sections to work with:

1. Introduction

2. Background

   • perhaps sub-sections on different areas of background

3. The approach
   3.1. Overall approach
   3.2. Detailed design

4. Key implementation decisions

5. Experiments

6. Related work

7. Conclusions

I'm trying to understand the difference between (3) and (4) in the context of what I'm doing. Specifically, how is a detailed design different from implementation decisions?

Answer 1

Design would include things like "order the data by date" or "track each author independently".

Implementation would be things like an actual database schema or a routine itself.

The key difference would be that design is "what I need to make happen" and implementation is "how did I make it happen".

Answer 2

Adding to Maura's answer:

"Detailed design" implies you will go in-depht showing the abstract structure of your project. This means showing what the program does, without looking at the code. Design decisions have to be discussed and explained, often with the aid of UML-like diagrams, either showing a class diagram

_{(source: ibm.com)}

or maybe a process:

Those of course are examples. There are a lot of things that can be done with UML in standardized notation - you have to decide what would be the most relevant depending on your program. If the code interacts with external services (e.g. a database, web API's, the internet) it may be worth showing an architectural diagram.

In this section you may also want to describe how you designed your method. It's a paper: it implies you have done your research. So it may be relevant to show here how you designed the process of testing.

"Key Implementation Decisions" is where you are supposed to show that you got your hands dirty, as a figure of speech. Here you are allowed to talk about your code, or whatever tech-related mechanism you have used in your research.

Keep in mind that you don't need to comment everything: just the "key" parts that are required to understand your program. Nobody wants to read a paper where you describe how you defined an array, since everyone can do that. Essentialy, you have to show how you implemented your design, what's interesting about it, what's new, what's difficult, and what challenges you did undertake.

You may want to show a "core" part of your program; you may want to discuss how you decided to improve the overall performance by using different data-structures during development; you may discuss why a particular method gives you best results, commenting the code. Those are the "decisions" that belong in a paper.