Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

INFS 347 > Exam 2 > Flashcards

Exam 2 Flashcards

1
Q

Process model

A

Formal way of representing how a business operates, illustrates activities performed and how data moves among them

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Data flow diagramming

A

A popular technique for creating process models

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Elements of a data flow diagram

A

Process: an activity a function performed for specific business reason
Data flow: a single piece of data or a logical collection of data
Data store: A collection of data that is stored in someway, “out” is retrieved from the data store, “in” updates or is added to the data store
External entity: A person, organization, or system that is external to the system but interacts with it

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Level 0 vs level 1 DFD

A

Level 0: usually 3-7 processes
Level 1: greater detail

The context diagram to find the scope and systems interacting with the environment

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Text based process descriptions

A

Provide more information about the process than the DFD alone

  • structured English (common statements, example)
  • decision trees (graphical if-then logic)
  • decision tables (complex with multiple decision rules)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Creating a data flow diagrams

A
  • DFDs start with the use cases and requirements definition
  • names of use cases become processes and are integrated
  • inputs and outputs become data flows
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Steps in building DFDs

A
  • building the context diagram
  • create a decomposition diagram
  • organize DFD fragments into level 0 diagram
  • decompose level 0 processes into level 1 diagrams, level one then into level 2, etc
  • validate DFDs with user to ensure completeness and correctness
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

DFD Balancing

A

The conversation of inputs and outputs to a data flow process when that process is decomposed to a lower level
- balanced means: # inputs to lower level DFD = # inputs to associated process of higher level DFD

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Data model

A

The formal way of representing the data that are used and created by a business system

  • logical: data model shows the organization of data without indicating how it is stored, created, or manipulated
  • physical: data model shows how the data will accurately be stored in databases or files
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Entity relationship diagram

A

A picture showing the information created, stored, and used

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Entities

A

Represent things that the system needs to store information about

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Relationships

A

Associations between entities

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Identifier types

A
  • Concatenated Identifier: can have uniqueness problems
  • Single Identifier: most common
  • Identifier to be added later: wait until design phase
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Cardinality

A

Refers to the number of times instances in one entity can be related to instances in another entity

One-to-one (state to capital)
One-to-many (patient to doctor)
Many-to-many (student to class)

(Lists Max)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Modality

A

Refers to whether or not an instance of a child entity can exist without a related incident in the parent entity

  • not null (must exist)
  • null (optional)

(Lists Min)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Creating an entity relationship diagram

A

1) identify the entities
2) add appropriate attributes for each entity
3) draw the relationships that connect associated entities

  • data stores of the DFD generally correspond to entities
  • only include entities with more than one instance of information
  • Don’t include entities associated with implementation of the system, they will be added later
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Balancing ERDs w/ DFDs

A

The DFD data components need to balance the ERD data stores (entities) and data elements (attributes)

  • Data not used is unnecessary
  • Data that is omitted results in an incomplete system
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Normalization

A

A technique used to validate data models

  • ensures data integrity
  • eliminate redundancy
  • ensures flexibility of database making it easier to add change or delete entities and attributes
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

CRUD matrix

A

Data flow diagram

-creating, reading, updating, and deleting

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

The three rules of normalization

A

1) do any attributes have multiple values for a single instance of an entity ?
- if yes: then remove the repeating attributes and create a new entity
2) is the identifier composed of more than one attribute? or any attribute values dependent on just one part of the identifier?
- if yes: remove partial dependency
3) do any attribute values depend on an attribute that is not the entities identifier
- if yes: remove the transitive dependency

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Design phases

A

Decide HOW to build the system

-create system requirements that describe technical details for building the system

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

System specification

A

Final deliverable from the design phase

-conveys exactly what system development team will implement during the implementation phase

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

8 steps of the design phase

A

1) determine system acquisition strategy, make buy or outsource
2) determine the technical architecture for the system
3) Address security concerns and globalization issues
4) make hardware and software selections
5) determine the Waze user to interact with the system, interface inputs and outputs
6) design the programs for the underlying processes
7) design the way the data will be stored
8) create a final deliverable - the system specification

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

3 system acquisition strategies

A

1) custom development: build from scratch
2) purchasing software package: can customize or rent software
3) outsource development to a third-party

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q

Custom development pros and cons

A

Pros:

  • get exactly what we want,
  • allows flexibility,
  • consistent with existing technology,
  • build technical skills and functional knowledge in-house

Cons:

  • requires significant time and effort,
  • may add to existing back logs,
  • may require skills we don’t have,
  • often costs and take more time,
  • risk of project failure
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q

Packaged software pros and cons

A

