BITS MS- Dissertation Final Report

1

Birla Institute of Technology and Science

Pilani

First Semester 2014 – 2015

M.S. (Software Engineering)

Dissertation Final Report

Outage Management System using MicroStrategy 9.0

Name:Annie Sofia

Bits ID: 2010HW70678

2

SEWP ZG629T DISSERTATION

Outage Management System using MicroStrategy 9.0

Submitted in partial fulfilment of the requirements of

M.S. Software Engineering Degree Program

By

Annie Sofia

Under the supervision of

Sushovan Basu Bhowal

Technical Leader

Dissertation work carried out at

Wipro Technologies, Bangalore

BIRLA INSTITUTE OF TECHNOLOGY AND SCIENCE

PILANI (RAJASTHAN)

(November 20, 2014)

4

ACKNOWLEDGEMENTS

I would like to thank my supervisor Sushovan Basu Bhowal for his guidance and whole hearted

support. His valuable comments have been immensely helpful in enhancing the quality of work. I

would like to express my sincere gratitude towards my project mates for the support and

cooperation they have provided so far.

Special thanks to my examiners Joby Jacob and Harsha Nuti Prakash Gupta for their support

and guidance.

I am also thankful to WIPRO Technologies for giving me this opportunity and also

makingavailable all the resources required for this dissertation. I am also thankful to BITS, Pilani

andthe Training department for all their efforts in organizing this course.

My sincere regards and thanks to Prof. Ramesh for the guidance throughout the dissertation.

7

CONTENTS

List of Acronyms and Abbreviations………………..…………………………………………………8

List of Figures…………………………………….………………………………………………………8

List of Tables…………………………………….………………………………………………………..8

Introduction .............................................................................................................................................................. 10

Problem Statement.................................................................................................................................................... 10

The Existing Systems ................................................................................................................................................ 11

Objective .................................................................................................................................................................... 12

Scope of dissertation ................................................................................................................................................. 12

Roles and Responsibilities ....................................................................................................................................... 13

Requirement Analysis ............................................................................................................................................ 14

High Level Architecture Model of the proposed solutions: ............................................................................... 14

microstrategy architecture ....................................................................................................................................... 15

Benifits ........................................................................................................................................................................ 16

User Acceptance Criteria ......................................................................................................................................... 16

Functional specifications ........................................................................................................................................ 17

Overview of OMS Reports/Dashboard ................................................................................................................. 17

OMS Reliability Indices ........................................................................................................................................... 20

Emails notification for Outages .............................................................................................................................. 23

Process Model ........................................................................................................................................................... 24

Subsystem .................................................................................................................................................................. 26

Design specifications .............................................................................................................................................. 27

Overview of OMS Data Model ............................................................................................................................... 27

Data Load Strategy ................................................................................................................................................... 29

Overview of OMS Reports/Dashboard design .................................................................................................... 31

Testing Methodologies ........................................................................................................................................... 34

8

Features/Functionality to be tested ....................................................................................................................... 34

Implementation ........................................................................................................................................................ 41

Report Design Approach ......................................................................................................................................... 41

Report Analysis ......................................................................................................................................................... 41

Distribution and Sharing ......................................................................................................................................... 42

Code Promotion – [Dev -> ST / UAT -> Prod] ..................................................................................................... 42

Hardware and Software: .......................................................................................................................................... 43

Deliverables of the Work: ........................................................................................................................................ 43

Conclusion ................................................................................................................................................................ 44

References .................................................................................................................................................................. 44

List of Acronyms and Abbreviations

Abbreviations Meaning

EWAM Enterprise Work and Asset Management OMS Outage Management System

DMS Distribution Management System

IEEE Institute of Electrical and Electronics Engineers

BI Business Intelligence

SAIDI System Average Interruption Frequency Index

SAIFI System Average Interruption Frequency

CAIDI Customer Average Interruption Duration Index

MAIFI Momentary Average Interruption Frequency Index

SCD Slowly Changing Dimension

YTD Year to Date

9

List of Figures

Figures Details

Figure 1 Current reporting model

Figure 2 High Level Architecture Model of Proposed System

Figure 3 Process Model

Figure 4 Informatica Mapping of Daily Load

Figure 5 Informatica Mapping of NRT Load

List of Tables

Figures Details

Table 1 List of Config, Dimensions and Fact tables

Table 2 List of Source Tables.

10

INTRODUCTION

PROBLEM STATEMENT

