Consider Use Of Enhanced Modelling Concepts

Published Date: 02 Nov 2017

An online financial reporting system is a tool that generates financial statements, derived from stored accounting data that is submitted by a user via an online system. A financial statement consists of "records that outline the financial activities of a business, an individual or any other entity. Financial statements are meant to present the financial information of the entity in question as clearly and concisely as possible for both the entity and for readers. Financial statements for businesses usually include: income statements, balance sheet, statements of retained earnings and cash flows, as well as other possible statements" such as budgets. (Investopedia, 2009). The system stores, reads, and manipulates data in order to present findings/information which enables individuals or businesses to make sense of their financial performance and consider the findings when making key decisions.

In recent times, OFRSs have been preferred to the financial reporting tools provided by accounting software systems. Some of the reasons for this migration are due to the accessibility, speed and performance, data storage, usability, and interface of online systems. OFRSs are more effective and efficient compared to account software systems

Legacy Systems

Various online financial management systems that have financial reporting capabilities do exist within the market. These systems also offer other accounting services such as CRM, ERP, HR and Payroll, Banking, Tax Returns e.t.c. which are available via a software program or online. Some of the most popular systems that provide online financial management services:

Sage

Centage

ClearBooks

Kashflow

Free Agent

Liquid

Sage

Clearbooks

Liquid

Problem

Current systems

Solution

Auditor

Objectives

The goal of developing a usable, efficient and reliable financial reporting system as stated in the Appendix has been divided into SMART objectives that will help meet the requirements of system.

To create an operational system that meets the financial requirements of users.

To create a system that will be able to store, manipulate, and present summarised financial data.

To construct a modern and stylish interface that is user friendly and easily accessible.

To be able to extract customer insight (e.g. demographics) by executing queries on financial data stored on the system.

To provide accurate data to sole traders and individuals. This will allow them to make major decisions on their financial performance.

To build a system that will help clients manage and add value to their work.

System Requirements

Main User Stories

Report Organisation

Special Terminology

CRM – Customer Relationship Management

DBMS – Database Management System

DSDM - Dynamic Systems Development

ER-Diagram – Entity Relationship Diagram

ERP – Enterprise Resource Planning

HR – Human Recourses

OFRS – Online Financial Reporting System

PRINCE2 – PRojects In Controlled Environments 2

PRiSM - PRojects Integrating Sustainable Methods

Literature Review

Brief History

Existing Solutions

Relevant Technology

Critical Analysis

Methodology & Analysis

Project Management Methodology

Project management is a framework for planning, structuring and controlling of projects by managing various resources to achieve a specific goal that is time-bound. Project management methodologies that exist as methods to implement the various processes involved in managing a project can be used for different types of projects. One of the main and primitive methodologies the traditional approach consists of processes were one or two steps are adopted by all other methodologies. These processes include:

Initiation

Planning

Execution

Monitoring

Completion

The traditional approach consists of a cycle where each process is completed one after the other during the development of a project. Other methodologies include PRINCE2, PRiSM, Critical chain project management, Critical path method, Event chain methodology e.t.c. Some other methodologies used by companies mentioned in chapter 2 and also in the IT industry also include agile, scrum, DSDM, six sigma e.t.c.

The agile project methodology is considered suitable for the planning and development of Auditor. This is due to the requirements and objectives of Auditor which constantly changed to meet user requests. For example, during the initiation of Auditor, a plan to build an online financial reporting system was drafted with gathered user stories on features and performance of the system. The development of auditor was an iterative process where changes were made to the system after user reviews and constant testing.

In order to co-ordinate and implement these changes, scrum was used as an agile method to implement the various processes of a project management methodology. On the other hand, traditional methodologies are quite sequential and are implemented hierarchically with a step by step approach. In a traditional view, a process must be completed before another process begins. This could lead to issues such as client’s dissatisfaction with the finished product, since this approach doesn’t give them the chance to review the product they have requested since the initiation phase, after the requirements have been gathered.

