CIS 895 – MSE Project

1. CIS 895 – MSE Project Cooperative Robotics Organization Simulator (CROS) Presentation 1 on Mar 1st, 2011 Daniel Christopher Greene dgreene@ksu.edu

2. Outline • Terms • Project Overview • Motivation • Goal • Purpose • Block Diagrams and Data Flow Diagrams • Project Requirements • Project Schedule • Cost Estimation • Software Quality Assurance Plan • Prototype Demonstration • Questions / Comments

3. Terms • Cooperative Robotics Organization Simulator (CROS) • A tool for testing organization models in multiagentsystems. • Multiagent& Cooperative Robotics (MACR) • A group headed by Dr. Scott DeLoach whose primary focus is organization-based multiagent systems.

4. Project Overview • Motivation • Simulation should be as realistic as possible while maintaining abstraction. • Hex Grids allow more degrees of freedom without distorting distance.

5. Project Overview (cont.) • Goal • To update the CROS framework • Objects to display in a hex-grid • Capabilities updated to work in a hex-grid

6. Project Overview (cont.) • Purpose • To test organization models in a multiagent system • To have agents with more degrees of freedom • To have capabilities with more realistic evaluation of distance.

7. Square Grid vs. Hex Grid

8. System Overview

9. System Overview (cont)

10. Use case Diagram

11. Data Flow

12. Project Requirements • Requirements broken into 3 sections • GUI Requirements • Simulator Requirements • Wumpi World Requirements • Each section has it’s own identifier and numbering system • Each requirement has an associated build release noted in the Vision Plan

13. GUI Requirements • GUIRI 1 [CR] - The GUI will display objects in a hex-grid format. • GUIRI 2 - The image assets associated with various applications should be redrawn/resized to fit in hexagon. CR stands for Critical Requirement

14. Organization Simulator Requirements • OSRI 1 [CR] - Update the Directions class to handle Hex directions. • OSRI 2 [CR]  - Update the AbstractAgent class to be able to handle the Hex directions. • OSRI 3 [CR] - Update the LocationData class to compute distance with Hex-grid coordinates. • OSRI 4 [CR]- Update the Gripper to be able to grab any of the 6 neighboring cells. • OSRI 5 [CR] - Update the Heat Sensor to be able to sense ranged hex-grid. • OSRI 6 [CR] - Update Holonomic Movement to allow hex-grid movement. • OSRI 7 [CR] - Update the Laser Range Finder to compute range with hex-grid coordinates. • OSRI 8 [CR] - Update the Sonar to be able to sense ranged hex-grid. • OSRI 9 [CR] - Update the Sonar to be able to compute line of sight for hex-grid. • OSRI 10 [CR] - Update Steered Movement to follow hex-grid movement. CR stands for Critical Requirement

15. Wumpi World Requirements • WWRI 1 [CR] - Update the Wumpi to claw in 6 directions. • WWRI 2 [CR] - Update Bazooka to shoot in 6 directions. • WWRI 3 [CR] - Update Breeze Sensor for 6 adjacent cells. • WWRI 4 [CR] - Update Gold Grabber to drop gold in any of the 6 adjacent cells, or same cell. • WWRI 5 [CR] - Update Robot Movement to allow for 6 directions. • WWRI 6 [CR] - Update Smell Sensor to detect wumpi in range of 2 hex-grids. • WWRI 7 [CR] - Update Sparkle Sensor to detect gold in any of the 6 adjacent cells, or same cell. • WWRI 8 - Update Demo Robot to demo HEX-GRID capabilities. CR stands for Critical Requirement

16. Project Schedule • Key Dates • Presentation 1: March 1st, 2011 • Basic Prototype • Presentation 2: March 29th, 2011 • Redesigned Architecture • Prototype using proposed architecture • Presentation 3: April 26th, 2011 • Finish Reimplementing Capabilities • Polish Simulator Back-end

17. Project Schedule

