1. UPenn is a very large school with many departments. Finding help from the right place can be confusing, responses can take a long time PennHelp’s purpose is to assist students and staff in getting questions answered quickly and easily PennHelp: –Provides question ticketing system access to Student Affairs depts. –Contains history of previously asked/answered questions –Bypasses email, preventing questions from getting lost in junk mail –Allows staff to get only pertinent questions The Problem

2. Roles and Responsibilities Brian CaputoLead, Front end coding Adam FrancisTesting, Documentation, Versioning, Scheduling Inder NandaCo-Architect, Back end coding Blake WilmarthCo-Architect, Back end coding, Navigation Tree Wei XiangWeb Design, Testing, Documentation

3. Architectural Overview Two aspects to the design: Content Management –Users must be able to add content in the form of questions and responses –User pages must reflect the status of their questions and history of open and closed questions –Users should be able to navigate questions posted by other users –Staff notification of assigned questions based on the office and category selected –Public and user histories

4. Architectural Overview 2 Administrative Interface –Assign user roles Student, Staff, Admin, or Retired –Assign staff to categories –Modify the offices and categories in the tree and their meta information –Remove inappropriate content (Not yet implemented)

5. Website Demonstration Demonstration

6. Process: Requirements Question/Ticketing system for Penn students and staff –Data and functions in the Penn Portal website as a base –Automate question assignment to appropriate staff –Asker-Staff communication –Question/Answer histories Use Cases – what we would want in such a system based on past experience –Easy to navigate to the “place” you have a question –Don’t have to know who to ask ahead of time –Quick turnaround, communication –Central repository of common problems and their solutions –Admin requirements elicited to support the operation of such a system

7. Process: Architecture CMS + Admin Facilitation: Office/Category Navigation RDBMS Office and Category Navigation Hierarchy of grouped offices and categories Selection assigns questions to staff Tree quick search Office contact (meta information) XML –Natural storage for static hierarchical data Allows for arbitrary levels –Synergy with.NET

8. Process: Architecture 2 RDBMS: Database Design Models the component entities and the relations between them –Users, Questions, Responses, Offices, Categories A Stored Procedures API defines the interface between the Database Layer and the Application Layer

9. Process: Design User Interface Design: –User experience analysis: Students, Staff, Administrators –Page layout analysis: Convenience, ease of use, efficiency, effectiveness –Quality analysis: Robustness, comprehensibility, reliability, expandability – Unified Modeling Language to explore the workflow – Refinement process: Scenario testing and peer reviews

10. Process: Estimation & Risks Estimation: –Created Milestones based on workload and to assess strict deadlines –Initial Schedule layout: Week 1: Learning curve Week 2: Question/Response systems up Weeks 3 and 4: Admin page, Testing Risks: –Communication problems between members –Learning new language/Dev environment, etc. –Lack of focus/Feature creep –Constraints for members to work/meet due to outside circumstances –Database issues/ISP issues

11. Process: Coding.Net 3.5 framework –Uses the ASP.net form model ASP.net, XML(NavTree), C#, CSS, HTML, and JavaScript. 7 pages including the master(template) page. Each page contains a separate C# “code behind” file(.aspx.cs) for logic and event handling and a design file (.aspx) –Separate tier for data access in wrapper class.

12. Process: Coding 2 Office/Category navigation and selection –XML data bound to.NET TreeView control –Quick search: depth-first search with word stemming –Admin modifications reflected in both XML and database Back-end stored procedures written for Navigation, Content Management and Admin functions in MS SQL Server 2008 T-SQL

13. Process: Testing Unit Tested stored procedures, etc. Testing approach: coverage-based, error-based, Black box and White box. Testing metrics: View Restriction Rule, invalid inputs, and abnormalities. Manual and automated testing of website –Automated Testing with Selenium/Java Browsers Tested: –Firefox (Mac/PC), IE (PC), Safari (Mac) Logged issues into Google Code site Followed use cases for various input/output types

14. Process: Deployment Versioning: –Subversion client used to upload builds/files to Google Code site, track various updates Web Publishing

15. Process: Evaluation Metrics: –Over 3500 LOC in complete version –96 functions (31 for the NavTree) –1128 LOC in SQL Scripts, 38 stored procedures –Counted LOC, Function points, Bugs filed (approx. 40) Risk Analysis - What did we use to manage the risks? –Heroics –Matching Talent to task as much as possible –Put together separate database schema for testing Planned to prevent database corruption

16. Post Mortem What did we do right? –Most of the initial requirements were implemented –Managed risks What would we change next time? –Create a backup system –Possibly simplify the design of XML to allow more time for testing/integration in the schedule –Prioritize tasks to tackle more advanced material earlier –Make the site more inviting, add more charm