UW Business Analyst

Severity
Affected Functionality
Date raised, date closed
Fix rate
Rejection rate

Test rate - how long is has been taking to run each test
Key Functionality Test - identify the tests that cover high risk or high use areas
Software version tested

condtion or capability needed by a user to solve a problem or achieve an objective
condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard specification, or other formally imposed document
documented representation of a condtion or capability

business, user (stakeholder), functional (solution), non-functional (quality of service), constraint, and implementation (transtion).

refers to the agreed upon set of features that the final product will contain.

the propensity of scope to expand as stakeholders add requirements during the project without regard to its impact on budget, schedule and deliverables

anyone who has an interest in the successful outcome of th project - sponsors, users, business execs, managers, developers, clients. customers, vendors, and government or regulatory agencies.

Discovery (elicitation), analysis, modeling and documentation, communication, and validation.

priority

complete
accurate
testable
feasible
necessary
unambiguous
prioritized

Finance
Claims
Underwriting
Reporting
Information Warehouse

Production region
Production support Region (known as IND or INDDSAP)
Acceptance Region
CON Region
TST Region
SYS Region

Acceptance and CON

Perfective - software is refined
Adaptive - adaptation such as OS upgrades
Corrective - correct logic errors or design flaws

Magnitude of a risk is a joint function of the liklihood of something bad happening and the potential impact that might be felt if it does happen

Generic - universal, high level, any software
Specific - applies to the software YOU are testing

Usability
Tables
Conversion
Screen
Application
Concurrence
Integration
Regression
Recovery
Load/Stress/Volume
Production Trial

It is an effective system for integrating the quality development, quality maintenance and
quality improvement efforts of the various groups in an organization so as to enable production
and service to function at a level that allows for full customer satisfaction.

1. Setting quality standards
2. Appraising performance to assess the standards
3. Taking action when standards are not met
4. Consistently planning for improvement in the standards

1. A description of the particular situation/Circumstances being tested
2. The expected results
3. Reference to a particular test case

A good test plan should specifically mention who will do what, when and how.

1. Brainstorming
2. Document Analysis
3. Focus Group
4. Interface Analysis
5. Observation/Job shadowing
6. Prototyping
7. Requirements workshop
8. Reverse Engineering
9. Survey/Questionnaire

1. Technology factors (Hardware/materials, etc.)
2. Human factors
Of these, the human factors are the most important.

a) Prevention Costs – the cost of planning for quality and the costs of planning for dealing
with non conformance and defects
b) Appraisal Costs – the costs associated with measurement and evaluation of product
quality
c) Internal Failure Costs – caused by defective products, processes that don’t meet
compliance (ie. The time/cost for rework)
d) External Failure Costs – when non compliant products/processes reach the customer
(possible loss of customer loyalty and market share)

1. Analysis Phase
2. Requirements Definition
3. Design Phase
4. Development (may include Usability Testing)
5. Unit and or System Testing
6. Acceptance Testing (includes Volume Testing)
7. Implementation
8. Shakedown
9. Maintenance (Includes Regression testing)

Deliverables:
Project charter
Project charter sign-off
Kick-off meeting

Deliverables:
Business requirements document
Revised scope, estimates and plan
Business requirements sign-off
High level test plans

Deliverables:
Conceptual design document
Revised scope, estimates and plan (incl. test plans)
Conceptual design sign-off
Test region/environment plan

Deliverables:
Detail design documents
Revised scope, estimates and plan
Design document sign-off
Revised test region/environment plan

Deliverables:
Unit tested applications
Unit tested conversions
Client detailed test statements/cases

Implementation criteria
Table update plan
Fully tested applications
Fully tested conversions

Deliverables:
Production trial
Product available for use
User guides/procedures

Deliverables:
Shakedown definition – timeframe and criteria
Evaluation of items addressed, outstanding, plan to address
End of shakedown/turnover to production support

Deliverables:
Pilot structure and definition
Pilot success (or go forward) criteria

Deliverables:
Rollout Plan

Deliverables:
Lessons learned document
Contract closures
Release of resources

1. completing all project deliverables on time
2. within budget, and to
3. a level of quality that is acceptable to sponsors and stakeholders

planning

Any work that happens only once, has a clear beginning and end, and is intended to create a unique product or knowledge. It may involve only one person, or thousands. It may last several days, or many years. It may be undertaken by a single organization, or by an alliance of several stakeholders.

The application of knowledge, skills, tools and techniques to project activities in order to meet or exceed stakeholder needs and expectations of a project.

1. Clear Objectives
2. A Project Plan
3. Communication, communication, communication
4. A controlled scope
5. Stakeholder support

The scope of a project refers to the agreed upon set of features that the final product will contain.

Scope creep is a common occurrence and it describes the propensity of scope to expand as stakeholders add requirements during the project without regard to its impact on budget, schedule, and deliverables.

refers to the software development practice of embedding directly into the source code of a program

refer to the set of procedures or definitions that govern the way an organization does business

