IIL Location Intelligence for Policy Assessment (LIPPA) Project

The IIL LIPPA Project aims to address the inefficiency of the current Risk Analysis Product (RAP) system used by Inshore Insurance Ltd. The proposed system will utilize a single platform to operate on generated and primary data, and will run on SAP platform. The solution will greatly focus on data security to ensure that no unauthorized access is allowed to access confidential and sensitive data. The system will have different interfaces for recording new incidences, registering clients, analyzing the incidences, making and generating claim reports, making and generating payment reports, search panel, client profiles, and data archiving.

Running head: IIL LIPPA PROJECT 1
IIL Location Intelligence for Policy Assessment (LIPPA) Project
Student Name
Institutional Affiliation

IIL LIPPA PROJECT 2
Table of Contents
1.0 Introduction.....................................................................................................................................4
1.1 Introduction.................................................................................................................................4
1.2 Solution Scope.............................................................................................................................5
1.3 Solution Overview.......................................................................................................................5
1.4 Constraints...................................................................................................................................5
1.5 Exclusions....................................................................................................................................7
2.0 Use Cases........................................................................................................................................7
2.1 Actors..........................................................................................................................................7
2.2 Use Case Diagrams......................................................................................................................8
3.0 Design Overview.............................................................................................................................8
3.1 Solution Architecture...................................................................................................................8
3.1.1 Project Governance Process.................................................................................................9
3.1.2 IT Infrastructure Solution...................................................................................................10
3.1.3 Infrastructure Security........................................................................................................10
3.1.4 Application Solution..........................................................................................................12
3.1.5 Data Solution.....................................................................................................................12
3.2 Capacity Requirements..............................................................................................................12
3.3 System Interfaces.......................................................................................................................12
3.4 Constraints and Assumptions.....................................................................................................13
4.0 System Object Model....................................................................................................................13
4.1 Sub Systems...............................................................................................................................13
4.2 Subsystem Interfaces.................................................................................................................13
5.0 Object Collaboration......................................................................................................................14
5.1 Collaboration Diagrams.............................................................................................................14
5.2 Access Model............................................................................................................................14
6.0 Non-Functional Requirements.......................................................................................................14
6.1 Performance Considerations......................................................................................................14
6.2 Design Constraints.....................................................................................................................15
6.3 Test Criteria...............................................................................................................................15
6.4 Proof of Compliance..................................................................................................................15
7.0 Conclusion.....................................................................................................................................16
8.0 References.....................................................................................................................................17

IIL LIPPA PROJECT 3

IIL LIPPA PROJECT 4
1.0 Introduction
1.1 Introduction
System analysis is a very crucial task that should be regularly undertaken to determine if the
current system being used by the business meets its increasing requirements and demands.
Inshore Insurance Ltd (IIL) carried out an analysis on their existing Risk Analysis Product (RAP)
system and found out that there was a problem in location and timing of the accidents and crimes
which brings about vehicular, personal, and household insurance claims that directly relate to
cost and frequency. The system lacks the ability to time and locate events intelligently which
give rise to inefficiency in process flow within the company. This has caused incorrect frequency
estimation of accidents that happens and insurance claim cost. Therefore, estimating the future
budget is difficult and causes inaccuracy and inconsistency. Therefore, there is need to come up
with a system that will be able to address these problems that have arose because of the
inefficiency of the current system. It is expected that the Risk Analysis product will be excluded
from System Analysis in order to be run independently. In addition, RAP should be able to store
and support both generated and from the cloud using the system and one architecture.
One of the crucial requirements that is needed is the storage component which is needed in order
to fulfill the required storage capacity so that the system can run effectively and efficiently to
produce quality results (Valentijn et al., 2015). The proposed system will utilize a single
platform to operate on generated and primary data and is expected that the data volume will
increase drastically. However, the system is face with several challenges including data security,
unauthorized access, and performance limitation. The expected database size is 100TB and is
expected to increase yearly at the rate of 50% to 100%.

