Week 5

Events! ok so after the tute i think im finnally getting my head around events verses activities. But have a feeling that i may need to be revise this when completing the first assignment. I find i learn amost everything from doing the assignments. From the information presented in the lecture the DFD's seem like its going to take a LONG TIME to get them close to the real life abstraction, so i better get a move on and get this assignment into gear.

Week 4:

Begining analysis (but does not reference the chapter of the same name in the book, really means chapter 5):

The starting point of analysis is is attempting to model an event. An even being an occurrence at a specific time and place that triggers a system process. There are three types of events:

External
- Outside the system
- Initiated by external agent or actor

Temporal
- Occurs as result of reaching a point in time
- based on system deadlines

State
- Something inside system triggers processing need

The rest of the lecture was basically about all the different modelling diagrams contained in the UML. It may become confusing when differentiating them because a lot of them are structured the same way and include the same information. We have already looked at Class diagrams in java and ERD/DSD in database so I’m not too worried, but intend to go back and look over the differences.

My father is a member of a private golf club that has such a system in place, so I’m aware of most of the extra information need to operate. This helped immensely when interviewing the mock client because i could already foresee the answers to the questions i had and was merely clarifying what i already knew.

Hu is on first?

Week 3

Requirements Gathering:

We all know about the different techiniques for information gathering 'reviewing existing documents, interviews, observation ect...' and what each strength and weeknesses assocated with these are. This week we looked at how a system analyist would go about aquiring the information needed to create the system from its users.

We identified that users dont always work the way the organisation created system works so the correct way and acctual way of doing something has to be identified during this process.

There are two types of requirements functional (activities systems must proform) and non-functional (such as useability, reliability, and security requirements).

PODCASTS: I cant help but think that this topic was brought up in the tutes as a way of infulencing more individuals to sign up for the unit podcast.. *casts a disparaging look*

Amusing facts: Tutor has left the room twice to take calls :P

Week 2

(Week 2)

There was a lot of information to take in in the lecture! We covered the SD methodology and the different approachs (waterfall, overlap, itteration) to SD.

The tute was a repeat of the last one, which was just inforcing the skills we learnt in the first one.

Update: oops i just made this post in the last two minutes of the tute and was going to come back to it. So now here i am :P

Yeah ok as i was saying there was a lot of information! But its basically information we have covered either in earilier units or VCE. So im not too worried about how much we had to absobe but i have gone over it again just to make sure i know the majority of the imformation.

Till next we meet,
Paul

I LEFT HOME EARLY!

Sitting I’m my tute wondering what is the appropriate amount of time I should stay if the tutor hasn’t turned up… You would think what half an hour? (24 minutes and counting :P). Im going to try and battle on by myself.

Wish me Luck

Till next we meet,
Paul

(UPDATE: 29 minutes, ow his lucky)

Tute one

Good start to the unit paul, 10 minutes late to the first tute! Grr over an hour with the traffic! (Yet still arrive before it begins)

Ok so the tute has started off a bit slow, first we discussed what a system is and what the role of a systems analysis is. I think it was very important that we did this because everyone was still a little iffy about what these were in relation to the unit, people were getting confused with an information system rather than just a system.

The exercise was to divide into groups and select a subsystem of the water supply system. We selected the distribution system, and had a bit of a hard time identifying the stages in which the water must go through to reach the end consumers. None of the websites that were linked as extra resources provided a clear outline of the processors that take place (or rather we couldn’t find the relative material on the resources provided). We sat down and logically thought about how the system worked and then created, what would probably be very simplistic in relation to real life, staged process.

Overall i believe it served its purpose, a simplistic introduction to how a systems analyst tackles a problem that wasn’t overloaded with information we will never remember, nor need.

Week one over and only twelve more to go!

Till next we meet,
Paul