Week 5

This week we learned a bit more about drawing models and we reviewed event tables in the lecture.

We started off by analyzing the difference between OO and traditional approach. From what I understood, basically the focus of traditional approach is on the processes, whereas the focus of OO approach is on the objects of the system. I came across these two terms quite often during my course, but I never quite understood what OO meant and how it was any different..it makes a bit more sense to me now.

I've seen the 2 different formats of an Event table, and I think I prefer the SJB format over the Stumpf one. I think that's because last week we were introduced to the event table using the SJB format, so it is a bit more familiar to me and I understand it better.

I've been drawing DFDs ever since I was in high school. This part was nothing new to me, except maybe for the 'Realtime Link' symbol. I had never seen that one before. At first I thought that this was used whenever data is sent to and from an object/process, but then a few slides later I realised this was not the case. This symbol was only used when data had to be updated in real-time and sent back and forth. Of course, the name "Real-time link" should have ticked me off :)

Layers of abstraction was also familiar to me and my memory was quickly refreshed after Cheryl explanation. Quite an easy concept to understand; as you go into more details about the processes, you go into deeper layers. The context diagram is the highest level of abstraction as it has less details about the processes...it is the most 'abstract'.

DFd fragments were the small chunks of processes that had to be described in details. If within a fragment, there is another process that needs to be in more details, then another DFD fragment is created (subprocess).


DFDs have to be consistent.
Data cannot be created out of nowhere...
All data that flows out of a process must have flowed into that process or must have been generated by some data that flowed into that process.

...and data cannot just disappear
All data that flows in a process must flow out of the process or be used to generate data that will flow out of that process.


I thought the decision table/tree was pretty cool. It was a very simple way to show a decision making process..instead of using lots of "if" and "else". I have used the decision tree in high school before for Maths, but I thought the table was cleaner way to display the same information.

I must admit that by the time we reached IE models, I was phasing in and out of the lecture (9am lectures...sigh). I vaguely remember terms like CRUD matrix and I remember the dependency diagram. It should all come back to me when I do my reading tonite.


As for the tutorial, it was pretty cool. I enjoyed making the class-diagram although I'm not sure I got it all right. The event table was pretty straight forward as well. I think it shouldn't be that hard to create one for the assignment.

I've been listening to the assignment mp3 this morning and there were a few things that I had not picked up on during the interview. Now I'm not sure what we are supposed to do about them. I should've asked about them during the interview, but unfortunately listening to the recording only once was not enough.

Event Tables...

This week we listened to the assignment MP3 in the tutorial. Honestly, I actually did not even realise there was an MP3 to listen to for the assignment. Good thing I attend classes then..haha :)

Lsitening to it once was not really enough, as I would phase out from time to time when trying to note down something important I heard. So I didn't get all the required details on the first time. Thank god for my lab partner who was actually listening to the recording while I was taking notes :)

The existing system seemed pretty simple and it reminded me A LOT of the case study for the IT in Organisations assignments. Instead of soft drinks delivery, it was about bread delivery.
During the interview, Daniel warned us that thinking too much about things the client did not ask for might make our assignments harder/longer.

I realised this was true after looking at the event table that was posted as an example on Moodle. Although a lot of the questions made sense, the client did not actually ask for these improvements to be made. I guess if we think it would make a lot of sense, then we just have to say that we have assumed the client agreed with this.

The event table itself was easy to understand. Although I think I need to actually make one to know if I'm having trouble understanding all the parts.

Humans don't know what they want...

That video we watched in the tutorial about the Aeron Chair was REALLY interesting. Its amazing how the human mind works (or doesn't work :) )

Based on that video, I observed that humans can be fooled into believing they like something (or not) and that their taste keeps changing alllllll the time. The key here, I guess, is to know when to take what they have to say seriously and when to push forward with an idea even though the response was not great.

Previously on SAD....

Things have been going pretty well for SAD.

We've been learning about System Analysts. This is the first time that I actually got a deeper insight into what they actually do and what is expected from them.

We've learned about the sets of skills an analyst is required to have (Fundamental knowledge of technology, technical, business and people skills) and also about his ethics and integrity. The role of the analyst in strategic planning was also covered. Basically we learned about all the important aspects surrounding an analyst and his contribution to the business.

We are now learning about the SDLC in more details every week. Ah, SDLC...I have been reciting these stages for too long now :)

1. Planning
2. Analysis
3. Design
4. Development
5. Testing
6. Maintenance
......

1. Planning
2. Analysis
3. Design
4. Development
5. Testing
6. Maintenance
......

1. Planning
2. Analysis
3. Design
4. Development
5. Testing
6. Maintenance
....

(that's me reciting the stages... :)

Each week SAD is going deeper into a different stage of the SDLC.

I've been keeping up with my readings most of the time. I don't always have time to read through the book, but definitely the study guide!

First Entry

Before even starting this semester, I was not really looking forward to this unit. As most core units were to me, I thought this one would be boring too. The only factor that can make me change my mind about core units is often the staff.

Usually if the lecturer/tutor is boring or not passionate, it puts me off as well. I stop attending lectures and sometimes even tutorials and lose interest completely. On the other hand, if the lecturer is funny and is very clear in his/her explanation, then it keeps me awake and I will be regularly attending classes..and I will even read study guides! :)

Fortunately for this unit, we ended up with Cheryl instead of someone from Clayton. I have had classes with Cheryl almost every semester since I started this course (this is now my last semester), and I knew that her lectures were always good and she's really funny. As expected, I haven't missed any lectures and always leave without any confusion.

It's the first time I've had a class with Daniel as a tutor. Although I've seen him around uni a lot, I had no idea what kind of tutor he was. To my surprise, he was really funny in the tute. This alone makes tutorials enjoyable, especially since on Thursdays I have a very long day. He is very patient and talks 'human' to us (it's easy to understand his point).

All in all, great combo. It is similar to the staff we had for 'IT in organizations'... makes all the difference.

As for the unit content itself, it isn't as boring as Project Management. It also helps that we have already learned some parts of it in other units ( for e.g. IT in Organizations). The content is pretty straight forward and easy to understand (for the moment). I only have access to an old edition of the prescribed book, but I find that it is just as good as the new one. The gist of it is still the same.