| Faculty: | SCHOOL OF COMPUTING | Academic Year: | 2010/2011 |
| Department: | COMPUTER SCIENCE | Semester: | 2 |
| Module: | SOFTWARE ENGINEERING ON MODERN APPLICATION PLATFORMS - CS3217 | ||
| Note: | Feedback on module in general | ||
| Qn | Items Evaluated | Module Avg Score | Nos Responded |
|---|---|---|---|
| 1 | Overall opinion of the module. | 4.048 | 21 |
| 2 | Grade likely to get for the module. | 4.65 | 20 |
| 3 | Difficulty level of the module. | 4.429 | 21 |
QN\SCORE | 5 | 4 | 3 | 2 | 1 |
Qn 1: Overall opinion of the module. | Excellent | Good | Satisfactory | Unsatisfactory | Poor |
Qn 2: Grade likely to get for the module. | A | B | C | D | F |
Qn 3: Difficulty level of the module. | Very Difficult | Difficult | Average | Easy | Very Easy |
| Nos. of Respondents(% of Respondents) |
| | | ||||||
ITEM\SCORE | | | Excellent | Good | Satisfactory | Unsatisfactory | Poor |
| | | ||||||
Module | | | 9 (42.86%) | 7 (33.33%) | 3 (14.29%) | 1 (4.76%) | 1 (4.76%) |
Module at Same Level (Dept) | | | 101 (25.06%) | 203 (50.37%) | 88 (21.84%) | 10 (2.48%) | 1 (.25%) |
Module at Same Level (Fac) | | | 148 (20.30%) | 362 (49.66%) | 186 (25.51%) | 27 (3.70%) | 6 (.82%) |
| Nos. of Respondents(% of Respondents) |
| | | ||||||
ITEM\SCORE | | | A | B | C | D | F |
| | | ||||||
Module | | | 13 (65.00%) | 7 (35.00%) | 0 (.00%) | 0 (.00%) | 0 (.00%) |
Module at Same Level (Dept) | | | 122 (30.73%) | 224 (56.42%) | 39 (9.82%) | 12 (3.02%) | 0 (.00%) |
Module at Same Level (Fac) | | | 240 (33.57%) | 399 (55.80%) | 64 (8.95%) | 12 (1.68%) | 0 (.00%) |
| Nos. of Respondents(% of Respondents) |
| | | ||||||
ITEM\SCORE | | | Very Difficult | Difficult | Average | Easy | Very Easy |
| | | ||||||
Module | | | 10 (47.62%) | 10 (47.62%) | 1 (4.76%) | 0 (.00%) | 0 (.00%) |
Module at Same Level (Dept) | | | 87 (21.59%) | 171 (42.43%) | 133 (33.00%) | 10 (2.48%) | 2 (.50%) |
Module at Same Level (Fac) | | | 99 (13.62%) | 270 (37.14%) | 336 (46.22%) | 18 (2.48%) | 4 (.55%) |
| Q1. | Please comment on the strengths and weaknesses of the module, and suggest possible improvements. |
| 1. | Strengths: One of THE best modules in NUS. The contents taught in the module are extremely relevant to any computing student and in-fact should be made a compulsory module. The module has enhanced my way of thinking and also the way I work in a group. The topics of software engg. were not only taught theoretically, but the assignments designed enabled me to experience software engg. in a real world scenario. Weakness: Maybe a bit too hard for normal students. Good that the prof chooses only certain students to suffer ;) |
| 2. | very very heavy workload. too much self-learning about coding required. |
| 3. | Strengths: Practical, possibly the closest thing to a real small scale SE project in the real world. Weaknesses: Too little time, too much to do, too competitive. Possible Improvements: Balance out the scoring, and make them more transparent and upfront so that the learner can better gauge the amount of effort for each component right at the start of the module (one quarter of the entire scoring of the module to one PS is too lopsided). |
| 4. | Good for independent learners, and intrinsic-driven people. There are a lot of rooms of improvement, but because we are the first batch, it was expected to bleed a little. |
| 5. | Many things to learn but too little time to apply concepts. Students become aware of bad practices but due to lack of time before deadline, many rules end up broken anyway. Many new requirements are added suddenly such as level of detail in reports which end up snatching all the time for other modules away. |
| 6. | Needs to perfect and sort out some of the Problem Sets. Could give more time for the projects. Could try to cut down on the amount of workload - especially by reducing the number of reports required. |
| 7. | In principle, a very good module. In execution, it fell short. Out of all the Prof Ben modules I have taken, this is the poorest (by his standards). Even though I understand this is a new module, the haphazard nature of the module is extremely overwhelming and have caused a lot of pain. The first half of the module is very good. I think it tested us vigorously and pushed us as programmers. The assessment was fair and straightforward. I deem it excellent. The first main issue of contention is assessment. Assessment is a lot more fluffy than expected. Primarily the standards of different tutor differ. Some tutors may be good at writing code, but that does not mean they are better at grading. Specifically, our grading tutor has very weird tendencies in UI and program design. "I think its very weird" - What happened to UI design is not just about you? Even I can't be sure that what we've design is right/wrong, how can he? Just because he is a hacker, does not mean whatever he thinks/say is write. He assessment of reports are extremely unfair as well. Our grading tutor can even suddenly add in new grading criteria - "coolness" for our final application. Didn't the teaching staff already establish that we are marked on how we deliver to the specifications? Since when "coolness" came in. To make matters worse, he added that "frankly, i don't think your app is very cool". A similar test suite given by another group was not docked on marks. The question begs: what is being marked here: the effectiveness of the test suite or the actual demo? Where is the consistency there? Clearly, our marking tutor is marking based on impression. We feel extremely shortchanged for the time we especially put into working on our document. This consistency is actually also present in the marking of the first half assessment (problem sets). Though I may personally not be affected by this, the same tutor mentioned above gave very different assessment on similar products. This brings us to the next point - the clearness of assessment. At the start of the module, Prof Ben made promises such as no diagrams and assessment based on - as long you meet specs, you can get A. When the actual assessment is released, it had a lot of additional components. Report after report after report. While I understand that this is to reduce the final workload, it is really a lot of work. At times it becomes unnecessary because everyone is going through motion. 1 week before the dateline, now there is a new code review during recess week. What about the other modules? Isn't recess week supposed to be for other modules? Now we have to refactor again before thursday on recess week. Having your tutors work is really not a defence. I think a line needs to be drawn on the amount of work. We really do have other modules. Up till now, the assessment criteria is really not clear. We are not clear the impact that each mark lost in PDD has on our final grade. On paper, each mark lost is 0.5% in the final scheme. But the problem is that we do not know how this 0.5% will affect the final grade. Are you really going to give a full class of A? I believe not (even though that was claimed at the first presentation). How much impact does is 0.5% for grades? The presentation was really not effective at all. Almost all teams just went through the motion of creating the presentation on a day after the submission of another milestone. Overall, I am very very disappointed in the second half of the module. Unclear assessment, unfulfilled promises, and disproportionate work. The arms race promised not to happen eventually aroused. I find it sad that our grades are at the fate of the grading tutor, whose standards clearly differ amongst the tutors. (I'm sure there is moderation done, but the representation of a project is given by the marking tutor. Furthermore, I would like to express my great displeasure at the quality of one of the teaching staff. |
| 8. | Extremely tough, provides a lot of self-learning opportunities. |
| 9. | Strength: Many new, challenging stuffs learnt from this module. Weakness: Heavy workload |
| 10. | It gives chance to work on supposed-to-be-real project, but since this is the first time the module is offered, there are still "bugs" here and there, especially the iMac account settings. And the problem set can be better finalized next year with the responses and feedback from current year. |
| 11. | Very cool module. But very very heavy at the same time :( |
| 12. | Superb module on software engineering. Important software engineering principles is covered quite throughly. Lectures are very inspiring, professor is ways very cool. Professor generally takes very good care of all the students in the module. Problem sets are well design and concentrate on helping students learning software engineering principles/skills, as well as strengthening them. Feedback after problem set is quite useful and help students understand disadvantages/advantages of their doings and thus can do better next time. Students in the class are all cool, smart, hard-working and dedicated. Final project pitching session and poster session is rare experiences in NUS. In brief, a must take module for any software engineer. |
| 13. | The modules have quite a lot assignments which will make you very busy in the first half of the semester. But this is a really cool module where you can practice your software engineering principles by doing those practical assignments. In fact, I learned a lot by doing the assignments (like: debugging skills, overcoming stress skills etc : ) Besides, you can have the chance to use an ipad provided by SoC. |
| 14. | Good assignment Good lectures Inspired talk Just can say wonderful |