1. Project: Dynamic Presenter Students: Carlos Fernandez Jimmy Mauri Jose Camino Mentor: Juan Caraballo
Final Presentation
CIS 4911 Senior Project
School of Computing and Information Sciences
Florida International University
December 9, 2013

2. Problem Statement
Multiple collaborators may work on the same presentation together
Each collaborator’s changes may conflict with each other
Invalid data may be added and go unnoticed until its too late
Important data may be deleted
Existing systems don’t attempt to solve these issues

3. Solution
Dynamic Presenter: A Presentation Management System with the following features:
Collaborative Projects: Multiple users can work on a presentation simultaneously.
Strict version control: Project managers and presentation creators have complete control over the changes made by other collaborators.
Extensive version history: An entire presentation can be reverted to a previous version. Individual slides can also be reverted to a previous version without affecting the rest of the slides.

4. Project Management

5. Use Case Diagram

6. Functional Requirements
Use Case ID: DP11 - Checkout a slide
Use Case Level: High-level Use Case
Functional Requirement: The system shall allow users to checkout a slide from their project.
Non-Functional Requirements:
Usability: The actors must have basic knowledge in web browsing and basic understanding of the application's workflow.
Reliability: The system should have at least 95% uptime. The system should not crash because of this use case at any step.
Performance: A single checkout should occur in under 2 seconds.
Supportability: This will be implemented for HTML 5.0 compliant web browsers such as Internet Explorer 9, Mozilla Firefox, or Google Chrome.

7. Functional Requirements
Use Case ID: DP14 – Revert a slide
Use Case Level: High-level Use Case
Functional Requirement: The system shall allow managers and presentation creators to revert a slide to a previous version.
Non-Functional Requirements:
Usability: The actors must have basic knowledge in web browsing and basic understanding of the application's workflow.
Reliability: The system should have at least 95% uptime. The system should not crash because of this use case at any step.
Performance: Reverting a single slide to a previous version should take less than 2 seconds.
Supportability: This will be implemented for HTML 5.0 compliant web browsers such as Internet Explorer 9, Mozilla Firefox, or Google Chrome.

8. System Decomposition
User Interface  - The primary means of interaction with the system.  It will handle all requests from the client and transfer them appropriately to the other subsystems. It will also handle return messages from data requests for the DBMS and FileSystem.
Version Control System - Handles version control for the file system by ensuring files requested are appropriate for the version that is requested by the client (or is appropriate for the client).  
Presentation Parser - Encapsulates all functionality related to parsing the presentation data. Extracts relevant information from the xml files contained in the presentation. Merges and splits presentation files.

9. System Decomposition

10. System Deployment

11. Class Diagrams - Parser

12. Class Diagrams - VCS

13. Class Diagrams – User Interface

14. Persistent Data Design

15. Security/Privacy
System generally won’t hold PII credentials in database.
Confidentially marked slides will be encrypted.
DBMS for authorization to be firewalled to prevent unauthorized access.
Passwords for accounts are salted and hashed for protection (provided by werkzeug.security, included in Flask)

16. Validation Sunny Day Test Case Checkout a slide Test Case ID
DP_011_Test003
Purpose of Test
Test the capacity for a Slide Creator to Check Out a Slide for themselves.
Test Setup
The user will enter the website. User will successfully log in to the system. User will access a project where they are the Slide Creator of that project. User will select “Checkout Slide”. User will select a slide that hasn’t been checked out yet in the project and submit their choices.
Input
Slide: 3
Expected Output
The slide will be checked out to that user.

17. Validation Rainy Day Test Case Checkout a slide Test Case ID
DP_011_Test004
Purpose of Test
Test the system if it will prevent multiple concurrent checkouts on the same slide.
Test Setup
The user will enter the website. User will successfully log in to the system. User will access a project where they have are either the Presentation Creator or Project Manager in that project. They will select “Authorize User for Checkout”. They will select a slide that has been checked out in the project and submit their choices.
Input
User:
Slide: 2
Expected Output
The system should prevent the checkout from occurring, saying it already has been checked out.

18. Validation Sunny Day Test Case Revert a slide Test Case ID
DP_014_Test001
Purpose of Test
Test that Presentation Creators are able to revert the changes to a single slide
Test Setup
The user will enter the website. User will successfully log in to the system. User will access a project where he/she is a Presentation Creator. User will select the “Revert Slide” link next to the desired slide. User will select the previous version of the slide from the list and submit the changes.
Input
User:
Slide: 2
Expected Output
The current version of the slide will reflect the changes of the previous version.

19. Validation Rainy Day Test Case Revert a slide Test Case ID
DP_014_Test002
Purpose of Test
Test that Slide Creators are not able to revert the changes to a slide.
Test Setup
The user will enter the website. User will successfully log in to the system. User will access a project where he/she is a Slide. User will select the “Revert Slide” link next to the desired slide.
Input
User:
Slide: 2
Expected Output
The system should prevent access for the slide creator to revert the changes for the slide.

20. Questions?