Final Exam Study Guide PDF

Preview

Summary

Final Exam Study Guide...

Description

Final Exam Study Guide Chapter 6: Behavioral Modeling 1. What is a sequence diagram? a. A UML diagram that shows the interaction between objects to perform critical pieces of Use Case behavior in a time – ordered manner; a “tool” for specifying and understanding the flow of control b. Interactions are in the form of messages c. Behavioral responsibilities are assigned to message recipients (AKA shows behavior of systems) d. Moving  Design e. Used to Depict “to be” system i. Last part of JUST doing functional requirements f. Sequence Diagram – return to and correct/add to use case or class diagrams 2. Sequence Diagram cont’d a. Process and data are done TOGETHER b. Take use cases and class diagrams and see what the process in the use case means for the data c. Use case = process d. Class diagram = data e. Sequence diagram = BOTH f. One sequence diagram for each use case (follows the normal flow of events) g. When coding the system: i. Sequence diagrams help capture the dynamic aspects of the system by implementing the operations, messages and the sequencing of those messages in the target program language 3. Stereotypes of Analysis Classes a. Entity Class i. Holds most of the data for the application – WHERE WE STORE DATA ii. If the object exists at the beginning of the use case, it is show at the top of the sequence diagram iii. If the object is created during the use case it is shown where it is created b. Boundary Class i. Used by actors to interact with the system ii. INTERFACE – interface designed so that the end user can interact with the system iii. The boundary of how someone interacts with a system through a form iv. The programmer designs the boundary and decides how the user interacts with it v. Ex: getting money at the ATM doesn’t happen unless you prove who you are and get past the bank boundary to your money c. Control Class i. Captures the main application logic within the system ii. Functions that the system needs to do

iii. The software lets the system do the functions you want it to do because you coded it into the system d. Additional Syntax i. An actor 1. A person or system that derives benefits from and is external to the system 2. Participates in a sequence by sending and or receiving messages 3. Is placed across the top of the diagram 4. Is depicted as a stick figure and ii. A lifeline 1. Denotes the life of an object during a sequence iii. An execution occurrence 1. A long narrow rectangle placed atop a lifeline 2. Denotes when an object is sending or receiving a message 3. When a lifeline becomes active you put in an execution box iv. A message 1. Conveys information from one object to another one 2. An operation call is labeled with the message being sent and a solid arrow 3. A return is labeled with the value being returned and is shown as a dashed arrow v. A guard conditions 1. Represents a test that must be met for the message to be sent vi. Object Destruction 1. An X is placed at the end of an object’s lifeline to show that it is going out of existence 4. Sequence Diagram Guidelines a. Employ the use – case diagram to determine the use cases b. Determine the actors that interact with the use case c. DO NOT model interactions among actors d. Actors are outside the scope of the system e. Consider one use case at a time  obtain the use case description for each use case f. For a given use case, specify an analysis boundary class between the use case and each actor i. If there are two actors, there will be two boundary classes g. For a given use case, specify one control class (often the system) h. Derive the entity classes from the class diagram i. Interactions are among objects of the classes not among the classes themselves i. Ex: use the notation :aCustomer to indicate an object of the class Customer j. Show messages passed from one object to another – the receiver object has the responsibility of carrying out the request conveyed by the system 5. Rules a. Actors can talk ONLY to boundary objects b. Boundary objects can talk ONLY to controllers and actors

c. Entity objects can talk only to controllers d. Controllers can talk to boundary objects, entity objects, and other controllers e. Controllers CANNOT talk to actors

f. Chapter 10: Human – Computer Interaction/Interface and Report Design 1. Principles of the User Interface Design a. Layout i. Each are may be further subdivided ii. Each area is self – contained iii. Areas should have a natural intuitive flow 1. Users from western nations tend to read from left to right and top to bottom 2. Users from other regions may have different flows b. Content Awareness i. Intuitively answers the users’ questions: 1. Where am I? 2. What am I supposed to be doing here? ii. Content awareness applies to sub – areas within a form or window 1. Related form fields (ex: address information) are grouped together 2. Related report information (ex: records) are grouped together c. Aesthetics i. Interfaces should be functional, inviting to use, and pleasing to the eye ii. In most cases, less is more (minimalist design) 1. Too much/clutter = OVERHWELMING/BAD iii. White space is important

