SAP Bank Analyzer – implementation

SAP Bank Analyzer Implementation Strategy -High Level Implementation / Overview

 SAP Bank Analyzer –

This article will explain best approach and Implementation approach for the SAP Bank Analyzer solutions, upgrade or integration. Recently I've had opportunity to work on two demo solutions for a banking system SAP Bank analyzer implementation within risk and profit analyses team and a short term test strategy development for rapid SAP bank analyzer implementation within an investment bank.

This article will explain best approach to implement SAP Bank Analyzer solution 8.0 or  upgrade from or integration. Recently we worked on two demo solutions for a banking risk system SAP Bank analyzer implementation within risk and profit analyses team and a short term test strategy development for rapid SAP bank analyzer implementation within an investment bank.

In next couple of blogs we will detail an effective way to test SAP Bank analyzer and its individual components.

 - SAP BA - Objectives in upgrade and in new Implementation

                 Business Architecture      

                Test Approach

There could be two scenarios either – Accounting IFRS implementation or risk architecture – see below diagram for both .. 

A)  Accounting IFRS implementation (accounting consequence, SGL scenarios)

B) Risk architecture

Lets review each of the element in the diagram
See SAP SDN for SDS -

 First later is SD component to load original data from other operational systems or source systems into the Source Data Layer (SDL) by means of an extraction, transformation, and loading process (ETL process).  The SDL saves, consolidates, and manages the original data. At the same time it provides interfaces to additional operational systems.

The primary objects of the Source Data Layer (SDL) and their scenario versions are a flexible way of saving master data, flow data, and market data. They also group this data into units that belong together logically from a business perspective. This ensures that the Bank Analyzer components that are linked to the SDL have a standard, consistent data source.

In addition to storing primary object data, the SDL provides the following primary objects functions for applications linked to it:

●     Access to source data

●     General functions for source data layer

●     Methods for source data

●     General access to corrections

●     Tools

Integration

The SDL provides both the central original data basis and a part of the underlying infrastructure for linked applications. It is therefore a key element in ensuring the consistency of data and results.

<To be updated soon) - if you need detail document, please email your request

Category 1 - business transactions

• Post external business transactions
• Update secondary business Transactions

Category 2 - date valuation
 

• Key date valuation for all financial positions
• Financial Positions for Period (PICC) event processing etc
• Update costing for period before GL and during transferring GL documents
• Calculation for all PICC

Category 3 – SAP GL Postings

• GL Connector and document generation – Journal and document review and finance reconciliation of the GL, Profit centre and any material code posting review
• Balance processing step 1 - (SV)
• Balance processing step 2 - (ATP)

Testing of the accounting for FI with Aggregation (AFI) for Accounts Results before RDL and GL

Category 1 – position management

• Generate Finance Instruments position
• Aggregate Financial Transactions
• Prepare Business Transactions for Aggregation
• Process Reassignments for Business Transactions
• Aggregate Business Transactions
• Aggregate Current Accrual Results
• Process Reassignments for Accrual results
• Aggregate Retroactive
• Accrual Results
• Derive Application Events for source data aggregation

Imported Sub-Ledger Documents (ISD) for Results

 ISD sub-ledger import

Data Warehouse Testing Recommendations

Data Warehouse Testing Recommendations

A data warehouse / business intelligence system is challenging to test. Standard testing methodology tests one little thing at a time, but a DW/BI system is all about integration and complexity, not to mention large data volumes. Here are my top five recommendations for building and executing a testing environment for your DW/BI project.

1. Create a small static test database, derived from real data.
You want it to be small so tests can run quickly. You want it to be static so that the expected results are known in advance. And you want it to be derived from real data because there’s nothing like real data to give you a realistic combination of scenarios, both good and bad. You will need to “cook” additional rows into the test database to test any branch of your ETL code that covers a data scenario not included in the original test data.

