Mobile Disaster Management System Implementation

Executive Summary

MQ IT solutions has outlined in the following report two main approaches to achieve the end goal of a functional Mobile Disaster Management System (MDMS). One approach uses existing technologies as opposed to starting software from scratch. There are obvious financial and time advantages to both approaches and they should both be considered by the business before implementation. Risks associated with moving to a cloud based system have been outlined with possible vulnerability such as denial of service attacks identified. While the MDMS does represent a safer future system that is both more scalable and efficient, all possible risks should be discussed before implementation to safeguard against future problems.

Table of Contents

Executive Summary

Current System

Future System

Scope For Project

Expected Benefits

Benefits Realisation Plan

Project Components

Project Process Model

Risk management plan

Recommendations

Current System

The current disaster recovery process is a traditional telephone based approach. This however is not a completely reliable or realistic approach for the future. More investigation on the current system should be undertaken along with interviews with key personal and observation of current system use. This will allow for a more accurate scope of what is required in the project. Issues lie with scalability as well as the issue of there being almost no continuity or redundancy plans possible. If a natural disaster such as an earthquake destroys telephone lines, there is no way of recovering telephone systems until the internet service provider or telecommunication companies get the issue resolved.

Daisy is in the process of changing the traditional telephone-based disaster management system of the organization to a new system.

Future System

The Future system focuses on the use of mobile technology as opposed to traditional telephone line approaches. The advantages of this are your disaster recovery system is always operational. Cloud based services allow people to be contacted and warned of the disaster regardless of telephone lines being non-operational which is a common issue during disaster situations. Cloud based operations are also significantly more scalable meaning a business does not pay for a resource they don’t utilize. The proposed disaster recovery system will notify people of a disaster via social media, text messages, and push notification via pre-downloaded applications. Its online nature means it accesses and passes on information from a variety of sources including the local disaster alert system and the global disaster alerts and coordination system (GDACS).

By ensuring all employees have a disaster recovery application, they can receive push notifications of any upcoming issues. In addition, their phones can ping back to a server with information on geographic location that is constantly updated to a database. In the event of a natural disaster the last known location of an individual can be used to track them down if they were hypothetically buried in rubble resulting from anS earthquake.

MQ IT solutions have developed 2 main approaches moving forward in the disaster recovery mobile network project. By using existing API’s and integrating these into one complete piece of software, there can be a reduction in costs and the time taken for project completion. Another option for the project is to implement completely new software from scratch. This approach is both costly and time consuming however it provides the client with a more appropriate solution to their issue.

Scope for Project

This project will consist of changing an outdated traditional telephone-based disaster management system to a mobile disaster management system (MDMS), focusing on using mobile technology to improve response capabilities of the organisation in times of natural disaster. The goals of the new system are listed below:

• Cloud-based;
• Support most wired, wireless and mobile devices;
• Support push-functionalities (e.g., pushing alerts to users);
• Open Source;
• Incorporate information from social media such as Twitter;
• Easy to integrate with current systems.

The project will be undertaken in the following sub-phases:

• Initiation
• Planning
• Requirements Analysis
• System Design
• Implementation
• Roll out of System
• Support
• Closing

The project will be allocated to the team members below, as well as a limiting budget of $100,000,000 for the project and the consultancy company.

• Project Management Expert
• Software Expert
• Marketing Guru
• Accountant
• Admin Support

The key stakeholders in this project include the organisation and employees of the client’s organisation as they will be the primary users of the system. The project is expected to be completed in a timeframe of six months. This will encompass the entire project, from planning to the presentation of the new system.

Expected Benefits

The expected benefits of the project include improving response capabilities of the disaster management system as well as improve its capabilities in providing information to the public. Using a MDMS can provide useful information such as updates from the nation’s disaster alert system, locational information for people to help and efficient disaster recovery procedures can be made readily available to people in the affected area. A cloud-based system also improves stability of the system tremendously, making it more reliable as opposed to the previous telephone-based system which is extremely vulnerable in an area prone to earthquakes. Enabling push notifications to individual mobiles will also improve the effectiveness of the system by providing a quick and efficient way to notify people in immediate danger. A cloud-based system will also be more cost-efficient as the organisation will not be paying for resources they aren’t utilizing.

