EPA Android App - Admin Website Module Architecture







    The challenge is finished.
    Show Deadlinesicon-arrow-up

    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

    Welcome to third architecture in the series of four EPA Android App Architecture Contests. Each contest will run after the other and will be using the output of previous contest to build further. We recently concluded the development of the data management backbone for the system which will receive data from admin website. This contest will design the architecture of admin module of the system. We have a front-end prototype for admin module already in place and this contest will use that front-end to design the implementation of underlying features.

    In this contest, we are looking for you to design the module architecture for admin module system of EPA Android App. We want you to use all the available information architecture in form of system architecture and application requirements specification to develop this module architecture. We will also provide access to the admin website front-end that has been already developed and which will interact with this module. There is one update required to admin website which will be done as part of this module. . Finally, we will provide recently designed data management architecture and also the corresponding assembly code if required. The admin module is responsible for uploading all data to the system, provide configuration details to back-end and display results summary from the application to the admin - details of each function is provided later.

    enlightened Tips for Success:
    • Please discuss in forums and suggest new ideas if you think something here can be enhanced or made better. We welcome all ideas and suggestions.
    • Asking questions early and getting feedback is very important for the success of this competition.
    • Ask questions if you feel anything is confusing, or if you have any questions on the provided resources.


    Following is the description for each of functionality of admin module:

    EPA Android App Admin Module: This module will be responsible for doing all the admin operations. This module will not be computationally intensive but will require great i/o and network performance consciousness. Please note that upload performance is the key for this module. So, please make sure to include all possible optimizations so as to make this a very efficient module.

    - Please refer to Admin Use Case Diagram (page 12 in ARS) for all the use cases that needs to be implemented.

    - The admin module will upload the data and store it in temporary folder. The data management module will use this data from temporary folder.

    - The admin module will also interact with the back-end for sending configuration details.

    - The admin module will receive prediction results and aggregate analysis results and it will be displayed in the front-end.

    - We will provide you the back-end architecture (currently in review process) to provide an idea of what kind of data will be received by admin related for prediction and aggregate analysis and how it needs to be displayed. Please ask as many questions as you need for getting clear idea on this.

    - Please read carefully: There is one feature which is not available in current front-end prototype. Please refer to 2.33.1 Upload Image(s) Activity > Provide URL for bulk upload. This needs to be implemented as part of this module. The front-end will have a new text box as an option to current upload function. The admin can enter a url into this box and once the admin hits upload, the admin module will just send the url to data management module. The data management module will then fetch the data from the url.  We want you to once look at data management architecture/assembly to see that this fetch from url function is properly implemented and can be synced with the current feature in admin module.

    3. Technology Overview

    1. The Admin Website prototype is a CMS developed using Django framework 1.6.1, Python 2.7x and PIL 1.1.7.

    2. We are open to use of any technology for the admin module as far as it does not limit any specific OS requirements. To match with prototype, you can use python but keep upload performance in mind. Other modules for this system are developed in Java. So, you are free to use Java also.

    3. We plan to host the admin module along with the data management module on a single (same) server - ex. Amazon EC2 Server.

    4. Open source software resources are welcome, but they must have third party support services available. Please ask in forum when in doubt.

    5.  You are allowed to use any open source DB, data storage mechanisms for storing data at various stages.

    6. Please note that the developers are not allowed to use any component from TC Catalog for this contest.

     4. Process Flow and Storage Considerations

    - We will use two main storage modules: Temp Storage and Shared Storage.

    - The admin website will put all new data in Temp store.

    - The data management module will read data from this temp store and then process it. After processing completes, it moves the original data to shared store (this is not part of this module, it is already done by DMM.)

    - In case admin provides url, the data management module will fetch data and put it in temp store.

    Please Note: Both the process flow and storage details are just high-level suggestion from our side. Architects are welcome and encouraged to suggest and propose any changes and updates as deemed necessary in this process flow. Also, architects are allowed to use any media for data storage like DB or files, etc. Please open a discussion in forum to clarify/confirm your ideas when in doubt.

    5. Resources Provided

    The following resources are available for your use. You will be able to access some of them on forums after registration while others require discussion forum request for access:

    1.) EPA Admin Website Prototype

    2.) System Design Specification

    3.) System Architecture TCUML

    4.) Application Requirements Specification and Use Case TCUML

    5.) Data Management Module Architecture

    6.) Data Management Module Assembly

    7.) Back-end Module Architecture

    Please Note: In case of use case discrepancies, precedence should be considered as following:  Data Management Architecture and Assembly and Back-end Architecture > ARS > System Architecture. Please follow them and if there is still confusion, please ask in forums.

    Final Submission Guidelines

    We want you to submit the following deliverables:

    • Application Design Specification
    • Sequence Diagrams
    • Interface Diagrams
    • ER Diagram
    • Assembly Specifications
    • Requirements Implementation Mapping

    You can refer here to know more description on the templates and other details related to above mentioned required documents.

    Please Note: For Section 508 compliance, this contest must follow the accessibility rules provided here:  http://developer.android.com/guide/topics/ui/accessibility/index.html

    Reliability Rating and Bonus

    For challenges that have a reliability bonus, the bonus depends on the reliability rating at the moment of registration for that project. A participant with no previous projects is considered to have no reliability rating, and therefore gets no bonus. Reliability bonus does not apply to Digital Run winnings. Since reliability rating is based on the past 15 projects, it can only have 15 discrete values.
    Read more.


    2014 TopCoder(R) Open


    Final Review:

    Community Review Board


    User Sign-Off