The traditional or structured approach to design

1. Data flow diagrams

Graphical system model that shows all main requirements for an information system in one diagram.

Typical data flow symbols:
Process: step-by-step instructions that followed to transform input to output.

Data flow: data flowing from place to place, such as an input or output to a process.

External agent: the source or destination of data outside the system.

Data store: data at rest, being stored for late use, usually corresponded to a data entity in a ERD.

Real-time link: communication back and forth between an external agent and a process as the process is executing.

Abnormal in DFD:
Black hole process: process that just have the input.
White hole process: process that just have the output.
Cannot create output from the input.

High-level diagrams provide general view of the system.
Low-level diagrams provide detail vies of the system.
Different views are called levels of abstraction.

Physical model and logical model:
Logical model: assumes implementation in prefect technology, does not tell how system is implemented.
Physical model: describe assumptions about implementation technology, developed in the last stage of design or in early design.

Consistency rule:
All data flows into a process:
a. Must flow out of the process or
b. Be used to generate data that flows out of the process.
All data flows out of a process:
a. Have data that flowed into the process or
b. Have been generated from data that flows into the process.

2. Modules form IE may supplement DFD:
a. Process decomposition diagram: how process on multiple DFD levels is related.
b. Process dependency diagram: emphasizes interaction with store entities.
c. Location diagram: geographic where system used.
d. Activity-location matrix
e. Activity-data matrix.

Design: Use case Realization

Design: Use case Realization

1. OO design: The bridge between analysis and programming

User-interface, networks, control, security and database requires design tasks and models

2. Interactive process of OO design

a. Create preliminary design class diagrams model

b. Develop interaction diagram for each use case or scenario

c. Return to design class diagram

d. Partition design class diagram into related functions using package diagrams

3. Design class diagram

a. Standard design classes

Entity: design identifier for problem domain class
Boundary: designed to live on system’s automation boundary
Control: mediate between boundary and entity classes, between the domain layer and view layer.
Data access: retrieve from and send data to database.

b. Design principles:

Encapsulation: each object is self-contained unit that include data and method.
Object reuse: designers often reuse same classes for windows components.
Information hiding: data associated with object is not visible to outside world.
Navigation visibility: object is able to view and interact with outside object.

c. Coupling and cohesion:

Coupling: qualitative measure of how closely classes in a design class diagram are linked.
Cohesion: qualitative measure of consistency of functions within a single class.

4. Interaction diagrams: realizing use case and define methods.

a. First-cut sequence diagram:
Start with elements from SSD.
Replace: system object with user case controller.
Add other objects to be included in use case.
Determine other messages to be sent
b. Design with collaboration diagrams;

Sequence diagram: because use case descriptions and dialog follow sequence of steps
Collaboration diagrams: emphasizes coupling.

5. Package diagram: structuring the major components

a. Indentifies major components of a system and dependencies.
b. Determines final program partitions for each layer: view, domain, data access.
c. Can divide system into subsystem and show nesting within packages.

Structured Design

Structured Design

1. Top-down approach

DFDs with automation boundaries.

System flowcharts, structure charts, pseudocodo
2. The automation of system boundary

Partitions data flow diagram processes into manual processes and automated systems.

Processes can be inside or outside of boundary.

Data flows can be inside and outside of boundary.

a. Crossing the system boundary represent inputs and outputs of system.

b. Crossing boundaries between programs represent program-to-program communication.

3. The system flowchart

Representation of various computer programs, files, database and associated manual processes that make up complete system.

4. The structure chart

a) Describe functions and subfunctions of each part of system.
b) Show relations between modules of a computer system.

Developing a structure chart:

a. Transaction analysis: uses system flow charts and event table inputs upper-level modules developed first
Identifies each transaction supported by the program.

b. Transform analysis: use DFD fragments for inputs into outputs
Computer program transforms inputs into outputs
Chart shave input, calculate and output subtrees.

Evaluating the quality of a structure chart:

a. Module coupling: measure of how module is connected to other modules in program and the goal is to be loosely coupled.

b. Module cohesion: measure of internal strength of module and goal is to be highly cohesive.

5. Three-layer design: view layer, business logic layer , and data layer.

1. Overview of system interface (do not require much human interaction)

2. Design of system inputs:

a) Identifying devices and mechanisms used to enter input

b) Identify all system inputs and develop list of data content with each other. (ensure all data inputs are identified and specified correctly)
i. Identify automation boundary
ii. Examine structure charts

OO model: system sequence diagrams identify each incoming message.

3. Design system outputs:

a) Types of reports: printed reports, electronic displays and turnaround documents.

b) Types of outputs reports: detailed, summary, exception, executive/dashboard

