4

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?

  • 1
    Welcome to Writers SE. Questions here need to be useful to others; this is unfortunately too localized. We could help you with general structure questions ("How do I make an intro different than a conclusion?") but here you're asking us for advice on your particular paper, which won't help anyone not writing your paper. – Lauren-Reinstate-Monica-Ipsum Mar 12 '13 at 18:02
  • It doesn't need to be in the context of this particular paper. The sections he's given me are generic and I'm just trying to figure out how 3.2 is different from 4. I assumed it would be easier to explain is some context. – James Mar 12 '13 at 18:07
  • 2
    Hi James and welcome to Writers.SE. As Lauren said this is kind of localized, but to try to help you out even if this question gets closed: what I would mean by that distinction were I writing or assigning the paper is that 3 is "what you did" and 4 is "what key decisions led you to do that". You don't want to clutter up a discussion of methodology with all those "why" details, but you don't want to drop them either. – Monica Cellio Mar 12 '13 at 19:22
  • "Specifically, how is a detailed design different from implementation decisions?" This part of the question is answerable, the rest is a bit fuzzy and hard to pin down. Maybe we can edit this question to focus a bit more on the answerable part? – Neil Fein Mar 13 '13 at 0:46
  • 1
    Maura's answer below is correct. No matter how detailed your design is, you won't get into questions of the actual technologies used, etc. Whereas implementation is exactly that. But I don't think this is a writing question, really; it's a software development question. – micapam Mar 13 '13 at 5:11
5

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".

  • Given the title "Key Implementation Decisions" I would think the implementation needs to go beyond just 'how' and also explain 'why'. Design identifies the specific problem and gives and idea of how to sort it out. Implementation states what has actually been done and why those decisions were made (Why only cat videos but not dogs? Why Chicago but not New York? and so forth). From there you can move on to the experiment on a solid foundation. – Lazarus Mar 20 '13 at 20:39
1

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

UML-classdiagram

or maybe a process: enter image description here

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.