1 / 52

Spherical Modeling Tool

Spherical Modeling Tool. Team 13. Outlines. Acceptance Test Plan and Cases OCD Prototype Update Architecture Life Cycle Plan Feasibility Evidence. Acceptance Test Plan. Outline. * Unit Testing * Monkey Testing * Performance Testing * Security Testing * Reliability Testing

Télécharger la présentation

Spherical Modeling Tool

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. Spherical Modeling Tool Team 13

  2. Outlines • Acceptance Test Plan and Cases • OCD • Prototype Update • Architecture • Life Cycle Plan • Feasibility Evidence

  3. Acceptance Test Plan Outline * Unit Testing * Monkey Testing * Performance Testing * Security Testing * Reliability Testing * Load Testing * End to End Testing

  4. Acceptance Test Cases Unit Tests * Creating a Sphere – Test whether user can successfully create a sphere. * 2D/3D View – Test to see if user can toggle between 2D and 3D views. * Edit Sphere – Test to see if user can edit the sphere and save it. * Share Sphere – Test to see if user can share the sphere succesfully. * Register – Test user registration, login and logout. Test the edge cases and rainy day scenarios(bad user input,etc.). * Creating Questions –Test whether user can create questions. * Edit Questions–Test to see if user can edit the questions.

  5. LOS Test Cases * Performance Testing - Speed(test the initial load times of home page, time it takes to toggle between 2D/3D view,etc.). * Scalability (how does system respond when there are 100 users and what happens if we gradually increase the number of users). * Stability (what happens if 1000 users tries to create a 2D or 3D sphere, what happens when all of them try to toggle between 2D/3D view). 5

  6. LOS Test Cases * Security Testing – Test cases according to (www.owasp.org/index.php/Web_Application_Security_Testing_Cheat_Sheet). * Reliability Testing – Test to see if we are up by 99% of the time. * Load Testing – Mainly do stress testing, concurrent users logging into the system at one time, concurrent user logging into system rapidly and doing the same thing or using the app heavily. Will be mainly using Apache Jmeter and if it does’t fit our needs, we will evaulate LoadUIWeb(loaduiweb.org). 6

  7. DOD * Code written including comments,checkins. * Pull requests are reviewed. * Unit test are written and passing. * Build without errors. * Passed UAT. * Relevant documentation produced or updated. * Trello tasks are updated and remaining time set to zero and task closed. 7

  8. Team’s Strong Points(Operational View) * Strong Communication (email, team/client meetings,etc.) * Commitment to The Class and to The Project * All CS Master Students

  9. Team’s Strong Points(Technical View) * Consists of Subject Matter Experts Programming Wise (Both back and front end technically solid people, in other words skills/needs match) * Ability to Learn and Iterate New Technologies Quickly * Use of Online Collaboration Tools (Google Docs, Dropbox, Trello, Flowdock, Bugzilla, Winbook)

  10. Team’s Weak Points(Operational View) * Having An Off-Campus Student Adds an Extra Layer of Communication (This is mitigated by team members taking notes and uploading to Dropbox, Skype meetings and emails) * People Having Different Schedules (This is mitigated by agreeing on a common time) * Two new students – adjustment time,etc.

  11. Team’s Weak Points(Technical View) * Low Precedence Technology (There is nothinglike Spherical Modeling Tool on the market. Possible solution is by having a prototype and see how it works.). * Possible Technology (Like advanced graphic rendering needed to render the Spherical Model) might take some time to learn and iterate(Possible solution is to constantly practice the new technology and get help from online communities).

  12. Overall Evaluation * Strong Team * Real Life Project * Great Learning Opportunity * Diverse Backgrounds

  13. OCD Outline * System Purpose * Changes in System * Capability Goals * Level of Service Goals * Diagrams

  14. System Purpose * Develop a data visualization model that uses the shape of a sphere to provide a holistic evaluation of the condition of dynamic systems * Mission is to improve productivity, communication, awareness and understanding in a wide variety of domains * Domains include education, healthcare, business and government organizations

  15. Changes in System There is no change in the system.

  16. Capability Goals

  17. Level of Service Goals

  18. System Boundary and Environment Diagram

  19. Prototype Update http://mighty-refuge-4158.herokuapp.com/

  20. Architecture Outline * System Context * Class Diagram * Sprint 1 Subset * NDI Products

  21. System Context

  22. Class Diagram (Server)

  23. ClassDiagram(Client)

  24. Sprint 1 Subset

  25. Architecture

  26. Life Cycle Plan Outline * Key Stakeholders Roles & Responsibilities by Phase * Project Plan * Iteration Plan

  27. Roles in 577B

  28. Responsibilities Example

  29. Project PlanConstruction Iteration Sprint 1

  30. Project PlanConstruction Iteration Sprint 2

  31. Project PlanDevelopment Phase - Transition Iteration

  32. Iteration Plan Strategy • * Construction Iteration: Two Iterations • * Within The Two Iterations: • - Adopt Scrum Development Process • - Three 2-Week Sprints in CCI • - One 2-Week Sprint in FCI

  33. Iteration Plan for Core CapabilityDrive Through Milestone Construction Iteration Capabilities To Be Implemented Sprint 1 : 50 points Sprint 2 : 53 points Sprint 3 : 40 points

  34. Iteration Plan for Core CapabilityDrive Through Milestone • 1. Construction Iteration Capabilities To Be Tested • * All The Capabilities Will Be Tested • (Except Those Noted On Next Slide) 2. Non-Functional Requirement To Be Tested

  35. Iteration Plan for Core CapabilityDrive Through Milestone * Construction Iteration Capabilities NOT To Be Tested

  36. Feasibility Analysis Outline * Feasibility Evidence & Business Case * Risk Analysis * Traceability Matrix * Definition of Done * Metrics * Conclusion 36

  37. Feasibility Evidence & Business Case Assumptions * A Successful Data Visualization Model * Analysis of The Application (As An Automation Tool Implemented to An Environment That Already Uses The Model) * Usage Rate: 60 Spheres/Year 37

  38. Business Case Cost Identification * Personnel Costs 38

  39. Business Case Cost Identification * Hardware and Software Costs 39

  40. Benefits Identification 40

  41. ROI Analysis 41

  42. Risk Analysis 42

  43. Traceability Matrix 43

  44. Traceability Matrix 44

  45. Traceability Matrix 45

  46. Definition of Done 46

  47. Definition of Done 47

  48. Metrics * Bugzilla Reports * Bug Periods Efficiency * Worked Hours Efficiency 48

  49. Metrics Bug Period Efficiency Blue - Days to be finished Orange - Over the deadline 49

  50. Metrics Worked Hours Efficiency 50

More Related