Wipro has implement Enterprise Work and Asset Management (EWAM) platform for an American Utility

company to improve Transmission and Distribution (T&D) process. Over all it consists of two different

business process; Capital and OnM (Operations and Maintenances). In business term when an Asset is

going to install/remove is part of Capital process. But to run business installing Assets is not enough; one

has to maintain the same also to have sustained customer satisfaction, which is part of OnM process. To

provide uninterrupted services along with to track interruptions and resume services quickly all utility

businesses use Outage Management System (OMS). The Company also has OMS powered by ABB which

creates Outages/Events in the system and maintains its own lifecycle till it’s restored. This is also called

as DMS (Distribution Management System).

Like any other utility businesses, our client also wants to know how reliable their service is so that they

will be able to get how customers are satisfied with their services. Moreover its mandate by PUCN

(Public Utility Commission of Nevada) that they should be notified if there is any major outage goes on.

So to satisfy all these DMS is very much crucial system. IEEE 1366 document provides how to define and

calculate reliability indices which helps to answer all the questions regarding performance.

11

THE EXISTING SYSTEMS

Till this time the company is using in-house tool called RPM to extract data from DMS system and Excel

to calculate those reliability metrics. It takes week to generate reports. Moreover all are canned reports,

don’t have any flexibility. IEEE has been defined many exclusion mechanism to conclude reliability

measurement values more accurate and practical. Client also has its own criteria and model for

exclusion. All are manual process by looking into each event and calculate indices which increase

reporting time also. Below is the current reporting model:

Figure 1

Moreover, even if DMS system keeps track of all Outages but there is no system is place which will

calculate all these metrics and prioritize work of action. In other words, if there are many outages going

on with large no. of customer out higher management also should be notified and can take proper

action accordingly.

12

OBJECTIVE

The objective is to provide an Enterprise solution and implement a platform using which all business

requirements will be met. The platform will provide a bunch of reporting solution along with giving

flexibility to users to build their own report on need basis, generating email notification on based on

business rules and all configuration should be flexible and scalable enough just by changing few

parameters. This should have in-built error handling piece will help to avoid unwanted system

downtime.

SCOPE OF DISSERTATION

There are 2 recommended solution approaches to improve efficiency of business process.

1. BI (Business Intelligence) implementation on DMS system to have automated process of

reliability metrics reporting

2. Notification engine implementation to notify management and system control regarding

ongoing outages

The objective of this document is to explain the report design to meet the BI reporting requirements

for the OMS BI solution. The OMS BI solution will enable data access, across Distributed

Management System Database Base for analytical and historical reporting. The basic component

involved in the reporting solution is Microstrategy and the Dashboards/Reports can be accessed

from Microstrategy Web.

This document will cover the report design specifications and implementation details for this solution.

13

ROLES AND RESPONSIBILITIES

My area of specialization is Data Warehousing and Operational and Business Intelligence Reporting. I

have extensive experience in Data Modeling & Report design, and in working with technologies like

Actuate, Microstrategy, Oracle SQL, Informatica.

In this project my responsibilities are:

Coordination with the team and business units as required for requirements, solution, testing

and training.

Requirements gathering and analysis for proposed solution.

Participate in requirements and solution workshops

Functional design and configuration design

Technical Design, Configuration and Build for Microstrategy and Business Intelligence

Applications

Testing and Implementation support

Participate in Product walkthroughs to project and business stakeholders

Product fitment assessment and mapping of requirements to the product features.

14

REQUIREMENT ANALYSIS

The requirement is to provide a platform to user with pre-build report on Outage

management system along with reliability metrics calculation. User should have capability to

build their own report also using report architecture model. To monitor on going outages

business wants to have automated emails depending on business rules to keep track of

them.

HIGH LEVEL ARCHITECTURE MODEL OF THE PROPOSED SOLUTIONS:

OMS users will be able to access the reports through the MSTR web interface. The MSTR I-

Server will point to the Warehouse built out of DMS database at the backend.

The source data for the reports i.e. the Warehouse built out of Maximo database will be

deployed on separate server, other than the MSTR I-Server.

The diagram below represents the overall architecture of OMS BI Reporting solution for

OMS-BI.

Figure 2

15

Explanation:

i. Data needs to be extracted from DMS system periodically using Informatica

mapping and dump into Staging area

ii. From Staging database data will be transformed/calculated followed by IEEE

methodology and flowed to Warehouse using Informatica.