Pros:

  • no need to reinvent the wheel
  • tested and proven product,
  • cost and time savings,
  • utilize vendors expertise,
  • some customization possible

Cons:

  • rarely a perfect fit,
  • organizational processes must adapt to software,
  • reliance on vendor and won’t develop in-house functional and technical skills,
  • may require system integration
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q

Application service providers (ASP)

A

Supply access to software on a pay-as-you-go basis, used for common business needs
-risks include: fear of losing confidential information and performance

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
28
Q

Outsourced development pros and cons

A

Pros:

  • acquisition choice that requires least in-house resources
  • higher expertise we don’t have
  • may save time and money, with lower risk

Cons:

  • no opportunity to build in-house experience,
  • reliance on vendor,
  • future options are limited,
  • security risk,
  • performance based on contract terms
29
Q

Outsourcing guidelines

A
  • keep lines of communication open
  • define and stabilize requirements before signing contract
  • View the relationship as a partnership
  • Select vendor, developer, or provider carefully
  • Assign someone to manage the relationship
  • Don’t outsource what you don’t need
  • Emphasize the flexible requirements, long-term relationships, and short term contracts
30
Q

Influences on acquisition strategy

A 
Business need
In-house experience
Project skills
Project management
Timeframe
31
Q

Selecting a strategy

A

– What tools and technology are needed for a custom development project?
– What vendors make products that address the project needs?
– What service pro providers would be able to build this application if outsourced?

32
Q

Request for proposal (RFP)

A
  • solicits proposal from vendors, developer, or service provide
  • explains the system to be built and criteria for selecting among applicants
  • contents include: description, special tech needs, evaluation criteria, instructions on how to respond, desired schedule
33
Q

Developing an alternative matrix

A

– Combine several feasibility analysis into one matrix
– include technical, budget, and organizational feasibility‘s
– assign weights to indicate the relative importance of each criteria
– assign scores to indicate how well the alternative matrix meets the criteria

34
Q

Architecture design

A

Plans for how the system will be distributed across computers and what hardware and software will be used for each computer
-non-functional requirements are developed early in the analysis phase and play a key role

35
Q

Hardware and software specification

A

Describes how the hardware and software components in detail aid those responsible for purchasing those products

36
Q

Four basic functions of a software system

A
  • data storage
    – data access logic: the processing required to access store data
    – application logic: the logic documented in the DFD, use cases, and functional requirements
    – presentation logic: the display of information to the user and acceptance of the users commands
37
Q

Objective of architectural design

A

To determine how the software components of the information system will be assigned to the hardware devices of the system

38
Q

Three primary components of hardware

A
  • client computers: input-output devices employed by users
    – servers: large multi user computers used to store software and data
    – the network: connects the computers
39
Q

Client server architectures

A

Balance the processing between client devices and one or more service devices, the most common
-clients are responsible for the presentation logic
– servers are responsible for the data access logic and data storage

40
Q

Thick versus thin client

A

A thick or fat client contains all or most application logic

A thin client contains a small portion of the application logic

41
Q

Benefits of client-server architecture

A
  • Scalable
  • Can support different types of clients and servers through middleware
  • The presentation logic, the application logic, and the data processing logic can be independent
  • If a server fails, only the applications requiring that server or affected
  • Majority limitation is in their complexity
42
Q

Mobile application architecture

A

• Rich client: involves processing on the mobile device using its resources
-Presentation logic, business logic, and data access logic on the client side
• Thin web based client: business and data access logic on the server side, always connected to server
• Rich Internet application: browser-based, uses some technologies on the client device to provide a rich user interface

43
Q

Server based architecture

A

One point of control because all messages flow through one central server
– zero client or ultrathin client
• Benefits: Green, limits non-business use, less expensive

44
Q

Advances in architecture configurations

A

• virtualization: creation of a virtual device or resource
– server virt.: partitioning a physical server into smaller virtual servers
– storage virt.: combining multiple network storage devices into what appears to be a single storage unit

• cloud computing: computing resources obtained as a service
– elasticity: the resources allowed can be increased or decreased quickly based on demand
– cloud customers contain cloud resources in a straightforward fashion
– cloud servers typically have standardized APIs

45
Q

Comparing architecture options

A

– Most systems are built to use the existing infrastructure in the organization, so often the current infrastructure restricts the choice of architecture
– each of the architecture‘s discussed have its strengths and weaknesses
– client server architecture‘s are strongly favored on the basis of the cost infrastructure
– cloud computing deserves consideration today

46
Q

Selecting in architecture design

A

