1 / 18

Modernizing Academic Submission System: A Comprehensive Case Study

Explore the successful transformation of a legacy academic submission system by replacing the outdated "try" system with a scalable, cross-platform solution. Discover the motivations, requirements, architecture, and challenges faced during the project development.

rociow
Download Presentation

Modernizing Academic Submission System: A Comprehensive Case Study

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. May 2005 Greg Giacovelli – Nick Mancuso – Shaun Newsum – Jean-Paul Pietraru – Nick Stroh

  2. Agenda • Background • Motivation • Requirements • Schedule • Metrics • Architecture • Tier Design • Domain experience

  3. Background • Replace the “try” system • Compiles, tests, and saves students submissions • Provides immediate feedback to the student • Collection of scripts written in the early 1990’s • Issues: • Steep learning curve • Performance issues at peak hours

  4. Motivation • New Features • Cross platform support • Small learning curve • A solid framework • Provide clear ports for adding future customizations & expansions • Separate concerns to ease maintenance • Distribute CPU load

  5. Requirements • Gathered from: • Project sponsor • Personal experience with old system • Sample try lab configuration • Tested against: • Project sponsor • try manuals • SRS is thorough & will be useful to future developers

  6. Schedule

  7. Metrics

  8. Metrics

  9. Solution • Architectural framework • May be easily extended to meet all requirements • Runs in any J2EE-compliant application server. • Scalable by distributing amongst multiple hosts • Distributed submission processing • Compile & testing is completed by an array of clients • Increases system performance • Scales up by adding more client machines

  10. Solution • Model-View-Controller • Decouples • UI from business logic • Business logic from data • Web services • Interface to the business logic • Custom UI’s & scripts may be written

  11. Architecture

  12. Web Tier

  13. Business Tier

  14. Data Tier

  15. Middle Tier

  16. Problems we encountered • Configuration issues • jBoss • Integration tests • J2EE complexity • Learning curve

  17. Post Mortem • What went well: • Solid documentation throughout. • Proof-of-concept or better code for each major component of the system. • What we learned from: • Too much wind-up time • Should have dropped JBoss early

  18. questions?comments?concerns?

More Related