The scrum process will be discussed in-depth in chapter 3.2. Furthermore, ways in which the implementation of scrum on chapter 5 and how it was applied in the development of Auditor will also be discussed in the next chapter.

Software Development Methodology

Software development methodologies are frameworks utilised during the planning, implementation and management of software systems. Various methodologies could be used in the development of an information system such as Waterfall, Prototyping, Rapid Application Development, V-Model, Spiral Development and Agile.

Figure Figure Figure

http://upload.wikimedia.org/wikipedia/commons/thumb/5/5f/Three_software_development_patterns_mashed_together.svg/420px-Three_software_development_patterns_mashed_together.svg.pnghttp://upload.wikimedia.org/wikipedia/commons/thumb/e/e8/Systems_Engineering_Process_II.svg/420px-Systems_Engineering_Process_II.svg.png

In this project, as stated on the project proposal in Appendix, the agile methodology was adopted. "Agile methodology is an alternative to traditional project management, typically used in software development. It helps teams respond to unpredictability through incremental, iterative work cadences, known as sprints. Agile methodologies are an alternative to waterfall, or traditional sequential development." (agilemethodology.org, 2008)

The agile framework scrum was used in the development of the Auditor system. As mentioned on chapter 3.1, as well as a project management methodology, "Scrum is used in the agile process for software development. But rather than a full process or methodology, it is a framework. So instead of providing complete, detailed descriptions of how everything is to be done on the project, much is left up to the software development team. This is done because the team will know best how to solve the problem they are presented."(Mike Cohn, 1998)

"Talk about sprint details such as the number of sprints and allocated time"

Auditor was developed and fully operational after 7 months 12 days. The project had a total of 16 sprints which lasted over 32 weeks. Since a sprint is completed in every 2 weeks, we can only get 2 sprints in a calendar month.

Comparison of Methodologies

Market Analysis

Summary

Design

Introduction

Auditor as a financial reporting system stores and manipulates data ranging user, financial and operational which then the system utilises and generates information to present. Some of this data include registered user details, financial performance, types of forms, charts, segments e.t.c. In order to efficiently manage this process, a relational database is essential in the successful development of the system. Adopting an agile approach which was chosen as both a project management and software methodology in chapter 3.1 and 3.2 means that changes will occur after the initial design of the database. This is inevitable due to the design decisions that are to taken during the process which might change upon constant review of the Auditor system throughout the management of the project.

Database Design Methodology

Adopting a database design methodology was the rational approach towards the construction of an efficient and operational database. Database design methodology includes various stages that were implemented successively on the completion of the design phase of Auditor. Each of these stages involved numerous procedures that need to be completed in order to develop an effective system. Exploiting the processes of the methodology to its full capacity helped with the planning, implementation, monitoring and management of the database. Database design methodology is divided into three phases which Auditor intended to accomplish upon its completion. These are known as conceptual, logical and physical design phases.

The conceptual design phase consists of the creation of a data model to represent the various entities involved in the development of the system which are independent of physical considerations such as the performance and robustness of the database system. The data model embraced for Auditor was an Entity Relationship Model (ER- Diagram). Some procedures included in this phase are identifying entities, detailing attributes and their domains for each entity, representing relationships, identifying primary and foreign keys for entities and constructing an ER-diagram.

The logical design phase builds upon the conceptual model. In this stage, the ER-Diagram is transformed from a model with entities to relations with unambiguous relationships. This is a model of information for the physical design phase. The processes involved in this phase included transforming entities to relations, mapping relationships and normalisation. One of the main purposes of this phase was to improve the quality of the data and remove any anomalies within it.

The physical design uses the logical data model as a source of information. It is a process that creates a description of the implementation of the database considering the targeted DBMS and other physical representations. This phase also focused on improving the performance of the database by enhancing data processing efficiency in order to apply the concepts in the logical design phase. Some of the decisions to be taken during this phase included storage format selection, file organisation, indexes, and query optimisation e.t.c. This phase will be tested and explained in chapters 5 and 6.

Critical Success Factors

