greenbay.usc.edu · Web viewLife Cycle Plan (LCP) GEOCODE DATA READER. TEAM 10. Anamarie. Ha Software Architect / UML Modeler. Ashi. Ranka. Feasibility Analyst / Prototyper. Damini

Life Cycle Plan (LCP)

GEOCODE DATA READER

TEAM 10

Anamarie Ha Software Architect / UML Modeler Ashi Ranka Feasibility Analyst / Prototyper Damini Cousik Implementer / Quality Focal Point Karthik Kenkere Software Architect / Implementer Pawandeep Gill Requirements Engineer / Prototyper Sriramkumar Thamizharasan Implementer / Project Manager Suchetha I Bhat Project Manager / Operational Concept Engineer Vidhubala Selvaraj Life Cycle Planner / Tester

10/23/2020

Life Cycle Plan (LCP) Version 3.0

Version History

Date Author Version

Changes made Rationale

10/10/20 VS 1.0 Outlined all basic features v1.0

Initial draft for peer review

10/14/20 VS 2.0 Estimated COCOMO II Model

Analyzed COCOMO II Output

10/23/20 VS 3.0 Updated Development Phase Table (Table 7)

Schedule detailed in Lecture.

document.docx ii Version Date: 10/23/20


Table of Contents

Life Cycle Plan (LCP)....................................................................................................................iVersion History..............................................................................................................................iiTable of Contents..........................................................................................................................iiiTable of Tables..............................................................................................................................ivTable of Figures.............................................................................................................................1

1. Introduction.....................................................................................................................2

1.1 Purpose of the LCP.........................................................................................................2

1.2 Status of the LCP............................................................................................................2

1.3 Assumptions.....................................................................................................................2

2. Milestones and Products.................................................................................................3

2.1 Overall Strategy..............................................................................................................3

2.2 Project Deliverables........................................................................................................4

3. Responsibilities................................................................................................................9

3.1 Project-specific stakeholder’s responsibilities..............................................................9

3.2 Responsibilities by Phase................................................................................................9

3.3 Skills...............................................................................................................................12

4. Approach........................................................................................................................13

4.1 Monitoring and Control...............................................................................................13

4.2 Methods, Tools and Facilities.......................................................................................14

5. Resources.......................................................................................................................16

6. Iteration Plan...........................................................................................................................23

6.1 Plan......................................................................................................................................25

6.1.1 Capabilities implemented...............................................................................................25

document.docx iii Version Date: 10/23/20


Table of Tables

Table 1: Project Milestones............................................................................................................4Table 2: Artifact deliverable in Exploration Phase........................................................................4Table 3: Artifact deliverable in Valuation Phase............................................................................5Table 4: Artifact deliverable in Foundations Phase.......................................................................6Table 5: Artifact deliverable in Development Phase......................................................................7Table 6: Artifact deliverable in Operation Phase...........................................................................7Table 7: Stakeholder and Responsibilities......................................................................................9Table 8: Project Manager Responsibilities in each Phase.............................................................9Table 9: Life Cycle Planner Responsibilities in each Phase.........................................................10Table 10: Software Architect Responsibilities in each Phase.......................................................11Table 11: Feasibility Analyst Responsibilities in each Phase.......................................................11Table 12: Client Responsibilities in each Phase...........................................................................11Table 13: Team Member’s Skills...................................................................................................12Table 14: Tools used in the Project...............................................................................................15Table 15: Rationale for Project Scale Factors.............................................................................16Table 16: Rationale for Project Cost Factors – Module_1...........................................................17Table 17: Rationale for Project Cost Factors – Module_2...........................................................18Table 18: Rationale for Project Cost Factors – Module_3...........................................................19Table 19: Rationale for Project Cost Factors – Module_4...........................................................21Table 20: Rationale for Project Cost Factors – Module_5...........................................................22Table 21: Construction Iteration Capabilities Implemented........................................................25

document.docx iv Version Date: 10/23/20


Table of Figures

Table 1: COCOMO II ESTIMATION

document.docx 1 Version Date: 10/23/20


1. Introduction

1.1 Purpose of the LCP

The purpose of the Life Cycle Plan (LCP) of the Geocode Data Reader is to plan, monitor and track the progress of the project in order to augment the productivity and resources throughout the system’s life cycle for development and maintenance.

1.2 Status of the LCP

The status of the LCP is currently at the version number 1.0. This is the basic version filled with all the basic requirements and tools to be used in this project.