2. Test early and often.
Start testing as soon as you write a line of code (or connect two boxes in your ETL tool’s user interface). Developers do this all the time, of course, developing and running unit tests to ensure their code does what it’s supposed to do. Many developers aren’t as good about keeping track of all those tests, and running them often. Daily. Every time you check in code. If you run your tests daily, and prioritize fixing any tests that broke yesterday, it will be easy to determine what went wrong.
Unit testing assures that a developer’s code works as designed. System testing ensures that the entire system works, end to end, according to specifications. System testing should also begin early. There’s an official test phase before you go live; this test phase is for running tests and fixing problems, not for identifying what the tests should be and how to run them. Start system testing early in the development process, so all the kinks are worked out long before the pressure-cooker system testing phase begins.

3. Use testing tools and automate the test environment.
The suggestion to test early and often is practical only if you automate the process. No developer is going to spend the last hour of the work day babysitting unit tests! And few teams can afford a full time tester to do that work on the developers’ behalf.
To automate testing, you need tools. Many organizations will already have system quality assurance testing tools in place. If you don’t, or if you’re convinced your tools won’t meet the needs of the DW/BI system testing, try googling “software quality assurance tools” for an overwhelming list of products and methodologies available at a wide range of costs.

All commercial software test tools will allow you to enter tests, execute tests, log the results of test runs, and report on those results. For unit testing and data quality testing, define tests to run a query in the source and target data warehouse. You’re looking for row counts and amounts to match up.

A testing tool used for DW/BI testing must be able to run a script that sets up the test environment before the tests are run. Tasks you may need to execute include:

• Restoring a virtual machine environment with clean test data
• Modifying the static test data with special rows to test unusual conditions
• Running your ETL program

After the tests are executed and logged, end with a cleanup script, which may be as simple as dropping the VM environment.
Standard testing methodology has you change one thing, run a test, and log results. In the DW/BI world, you should expect to group together many tests into a test group. Even with a tiny test database, you don’t want to execute your ETL code for each of the hundreds of unit tests that you should be running.

4. Enlist the business users to define system tests.
We need the business users’ expertise to define good system tests. How do we know the data is correct? How do we know that query performance meets their expectations? Enlisting business users in the test specification process will ensure better testing than if the DW/BI team just made up tests based on what they think is interesting. Engaging key business users in the quality assurance process also provides a huge credibility boost.

5. The test environment must be as similar as possible to the production environment.
It is vitally important that the test environment be similar to production. Ideally, it’s exactly the same hardware, software, and configuration. In the real world, relatively few organizations have the budget for two big DW servers. But any organization can, and should, make the following elements matchup:

• Drive configuration (relative names for drives). Disk is cheap and you should be able to duplicate your disk for test. But if you can’t, at least make the drive letters and database file layout the same. Many people have whined at me that this is so much work to change the environment and make them the same. Yes it is! And so much better to do it now than in the final testing phase of your project.
• Software versions from the operating system to the database to the users’ desktops, and everywhere in between.
• Server layout. If the reporting system software will be on its own server in production, test it that way.
• Security roles and privileges for back room service accounts. Your deployment is virtually guaranteed to fail if you don’t test security roles first. I don’t know why, but it always seems to go wrong.

If you follow these suggestions, especially the suggestion for continuous testing, you are likely to have a smooth, crisis-free test phase and move into production on schedule. If not, you’re running a serious risk of having an otherwise fabulous project be delayed interminably in QA hell, with business users and management rattling the doors.

Software Testing into a High-Performance Organization

How to Turn Software Testing into a High-Performance Organization

___________________