The critical success factors that were considered during the construction of the database for Auditor in order to promote effectiveness and efficiency during the design process were:

Work interactively with the users

Follow a structured methodology throughout the data modelling process

Employ a data-driven approach

Incorporate structural and integrity considerations into the data models

Combine conceptualisation, normalisation and transaction validation techniques in the data modelling methodology

Use diagram to represent as much of the data models as possible

Use a Database Design Language (DBDL) to represent additional data semantics that cannot be easily be represented in a diagram

Build a data dictionary to supplement the data model diagrams and the DBDL

Be willing to repeat steps.

(Connolly, T M. & Begg, C E., 2009)

Conceptual Database Design

Conceptual Data Model

The conceptual data model is a graphical diagram that captures and identifies the data requirements of the database system. An Entity Relationship Diagram has been used for the identification of entities and mapping of relationships of the system. The ER-Diagram in Appendix 9.4 shows the graphical description of the proposed Auditor database system.

Below are the steps followed to building the Entity Relationship Model for the database:

Identify entity types

These are the various elements that the Auditor database system required in order to be in operation. For more information, please see data dictionary on Appendix 9.21

Identify relationship types

This step comprised the identification of the unique relationships between entities which consists of one-to-one, one-to-many, and many-to-many relationships. For more information, please see data dictionary on Appendix 9.22

Identify and associate attributes with entity or relationship types

This step described each entity with details that defines their purpose. For more information, please see data dictionary on Appendix 9.23

Determine attribute domains

This step described each attribute defining its type and length for all entities in the conceptual model. For more information, please see data dictionary on Appendix 9.23

Determine candidate, primary, and alternate key attributes

This step identified the unique keys that help in managing relationships between entities. When more than one candidate key is identified for an entity, primary or alternate keys are considered to be more appropriate. For more information, please see data dictionary on Appendix 9.23 or 9.24

Consider use of enhanced modelling concepts

The use of an extended entity-relationship model will not be considered within this phase. The use of concepts such as super and sub classes, generalisations, and specialisation are not integrated into the design of the database.

Check model for redundancy

In this step, the possibility of data redundancy was observed against the model and removed when present. This process was achieved in three steps. The first step identified multiple entities meeting the same requirement through the inspection of one-to-one relationships. The second step involved eliminating redundant relationships that provided similar information as other existing relationships with more capabilities. The final step considered the time aspect in relationships.

Validate conceptual model against user transactions

This step validates the data requirements gathered from the user and system requirements highlighted in chapter 1.6 and 1.7 against the conceptual model. This process checks whether the model satisfies user transactions. User transactions could be described as the tasks that the Auditor system needs to perform in order to be operative. The effectiveness of the model was verified through manual testing and also in chapter 6 usability testing. The failure of a transaction meant that the model was incomplete and required modifications.

Descriptions of some transactions have been identified below to meet the data requirements of the system.

Adding Data

Add a new user by entering their registration details

Add a new form submitted by the user

Add a new field created/chosen by the user

Add a new field created /chosen by the user with a segment

Add a new entry on the recent activity on the account made by the user

Add a new entry showing a field that belongs to a submit form

Add a new entry showing fields with the same names belonging to various categories

Add a new entry to record the various forms submitted for comparison with details

Updating/Deleting Data

Update/Delete user information

Update/Delete submitted form information created by the user

Update/Delete submitted field information created by the user

Update/Delete an entry of a recent activity on account created by the user

Update/Delete an entry showing a field that belongs to a submit form

Update/Delete an entry showing fields with the same names belonging to various categories

Update/Delete an entry that records the various forms submitted for comparison with their details

Selected Queries

Get user information

Get all the forms created by the user and sort them according to the creation date

Get all the fields submitted by the user

Get the entries of the most recent activities on the user’s account

Get a form submitted by the user showing all the submitted fields

Get all the fields in a form and consolidate the fields with the same names as one

Get all the forms submitted for comparison and compare specific attributes.

Review conceptual data model with user

