1 / 33

(Java Web Enabled Access to Metadata)

This project aims to develop a web-based system for accessing and analyzing Synthetic Aperture Radar (SAR) metadata, improving data storage, retrieval, and platform independence. Unique solution due to data security and emerging technology.

cethel
Download Presentation

(Java Web Enabled Access to Metadata)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. (Java Web Enabled Access to Metadata)

  2. Team Members and Roles • William Busby: Team Leader, webmaster • Lindsey Gray: Communicator • David Meffe: Recorder Lindsey Gray

  3. Sponsor Information • Lockheed Martin • Reconnaissance Systems • Bill Rawlings and Marvin Kliene • Litchfield Park, AZ Lindsey Gray

  4. Main Points • Project Description • Problem Statement • Requirements • Development Paradigm • Design • Risks • Resources • Schedule Lindsey Gray

  5. Problem Statement: Background/History • Synthetic Aperture Radar (SAR) Metadata imagery used in reprocessing and post-processing procedures and analysis • Used by U.S. and allies for: • fixed target imaging (FTI) • moving target indications (MTI) • automatic target recognition (ATR) • battle damage assessment (BDA) Lindsey Gray

  6. Project Description • Retrieval and display of XML formatted SAR metadata in intranet environment • SAR metadata and imagery stored in a relational database • XML tags for metadata • Style sheets to display metadata • Web-based retrieval and display Lindsey Gray

  7. Problem Statement:Business Issues • need for web-based access and analysis of SAR metadata • Facilitate information dissemination • need for improved data storage/retrieval • Currently stored as binary flat files • inadequate to support web-based access and analysis • creates platform dependence Lindsey Gray

  8. Problem Statement: Value of a Technology Solution • Web-based access and analysis • more employees have more access to more detailed data • create platform independence • Relational database management system (RDBMS) & structured query language (SQL) will provide faster access and better support. Lindsey Gray

  9. Problem Statement: Competitive Products • No competitive products available commercially • Requires custom solution due to data security issues and desire to use new emerging technologies Lindsey Gray

  10. Functional Requirements • Provide web-based access to SAR metadata • Insert and store SAR metadata in database • Query database for SAR metadata • Use XML to describe SAR metadata David Meffe

  11. Non-functional Requirements • Product requirements. • Usability – online help features and user friendly. • Performance – query load average 50-100 per day. Max query load 1000 per day. • Maintenance – application must be extensible. Lifecycle of 5-10 years. David Meffe

  12. Non-functional Requirements • Process requirements. • Standards – Ambysoft coding standards www.ambysoft.com/javaCodingStandards.html • The final product will be delivered on writable disk containing all commented code, JavaDoc and architectural diagrams David Meffe

  13. Non-Functional Requirements • Implementation Requirements • Java Database Connectivity (JDBC) API’s used for accessing the database • One image viewed at a time • Must run in Windows NT • Oracle 8i used for the Database • Java API for XML parsing (JAXP) will be used David Meffe

  14. Business Philosophy • Multiple platforms • Make use of extensible modular design • Make use of distributive processing • Maximize computer assets David Meffe

  15. Design Overview • Design Method • Incremental Method • High-Level Architectural Views • Functional View • Logical View • Physical View • No Data View • Cleansed beyond recognition David Meffe

  16. Design Method • Incremental approach • Proceed through analysis and requirements phase linearly. • Process loops back to the requirements in the architectural, design, implement and testing stages • Ensures the requirements are a part of each step in the procedure David Meffe

  17. Design Method Problem Statement Requirements Architecture Design Implementation Testing David Meffe

  18. Design Method • Reason for using an incremental method • Allows the team to design the requirements and specifications rapidly • Ability to expand upon initial requirements • Dealing with cutting edge technology • Evolving project requirements • Better risk mitigation • Problems would be found earlier in the project David Meffe

  19. Technical Concept • Functional • Perceives the system through external entities • Entities – User, Web Browser, Input device, Web server View Metadata Browser HTML/XML User Web Server Input Device Enter URL Web Request David Meffe

  20. Technical Concept • Logical • Perceives the system through interactions of components in the application • Components – Web Browser, Web Server, Server Programs, Database, Generated XML Request Web Browser Web Server Server Programs Database Result Generated XML David Meffe

  21. Technical Concept • Physical • Perceives the system in physically tangible elements and interactions • Elements – Web Browser, Web Server, Database Server Web Browser Database Server Web Server Web Browser Web Browser David Meffe

  22. Risk Assessment • Risks • Marginal • Critical and Catastrophic • Risk Table • Mitigating,Monitoring, and Managing • General Strategy • Specific Steps William Busby

  23. Risk Table

  24. Risk: Learning new emerging technologies • Mitigation • Increase teams knowledge of technologies • Learn & practice between semesters • Monitoring • Enthusiasm for technologies • Confidence in ease of project • Management • Reassign resources • Group discussions William Busby

  25. Risk: Technology will not meet expectations • Mitigation • Continually assess use of technologies • Determine if other technologies can be substituted • Monitoring • Verify correct usage • Management • Communication w/ sponsor on usage & limitations William Busby

  26. Risk: Incomplete functionality • Mitigation • Create several prototypes • Monitoring • Sponsor enthusiasm about prototypes • Non-priority feature development • Management • Prioritize end-user needs & wants William Busby

  27. Risk: Sponsor not actively involved in project • Mitigation • Maintain active communication • Prototype usage • Monitoring • Contact with the sponsor • Management • Schedule meetings/phone conferences • Reach next deliverable sooner William Busby

  28. Risk: Lack of actual data • Mitigation • Request sample unclassified data • Generate ER diagrams for sponsor review • Monitoring • Teams understanding of the data • Management • Team/sponsor discussion about the data William Busby

  29. Resource Availability • Personnel • No experienced XML developers • One experienced Oracle/Servlet developer • 3 developers that require little or no sleep • Tools • Internet Explorer 5.5 & Netscape Navigator 6 • Oracle8i • Java • Forte • Book reimbursement William Busby

  30. Schedule • Fall 2000 • Problem Statement • Requirements • Proposal • Spring 2001 • Architecture • Design • Coding & Testing William Busby

  31. Current Status • On schedule • Against the odds • Many high probability risks • Communication problems • Able to go the distance • Purchasing books • December 15th meeting at Lockheed-Martin William Busby

More Related