FIT2001 week 6

The first week back from the holidays, with the Event Table assignment looming, as well as two other assignments due this week. I’m feeling a little behind, but haven’t turned anything in late yet. The Clayton lecture was quite short, I thought, for such an important topic. I did enjoy the Tutorial with the hands on practice with Visual Paradigm, and I’ve downloaded VP for use on my own computer, which should be good. (Hooray for Mac versions!)

Some of the points that stood out to me in this week’s lecture (besides the ominous clump of a microphone cutting out):

This week I found the most helpful method for studying was the quiz, because there were a lot of terms I didn’t know.

The Quiz!
This quiz was useful, because it shows what knowledge I’m missing and what I was able to guess based on the knowledge I have already (encouragingly 70%). However I did miss some stuff, these are the questions and observations that I have as a result of the quiz.

Well, now to finish off my Event Table.

April 16, 2010 | Leave a Comment |

FIT2001 week 5

Well, I’m glad that this week is a lighter one, about topics useful for the exam and the future, not for the assignments. I’ve got a cold at the moment so stayed home, missing the Clayton lecture and the tutorial. Instead, I watched POD’s lecture live over UStream. The slides were a bit pixellated, but it was good to see what slide (I had the PDF also open) we were on and the gestures being made to emphasise points.

My brain was a bit fuzzy so I didn’t soak in much, but this week’s topic was about traditional modelling techniques. The two phrases that stuck out to me were “black holes” and “miracles”.

The Quiz!
I was impressed that the correct answers were available for the “open ended” questions, I’m not sure if this is something new or if I just haven’t seen it before.

That’s all from me this week.

March 31, 2010 | 2 Comments |

FIT2001 week 4 modelling events and things

Finally the penny dropped when I listened to the Caulfield lecture: Analysis is really big picture: really big picture. All the implementation stuff like user passwords, system technologies and detail like that are not important to the analysis phase. Analysis is taking the requirements we have ‘gathered’ and making some models so we can understand the complex system easily. I must admit I tend towards being a details person, I really struggle to see the big picture sometimes, and even when I step back from the detail, I don’t step back far enough. So I guess I’ll have fun when drafting the assignment!

This week’s big topics were models, events, and things. The key things to remember about modelling are:

Events, and that elusive event table! Pay attention here, this is basically the how-to guide for assignment 1a.

The next thing we looked at are Things.
Things are: things! Think nouns, add items or categories of information needed, and refine the list, recording assumptions.

We then looked at UML a little, it was pretty straight forward and hard to describe without putting lots of pictures in, so I’ll leave that to the text book, lecture slides, etc. Something I picked up by reading the textbook is that if a relationship is optional, it’s got a 0 in it (or just a *).

The Tutorial
The interview went well, but I think I had too much of a project management and design mindset when asking questions. It was a little weird because our group was kind of a bunch of individuals asking questions rather than an “analyst team”. The most amusing question that was asked (by another group) was: “what if an employee forces another employee to do their quizzes for them? ” cyber roo representative: “well, umm…”. The most useful thing to me was the clarification that the system is to be used to teach the material as well as quiz the employees on it.

The Quiz!
Wow, a long one this week, almost 50 questions! My method of quiz taking shows pretty clearly what is obvious and common sense (or learned previously) knowledge, and what I need to make sure I remember. I did pretty well at guessing any questions relating to Objects, classes, etc, as I’ve taken at least 3 object oriented programming classes, and 1 database related subject. I was pretty confused about what a state event was- I’ve now worked out that state= internal event, and temporal means time event. I also found that I blitzed the multiple choice and true/false questions the second time around- shows that I’m building good recognition of key terms, just not good recall of key terms!

I found the “open ended” questions frustrating again. I guess I have to put in the effort to find the answers! The best tool to answering these open ended questions is the text book, not necessarily the lecture slides.
There seems to be a bug where you can’t skip questions- the next question answers don’t “stick” when you hit submit. N-ary is a term not mentioned in the lecture but was listed in the text book. I also couldn’t get a right answer nor find one in the text book for these questions:

A/n____________________ class is a class that cannot be instantiated.
A class that can be instantiated is referred to as a/n ____________________ class.

Something that catches me out is jargon- but as POD says, jargon means you can charge an extra 150$ an hour.

