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.