1. METTS: Metric Employee Time Tracking System Final Project Presentation 21 April 2009 1

2. Presentation Outline I.Initial Idea II.Project Scope III.Outline of Iteration Process IV. Requirements and Actors V.System Architecture VI.Use Case Comparison VII. Snapshot: Manage Metric Data Use Case VIII. Future Capabilities IX.Project Evaluation: Conclusion 2

3. Initial Idea: First Challenge Need exists at the Software Engineering Directorate (SED) to collect metrics data Idea to create a metric system that would also integrate existing Time and Attendance system Complications: Government vs. Contractor roles – Some information government specific Need to send information to METTS database and a Time and Attendance system Additional actors in the role of timekeeper and time certifier 3

4. Evolution of Initial Idea 1 st proposal meeting – Difficulties of implementing METTS with existing Time system discussed – Decision to focus on a simpler, more metrics- focused design – Still wanted it to be something that could be implemented at SED – Original proposal created with this new idea in mind 4

5. Project Scope Focus on time metrics Designed to implement an existing database structure Decision-support system System generates data for export Project Lead customizes project-specific time categories Potential to interface or integrate with a Time and Attendance system as a future capability 5

6. First Iteration Plan Establish functional and non-functional requirements and constraints Use case specifications Use case and activity diagrams Overall system architecture Develop techniques for analysis to be used in 2 nd Iteration 6

7. Second Iteration Plan Build on first iteration results Refine use cases: focus on abstraction Reduce redundancy White box analysis on major use cases Refine analysis for future iterations 7

8. Functional Requirements System will authenticate the actor System will allow certain actors to manage metric data System will allow project leads to manage project configuration System will allow data to be exported System will have a backup database System-level activities will be managed by system administrators 8

9. Non-functional Requirements Compatibility of exported data Backups performed in accordance with IA standards Web-based relational database structure Availability Privilege hierarchy of users 9

10. Actors Employee Project Lead System Administrator Operating System Scheduler 10

11. Actor: Employee Least-privileged user Able to manage and export his/her own data Associated with one or more projects as assigned by Project Lead 11

12. Actor: Project Lead Able to manage and export his/her own data Able to view, edit, unlock, delete, and export: Individual employee data for employees within assigned projects Project-level data Oversees project configuration Editing project categories Project memberships 12

13. Actor: System Administrator Oversees managing projects at system level Assigns user privileges Monitors authentication process Reviews maintenance logs for system errors 13

14. Actor: Operating System Scheduler Responsible for performing system backups Automated process 14

15. System Architecture 15

16. User Package Entities Includes User object, inherited by – Employee – Administrator Project Lead is a special type of Employee – shares main metrics functionality – has additional capabilities to manage projects 16

17. User Package Controllers UserValidationHandler – validates user against database SessionHandler – handles sessions used to specify metrics data 17

18. Project Package Project contains – associated metrics – project configuration Project Configuration contains – all relationships to the project employees categories project lead 18

19. Data Package Simple low-level building-block objects – Metric – MetricCategory Simple single-purpose controllers – ExportHandler 19

20. Other Packages Error Package – Handles all errors of METTS – Keeps all errors together to increase cohesion Display Package – Handles all output of METTS – Uses functions to display certain objects used throughout METTS 20

21. Use Case Comparison First Iteration I.Authentication - Login, Logout II.Manage Metric Data - Edit Metrics, View Employee Metrics, View Project Metrics, Unlock Metrics, Delete Metrics III.Manage Project Configuration - View Project Configuration, Edit Project Categories, Edit Project Membership IV.Export Data V.Backup Database VI.Manage System - Add User, Edit User, Import User, Add Project, Edit Project 21

22. Second Iteration Plan—Revisited Goal to reduce redundancy Refine use cases Analysis of use case functions – Focus on include and extend relationships Result: Added one use case, but merged and deleted several others Greatest changes within most important use cases 22

23. Use Case Comparison Second Iteration I.Authentication - Login, Logout II.Project Session - Select Project, Exit Project III.Manage Metric Data - View Metrics, Edit Metrics, Unlock Metrics, Delete Metrics, Export Data IV.Manage Project Configuration - View Project Configuration, Edit Project Categories, Edit Project Membership V.Manage System - View Projects, Add Project, Edit Project VI.Backup Database 23

24. Snapshot: Manage Metric Data First Iteration Allows actors to input and manage metric data Actors – Employee – Project Lead – System Administrator Five sub-use cases – Edit Metrics – View Employee Metrics – View Project Metrics – Unlock Metrics – Delete Metrics 24

25. Snapshot: Manage Metric Data First Iteration: Black Box Analysis View Employee Metrics View Project Metrics 25

26. Snapshot: Manage Metric Data First Iteration Edit Metrics 26

27. Use Case Challenges View Project Metrics and View Employee Metrics very similar -Decision to merge into a single View Metrics -Selecting a project becomes part of Project Session Edit, Unlock, and Delete also require viewing -Extend relationship with view enhanced Systems Administrator and Project Lead have conflicting roles -Decision to give Project Lead exclusive management of metrics data Export Metrics also managing metric data, but separate -Decision to merge into Manage Metric Data and extend from View Metrics 27

28. Snapshot: Manage Metric Data Second Iteration Allows actors to input and manage metric data Actors – Employee – Project Lead Five Sub-Use Cases – View Metrics – Edit Metrics – Unlock Metrics – Delete Metrics – Export Data 28

29. Snapshot: Manage Metric Data Edit Metrics – 1 st iteration Edit Metrics – 2 nd Iteration 29 Iteration Comparison

30. Snapshot: Manage Metric Data Second Iteration: Black Box Analysis View Metrics Edit Metrics 30

31. Snapshot: Manage Metric Data Second Iteration: White Box Analysis View Metrics 31

32. Snapshot: Manage Metric Data Second Iteration: White Box Analysis Edit Metrics 32

33. Change Summary Use of black box and white box analysis to refine use case roles within system Overlapping/duplicate roles condensed Elimination of functions performed outside system Implementation of generic use cases and specific activity diagrams 33

34. Future Capabilities Ability to interface with current Time and Attendance System Ability to remove metric categories from a project Ability for a Project Lead to view totals for all projects they manage Ability for Division Chiefs to view all projects in their division 34

35. Project Evaluation Accomplished our revised idea – Created a system capable of saving/exporting metric data System architecture revised but not radically changed Met or exceeded goals at each iteration – Clearer, more concise use cases – Refined actor roles and responsibilities Further analysis still possible 35

36. Questions? 36