Some thoughts
I sat towards the middle to be less conspicuous with my laptop in the Clayton lecture, after people have complained. The problem isn’t laptop usage! The problem is people talking- the hum of conversations makes me want to get up and leave! POD was complaining about lecture attendance at Caulfield, it’s a shame because his presentations are always interesting. I enjoy listening to them.
Also: I forgot that there was a copy of Microsoft Project 2007 in the back of the text book- a find that generated much excitement! I need MS Project for Project Management time to install parallels or something- so far I only have CrossOver games (for spider solitaire, old lode runner, etc) running windows stuff on my mac.

March 26, 2010 | 6 Comments |

FIT2001 week 3: werewolves and pepsi


This week we started to really fill our Systems Analysis and Design tool kit, with an emphasis on tools needed for gathering requirements, which is pretty much all of the analysis phase! I liked the phrase “fact finding” as opposed to mushroom gathering when it comes to requirements. I also found it interesting that you might not need to talk to all the users in order to design a system, but it’s important so that they are validated and feel an important part of the process, and also to balance the different needs and ideas of the stakeholders.

Check you have the right requirements, then prioritise and resolve conflicts between different stakeholder requirements, build a prototype (don’t make it too good, or your pointy haired boss will think it will take a lot shorter to do the project!) look at alternatives, and review the analysis to see if we should continue to design and build this system.

The Business Process Re-engineering and Analysis (BPR) sounds like it has the potential to go nuts and make huge mistakes; but it is a good idea to look at how best to solve the problem with IT, not just implement the manual system with computers.

When I sat in the Clayton lecture I thought: “What is JAD?” and saw the slide with a JAD room. On listening to the Caulfield lecture I got a better idea of what it was: Joint Application Design Sessions, where you rent a special room off site to

and basically get stuff done quickly. It is good when you have conflicts to resolve and therefore it is good to have the decision makers there, ready to make decisions. The JAD session seems to me to be a corporate version of something like a Start Up Weekend where a group of people get together and hammer out a new product from scratch and hopefully launch it.

Some other key phrases this week:


I really enjoyed the video that we watched in the tutorial, but I quibble that it was a “podcast” as we didn’t subscribe to it. However It was good to talk about new technologies, like podcasts and twitter, and remind everyone that we need to keep up with the new technologies to help us impress our clients. I reckon it was good to talk about stuff like that at the Clayton campus which feels a bit dinosaurish when it comes to IT technology sometimes. The content of the podcast, even though it didn’t directly mention Systems Analysis and Design, was extremely relevant. People are not good at knowing what they want, and are good at making up stories, so we have to be careful when it comes to asking people for their requirements. It also made me sit up and listen when Gladwell talked about the sip test versus drinking a whole can of coke or pepsi, and the changing beauty perceptions of the aeron chair. Lesson for Systems Analysis and Design? Pay attention to what people really need, not what they say they need.

Weekly Quiz

I found the Open ended questions frustrating for my method of quiz taking. The close ended ones are easier for me to work out the right answers. Confusing why “mock up” was in there, I guess to throw us when the correct answer is “prototype”.

Observation on learning techniques

There is one key thing when it comes to learning: remembering. While understanding is also crucial, it doesn’t help if you understand something and then don’t remember it (It also helps you remember if you understand.) I bet you’ve all been reading this blog post looking for a reference to werewolves- well here it is: you can use the werewolf effect to help you remember things. Rather, it’s the Von Restorff effect, which says that you will remember something that sticks out to you, and you are also more likely to remember something that is close to the “werewolf”. (This term “werewolf effect” is one I first read in a book on Memory when I was in grade 5, and even helped me to remember the name “Von Restorff” to google for the relevant wikipedia link after all these years.) This is why I liked the video about the exploding whale (and the earlier one about counting the basketballs) because they should help me to remember the Systems Analysis stuff also.

Another way that we remember is by telling and remembering stories- I don’t think I will forget Peter’s “*boop* *boop*” example where the shop assistants were scanning each item twice with the barcode scanner, and then wondering why the system was charging everyone double at the end of the month. Lesson? Observation is very important.

