: Structure for computer science research paper 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'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:
Introduction
Background
perhaps sub-sections on different areas of background
The approach
3.1. Overall approach
3.2. Detailed design
Key implementation decisions
Experiments
Related work
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?
More posts by @Rambettina586
: Do different formats of the same book need to be registered separately? We're self-publishing a book in both paperback and e-book format. The content between the versions will be identical except
: How to fix writer's thought muddledness? Honestly my problem here is that I've been on writing hiatus for like...a year and half. Apart from writing small stories here and there, I haven't really
2 Comments
Sorted by latest first Latest Oldest Best
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
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.
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".
Terms of Use Privacy policy Contact About Cancellation policy © selfpublishingguru.com2024 All Rights reserved.