1.3 Assumptions

The following are the list of assumptions made for this project:

This is a one-semester project and the duration of the project is 12 weeks in Fall 2020. Each of the team members are obliged to follow the project schedule. The core capabilities of the project are:

Provide a dynamic interface to lookup for geocode of institutions by countries and continents.

Create a way for consumers to report changes and additions to data. Provide multiple options for data download format. Provide privilege to only super_admins to delete or add the suggested data to the

database. Provide a retrieve_table to revert any changes done in the last 30 days. Provide end-users the ability to use their native language to search or suggest any

edit. The data will be translated using Google Translate API.

All project artifacts must follow the ICM – s/w guidelines.



2. Milestones and Products

2.1 Overall Strategy

The overall strategy of the project is organized through the Schedule as Independent Variable Strategy (SAIV) as the whole project’s duration should fit within the class schedule. This project involves prioritization of desired features; core capabilities of top priority features easily achievable within the available schedule.In the first increment, the team will develop the essential and must-have capabilities and in the upcoming increment, the team plans to collaborate the lower-priority features and focus more on data visualization aspects of the project. The schedule for this project is 12 weeks for Fall 2020 (CSCI 577a).

The process model implemented in this project is the Incremental Commitment Spiral Model (ICSM).The ICSM process that the GEOCODE Data Reader project follows is based on Net-Centric Services.

The process model includes the following key milestones: Valuation Commitment Review (VCR) Foundations Commitment Review (FCR) Development Commitment Review (DCR) Core – Capability Drive-through (CCD) Transition Readiness Review (TRR) Operation Commitment Review (OCR)

The development span can be categorized as follows:

Exploration, Valuation and Foundations phasesDuration: August 24’ 2020 – October 16’ 2020Concept: They identify project operational concept, system and software requirement, system and software architecture, and life-cycle plan. These phases prioritize the capabilities, conduct investment and feasibility analysis, and implement the software prototype.

o Exploration phaseDeliverables: Client Interaction ReportMilestone: Valuation Commitment ReviewStrategy: One Incremental Commitment Cycle

o Valuation phaseDeliverables: Win-Win Conditions Report, Initial Prototype PresentationMilestone: Foundations Commitment ReviewStrategy: At least one Incremental Commitment Cycle

o Foundations phaseDeliverables: ARB: OCD, LCP, FED, Architecture



Milestone: Development Commitment Review Strategy: At least one Incremental Commitment Cycle

Development phaseDuration: October 16’ 2020 – November 24’ 2020Concept: There are three increments in the Development phase. All core capabilities are developed in the first increment and deployed in the second increment, while the lower priority capabilities will be developed in the second increment. Furthermore, the development team has to prepare for transitioning, testing, and installing the system. In the operation phase, the development team delivers the system and ensures the quality of work product.

o Development phase – Construction Phase 1Deliverables: DCP – ARB: OCD, LCP, FED, Transition Plan, CCD ReportEnding Milestone: Core Capability Drive-through Strategy: One Incremental Commitment Cycle

o Development phase - Construction Phase 2Deliverables: TP, SP, ATPR, UMMilestone: Transition Readiness ReviewStrategy: One Incremental Commitment Cycle

o Transition IncrementDeliverables: Final Deliverables, Project ReleaseMilestone: Close Out ReportStrategy: One Incremental Commitment Cycle

2.2 Project Deliverables

The following is the list of major milestones of the project.

Table 1: Project Milestones

Milestone DateValuation Commitment Review 09/25/2020Foundation Commitment Review 10/12/2020Development Commitment Review 10/16/2020Core Capability Drive through 11/06/2020Transition Readiness Review 11/16/2020Operation Commitment Review 11/18/2007Project Release 11/20/2020

2.2.1 Exploration Phase

Table 2: Artifact Deliverables in Exploration Phase

Artifact Due date Format Medium



Client Interaction Report 09/14/2020 .doc, .pdf Soft copyValuation Commitment Package Operational Concept Description

(OCD) Early Section Life Cycle Plan (LCP) Early

Section Feasibility Evidence Description

(FED) Early Section

09/16/2020 .doc, .pdf Soft copy

Evaluation of Valuation Commitment Package

09/18/2020 .pdf Soft copy

Project Plan Friday .mpp, .pdf Soft copyProgress Report Friday .xls Soft copyRisk Analysis Friday Text DART system

