CITS2002 Programming and Systems - Project 1 Feedback
Q: Any comments or suggestions to improve the project assistance in
future years?
I enjoy learning programming, and this is my first programming unit so
far. I think some more simplified program practice throughout the unit
would have added a little more clarity to the project. However, it was
challenging (stressful) and fun.
Thanks :-)
The Project should be finalised before it is viewable. i.e. there
shouldn't be changes to the project (even minor ones) once the project
has 'started'
I believe that the only change made to the project after its release
was changing the maximum number of I/O operations from 100 to 50 - a change
easily handled by changing a single constant in C.
Clarifications were made to re-word or paraphrase explanations that were
unclear to some students, but they did not change the nature or specifications
of the project.
More timeslots where there is assistance available
Unfortunately providing more labtimes would require a bigger budget,
but I handled many questions in my office, after lectures,
and via email and the help forum.
More aviable consultation times
For noting, the consultation time was selected because it immediately
follows one of our lecture times, so everyone "should" be able to attend.
This time was also recommended by part-time students in previous years,
who found it difficult to get too much time off work, and sought lecture
and consultation times together.
Moreover, our unit page clearly states that you can email for an appointment
for another time.
Example data with example solutions when the assignment is released. Or
a primitive testing program.
(In hindsight) a good suggestion,
though I was surprised at how many students did not create/edit their own simple
eventfiles, and use the provided sample solution and viewer to
experiment with them.
Would be good to have a few lab/help sessions spread over the week,
rather than all within 2 days.
project released same time as mid semester exams, so i only spent
effectively 1 week on the project and ran out of time.
While some of the Assignment was somewhat ambiguous, answering of
inquiries on the help forum was prompt and well executed, so I found
everything I needed and certainly commend your management of this
assignment.
Thank you :-)
Just on the question above: "Do you feel that the lectures, labsheets,
and your reading (to week 5) were relevant and prepared you for the
project?" I think you really need another answer , which is not catered
for: Yes, the labs we have had were relevant and helped prepare for the
project, but no, they by themselves were not sufficient.
Thanks;
you should have no expectation that all labsheets before a
project are sufficient to complete the project.
Projects are not only set to assess what you already know,
but also to require you to seek out new knowledge and to demonstrate your
understanding of it.
This was a great project that tied the operating system material in with
a practical coding project. I enjoyed it thoroughly.
Thanks :-)
Please give tips that would avoid students spending hours on the same
problem . a couple for this project was to use unsigned longs for time
if using micro seconds , and also stuff with disk sectors. Even though
the problem was kind of simple i think a bit more structured abstraction
would of been helpful , this could of prevented students like myself ,
spending hours looking at the problem and getting no where simply
because we didn't "realise" a small fact or aspect of the problem.
Setting out what the project was asking instead of a vague project sheet
would be much prefered.
I sincerely don't believe that it was vague,
and there was every opportunity to seek clarification.
The lectures/labs are too easy compared to the project. Despite
understanding these and doing very well in the mid sem, the project was
still very hard
Instead of having 2 projects worth 20% each near the end of semester,
perhaps 4 projects spread evenly through out the semester would be
better. I read through the lecture notes, watched the lectures and
tutorial videos and attended labs I found that there were still skills
in C that I had not picked up. It's no good sending students off to read
multiple "suggested reading" texts if the lectures are full of theory
and little practical work as we tend to get bogged down in memorizing
theory to pass exams. Having said that the lecturer and the lab
demonstrator are great to work with and learn from. Both give great
help when asked however this can be daunting if a student has multiple
"stupid questions" because after all this is a brand new skill and
language to many students in the unit. I find that I am a student that
will spend copious amounts of time studying the theory trying to
understand as much as possible before attempting questions and getting
disheartened when I don't know an essential skill. As a recommendation
to the University and the Computer Science Faculty I would suggest
having a unit that focuses just on the skill of programming in C as it
is an essential skill that I feel it is being glossed over in this unit
to cover the theory of operating systems while relying on us to teach C
to ourselves.
A historic note - prior to the start of UWA's New courses (pre-2012)
there was a whole unit introducing C, in which we "got further" with extra
features in C and how to use it.
Unfortunately, we're limited in the number of how many units we can offer as
part of the New Courses, and there's a lot of computing to cover.
Either more time is required, or extra hints should be given on the
overall thought process of the assignment
the project was related to content and worthy of a second year unit
project, but the unit itself should have some programming prerequisites,
as people who have minimal or no programming experience will fail
(unless they manage to find a project partner who does everything/the
whole assignment). The reason students find this unit so difficult is
due to both operating systems and the C language being two very large
topics on their own - a begginer programmer undertaking this unit will
not realise there is not much focus on actually learning how to program,
and hence wont have the basic programming skills to undertake this
project Another issue I personally experienced is that the requirements
kept changing - i found this slightly annoying and hindering to my
progress.
More people helping
The assistance was fine.
Q: Any comments or suggestions about the nature of the project?
It was relevant to both what we had learned about programming and what
we learned about systems. I like that we could tie that all into one
project.
Thanks; that was the intention, as students from previous years indicated
that they had difficulty linking the two parts of the unit.
It seemed extremely difficult
It is not fair for beginner programming students! It took me too much
time to learn appropriate program techniques. I really felt that this
project is designed to people with more programming experience. I
enjoyed it but the deadline was too short!
Would of much preferred something less operating systems related,
something more real life related (AFL ladder, brownlow simulator etc.)
for the first project and then the second project something to be more
theory related.
For the past two years we've seen students pay no attention to the OS
material while an 'application-only' project was offered.
This year I wanted to better link the two areas.
I have indicated above that I found this project difficult - but at the
same time I might mark "Just right" (if survey options had allowed).
That is, I felt the project was reasonable for one worth 20% in a level
2 unit. It was a good challenge, and I feel that in doing it we learned
a lot. Also, in reply to "did you have sufficient time...?" I chose
"Yes, but i had to go without sleep..." - This was due to my own poor
time management and I suppose also another assignment I had to do for
another unit, which took time... but all things considered I think the
deadline was fair.
I really like this kind of project because to complete a project will
help us understand what we are doing and what we can do. What's more it
will practice our programming skills a lot. However , I have a confusing
question. We are asked to finish this project with a partner. But it was
very hard for us to separate the work. I mean, we didn't have a very
clear plan for the whole project, e.g what functions we are going to
use. So it will be a very teamwork project if we have learned how to
separate the project into two parts.
Working together doesn't suggest that you should divide the work,
and meet-up only towards the deadline to merge your partial projects.
The intention is that you work together,
discuss and solve the subproblems together,
and end up understanding all of your joint solution.
You can tackle and achieve much more as a team.
Good tie in between understanding of operating systems and C. A somewhat
challenging project but, given that it was worth 20%, certainly
appropriate.
It seemed to me that the project became for the first 2 weeks an attempt
to make up time, to gain the kind of knowledge that a couple of labs
might have given, and then a scramble to do something in a week with the
benefit of that knowledge. With other commitments, the need to debug
etc, this was not helpful to students who prefer to utilise the whole of
the project time more effectively. Even though this is a level 2 unit, a
student who has simply done some Java programming may still be
considered a novice when it comes to designing a simulator, or using the
concept of an event list. This project, because of the steep learning
curve, could easily have led to some students becoming stuck and not
advancing in terms of a project solution. The provision of sample event
lists and sample schedules would have allowed some students a better
grasp of what objectives the simulation had to meet, but this was only
if they could reverse-engineer it, and was probably making up for the
lack of explicit information in the problem question. It was not helpful
that the statement of output statistics was confusing and setting of
problem-questions might benefit from a second-set of eyes, particularly
someone who is less experienced and might ask the kind of questions a
student might.
It was really difficult to understand just what we should do and what
the program should do. A lot of time (maybe 2 weeks) was spent only on
understanding the questions and the project over /clarifications, which
I think was a little bit too much.
Your introduction to C programming needs to be better. I came into this
unit not even knowing what a terminal was. And yet within the first
lecture you opened something (what I thought was a text editor) and
started coding. So please identify the elements in which you code before
you dive into the actual coding. The project I felt was a lot harder
than what I had been learning, and the material we had learnt,
especially in the labs, was not relevant at all. You need to introduce
certain aspects of the project in the earlier labs. We need to be able
to use the materials learnt in the lab for an assessed project,
especially if it is worth 20% of our semester marks. I thought the
project difficulty was not appropriate at all, especially for beginner
programmers like myself. Thankfully the lab demonstrator was much
clearer in explaining the project.
Making it 'easier' by not conducting the process accurately (like not
using interrupts) actually made it more difficult to understand what was
required as this was not very clearly defined. The only source of
information on 'doing it a more simple way' is the project outline,
whereas there are thousands of sources for the alternative.
We will disagree on this;
while not the frequently-seen approach polling for the readiness of the disk,
rather than handling asynchronous events,
made the project accessible to more students
(consider, also, how an Arduino works).
It seemed quite difficult, couldn't complete it fully.
Something that we can show mum and dad , and they think we are learning
something at University. Jokes aside however , if students from other
faculties thought that our project was slightly useful , it might
encourage them to take up CS which would benefit the school.
It's a second-year unit - it's "too late" for students from other faculties
to take up CS, and ECM students need to get on learning some CS.
You could show Mum and Dad that you've learnt
something of an operating system's execution!
The programming side of the project didn't seem to hard, however
actually understanding what we were supposed to be programming was very
difficult. Past project 1's , the afl ladder and the MAC address project
were much much simpler to understand, even if they were harder to
actually program. While I'm sure I failed the project due to only
understanding it after talking with Chris 2 hours before it was due, if
I understood what the question was asking before hand I'm sure I could
have come up with a much better solution. While I realise that this is a
level 2 unit, and a project worth 20% is supposed to be difficult, I
spent many hours working on the project but getting nowhere or heading
in the wrong direction due to not fully understanding the task at hand.
Perhaps the first project could be a bit easier, and provide information
on the required steps.
Modelling a complicated physical system right off the bat has made me
seriously doubt my ability as a programmer and killed my enjoyment for
the unit. If it only gets harder from here I feel i need to take a full
semester off just to teach myself the entirety of C so I can stand a
chance of passing.
Instructions on what the program should do were very confusing, I found
it hard to interpret the instructions, like most students (thats why
several clarifications were required).
Myself and my partner found it incredibly difficult
There wasn't enough clarifications on the project. The explanation of
what was required from the project was too confusing that it had
students approaching the problem from completely different angles, which
had everyone going in tangents. It seemed as if the explanation was
minimal in nature so that it wouldn't give away too much too the
students but the project was fairly complex as it is, and being minimal
in the explanation just ended up making the project too vague.
The idea of the project was very good, it contributed both to the
understanding of operating systems and the understanding of programming
concepts.
It was overly obtuse. Given that the unit requires no prior programming
experience, the project seemed overly complex as far as coding goes.
Conceptualising the project was relatively easy, and breaking the
project down into manageable steps and understanding the theory behind
it wasn't difficult; actually coding it was another story entirely. The
queue was hard to establish in C, and I found myself resorting to arrays
and several nested loops.
Please read my earlier comments on the Advisable Prior Study for this unit.
Using arrays and loops was all that was expected (anticipated) for the
project, as it was clear that programming requirements for the project had
all been introduced by the time the project was released.
This project seemed to be aimed at those in the unit who have had a lot
of previous experience with c++. It called on information that wasn't
touched in the unit lectures. Lectures would concentrate on the theory
part of c++, explaining when it was created and how it can be utilized
although scarcely touched any practical areas which this project was
based around.
An unusual comment given that this unit makes know reference to,
nor assumes knowledge of, C++.
The project was fairly difficult, as expected for a second year unit,
but there should be prerequisites for the unit, as there is not much
actual programming to be taught (as in the java first year unit) Also, I
found that iwould have been incredibly confused had i not done the 2200
unit earlier, which clarified the idea of queues etc.
A bit easier
I believe that the purpose of the project was to push coding skill, and
understand more solidly the process followed by the CPU. However that
latter part seemed a bit odd, as I think the biggest gotcha of the
project was getting the order, loops and timing right. Definitely
important to understand how the CPU does things, but some of those
timing issues came across as a bit of an afterthought, not a deliberate
problem, in the assignment. As a result I'm wondering if I was really
matching a CPU's ordering of things, or just matching the sample
solution's. Also, where such attention to CPU activity was important in
one area, it was strange that it was unimportant in another, ie, queue
handling. I understand that this would have been pushing the difficulty
level, so this is just another comment about the nature of the project.
It was "simulate the CPU precisely, sometimes". If using a similar
project later, I would maybe hand them the code for the blocked queue
that simulates a real CPU's workings more closely, and talk openly about
approaches for the ready queue and expect students to figure out which
is best to use for that queue.
I got the main engine of the project running correctly, as it matched
exactly with your sample solutions total run time, but couldn't get the
turn around or blocked time working properly. It made me sad :(.
Q: Do you have suggestions/comments to assist the planning of the 1st
CITS2002 project for next year?
Perhaps some 'example' programs that do not give too much away but are
helpful in lending an understanding of how to use more complex
programming practices.
I feel that this project was very hard and would have preferred more
time to complete it as there was a steep learning curve and quite a few
misconceptions and errors.
Spend a lecture going through exactly what we have to do for the project
as I found there was a lot of ambigious moments where I didn't know what
the program was meant to do.
Tutorial-5 (Sept 5th) was devoted to answering questions about the 1st project,
and introducing the sample solution and event viewer.
Take into account that there are lots of students who has very little
concept of programming
More information given on day one instead of a couple days in. I
actually thought the lack of information (in my eyes) in the lecture
notes was actually a good thing, because it meant that we had to
research and read about it more in depth. However, it was hard to find
something specific about our project and most of it was just looking at
your implementation to figure out the correct sequences.
I don't think labs or lectures before the project had sufficiently
emphasised simulation (e.g. simulation of motion, or queueing), and then
coding to deal with pre-emptive processes and I/O buffering and
scheduling algorithms. Since this was the first time these topics had
been encountered in the course in a programming context, then it was
essential that either the problem question gave explicit background
information about these things, to adopt terminology allowing students
to put the problem in context. Ideally, there should have been a lab to
allow students to practice some kind of event-based simulation, and one
to do with systems, such as I/O processes. That would have been more
beneficial to the project than merely text-manipulation.
Other universities do set similar problems, but they do so after some
introductory labs or by giving students some directed help, or by making
more explicit reference to relevant terminology about schedule
algorithms and simulation. This also helps guide students to reference
materials. For example look at how much explicit definition and
direction is given to students about terms for scheduling algorithms and
pre-emptive scheduling in this course:
http://www.cs.grinnell.edu/~weinman/courses/CSC213/2014F/labs/scheduling.html
(Weinman has been playing around with his course structure since 2008).
That project is done in teams over only 6 days (less than for our
project). Whilst the student performance of these course is unknown, it
seems that there is a need to spend some time on these topics in the
course in conjunction with laboratory work. Reference to Lab problem
7.1 in Nutt is clearly relevant too. I think the main conclusion I have
is that it doesn't matter how much time is given for the project, until
such time as the relevant knowledge is gained (and that might be the end
of the second week, then the project can't really be started properly).
Our project did not require any detailed simulation, scheduling algorithms,
or I/O buffering.
it was based on the simple 5-state model introduced in lectures.
Further details about that model,
or ones sufficiently similar to address the project,
could all be found in any of the recommended introductory recommended textbooks.
It is incorrect to believe that all information for this unit is provided in
lectures, or that all requisite knowledge for a project will be known before
the project.
Yes, that lab exercise and unit from Grinnell College looks interesting,
but it's unreasonable to compare very much of it to CITS2002.
Their CSC213 unit has two formal CS prerequisites;
four lectures per week;
devotes just one lecture to *review* C
(knowledge which doesn't come from a prerequisite, but
an optional
unit);
demands a knowledge of pointers and building dynamic data-structures;
and requires students to attend and participate in all lectures and labs.
I'd like that luxury, too, and that's why I enjoy teaching in the US.
In contrast,
UWA permits an extreme amount of flexibility,
and our project could be successfully completed with only the
programming knowledge introduced by Week-5.
None, I suggest you use the same project next year. The most difficult
aspect of the project is learning to write clear, well commented,
semantic code. As we've been writing our own code in the labs, perhaps
more examples of good coding practice might be beneficial.
Thanks, but as sample solutions to projects are released,
it makes it infeasible to re-issue projects very frequently.
Hopefully you also found some benefit in the sample solutions to the labsheets.
I myself am a Vim user and have been so for 2 years -- I would most
definitely try to 'convert' other students into using Vim (in place of
other editors); however when I was helping others with the project, I
found that the majority of those who took the unit's recommendation to
use Vim were actually using a GUI version of Vim (i.e. not-Vim). I am
taking the guess that this was the result of not knowing how to enter
inset mode, let alone how to use the home row keys to move about, and
ultimately giving up on Vim only to then succumb to a GUI based editor.
I would strongly suggest having a short page for the basics of vim and
vimrc's (or just have one prepared for them) for next year so that
students will never have to go through the horrors of using a mouse
whilst editing. P.s. I never knew how Adele could 'Set Fire to the Rain'
until the day I saw you white-background terminal.
Please introduce aspects of the project in the earlier labs. There needs
to be some sort of lead up.
More clearly defining the specifics when the project was released
(instead of posting later) would have been more helpful. This project
was significantly more difficult to complete than any previous projects
I have done (first year cs, having done python and java previous
semester), this was mainly due to it being difficult to understand
exactly what the program was supposed to do on a more detailed level.
Once I actually understood what was wanted, I had no problem breaking it
down and actually writing the code. I have said this allot, but when the
program is required to do something so precise and specific, the project
outline should match up to this. Overall, I the project was worthwile
and beneficial.
Possibly smaller less weighted projects.
Perhaps a stronger focus on coding in C rather that having to have
additional knowledge about the physical hardware of a computer. The
concept of an event file, spinning discs and multiple queues that all
have different and complicated rules was really intimidating as a first
time programming student who had just wrapped their head around the
basic coding skills of C. Going back to my 4 projects suggestion,
perhaps the first project could be to write a set of small functions in
different text files. The second could be a physical system to model.
The third could be something similar to the first project but smaller as
it is worth less marks. The fourth could be similar to the final
project, but again simpler as it is also worth less marks. .
Clear instruction on how the program should behave,
without concepts like 'disk sector' (that students have not encountered).
The degree of knowledge about disk sectors required for the project
was easily available in any of our recommended OS textbooks,
or even Wikipedia.
The presence of a new term cannot seriously delay your learning.
The project needs to be worth more than 20% in our case. Or in future,
the explanation of the project needs to be made succint.
Too hard for a first project, especially considering nothing on the
labsheets without a chilli marker approached that level of complexity. A
bit more of a starting point would help.
the project should be well costructed before publishing, as there were
changes made during the course of the students' working time
I'll again state that there was only a single, trivial, change after the
project was released.
For advanced students, it can feel unintuitive to do some of the things
that are the default expectation for the project. Such as the number of
globals, the constantly re-shuffled arrays, and the always-max-size
arrays (though I suppose that's how it works in reality). The assignment
spec placed emphasis on "sound programming practices", but personally I
was confused about where I stood between "code for this problem only"
and "sound programming practices", because in my mind some sound
programming practices involve things beyond the project's scope. With
students like that in mind, I would have liked the specs to be clear on
whether 100% could be achieved without advanced things like optimising
the arrays (speed or size), or reducing globals, etc. It definitely felt
ugly to be shuffling an array every pretend microsecond. I guess a "you
can get full marks for sound programming practices up to what we have
covered" is what I would have liked, or anything that made the
description of where marks are coming from a bit clearer in the case of
going beyond course material so far.
I believe that it was clear that students with an understanding of all
material introduced to Week-5 would achive 100% in the project,
and anyone correctly employing any more advanced techniques would not have
been penalized for doing so (there was no need to 'dumb-down' a solution).