IIL LIPPA PROJECT 5
1.2 Solution Scope
The company seeks to have a high-level analysis and proposals for the information technology
solution. The scope of the solution is that the current RAP application will offer the needed
processing services. RAP will be separated and application impact analysis will be an
independent project. IIL has hosted the RAP application in their data center in virtualized in-
house environment. The proposed solution must describe one environment that can handle a vast
amount of generated and primary data.
1.3 Solution Overview
The proposed solution will run on SAP platform because it integrates well with the existing
database application. SAP offers the features for big data analytics and allow the company to
easily integrate their applications to the cloud. One of the benefits of integration is the ability to
provide in-house services. IIL will still focus on utilizing the RAP application for database
analysis (Vasylyna, 2018). SAP server will offer high accessibility because of the increased
performance and processing speed. The proposed IT solution will be flexible and scalable to
allow addition of more functions that may emerge in future. The solution will greatly focus on
data security to ensure that no unauthorize access is allowed to access confidential and sensitive
data.
1.4 Constraints
Data sensitivity is a very crucial aspect to any business. IIL wants to ensure that the data is
protected from any unauthorized internal or external access. It is very important to keep data
confidentiality to ensure data sensitivity is kept. Any data that can be used to directly or
indirectly identify an individual or critical resource of a business should be kept anonymous and
encrypted. However, it can be a challenge to achieve high-level data sensitivity because at times

IIL LIPPA PROJECT 6
authorized users may intentionally or intuitionally leak such data causing harm to the business
and affected individuals.
Having a realization plan or framework is essential in order to ensure that the business
expectations are clear. Business strategic planning process is the driving force of realization plan.
The framework constantly mirrors the business current objectives and strategic goals such as
quality, improvements, process, productivity, efficiency, customer service levels, cost
effectiveness, customer growth rates, revenue generation, and the rate if customer retention
(Thakur, 2016). However, it is necessary to examine all the dependencies and relationships in
order to get deeper insights where attainment of one benefit is dependent on realization of
another benefit. This can be a very challenging task.
It is also important to have a threat model to aid the business in identifying security flaws in the
system and addressing them. It saves on revenue, time, and maintains the company reputation. In
addition, it helps in bridging the gap between security and developers, documents all identified
and rated threats and risks, and offers awareness and knowledge of the emerging vulnerabilities
and risks. Designing a threat model can be a challenging task because it requires constant and
continuous system security review against emerging threats and vulnerabilities. The diagram
below gives an overview of steps to threat modelling:

IIL LIPPA PROJECT 7
Figure 1: Steps to Threat Modelling
(Source: Brewer, 2016)
1.5 Exclusions
When designing the application software, the IIL project team should clearly define what it will
do and the different states of the application, for instance, first run, create a new search/game,
operations, and foreground and background behaviors. Another aspect to focus on is user
interface which requires that the development team create wireframes for every interface with in-
depth description of operations, states, and controls (Spillner, 2015). Also, all the functionalities
should be represented, supported transitions and orientations, and error handling procedures.
2.0 Use Cases
2.1 Actors
 Analyst
 Risk Manager

IIL LIPPA PROJECT 8
2.2 Use Case Diagrams
Figure 2: Use Case Diagram
3.0 Design Overview
3.1 Solution Architecture
To better understand solution architecture, it is important to know the various IIL business
processes and the system architecture. Business process at IIL basically involves the insurance
claim in order to facilitate claim to a client. This is the high-level objective without alternative
options like rejecting a claim. The figure below better describes the business processes at IIL:

IIL LIPPA PROJECT 9
Figure 3: IIL Business Process
(Source: Garrett, 2014)
System architecture should be able to address the business processes in order to automate them.
The system should be able to capture the location and time when an accident occurred and make
real time updates. System architecture gives the different layers that the system is made up off
and describes every function associated with the layer. The system architecture should be made
up of the presentation layer (client), data access layer (Servers), and the persistence layer.
3.1.1 Project Governance Process
Managing project risks is very important and this can be achieved by aligning the risks against
the threat model. It should be acknowledged as a professional task and backed up by project
management principles and concepts. Project governance process gives guidelines on the best
practices and steps that can be taken to efficiently and effectively identify, examine, and address
project risks. Organizations and enterprises should strategically manage project risks and operate
in project mode. New structures, processes, and associations are needed to integrate risks related
to the project tasks together with corporate risk operations. It has become a governance role to
manage project risks.