2.2.2 Valuation Phase

Table 2: Artifact deliverable in Valuation Phase

Artifact Due date Format MediumInitial Prototype 09/20/2020 .doc, .pdf Soft copyWin-Win Report 09/23/2020 .doc, .pdf Soft copyEvaluation of Initial Prototype 09/25/2020 .xls Soft copyFoundations Commitment Package Operational Concept Description System and Software

Requirements Definition System and Software

Architecture Description UML Model Life Cycle Plan Feasibility Evidence Description Supporting Information

Document

10/12/2020 .doc, .pdf, .zip

Soft copy

Evaluation of Foundations Commitment Package

10/16/2020 .pdf Soft copy

Project Plan Friday .mpp, .pdf Soft copyProgress Report Friday .xls Soft copyRisk Analysis Friday Text DART systemClient’s Meeting Notes After the meeting .doc, .pdf Soft copy



2.2.3 Foundations Phase

Table 3: Artifact deliverable in Foundations Phase

Artifact Due date Format MediumUpdated Win-Win Report 11/08/2020 .doc, .pdf Soft copyDraft Development Commitment Package Operational Concept Description System and Software



Document

11/16/2020 .doc, .pdf, .zip

Soft copy

Evaluation of Draft Development Commitment Package

11/18/2020 .xls Soft copy

Development Commitment Package Operational Concept Description System and Software



Document

11/18/2020 .doc, .pdf, .zip

Soft copy

Response to Draft Development Commitment Package Evaluation

11/20/2020 .doc, .xls Soft copy

Evaluation of Development Commitment Package

11/20/2020 .xls Soft copy




2.2.4 Development Phase

Table 4: Artifact deliverable in Development Phase

Artifact Due date Format MediumDeveloper Preparation CCD Preparation

11/06/2020 .ppt, .pdf Soft copy

Core Capability Drive-through Report


IOC Working Set #1 Quality Management Plan Iteration Plan Acceptance Test Plan and Cases Peer Review Plan Transition Preparation Plan



2.2.4.1 Development Phase - Transition Iteration

Table 6: Artifact Deliverables in Operation Phase

Artifact Due date Format MediumTransition Package Transition Plan User Manual Support Plan Training Material Regression Test Package Packaged Tools and Procedure


Operations Commitment Package Operational Concept Description System and Software



Document

11/23/2030 .doc, .pdf, .zip

Soft copy



Product Archiving Source Code Files Executable Components Release Description

11/24/2020 .doc, .pdf, .zip

Soft copy



3. Responsibilities

3.1 Project-specific stakeholder’s responsibilities

The sub-team helps to identify and collaborate the points put forward by the client and maintain a separate document for pending tasks and a to-do list.

The sub-team helps to perform the following tasks: Co-ordinate with client to enlist the software technologies to be used. Organize weekly meeting with client and all team members to monitor the progress. Perform integration testing. Provide feedback.

3.2 Responsibilities by Phase

The following mentioned are team members and their responsibilities:

Table 7: Stakeholder and Responsibilities

Names Responsibilities

Anamarie Ha Software Architect / UML ModelerAshi Ranka Feasibility Analyst / PrototyperDamini Shiv Cousik Implementer / Quality Focal PointKarthik Kenkere Sreedharamurthy Software Architect / ImplementerPawandeep Singh Gill Requirements Engineer / PrototyperSriramkumar Thamizharasan Project Manager / ImplementerSuchetha I Bhat Operational Concept Engineer / Project ManagerVidhubala Selvaraj Life Cycle Planner / Tester

Table 8: Project Manager's responsibilities in each phase

Stakeholder/Role Suchetha I Bhat: Project ManagerExploration Primary Responsibility

Coordinate with clients Prepare for site visit

Secondary Responsibility Analyze current workflow

Valuation Primary Responsibility Manage project Coordinate with all stakeholders Analyze project investment

Secondary Responsibility Review artifacts Plan for configuration

managementFoundations Primary Responsibility

Manage projectSecondary Responsibility Review artifacts



Coordinate with all stakeholders Plan for testing Perform configuration management

Development- Development Increments

Primary Responsibility Manage project Coordinate with all stakeholders Plan for project transition, and support

Secondary Responsibility Maintain configuration

management

Development-Transition Increment

Primary Responsibility Manage project Coordinate with all stakeholders Perform final test

Secondary Responsibility Provide training