iv. Background color? v. Acceptable information density is proportional to the user’s expertise 1. Novice users prefer less than 50% density 2. Expert users prefer more than 50% density d. User Experience 1. Way people will interact/who will interact ii. Ease of learning (novice) 1. Significant issue for inexperienced users 2. Relevant to systems with a large user population iii. Ease of use (expert) 1. Significant issue for expert users 2. Most important in specialized systems iv. Sometimes ease of learning and ease of use go hand in hand (amazon) e. Consistency i. All parts of the system work in the same way ii. Key areas of consistency are 1. Navigation controls 2. Terminology iii. Probably most important concept is making the system simple because it allows the users to predict what is going to happen f. Minimal User Effort i. Interface should be designed to minimize the effort needed to accomplish tasks ii. A common rule is the three – clicks rule 1. Users should be able to go from main menu of a system to the information they want in no more than three clicks 2. User Interface Design Process a.

i. Use Scenario Development: outlines the steps performed by users to accomplish some part of their work ii. A use scenario is ONE path through an essential use case iii. Presented in a simple narrative description

iv. Document the most common cases so the interface designs will be easy to use for those situations b. Interface Structure Design i. The interface structure defines 1. The basic components of the interface 2. How they work together to provide functionality to users ii. Windows Navigation Diagrams (WND) show a. Ex:

2. How all the screens, forms and reports use by the system are related 3. How the user moves from one to another 4. Like a state diagram for the user interface a. Boxes represent components i. Window ii. Form iii. Report iv. Button b. Arrows represent transitions i. Single arrow indicates no return to calling state ii. Double arrow represents a required return c. Stereotypes show interface type c. Interface Standards Design i. Interface standards are basic design elements found across the system user interface ii. Standards are needed for: 1. Interface metaphor – shopping cart 2. Interface objects – names for objects 3. Interface actions – buy or sell 4. Interface icons – when in doubt use a word 5. Interface templates – layout 3. Navigation a. Interface Design and Navigation Prototyping i. Mock ups or simulations of computer screens, forms, and reports ii. Four common approaches 1. Storyboard

a. Ex:

2. Windows layout diagram 3. HTML or Visual Basic prototype 4. Language prototype – most detailed but most expensive b. Interface Evaluation i. Goal is to understand how to improve the interface design before the system is complete ii. Have as many people as possible evaluate the interface iii. Ideally, interface evaluation is done while the system is being designed – before it is built c. 4 Approaches to UI Evaluation i. Heuristic – follow a checklist ii. Walkthrough – give a feel for the interface iii. Interactive – users work with a prototype to follow a common scenario iv. Formal usability testing – formalized process in a usability lab with video, keystroke counts, etc 4. Navigation Design a. Navigation Design Basic Principles i. Prevent mistakes ii. Simplify recovery from mistakes iii. Use consistent grammar order 1. Object – action or action object iv. Types of Menus

v.

vi. Types of Messages

vii.

5. Input Design a. Input Design Basic Principles i. Online Versus Batch Processing 1. Advantages of online a. Entered timely with transaction b. Can be user driven 2. Advantages of batch a. Simplify communication b. Can be process driven c. Less expensive ii. Capture data at the source 1. Prevent duplicate work – completing a written “form” to allow data entered in to a web form 2. Reduces processing time to have customer do data entry 3. Sources data automation(hardware/software) with optical character recognition, bar code scanner, magnetic strip, smart card, smart phone iii. Minimize keystrokes 1. Default values 2. List boxes b. Types of Inputs i. Free form 1. Text box

2. Number box ii. Selection box 1. Check box 2. Radio button 3. List box (on – screen, drop – down, or combo) 4. Sliders c. Input Validation Types i. V

Validation Type

When to Use

Completeness Check

When several fields must be entered before the form can be processed When fields are numeric or contain coded data With all numeric data, if possible When numeric codes are used, such as when checking credit card numbers When data are related, such as when the user enters both a birth date and a date of marriage ( birth < marriage) When data are available to be checked, such as when a user selects a user ID and we need to ensure it is not already take

Format Check Range Check Check Digit Check

Consistency Check

Database Check