Introduction Testing is often looked upon by many as an unmanageable, unpredictable, unorganized practice with little structure. It is common to hear questions or complaints from development such as: -What is testing doing?  -Testing takes too long  -Testers have negative attitudes  Testers know that these complaints and questions are often unfair and untrue. Setting aside the development/testing debate, there can always be room for improvement. The first step in improving strategy and turning a test team into a higher performance test team is getting a grasp on where you are now! You want to know: -What testing is effective?  -Are we testing the right things at the right time?  -Do we need a staffing upgrade?  -What training does our team need?  -How does the product team value the test effort?  In this article we provide a framework for assessing your team, including: how to plan for an assessment, how to execute the assessment and judge your current performance, what to do with the information, and how to chart an improvement plan toward higher performance. The Test Process Assessment The goal of doing a test process assessment is to get a clear picture of what is going on in testing, the good things, the problems, and possible paths to improvement. Fundamentally, a test assessment is a data gathering process. To make effective decisions we need data about the current test process. If done properly; the assessment will probably cross many organizational and management boundaries. It is important to note when embarking upon such an assessment that this effort is much larger than the test team alone. Issues will arise over who owns quality as well as what is the goal of testing? It is also important to note that a possible result of the assessment is that work may actually increase. There may be: -More demands for documentation  -More metrics  -More responsibility for communication and visibility into testing  For such an assessment process to succeed requires: -Executive sponsorship  -A measurement program  -Tools to support change  -An acceptance of some level of risk  -Avoidance of blaming testing for project-wide failures  -Commitment about the goal of testing  -An understanding of testing or quality assurance across the product team  -Responsibility for quality  Components of a Test Strategy - SP3 A test strategy has three components that need to work together to produce an effective test effort. We have developed a model called SP3, based on a framework developed by Mitchell Levy of the Value Framework Institute. The strategies (S) components consist of: -People (P1) - everyone on your team  -Process (P2) - the software development and test process  -Practice (P3) - the methods and tools your team employs to accomplish the testing task  Phase 1 Pre-Assessment Planning: The goals for this phase are to set expectations, plan the project, set a timeline, and obtain executive sponsorship. The actions that occur in phase 1 include meeting with the management of various groups, laying out expectations for the results of the process, describing the plan, and establishing a timeline. The intended result is to obtain agreement on expectations and buy-in on the assessment process and follow-up commitment for improvement. The phase 1 deliverable is a schedule and a project plan. In phase 1 it is important to: -Get executive buy-in  -Make a schedule and stick to it  -Give a presentation of what you are doing, why and what you hope to get out of it  -Make a statement of goals or outline of work as a commitment  -Make a scope document a pre-approval/budget deliverable  It is important to note up front that assessment is only the beginning of the process. Phase 2-Information Gathering: The goal of phase 2 is to develop interview questions and surveys which become the backbone of your findings. Actions in phase 2 include gathering documentation, developing interview questions, and developing a test team survey. The result of this phase is that you will be ready to begin your assessment using the documentation, interview questions, and test team survey. The deliverables include complete development process documentation, interview questions, and the tester survey. Examples of the documentation to be collected include: SDLC documentation, engineering requirements documentation, testing documents (test plan templates and examples, test case templates and examples, status reports, and test summary reports). Interview questions need to cover a wide range of issues, including (but not limited to): the development process, test process, requirements, change control, automation, tool use, developer unit testing, opinions about the test team from other groups, expectation of the test effort, political problems, communication issues, and more. Phase 3-Assessment: The goal of phase 3 is to conduct the interviews and develop preliminary findings. Actions include gathering and reviewing documentation, conducting interviews, sending out and collecting the surveys. As a result of this phase there will be a significant amount of material and information to review. Phase 4-Post-Assessment: The goal of phase 4 is to synthesize all of the information into a list of findings. Actions include reviewing, collating, thinking, forming opinions, and making postulations. The result of this phase is that you will develop a list of findings from all of the gathered information, reviewed documentation, interviews, and the survey. The phase 4 deliverable is a list of findings, collated survey answers, collated interview responses, a staff assessment, and a test group maturity ranking. The findings can be categorized into: -People  - Technical skills  - Interpersonal skills  -Process  - Documentation  - Test process  -SDLC  - Practice  - Strategy  -Automation  - Environment  - Tools  More subcategories may also be developed to suit your needs. Phase 5-Presentation of findings with project sponsor, executive sponsor and team: The goal of phase 5 is to present preliminary findings to executives and the project sponsor, and to obtain agreement on the highest priority improvement areas. It is important in this phase to be prepared for a very different interpretation of the findings than you perceived. The deliverable for phase 5 is an improvement roadmap. Phase 6 -Implementation of Roadmap: The goal of phase 6 is to establish goals with timelines and milestones and sub tasks to accomplish the tasks agreed upon for improvement. The action of phase 6 is to develop a schedule for implementation of the improvement plan. It is helpful at this point to get some aspect of the project implemented immediately so people can see tangible results right away-even if they are the smallest or easiest improvement tasks. The deliverable for phase 6 is implementation of items in the roadmap for improvement according to the developed schedule. Conclusion A test strategy is a holistic plan that starts with a clear understanding of the core objective of testing, from which we derive a structure for testing by selecting from many testing styles and approaches available to help us meet our objectives. Performing an assessment helps to provide the "clear understanding" and "understanding of the core objective of testing". Implementing the resulting roadmap for improvement can help to substantially improve the performance of your software testing organization and help to solidify your test strategy.

