FIT2001 week 2: almost moving!
I think I enjoyed this week of FIT2001 more than last week’s, as we actually started to get our teeth into some real topics, and didn’t spend a lot of the lecture “settling in” as is inevitable for a first week class. I think I was a bit sick of the “welcome to our unit!” talk because FIT2001 is my last class of the week. I thought it was amusing how POD kept saying: “I know this is boring, I promise next week will be more exciting”, because I actually found this week interesting. It helps that I’m also doing Project Management (FIT3086 (FIT2003)) this semester as well so a lot of the concepts carry over. I guess the feel of this week is that we’re starting to climb up a mountain and the really interesting stuff is soon to come.
The theme of this week seems to be an overview of how a project works, because as future analysts and designers we’ll need to be aware of how our work slots into the whole. I liked getting the big picture idea, but I’m looking forward to getting into the details with the assignment.
While we’re talking about the assignment, I’m a bit concerned that a quick google search on wikipedia doesn’t show up anything meaningful for “Event Table” so my ears will be pricked for any references to them in the lectures, and I’ll look it up in the text book as well. This web based system sounds a lot simpler to the MAX FIZZ assignment from last year, but might not be as much fun.
Every project starts with a problem. Even if it is in response to a new business opportunity, the problem is “we’re not doing this yet and we should be!” So analysts have to be good at identifying problems. After that we can worry about how to best solve them, but we have to make sure we’re solving the right problem! Then we can look at all the tools, techniques and models we’ll need from our chosen methodology to make something cool (or not cool, I guess) that fixes the problem.
Model making seems to be something we’ll do a lot of this semester, something that stuck out to me from the lectures was models have to mean something, they have to help our understanding of the problem. So not like Dilbert then. (I reckon Dilbert is an “anti-manual”: a manual on how NOT to do things.)
The Quiz!
Since the quizzes don’t count towards our marks for this unit, I’m trying a new method of learning, which is “Fail first”. Basically if you take a test and then fail a lot of it, you’ll remember the information better come exam time. (I know I saw the article about this research, but can’t find it at the moment.)
So, the things I missed this week were mostly vocabulary terms: things like spiral modelling, context diagrams, and the exact definition of phase and activity (phase is a group of activities, activities are a group of tasks) I had some good guesses and some very easy questions. I sometimes confused the order of things, I put “write a project proposal” before “identify a business problem” I guess because I had a small picture view, not a big picture one. I found the text entry boxes frustrating to this method of quiz taking. I have several answers to double check.
The Tutorial
Only two groups showed up to our tutorial, so we got through the presentation pretty quickly. As POD said defining system boundaries is quite difficult! I enjoyed doing the presentation on only a small amount of preparation: I have done some volunteer teaching so I know how to conquer the nerves pretty well. I like the idea of focusing on a technological kind of system, not the big overview kind of systems. I’m looking forward to getting into the assignments, but I know I will be frustrated at not actually building it!
Onwards and upwards into week 3!