Automation System Boundary:
-Seperation of manual and automated processes
The system flow chart:
- Represents various computer programs, files, databases associated with manual processing that make up a complete system
The structure chart
- Describes functions and sub functions of each part of the system, relationship between modules of a computer
- Each module performs a specific function
Module algorithm deisng: Pseudocode
- Descrobes internal logic of of modules
- Syntax should mirror development code
- Three types of control statements used in structured programming:
- sequence: sequence of executable statements
- decision: if-then-else logic
- iteration- do-until or do-while
Three-Layer Design
- View layer
- Business logic layer
- Data layer
Monday, May 28, 2007
Week 8- The Nature of Good Design
-Design- process of describing, organising and structuring system components at architectural design level and detailed design level
- converts functional models from analysis into models that represent the solution, focused on technical issues, less user involvement
Design Phase Activities:
- Design and intergrate the network
- Design the application architecture
- Design the interfaces
- Design the system interfaces
- Design and intergrate the database
- Prototype for design details
- Design and interfrate system controls
Deployment Environment:
- Single- Computer and Multi-user Architecture
- Centralised and Distributed Architecture
Computer Networks:
- Set of transmission lines, specialised hardware and communication protocols
- LANs, WANS, Internet, Intranet
Application Architecture:
- Standards and tools used in an organisation
- Client-Server Architecture
- Inernet and Web-based Application archieture
- converts functional models from analysis into models that represent the solution, focused on technical issues, less user involvement
Design Phase Activities:
- Design and intergrate the network
- Design the application architecture
- Design the interfaces
- Design the system interfaces
- Design and intergrate the database
- Prototype for design details
- Design and interfrate system controls
Deployment Environment:
- Single- Computer and Multi-user Architecture
- Centralised and Distributed Architecture
Computer Networks:
- Set of transmission lines, specialised hardware and communication protocols
- LANs, WANS, Internet, Intranet
Application Architecture:
- Standards and tools used in an organisation
- Client-Server Architecture
- Inernet and Web-based Application archieture
Week 7- Finishing Analysis
Deciding scope and level of automation:
- Scope- Determins business functions that will be included in the new system
- Level of Automation- how much computer support exisits for the functions included in level
- Scope creep- additional requests after requirements have been defined and decions made, typically clients request more then the budget allows
Level of Automation:
- Low = simple computer records keeping
- Medium = combines features from low and high automation levels
- High = system takes over processes of business function (ok, I dont know if that makes sense..i think i abbreviate my notes too much)
Deployment Environment characteristics:
- Compatability with system requirements
- Compatability among hardware & software
- Required interfaces
- Conformity with IT strategic plans
- Cost & Schedule
Implementation alternatives:
- Buy vs Build
- In-house vs Outsourced
- The implementation alternative choosen should consider these 3 areas: general, technical and functional requirements
Contracting with Vendors:
- Generating Request For Proposal (RFP)
- Formal document sent to vendors if in-house development isn't selected
- States the requirements and solicits proposed solutions
- Competitive contract offer
- Contents: Intro & Background; overview of need; desciption of technical, functional and general requirements; requested provider and project information; details for submitting a proposal and evaluation criterea and process.
Benchmarking and choosing a vendor:
- Benchmark- evaluate the system against a standard
- Contract:
- Fixed - $ contract - ROV
- Cost +% - ROP
- Cost + fixed fee - RSBB
- Scope- Determins business functions that will be included in the new system
- Level of Automation- how much computer support exisits for the functions included in level
- Scope creep- additional requests after requirements have been defined and decions made, typically clients request more then the budget allows
Level of Automation:
- Low = simple computer records keeping
- Medium = combines features from low and high automation levels
- High = system takes over processes of business function (ok, I dont know if that makes sense..i think i abbreviate my notes too much)
Deployment Environment characteristics:
- Compatability with system requirements
- Compatability among hardware & software
- Required interfaces
- Conformity with IT strategic plans
- Cost & Schedule
Implementation alternatives:
- Buy vs Build
- In-house vs Outsourced
- The implementation alternative choosen should consider these 3 areas: general, technical and functional requirements
Contracting with Vendors:
- Generating Request For Proposal (RFP)
- Formal document sent to vendors if in-house development isn't selected
- States the requirements and solicits proposed solutions
- Competitive contract offer
- Contents: Intro & Background; overview of need; desciption of technical, functional and general requirements; requested provider and project information; details for submitting a proposal and evaluation criterea and process.
Benchmarking and choosing a vendor:
- Benchmark- evaluate the system against a standard
- Contract:
- Fixed - $ contract - ROV
- Cost +% - ROP
- Cost + fixed fee - RSBB
Week 6- Use Case Modelling
OO Models:
- Class/Domain model: definition of system comoments
- Use case diagrams/ descriptions: show user roles and how they use the system; graphical models that summarise information about actors and use cases; use event table to identify major uses
- System Sequence Diagrams: define inputs, outputs and sequence of interactions between user and system for a use case
- Statechart diagrams: describe object state
- Activity diagram: describe user activities
CRUD analysis:
- Create, Read/Report, Update, Delete
- An IE technique used to identify event table events/ develop use case diagram
- Three levels of detail: brief, intermediate and fully developed
Activity Diagrams:
- Used to document work flow of business process activities for each use case scenario
- Standard UML diagram
SSD notation:
- Actor = stick figure
- Object = rectangle
- Message = arrow (not sure, my notes are a bit scribbled)
- Lifeline = verticle line under object (passage of time)
- dashed verticle line (creation and deletion of thing isnt important to the scenario)
- long narrow rectangles (activation lifelines- object is active only during this part of scenario)
The Domain Class Diagram:
- Provides definition of system components
- Contains important class structure information for implementation with OO programming
- Conceptual data model to describe classes for database definition
- Class/Domain model: definition of system comoments
- Use case diagrams/ descriptions: show user roles and how they use the system; graphical models that summarise information about actors and use cases; use event table to identify major uses
- System Sequence Diagrams: define inputs, outputs and sequence of interactions between user and system for a use case
- Statechart diagrams: describe object state
- Activity diagram: describe user activities
CRUD analysis:
- Create, Read/Report, Update, Delete
- An IE technique used to identify event table events/ develop use case diagram
- Three levels of detail: brief, intermediate and fully developed
Activity Diagrams:
- Used to document work flow of business process activities for each use case scenario
- Standard UML diagram
SSD notation:
- Actor = stick figure
- Object = rectangle
- Message = arrow (not sure, my notes are a bit scribbled)
- Lifeline = verticle line under object (passage of time)
- dashed verticle line (creation and deletion of thing isnt important to the scenario)
- long narrow rectangles (activation lifelines- object is active only during this part of scenario)
The Domain Class Diagram:
- Provides definition of system components
- Contains important class structure information for implementation with OO programming
- Conceptual data model to describe classes for database definition
Monday, May 7, 2007
Blog.
I am doing this blog for the sole reason that im apparently meant to have 10 by the end of the semester.
My future blogs will continue with the same format my previous ones have, lecture summaries...however when i get around to it then i shall do it.
Blogging is a waste of time.
Thankyou.
My future blogs will continue with the same format my previous ones have, lecture summaries...however when i get around to it then i shall do it.
Blogging is a waste of time.
Thankyou.
Monday, March 26, 2007
Week 5- The Traditional or structured approach to analysis
Today's lecture was just basically a summary of things we've already learnt about in the past...I learnt about DFDs in about year 11 and then again in year 12...and then again last year in IT in orgs....so yeah...I cbf writtin a summary of todays lecture...
That is all.
//End blog.
That is all.
//End blog.
Monday, March 19, 2007
Week 4- Beginning Analysis
Todays lecture covered:
-Analysis models
-Events
-Things and systemr requirements
-UML
Analysis Models:
-Help us understand the system
-Types of models:
.:. Mathematical- formula's, accounting
.:. Descriptive- event tables, narrative memos
.:. Graphical- diagrams, schematic representations
-Models used in analysis- event list, dfd, ERD, class diagrams
Events:
-Occurences at a specific time and place
-Types of events:
.:. External- outside the system
.:. Temporal- reaching a point in time
.:. State- internal trigger
Things and system requirements:
-define sys requirements by understanding what information needs to be stored
-what things does the sytem need to know about and store information about?
-characteristics of thigns:
.:. relationship- cardinality
.:. attribute - specific peice of information about a thing
And that will do.
-Analysis models
-Events
-Things and systemr requirements
-UML
Analysis Models:
-Help us understand the system
-Types of models:
.:. Mathematical- formula's, accounting
.:. Descriptive- event tables, narrative memos
.:. Graphical- diagrams, schematic representations
-Models used in analysis- event list, dfd, ERD, class diagrams
Events:
-Occurences at a specific time and place
-Types of events:
.:. External- outside the system
.:. Temporal- reaching a point in time
.:. State- internal trigger
Things and system requirements:
-define sys requirements by understanding what information needs to be stored
-what things does the sytem need to know about and store information about?
-characteristics of thigns:
.:. relationship- cardinality
.:. attribute - specific peice of information about a thing
And that will do.
Wednesday, March 14, 2007
Week 3- Requirements Gathering
This week we focused more on the analysis side of the SDLC.
The are 6 main activities in the analysis phase, they are:
- Gather information
- Defne system requirements- both logical and physical
- Prioritise requirments- what must be done, what should be done..and what would be nice if it was done but not neccessary..
- Prototype for feasibility and discovery
- Generate and evaluate alternatives
- Review recommendations with management
System requirements-
- system requirements are determined with the help of organisational stakeholders
Functional requirements: What the system should do
Nonfunctional requirements: The technical environments in which the system exists
There are 7 fact finding methods an analyst can use to gather information...i'll let you go through the slides yourself to find out what these 7 are ;)
Anyway...these blogs are so pointless unless your one of those people who like attention/to talk just to have people read your blogs and comment on how brilliant/ humorous/fantastic you are. I personally think this is a massive waste of time.
Ciao.
The are 6 main activities in the analysis phase, they are:
- Gather information
- Defne system requirements- both logical and physical
- Prioritise requirments- what must be done, what should be done..and what would be nice if it was done but not neccessary..
- Prototype for feasibility and discovery
- Generate and evaluate alternatives
- Review recommendations with management
System requirements-
- system requirements are determined with the help of organisational stakeholders
Functional requirements: What the system should do
Nonfunctional requirements: The technical environments in which the system exists
There are 7 fact finding methods an analyst can use to gather information...i'll let you go through the slides yourself to find out what these 7 are ;)
Anyway...these blogs are so pointless unless your one of those people who like attention/to talk just to have people read your blogs and comment on how brilliant/ humorous/fantastic you are. I personally think this is a massive waste of time.
Ciao.
Monday, March 5, 2007
Week 2- The Context of systems analysis and design
Todays lecture went pretty fast...
Things we covered in the lecture today were:
-Review of SDLC
-Methodologies
-Tools and techniques used for system development
-IE
-OO Approach
-EXTREEEEEEME programming lol...all programming is EXTREMEly gay..
-Feasibility issues
In the tute we just went through the excercise we started last week and presented our findings to the class. All the presentations were really good, especially Luke's diagram...very clear and ever so artistic..hehe
Um...i still need to subscribe to the podcasts and need to look at the assignments and stuff but otherwise im doin ok in this subject...lol? NEWAI..
Cya!
Things we covered in the lecture today were:
-Review of SDLC
-Methodologies
-Tools and techniques used for system development
-IE
-OO Approach
-EXTREEEEEEME programming lol...all programming is EXTREMEly gay..
-Feasibility issues
In the tute we just went through the excercise we started last week and presented our findings to the class. All the presentations were really good, especially Luke's diagram...very clear and ever so artistic..hehe
Um...i still need to subscribe to the podcasts and need to look at the assignments and stuff but otherwise im doin ok in this subject...lol? NEWAI..
Cya!
Tuesday, February 27, 2007
Week 1-Understanding the nature of systems analysis and design
We just went through the standard administration stuff like lecturers name, email, timelines and topics to be covered in the first half of the lecture and in the second half we started on a bit of definitions. Apparently a systems analyst is a person who "uses analysis and design techniques to solve business problems with information technology" ...I'm gunna feed that to the next family member who asks me what job this course will get me after i finish....ummmmmmm am I plaigarising by using the definition up there?? Newhoo..
In the lab we just worked on a case study about the Melbourne water system and its components, what issues would need to be discussed with the groups responsible for designing the other parts of the system and how our perspective on the analysis would differ to these other groups...
Oh and by the way, I totally didn't notice the monkey walk in the middle of those people throwing basketballs around..
Subscribe to:
Comments (Atom)