A little girl was talking to her teacher about whales.
The teacher said it was physically impossible for a whale to swallow a human because even though it was a very large mammal its throat was very small.
The little girl stated that Jonah was swallowed by a whale.
Irritated, the teacher reiterated that a whale could not swallow a human; it was physically impossible.
The little girl: said, "When I get to heaven I will ask Jonah".
The teacher: asked, " What if Jonah went to hell?"
The little girl: replied, "Then you ask him".
Wednesday, September 24, 2008
Wednesday, September 17, 2008
Wk 10: Use Case Realization
After last week horrible podcast, i've learnt to appreciate having a living lecturer speaking infront of the electronic rostrum. It is nice to have Rob back and hope he is all well from last week.
This week, we talked about use case realization, the design of class diagrams, interaction diagrams, sequence diagrams and collaboration diagrams. From assignment 1b, i should have sufficient practice for use case diagram and the class diagram. That assignment, we are talking and showing the functions of the system. This few diagrams shows how objects react with each other. The simplified or summarised name for these diagrams are known as object-oriented design.
I've not really read up much on this diagrams therefore unable at the moment to write much about each diagrams. But a quick glance through the slides, i am refreshing some of my memory through the lecture. Guess my next post will be much more detailed in the diagrams.
This week, we talked about use case realization, the design of class diagrams, interaction diagrams, sequence diagrams and collaboration diagrams. From assignment 1b, i should have sufficient practice for use case diagram and the class diagram. That assignment, we are talking and showing the functions of the system. This few diagrams shows how objects react with each other. The simplified or summarised name for these diagrams are known as object-oriented design.
I've not really read up much on this diagrams therefore unable at the moment to write much about each diagrams. But a quick glance through the slides, i am refreshing some of my memory through the lecture. Guess my next post will be much more detailed in the diagrams.
Friday, September 12, 2008
Assignment 1b completing
This assignment has been taking alot of my time recently. I have been doing the requirements and diagrams. And now i see the fruit of my labour. I'm not aiming for a HD but hopefully get a decent mark to make my life easier. Also, to prove that what i understand from this point onwards is correct.
Tuesday, September 2, 2008
Professional Report
The time has come to start doing and worrying about the report on analysis. A major 20% of the overall grade. It is something that will cause a worry among my peers. Hehe... Well, i've started by creating small steps or tasks that are required to be done. Once each task is done, i can compile them together to make the actual report.
Monday, September 1, 2008
Week 7: Ending Analysis Phase
This is the final lecture regarding analysis. I realise that we took three weeks to fully complete analysis studies. So this must have certain importance in this unit. The analysis of a system is very the basis of the system. As we discussed before, if the analysis is not done properly or critical tasks are not taken in during analysis the system will fail to fit the requirements of the client.
On this week, we talked about how much system costs, how much automation the system has to be, request for proposals, etc. Compared to the slides from the past week, this was rather done quickly. It was not rushed through and Rob really wanted to slow down but i think he has done a good job trying his best to slow down his talking.
Part of teh lecture we discussed about how systems are developed. It can be done via internal or external sources. Internal sources require the organisation to develop the system with their own staff. External sources means getting people outside the organisation to develop the system.
Pros and cons? Internal means staff from the organisation are asked to develop the system. This means that they are taken from their usual workload and given this new task. Sensitive data is kept within the organisation when the system is being developed in-house. Cost of developing is lower compared to external sources.
External sources are organisations that are experts in developing systems. These companies comes in, plan, analyze and design the system. They are good at what they are doing and they don't come cheap. I know how much a simple ERP solution cost while i was interning at Microsoft. Cost is not the important part. It is trust. Trust that these external sources do not leak sensitive data or even customer data to their rivals. As these organisations deal with plenty of other customers, the is a risk of losing sensitive data to competitors. MS made sure that the project leader sign a document with the company to trust them. Trust them not to comprommise sensitive data. If discovered, MS will pay damages. Usually amounts that i have dreamed of winning. Haha...
Lastly, we discussed about the professionalism in our work. How we present our analysis in a profesional way. How companies will ask for quote on developing the system. This is important as analysis understood by just the developers is not much of value when the clients do not understand them. Therefore we must create documents that satsify both parties than money will start to roll in.
On this week, we talked about how much system costs, how much automation the system has to be, request for proposals, etc. Compared to the slides from the past week, this was rather done quickly. It was not rushed through and Rob really wanted to slow down but i think he has done a good job trying his best to slow down his talking.
Part of teh lecture we discussed about how systems are developed. It can be done via internal or external sources. Internal sources require the organisation to develop the system with their own staff. External sources means getting people outside the organisation to develop the system.
Pros and cons? Internal means staff from the organisation are asked to develop the system. This means that they are taken from their usual workload and given this new task. Sensitive data is kept within the organisation when the system is being developed in-house. Cost of developing is lower compared to external sources.
External sources are organisations that are experts in developing systems. These companies comes in, plan, analyze and design the system. They are good at what they are doing and they don't come cheap. I know how much a simple ERP solution cost while i was interning at Microsoft. Cost is not the important part. It is trust. Trust that these external sources do not leak sensitive data or even customer data to their rivals. As these organisations deal with plenty of other customers, the is a risk of losing sensitive data to competitors. MS made sure that the project leader sign a document with the company to trust them. Trust them not to comprommise sensitive data. If discovered, MS will pay damages. Usually amounts that i have dreamed of winning. Haha...
Lastly, we discussed about the professionalism in our work. How we present our analysis in a profesional way. How companies will ask for quote on developing the system. This is important as analysis understood by just the developers is not much of value when the clients do not understand them. Therefore we must create documents that satsify both parties than money will start to roll in.
Monday, August 25, 2008
Week 6:Use Case Modeling
Last week we started on use case modeling and how the event table assist in designing use case diagram. We touched on the rules, the diagrams and the way to interpret the use case models. The use case diagram puts how words in the event table into a diagram to see the system and how actors or users interact with the system.
After a thorough walkthrough of the use case diagram, we went on to activity diagram and the class diagram. In the class diagram, we discuss how objects in the system gets created and how they interact with each other. Also what are the attributes and function the object has.
After confusing us with so many diagrams, Rob threw in another diagram; sequence diagram. ARGHZ!!! Well... The sequence diagrams shows how a use case goes through all the functions till it ends. It mimics almost like the activity diagram but it shows how the objects interact with each other.
All in all, the diagrams go through a flow. We start off with the events table. After stating all the possible events we move on to drawing the use case diagram. The use case diagram now shows the functions of the system and the boundary of where the user stands against the system. From the use case diagram, we design the class diagram so as to design the database. This would be objects that will be in or out of the system. Lastly, we draw the sequence diagram to explain further or more in-depth.
Sometimes we take a step back to the previous diagram to cross-reference it. It ties up the loose ends of the system and makes it more robust. I guess its how this diagrams comes together in relation and how we use them to design successful systems. Even though more than 50% of systems fail. :D
After a thorough walkthrough of the use case diagram, we went on to activity diagram and the class diagram. In the class diagram, we discuss how objects in the system gets created and how they interact with each other. Also what are the attributes and function the object has.
After confusing us with so many diagrams, Rob threw in another diagram; sequence diagram. ARGHZ!!! Well... The sequence diagrams shows how a use case goes through all the functions till it ends. It mimics almost like the activity diagram but it shows how the objects interact with each other.
All in all, the diagrams go through a flow. We start off with the events table. After stating all the possible events we move on to drawing the use case diagram. The use case diagram now shows the functions of the system and the boundary of where the user stands against the system. From the use case diagram, we design the class diagram so as to design the database. This would be objects that will be in or out of the system. Lastly, we draw the sequence diagram to explain further or more in-depth.
Sometimes we take a step back to the previous diagram to cross-reference it. It ties up the loose ends of the system and makes it more robust. I guess its how this diagrams comes together in relation and how we use them to design successful systems. Even though more than 50% of systems fail. :D
Friday, August 22, 2008
Event Table is ready!!
I've completed my event table. As with all assignments, one will worry whether is this the correct answers or even the correct way of answering it. Well.. Here goes nothing!!
Sunday, August 17, 2008
Week 5: More Analysis and More Diagrams...
We are heading into the main part of the unit, about designing systems and drawing diagrams. Not just drawing, we have to learn to see how users interact with the system and what operations they do with the system. As we know, systems are meant to assist users to ease their workflow or increase efficiency. If a system is designed badly, or does not meet the users' requirements, it is badly designed.
We touched more on certain diagrams and did a sample during the tutorial. It was a reminder of my past experience while having internship. The only difference was the stress or pressure is not present. Hehe...
Last week we touched on event table, which is the upcoming assignment. Now we start another diagram, data flow diagram(DFD). The DFD is able to show how the levels of interaction from users to the system and datastores. There is alway a context level that shows what are the major operations or functions this system is going to handle. As we enter each function, there are more operations which we can go deeper. As we go deeper, the more intricate the operations become.
We touched more on certain diagrams and did a sample during the tutorial. It was a reminder of my past experience while having internship. The only difference was the stress or pressure is not present. Hehe...
Last week we touched on event table, which is the upcoming assignment. Now we start another diagram, data flow diagram(DFD). The DFD is able to show how the levels of interaction from users to the system and datastores. There is alway a context level that shows what are the major operations or functions this system is going to handle. As we enter each function, there are more operations which we can go deeper. As we go deeper, the more intricate the operations become.
Saturday, August 9, 2008
Week 4 Revised
During the tutorial, we interviewed our tutor to find out the events and requirements of the system. It was a little nerve-wrecking initially but David made it very enjoyable which reduced the stress level inside me.
We started by activating our recording mechanism and by doing that, we learn a very valuable lesson from David.
"When you are recording a conversation, it is polite to ask the person if they mind that the conversation is being recorded," said David. I would say that would be the one lesson that is not covered in the unit but a valuable life lesson.
We continued the interview and got what we wanted. I would say not fully what we want or covers all that is required, but that some what mimics real life systems design. A single interview usually don't give you all the requirements. That depends on the size of the system.
We started by activating our recording mechanism and by doing that, we learn a very valuable lesson from David.
"When you are recording a conversation, it is polite to ask the person if they mind that the conversation is being recorded," said David. I would say that would be the one lesson that is not covered in the unit but a valuable life lesson.
We continued the interview and got what we wanted. I would say not fully what we want or covers all that is required, but that some what mimics real life systems design. A single interview usually don't give you all the requirements. That depends on the size of the system.
Tuesday, August 5, 2008
Week 4: Analyze the Analysis
We discussed about analysis this week. We discussed how to put our analysis into models. Models such as the use case model, event table, class diagram and many more. We put more emphasis on the event table as it is the upcoming requirement for our assignment.
An event can be classified under three different types; External, Temporal and State(Internal). External events are events that happen outside the system, usually initiated by an external agent or factor. A simple example would be a passenger pressing the lift button to call for the lift. Temporal events occurs when the system reaches a certain point in time. An example to that would be daily backups by the servers. By a certain time listed by the Administrators, the system will execute a backup event. The internal or state event is stuff that happens inside the system. This events are very minute like the system accessing the database.
We went on to talk about things. Things that affect the system one way or another. I think they are just things that interact with the system or a word/noun to describe something. I do not know for sure what it is but that will have to leave to the reading up then...
An event can be classified under three different types; External, Temporal and State(Internal). External events are events that happen outside the system, usually initiated by an external agent or factor. A simple example would be a passenger pressing the lift button to call for the lift. Temporal events occurs when the system reaches a certain point in time. An example to that would be daily backups by the servers. By a certain time listed by the Administrators, the system will execute a backup event. The internal or state event is stuff that happens inside the system. This events are very minute like the system accessing the database.
We went on to talk about things. Things that affect the system one way or another. I think they are just things that interact with the system or a word/noun to describe something. I do not know for sure what it is but that will have to leave to the reading up then...
Sunday, August 3, 2008
Week 3 Revised
It's another roller coaster week. Assignments are getting dued and work load is increasing as the week advances. The nightmare seems to be happening all over again. I do not think i can survive this semester! Noooooo~~
That is the usual thinking of a student. No matter where he/she is studying, a student goes through phases just like how a caterpiller morphs into a butterfly.
This week i didn't do much revision regarding this topic. Most of my time dedicated to this unit is concentrated towards the formulation of questions for the upcoming interview. I have been through job interviews, i have conducted job interviews, i have even participated in a systems interview. Like i said before, i'm not good at it as i've only experienced. Experience does helps, but it does not makes you prepared for the coming.
After this... I guess its full steam assignment work.
That is the usual thinking of a student. No matter where he/she is studying, a student goes through phases just like how a caterpiller morphs into a butterfly.
This week i didn't do much revision regarding this topic. Most of my time dedicated to this unit is concentrated towards the formulation of questions for the upcoming interview. I have been through job interviews, i have conducted job interviews, i have even participated in a systems interview. Like i said before, i'm not good at it as i've only experienced. Experience does helps, but it does not makes you prepared for the coming.
After this... I guess its full steam assignment work.
Tuesday, July 29, 2008
Week 3: Finding out Systems Requirements
The lecture was about requirement gathering and the skills to find out what we need. In the SDLC phase, we are now in the analysis phase. This is where the system designers sit down with the users or owners of the systems and figure out what are their needs and wants. There are two methods when introducing a new system, briefly explained as either the system wraps around the users or the users adapt to the new system.
The first is not replacing the current work process but just digitising or making it simpler or faster. The new system would produce better effiency from the users.
The other method is replacing certain business processes and streamlining them. Users have to be retrained to use the system. Simply put, the users revolved around the system.
Also we discussed in the lectures about how to ask questions on getting the requirements of the system. If the requirements are not gathered properly, the system might have conflicts with the users or the business process. Also reviewed together with the questions are the paperwork that are used currently. Do we duplicate them in the new system or do we need to redesign them to fit the system?
Joint Application Design(JAD) were highlighted near the ending. A JAD is where the users or stakeholders of the system sits down together with the project team members. Certain resources must be available such as an overhead projector, whiteboard, printer, etc. The sessions' minutes are taken down and documented in case. This would continue the flow of events and even documentation would be easier at the end of the project.
That is about it... My next post would be about my revision on the topic. Most probably would be a review of the questions i would have on hand before i enter the tutorial for the interview.
The first is not replacing the current work process but just digitising or making it simpler or faster. The new system would produce better effiency from the users.
The other method is replacing certain business processes and streamlining them. Users have to be retrained to use the system. Simply put, the users revolved around the system.
Also we discussed in the lectures about how to ask questions on getting the requirements of the system. If the requirements are not gathered properly, the system might have conflicts with the users or the business process. Also reviewed together with the questions are the paperwork that are used currently. Do we duplicate them in the new system or do we need to redesign them to fit the system?
Joint Application Design(JAD) were highlighted near the ending. A JAD is where the users or stakeholders of the system sits down together with the project team members. Certain resources must be available such as an overhead projector, whiteboard, printer, etc. The sessions' minutes are taken down and documented in case. This would continue the flow of events and even documentation would be easier at the end of the project.
That is about it... My next post would be about my revision on the topic. Most probably would be a review of the questions i would have on hand before i enter the tutorial for the interview.
Wednesday, July 23, 2008
Week 2 Revised
I took a look at the slides that Rob briskly went through in the last lecture. I would say it was quite abit that he went through rather quickly. Hopefully they are not in the exam. Currently i can see that the main stuff are the diagrams and the study of system designing. I have some background knowledge of systems design but it is just a basics.
I have led a team during my technical studies in Singapore in creating a system where a company, around 15 employees, uses it daily. It was a tough process but it was rather rewarding as the system is still running at its 4th year and the maintenece people are holding up the system rather well. They comment that the system is something that did increase the productivity. I was proud of it. Well... Hopefully my past experience of designing and maintaining a system will help me understand this unit fairly well.
I have led a team during my technical studies in Singapore in creating a system where a company, around 15 employees, uses it daily. It was a tough process but it was rather rewarding as the system is still running at its 4th year and the maintenece people are holding up the system rather well. They comment that the system is something that did increase the productivity. I was proud of it. Well... Hopefully my past experience of designing and maintaining a system will help me understand this unit fairly well.
Monday, July 21, 2008
Week 2: SDLC and The Works
I have not attended the previous lecture as i was stuck in Singapore. Long story... But i manage to return last week and quickly got back to my lifestyle here in Melbourne. My first lecture for Systems Analyst and Design. I'm a programmer when i was in Singapore and this is something that i love and hate. Love it as it shows you the overview of the system. Hate it as there is alot of work to do. Love it as is can be a plan to follow tightly when you are fully engrossed in coding. Hate it as once you screw this up and proceed to coding, you are really screwed up.
The lecture this week is about the System Design Life Cycle(SDLC). As Rob says it, it is something that every idea will go through from just words to a physical system. Well... Not all ideas eventually becomes a physical system. We gone through the phases of the SDLC, planning, analysis, design, implementation and support. Also went through the ways of going through the phases, advantages and disadvantages. Also certerin tools that we can use to develope a system.
Approaches to system development has been touched on. Ways like Structure Chart, Data Flow Diagram, Entity-Relationshop Diagram, etc. Another popular way is using Object-Oriented. Using objects in a computer system and designing it to fit together into a system. Objects have attributes and functions, or descriptions and behaviours.
Class Diagrams are also used as a way to showcase a system. And the others...
Ended the lecture in a rush... Guess the details are to be settled in own time own target(OTOT).
The lecture this week is about the System Design Life Cycle(SDLC). As Rob says it, it is something that every idea will go through from just words to a physical system. Well... Not all ideas eventually becomes a physical system. We gone through the phases of the SDLC, planning, analysis, design, implementation and support. Also went through the ways of going through the phases, advantages and disadvantages. Also certerin tools that we can use to develope a system.
Approaches to system development has been touched on. Ways like Structure Chart, Data Flow Diagram, Entity-Relationshop Diagram, etc. Another popular way is using Object-Oriented. Using objects in a computer system and designing it to fit together into a system. Objects have attributes and functions, or descriptions and behaviours.
Class Diagrams are also used as a way to showcase a system. And the others...
Ended the lecture in a rush... Guess the details are to be settled in own time own target(OTOT).
Subscribe to:
Comments (Atom)