IIL LIPPA PROJECT 10
3.1.2 IT Infrastructure Solution
System architects is responsible for defining the project both logically and conceptually. They
should have the ability to develop, analyze, and update blueprints or designs to give an overall
guideline for the project, system, or the entire business. When designing an IT infrastructure
solution, it can undergo different phases from conceptualization to implementation. Therefore, it
is to provide a roadmap or design for because it will help during marketing or training the users
about the system/concept. This creates a picture of how the system will look like or how it will
work even before developing it.
A conceptual design of the system that IIL needs to implement is a high-level design or abstract
of the most crucial elements and components. The major objective of a conceptual design is to
give a rough picture of the proposed IT solution. Logical design is am advancement of
conceptual design with more details including all the entities components and their relationships.
Connection and data flows in this stage are detailed in this stage. Logical designs are basically
targeted for system architects and developers.
3.1.3 Infrastructure Security
Security of IT infrastructure is very important because it ensures that not unauthorize access get
into the system or malicious programs such as viruses and malwares get into the system and
destroy the data (Telerik, 2018). Therefore, it is vital that IIL enforce various security measures
to secure its infrastructure. Some of the security measures that can be employed by IIL include:
Controlling log-in information: the company should develop policies with regards to login
credential such as passwords. The passwords should consist of mixed characters such as
numbers, special characters, and alphabetical letter both lower and upper case. Strong passwords
make it difficult for hackers to access the system. Also, the policy should state that the users

IIL LIPPA PROJECT 11
should change passwords regularly either weekly or after a specified period of time to better
enhance security and prevent hackers from guessing the passwords.
Use two-factor authentication: this provides an extra security layer and many internet-based
services such as Facebook, google, and twitter have employed this concept to safeguard their
users. IIL should also adopt this strategy by connecting their accounts to their mobile phones so
that even after putting in their passwords they need to key in the code sent to their mobile phones
via SMS.
Encryption: this is one of the commonly used strategy when transmitting sensitive data over the
network. Encryption means encoding data into a format that cannot be interpreted by anybody
else unless they have the encryption key.
Install antivirus: this is one way to prevent the system from being infected by malicious
programs that may damage the data or silently send sensitive and private information to
unauthorize users. Additionally, it is important to regularly scan the system for any infected files
that can affect the security.
Additionally, it is important to always delete the users that are no longer active in the system so
as to ensure that no unauthorized person from using their accounts to access the system.
Regularly update the system to fix any bugs that may render the system vulnerable and use a
strong firewall to protect the entire IT network infrastructure at IIL.

IIL LIPPA PROJECT 12
3.1.4 Application Solution
The application should be able to generate different reports such as accident reports, processed
claims, pending claims, new claims, payments made to clients, clients with payment issue among
other reports.
3.1.5 Data Solution
Data archiving is very important in ensuring that data is classified and structured properly. Data
archiving involves transferring data that is no longer used actively to different storage media for
retention and future reference if need arises (Margaret, 2016). This is very important because it
ensures that inactive data does not occupy more space where actively used data resides. IIL can
devise a strategy to allow the archive the data after a certain period it can be quarterly, half-year,
or yearly. Also, populating data is very important because it ensures that data is group or
categorized properly for easy access and referencing.
3.2 Capacity Requirements
The proposed system will require that some minimum requirements be met. There are several
factors that will affect the performance and productivity of the system. They include amount of
RAM and hard disk, workload, number of users, processing speed, NIC speed, and type of
operating system (TechNet, 2014).
3.3 System Interfaces
The system will have different interface that the user will interact with. They include interfaces
for recording new incidences, registering clients, analyzing the incidences, making and
generating claim reports, making and geniting payment reports, search panel, client profiles, and

IIL LIPPA PROJECT 13
data archiving. The interfaces should be kept simple, consistent, purposeful, proper use of colors
and texture, and the system should be communicating what the system is doing (Garrett, 2014).
3.4 Constraints and Assumptions
Some of the assumptions that the users are computer literate and can interpret some interface
elements without assistance. Secondly, IIL have network infrastructure already in place and have
installed all the necessary security measures (Spacey, 2017).
4.0 System Object Model
4.1 Sub Systems
Data storage will be in the SAP cloud servers and the users will be able to access them from their
desktops. The front end (the interface where the users will interact with the system) will be
accessible via desktop browsers while the back-end (database) will be in the cloud.
4.2 Subsystem Interfaces
The system will have various interface including:
 Client interface (client registration and profile updates)
 System administrator interface (monitor activities of the employees and clients on the
system and enforce security measures)
 Employee interface (report generation, registering incidences, processing claims, and
approving payments)