iii. Reliability indices Reports/Dashboards will be developed in MicroStrategy which

will be fed from Warehouse data.

iv. Notification reports will be built in MicroStrategy which will be used as email to

notify business.

MICROSTRATEGY ARCHITECTURE

I-server

MicroStrategy Intelligent server provides jobs management and analytical processing

for all MicroStrategy applications. This acts as a central component connecting the

metadata, warehouse, desktop, Web server and Narrow cast Server. Few or main

features: Reports Services, OLAP Services, Data Mining, Multi Source connection,

Caching, Clustering.

Web Server

MicroStrategy web server responds to the requests from browsers. Web server

interacts with the I-server to extract the necessary information. Can be installed on

most of the major web servers and supports most popular browsers.

Metadata

The database repository where definitions of all MicroStrategy objects are stored.

Metadata could be hosted on most databases. In simple words, Metadata could be

considered as the heart of MicroStrategy environment.

Desktop

MicroStrategy Desktop is a client used to interact with the Server.

All the above said components are depicted in the diagram below.

16

BENIFITS

This platform will provide a bunch of reporting solution along with giving flexibility to users to build their

own report on need basis, generating email notification on based on business rules and all configuration

should be flexible and scalable enough just by changing few parameters. This should have in-built error

handling piece will help to avoid unwanted system downtime.

USER ACCEPTANCE CRITERIA

The final working system should pass all the tests mentioned in the system test cases document. The

system should be able to maintain the complexity and be able to implement the write off process.

17

FUNCTIONAL SPECIFICATIONS

The objective is to explain the report functionality to meet the OMS reporting requirements for EWAM

solution.

The EWAM OMS reporting solution will enable data access for static reporting.

The basic component involved in the reporting solution is MicroStrategy. The scope of this document is

for OMS Reports.

OVERVIEW OF OMS REPORTS/DASHBOARD

The plan is to deliver 5 reports/dashboards to business as part of this implementation.

1. Asset Reliability Dashboard

Report Description:

The Asset Reliability Report represents data from DMS/OMS System in a graphical manner for various

metrics like SAIDI, SAIFI, etc.

After user provides the required month as input, the SAIDI and SAIFI metrics will get loaded with data

displaying the Actual YTD, Target YTD and Rating for that particular month.

On clicking on the graph, there will be a pop up providing a link to drill to the Organization level for

either SAIDI or SAIFI (depending upon which metrics has been selected)

On clicking the link in the pop up window, there will be a graphical display of below:

a. Current and Previous year metrics (for SAIDI/ SAIFI depending upon which has been selected)

b. Current and Previous year outages

The above graphs will be displayed with the corresponding ranking for Organization, Month, Cause and

Device/Asset.

While at Organization Level, on clicking the Current/Previous Year graphical bar, a pop up window will

display option to select a particular Business Unit.

In order to navigate till Feeder level, a Hyperlink will be established from Organization till Feeder Level.

18

The bottom of the report will be having link for Home, SAIDI, SAIFI, CAIDI, MAIFI and Help.

On clicking of any of the metrics link (SAIDI, SAIFI, CAIDI and MAIFI), the graphical details for

Organization, Month, Cause and Device will change according to the selected metrics.

Business Objective:

This report will help Business to monitor various outages getting recorded in the DMS/OMS system and

to take necessary and corrective measures.

This report will also help Business to analyze and prioritize their work depending upon the severity of

the issue.

2. Current Outage Report

Report Description:

This report will display the current outages in DMS/OMS systems according to Organization or Device.

The data getting displayed according to Organization can be further drilled down to Site/Business Unit,

Region, District, Sub Station and Feeder to fetch the data as per need.

On drilling down, the hourly trend will get displayed with various index points such as Customers

Degenerated, Total Customer Out, Active Outages, etc.

Business Objective:

This report will help Business to view the current outages on the system and it will also help them to

take necessary action according to the severity of the issue.

3. Worst Performing Circuits Analysis Dashboard

Report Description:

The report will display the metrics details such as SAIDI and SAIFI and other parameters such as

Customer Hours and Events (Number of Outages/Number of Trips) for the worst performing circuits

Business Objective:

19

The Business Objective of this report is to view the data for Worst Performing Circuits for the year till

date against defined metrics such as SAIDI, SAIFI and defined parameters like Customer Hours and

Events and take necessary action for the same.

4. Monthly Distribution Reliability Report

Report Description:

