cis 895 – mse p roject cooperative robotics organization simulator (cros) presentation 1 on mar 1...

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 Requirement

15

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 FACTORS

Identifier 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?