SAP Bank Analyzer Implementation Strategy -High Level Implementation / Overview (High level Process)

 SAP Bank Analyzer –

This article will explain best approach and Implementation approach for the SAP Bank Analyzer solutions, upgrade or integration. Recently I've had opportunity to work on two demo solutions for a banking system SAP Bank analyzer implementation within risk and profit analyses team and a short term test strategy development for rapid SAP bank analyzer implementation within an investment bank.

This article will explain best approach to implement SAP Bank Analyzer solution 8.0 or  upgrade from or integration. Recently we worked on two demo solutions for a banking risk system SAP Bank analyzer implementation within risk and profit analyses team and a short term test strategy development for rapid SAP bank analyzer implementation within an investment bank.


In next couple of blogs we will detail an effective way to test SAP Bank analyzer and its individual components.

 - SAP BA - Objectives in upgrade and in new Implementation Solution Architecture to  future looking business Architecture      
      

As IS Approach- There could be two scenarios either – Accounting IFRS implementation or risk architecture – see below diagram for both .. the Accounting IFRS implementation (accounting consequence, FSPL scenarios)



B) Risk architecture scenario



 
Transformation, and loading process (ETL process).  The SDL saves, consolidates, and manages the original data. At the same time it provides interfaces to additional operational systems.
The primary objects of the Source Data Layer (SDL) and their scenario versions are a flexible way of saving master data, flow data, and market data. They also group this data into units that belong together logically from a business perspective. This ensures that the Bank Analyzer components that are linked to the SDL have a standard, consistent data source.In addition to storing primary object data, the SDL provides the following primary objects functions for applications linked to it:
 See SDN for more detail

●     Access to source data
●     General functions for source data layer
●     Methods for source data
●     General access to corrections
●     Tools
 
Integration
The SDL provides both the central original data basis and a part of the underlying infrastructure for linked applications. It is therefore a key element in ensuring the consistency of data and results.
 <To be updated soon) - if you need detail document, please email your request

 Category 1 - Business transactions

• Post external business transactions

• Update secondary business Transactions

Category 2 - Date valuation
 

• Key date valuation for all financial positions

• Financial Positions for Period (PICC) event processing etc

• Update costing for period before GL and during transferring GL documents

• Calculation for all PICC

• Balance carry forward etc..  Create FT and BT, Period Open( Previous year),Set the posting date,register contract, Open new fiscal and End-of -day processing before you click on Execute BCF

Category 3 – SAP GL Postings

• GL Connector and document generation – Journal and document review and finance reconciliation of the GL, Profit centre and any material code posting review

• Balance processing step 1 - (SV)

• Balance processing step 2 - (ATP)

Testing of the accounting for FI with Aggregation (AFI) for Accounts Results before RDL and GL
Category 1 – position management

• Generate Finance Instruments position

• Aggregate Financial Transactions

• Prepare Business Transactions for Aggregation

• Process Reassignments for Business Transactions

• Aggregate Business Transactions

• Aggregate Current Accrual Results

• Process Reassignments for Accrual results

• Aggregate Retroactive

• Accrual Results

• Derive Application Events for source data aggregation

Imported Sub-Ledger Documents (ISD) for Results
 ISD sub-ledger import
- Please email if you need full info ....
 

 

Planning review process in test management

1. Reviews

Terms

Audit, IEEE 1028, informal review, inspection, inspection leader, management review, moderator, review, reviewer, technical review, walkthrough.

