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):
- Sometimes we model for documentation, but be careful that the model is still useful and that you’re not just modelling for the sake of generating models.
- Sometimes an actor might be another system or organisation rather than a person.
- repeat or loop = asterisk * in UML
This week I found the most helpful method for studying was the quiz, because there were a lot of terms I didn’t know.
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.
- woops the answers are shuffled randomly, so “All of the Above” appeared as “a” the first answer option, above the others! When you see “all of the above” it is most likely the answer.
- what are System Sequence Diagrams?
(A) System Sequence diagram is one that shows the sequence of messages between an external actor and the system during a use case or scenario.
- what is an object life line? No, not a part of the new game show Who wants to be a
MillionaireSystems Analyst. The object lifeline is used in a System sequence diagram to show the passage of time for an object, it’s a vertical line.
- what is a scenario? A scenario is a version of a use case, such as when two use cases are similar enough that they can be made into one with a minor variation that is the scenario.
- you can create temporal events manually.
- what is an interaction diagram? a System sequence diagram is a kind of interaction diagram.
- return of data is shown as a dashed line with an arrow.
- I protest: clearly object oriented is the same as object-oriented, this highlights issues with open ended quiz questions with specific answers required.
The ____________________ approach to systems development requires several interrelated models to create a complete set of specifications.
Answer: object oriented
Correct answer: object-oriented
Well, now to finish off my Event Table.
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”.
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.
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:
- Don’t over model- we model for understanding and learning about the system.
- There are 3 types of models:
- graphical (can be like a whiteboard and marker- I like whiteboards.)
- Mathematical (formulas and ways to manipulate the data.)
- Descriptive (narrative, important to agile methodology.)
- you can move from a good model directly to the code. (CASE tools)
- they have standards (like UML) to help us talk to other IT people about the model without needing to explain how the modelling language works.
Events, and that elusive event table! Pay attention here, this is basically the how-to guide for assignment 1a.
- Events are good to look at because of “event driven programming”, things a system has to react to.
- an external event: something outside of the system. (fairly obvious to guess)
- a temporal event: a time based event. (bit trickier, still managed to guess for the quiz.)
- a state event: (no idea what this was at first!) something inside the system triggers an event, for example when a printer runs out of paper and tells you about it.
- Events can be hard to identify properly, so give it a few passes and revisions.
- Name, Trigger, source, activity/use case, response, destination: event table columns.
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 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.
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.
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.
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
- minimise distractions
- send a “this project is important” vibe
- send a “you are valuable to this project” vibe
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:
- Functional Requirements: what the system has to do.
- Non-functional Requirements: how the system has to do it.
- Questionnaire: good for getting data from a lot of people (users, stakeholders)
- Interview: good for getting detailed information about the system.
- Open Items list: good for tracking issues and fixing them.
- prototype: original, primitive, from protos “first” + typos “impression”
(prototype from etymology online)
- logical model: information based, like “invoice details”
- physical model: physical object based, like “the invoice”
- Activity Diagram
- Structured Walk through
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.
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.
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.)
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.
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!
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.
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.
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.