Benefits Realisation Plan

Improved response capabilities of system

Primary Outcome

With a focus on mobile technology, the new system should improve on the response capabilities of the old system, meaning faster response times and reaching a wider range of individuals in the affected area. The employees will be the main party that benefits from this objective as this increases the quality of service provided by the organisation.

Secondary Outcome

With the resulting improved service, the organisation may benefit by creating a positive work environment for employees, increasing efficiency.

Key Performance Indicator

Time taken for sent notification to reach an individual’s mobile.

Date of Review

This benefit can be reviewed immediately after development of the new system. Its outcomes are both easy to be recognize and assess.

Improved information distribution

Primary Outcome

Using a cloud-based system, information can be stored online and readily available to people in need. The quality of information will also increase, as the system integrates information from several different sources such as social media and the national disaster alert system. The employees benefit from this improved service.

Secondary Outcome

With information being stored online and of higher quality, the organisation should experience an improved awareness of natural disasters.

Key Performance Indicator

Number of users actively using the application.

Date of Review

This benefit will be reviewed after the new system has been operational for 3 months. This provides time for users to become accustomed to the new features and allows for preliminary growth of the user base which can be revisited to monitor growth.

Improved stability

Primary Outcome

By moving the system to the cloud, it will become more stable and reliable as a result. This is especially relevant as the system will be dealing with natural disasters and it needs to be able to be relied upon by the users. Improving the stability benefits the organisation in providing a more robust service as well as reducing costs in maintenance of the system.

Secondary Outcome

The employees benefit from improved stability of the system in times of crisis.

Key Performance Indicator

Percent of downtime the system experiences in a year.

Date of Review

This benefit will be reviewed after a year of operation with the new system.

Improved cost-effectiveness

Primary Outcome

A cloud-based system improves cost-effectiveness of the system as the organisation only needs to pay for the services that it utilizes. The organisation benefits from this by reducing costs.

Key Performance Indicator

Annual costs of the system.

Date of Review

This benefit will also be reviewed after a year of operating the new system.

Project Components

Scope

The scope of the project is to create a cloud based system that revolves around using mobile devices to communicate with the cloud servers to receive push notification alerts on the mobile phones using a dedicated application. Daisy has given the features of the system and what is required for the new system to be implemented within a time frame.

The Features of the project’s goals:

• Must be cloud based
• Support wired, wireless and mobile phone devices
• Is open source
• The support for push notification functions
• Is easy to integrate with the current available systems
• Integration of social media information

Cloud Based

The new system that Daisy is going for is that it will need to be cloud based. This cloud based solution will be able to extend the current system as it allows it to store vital information within its database servers in the event an earthquake does occur resulting in the physical system being broken down. The cloud based solution will deliver daily backups of the current system.

Support for wired, wireless and mobile phones

The support for cross-platform operating systems is important as everyone will be able to use the application for any device whether it is wired, wireless or any mobile device.

Open Source

This allow customers who use the application to recode the application to their own likings e.g. The user is able to recode the application to only push notifications based only on their desired locations instead of every single geographic location in the area or country.

Support for Push Notifications

The application that is going to be developed will have a push notification function integrated within the application which allow Daisy’s company to be able to send notifications live to its users.

Ease of Integration

Integrating it with the current system will be made easy for Daisy’s digital imaging company as the systems will be able to work with each other to achieve the utmost stableness of the systems combined.

Integrating Social Media

The integration of a social media feature will be useful as users can tweet or post live events or videos of the whereabouts they are in the event of a natural disaster.

Project deliverables

• Initiation
• Planning
• Requirements Analysis
• System Design
• Implementation
• Roll out of System
• Support
• Closing

Initiation

1. Interviews
2. Forming the project team
3. Developing the project charter

Planning

1. Development of project plan
2. Developing and refining the other plans
3. Define the risks and risk management approach
4. Creating the Work Breakdown Structure

Requirements Analysis

1. Defining the requirements
2. Evaluating current intranets
3. Define user requirements
4. Define content requirements
5. Define system requirements
6. Define detailed functionality

System Design

1. Modelling UML
2. Check constraints on the models
3. Make the final decision on cross platforming adoption

Implementing

1. Setting up MDMS system
2. Testing phase