Table 9: Life Cycle Planner's responsibilities in each phase

Stakeholder/Role

Vidhubala Selvaraj: Life Cycle Planner/ Quality Assurance

Exploration Primary Responsibility Analyze current business workflow Analyze related artifacts Draft project plan

Secondary Responsibility Coordinate with clients and

team members

Valuation Primary Responsibility Generate project plan and estimate

cost Assure high quality of the project Review project artifacts

Secondary Responsibility Coordinate with team

members

Foundations Primary Responsibility Coordinate with Developer Team Update project plan and cost

estimation Assure high quality of the project Review project artifacts

Secondary Responsibility Plan for testing Coordinate with team

members


Primary Responsibility Coordinate with Developer Team Perform integration test Review project artifacts Prepare for project transition and

support

Secondary Responsibility Prepare for training


Primary Responsibility Coordinate with Developer Team Finalize all project documents

Secondary Responsibility Provide initial support

Table 10: Software Architect’s responsibilities in each phase

Stakeholder/ Anamarie Ha: Software Architect



RoleExploration Primary Responsibility

Analyze current system and its environment

Secondary Responsibility Analyze possible software and

6hardware usedValuation Primary Responsibility

Develop prototype Design Foundations framework

Secondary Responsibility Analyze all possible COTS

Foundations Primary Responsibility Define system architecture Revise prototype Generate UML models

Secondary Responsibility Inspection, OCD


Primary Responsibility Develop software modules Integrate software modules

Secondary Responsibility Perform unit tests


Primary Responsibility Perform final test Provide initial support

Secondary Responsibility Prepare operational

environment

Table 11: Feasibility Analyst's responsibilities in each phase

Stakeholder/Role

Ashi Ranka: Feasibility Analyst

Exploration Primary Responsibility Identify project feasibility and risk

Secondary Responsibility Analyze possible software and

hardware usedValuation Primary Responsibility

Define operational concepts Analyze investment analysis

Secondary Responsibility Analyze all possible COTS

Foundations Primary Responsibility Maintain consistencies between win

conditions, requirements, and system architecture

Prepare test cases

Secondary Responsibility Verify prototype

Table 12: Client's responsibilities in each phase

Stakeholder/Role

W Mathew Bemis: Client

Exploration Primary Responsibility Prepare for site visit Express interests on the project

Secondary Responsibility Show current workflow

Valuation Primary Responsibility Provide support and collaboration

Secondary Responsibility Provide feedback to development



to the development team Express win conditions Approve and commit to the

selected project technologies

team

Foundations Primary Responsibility Provide support and collaboration

to the development team Approve and commit to the

selected project progress

Secondary Responsibility Provide supporting data Provide feedback about prototype


Primary Responsibility Provide support and collaboration

to the development team Approve and commit to the

project development

Secondary Responsibility Provide necessary support Provide feedback about

developed modules


Primary Responsibility Provide feedback about

developed modules Get trained

Secondary Responsibility Prepare for training to others

3.3 Skills

The current and required skills for each role in CSCI 577a are:

Table 13: Team members skills

Team members Role SkillsSuchetha I Bhat, Project Manager /

Operational Concept Engineer

Project management, problem solving, negotiation.

Vidhubala Selvaraj Life cycle planner / QA Project coordination, Quality Management, COCOMO

Anamarie Ha System Architect UML, OOADDamini Shiv Cousik,Sriramkumar Thamizharasan,Karthik K Sreedharamurthy,

Implementer Programming, Testing, AWS Amplify,AWS Cognito, DynamoDB

Ashi Ranka Feasibility Analyst WinWin, Financial analysisPawandeep Singh Gill Prototyper UX, Critical thinking



4. Approach

4.1 Monitoring and Control

The purpose of monitoring and control for Geocode Data Reader is to ensure the appropriate quality of software also in the future. Every team member is responsible for the quality of the product when it meets the deliverable date and milestones. The strategies for monitoring and control used in this project are the following:

1. Weekly Client Meeting Report This report informs all stakeholders about this content of each meeting. They can

track and open issues and other concerns from last meeting and prepare themselves for upcoming tasks and responsibilities.

2. Weekly Progress Report – Bi-Weekly ReportThis allows stakeholder to keep track of the status of the project and thus

determine efficiency of the team contribution to the project.3. Weekly Effort Report

Weekly effort by individual is shown in number of hours. This can determine whether every team member has balance workload or not.