Hard Coding
- duplicate rules must be coded and maintained in many systems
- hard to isolate rules from code during maintenance
- even harder to change and test apps
- takes months to change hard coded business logic
- redundant development and maintenance costs
Business Rule Tables
- shared rules (reuse)
- rules are isolated from code
- only takes days to change BR
- lower development and maintenance costs

To ensure that the screens allow the end user to work efficiently and effectively on their business tasks.

To ensure that any tables used by conversion and/or the GIS applications can be successfully established and maintained.

To ensure that the conversion process will select and transfer all the required records between the mainframe and GIS

To verify that each screen is properly set up and connected before getting into business cases to test the application.

To determine that a particular application functions properly on a stand alone basis.

To ensure that the system successfully handles multiple clients attempting to access the same records at the same time.

To ensure that all required applications work together correctly. This involves entering data in one system which is then used as a basis for certain transactions in other systems.

To ensure that changes made during testing to correct errors have not caused additional errors in previously tested portions of the application. This kind of testing is a must with complex integrated systems like GIS.

To ensure that your backup and restore procedures allow you to properly recover from problems.

To ensure that the new/modified application will perform properly with normal and peak production volumes.

To determine as far as possible that the applicaiton has been correctly moved to the production enviroment and that both the new application and any existing related production applications still fuction properly.

The first and most critical step in testing. The test plan documents all the business cases and circumstances that will be attempted during testing.

Test cases are the actual transactions that you plan to process through the system as representative sample of the kinds of situations that can arise in the production enviroment.

Which screen/report you were on when the error occurred, how did you get to this screen?, which function keys or menu selections did you make immediately prior to the error occurring?, what was the error?

The potential that a chosen action or activity (including the choice of inaction) will lead to a loss (an undesirable outcome)

1. Identify Uncertainties
2. Analyze Risks
3. Prioritize Risks

Anytime someone in the project organization recognizes any subject matter that may be of interest to the project, something that could affect the project or may have an influence on some entity beyond project boundaries. These issues may include new business directions, a change in the scope of the project, new technical directions, a choice between one path over another, a future decision that must be made, an early alert to an potential problem.

- a general description of the issue
- the potential impact of the issue
- any suggested resolution for the issue

- Clear understanding of the needs of users, customers and stakeholders.
-Strong committment of the requirements development members to project objectives
- use of a repeatable requirements process that is continually improved
- ability to accomdate changes in requirements as they are progressively elaborated
- high quality systems and products
- systems development cost savings, accurate schedules, customer satisfaction

Advantages:
- Defects are detected early
- It is easier to fix defects detected earlier
- We get earlier feedback on the health and acceptability of the individual modules and on the overall system
- Scheduling of defect fixes is flexible, and it can overlap with development
Disadvantages:

A test cycle is the time it takes in a test environment to prepare for a test, execute the test, collect and analyze the results, report bugs, and recuperate

Finance, Claims, Underwriting, Infowarehouse

Reducing the risk of a serious fault occurring in production. Major issues are far, far more costly to address once a system goes live than if they can be identified sooner, and addressed. Functionality should be priority.

- Reduced Costs
- Sustained profit/market growth
- Greater customer retention
- Improved Infrastructure/Systems (more stable, robust)
- Improved morale and employee engagement

number of bugs found in testing divided by (number of bugs found in testing plus
the number not found)

using prior projects to set quality standards for processes and results

1. A project charter
2. A calendar of activities
3. A time schedule
4. A responsibility matrix
5. A project plan budget
6. Major milestones with target dates
7. A risk management strategy

Avoidance
Mitigation
Transferamce
Acceptance

- feasibility
- cost benefits analysis
- scope of what is being considered is determined
- team members identified

-actual business requirements defined
- info is gathered which wil be used to support the designing and building of the system
- goal is to make the system do what it needs to do.

- design details are documented using the requirements document as a guideline
- final document is used in draft form for the BA staff to review

- coding of the system
- debugging
- Unit/System testing (done by IT staff)
- normally little input from BA's at this time

- testers (having put together a test plan) will "test drive" the system
- goal is to run the system through simulated production tasks
- documentation is critical: ie: issue logs.
- other testing - usability, volume, concurrence, integration, regression

- changes are moved into the production environment
- always includes a "Production Trial"
- done in a down time period

- period immediately following implementation (usually about 2 weeks)
- focus is on any problems that may result from the changes
- priority is to fix any problems

- during the ongoing period following a release where the system is maintained on a daily basis

Requirements management

1. Start up
2. Business Requirements
3. Conceptual design
4. Detail design
5. Development
6. Acceptance
7. Implementation
8. Shakedown
9. Pilot Phase

- examine the business need or opportunity
- write a clear statement of project objectives
- know the difference between wants and needs
- negotiate the requirements definition interactively with the customer
- conduct a thorough and comprehensive anaysis
- document the results unambiguously in detail
- put the requirements document under version control

Cost
Schedule
Technical Objectives

How?
When?
By whom?
For how much?