Roll Out

1. Communication of roll out plan to users
2. Kickoff user training
3. Release the internal PR

Support

1. Determine what resources are needed
2. Make appropriate staff changes
3. Determine the support stages
4. Conduct a review for the post implementation stage

End

1. Prepare and present final report and presentation

Management and Allocation for MQ IT SOLUTIONS staff

All the employees shown on the table below are created as part of the overall team that is initiating this project. All the employees are listed with their allocated groups and standard hourly rate with the percentages of how many people there are being 100% meaning 1 employee.

Project Process Model:

Initiation Process:

This is where the whole project starts off. Interviews will be taken into place for employers. After the interviews are up, usually resulting in 1 weeks’ worth of time, the next process is started. Forming the project team and developing the project charter will be done in 3 weeks with 1 and a half weeks for each process respectively. When the 2 stages are complete, we continue to the next stage, the planning stage.

Planning Process:

The planning stage consists of development of all processes and allocation of staff and resources based off desired costings. The planning stage starts off with the development of the project plan. This then pans out into three different processes. The three stages are resource and staffing, budget and acquisitions and purchases.  Resources and staffing consists of calculating the amount of resources for each component is needed and how many staff is needed and is allocated afterwards. Acquisitions and purchases are sorted accordingly which both the processes are then tied to the budget. With the budget, the project manager can determine how much is needed for each process. Other plans will also be looked at in detail in the developing and refining other plans process.

After development and refinement of the other plans, a risk management process and risk matrix are made to be put in place in case of an emergency that will occur from natural disasters. With the cloud based servers, security will be the top priority as information are not to be stolen.

When the risk management is sorted out, the next process is to create a work breakdown structure of each task and where and who are they will be allocated to.

Requirement Analysis:

This is the most time-consuming stage of the project plan. This stage consists of analyzing all the possible requirements that are needed before continuing with the system and implementation.

It starts with defining the requirements which consists of three separate processes. They are defining the content requirements, evaluating intranets and the user requirements. This is then gone to the system requirements.

Acquiring all the requirements needed for the cloud based system to be able to work is the next process. With the specifics of the system sorted out, it will start to implement, code and insert all the necessary functionalities that Daisy is hoping for, for her company to be managed and maintained on.

These functionalities include the allowance of cross platforming to suit all types of electronic devices whether it be wireless or wired. Push notification functionality will allow live server updates on events. Geographic location for last known location of a user in the case of a natural disaster. And the last functionality is the use of different social media platforms for users to stream live events, post or tweet about a disaster to their families and friends. These functionalities are then tested and are then sent to the project manager to approve of the stability and functions of it.

System Design:

This stage of the project plan consists of the design of the system that the company and its users will be testing and using on. Modelling the UML is where all the information is to be put in place. Modelling a UML will provide a way of viewing and visualizing the essential design of the system.

After the UML model has been completed, the coders will then check for constraints such as user constraints and to see if there were errors that occurred during the making of the UML model.  The code is then written for multiple platform operating systems to satisfy the wide range of users.

Implementation:

Implementation is then initiated and the new system will be tested upon to check on the security levels and to see if there are errors that might occur when using the new system. Once the project manager has tested the new system and it is functional and stable, the manager will give an approval and the roll out and support of the new system will begin.

Roll Out and Support:

The roll out and support stage requires a lot of training and support for the employees this will be really timely and costly as there will be private lessons for the employees to train them to interact with the new system and adapt it with the current system as well. The employee training will take three weeks in total whilst the release of the internal PR will be out. This is then approved by the manager before execution of the next process. The project team will then determine what resources are needed for the support with staff changes being made and support stages being done.

The final process will require a review of the post implementation stage, how all the steps and processes were done to achieve the new system and whether it was a success or failure whilst listing all the risks that can possibly occur and evaluating all the features and functionalities integrated within the system.

End:

The ending stage is where all feedback is collected from its users and employees. The feedback received will be reviewed by the project manager. Once the project manager is satisfied with the feedback, a report and presentation will be prepared and delivered to the CEO.

Risk management plan

