CIS 895 – MSE P ROJECT Cooperative Robotics Organization Simulator (CROS) Presentation 1 on Mar 1 st, 2011 Daniel Christopher Greene 1

O UTLINE 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 2

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

P ROJECT O VERVIEW Motivation Simulation should be as realistic as possible while maintaining abstraction. Hex Grids allow more degrees of freedom without distorting distance. 4

P ROJECT O VERVIEW ( CONT.) Goal To update the CROS framework Objects to display in a hex-grid Capabilities updated to work in a hex-grid 5

P ROJECT O VERVIEW ( 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. 6

S QUARE G RID VS. H EX G RID 7

S YSTEM O VERVIEW 8

S YSTEM O VERVIEW ( CONT ) 9

U SE CASE D IAGRAM 10

D ATA F LOW 11

P ROJECT R EQUIREMENTS 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 12

GUI R EQUIREMENTS 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 13

O RGANIZATION S IMULATOR R EQUIREMENTS 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 14

W UMPI W ORLD R EQUIREMENTS 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 15

P ROJECT S CHEDULE Key Dates Presentation 1:March 1 st, 2011 Basic Prototype Presentation 2: March 29 th, 2011 Redesigned Architecture Prototype using proposed architecture Presentation 3: April 26 th, 2011 Finish Reimplementing Capabilities Polish Simulator Back-end 16

P ROJECT S CHEDULE 17

C OST E STIMATION M ODEL 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. 18

C OST E STIMATION F ORMULAE Effort = 2.94 * EAF * (KSLOC) E Time = (3.67*(Effort) F )*SCHED%/100 E = B *SF = *SF F = ( *[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 19

S CALE F ACTORS IdentifierClassificationValueReasoning PRECVery High1.00 Familiarity with the project framework and applications based on it. FLEXExtra High0.00 The implementation is very flexible. RESLHigh2.83 Some tools/methodologies available for Risk Resolution TEAMVery High1.10 Stakeholders and Developer(s) highly cooperative. PMATHigh3.12 Fairly Mature Process 20

E FFORT A DJUSTMENT F ACTORS IdentifierClassificationValueReasoning RELYVery Low0.82 Project is not safety critical, and does not need to run for extensive periods of time. DATALow1.00 Data is domain specific. Only data necessary is configuration file. CPLXNominal1.00 Complex system. Abstracted enough to make applications simple. RUSENominal1.00 The changes must be met for the current project. DOCUHigh1.10 Documentation must be met to match the rest of the project. TIMENominal1.00 Simulation won’t be needing 50% Execution Time STORNominal1.00 Constraints limited by JVM and application specific PVOLLow0.87 Major changes to platform not frequent. ACAPNominal1.00 Some experience with High level design. 21

E FFORT A DJUSTMENT F ACTORS ( CONT ) IdentifierClassificationValueReasoning PCAPNominal0.90 Developer is highly versatile and capable PCONVery High.81 Personnel Continuity – Very low turnover AEXPHigh0.88 Developer has worked with similar applications for several years. PLEXHIGH0.91 Developer has several years with the platforms used LTEXHIGH0.91 Developer has 4+ years experience with Java, and a few years with other software engineering tools TOOLNominal1.00 Some tools have some Lifecycle integration SITEVery High0.86 All parties responsible for the project are in the same building SCEDNominal1.00 Project is tightly scheduled but is a bit flexible 22

C OST E STIMATION C ALCULATIONS 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.21 chronological months Result: Project should be able to be accomplished in 1 semester. 23

S OFTWARE Q UALITY A SSURANCE P LAN 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 24

S OFTWARE Q UALITY A SSURANCE P LAN ( CONT.) Documentation A listing of the required documentation is available at: Project Documentation will be available at : MSE Portfolio/ 25

S OFTWARE Q UALITY A SSURANCE P LAN ( 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 26

S OFTWARE Q UALITY A SSURANCE P LAN ( 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 27

S OFTWARE Q UALITY A SSURANCE P LAN ( 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 28

S OFTWARE Q UALITY A SSURANCE P LAN ( 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 29

I MPLEMENTATION C HOICES 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 30

P ROTOTYPE D EMONSTRATION Wumpi World Shows agent moving in a Hex-Grid 31

P HASE 2 D ELIVERABLES 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 32

T O -D O L IST Revise the Documents Revise Project Schedule Redesign Simulator Architecture? Implement Hex-based Capabilities 33

Q UESTIONS ? 34