程序代写案例-COMSC 343

欢迎使用51辅导,51作业君孵化低价透明的学长辅导平台,服务保持优质,平均费用压低50%以上! 51fudao.top
COMSC 343 - Final Project
Several due dates; see individual parts
Goals
● To explore an OS topic independently / as part of a small group
● Var
ious subgoals (project-specific)
○ Strengthen skill writing low-level code in C
○ Deepen understanding of an OS-related topic
○ Practice writing a technical paper
○ Practice reading technical papers
○ Practice giving a technical presentation to peers (in video form)
Introduction
As you know, this course requires you to complete a final project that will determine a sizable
portion of your grade. You will choose your own topic related to operating systems to study in
more detail than we have as a class. There are many possible directions you can go with your
project, but it should be reasonably substantial. It also must have a believable story about why
it fits into this class (that is, it must relate to operating systems strongly!).
I will continue to make announcements about upcoming due dates, but you might want to set
them in your calendar!
PR0 - Come up with an idea (or more than one)
The real first phase of the project is to come up with an idea. If you have a project idea that
seems too ambitious to do alone, you should think of this as an opportunity to work with a
partner.
A very straightforward project would be reading several related papers on an OS subject which
interests you (from various ACM journals/conferences/etc., perhaps), and writing an eight page
paper synthesizing what you've learned and which includes some hands-on aspect (e.g.,
running an experiment or gathering data). A more ambitious one would be writing some code,
such as writing an implementation of the FAT filesystem in Python (which you could then use to
actually access files in the VM or even your own "normal" OS). There are other possibilities as
well -- I'll try to be flexible! L16 has a bunch of ideas. A crucial point is that every project should
have some sort of "hands-on" component unless you can argue very well that the project is
worthwhile but no hands-on component is possible.
PR1 - The Proposal (3 Points)
The proposal should be turned in by the end of November 9.
The proposal is a write up of probably one or two pages wherein you describe your idea for a
project. If you're working with a group, you should each submit the same one and it should
clearly list the group members. If you're thinking about multiple projects, you can submit more
than one proposal.
Answer questions like the following (but don't feel beholden to exactly this list!):
● What are you hoping to learn?
● What resources will you make use of?
● What will be the final products? What will be the hands-on portion?
● Will you be working on it alone, or with a partner/group?
○ If you're not working alone, how will you divide the work? How will you ensure
that everyone feels that everyone has done their part?
● What is your timeline? What should you have accomplished by when? In particular,
what will you have done by the progress report?
● Is there any specific feedback you want from me?
I'll give you some feedback based on this.
PR2 - Progress Report (2 Points)
The progress report is due November 23 30.
The progress report is a way of helping to ensure that you're on track. It should probably be one
or two pages. It should contain at least:
● A description of what you've done so far
● The resources you've found so far, what information they contain (see the notes below
on sources)
● A list of things you know still need to be done, or resources you still need to gather
● An outline of your paper and/or description of "hands on" stuff you've done so far
Note that by the progress report, you should ideally have truly started. You should have a clear
idea of what your final project will look like. You won't have fleshed out the entire paper, and
you may not have completed all your hands-on stuff, but you should know what you are
expecting in some detail. If you want to pivot to a different project than you initially proposed,
you should know it by this point, have discussed it with me, and made progress on your new
idea!
Regarding sources: citations of web pages are acceptable if they are reliable sources, not
marketing hype or some random person making unsubstantiated claims (e.g., citing the Linux
kernel website or mailing list posts from Linus Torvalds are very acceptable for a project on the
Linux kernel; random Stack Exchange posts are not -- find authoritative sources!). Learning to
evaluate the quality of resources is a valuable skill. Feel free to ask me for input. Of course,
books, articles in conference proceedings or journals, or technical reports are good sources to
use. Be sure to make good notes about your sources so that you can make a proper list of
references in your final paper.
The grading for the progress report will be based largely on your progress. For example, a
decent paper outline, including the key points you want to make and resources to back them up,
a full description of your hands-on component which shows you've actually thought about it, and
a detailed list of good sources will get the full points. A thrown-together sketch of a paper that
leaves all the details to be worked out later will not get the full points.
PR3 - The Video (5 Points)
This portion is due December 12.
The video is your chance to present your work both to the professor and (more importantly) to
your peers. They should be between five and ten minutes.
Suitable material for presentations will vary depending on the project, but should probably
contain at least:
● Some background information so that everyone can understand
● A description of what you did
● A summary of what you learned
If you wrote software, a demonstration may be appropriate.
It is likely you will not be done with your final deliverables at the time you record your video.
That's okay. You should have something substantial by then, and can talk about what you've
done so far, what you hope the final results are going to show, what you've found challenging or
interesting, and so on.
You should probably include slides, and you should rehearse or edit your video so that it flows
well.
Videos will be posted on the Moodle. Your own video is worth 3 points. You should watch at
least two of your peers' videos as well, and make a thoughtful comment or ask a question on
Moodle; those two comments are worth 0.5 points.
PR4 - The Final Deliverable (10 Points)
The final deliverables are due on December 20.
All projects should include a paper. For this paper, good technical writing style is important.
Writing well is very difficult - it is an iterative process and cannot be done all at once. Be precise
and be concise. Feel free to ask other students to read and make suggestions about your paper.
You may wish to investigate whether the SAW Center can help you improve your writing. Add
an acknowledgment section to thank anybody, whether in the class or not, who has provided
feedback on your paper or helped you in other ways. Check your spelling and grammar
carefully. Only include items in the bibliography/references that are actually cited in the paper.
Exactly what the paper contains will depend on your project, but here are some rough ideas of
what I'm expecting (truly, your results may vary, but hopefully this gives you an idea):
If your project is focused on a coding project, your paper might be organized as follows. You
should begin with a title, author, and abstract. The main body of the paper should be organized
into sections including (i) an introduction in which you describe the general topic and the
particular aspects you will be examining, (ii) one or more sections comprising your main text,
where you describe what you have done, how you have done it, and what you have learned, (iii)
a conclusion, which should include ideas for future investigation into your topic which were
beyond the scope of your project and the paper, and (iv) a list of citations.
If your project is based more on reading papers, your paper might be organized as follows.
You should begin with a title, author, and abstract. The main body of the paper should be
organized into sections including (i) an introduction in which you describe the general topic that
the papers discuss, (ii) one or more sections comprising your main text, where you summarize
what you learned from the papers and what you did to further investigate or confirm the results
from the papers (your hands-on component), (iii) a conclusion, which should include ideas for
future investigation related to these papers, and (iv) a list of citations.
A decent length paper would be around 8 single-sided pages, using 1.5 line spacing, one inch
margins, and a 12-point Times Roman font (or similar). If you did a coding-based project, your
paper may be somewhat shorter (your code should do some of your talking for you!). Figures
are wonderful if they help explain your meaning. If you ran experiments, you may find it useful
to include some tables of interesting results.
Honor Code Guidelines
Since all the projects should be different, you are free to discuss your projects with each other. If
you wish to use or refer to any software libraries or outside source code beyond the standard
language (C, Java, …) libraries, be sure to cite them properly.
Of course, plagiarism of any material is not allowed. Also of course, your project does not exist
in a vacuum -- there is likely much related work out in the world. Cite the related work you
referred to, learned from, or incorporated. And be sure you are adding something of your own --
your project should not be an exact duplicate of any of it!
If in doubt about anything related to the honor code, ask now and avoid problems later!

欢迎咨询51作业君
51作业君

Email:51zuoyejun

@gmail.com

添加客服微信: abby12468