The Monthly Distribution Reliability Report will provide the below details for a particular month of a

year defined against various parameters as below:

1. The Year to Date (YTD) End Target, Year to Date (YTD) Actual and Target (Net), Year to Date

(YTD) % & Rating for North, South.

2. Interruption Report for the month consisting of Transmission, Substation and Distribution Net &

Gross for SAIDI, SAIFI, CAIDI and MAIFI Metrics.

3. The Year to Date for South and North SAIDI (NET) and SAIFI (NET) depicting the Target Details.

Further details for SAIDI (NET) and SAIFI (NET) against Region.

4. The Significant Service Outages by Quarter (TSD Gross).

5. Top 10 Interruption Causes YTD by Customer Hours in TSD(Transmission, Substation and

Distribution) Gross

6. Geographic Customer Hours Results (TSD NET).

7. Ten Most Active Circuits by Number of Trips (NET and GROSS).

8. Ten Most Active Circuits by Customer Hours (NET and GROSS).

9. Ten Most Active Circuits by Customer Interruptions (NET and GROSS).

Business Objective:

The Business Objective of this report is to view the Monthly Distribution Reliability Report for a

particular month of a year.

This will help Business in validating performance of Active Circuits and taking necessary action for the

circuits which have higher number of trips, Customer Hours and Customer Interruptions.

This will also help Business in identifying the main causes of interruptions and significant service outages

and ways to handle the same

20

5. Weekly Outage Report

Report Description:

This report will provide the weekly outage details and has the below mentioned specifications:

1. The outage details are calculated at Organization Level.

2. The Reliability Metric(s) is applicable for below mentioned:

o Interruptions

o System Average Interruption Duration Index (SAIDI)

o System Average Interruption Frequency Index (SAIFI)

o Customer Average Interruption Duration Index (CAIDI)

3. The above mentioned metrics will display the Actual and Planned values for Previous Week

(Immediate), Year to Date (YTD) and Year End

Business Objective:

The Business Objective of this report is to provide the correct picture of the reliability metric values

against defined parameters on a weekly basis to PUCN (Public Utility Commission of Nevada)

Note: - Week as per above details is from Tuesday till Monday

OMS RELIABILITY INDICES

1. SAIDI: System Average Interruption Duration Index.

The System Average Interruption Frequency Index (SAIDI) indicates the total duration of

interruption for the average customer during a predefined period of time. It is commonly

measured in minutes or hours of interruption. Mathematically, this is given as below.

SAIDI = Total Minutes of Interruption

--------------------------------------------------

Total Number of Customers Served

21

To calculate the Index, use the below rules

2. SAIFI: System Average Interruption Frequency Index.

The system Average Interruption Frequency Index(SAIFI) indicates how often the average

customer experiences a sustained interruption over a predefined period of time.

Mathematically, this is given as below.

SAIFI = Total Number of Customers Interrupted

-------------------------------------------------------------



3. CAIDI: Customer Average Interruption Duration Index.

The Customer Average Interruption Duration Index (CAIDI) represents the average time required to

restore service. Mathematically, this is given as below.

CAIDI = Customer Minutes of Interruption CMI

------------------------------------------------------------- = ---------

Total Number of Customers Interrupted CI

22


4. MAIFI: Momentary Average Interruption Frequency Index.

The Momentary Average Interruption Frequency Index (MAIFI) indicates the average of momentary

interruptions. Mathematically, this is given as below.

MAIFI = Total Number of Customers Momentary Interruption

-----------------------------------------------------------------------



23

EMAILS NOTIFICATION FOR OUTAGES

1. Internal Notification

a. 100 or more Customer Out

b. 500 or more Customer Out

c. TQS Customer(s) Out

d. Major Customer(s) Out

2. Pre-PUCN Notification

a. 1000 Customer-Hrs

b. 200 Customer-Hrs

c. 50 or more Customer Out for 8 Hrs

d. 50 or more Customer Out for 9 Hrs

3. PUCN Notification

a. 3000 Customer-Hrs

b. 50 or more Customer Out for 10 Hrs

4. Restore Notification once Outage has been restored

24

PROCESS MODEL

The development for this project follows the V-Process Model. The model is suitably customized

according to the needs this project.

Following are the different phases of the model for the proposed project.

Figure 3 - Process Model

Requirement Specification Phase

Design Phase

Coding Phase

Unit Test Phase

System Test Phase

Requirement Specification Phase: The goal of this phase is to produce requirement specification

document of the proposed system. Identify and document all the functional and non-functional

Requirement

Specification Phase

Design Phase

Coding Phase Unit Test Phase

System Test Phase System Test Plan

Unit Test

Plan

Integration Test

Phase

25

requirements completely and unambiguously. Also, a system test plan is prepared explaining the

approach for testing the features and functionality of the project. The system test cases are prepared

based on the test plan.

Design Phase: The goal of this phase is to produce a design document. Both, a high level and a detailed

design document will be prepared. An appropriate design methodology suitable for the project is

decided and a detailed design document is prepared. An integration test plan is prepared explaining the

approach for testing the interfaces between various units of the project.

Coding Phase: The main activity of this phase would be developing source code based on the detailed

design document. A unit test plan is prepared explaining the approach for testing the implementation of

features and functionality of each component or each module of the project. Unit test cases are

prepared based on the Unit Test Plan.

Unit Test Phase: The individual components of the project are tested according to the procedure

defined in the Unit Test Plan. The unit test cases are executed and their results are recorded.

System Test Phase: The system is tested, according to the test procedures defined in the System Test

Plan. Moreover, the test cases are executed and the results are recorded.

26

SUBSYSTEM

Informatica Power Center 9.6.1

Informatica PowerCenter is a widely used extraction, transformation and loading (ETL) tool used in

building enterprise data warehouses.

The components within Informatica PowerCenter aid in extracting data from its source, transforming it

as per business requirements and loading it into a target data warehouse. Informatica PowerCenter is

produced by Informatica Corp.

The main components of Infromatica PowerCenter are its client tools, server, repository server and

repository. The PowerCenter server and repository server make up the ETL layer, which completes the

ETL processing.

The PowerCenter server executes tasks based on work flow created by work flow managers. The work

flows can be monitored using a work flow monitor. Jobs inside the program are designed in a mapping

designer, which creates mapping between source and target. Mapping is a pictorial representation

about flow of data from source to target. Transformations such as aggregation, filtering and joining are

major examples of transformation.

27

DESIGN SPECIFICATIONS

The objective is to explain the micro strategy report/dashboard design details and the data model

design for this project.

OVERVIEW OF OMS DATA MODEL

The data model consists of 13Config/NRT tables, 19 Dimension tables and 16 Fact tables:

Config Table

Dimensions

Facts

CONF_OMS_CAUSE

CONF_OMS_CUSTOMER_HRS_INT

RP

CONF_OMS_MAJOR_CUSTOMER

CONF_OMS_MONTHLY_TARGET_I

ND

CONF_OMS_MONTHLY_WT

CONF_OMS_TQS_CUSTOMER

CONF_OMS_WEEKLY_TARGET_IN

D

CONF_OMS_YEARLY_TARGET_IND

OMS_CURRENT_OUTAGE_MAP

OMS_CURRENT_OUTAGE_NOTIFY

OMS_CUSTOM_OUTAGE_NOTIFY

OMS_NRT_RUN_NOTIFY

OMS_RESTORED_OUTAGE_NOTIF

Y

DIM_OMS_ARL_NWRELEXTYPE

DIM_OMS_ASSET

DIM_OMS_ASSETTYPE

DIM_OMS_CAUSE

DIM_OMS_CIRCUIT

DIM_OMS_CUSTOMER

DIM_OMS_DATE

DIM_OMS_DATEPERIOD

DIM_OMS_DATEPERIODTYPE

DIM_OMS_DISTRICT

DIM_OMS_EQUIP

DIM_OMS_EVENTACTIONTYPE

DIM_OMS_FEEDER

DIM_OMS_ORG

DIM_OMS_ORGANIZATION

DIM_OMS_REGION

DIM_OMS_SITE

DIM_OMS_SUBSTATION

DIM_OMS_TIME

FACT_OMS_CAUSE_BYCUSTHRS_RA

NK

FACT_OMS_CUST_TOTAL_HRS_INT

RP

FACT_OMS_CUSTSUPPLYLINK

FACT_OMS_EVENT

FACT_OMS_EVENTACTION

FACT_OMS_EVENTSBYASSETTYPE_S

UM

FACT_OMS_EVENTSBYORG_SUM

FACT_OMS_HOURLYTREND_SUM

FACT_OMS_RELWEXBYASTTYPYOY

FACT_OMS_RELWEXBYCAUSEYOY

FACT_OMS_RELWEXBYMONYOY

FACT_OMS_RELWEXBYORGYOY

FACT_OMS_RESTORATION

FACT_OMS_TARGET_ACTUALS

FACT_OMS_WEEKLY_REPORT

FACT_OMS_WORSTPERF_CIRCUIT

Table 1

28

Informatica mapping will be developed for data extraction from DMS source system to final EDW

database to load data.

Here is the DMS source table information:

DMS Source Table

EXT_ACCOUNT

EXT_CAUSE_CAT

EXT_CIRCUIT

EXT_CREW

EXT_CREW_ACTIVITY

EXT_CUSTOMER_PREMISE

EXT_DEVCAT_TYPE

EXT_DEVICE

EXT_DISTRICT

EXT_EMPLOYEE

EXT_EQUIP_CAT

EXT_FEEDER

EXT_FIELD_DEF

EXT_JTK_EVENT

EXT_LASTRUN

EXT_LASTRUN_LOG

EXT_LASTRUN_TMP

EXT_LINE

EXT_LOAD

EXT_MANUAL_EVENTS

EXT_MANUAL_EXCL_EVENTS

EXT_OPERATOR_EVENT

EXT_OUT_XFMR

EXT_OUT_XFMR_HISTORY

EXT_OUTAGE_CAUSE_CAT

EXT_OUTAGE_EQUIP_CAT

EXT_OUTAGE_FIELD

29

EXT_OUTAGE_LOG

EXT_OUTAGE_PTMP

EXT_OUTAGE_PVT

EXT_OUTAGE_REPAIR

EXT_PHASE_TYPE

EXT_SOURCE

EXT_SUB_AREA

EXT_SUBSTATION

EXT_TROUBLE_RPT

EXT_VOLTAGELV

Table 2

DATA LOAD STRATEGY

In high level there will be 2 sets of ETL job.

1. Daily Load

2. NRT Load

Daily Load

Daily load job will be running once in a day to load all master data i.e. All dimensions and fact tables

apart from Outage related Facts. All dimensions will be SCD2 to keep historical data change.

Figure 4

30

NRT Load

NRT load will be running in every 5mins and will extract all live outage related data to process. Email

notification will be sending end of this data process.

Figure 5

31

OVERVIEW OF OMS REPORTS/DASHBOARD DESIGN

As per the given business requirement and metrics, the report are created in micro strategy. Below

given are the few sample designs of the reports.

Asset Reliability Dashboard

32

Current Outage Report

33

Worst Performing Circuits Dashboard

34

TESTING METHODOLOGIES

The scope of testing includes testing the functionality of all the individual reports against the

requirements as specified in the requirement analysis and design document. All the reports will be

tested individually. The test data required for the individual reports will be prepared beforehand and

made available for unit testing the subsystems. Unit testing will be performed once the report

development is completed.

FEATURES/FUNCTIONALITY TO BE TESTED

Requirement Specification

Ease of Access The reports will be available for access through the MicroStrategy web portal.

Single Sign-On Business has to login to MicroStrategy portal to access reports. A link for this portal may be available at Developer Dashboard screen.

Look & Feel The report will follow the look & feel of all existing custom reports. There may be small variations in font & color since the tool is different.

The following standards will be adhered to as closely as possible.

For Number:

All Decimals will be round-off to two decimal digits.

All Dollar Values will have $ sign in front of the Value.

Font Size Bold/Italic/Underline Alignment

Row Header Lucida Sans Unicode

11 Bold Center Justified

Row Value Lucida Sans Unicode

9 Regular Left Justified

Column Header Lucida Sans Unicode

11 Bold Center Justified

Column Value Lucida Sans

9 Regular Right Justified

35

Unicode

For Text:

Font Size Bold/Italic/Underline Alignment

Row Header Lucida Sans Unicode

11 Bold Center

Row Value Lucida Sans Unicode


Column Header Lucida Sans Unicode

11 Bold Center

Column Value Lucida Sans Unicode


Common Information Across reports

The following fields will be common across all reports

- Report Run By: The user who ran the report - Report Run Date: The date on which the report was run - Prompts: The value of the prompts selected - Page number (Page X of Y): The page number will be on the bottom

left hand side of the footer and on the right hand side Date is displayed along with the day and time.

- Confidential – “For Internal Use Only”: This text should appear in all reports at the center of the footer.

Multipage Considerations

On every page, the following information should be available:

- Report title - Table/grid header - Footer Information - Logo