18. Cost Estimation Model • COCOMO II : The Post-Architecture Model • Is used before we start developing the architecture • COCOMO II is chosen as it considers important factors like • Reliability • Software Development Complexity • Database and Memory Usage • Etc.

19. Cost Estimation Formulae • Effort = 2.94 * EAF * (KSLOC)E • Time = (3.67*(Effort)F)*SCHED%/100 • E = B + 0.01*SF = 0.91 + 0.01*SF • F = (0.28 + 0.2*[E – 0.91]) • Effort = Number of person months (PM) • Time = Duration time in months for project • KSLOC = Estimated number of source lines of code for the project (expressed in thousands) • SF = Scale Factor • EAF = Effort Adjustment Factor

20. Scale Factors

21. Effort Adjustment Factors

22. Effort Adjustment Factors (cont)

23. Cost Estimation Calculations • KSLOC estimated at: 1.5 • Based on experience with CROS framework and number of capabilities • SF = 8.05 • E = 0.99 • F = 0.30 • EAF = 0.36 • Effort = 1.58 person months • Time = 4.21chronological months • Result: Project should be able to be accomplished in 1 semester.

24. Software Quality Assurance Plan • References • Vision Plan • Project Plan • IEEE Standard for Software Quality Assurance Planning • IEEE Guide for Software Quality Assurance Planning • Supervisory Committee • Dr. Scott A. DeLoach • Dr. William H. Hsu • Dr. David A. Gustafson • Major Professor • Dr. William H. Hsu • Developer • Daniel C. Greene • Formal Technical Inspectors • TBD • TBD

25. Software Quality Assurance Plan (cont.) • Documentation • A listing of the required documentation is available at: • http://mse.cis.ksu.edu/portfolio.htm • Project Documentation will be available at : • http://people.cis.ksu.edu/~dgreene/Projects/cis895 MSE Portfolio/

26. Software Quality Assurance Plan (cont.) • Standards, Practices, Conventions & Metrics • Documentation – IEEE standards will be followed for all applicable documentation • Coding – Java coding standards • Metrics – COCOMO II will be used to measure project effort • Reviews & Audits • Supervisory committee will review all documentation at each milestone • Formal Technical Inspectors will review the architecture before the second presentation

27. Software Quality Assurance Plan (cont.) • Testing • Defined in Software Test Plan • Will be available by Presentation 2 • Outputs of each capability manually checked • Problem Reporting • Issues will be logged in a spreadsheet • All issues will be reported to Major Professor

28. Software Quality Assurance Plan (cont.) • Tools, Technologies and Methodologies • Eclipse IDE – for software development • Java – for software development • Microsoft Word – for documentation development • Microsoft Excel – for risk and problem report tracking and time logs • Microsoft PowerPoint – for project presentation creation • Microsoft Project – for drawing the Gantt chart (project planning) • Visual Paradigm – for software design development • Microsoft Paint – for any quick sketches/image changes necessary • JUnit – for testing the java code

29. Software Quality Assurance Plan (cont.) • Code and Media Control • gForge CVS for versioning control • Change logs will be maintained for all documents • Versions of documentation will be maintained on the developer’s computer

30. Implementation Choices • 1) Replace Square-Grid System entirely with Hex-Grid • Simple • Don’t have to worry about flexibility • 2) Add Hex-Grid System along-side Square-Grid System • Developer can choose which system to work with • Architecture mirror • 3) Refactor Architecture to allow a Direction Interface • Can decide which to use at Application level • A bit more work to refactor

31. Prototype Demonstration • Wumpi World • Shows agent moving in a Hex-Grid

32. Phase 2 Deliverables • Vision Plan 2.0 • Project Plan 2.0 • Architectural Design Document • Software Test Plan 1.0 • Technical Inspection List • Presentation 2 • Prototype 2.0 Source Code • Partial Implementation of Wumpi World

33. To-Do List • Revise the Documents • Revise Project Schedule • Redesign Simulator Architecture? • Implement Hex-based Capabilities

34. Questions?