IIL LIPPA PROJECT 14
5.0 Object Collaboration
5.1 Collaboration Diagrams
The system should be able to be able to facilitate interdepartmental business processes to
integrate all the processes in all the departments. The processes should be able to integrate and
work collaboratively.
5.2 Access Model
The system will employ two-factor authentication to enforce extra layer of security to prevent
unauthorized access to the system. Also, the company should create a policy to regulate system
access such as password policies that requires users to regularly change their passwords and
users’ different characters in their password. Other security controls include user access
management, privilege management, user password management, user access rights, and
operating system access control (Records.nsw.gov.au, 2018).
6.0 Non-Functional Requirements
6.1 Performance Considerations
The following are performance considerations:
 RAM size
 Hard disk capacity
 Processing speed
 Network interface card speed
 Security and access controls
 Workloads
 Number of users

IIL LIPPA PROJECT 15
6.2 Design Constraints
Design constraints refers to design limitations. They include:
 Commercial constraints
 Functional requirements
 Compliance
 Non-functional requirements
 Integration
 Usability
6.3 Test Criteria
The system will undergo several test criteria including:
 Black box testing
 White box testing
 Usability testing
 Unit testing
6.4 Proof of Compliance
The system will ensure that all the legal obligations have been met and certificate of
incorporation provided (Epps, Norris & IBM, 2012). Also, the trustees, board members,
directors, and other stakeholders will take part in ensuring that none of their rights or privileges
have been affected.
7.0 Conclusion
It is very important to have a detailed plan when developing a system to ensure that the
development process is smooth with minimal interruptions. In addition, it is important to have all

IIL LIPPA PROJECT 16
the security measure in place to ensure that the system is secured from external attacks such as
malicious programs, hackers, and other cyber criminals. The developers should also ensure that
all the laws, regulations, and policies both of the organization and government have been met.

IIL LIPPA PROJECT 17
8.0 References
Brewer, W. (2016, September 28). IT Compliance and Software Development. Retrieved
October 16, 2018, from https://www.red-gate.com/simple-talk/opinion/opinion-pieces/it-
compliance-and-software-development/
Epps, C. V., Norris, N., & IBM. (2012, September 28). Software Development Compliance –
Overview. Retrieved October 16, 2018, from https://jazz.net/library/article/856
Garrett, E. J. (2014, May 21). User Interface Design Basics. Retrieved October 16, 2018, from
https://www.usability.gov/what-and-why/user-interface-design.html
Margaret, R. (2016, June 04). What is data archiving? - Definition from WhatIs.com. Retrieved
October 16, 2018, from https://searchdatabackup.techtarget.com/definition/data-archiving
Records.nsw.gov.au (2018, April 02). Developing systems: Information management
considerations.. Retrieved from
https://www.records.nsw.gov.au/recordkeeping/advice/developing-systems-
considerations
Spacey, J. (2017, June 9). 9 Types of Design Constraint. Retrieved October 16, 2018, from
https://simplicable.com/new/design-constraints
Spillner, A. (2015). Test criteria and coverage measures for software integration
testing. Software Quality Journal,4(4), 275-286. doi:10.1007/bf00402648
TechNet. (2014.). Estimating system capacity requirements. Retrieved October 16, 2018, from
https://blogs.technet.microsoft.com/megand/2014/04/06/estimating-system-capacity-
requirements/

IIL LIPPA PROJECT 18
Telerik, T. (2018, August 27). Retrieved October 16, 2018, from
https://docs.telerik.com/reporting/designing-performance
Thakur, D. (2016, February 04). Dinesh Thakur. Retrieved October 16, 2018, from
http://ecomputernotes.com/software-engineering/discuss-briefly-test-cases-and-test-
criteria
Valentijn, P. P., Ruwaard, D., Vrijhoef, H. J., Bont, A. D., Arends, R. Y., & Bruijnzeels, M. A.
(2015). Collaboration processes and perceived effectiveness of integrated care projects in
primary care: A longitudinal mixed-methods study. BMC Health Services
Research,15(1). doi:10.1186/s12913-015-1125-4
Vasylyna, N. (2018, July 20). 6 Basic Criteria For Testing Requirements. Retrieved from
http://blog.qatestlab.com/2011/05/07/6-basic-criteria-for-testing-requirements/