– Creating an architecture design begins with a non-functional requirements
– refined non-functional requirements into a more detailed requirements for the selection of architecture
– the non-functional requirements in the architecture design are used to develop the hardware and software specification

47
Q

Operational requirements

A

– Technical environment: special hardware/software in network regulations
– system integration: the extent to which the system will operate with other systems
– portability: extent to which system will need to operate in other environments
– maintainability: expected business changes to which the system should adapt

48
Q

Performance requirements

A

– Speed con time within which the system must perform its function
– capacity: total and peak number of users, and the volume of data expected
– availability: extent to which the system will be available to users
- reliability: failure rate due to errors

49
Q

Security requirements

A
  • system value estimate: estimated business value of system and data
    – access control: limitations on who can access what data
    – encryption and authentication: defines what data will be encrypted and authentication needed
    – virus control: controls to limit viruses
50
Q

Cultural/political requirements

A
  • multilingual: all the language is needed
    – customization: aspects that can be changed by local users
    – making understated norms explicit: stating assumptions a different country to country
    – legal: laws and regulations that impose system requirements
51
Q

Hardware and software specification

A

– The design phase is also the time to begin selecting in acquiring the hardware and software that will be needed for the future system
– a document that describes what hardware/software are needed to support application

52
Q

Interface design

A

The process of defining how the system will interact with external entities

53
Q

User interfaces

A

Define how the system will interact with the users
– navigation mechanisms: provides the way for users to tell the system what to do
– input mechanism: defined the way the system captures info
– output mechanism: defined the way the system provides info to users or other systems

54
Q

System interfaces

A

Define house systems exchange information with others

55
Q

Principles for user interface design

A
  • Layout: the series of areas on the screen that are used consistently for different purposes
  • Content awareness: users should always be aware of where they are in the systemAnd what information is being displayed
  • Aesthetic’s: should be functional and inviting, careful use of white space, colors, and Fonz
  • User experience: ease-of-use and ease of learning
  • Consistency: enables users to predict what will happen before they perform the function, most important
  • Minimize user effort: should be simple to use
56
Q

Steps in the interface design process

A

1) understand the users
2) organize the interface
3) define interface standards
4) develop interface design Prototypes
5) evaluation and testing

57
Q

Understand the users

A

Users likely will have very different goals and intentions on using the system, plan a user interface that will be satisfying for that particular user group
– use personas to develop characterizations of various user groups
– use scenarios outlining the steps that the users perform to accomplish some part of their work

58
Q

Organize the interface

A

Defines the basic components of the interface and how they work together to provide functionality to users

59
Q

Interface standards

A

The basic elements that are common across individual screens, forms, and reports with an application
– Interface metaphor: concept from real real world
– interface objects: fundamental building blocks of the system
– interface actions: common commands employed by users
– interface icons: simple picture representing status or actions
– interface template: layout guide for all screens

60
Q

Interface design prototyping

A

A mock up or simulation of screen, form, or report

– common methods include: paper sketches, wire frame diagrams, storyboards, wire flow diagrams

61
Q

Four common approaches to interface evaluation

A

1) Heuristic evaluation: compare design to a checklist
2) walk-through evaluation: team simulates movement through components
3) interactive evaluation: users try out the system
4) formal usability testing: expensive, detailed use of specific lab testing

62
Q

Basic principles of navigation design

A

•Analysis usually must assume that users have not read the manual, have not attended training, and do not have external help readily at hand
•All controls should be clear and understandable and placed in an intuitive location on the screen new line Dash prevent mistakes: by limiting choices
– simplify recovery from mistakes: with undo button
– use consistent grammar order

63
Q

Types of navigation control

A
  • Menus: enable users to select action from an organized display of action categories and options
  • Direct manipulation: used with the icons to start programs and used to shape and size objects, may not be intuitive for all commands
64
Q

Message design principles

A

should be clear, concise, and complete, should be grammatically correct and free of abbreviations

65
Q

Basic principles of input design

A 
Goal is to simply and easily capture accurate info for the system
– reflect the nature of the inputs
– find ways to simplify their collection
– use online and batch appropriately
– capture data at the source
66
Q

Capture the data at the source

A

Dash motivation: reduces duplicate work and processing time, decreases cost and probability of error
– source data automation: barcode readers/scanners, optical quick character recognition, magnetic strip readers

67
Q

Minimize keystrokes

A
  • never ask for information that can be obtain other ways

– carefully select types of inputs, selection boxes, and input validation

68
Q

Basic principles of output design

A 
•Understand the report usage:
– reference or cover to cover
– frequency
– real time or batch reports
•Manage information load
•Minimize bias
•Utilize various report types and media to satisfy users output requirements

INFS 347 (2 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions