The existing outage management system has several limitations: 1. It uses in-house tools to extract data from the distribution management system and Excel to calculate reliability metrics, which takes weeks to generate canned reports with no flexibility. 2. The calculation of reliability indices is a manual process that requires examining each event, increasing reporting time. 3. There is no system to calculate reliability metrics and prioritize work based on outages, nor to notify high management of major outages impacting many customers. The client needs a new outage management system to more accurately and efficiently calculate reliability indices, generate flexible reports, and notify stakeholders of significant outages.

1. 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. 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)

3. 3

4. 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.

5. 5

6. 6

7. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
-------------------------------------------------------------
Total Number of Customers Served
To calculate the Index, use the below rules
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. 22
To calculate the Index, use the below rules
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
-----------------------------------------------------------------------
Total Number of Customers Served
To calculate the Index, use the below rules

23. 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. 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. 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. 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. 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. 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. 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. 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. 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. 32
Current Outage Report

33. 33
Worst Performing Circuits Dashboard

34. 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. 35
Unicode
For Text:
Font Size Bold/Italic/Underline Alignment
Row Header Lucida
Sans
Unicode
11 Bold Center
Row Value Lucida
Sans
Unicode
9 Regular Left
Justified
Column Header Lucida
Sans
Unicode
11 Bold Center
Column Value Lucida
Sans
Unicode
9 Regular Left
Justified
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. 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
PromptSummary Headers and Values in
the document header section
 Border color for the rectangle around
PromptSummary headers and values
should be set to RGB(68, 108, 128)
 Line style for the border color for the
rectangle around PromptSummary
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)
PromptSummary
Headers
 Font Face should be set to 'Lucida Sans
Unicode'
 Font Color should be set to Black
 Font Style should be set to Bold
 Font Size should be set to 11
 PromptSummary headers (Text) should be
Right aligned
 All the promptSummary headers (Text) are
ending with a Colon (:)
PromptSummary
Values
 Font Face should be set to 'Lucida Sans
Unicode'
 Font Color should be set to Black
 Font Style should be set to Plain

37. 37
 Font Size should be set to 9
 PromptSummary values (Text) should be
Left aligned
Group Headers  Font Face should be set to 'Lucida Sans
Unicode'
 Font Color should be set to Black
 Font Style should be set to Bold
 Font Size should be set to 11
 Group headers (Text) should be Right
aligned
 All the group headers (Text) are ending with
a Colon (:)
Group Values  Font Face should be set to 'Lucida Sans
Unicode'
 Font Color should be set to Black
 Font Style should be set to Plain
 Font Size should be set to 9
 Group values (Text) should be Left aligned
Grid Section
Headers
 Font Face should be set to 'Lucida Sans
Unicode'
 Font Color should be set to Black
 Font Style should be set to Bold
 Font Size should be set to 11
 Grid section headers (Text) should be Left
aligned
Grid Column
Headers
 Font Face should be set to 'Lucida Sans
Unicode'
 Font Size should be set to 11
 Font Style should be set to Bold
 Font Color should be set to White
 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  Font Face should be set to 'Lucida Sans
Unicode'
 Font Size should be set to 9
 Font Style should be set to Plain
 Font Color should be set to Black
 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. 38
 Grid Line color should be set to Black
 Grid Line property should be set to Thin
Sub-TotalsGrand
Total Headers
 Font Face should be set to 'Lucida Sans
Unicode'
 Font Size should be set to 11
 Font Style should be set to Bold
 Font Color should be set to White
 Fill Color of the sub-totalgrand total
headers should be set to RGB(68, 108, 128)
 Sub-totalgrand total headers (Text) should
be Left aligned
Sub-TotalsGrand
Total Values
 Font Face should be set to 'Lucida Sans
Unicode'
 Font Size should be set to 9
 Font Style should be set to Plain
 Font Color should be set to White
 Sub-totalgrand 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 Face should be set to 'Lucida Sans
Unicode'
 Font Size should be set to 9
 Font Color should be set to
RGB(51,102,255)
 Font Style should be set to Plain
 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
 Font Face should be set to 'Lucida Sans
Unicode'
 Font Size should be set to 11
 Font Color should be set to
RGB(51,102,255)
 Font Style should be set to Bold
 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. 39
set to 'Day, MM/DD/YYYY HH:MI AM/PM'
 Font Face should be set to 'Lucida Sans
Unicode'
 Font Size should be set to 9
 Font Color should be set to
RGB(51,102,255)
 Font Style should be set to Plain
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. 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. 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. 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. 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. 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~