The final point of the requirements gathering process is to check back with your client and make sure that you are both on the same page and understand what the system will be built like.
Thanks for the “blog of the week” award last week P O’Donnel, I hope including another Dilbert cartoon doesn’t look like an attempt to sway the judges! Hey, I can’t help it if they’re relevant to this material. :)

March 19, 2010 | Leave a Comment |

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!

March 13, 2010 | Leave a Comment |

FIT2001 week 1: beware gorillas!

This week has been learning about what a Systems Analyst is, how to think about systems, and to be very aware of gorillas.

There is a problem with simply asking how the company wants you to solve their problem, or even what they think the problem is. It’s called situational blindness, and it means that people see what they want to see. When we design systems to solve problems, we need to be very careful that we observe how the company works, what the actual problem is, and the best way to solve it. It’s good to take input from the client, but we still need to be aware that they might be suggesting something that won’t actually fix the real problem they have. You’ll have to watch the lecture 1 from Caulfield to work out what I mean about the gorillas.

An analyst doesn’t need to be an expert in every kind of technology, but it helps to be aware of what is out there. The most important skill an analyst has is observation, and then using those observations to solve problems. It’s good to develop a few solutions to be able to pick the best one to solve the problem.

In the tutorial, we started to play with analysing a system. I remember getting frustrated with this exercise last year, but this year it has been easier to generalise the system into an object oriented sort of system. We were assigned the water system, at Clayton we are looking at the super system as well as the different parts of each system. I think we might get some more practical experience looking at a specific part of the system in more detail, but looking at the overview makes sense also. It has been good to look at the Characteristics, State, and Actions/Activities of each object in the system. I’m looking forward to next week to see how we can do better at analysing the system.

As a side note, using Google Docs was a great way for all of us in the group to collaboratively develop the document as we went, instead of having a “secretary”.

I must admit that the 2 hour slab of lecture is difficult for me. I find the Caulfield lectures fun to listen to, but after 1 hour I get restless and wonder if I could be using my homework time more efficiently. The Clayton lecture explained things a bit differently, and since POD is the head examiner I reckon it’s important to get the Caulfield perspective as well. I’ll be listening to the mp3s, maybe when I’m transiting. I’ve had success in the past of speeding up recorded lectures to 1.5x speed, (2x is often garbled) to get through the recordings in 2/3rds of the time, we’ll see how this goes.

The Quiz
I found the quiz very easy, I got a lot of the questions right without having to review the material. I was stuck in programmer mode however when I said false to “system construction is the last system development life cycle” – it is true that there is maintenance and testing needing to be done afterwards, but those processes involve a different life cycle and often a different part of the company. (Probably because I’m doing Project Management (FIT3086) this year also.)
Case stands for Computer-aided system engineering.
ERP is Enterprise Resource Planning, where a company commits to a set of software packages to deal with their systems of information.

I also found it amusing that there was an odd thumbs down icon in the quiz- I think it’s because the question was A/n (for A or An).

March 4, 2010 | 3 Comments |

FIT2001 week 0

Anecdotal evidence tells me that students who blog or journal about their experiences and newly acquired knowledge do better in those subjects. Perhaps this is because they solidify their knowledge through summarisation, and are able to recall this knowledge when doing assignments and the exam.

Happily, there is an optional 3% bonus for FIT2001 if I blog reflectively each week about what I’ve learned. I will be using the existing WordPress infrastructure on my own personal blog to write the posts, but will be using an RSS scraper to display these reflective FIT2001 posts on my newly acquired student web space (used for another of my subjects: FIT3084, Multimedia programming and the WWW.) (Due to complications I have just submitted the fit2001 category page as my blog.) Another advantage of blogging on my personal blog is to keep the posts I’ve written after the semester ends and my access to the Monash server ends. I will be using the category “fit2001″ to flag each of these posts.

I’m looking forward to FIT2001 this year, it is my last 2nd year subject and pre-requisite for my Computer Science Degree. I was enrolled in the subject last year, but as I was overloaded to 5 subjects (instead of 4), I had to drop one, and FIT2001 was the most logical one to drop. So, I’ve had an advance taste of the subject, and it looks like it will be lots of fun!

If you would like to subscribe to the RSS feed of just my FIT2001 posts, use this link: RSS for FIT2001 posts only.

March 3, 2010 | Leave a Comment |
« go back