6. Output Design a. Output Design Basic Principles i. Understand report usage 1. Ordering, grouping, real time, batch ii. Manage information load 1. Report what is needed, not necessarily what is available iii. Minimize bias 1. Consider how presentation order may effect understanding (alphabetical, chronological) 2. Graphical display are good, but consider scale iv. Consider Media 1. PDF, HTML, etc 2. Mobile Phone and Tablet a. Size b. Keypad size c. Limitation in navigation d. Distracted user e. Possible use of mobile tools – GPS f. Consider data plans v. Types of Media

vi.

7. NonFunctional Requirements a. Operational requirements i. Technologies that can be used (ex: GUI, mouse) b. Performance Requirements i. User interface speed and capacity c. Security Requirements i. Restricted user interface (ex: ATM machine) d. Political and Cultural Requirements i. Date formats, colors and icons

Chapter 12: Construction 1. Developing Documentation a. Documentation of the system must be done throughout system development b. Two fundamentally different systems i. System documentation is for those who install, maintain or build upon the system ii. User documentation is for those who use the system 1. Assume the users will not read the manuals before starting to use the system c. Online documentation is the norm today 2. Types of Documentation

a. Reference Documentation: tell users how to perform specific tasks b. Procedure Manuals: describe how to perform business tasks; each procedure normally entails multiple tasks c. Tutorials: teach people how to use major components of a system 3. Designing Documentation Structure a. Develop a set of documentation navigation controls that lead user to documentation topics b. Topics generally come from 3 sources i. Commands and menus in the user interface ii. How to perform certain tasks iii. Definitions of important terms 4. Writing Documentation Topics a. Use the active voice i. Writing as if you are doing it RIGHT NOW b. Use consistent terms i. Our consulting firm vs Solis Consulting  make it ONE term or the other ii. Balance = you are using all components of the analysis phase together c. Use simple language i. Clear and concise (remember who your customer is  business specific vs technology specific) d. Use friendly language i. Don’t use derogatory term (esp in risk assessment) ii. Language appropriate for ALL readers e. Use parallel grammatical structures i. Present tense (ex: WE execute this plan) f. Use steps correctly i. Say up front what you are doing and break it up ii. Don’t include what you aren’t doing g. Use short paragraphs i. Don’t overwrite

Chapter 13: Installation 1. Installation a. Managing the change to a new system is one of the most difficult tasks in any organization b. Conversion planning normally begins while the programmers are still coding c. Change management focuses on people d. Implementing Change i. draw Diagram 2. Conversion a. Conversion: the technical process by which a new system replaces an old system b. Three Major Steps i. Acquire and install needed hardware

ii. Install software iii. Convert data c. Three dimensions to a conversion plan i. Conversion style ii. Conversion location iii. Conversion modules d. Conversion Strategies i. Often Consider Using 2 or more of the conversion conventions ii.

e. Selecting Conversion Strategies i. Risk, cost, time: choose any two ii. Risk 1. Even after testing, bugs may exist 2. Want to reduce iii. Cost 1. Redundant resources for transitions can be pricey 2. Want to do the least amount of work 3. “want to do the least amount of pay for a good, safe job” iv. Time 1. Slow and safe or fast and risky? 2. Slow = more flexible 3. Fast = potentially risky f. Conversion Style i. Direct Conversion (cold turkey, big bang, abrupt) 1. Turn off the old, turn on the new system 2. Simple and straight forward

a. More risky, low cost, short time 3. EX: JMU enrollment system 2000, Sentara RMH ii. Parallel Conversion 1. Operate the new system and the old system simultaneously (parallel conversion runs as long as needed to test all interactions) a. Low risk, high cost, long time g. Conversion Location 1. THINK BANKS ii. Pilot Conversion 1. One or more locations or business units or work groups are selected to convert first, as part of a test a. Reduce risk, slow time a little bit, hold the cost, complex (using 2 systems for short time) 2. Go to one branch of the bank and implement at THAT branch and only that branch a. If anything goes wrong you study and prepare for the next version to fix it b. Sometimes start at a small bank pilot, then a bigger bank pilot then go full iii. Phased Conversion 1. Phases are installed in sequence, back to back a. Normal risk, hold the cost, long time 2. Phase in slowly (usually geographic) a. Ex: 3 branches in Harrisonburg then 3 Branches in Staunton then 3 branches in culpepper iv. Simultaneous Conversion 1. Go to every branch of the bank and install at once h. Conversion Modules i. Whole system conversion 1. Entire system is installed at one time 2. Very complex if system is complex a. High risk, hold cists, short time (too quick) ii. Modular Conversion 1. System are often in modules and can be designed to be installed individually or together in sets a. Reduces risks, increases costs, lengthens time i. Elements of Migration Plans i. Conversion Plan (Technical Issues) 1. Install hardware 2. Install software 3. Convert data ii. Change Management Plan(organizational Issues) 1. Revise management policies 2. Assess costs and benefits