In this step, the conceptual data model was reviewed to ensure that it captured and represented the various requirements of Auditor. If any irregularities are discovered during the review process then changes need to be made to the model. The conceptual data model must represent all the requirements posed by Auditor.

Logical Database Design

The logical data model is a managed process where entities in the conceptual data model are transformed to into relations in order to structure the model and validate the integrity of the data to meet the requirements of the Auditor system. The model is constantly refined to accomplish the data requirements.

Derive relations for logical data model

This step includes the various entities identified in the conceptual design phase which are now converted to relations with integrity constraints. A list of these relations with more information is defined in Appendix 9.24

Validate relations using normalization

An incomplete assembled database design will affect the effectiveness of the system, creating several problems such as data redundancy, invalidity, and irregularities. Normalisation is the process of refining relations to make them well formed through the removal of anomalies. Anomalies are the various modifications carried out on relations that are insertion, deletion and update. Some of the relations in the model were affected by anomalies. The relations with anomalies had to be normalised through three different stages which are 1st, 2nd, and 3rd Normal Forms.

1NF

A relation in the 1st normal form (1NF) has no repeating groups and every attribute is atomic. This was applied to all the relations in model because all records in each relation were unique and all non-primary key attributes were functionally dependent on the primary key.

2NF

In addition, some relations in the model were in 2nd normal form (2NF) because they already achieve 1NF and all non-primary key attributes were fully functionally dependent on the primary key. This was implemented by splitting the relations and removing the attributes that were only partially dependent on the primary key and copying the determinant

3NF

A relation in the 3rd normal form (3NF) is only valid if 2NF is achieved and non-primary key attributes are transitively dependent on the primary key. This was applied to some relations in the model by splitting them and removing the attributes that were not directly dependent on the primary key and copy the determinant.

The process of normalisation involves the splitting of relations which meant more relations were generated. Unfortunately, accessing information across the various connected tables in the next phase will be quite difficult and inflexible due to additional operations being required to retrieve data. This will have an impact on the performance of the system.

Validate relations against user transactions

In this step, the logical data model was validated to ensure that it met the requirements of the Auditor system. Completing the transformation of all entities to relations without errors helped accomplish this step. Thorough examination and development of the logical model and data dictionary would reveal any errors that reside within the model. Any errors that did occur were due to failure in the designing of the data model. These errors were then investigated and fixed.

Define integrity constraints

To avoid the existence of data redundancy, invalidity, and irregularities in the database system, the integrity constraints stated below must be considered.

NOT NULL integrity

All attributes in the database can contain NULL values. However, when the NOT NULL constraint is set for chosen attribute, then it must always contain a value at all time. This has been specified in the data dictionary in Appendix 9.3.

Domain integrity

The attributes in the database must comply with the restrictions set in their domains as seen on Appendix 9.23. The defined data types and lengths will limit the values of attributes when creating the relations.

Entity integrity

All primary keys specified in relations in the database can’t take null values. See data dictionary in Appendix 9.3.

Referential integrity

All foreign keys in the database can take a null value. However, they must reference a primary key another relation.

Review logical data model with user

This step allowed the validation of the database to the requirements of the Auditor system in order to check whether these requirements were achieved.

Merge logical data models into global model

This step wasn’t integrated in the database design because an extended entity relationship model wasn’t considered in the conceptual design phase. Concepts such as super and sub classes, generalisations, and specialisation were not implemented in the data model.

Check for future growth

The logical data model is definitely capable of adopting changes in the near future if there are any.

Development

Sprint 1

Overview

"Talk about the sprint velocity, process and procedures"

Requirement

Test Plan

Design

Implementation

Testing

Sprint 2

Overview

"Talk about the sprint velocity, process and procedures"

Requirement

Test Plan

Design

Implementation

Testing

Sprint 3

Overview

"Talk about the sprint velocity, process and procedures"

Requirement

Test Plan

Design

Implementation

Testing

Usability Testing

Introduction

Method(s)

Results & Analysis

Critical Review

Introduction

Problems encountered & Solutions

Achievements and Limitations

Legal, Ethical and Social Ramifications

Future Work