1.1 Introduction

A successful review process requires planning, participation and follow-up. Training providers will need to ensure that test managers understand the responsibilities they have for the planning and follow-up activities. Testers must be active participants in the review process, providing their unique views. They should have formal review training to better understand their respective roles in any technical review process. All review participants must be committed to the benefits of a well-conducted technical review. When done properly, inspections are the single biggest, and most cost-effective, contributor to overall delivered quality. An international standard on reviews is IEEE 1028.

1.2 The Principles of Reviews

A review is a type of static testing. Reviews frequently have as a major objective the detection of defects. Reviewers find defects by directly examining documents.

The fundamental types of reviews are described in section 3.2 of the Foundation Level Syllabus (version 2005) and are listed below in chapter 6.3.

All types of review are best executed as soon as the relevant source documents (documents which describe the project requirements) and standards (to which the project must adhere) are available. If one of the documents or standards is missing, then faults and inconsistencies across all documentation cannot be discovered, only those within one document can be discovered. Reviewers must be provided with the document to be reviewed in adequate time to allow them to become familiar with the contents of the document.

All types of documents can be subjected to a review, e.g. source code, requirements specifications, concepts, test plans, test documents, etc. Dynamic testing normally follows a source code review; it is designed to find any defects that cannot be found by static examination.

A review can lead to three possible results:

·                                 The document can be used unchanged or with minor changes

·                                 The document must be changed but a further review is not necessary

·                                 The document must be extensively changed and a further review is necessary

The roles and responsibilities of those involved in a typical formal review are covered in the Foundation Syllabus, i.e. manager, moderator or leader, author, reviewers and scribe. Others who may be involved in reviews include decision makers or stakeholders, and customer or user representatives. An additional optional role sometimes used in inspections is that of a reader, who is intended to paraphrase sections of the work product in the meeting. In addition to review roles, individual reviewers may each be assigned a defect-based role to look for particular types of defect.

More than one of the review types may be employed on a single product. For example, a team may hold a technical review to decide which functionalities to implement in the next iteration. An inspection might then be performed on the specifications for the included functionalities.

1.3 Types of Reviews

The Foundation Syllabus introduced the following types of review:

·                                 Informal review

·                                 Walkthrough

·                                 Technical review

·                                 Inspection

Hybrids of these types of reviews may also occur in practice, such as a technical review using rule sets.

1.3.1 Management review and audit

In addition to the types mentioned in the Foundation Syllabus, IEEE 1028 also describes the following types of review:

·                                 Management review

·                                 Audit

The key characteristics of a management review are:

·                                 Main purposes: to monitor progress, assess status, and make decisions about future actions

·                                 Carried out by or for managers having direct responsibility for the project or system

·                                 Carried out by or for a stakeholder or decision maker, e.g. a higher level manager or director

·                                 Checks consistency with and deviations from plans, or adequacy of management procedures

·                                 Includes assessment of project risks

·                                 Outcome includes action items and issues to be resolved

·                                 Participants expected to prepare, decisions are documented

Note that test managers should participate in and may instigate management reviews of testing progress.

Audits are extremely formal, and are usually performed to demonstrate conformance to some set of expectations, most likely an applicable standard or a contractual obligation. As such, audits are the least effective at revealing defects.

The key characteristics of an audit are:

·                                 Main purpose: provide independent evaluation of compliance to processes, regulations, standards etc.

·                                 A lead auditor is responsible for the audit and acts as the moderator

·                                 Auditors collect evidence of compliance through interviews, witnessing and examining documents

·                                 Outcome includes observations, recommendations, corrective actions and a pass/fail assessment

1.3.2 Reviews of particular work products

Reviews may be described in terms of the work products or activities that are subject to reviews, such as:

·                                 Contractual review

·                                 Requirements review

·                                 Design review

o                                                        preliminary design review

o                                                        critical design review

·                                 Acceptance review / qualification review

·                                 Operational readiness review

A contractual review may be associated with a contract milestone, and would typically be a management review for a safety-critical or safety-related system. It would involve managers, customers and technical staff.