Logo The logo will appear on the top right side of the report & will be repeated across all pages.

Non-Availability of data If the input to the report does not return any data, based on the available data in the underlying database, then the user will get a blank report with a message – “No data returned for this view. This might be because the applied filter excludes all data”. The report will not catch the specific exception to notify the users on the reason.

36

Format for MicroStrategy Documents (RSD)

Section Standards

Logo Logo should be displayed at the Top-Right corner of the document.

Height of the Logo should same as that of the rounded rectangle around the Report Title

Document Document file name should be same as the Report name (without the report identifier)

Document Header

There should be a rectangle around Prompt\Summary Headers and Values in the document header section

Border color for the rectangle around Prompt\Summary headers and values should be set to RGB(68, 108, 128)

Line style for the border color for the rectangle around Prompt\Summary headers and values, should be set to (Solid, 2)

Report Title

Font Face should be set to 'Lucida Sans Unicode'

Font Size should be set to 16

Font Style should be set to Bold

Font Color should be set to White

Report title should be same as the Document Name

Report title (Text) should be Left aligned

Rounded Rectangle

Rectangle should be a rounded rectangle around the report title.

Fill Color of the rounded rectangle should be set to RGB(68, 108, 128)

Prompt\Summary Headers


Font Color should be set to Black



Prompt\Summary headers (Text) should be Right aligned

All the prompt\Summary headers (Text) are ending with a Colon (:)

Prompt\Summary Values



Font Style should be set to Plain

37


Prompt\Summary values (Text) should be Left aligned

Group Headers





Group headers (Text) should be Right aligned

All the group headers (Text) are ending with a Colon (:)

Group Values





Group values (Text) should be Left aligned

Grid Section Headers





Grid section headers (Text) should be Left aligned

Grid Column Headers





Fill Color of the column headers should be set to RGB(68, 108, 128)

Column headers (Text) should be Center aligned

Grid Line color should be set to Black

Grid Line property should be set to Thin

Grid Rows





Row values should be Left aligned for all columns with data type as VARCHAR, DATE

Row values should be Left aligned for all columns with data type as NUMBER

38

Grid Line color should be set to Black

Grid Line property should be set to Thin

Sub-Totals\Grand Total Headers





Fill Color of the sub-total\grand total headers should be set to RGB(68, 108, 128)

Sub-total\grand total headers (Text) should be Left aligned

Sub-Totals\Grand Total Values





Sub-total\grand total values are Right aligned

Page Number

Page number should be displayed in the document footer section with the format - Page X of Y



Font Color should be set to RGB(51,102,255)


Page number should be displayed in the document footer section at extreme Bottom Left of the document

Confidential Message

Text 'Confidential - For Internal Use Only' should be displayed in the document footer section





Confidential message should be displayed in the document footer section at Bottom-Center of the document

Report Execution Date and Time

Report execution time should be displayed at extreme Bottom-Right of the document footer section

Format of report execution time should be

39

set to 'Day, MM/DD/YYYY HH:MI AM/PM'





Form / Report Layout

Based on data volume and availability presentation of forms & reports may vary from the sample layout.

Slice & Dice, Drill-down Some of the static operational reports listed in Section 3.2 will not have any power, user capabilities like Slice & Dice, Drill-down/drill-up unless it is mentioned.

Page By Some Report will have Page by functionality which will allow user to select values and view report for that selection.Reports when exported to PDF will show the values in page by as bookmarks in PDF.

Drop Down Selection Some Reports will have Drop down Selectors in the header which will allow user to view data pretending to particular value selected in the selector. When report is exported to PDF , it will show data for current selection.

Abbreviations: NA

Export to Excel , PDF and Print Option

Report can be exported to PDF / Excel using MicroStartegy out of Box export feature.

Report can be printed using MicroStrategy out of Box “Print” feature. Reports will be optimised to be printed in Letter size Page.

Column width in Reports

All Column width will fit to content. Or modified as per the report look and fill.

Sorting Report will be sorted by first column Ascending by default unless it is specified and user will be able to sort on any column in report output.

40

Bulk Printing User will be having flexibility to print a selected/all completion forms for a order or list of orders in a single shot.

Update Comments User will have option to update review comments in specified reports.

If any Field/information below is blank, it means that information is either not available or not applicable.

41

IMPLEMENTATION

Below discussed are the implementation methods for micro strategy BI reports.

REPORT DESIGN APPROACH

The Reports and Dashboards are designed by the designer as per the requirements given, using the

MSTR Tool. As part for the Design Phase, Report layouts are validated to arrive at the Report Field

mapping and logic needed to arrive at aggregation and Formulae used in reports.

Once the Data Model is ready, the necessary tables are imported to MSTR environment using Project Creation Wizard or Warehouse Catalog.

On top these Table Objects, Facts and Attributes are created.

All the required relationships are defined at this stage of Attribute creation.

Next Application Objects will be created taking Schema Objects as base objects.

Metrics are created using Facts and all the Business rules/formula are applied here.

Prompts, Filters are the next to follow which are qualified on Attributes for most of the times, with respect to the requirements it can be qualified against Metrics as well.

Having created all the necessary objects, finally Reports or Data Sets are created as per the layout specified.

Keeping Reports as base Report Service Documents and Dashboards are created and are made available

for users to access via MSTR Web

REPORT ANALYSIS

This section details the various kinds of Report analysis users have requested and techniques which will

be adopted to implement the same.

The techniques which are technically feasible will then be documented in this section and for those

which are technically not feasible, alternate requirements will be recommended by the FA team and

Functional Specification Document will be updated accordingly by the BI Team.

42

Drill Up / Down

Slice & Dice, Drill-down/drill-up options are provided to the users. All the drill-down/drill-up is specified

as per the system default no new User Specific Drill Paths will be created.

Aggregate Analysis

MSTR as a BI tool provides an exclusive feature to handle aggregation at user defined levels.

DISTRIBUTION AND SHARING

The users can download Reports and Dashboards to Word document, Excel Spread sheet or a PDF and

then distribute them via email, Print, Post or Fax.

CODE PROMOTION – [DEV -> ST / UAT -> PROD]

Creation of objects will start in ‘Development’ environment in the build phase. Once all the required

objects are created in ‘Dev’, it will be migrated to ‘UAT’ environment through MSTR Object Manager.

As per the migration, following are the objects to be moved in the order specified from Dev to UAT.

1. Tables

2. Attributes

3. Facts

4. Prompts

5. Metrics

6. Reports

7. Report services documents

8. Dashboards

It is important to follow the precedence as mentioned above. By following so, the dependant objects are

moved first and later the object with the highest precedence can be moved without any tribulations.

And it is a good practice to follow the order to keep metadata in good health.

43

After moving all these specified objects, the UAT environment will be ready. Once all the reports get

signoff in UAT again the same procedure is followed as mentioned above by using MSTR Object

Manager to move the objects from UAT to Production environment.

When moving objects from ‘UAT’ to’ Prod’ apart from the above said objects the ‘Users’ and ‘User

Groups’ should also be moved to ‘Prod’ because it is only in UAT the users, user groups and their roles

are specified

HARDWARE AND SOFTWARE:

There is no additional infrastructure required for this implementation. Existing system of the company

will support all of these.

Below infrastructures are already available:

1. Unix boxes for Informatica/MicroStratery/Oracle

2. Windows box for client installation

3. Informatica 9.6.1

4. MicroStrategy 9.4.1

5. Oracle 11G

DELIVERABLES OF THE WORK:

Below is the list of deliverables-

1. Requirement specification

2. Functional specification

3. Detail design document

4. Unit/System test cases and test results

5. Informatica Mappings

6. Microstrategy Reports

7. Configuration data and documents

44

CONCLUSION

Performance issues can be handled by managing the cache of micro strategy. Also higher

versions of protected browsers help in this. Scheduling of reports are be done in the micro

strategy console, so that the reports are delivered over email to the corresponding people

on a timely basis.

The platform will provide a bunch of reporting solution along with giving flexibility to users to build their

own report on need basis, generating email notification on based on business rules and all configuration

should be flexible and scalable enough just by changing few parameters. This should have in-built error

handling piece will help to avoid unwanted system downtime.

REFERENCES

Software Engineering: A Practitioner's Approach (Roger S. Pressman) Mac Graw-Hill Science/Engineering/Math; 5th edition.

Software Testing: A Craftsman’s Approach, 2nd Edition, Paul C Jorgenson, CRC Press.

Micro Strategy Report Designer Guide

Micro Strategy Advanced Reporting Guide

http://nocapx2020.info/wp-content/uploads/2010/04/pages-17-19-from-rpu2009_e_and_o_report.pdf

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

BITS MS- Dissertation Final Report

Documents

Transcript of BITS MS- Dissertation Final Report