BIS261 Final Exam Paper

BIS261: Final Exam Study Guide
Exam Structure
Class, the Final Exam consists of the following:
• 42 Questions worth 250 points, which breaks down as follows: o 34 Multiple-Choice questions @ 5 points each o 8 Essay questions @ 10 points each
• There are four pages in the exam.
• Covers all of the reading assignments for the course: o Chapters 1-5, 7, and 16 from the textbook o International Association of Facilitators Basic Facilitation Primer o The articles from the DeVry University Library: Managing Virtual Teams by LaBrosse; Successfully Transitioning to a Virtual Organization by Lockwood; and Technology Support for Enhanced Productivity in International Virtual Teams by Seilheimer, Ishman, & Seilheimer
• Covers TCOs 1-8
Multiple-Choice
Questions
Pages 1 and 2 consist of multiple-choice questions that are similar to the Quizzes.
These are questions that are taken from all of the reading assignments and the weekly lectures. The best way to study for these questions is to review the reading, lectures, and quizzes. The multiple-choice questions will address the following topics:
1. Roles and responsibilities of a business systems analyst
a. ensure that the needs and wants of the client are represented correctly so that a solution can be developed and implemented by capturing and documenting the requirements needed to (design and) implement a solution
i. Analyzes the business processes to identify areas of inefficiency ii. Analyzes business requirements iii. Translate business requirements into IT projects to increase efficiency or profitability then works with the IT people to ensure the solution meets client’s needs
2. Business analyst's problem-solving approach
a. A systems analyst solves business problems using information systems technology
b. Problem solving means looking into business problem in great detail, completely understanding problem, and choosing best solution
3. Systems Development Life Cycle (SDLC) phases
a.
http://en.wikipedia.org/wiki/Systems_development_life-cycle
b. Requirements Analysis -> Design -> Implementation -> Testing -> Evolution-> Requirements Analysis
4. Types of information systems
a. Customer Relationship Management (CRM)
b. Supply Chain Management (SCM)
c. Accounting and Financial Management (AFM)
d. Human Resource Management (HRM)
e. Manufacturing Management
f. Knowledge Management (KM)
g. Collaboration Support Systems (CSS)
h. Business Intelligence System
5. SDLC models and development approaches
a. Waterfall, Prototype, Dynamic System Development Model, Object Oriented Model

