FIT2001 Systems Analysis and Design @ Monash

FIT2001 Systems Analysis and Design @ Monash
By Peter O'Donnell
About this podcast
This is a podcast supplementing material for the unit FIT2001 Systems Analysis and Design at Monash University for Semester 1, 2010.
In this podcast

Podcasts like "FIT2001 Systems Analysis and Design @ Monash"   · View all

By powered by
By I Need A Change
By Jake VanHuss
Latest episodes
June 3, 2010
The last lecture, going over the aims and role of the unit, and helping you prepare for the exam.
May 28, 2010
his week we wrap up design in the lecture. We look at the inputs and outputs to the system that don't involve direct human interaction. The integrity and security of these interfaces is of particular concern. One important type of output "reports" - a major segment of the IT industry - is also examined.
May 24, 2010
POD walking through the "Look up item availability" use case and making a sequence diagram using VP for UML.
May 20, 2010
The interface has always been important, but its role in analysis and design is increasing in importance and focus. Users are becoming more sophisticated and demanding as technologies like the web become more used and useful. Interface design also represents a curious point of tension between analysis and design - interface prototypes are a very useful tool to aid and provoke the development of requirements, yet interface design is a "design" discipline very much concerned with how a system works. This weeks lecture provide an introduction to the field of interface design and some practical points of skill (and theory) which you can apply to your assignment work (assignment 2
May 17, 2010
This week we look at the process of design for object oriented systems. We will examine and then practice the process used to turn use cases into sequence diagrams (and other interaction diagrams). These help to ensure that we have a set of classes in the application that will be able to perform the functions identified during analysis. You need to do this for assignment 2 (for just 1 use case) and will also be asked to do this in the exam.
May 7, 2010
As we look at the detail of design, we will begin with structured design, This is nice to know - there is a very neat process that transforms the DFDs from analysis to structure charts that tightly define the modules and functions of a system. Perhaps, more importantly, the principles of good design - coupling and cohesion - first developed to aid structured design are explained. This principles are also relevant to object design (but many think easy to understand in their structured form) .
April 29, 2010
This week the lecture examines the design phase and all the activities that are performed during systems system. In some ways this provides a summary of the detail that will come in the following weeks. We will also think about the inputs to design that are provided by analysis.
April 22, 2010
Our last lecture focussed on analysis looks at the remaining major tasks of analysis - the purpose of all the models of data and process we build is to understand and document the system - now we look at how we move to design. Decisions have to be made about what the system will do - what's in and what's out, how the system will be built, what it will cost and what the benefits will be - and the results have to be presented to management so they can approve (or not) the the phases of development.
April 17, 2010
This is the main week on object analysis. We look in the lectures at how event tables - and other general information - is turned into more detailed descriptions of system functionality called use cases. We will look at use case diagrams, narratives and also how activity diagrams can be used to model use cases.
April 7, 2010
This week the lecture focuses on structured analysis - data flow and entity relationship modelling. You need to know how this is done and to be able to read them diagrams, but not draw them (with the exception of context diagrams - you will need one of those for your assignment). However, perhaps more importantly, learning abut structured analysis will help you understand analysis more generally and improve your UML (object-based) modelling. The need to think of things logically, rather than physically is clearer in structured design and will be a major "take-away" from this week that will help you do better object analysis.