4. Project schedule ManagementMicrosoft Teams is used to determine tasks and responsibilities for each member.

This helps monitor and control project plan and make everyone aware of upcoming dateline and critical issues.

5. Risk management and mitigationRisk is identified and prioritized. It can be used toward risk mitigation and

prevention. Therefore, it helps the project from making major changes, which effects in the increase of project schedule and effort.

6. Software Cost Estimation (USC COCOMO tool) Estimated schedule and effort is calculated for the completion of the project.

7. Regular Team meeting After classes, developers hold short meetings to discuss plans, issues, and status

of the project.

4.1.1 Closed Loop Feedback Control

Closed-loop feedback control involves monitoring progress and resource expenditures in planning, which are achieved through the Weekly Client Meeting, Progress report, and Trello report. If problem occurs, the team can plan and reschedule to resolve them shortly. In addition, it assesses the balancing of the workload for each team member. Team members meet frequently after class to distribute work and settle any uprising issues.



4.1.2 Reviews

There are many kinds of review conducted in the project life cycle. Reviews determine the maturity of the artifacts and readiness to continue to the next phase.

1. Review Board – At the end of each phase, the review board meeting is held to determine the readiness and commitment level of the project. Required participants are all critical stakeholders. There are four Architecture Review Boards (ARB) as follows:

a. Valuation Commitment Reviewb. Foundation Commitment Reviewc. Development Commitment Reviewd. Transition Readiness Reviewe. Close Out Report

2. Core Capability Drive-through (CCD) – Towards the end of the development phase, the development team presents the project’s core capabilities to the client. The client will conduct hands-on review and testing of the system.

3. Configuration Management – This ensures completeness and conformance among artifacts, as well as source code, for each dateline. Developers are able to trace back to the previous-versions artifacts, which allows them to have the ability to analyze and manage current version artifacts with better consistency. This is at the same time as the Fagan’s inspection. Subversion is used in this project to build a version control system.

4. Peer Review – Team members will help each other to check the correctness, completeness, and consistency of all project artifacts.

4.1.3 Project plan

The team produces weekly progress reports, which identifies all the tasks in progress, the problems have occurred, and the risk items associated with each task. Reports also include plans to minimize or avoid issues, problem reports, and defects. Weekly individual reports summarize the details of hours of work by individuals in specific areas of project. In addition, in the beginning of each weekly client meeting, all attendees must confirm for approval of previous client meeting report to show that they are aware of the current status and progress of the project.

4.2 Methods, Tools and Facilities

The following table shows the methods, tools, and facilities that will be used in the project in preparing and operating the project facilities.



Table 14: Tools Being Used in the Project

Tools Usage ProviderMicrosoft Word Constructs documents for all artifacts. Open SourceMicrosoft Project Plan Maintains track of members responsibilities and

tasks.Open Source

Microsoft PowerPoint Creates presentation for client meeting and ARB reviews

Open Source

Google Chrome Downloads course material and medium for communication among stakeholders

USC

Google Sheets Facilitates and supports Win-Win negotiation TeamVisual Paradigm Creates UML, sequence diagram, and other

diagrams for SSADOpen Source

USC Greenbay Hosted team website; involved in the creation of the system using HTML and CSS.

Developer

Adobe Acrobat 6.0 Used for documentation dissemination DeveloperTrello Board Keeps track of project effort USCAWS Amplify, AWS Cognito

Is a web application framework for the projects Open source

AWS Lambda Is an open development platform Open sourceDynamo DB To maintain the records in the database. Open source

Node.js Javascript Framework for backend. Open SourceZoom Platform to attend Meetings and Presentations. USC



5. ResourcesThis section describes the result of using COCOMO II tool to estimate cost for the project development in terms of effort and schedule. Since we are using SAIV, the estimates will tell us the effort required for the given project specification.

Estimated 577a Effort: Eight team members at 14 hrs/week for 12 weeks

Total estimated Effort: 1344 hours

The following are conditions applied for estimating the cost of the Geocode Data Reader:

1. Project schedule is 12 weeks for Fall 2020 in 577a.2. Zero monetary budget for a year. 3. There are eight team members in 577a.4. There are five modules in the project:

Search Module – Search the institution name and it’s geocode. Suggest/ Edit Module – User is able to suggest an edit to the data. Export Module – User is able to export the data by downloading as CSV/JSON. Admin Module – Admin liberty to add/ delete data from directory. Data Visualization Module – Access to visualize data through amcharts.