A risk management plan will be used to evaluate the potential risks that are associated with the new mobile disaster management system(MDMS) as there are many factors that are required to support the MDMS. The system requires tools and data sources to be utilized to perform the risk management plan. The people and roles that will factor in on the roles and responsibility for implementing a specific task that will inevitably be involved in the system. We need to consider how much the estimated costs and the schedule in performing these tasks as these will be important in determining the influence of the risk within the mobile disaster management system. The Risk categories will factor on the feature that is imposed in the system, also we need to take in account the probability and the impact that these systems will factor if the risks are potentially extremely hazardous to the system we need to make it a priority to make sure these risks do not conflict towards the system for customers and stakeholders alike. We need to make sure that the risks will not affect the reputation of the company as this can affect stakeholders to risk changes. For a risk to happen we must also administrate methods of tracking the risk and what methods or techniques need to be applied during auditing the risk. The last step that needs to be implied is the Risk Documentation which will be the reporting formats and processes that will be used to be used to solve and resolve issues within the MDMS.

Methodology

Methodology is essentially how the risk management will be performed in the project plan report on what tools and data sources will be available and applicable. There will be factors that will have external factors like the utility of using a cloud based and there will be internal factors like a lack of training within the project. For MQ IT solutions we will separate it into 6 separate sections where daisy has requested the features in the system to be implemented in the MDMS which are:

• Cloud based
• Support most wired, wireless and mobile services
• Support push functionalities
• Open source
• Incorporate information from social media such as twitter
• Easy to integrate with current systems

All these features pose risks that MQ IT solutions needs to assess and make sure we can properly identify the problem so that the MDMS with all the features can work properly for users. In addition to all these features that contain risks within them we also need to take in account common risks that are associated with creating IT projects which mainly include:

• Environmental risks
• Size risks
• Organizational and managerial risks
• Customer risk

For the following risks mainly associate with the project we will implement a two-step method that will be used:

1. Reflect on how the risks create or trigger the event. It is possible that the following could have several triggers that could inherit the same risk
2. Identify the risk and describe the nature of the risk and the impact it creates on the project

Once that has been addressed we will require to create a risk register which will be used to document all the information.  To gather this information, we require the input of a small group of people in each of the sectors to do a brainstorm session which will also include external stakeholders. This will then provide the data sources that we will need to resolve risk within the project life cycle.

Roles and responsibilities

The roles and duties that each member is associated must be assigned properly so that we know which risks will are involved in the process.  MQ IT solutions contains the following group of people in the organization:

• Director of MQ IT solutions
• Project manager
• Software experts
• Marketing guru
• Accountant
• Admin support

Director IT MQ IT solutions

The director focuses on the company as a whole and focuses on the major decisions involved in its operation. They are accountable for shareholders and require to form reports to our shareholders for future plans that will be addressed. They play a role in collectively directing the company’s affairs. In addition to a particularly fundamental part of being proactive amongst shareholders they must face challenge and issues with corporate governance, corporate social responsibility and corporate ethics. They role within risk management is to assess what stakeholders want out of MQ IT solutions and will have tolerance with the direction of the company.

Project manager

Project manager forms and organizes the teams and decides and assigns the overall project and what needs to be done within the time, cost and scope. They will be the development and the implementation of the risk management plan. Managers will require that risk are given grading which will be closely monitored. They will be also required to assess and identify risk and the developing strategies that are required in the phase of the project.

Software experts

Software experts will primarily be focused to identify risks or flaws that may be associated within the technical aspect of the MDMS. They will also continually monitor any risks that may occur in the future and refer them towards the risk register for documentation to support issues for MQ IT solutions if similar problems arise in the future.

Marketing guru

The marketing guru is required to deal with risk associated with the public face of the MDMS. They will responsible to identify, analysis and evaluate risks in towards the public and maintain and be responsible especially social media tools to make sure that users aren’t getting a negative perception of the MDMS.

Accountant

Accountant will need to be especially focused on maintaining transaction records and to analyse whether we are spending unnecessary items to make sure we meet with costs for the project. They are permitted to continuously monitor and keep constant record of our expenditure for the project to be successful.

Admin Support

Admin support primarily will deal with issues of day-to-day tasks and will need to have a high attention to detail on risks and issues involve from the system, from our users and will be responsible in assisting the project manager to gather the risks during the project life cycle.

Risk categories