3. Motivate adoption 4. Conduct training iii. Usually people take a hybrid of these conversions and do what is best for their organization 1. Ex: at this pilot bank we are going to do a direct conversion 3. Change Management a. Change Management i. The process of helping people adopt and adapt to the to be system and its accompanying work processes without undue stress ii. Key rules 1. Sponsor 2. Change agent 3. Potential adopters iii. “Build it and they will come” doesn’t work b. Resistance to Change i. What is good for the organization is often not good for the people in it ii. People perform their own personal cost – benefit analysis 1. Most will overestimate costs and underestimate benefits 2. Must take into account the transition process cost 3. Perceived costs and benefits determine attitude c. Revising Management Policies i. Management policies 1. Provide goals 2. Define how work processes should be performed 3. Determine how people are rewarded ii. No computer system will be successfully adopted unless management policies support its adoption d. Work Process Structuring Tools i. Standard operating procedures 1. SOPs must be revised to match the to be system ii. Measurements and Rewards 1. Adapt to motivate desired (acceptance behavior) iii. Resource Allocation 1. Direct effect is the actual reallocation of resources 2. Symbolic effect shows that management is serious about the new system e. Assessing Costs & Benefits i. Two perspectives: organizational & adopters ii. Consider the effects on both end – users and their middle managers iii. Goal is to persuade opponents to go along 1. Significant management changes may be required to prevent grassroots derailing efforts iv. The success of the organization may actually hinder willingness to adopt a new system

1. “why fix it it aint broke” Motivation Adoption i. Provide clear and convincing evidence of the need for change ii. Two basic strategies to motivate adoption 1. Informational strategy 2. Political strategy iii. Change management goal is to support and encourage the ready adopters and help them win over the reluctant adopters g. Training i. Adoption is enabled by providing the skills needed to adopt the change ii. Training should not focus on using the system iii. Training should focus on helping the users accomplish their jobs iv. Classroom training is most common, but others are better for specific situations v. Select Training Methods vi.

f.

h. Super User Support i. A content expert and super user “hang out” and assist the normal users 1. Ex: informatics Nurse 2. Ex: FROG – Freshman Orientation Guide 3. Ex: Peer Advisor

Chapter 7: Design Strategies 1. Key Ideas a. The purpose of the analysis phase is to figure out what the business needs b. The purpose of the design phase is to figure out how to provide it c. The steps in both analysis and design phases are highly interrelated and may require a serious amount of iteration 2. Design Strategies i. Developing custom app in house, buying and customizing a package, and relying on external b. Custom Development

i. ii. iii. iv. v. vi. vii.

Allows for meeting highly specialized requirements Allows flexibility and creativity in solving problems Easier to change components Builds personnel skills May tax firm’s resources May add significant risk Overall: total control over the system and the way the system looks/functions 1. Requires A LOT of time and highly skilled professionals 2. If not critical and something along the lines already exists 3. Use when time is an issue c. Packaged Software i. Software already written ii. Also called COTS or commercial off the shelf iii. May be more efficient iv. May be more thoroughly tested and proven v. May range from components to tools to whole enterprise systems vi. Must accept functionality provided vii. May require change in how the firm does business viii. May require significant “customization” or “workarounds” ix. Bought and installed in a relatively short amount of time x. ERP  automate business 1. Allow customization xi. MOST often written for common applications d. Outsourcing i. Hire external firm to create system or select COTS product 1. Could lose control 2. Be aware of barriers 3. External firm NEEDS to understand the requirements ii. May have more skills 1. Use if someone outside the company has better skills iii. May extend existing resources iv. Never outs...