Week 9- Structured Design

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

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

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

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

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.

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.

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.