Risk categories for MQ IT Solutions contain a wide array of different types and contain a lot of other resources that we require for the MDMS to work effectively. There are General, product-specific, people, size, process, technology, tools organizational, managerial, customer, estimation, sales and support risks.

• General risks are the threats that occur in every project. Some examples of these include losing key personnel, or bankruptcy of the software company. It is required that there MQ IT solutions should contain a list of these types of risks. The employees in the teams can then assess the extent to which these risks are a factor to the project based upon the known set of programmers, managers, customers, accountants and policies.
• Product-Specific risks are referred to the technology, people and the environment of the MDMS. An example of a product-specific risk is the availability of a complex cloud system that is required to be tested
• People risks involve the staff which factor in the availability, motivation, skills within the team
• Size risks generally affect the scale of the project as larger more complex items will be harder to manager. In addition to that large teams will also be significantly much harder to coordinate
• Process risks are referred to the team on whether they have the appropriate software development process and whether the team members follow the methods
• Technology risks involve the software and hardware technologies that are being used in the MDMS development that can include emerging technologies that can increase the overall risk
• Tool risks refer to the availability and the reliability of support software used by the software experts such as utilizing CASE tools
• Organizational and managerial risks are identified from the environment where the MDMS is being developed. Issues like financial stability of the company and the loss of support by management due to change in focus or a change in staff are example of risks
• Customer risks affect how customer requirements and customers lack of understanding to communicate effectively with the team and to convey the functions and tools used on the MDMS.
• Estimation risks affect the approximation of required resources and the time scope of the overall product.
• Sales and support risks affect the software experts and admin team where the product isn’t clearly understood to the admin team which make it difficult to sell the system to customers.

Risk probability and impact

Risks will be used to determine the identified risks that we have analysed in the risk categories. Once all the risks have been identified we will then use two units of measurement which will be probability and impact.  Probability will be a qualitative measurement which will be measured to see the likely occurrence when these risks are to occur. Impact is also a qualitative measurement that measures how much a negative impact it will do to the overall project.  Below is the table that will be used to address the risk probability with 1 being the least important and 10 most important priority to resolve.

		Impact
		low	low/medium	medium	medium/high	high
Probability	Low	1	2	3	4	5
	Medium	1.5	3	4.5	6	7.5
	High	2	4	6	8	10

Figure 1-1 risk Probability and impact table

Revised stakeholder’s tolerance

Stakeholders are required to communicate issues and risks within the development lifecycle. Communication is necessary for risk management to work effectively as the three stakeholders that need to communicate are software experts, managers and customers.

The software experts are required to continually assess and systematically to check for any technical related issues. The manager must give direction to the teams and make them involve on the risk management process. In addition to this the manager must be proactive in resources used in risk management. Customers will continually identify issues and risks on the system once it is developed. All these factors contribute to the stakeholder’s tolerance and we need to make sure that new risks and risk with higher impacts to the system will not damage the project. With each risk, there are going to be factors that will affect the stakeholder’s tolerance. If there are technical issues where the system has a high impact on stakeholders, they will not have good tolerance if problems like these do occur and need to make sure we identify these issues and resolve them effectively.

Tracking/Monitoring

Tracking and monitoring the risks occurs when risks have been clearly identified, analysed and prioritized it is essential that the company monitors the system and the resolution of the risk items by taking corrective actions. Risks need to be revisited at regular intervals especially the main features in the system that need to be placed and making sure that they don’t compromise the system. For instance, the cloud base is a feature that is needed to be put in place for the MDMS and we need to make sure that our storage and cost of the storage is constantly monitored to make sure we are being efficient with using the cloud based storage system. If the prevention techniques are being implemented there will be a significant amount of focus on monitoring these risks in the future of the system.

Risks tracking should be prioritized towards the risk probability and impact table which will be used to make sure these risks are assured and monitored weekly. If risks have less priority over the ones with more impact, we should monitor the issues monthly rather than weekly. A technique that would be a more effective way to document the risks is ‘Rank last month’ which will be useful as we can effectively monitor changes in priority of the risks, to determine if required actions are being taken that cause changes in the rank of the risk. Staff should be allocated to the correct issues and risks associated with in the system. For example, software experts should monitor risks within technical aspects of the business as they have the correct knowledge and skills to identify these much more effectively in comparison to the admin staff that may not have the required knowledge and clearly identify and prioritize the risks.