A requirement review may be a walkthrough, technical review or inspection, and may consider safety and dependability requirements as well as functional and non-functional requirements. A requirement review may include acceptance criteria and test conditions.

Design reviews are typically technical reviews or inspections, and involve technical staff and customers or stakeholders. The Preliminary Design Review proposes the initial approach to some technical designs and tests; the Critical Design Review covers all of the proposed design solutions, including test cases and procedures.

Acceptance reviews are to obtain management approval for a system. This is also referred to as a Qualification Review, and is normally a management review or audit.

1.3.3 Performing a formal review

The Foundation Syllabus describes six phases of a formal review: planning, kick-off, individual preparation, review meeting, rework and follow-up. The work product to be reviewed should be appropriate for the qualification or the reviewer, e.g. a Test Plan for a Test Manager, a business requirements or test design for a Test Analyst, or functional specification, test cases or test scripts for Technical Test Analyst.

1.4 Introducing Reviews

In order for reviews to be successfully introduced into an organization, the following steps should occur (not necessarily in this order):

·                                 Securing management support

·                                 Educating managers about the costs, benefits and implementation issues

·                                 Selecting and documenting review procedures, forms and infrastructure (e.g. reviews metrics database)

·                                 Training in review techniques and procedures

·                                 Obtaining support from those who will be doing reviews and having their work reviewed

·                                 Executing pilot reviews

·                                 Demonstrating the benefit of reviews through cost savings

·                                 Applying reviews to the most important documents, e.g. requirements, contracts, plans etc.

Metrics such as reducing or avoiding cost of fixing defects and/or their consequences may be used to evaluate the success of the introduction of reviews. Savings may also be measured in elapsed time saved by finding and fixing defects early.

Review processes should be continually monitored and improved over time. Managers should be aware that learning a new review technique is an investment – the benefits are not instant but will grow significantly over time.

1.5 Success Factors for Reviews

There are a number of factors that contribute to successful reviews. Reviews need not be difficult to perform, but they can go wrong in various ways if factors such as these are not considered.

Technical factors

·                                 Ensure the defined process for the review type is followed correctly, particularly for more formal types of review such as inspection

·                                 Record the costs of reviews (including time spent) and benefits achieved

·                                 Review early drafts or partial documents to identify patterns of defects before they are built into the whole document

·                                 Ensure that the documents or partial documents are review-ready before starting a review process (i.e. apply entry criteria)

·                                 Use organization-specific checklists of common defects

·                                 Use more than one type of review, depending on objectives, such as document cleanup, technical improvement, transfer of information, or progress management

·                                 Review or inspect documents on which important decisions will be made, for example, inspect a proposal, contract or high level requirement before a management review authorizing major expenditure on the project

·                                 Sample a limited subset of a document for assessment not clean-up

·                                 Encourage finding the most important defects: focus on content not format

·                                 Continuously improve the review process

Organizational factors

·                                 Ensure managers allow adequate time to be spent on review activities, even under deadline pressure

·                                 Remember, time and budget spent are not in proportion to the errors found.

·                                 Allow adequate time for rework of defects identified by reviews

·                                 Never use the metrics from reviews for individual performance appraisal

·                                 Ensure that the right people are involved in the different types of review

·                                 Provide training in reviews, particularly the more formal review types

·                                 Support a review leader forum to share experience and ideas

·                                 Ensure everyone participates in reviews and everyone has their own documents reviewed

·                                 Apply the strongest review techniques to the most important documents

·                                 Ensure a well-balanced review team of people with different skills and backgrounds

·                                 Support process improvement actions must be supported to address systemic problems

·                                 Recognize improvements gained through the review process

People issues

·                                 Educate stakeholders to expect that defects will be found and to allow time for rework and rereview

·                                 Ensure the review is a positive experience for the author

·                                 Welcome the identification of defects in a blame-free atmosphere

·                                 Ensure comments are constructive, helpful and objective, not subjective

·                                 Do not review if the author does not agree or is not willing

·                                 Encourage everyone to think deeply about the most important aspects of the documents being reviewed