EPA Android App Module Architectures Sync Challenge

Key Information

Register
Submit
Status: ‌Cancelled zero submissions

Challenge Overview

1. Project Overview

The EPA is a U.S. federal government agency devoted to safeguarding the environment. One of the EPA's great concerns is the proliferation of cyanobacterial harmful blooms (cyanoHABs) in the nation's lakes. The following resources provide information on what cyanoHABs are and how they threaten the environment.

The TopCoder project on cyanoHABs aims to develop an algorithm that will be deployed in an Android app with mapping and data visualization capabilities. The app will inform local and federal policy makers about locations where bloom events are likely to occur, allowing them to concentrate their efforts in those areas.

2. Contest Overview

- This is a private task to update all the architecture modules of EPA Android App.

- The system has four different modules:

1. Admin Website Module

2. Data Management Module

3. Back-End Module

4. Front-End Module

- The architecture contests for all these four modules are complete and we have also completed the assembly for admin website and data management module.

- The architect and developer of each of these modules and assemblies respectively have suggested/recommended certain updates to the other modules and provided a list of updates that they feel should be done in other modules to support their own module.

Your task in this contest is to take all four architectures and study them. After that, look at the list of updates provided by various members (architects and developers other than you). Using that list, update all the modules as required. Please still keep all module separate and make a submission of 4 different architectures just as they are attached in forums. You can put all 4 architectures in single zip file.

We want update only to architecture design. In short, we want you to sync all the architectures so that they are compatible to each other. Please use suggested updates just as recommendations and not hard and fast requirements. Please use your best judgment to discard any of those updates or to add new updates.

Please clarify in forums as soon as you have some confusion. We will be on our toes to answer all yoru questions promptly.

Resources:

- We will provide you following resources in forums:

1.) System Architecture and tcuml

2.) ARS and its UML

3.) All four architectures (update list attached with each of them)

4.) Two assemblies (you do not need to do anything with these assemblies but you need to use the update list that accompany these assemblies. Basically, these are the updates required in design of other modules to make them compatible to the assembly already developed.)

5.) Prediction Algorithm

Please try to see that there is minimum change required for admin website and data management module as their assembly is already complete so lesser fixes in them will save time for us. Having said that, please suggest whatever you think is necessary and we will update it.

In addition to above task, we need you to add/confirm few small things:

1.) The data management module should have capability to fetch data from URL in case the admin just provides URL and not the actual data. I believe this was already covered by you in earlier architecture and also implemented in the assembly but wanted to confirm.

2.) IMPORTANT!!!: We want to add an ON/OFF  feature which will be a system wide feature and the feature will be provided to admins. This is a toggle feature which will decide whether the rpedictive facility inthe app will be available to the users or not. Here is the suggested flow of this feature: The admin has a setting which says something like "Turn On Predictive Capability" and "Turn Off Predictive Capability" as per the case. When the admin chooses to trun off this facility, a message or dtaa packet will be send ot back-end with this update. The back-end will then de-avtivate the precditive feature from front-end i.e. the Predcition tab in the front-end of the app will be disabled. Our only aim is to not allow users of the app to see the prediction part. By this, we do not want to stop the system from using the algo that is available in back-end. It will just not show to the front-end app user. Please ask in forum if there is any confusion about this.

3.) The prediction is algo is available now and we will provide it in forum. You will be required to embed it into back-end.

4.) Here is how the system is going to be hosted physically. There are two servers with EPA - back-end and front-end.

From software perspective, our admin module, data management module and back-end will reside on their physical back-end server.

Our front-end software module will be on the user's app. As you can see, nothing is hosted on EPA's physical front-end server. This is where they wil have a proxy message passing server. Thus, mobile front-end will communicate with this proxy server which in turn wil communicate with the back-end server which hosts all our modules. This is for security reasons and so can please add this consideration of communiating with proxy server in relevant architecures?

5.) There is one front-end requirement which was not fulfilled in its dedicated contest - it is a very small requirement and you are required to add that in front-end. Following is the requirement:

In ARS it is, 2.23: View Aggregate Analysis screen



Final Submission Guidelines

NA

REVIEW STYLE:

Final Review:

Community Review Board

Approval:

User Sign-Off

SHARE:

ID: 30045985