4. Design integrity control

a) Ensure that only appropriate and correct business transactions occur.

Ensure that transactions are recorded and processed correctly.

b) Input integrity control
i. used with all input mechanisms
ii. addition level of verification to help reduce input errors
iii. common control techniques: filed combination control, value limit control, completeness control, data validation control

c) database integrity control
i. access control
ii. data encryption
iii. transaction control
iv. update control
v. backup and recovery protection

d) Output integrity control
Ensure output arrives at proper destination and is correct accurate, complete and current.
Destination control: output is channeled to correct people.
Completeness, accuracy and correctness control.
Appropriate information presents on output.

5. Designing of security control (protect assets of organization from all threats )

a) Access to systems: control access to any resource managed by OS or network. (unauthorized user, registered user, privileged user)
b) Data security
c) Secure transactions

6. Tree-tier applications
a) Presentation tier: the user interface
b) Business tier: class that handle the data
c) Data tier: retrieving and storing the data in a database.

The User Interface design

Design the user interface
1. Identifying and classifying the inputs and outputs
In the event tables, triggers represent the inputs, and outputs are shown as responses to events.
Traditional approach: data flow diagrams.
2. System interface VS System interface
System interface: I/O, require little human interaction
User interface: require human interaction to the user, and sometimes UI is the system.
Physical aspect, perceptual aspect, conceptual aspect.
3. Human-computer interaction (HCI)
Metaphors for HCI:
a). Direct manipulation metaphor: user interfaces with objects on display screen.
b). Document metaphor: computer is involved with browsing and entering data on electronic documents
c) Dialog metaphor: much lick carrying a conversation
Guidelines for designing UI:
Visibility: all controls should be visible, and provide immediate feedback to indicate control is responding.
Affordance: appearance of control should suggest its functionality, the purpose for which it is used.
4. Documenting dialog design: used to design menu hierarchy (allow user to navigate to each dialog provides overall system structure)
Using UML dialogs:
a)Use case description: list of steps followed as system and user interact
b) Activity diagrams: document dialog between user and computer for a use case
c)System sequence diagrams
5. User centered design:
a) Focusing early on users and their work
b) Evaluating designs to ensure usability
c) Applying interactive development

The nature of good design

Design is the process of describing, organizing and structuring system components at architectural design level and detained design level.

Design: convert functional models from analysis into models that represent the solution.
1. focus on technical issues (language,software,hardware)
2. requires less user involvement that analysis

Design phase activities:

1. design and integrate the network
2. design application architecture
3. design the user interface ( how user interact with the system)
4. design the system interface (enable system to share and exchange information)
5. design and integrate the database (system analysis model to create physical database model)

6. design and integrate the system control ( controls are need for all the other design activities)

a. user interface - limit access to authorized users
b. system interface - protect from other systems
c. application architecture - record systems
d. database - protect from software/hardware failure
e. network - protect communication

Deployment environment - bridges analysis and design
hardware, system software, networking

Network design:

Internet: global collection of networks that use TCP/IP networking protocols
Intranets: private networks using same TCP/IP protocol as the Internet
Extranets: intranet has been extended outside the organization.

Application architecture: consists of standards and tools used in an organization

Client - server architecture:

Server - manage information system resources or provides well defined services for client
Client - communication with server or request resources or services.

Three layer client - server architecture:

Data layer - manages stored data in database
Business logic layer - implements rules and procedures of business processing.
Vies layer - accepts user input and formats and displays processing results.

My plan for the exam and the following study!

From this week, I will review all the lecture notes for FIT 2001, and each week 3 lectures including the quizes.

For the week 11, lecture 7,8,9

For the week 12, lecture 4,5,6

For the weel 13, lecture 1,2,3

Hope I can get a good result in the exam!

fit 2001 for week 4

Beginning analysis

1. Different models are used in the information system development:

a) Mathematical: formulas that describe technical aspects of the system

b) Descriptive: narrative memos reports or lists that describe aspects of the system

c) Graphical: diagrams and schematic representation of some aspect of the system

2. Overview of models used in analysis and design

a) Analysis phase activity named “define system requirements”

i. Logical models

ii. Provide detail without regard to specific technology.

b) Design phase

i. Physical models

ii. Provide technical details

iii. Extend logical models

3. Events: occurrences at a specific time and place, and trigger all system processing

Types of events:

a) External event: outside system, and initiated by external agent or actor

i. External agent wants something resulting in a transaction

ii. External agent wants some information

iii. Data changed needs to be updated

iv. Management wants some information

b) Temporal event: occurs as result of reaching a point in time, and based on the system deadline

i. Internal outputs needed

ii. External: statements, status, reports, bills, reminders

