CIS 895 – MSE PROJECT

Cooperative Robotics Organization Simulator

(CROS)

Presentation 1 on Mar 1st, 2011

Daniel Christopher Greenedgreene@ksu.edu

1

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 2

TERMS 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

PROJECT OVERVIEW Motivation

Simulation should be as realistic as possible while maintaining abstraction.

Hex Grids allow more degrees of freedom without distorting distance.

4

PROJECT OVERVIEW (CONT.) Goal

To update the CROS framework Objects to display in a hex-grid Capabilities updated to work in a hex-grid

5

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.

6

SQUARE GRID VS. HEX GRID

7

SYSTEM OVERVIEW

8

SYSTEM OVERVIEW (CONT)

9

USE CASE DIAGRAM

10

DATA FLOW

11

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

12

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

13

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

14

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 Requirement15

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

16

PROJECT SCHEDULE

17

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.

18

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 19

SCALE FACTORSIdentifier Classification Value Reasoning

PREC Very High 1.00Familiarity with the project framework and applications based on it.

FLEX Extra High 0.00 The implementation is very flexible.

RESL High 2.83 Some tools/methodologies available for Risk Resolution

TEAM Very High 1.10Stakeholders and Developer(s) highly cooperative.

PMAT High 3.12 Fairly Mature Process

20

EFFORT ADJUSTMENT FACTORSIdentifier Classification Value Reasoning

RELY Very Low 0.82Project is not safety critical, and does not need to run for extensive periods of time.

DATA Low 1.00 Data is domain specific.  Only data necessary is configuration file.

CPLX Nominal 1.00 Complex system.  Abstracted enough to make applications simple.

RUSE Nominal 1.00 The changes must be met for the current project.

DOCU High 1.10 Documentation must be met to match the rest of the project.

TIME Nominal 1.00 Simulation won’t be needing 50% Execution Time

STOR Nominal 1.00 Constraints limited by JVM and application specific

PVOL Low 0.87 Major changes to platform not frequent.

ACAP Nominal 1.00 Some experience with High level design.

21

EFFORT ADJUSTMENT FACTORS (CONT)

Identifier Classification Value Reasoning

PCAP Nominal 0.90 Developer is highly versatile and capable

PCON Very High .81 Personnel Continuity – Very low turnover

AEXP High 0.88 Developer has worked with similar applications for several years.

PLEX HIGH 0.91 Developer has several years with the platforms used

LTEX HIGH 0.91 Developer has 4+ years experience with Java, and a few years with other software engineering tools

TOOL Nominal 1.00 Some tools have some Lifecycle integration

SITE Very High 0.86 All parties responsible for the project are in the same building

SCED Nominal 1.00 Project is tightly scheduled but is a bit flexible

22

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.21 chronological months

Result: Project should be able to be accomplished in 1 semester.

23

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

24

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/

25

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

26

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

27

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

28

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

29

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 30

PROTOTYPE DEMONSTRATION Wumpi World

Shows agent moving in a Hex-Grid

31

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

32

TO-DO LIST Revise the Documents Revise Project Schedule Redesign Simulator Architecture? Implement Hex-based Capabilities

33

34

QUESTIONS?