Documentation

Documentation of the risk management will consist of the risk register that will be necessary to collectively see the possible risks that will be associated when developing the system. The risk register will include the probability of the risk, the impact of the risk, time in which it takes to mitigate actions.

Future documentation will also include other data sources that will be used to support the risk register. For example, if the system hardware is using too many system resources for the mobile device we will require documentation of test bench results to solve a method to reduce the amount system resources that are being used.

Risk Register

The Risk	Methodology	Roles and responsibilities	Risk Categories	Risk probability and impact	Tracking	Documentation
1.Cloud based computing	Methods to assess risk management will involve ‘application performance of the cloud ‘. This technique involves a testing stage to assess performance. This is important as users access the system must meet high speed in accessing the data without major latency	The system will work on a third party where admin support will be associated with it to support the data that will be part of in house application and the cloud	Technology/tool Risk	8   As the increase concentration of data that is present makes it more attractive for hackers to try to use and manipulate the important details that will be sent out to our users.	A Watermarking solution could be implemented. This technique will allow information related to access and use to be added to any digital file. When users access the cloud services they normally use it with short sequences. A long and uninterrupted use of the service may signal data collection or archiving for the purpose of exporting. We require to have control of this behaviour within the system	Documentation will include the contacts that will support our cloud based system and the techniques that will be used to track the way the data is accessed to make sure no attackers attempt to bypass our MDMS
2.Economic denial of service (EDoS)	Methods to assess risk management will involve Checking previous accounts to make sure the MQ solutions isn’t paying extra for their cloud based services	This will be worked through the third-party cloud based computing company and additional admin support will be involved to resolve the issue of the attack. Also, accountants will be required in this risk to assess documentation and transactions	Tool risk	9   Critical this will affect the cost of the company in a great deal if a EDoS was to occur on the MDMS	The tracking method will involve checking accounts and transactions and tracing whether the previous bill or the amount that was intended to cost didn’t not doubled or even tripled in cost.	Documentation of previous months’ bill will be necessary to see the difference of cost of the cloud based system being utilised
3.  mobile operating system issues	Methods to assess this risk is to work in a testing environment where we test common Mobile OS to see if the push notifications work. We will also need to resolve the issue by patching the system.	Software experts will be required in this situation to see whether the push functionality work on the OS	Customer /Technology risk	6.5   Medium-high impact as if the push notifications do not work within the MDMS the software will be useless to utilize for the mobile systems	The method of tracking will be to give contact details on our web site where users can discuss their issues with the system so we can improve the overall quality and performance of the MDMS	Documentation will include the software design and limitations of how the software will work. Also, including user input through contacting us to work out and solve issues to resolve mobile operating system issues
4.Unreliable media sources through social media	The methodology to address is to filter out unnecessary sources of information so that the social media is consistent by using administrative access to monitor and control what sources are available to our users	Admin support will be associated in dealing with this issue as they need to check that we have reliable sources that can be used.	Tool risk	3   This is a relatively easy issue to solve and is more of a general newsfeed that we send to our users	Our social media systems will be monitored on the name of the sources we are getting access to	documentation will be the account information on the list of social media sources that we are using for our MDMS

Recommendations

Recommendations will help in assisting the project to give guidance on the tools and processes that can be used to make sure the project will be successful. Some recommendations for the MDMS will be focused on the features that are wanted to be implemented and other fields that are associated within the company.

Recommendation 1: Cloud based system

The cloud based system was an important aspect within managing cost as the pay per use price model that is used in Cloud computing could be beneficial for future expansion of data without the hassles of maintenance and purchasing hardware to store the information. However, there are issues of security risk that need to be carefully checked before engagement in this area. Cloud computing has grown enormously in recent years. The pay per use pricing model offers a relatively attractive alternative rather than supporting in house IT infrastructure (Brender & Markov, 2013). There are 2 choices for a cloud based system which are:  Amazon web services, Google Cloud platforms.

Amazon web services

Amazon Web services (AWS) is Cost effective as you pay for only the power, storage and other resources you use. With no long-term contracts or upfront costs.

