CITS2002 Systems Programming  
 

Unit home

Project 1

help2002

Lecture & Workshop
recordings on LMS

Schedule

FAQ

Unit outline

C textbooks

OS textbooks

Information resources


Extra reading

Past projects

Recent feedback


Working effectively

Look after yourself!

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

The University of Western Australia

Computer Science and Software Engineering

CRICOS Code: 00126G
Presented by [email protected]