b. V-Model (Diagram) showing how development activities are related to each other according to the V-Model of Systems Development. Steps are arranged in a V-shape. Down the left side, in time order, are Requirements Gathering (Analysis), Design, and Build or Acquire (Implementation); followed by, going up the right side, the testing activities of Unit Testing, Integration Testing, and Usability and Acceptance Testing. Horizontally, the relationships are that Requirements Gathering (Analysis) is tested by Usability and Acceptance Testing, Design is tested by Integration Testing, and Build or Acquire (Implementation) is tested by Unit Testing. The activities at the top of the V, Requirements Gathering (Analysis) and Usability and Acceptance Testing, are labeled as Business Focused, while all other activities at the bottom of the V are labeled as Technology Focused.
c. http://www.cms.hhs.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/SystemLifecycleFramework/downloads//SelectingDevelopmentApproach.pdf
6. Economic feasibility and cost/benefit analysis
a. Economic feasibility – expected benefits equal orare greater than the expected costs
b. Need cost/benefit to determine truly
c. Cost/benefit – determination of actual numbers using existing systems or formulas
i. http://www.freetutes.com/systemanalysis/sa3-cost-benefit-analysis.html bottom ofpage or see ilab excelfile.
7. Categories of feasibility analysis
a. Technical
b. Economic
c. Operational
d. legal
8. Requirements-gathering techniques
a. Interviews
b. Questionnaires
c. Site Observations
d. Record (artifacts/reports) review
e. JAD session
9. Prototypes
10. Categories of requirements
a. Functional – required for the system to meet stakeholder and user needs – what the system will do
b. Non Fnunctional – dictate properties and impose constraints – specify attributes of system rather than what it will do
i. Operational - Make the system work, but are optional ii. Performance – how the system runs (efficiency, exapandability) iii. Usability – look and feel or layout of forms and site
11. Meeting preparation documents: charter, agenda, ground rules
a. IAF_Facilitation_Manual - Shortcut.lnk
b. norms (shared values, or guidelines) like these helping your student projectteams perform better
12. Process interventions by a meeting facilitator
a. Pg 21 of facilitation manual
13. Advantages and disadvantages of virtual teams
a. Advantages
i. Dispersed worker base ii. Enables 24 hr work day iii. Increased access to better employees
b. Disadvantages
i. Technical problems ii. Lack of team building iii. Slower to hit team productivity (if ever)
14. Best practices for leading a virtual team
15. Online communication/collaboration tools: when and how to use each
a.
16. Class hierarchies: generalization/specialization and whole-part
a. http://en.wikipedia.org/wiki/Class_%28computer_programming%29
17. Types of events to be considered during event decomposition
18. Types of relationships: unary, binary, ternary, n-ary
19. Use case diagrams: purpose and how to develop
20. Multiplicity of associations in class diagrams
21.
or relationships in use case diagrams
22. Types of testing: definitions and when to use each
SHOULD BE DONE EVERY TIME
Test Type Description Purpose Performed By
Unit test (sometimes called stub test) Check each system component by itself. Ensure that each component was implemented correctly before integrating it into the larger system. Programmers (usually)
Integration test Check the components in combination with each other. Ensure that components work together, doing what they were designed to do. Programmers or QA staff
System test (sometimes called end-to-end test) Check the operation of the complete system in a controlled environment. Ensure that the system, as a whole, satisfies requirements. QA staff
Acceptance test Try out the system with actual users in a realistic setting. Determine if system meets user needs and will be accepted as complete by the user organization. Users
a. Functional - Does it meet functional requirments
b. Audit – performed by outside independent party to verify that a critical system complies with certain standards
c. Performance – speed and processing capacity of system
d. Load- examine how well system perfoms under high deman (# users)
e. Usability- ease of
use
f. Security- examine vulnerability to security threats, hacking, viruses
g. Black Box – consider only input and output, the system is a black box that no one can see inside
h. White Boxalso called glass-box looks at internal details like code and database records, or values of program variables
i. Alpha- done on early incomplete versions of a system (internal)
j. Beta – done on nearly complete version (often external)
k. Regression – repetition of previously done tests after bugs have been fixed to see if the fix has broken anything else that had already passed to ensure no new problems were introduced.
l.
23. Technical reviews, walkthroughs, and inspections
24. Participants in the testing process: who does what
25. Generation of test cases
a. Test case – individual test that can be performed as a single unit
i. The procedural steps make up a test script ii. At least one test case for every requirement iii. Requirements that are of greatest importance to the user, and those that carry the greatest risk, should receive the most attention during testing; less-important and less-risky requirements can be tested less thoroughly. iv. The following are a few guidelines for selecting test cases to be performed:
1. Test with several typical or expected input values.
2. Test with extreme input values (the highest and/or lowest values that are legal).
3. Test boundary values that are just above or below the legal range.
4. Test a few values that are way outside of the expected range (i.e., for a person's weight, try entering 1,000,000).
5. Test some nonsensical entries (a negative number for weight, or letters in a numeric field);
6. Test some likely user errors (e.g., swap height and weight; add an extra digit, leave off a digit, or transpose two digits; leave a required field blank; leave out the decimal point).
7. Test with exception conditions that are likely to occur at some time. (What if the printer runs out of paper? What happens if the power fails in the middle of a transaction? What happens if the record in the database is missing?)
8. Test with a range of hardware, software, and configuration settings that users are likely to employ. (For example,try several different screen resolutions, not just the one to which your own monitor happens to be set. For Web applications, this usually means testing with different browsers, such as Internet Explorer and Firefox.)
9. Some test cases are complicated, but not all of them need to be that hard. For example, a requirement that a web page should have a green background can be tested by just opening the page and inspecting the background color. For testing, as much as possible, follow the KISS rule: Keep it short and simple!
v. CASE tools (Computer Aided Software Engineering) generate test data and automates execution and analyzes test results
1. Examples:
a. LoadRunner and Quality Center from HP
b. Silk from Micro Focus
c. Rational series from IBM vi. the reality is that many organizations do not do as much testing as they should
1. Why ---
a. Time consuming and expensive
b. Uncovers problems that may extend a project
c. Longer project takes, more likely to be cut
d. Cut to keep to schedule if already fallen behind in other areas
2. Statistics
a. 95% do unit and system testing
b. 70% regression testing
c.