Amazon web services also provide database migration service that offers nearly no down time. Any data changes on the cloud system to the database will be fully operational during the migration process.

In addition to all these benefits it also supports homogenous migration such as oracle to oracle databases or heterogeneous migration such as oracle to amazon Aurora enabling a great deal of support of different database storage options.

Google cloud platforms

• GCP is built for security and protection of your data from intrusion as the google data centers feature a layered security model, including safeguards like custom-designed electronic cards, alarms, vehicle access barriers, perimeter
• All services are maintained through an API gateway infrastructure
• Google has controls and practices to protect the security of customer information.
• Cloud disaster recovery tools that enable continuous replication of applications to the cloud thus providing a robust recovery solution.

Recommendation 2: Able to support most wired, wireless and mobile devices

The tool that needs to be integrated so that all devices work efficiently. For wired networks, Ethernet cables will link to the computer in order to collect the information. An app will be installed on the computer of the MDMS which will give constant updates of any disaster information that is about to occur.  For wireless devices, the mobile phone devices will most likely be connected to a 4G network or Wi-Fi. However, it is important to note that some mobile users will not always be connected through the network so it is imperative that they can contact us to have information accessed through them via a text. We recommend that we should have a website that will give resources for the users who don’t have access to the network so they are not left behind when a disaster happens. The data redundancy will not be an issue for the few users who can’t manage to have access to the network because it necessary that they get the information so they will be prepared from any disasters that will occur.

Recommendation 3: Support Push-functionalities

Support for push functionality is an important feature that needs to be properly integrated with all mobile devices. An important recommendation that should be placed is that we have to find a system that will enable the support push functionality to all different mobile operating systems. My recommendation is to use Google firebase cloud messaging as it supports many different systems making it a universal tool that can send the push notifications to our users. Some benefits of Google firebase Cloud Messaging include:

• Sends notifications messages to users.
• Versatile message targeting which can be useful for targeting specific locations upon disasters so messages do not become redundant to our users.
• Supports IOS, Android, Web, C++ and Unity setups making it useful to integrate a range of devices.

Recommendation 4: GPS Enabled Services

MQ IT Solutions is also recommending the implementation of the google maps API and into the mobile application. In the modern era, almost everyone carries a mobile phone around with them. This being the case, it gives the application the ability in GPS enabled devices to ensure all users are out of harm’s way when a disaster strikes. If they are not precautions can be taken, such as phone calls and physical searches. On the other hand, the feature could be used as a recovery tool. In the event of an earthquake which is common to the area, search and rescue crews would be able to track down victims in rubble in the aftermath of the event. This then gives the app the ability to helpful both before and after an incident.

Recommendation 5: Open source

Using an open source system will be used to assess the code and design of the overall project. We will require a tool that is intuitive enough that we can have control over the project management and community management. GitHub a open source that supports workflow with lightweight tools and features to our disposals which include:

• Code review
• Project management
• Integration
• Community Management
• Documentation
• Code hosting

Recommendation 6: Incorporate information from social media

The information must be reliable and concise for this feature to be particularly useful to our users. We will need to find the government site of the place that can link emergency alerts for each state. In addition, Twitter can incorporate twitter alerts which can notify users of incoming disasters though the various emergency accounts that we support. Facebook could also be used to implement information as they have a function called Facebook safety check which can be used to check if user’s friends and family are safe from the disaster.

Recommendation 7: Easy to integrate with current systems

In order to easily integrate with the current system, the best recommendation would include creating a desktop app, mobile app and text message. These three would be ideal to integrate the existing as it will be a single app install on each device.  The apps will then require the user to enter their details and provide info on their phone number, mobile number, email address etc. Once the app has been installed they will be able to receive push notification through all their devices as long as they are connected to a network.

Recommendation 8: Increased awareness

An ideal amount of awareness is necessary to gain the public trust in supporting the MDMS that we are being implemented. It is necessary to strengthen the users trust between loyal users and potential users. Giving and providing updated Details towards our users to keep them interested in our system.

Recommendation 9: Increased focus in social consideration to partners and public sectors

A Stronger commitment and communication between stakeholders in both private and public sectors is vital in providing better opportunities and a stronger user base. Therefore, it is necessary that we provide stakeholders social consideration of the MDMS so that they can contribute supporting our system.