c) State: something inside system triggers processing nee

Event table:

Event	Trigger	Source	Use case	Response	Destination
	How does the system know the event occurred	The source of data entering the system	What does the system do when the event occurs?	What output is produced by the system?	What external agent gets the output

4. Things and system

Procedure for developing an initial list of things

a) Using the event table and information about each event, identify all nouns about the system

b) Using other information from existing systems, current procedures and current reports or forms, add items or categories of information needed.

c) Refine list and record assumptions or issues to explore

Characteristics of things:

a) Relationship

b) Attribute: a piece of information about a thing

Objects:

Objects do the work in the system and store information in OO approach, and objects have behaviors and attributes.

An object is encapsulated – a self-contained unit.

The class diagram

5. UML

OO system requirements are specified and documented through process of building models, and system development process starts with identification of events and things.

Events are business processes that new system must addressed.

Things are problem domain objects involved in business process.

Fit2001 for week 3

Lecture 3
1. The analysis phase in more detail
a) Gather information : what the user wants
b) Define requirements: what we will build
c) Prioritize requirements
d) Prototype for feasibility and discovery
e) Generate and evaluate alternatives
f) Review recommendations with management
2. System requirements: new system capabilities and constraints
a) Functional requirements: activities system must perform
b) Nonfunctional requirements
3. Stakeholders – the source of system requirements: people with interest in successful system implementation.
a) Users (user system)
Horizontal user roles – information flow across departments
Vertical user roles – information needs of clerical staff, middle management and senior executive
b) Clients (pay for and own the system)
c) Technical staff (ensure system operation)
4. Techniques for information gathering: analysis phase done to understand business functions and develop system requirements
a) Original structure
b) Current structure
5. Fact finding methods
a) Review existing reports, forms and procedure descriptions
i. Source: external industry wide professional organizations and trade publications
ii. Existing business documents and procedure descriptions within organization
b) Conduct interviews and discussions with users: effective way to understand business functions and rules.
c) Observe and document business processes: varies from office walkthrough to performing actual tasks, and not necessary to observe all processes at the same level of detail
d) Build prototypes: preliminary working model of a larger, more complex system, and working model to provide “look and feel”
e) Distribute and collect questionnaires: limited and specific information from a large number of stakeholders.
i. Closed-ended questions direct person answering question.
ii. Open-ended questions encourage discussion and elaboration.
f) Conduct JAD sessions: expedite investigation of systems requirements
g) Research vendor solutions
h) Validating the requirements: make sure gathered information is correct.

Fit 2001 week 2

Fit 2001 week 2:
The Context Systems Analysis and Design
1. Phases of system development of life cycle (SDLC):
a) Planning (important to confirm the feasibility of the project)
b) Analysis (important to understand the business needs)
c) Design
d) Implementation
e) Support (maintain, enhance, support)
2. Scheduling project phases:
a) Waterfall approach- each phase falls into next phase
b) Overlapping (current) approach
c) Spiral model: and adaptive SDLC approach that cycles over and over again through development activities until a project is complete.
3. Methodologies and models:
a) Methodologies: comprehensive guidelines to follow for completing every SDLC activity collection of models, tools and techniques.
b) Models: representation of an important aspect of real world, but not some real thing
c) Tools: software support that helps creating models and other required project components.
d) Techniques: collection of guidelines that helps analyze complete system development activity or task.
4. Two approach
a) Traditional approach
b) Object-oriented approach-views information system as collection of interacting objects that work together to accomplish objects.
5. Confirm project feasibility:
a) Economic feasibility:
i. CBA-cost/benefit analysis
ii. Intangible cost/benefit cannot be measured in dollars
b) Organizational and cultural feasibility
c) Technological feasibility
d) Schedule feasibility
e) Resource feasibility
f) Staffing and launching feasibility.

FIT 2001: First week

This is just the first week of FIT 2001, and we go through some important information in this lecture:

1. The structure of this unit.

2. The objective of learning this unit.

3. The textbook, the assessment and all the related materials of this unit.

Some key points in the first lecture:

1. System analysis: the process of understanding and specifying in detail what the information system should accomplish.

System design: the process of specifying in detail how the many of components of the information system should be physically implemented.

System analyst: a business professional who uses analysis and design techniques to solve business problems using information technology.

2. System analysis and design focuses on understanding the business problem and outlining the approach to be taken to solve it.

3. Information system: a collection of interrelated components that collect, process, store and provide as output the information needed to complete business tasks.

4. Knowledge and skills required of a system analyst: technical knowledge/skills, business technical knowledge/skills and people knowledge/skills.

5. System analysts need to understand how people think, learn, react to change, communicate, work( in a variety of jobs and levels).