5. Most modules use JavaScript, HTML5, CSS3 language.

Table 15: Rationale for Project Scale Factors

SCALE DRIVER

VALUE RATIONALE

PREC NOMINAL The development team is somewhat unprecedented in experience with AWS Lambda; should learn in depth about this new technology.

FLEX NOMINAL As per client’s specifications, there is some relaxation in terms of constraints put forward by the client

RESL HIGH There are no major risks identified and risks previously discussed are mitigated with the help of prototyping.

TEAM VERY HIGH

All team members meet up on regular basis through Zoom/ WhatsApp/Email.

PMAT NOMINAL The development team follows ICM guidelines, which is CMM level 3 maturity level.



5.1 Module_1: SEARCH MODULE

Table 16: Rationale for Project Cost Factors

COST DRIVER

VALUE RATIONALE

RELY NOMINAL Any data loss can be recovered as AWS provides required resources for data recovery.

DATA LOW The DP ratio is around 50.

CPLX NOMINAL

This module contains simple widget, simple input output process and simple structural changes.

RUSE NOMINAL This module is intended to be reused in the project.

DOCU NOMINAL It is right-sized to life cycle needs,

TIME NOMINAL The percentage of available execution time, expected to be used by the system is 50%, system will be actively in use when searching an institution or when records are to be appended to the directory.

STOR NOMINAL This module does not require large amount of storage at execution time.

PVOL LOW The major change of the platform could happen every 12 months.

ACAP HIGH The analysts work and analyses design and requirements; communicate and cooperate very well.

PCAP HIGH Programmers are capable and efficient. They are able to communicate and cooperate very well.

PCON VERY LOW

This is a one semester project and hence, no members will participate in 577b.

APEX NOMINAL Familiarity with Database end implementation but not much knowledge in the AWS platform.

LTEX HIGH The programmers are well-versed in JavaScript, HTML and CSS.



TOOL NOMINAL The tools are moderately integrated and provide various functionalities.

SITE HIGH Seven of eight team members all live in the same vicinity.

SCED NOMINAL The schedule is fixed for 12 weeks in Fall.

5.2 Module_2: SUGGEST/EDIT MODULE


COST DRIVER

VALUE RATIONALE



CPLX NOMINAL











PCON VERY LOW







5.3 Module_3: EXPORT MODULE


COST DRIVER

VALUE RATIONALE



CPLX NOMINAL











PCON VERY LOW







5.4 Module_4: ADMIN MODULE


COST DRIVER

VALUE RATIONALE





CPLX NOMINAL









PCON VERY LOW







5.5 Module_5: DATA VISUALIZATION MODULE




COST DRIVER

VALUE RATIONALE



CPLX NOMINAL









PCON VERY LOW




TOOL NOMINAL The tools are moderately integrated and provide various



functionalities.



5.6 COCOMO II ESTIMATION

Estimated Code Size:

Total Lines of Code = 2338.

Time required = 152 hours/month. Effort = 6.1 person-months. Schedule = 6.5 months. Per Person Effort = 14 hours/week. (8 members) x (14 hours/week) x (4 weeks) = 448 hours/month.

Hence, an eight-member team can finish the project in 3 months.



6. Iteration Plan

6.1 Plan

Currently, there are two main phases for the Geocode Data Reader project; the project is presently headed into Phase-2. The project is yet to achieve the Transition Readiness Review (TRR).

6.1.1 Capabilities implemented

For the milestone identified above (DCR), the team has planned to cover the basic and most prioritized functionalities of the project.

The second phase of the project will largely focus on the data visualization of the project, thereby providing features for a more convenient access of the Geocode Data Reader for the end-users.



Table 21: Construction iteration capabilities implemented

ID Capability Description Priority Iteration1. Search

FeatureTo search geocode of institutions. 1 1

2. Filter Search Able to filter search through country name; sort the results as required.

2 1

3. Export Feature

Able to export the results either as JSON/CSV.

2 1

4. Suggest Feature

End-users are allowed to suggest changes to the data.

2 1

5. Admin Privileges

Admin is allowed to view, edit and/or delete data.

1 1


Documents

greenbay.usc.edu · Web viewLife Cycle Plan (LCP) GEOCODE DATA READER. TEAM 10. Anamarie. Ha Software Architect / UML Modeler. Ashi. Ranka. Feasibility Analyst / Prototyper. Damini