Exam 2

Question 1

Process model

Answer 1

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

Question 2

Data flow diagramming

Answer 2

A popular technique for creating process models

Question 3

Elements of a data flow diagram

Answer 3

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

Question 4

Level 0 vs level 1 DFD

Answer 4

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

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

Question 5

Text based process descriptions

Answer 5

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)

Question 6

Creating a data flow diagrams

Answer 6

• DFDs start with the use cases and requirements definition
• names of use cases become processes and are integrated
• inputs and outputs become data flows

Question 7

Steps in building DFDs

Answer 7

• 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

Question 8

DFD Balancing

Answer 8

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

Question 9

Data model

Answer 9

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

Question 10

Entity relationship diagram

Answer 10

A picture showing the information created, stored, and used

Question 11

Entities

Answer 11

Represent things that the system needs to store information about

Question 12

Relationships

Answer 12

Associations between entities

Question 13

Identifier types

Answer 13

• Concatenated Identifier: can have uniqueness problems
• Single Identifier: most common
• Identifier to be added later: wait until design phase

Question 14

Cardinality

Answer 14

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)

Question 15

Modality

Answer 15

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)

Question 16

Creating an entity relationship diagram

Answer 16

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

Question 17

Balancing ERDs w/ DFDs

Answer 17

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

Question 18

Normalization

Answer 18

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

Question 19

CRUD matrix

Answer 19

Data flow diagram

-creating, reading, updating, and deleting

Question 20

The three rules of normalization

Answer 20

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

Question 21

Design phases

Answer 21

Decide HOW to build the system

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

Question 22

System specification

Answer 22

Final deliverable from the design phase

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

Question 23

8 steps of the design phase

Answer 23

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

Question 24

3 system acquisition strategies

Answer 24

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

Question 25

Custom development pros and cons

Answer 25

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

Question 26

Packaged software pros and cons

Answer 26

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

Question 27

Application service providers (ASP)

Answer 27

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

Question 28

Outsourced development pros and cons

Answer 28

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

Question 29

Outsourcing guidelines

Answer 29

- 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

Question 30

Influences on acquisition strategy

Answer 30

``` Business need In-house experience Project skills Project management Timeframe ```

Question 31

Selecting a strategy

Answer 31

– 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?

Question 32

Request for proposal (RFP)

Answer 32

- 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

Question 33

Developing an alternative matrix

Answer 33

– 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

Question 34

Architecture design

Answer 34

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

Question 35

Hardware and software specification

Answer 35

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

Question 36

Four basic functions of a software system

Answer 36

- 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

Question 37

Objective of architectural design

Answer 37

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

Question 38

Three primary components of hardware

Answer 38

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

Question 39

Client server architectures

Answer 39

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

Question 40

Thick versus thin client

Answer 40

A thick or fat client contains all or most application logic | A thin client contains a small portion of the application logic

Question 41

Benefits of client-server architecture

Answer 41

- 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

Question 42

Mobile application architecture

Answer 42

• 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

Question 43

Server based architecture

Answer 43

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

Question 44

Advances in architecture configurations

Answer 44

• 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

Question 45

Comparing architecture options

Answer 45

– 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

Question 46

Selecting in architecture design

Answer 46

– 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

Question 47

Operational requirements

Answer 47

– 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

Question 48

Performance requirements

Answer 48

– 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

Question 49

Security requirements

Answer 49

- 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

Question 50

Cultural/political requirements

Answer 50

- 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

Question 51

Hardware and software specification

Answer 51

– 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

Question 52

Interface design

Answer 52

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

Question 53

User interfaces

Answer 53

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

Question 54

System interfaces

Answer 54

Define house systems exchange information with others

Question 55

Principles for user interface design

Answer 55

* 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

Question 56

Steps in the interface design process

Answer 56

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

Question 57

Understand the users

Answer 57

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

Question 58

Organize the interface

Answer 58

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

Question 59

Interface standards

Answer 59

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

Question 60

Interface design prototyping

Answer 60

A mock up or simulation of screen, form, or report | – common methods include: paper sketches, wire frame diagrams, storyboards, wire flow diagrams

Question 61

Four common approaches to interface evaluation

Answer 61

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

Question 62

Basic principles of navigation design

Answer 62

•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

Question 63

Types of navigation control

Answer 63

* 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

Question 64

Message design principles

Answer 64

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

Question 65

Basic principles of input design

Answer 65

``` 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 ```

Question 66

Capture the data at the source

Answer 66

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

Question 67

Minimize keystrokes

Answer 67

- never ask for information that can be obtain other ways | – carefully select types of inputs, selection boxes, and input validation

Question 68

Basic principles of output design

Answer 68

``` •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 ```