Project Instructions For The LU Rumble

User Manual:

Open the PDF directly: View PDF .
Page Count: 37

ETSA02-ADM-INS

Project

Instructions

for

the LU Rumble

Version 0.96

Prepared by Markus Borg

Dept. of Computer Science, Lund University

March 4, 2019

Contents

1 Introduction 4

1.1 Learninggoals ................................. 4

1.2 Robocode – Build the best, destroy the rest! . . . . . . . . . . . . . . . . . 5

1.3 Projectoverview ................................ 6

1.4 Projectgrading................................. 9

2 The project from a bird’s eye view 10

2.1 Engineeringtherobot ............................. 10

2.1.1 Speciﬁcation .............................. 10

2.1.2 Construction .............................. 12

2.1.3 Veriﬁcation ............................... 14

2.1.4 Robot-to-Robot communication . . . . . . . . . . . . . . . . . . . . 15

2.2 Monetizingtherobot.............................. 17

2.2.1 Bespoke supplier-customer relationships . . . . . . . . . . . . . . . 18

2.2.2 Selling robots on Robot Market . . . . . . . . . . . . . . . . . . . . 19

2.3 Strategizing to win the LU Rumble . . . . . . . . . . . . . . . . . . . . . . 20

3 Project phases 22

3.1 Projectinception................................ 22

3.2 Processmodel.................................. 23

3.2.1 Sprint1................................. 23

3.2.2 Sprint2................................. 25

3.2.3 Sprint3................................. 27

3.3 Postrelease................................... 27

3.4 LURumble ................................... 28

4 Inter-group communication 30

4.1 Theregulatorybody.............................. 30

4.2 Maintaining supplier-customer relations . . . . . . . . . . . . . . . . . . . 30

4.3 Groupconﬂicts ................................. 31

5 Detailed instructions 32

5.1 Roleassignment ................................ 32

5.2 Timereporting ................................. 33

5.3 Software Releases: Alpha, Beta, and Final . . . . . . . . . . . . . . . . . . 33

6 Expectations per deliverable 35

6.1 Projectinfrastructure ............................. 36

Revision History

Name Date Change description Version

Markus Borg 2017-12-07 Initial draft. 0.1

Markus Borg 2017-12-27 Complete draft of intro, engineering, monetiz-

ing, and strategizing. Sent for external review.

0.2

Markus Borg 2017-12-31 First draft of sprints. 0.3

Markus Borg 2018-01-02 First complete draft. 0.4

Markus Borg 2018-02-05 Updated after internal review. 0.5

Markus Borg 2018-03-06 Updated after external review. 0.6

Markus Borg 2018-03-08 Minor consistency improvements. 0.7

Markus Borg 2018-03-24 Updated after course start. Added robot com-

munication, releases and deliverables.

0.8

Markus Borg 2018-03-29 Replaced test speciﬁcation with STS. Fixed L4

dates. Introduced RoboTalk.

0.85

Markus Borg 2018-04-18 Clariﬁed the discount rule for Robot Market. 0.86

Markus Borg 2018-04-21 Added the Lab4 tools, and details for Sprint 2

and the Beta Release.

0.87

Markus Borg 2018-04-21 Added details for Sprint 3 and the Final Release. 0.88

Markus Borg 2018-04-24 Added review protocol in the process ﬁgure. 0.89

Markus Borg 2018-05-05 Updated ETSA02 RoboTalk to v1.3. 0.90

Markus Borg 2018-05-05 Clariﬁed Monetization in two parts, updated

Strategizing.

0.91

Markus Borg 2018-05-05 Updated LU Rumble rules and awards. 0.92

Markus Borg 2018-05-07 Clariﬁed bundle deals. 0.93

Markus Borg 2018-05-10 Corrected L8 date, ﬁxed typos. 0.94

Markus Borg 2019-02-05 Basic updates for 2019 edition. 0.95

Markus Borg 2019-03-04 Detailed updates for 2019 edition. 0.96

1 Introduction

This document describes the project in ETSA02 Introduction to Software Engineering

– Methodology. Together with other students, you will work together to engineer a

robot for competition in LU Rumble – a local instance of team battles in Robocode, a

programming game in which robots compete in battles without human intervention by

executing their programs.

In the remainder of this document, we use the term “group” to refer to the students

working together during the project. While the student constellations would better be

described as teams, i.e., groups of people working together toward a common goal, we

reserve the term “team” to robots competing together in Robocode.

This document is organized as follows: Section 1.1 presents the learning goals of the

project in relation to the ETSA02 formal course description.

1.1 Learning goals

The project primarily aims to increase your ability to develop high quality software

systems using established software engineering best practices. Moreover, basic software

business concepts will be introduced as each project group will oﬀer their product on a

highly competitive market.

The project complements the theoretical concepts introduced during the lectures by

taking a practical approach to the presentation of fundamental software engineering con-

cepts such as speciﬁcation, version control, testing, sprints, and releases. By the end

of the course, you will have acquired new skills with essential components of the con-

temporary software engineering tool chain: the Java programming language, the Eclipse

integrated development environment, the JUnit testing framework, the git conﬁgura-

tion management system, GitHub cloud-based project hosting, the Maven build system

(tentative), and the SonarQube automated quality assurance tool.

On top of your skills with traditional software engineering concepts and the tool chain,

you will address aspects of market-driven software engineering. Each project group will

practice making critical business and engineering decisions in a controlled fashion. The

course introduces several important activities in software business, including analyzing

the business ecosystem, ﬁnding a niche market, marketing a product, competitive pricing

strategies, and customer negotiations.

More formally, the project is primarily designed to meet the practical requirements

of the ETSA02 course description, i.e., the “Competencies and Skills”. However, the

project will also reinforce the theoretical concepts listed under “Knowledge and Under-

standing” and it contributes to the “Judgment and Approach” section.

•Competencies and Skills

–Be able to develop a project plan, requirements speciﬁcation and test plan

for a small project.

–Be able to review a project plan, requirements speciﬁcation and test plan for

a small project.

–Be able to formulate text for project documentation.

•Knowledge and Understanding

–Be able to deﬁne basic terms and deﬁnitions in software engineering.

–Be able to describe the most common software development processes.

–Be able to explain the most important steps in requirements engineering

–Be able to explain how testing is conducted.

–Be able to describe what a software architecture design is.

–Be able to describe the most important steps in project planning and project

tracking.

–Be able to describe how an organization plan and manage a series of projects.

•Judgment and Approach

–Understand the complexity involved in developing software systems

–Have an understanding of the professional role of the engineer

1.2 Robocode – Build the best, destroy the rest!

The goal of Robocode is to implement the behavior of a robot to compete against other

robots in a battle arena. The contestants have no direct inﬂuence on the game, instead

they write the AI of the robot telling it how to behave and react on events occurring in the

battle arena. Battles are running in real-time and on-screen, see Figure 1.1. Robocode

battles, referred to as “rumbles”, are either in the form of duels between individual

robots, free-for-all battles with multiple robots, or battles between robot teams.

From http://robocode.sourceforge.net/docs/ReadMe.html: Robocode oﬀers a

complete development environment, and comes with its own installer, built-in robot

editor and Java compiler. Robocode only pre-requires that a JVM (Java Virtual Ma-

chine) to exist already on the system where Robocode is going to be installed. Hence,

everything a robot developer needs to get started is provided with the main Robocode

distribution ﬁle (robocode-xxx-setup.jar). Robocode also supports developing robots

using external IDEs like Eclipse.

Robocode is an Open Source project, which means that all sources are open to every-

body. In addition, Robocode is provided under the terms of EPL (Eclipse Public Li-

cense). The Robocode game was originally started by Mathew A. Nelson as a personal

endeavor in late 2000 and became a professional one when he brought it to IBM in

Figure 1.1: Screenshot from the Robocode battle arena. (Image credit: robowiki.net

user MultiplyByZer0)

July 2001. In the beginning of 2005, Mathew convinced IBM to release Robocode as

Open Source on SourceForge. Eventually, Flemming N. Larsen took over the Robocode

project at SourceForge as administrator and developer in July 2006 to continue the

original Robocode game – which now is hosted on GitHub.

1.3 Project overview

Each project group will develop a robot using established software engineering practices.

Furthermore, each group will compose a robot team to compete in a “LU Rumble” at

the ﬁnal lecture in the course. However, no project group is allowed to ﬁeld their own

robot – instead robots developed by other groups must be purchased on an open market

(in truth, a somewhat regulated market). Consequently, each project group has two

primary goals: 1) maximizing proﬁt by selling a successfully engineered robot on the

market and 2) winning the LU Rumble by composing a competitive Robocode team.

Project groups pursue the two goals by completing three main activities that we refer

to as strategizing,engineering, and monetizing, respectively.

Figure 3.1 shows the four main phases of the project. First, during the course incep-

tion, the course infrastructure and the project tasks are introduced. More importantly,

project groups consisting of six students (preferably!) are established. Second, the back-

bone of the course follows: three development sprints mixing engineering, monetizing,

Figure 1.2: The four phases of the project. Expect also a post mortem phase, concluding

with the take-home exam.

and strategizing. Third, purchasers of robots perform acceptance testing to ensure that

the delivered robot fulﬁlls the expectations – otherwise purchasers ﬁle business claims

to request money back. Fourth, in the last phase of the project, the LU Rumble takes

place followed by an awards ceremony to recognize the winning robot team – and the

most proﬁtable project groups.

Figure 1.3 shows the context of each individual group during the project. Organiza-

tionally, your group has three divisions: 1) Engineering, 2) Purchasing, and 3) Sales.

Your group will assign the following roles: 1) project manager, 2) requirements engineer,

3) development lead, 4) test lead, 5) domain expert, and 6) sales engineer. Each role is

described in detail in Section 5.1.

Project groups do not exist in isolation, instead they act in a business ecosystem. Dur-

ing engineering of the robot, each project group will be part of two supplier-customer

relationships. First, your sales engineer will be responsible for promoting sales of the

robot under development. The domain expert of another project group will sign a con-

tract of sale, establishing a formal relationship. Your sales engineer will be the primary

communication point for the purchasing group’s domain expert, i.e., a supplier-customer

relationship involving feedback, feature requests, and negotiations. Second, analogously,

your domain expert will act as the customer in a supplier-customer relationship with

another project group. Note that, in some cases, project groups might buy from and sell

to the same other group – this is not regulated in the ecosystem.

On top of the two supplier-customer relationships, your project group will also commu-

nicate with the regulatory body (represented by your project supervisor). Your project

group will hand in various signed contracts to the regulatory body, turn to it to get sup-

port during supplier-customer negotiations, and to report the results from your accep-

tance testing. The regulatory body might also contact you with regulatory changes

during the course of the project. Finally, you will practice one-way communication with

the Robot Market, i.e., the open market where you will sell your Robot. All project

groups will complement their robot teams with additional robots during the last week

of the project – and your sales engineer will be responsible for maximizing sales of your

robot.

Figure 1.3: The project context. Your project group will interact with your supplier’s

sales engineer, your customer’s domain expert, the open Robot Market, and

the regulatory body.

// TODO: Update

1.4 Project grading

To be extended...

The project will be graded as 3, 4, 5 or UG.

The project supervisors’ overall grading guidelines include the following:

•The ﬁnal release meets the ﬁnal requirements speciﬁcation. This is partly indicated

by the customer’s successful acceptance testing.

•The delivered robot is successful and non-trivial.

•All the robots behaviors are covered by the requirements speciﬁcation.

•The test speciﬁcation describes a comprehensive veriﬁcation of the robot. Auto-

mated test cases and test reports are provided.

•The project group adhered to the process model and met all deadlines.

•All deliverables are of high quality. Appropriate technical language and a consistent

look-and-feel across documents.

2 The project from a bird’s eye view

The project consists of three main activities, interconnected as presented in Figure 2.1.

This section presents an overview of the three activities.

2.1 Engineering the robot

Each project group will develop a robot (see Figure 2.2) according to established engi-

neering principles. These principles include product prototyping, integrated require-

ments engineering, and automated testing. The process model is organized in three

development sprints, further described in Section 3.2. The engineering process is domi-

nated by three core activities: speciﬁcation,construction, and veriﬁcation. In line with

Agile development methodologies, all sprints consist of a mix of these three activities.

Still, the groups’ focus during the project will progress from speciﬁcation, through con-

struction, to veriﬁcation – also reﬂected by the order of the lectures.

2.1.1 Speciﬁcation

Requirements engineering, i.e., a systematic approach to developing a product with

an end-user perspective, will be an integrated activity throughout the project. The

requirements will be captured in a Software Requirements Speciﬁcation (SRS) adhering

to a template structure provided by the Institute of Electrical and Electronics Engineers

(IEEE). IEEE is the world’s largest technical professional organization, and a natural

resource for software engineers – possibly contented by the Association of Computing

Machinery (ACM). Both organizations support engineers in development of software

products adhering to state-of-practice approaches and provide ethical guidelines.

The IEEE SRS template provides a standard document structure: 1) an introduction

section, 2) an overall description of the product under development, and 3) a list of prod-

uct features further broken down into detailed requirements. Furthermore, the template

supports engineers to specify quality requirements such as performance, maintainability,

and memory footprint. Project groups are recommended to use a combination of tra-

ditional requirements of “shall” format and step-wise use case descriptions. While also

user stories are covered in the lectures, it uses a narrative style that is less appropriate

for development of autonomous robots.

The SRS connects all roles in the project group. While the requirements engineer is

responsible for the SRS, the sales engineer is responsible for developing a sales pitch

based on its content. The SRS will be public on the Robot Market, i.e., when other

project groups consider purchasing your robot, they will critically review your SRS.

The domain expert, having the most chance to predict what features will be valued on

Figure 2.1: Project components.

Figure 2.2: Model of the Robocode robot ( c

Klaus Knopper under CC BY-SA 3.0).

the Robot Market, will provide important input to the SRS – eﬀectively acting as a

proxy-customer until the supplier-customer relationship has been established. Finally,

the development lead is responsible for implementing the SRS in source code and the

test lead is responsible for verifying that the developed product fulﬁlls the SRS.

There are several quality attributes that a high-quality SRS should comply with. First,

the SRS should be complete, i.e., if properly implemented, the developed product shall be

a competitive robot. Just as importantly, the robot shall not oﬀer any features that are

not properly captured in the SRS – the customer is not allowed any surprises. Second,

the SRS should constitute a coherent document that is easy to follow. Furthermore,

each individual requirement should be:

Complete All information needed to implement source code to fulﬁll the requirement

shall be speciﬁed. Developers must not be forced to read between the lines.

Consistent There are no contradictions between individual requirements.

Feasible The requirement can be practically implemented by the developers given the

available resources. Also, the requirement will bring value to the end user or

another stakeholder.

Modiﬁable An SRS is rarely static, thus all requirements must be able to change. Each

requirement should be clearly identiﬁable.

Unambiguous A requirement shall only be interpretable in one way, i.e., no subjectivity

can exist. Quality requirements should be quantiﬁed, not described using vague

adjectives.

Design free Requirements shall specify what the system must or must not do, but not

how the software will ensure the requirement is met – leave that to the construction

phase.

Testable Requirements shall be possible to veriﬁable, preferably by testing, otherwise

inspection.

As a result from the speciﬁcation activities, each project group shall produce the

following deliverables, further described in Section 3.2:

Sprint 1 SRS v0.5 – Main features captured

Sprint 2 SRS v0.9 – Detailed requirements speciﬁed

Sprint 3 SRS v1.0 – A complete Robot speciﬁcation

2.1.2 Construction

The ﬁrst two computer labs will help project groups set up Robocode development in

Eclipse and source code control in git. Moreover, the second computer lab will initiate

automated unit testing, an activity that overlaps construction and veriﬁcation.

An early construction activity is software design. In this project, the design is lim-

ited to object-oriented design – the robot development is too restricted to address any

considerations on the software architecture level and there is also no user interaction

design. Each project group will present the Object-Oriented Design (OOD) using a

Uniﬁed Modeling Language (UML) class diagram. As the project is inspired by Agile

development methodologies, there will be no big design activity upfront. Instead, the

OOD will evolve as the construction phase proceeds. The development lead is respon-

sible to complement the ﬁnal source code delivery with a class diagram to describe the

OOD after-the-fact. Any project group that recognizes a value in using class diagrams

in their robot sales pitch are of course welcome to do so. Furthermore, the ﬁnal source

code deliverable shall be complemented by Javadoc documentation (excluding the test

code).

As most practical construction work will be done outside of scheduled sessions, how

the backbone of the programming will be conducted must be decided by the individual

project groups. Still, for this project, we recommend groups to follow a handful of well-

known Agile development practices, originally proposed as part of Extreme Programming

(XP). Below we list ﬁve that we believe are particularly suitable for the process model,

along with their Wikipedia deﬁnitions:

Pair programming All code is produced by two people programming on one worksta-

tion. One programmer has control over the workstation and is thinking mostly

about the coding in detail. The other programmer is more focused on the big

picture, and is continually reviewing the code that is being produced by the ﬁrst

programmer. Programmers trade roles after minute to hour periods. The pairs are

not ﬁxed; programmers switch partners frequently, so that everyone knows what

everyone is doing, and everybody remains familiar with the whole system, even

the parts outside their skill set. This way, pair programming also can enhance

team-wide communication and goes hand-in-hand with the concept of Collective

Code Ownership.

Continuous integration The development team should always be working on the latest

version of the software. Since diﬀerent team members may have versions saved

locally with various changes and improvements, they should try to upload their

current version to the code repository every few hours, or when a signiﬁcant break

presents itself. Continuous integration will avoid delays later on in the project

cycle, caused by integration problems, aka. “big bang integration”.

Code refactoring Restructuring existing code without changing its external behavior.

Refactoring improves quality attributes of the software, e.g., code readability,

performance, maintainability. Refactoring is often initiated when a so called “code

smell” is identiﬁed, i.e., structures in the code that indicate violation of fundamen-

tal design principles and negatively impact design quality.

Test-driven development Create unit tests before the eventual code is written. This ap-

proach is intended to stimulate the programmer to think about conditions in which

his or her code could fail. Test driven development proceeds by quickly cycling

through the following steps: 1) write unit tests, 2) run tests, watch them fail, 3)

write code, 4) run tests, watch them pass, and 5) refactor the code. Adhering to

test-driven development leads to a large set of test cases that can be automatically

executed, increasing developers’ conﬁdence when e.g. refactoring code.

Collective code ownership Everyone is responsible for all the code; therefore, every-

body is allowed to change any part of the code. Collective code ownership is not

only an organizational policy but also an attitude. Pair programming, especially

overlapping pair rotation, contributes to this practice: by working in diﬀerent

pairs, programmers better understand the system context and contribute to more

areas of the code base. Collective code ownership may accelerate development

because a developer who spots an error can ﬁx it immediately, which can reduce

bugs overall. However, programmers may also introduce bugs when changing code

that they do not understand well. Suﬃciently well-deﬁned unit tests should miti-

gate this problem: if unforeseen dependencies create errors, then when unit tests

are run, they will show failures.

The construction phase involves prototyping to quickly create a working robot. Pro-

totyping supports speciﬁcation activities by enabling early executable software – truly

beneﬁcial in contexts where the requirements are very unstable. Already at the end of

sprint 1, around the LU Robot Fair, the project group shall deliver a ﬁrst prototype of

the robot. The prototype will help the purchaser to understand your product vision,

and enable better feedback. The second deliverable shall be a Minimum Viable Product

(MVP) inspired by lean software development practices, i.e., a product with just enough

features to satisfy early customers and to stimulate feedback for future robot evolution

throughout Sprint 3.

As a result from the construction activities, each project group shall produce the

following deliverables. Each release shall be prepared as two jar-ﬁles: 1) one jar-ﬁle for

customers and 2) one jar-ﬁle with embedded source code for the regulatory body. As

previously stated, the ﬁnal release to the regulatory body shall be complemented by a

class diagram and Javadoc documentation, as further described in Section 3.2:

Sprint 1 Robot Alpha release (Robot v0.5) – A prototype

Sprint 2 Robot Beta release (Robot v0.9) – An MVP

Sprint 3 Robot Final release (Robot v1.0) – The ﬁnal robot

2.1.3 Veriﬁcation

All computer labs but the ﬁrst one will involve working with the JUnit framework for

automated testing. Project groups will work with unit testing as a natural companion to

the programming during development. While JUnit is designed for automated execution

of unit test cases, groups will also use JUnit for system testing of both functional and

non-functional (quality) aspects of the robot under development. Finally, groups will

learn to use measure code coverage and use static code analysis tools to support software

quality assurance.

The test lead is responsible for delivering three growing development artifacts during

the projects, as well as a ﬁnal test report at the ﬁnal release. First, a suite of automated

unit test cases shall evolve during the project. At sprint 1, an initial version shall

simply be executable, but at the ﬁnal release all source code shall be exercised by unit

tests. Second, a suite of automated system test cases shall be developed – an initial

version at sprint 2, and the complete suite with the ﬁnal release. Third, a Software Test

Speciﬁcation (STS) that describes the project group’s test and quality activities. At

sprint 3, all requirements in the SRS shall be veriﬁed either by test cases or targeted by

a convincing argumentation that the requirement has been veriﬁed through inspection.

Veriﬁcation activities are naturally supported by tools. Apart from the JUnit frame-

work, the project groups will use the Robocode framework RobotTestBed to automate

system testing, and EclEmma to measure code coverage. Furthermore, the project

groups will learn about source code quality assurance by running two static code anal-

ysis tools: SpotBugs and SonarLint. The tools automatically analyze the source code

from complementary quality perspectives.

The ﬁnal robot release shall be accompanied with a test report, signed by the test

lead, showing that all test cases have been executed – and all corresponding test verdicts.

The customer will surely expect that all test cases passed, i.e., that you provide evidence

that the entire SRS has been fulﬁlled by the ﬁnal robot. In addition to the test verdicts,

the test report shall contain appendices with extracted report from the code coverage

tool as well as the static code analysis tools.

As a result from the veriﬁcation activities, each project group shall produce the fol-

lowing deliverables, further described in Section 3.2:

Sprint 1 STS v0.5 – Initial document structure

Sprint 2 STS v0.9 – Unit testing and system testing partly speciﬁed

Sprint 3 STS v1.0 – A complete speciﬁcation (complemented by a signed test report)

2.1.4 Robot-to-Robot communication

Robots that extend TeamRobot can communicate with team members, as speciﬁed in the

Robocode API: http://robocode.sourceforge.net/docs/robocode/robocode/TeamRobot.html

Serializable objects can be sent between robots, e.g., point objects containing coordi-

nates, color objects to set uniform team colors, and message strings with orders from

the leader. The following three methods represent the backbone of robot communication.

Broadcasting message to all team members:

public void broadcastMessage(Serializable message)

Sending messages to one speciﬁc team member:

TeamRobot.sendMessage(String name, Serializable message)

When a robot receives a message, the following method is called:

onMessageReceived(MessageEvent)

The MessageEvent always contains the name of the sending robot and a speciﬁc mes-

sage. As stated above, the message can be instances of various classes. Please refer to

the Robocode Sample Team to see an example implementation, or refer to the ETSA02

GitHub repository.

The only type of communication that must be implemented by the robots entering

LU Rumble is team color – this is mandated by the Regulatory Body. During the LU

Rumble, all robots of the same team must share the same color scheme. With 10 robots

battling at the same time, it is critical to help spectators understand the action on the

battleﬁeld. This introduces one of the following regulatory requirements to all robots:

•For normal robots and droids:

“The robot shall set its color scheme upon request by a leader bot according to

ETSA02 RoboTalk v1.X.”

•For leader bots:

“The robot shall set its color scheme at the start of the battle, and request the

other team robots to follow suit according to ETSA02 RoboTalk v1.X.”

ETSA02 RoboTalk also speciﬁes a string-based communication protocol. Teams are

free to implement as much of the communication protocol as they ﬁnd useful. While it

is completely optional, it might be expected by potential customers on Robot Market.

Please refer to the classes MessageReader and MessageWriter on the ETSA02 GitHub

repository for an implementation suggestion. A message string should have the following

overall structure, including the new lines.

[0-1] leadership;[followMe|leadMe]

[0-1] teamMode;[offensive|defensive]

[0-1] myPos;x;y

[0-*] friendPos;name;x;y

[0-*] enemyPos;name;x;y

[0-*] enemyDetails;name;x;y;velocity;energy;heading;gunHeading

[0-1] bullet;x;y;absBearing;bulletPower

[0-1] targetEnemy;name

[0-1] targetPos;x;y

[0-1] moveTo;x;y

Example message:

teamMode;offensive

myPos;100;100

enemyPos;bot1;50;50

enemyPos;bot2;200;150

targetPos;50;50

The commands shall have the following meaning:

leadership Tells the receiving robot(s) that the sender takes on leadership (followMe)

or reports as a follower (leadMe).

teamMode Tells the receiving robot(s) that the team shall enter oﬀensive mode (oﬀen-

sive) or defensive mode (defensive).

myPos Tells the receiving robot(s) its current position on the 2D battleﬁeld.

friendPos Tells the receiving robot(s) the position of an identiﬁed robot in the same

team.

enemyPos Tells the receiving robot(s) the position of an identiﬁed enemy robot.

enemtDetails Tells the receiving robot(s) detailed information about an enemy robot.

bullet Tells the receiving robot(s) that a bullet has been ﬁred and details its trajectory.

targetPos Tells the receiving robot(s) to ﬁre at a speciﬁc position on the 2D battleﬁeld.

targetEnemy Tells the receiving robot(s) to target a speciﬁc enemy robot.

moveTo Tells the receiving robot(s) to move to a speciﬁc position on the 2D battleﬁeld.

ETSA02 RoboTalk might evolve during the course, i.e., the Regulatory Body will

possibly release new versions. All groups are welcome to provide feedback and requests

to the standardization work done by the Regulatory Body. To do so, the project manager

should submit a “Change Request” to the Regulatory Body. The Change Request should

carefully describe what changes are proposed, and motivate why this request should be

considered.

ETSA02 RoboTalk is version controlled, and student groups that decide to implement

communication should carefully specify in their SRS which version of the protocol is

implemented. For further details and a formal speciﬁcation, including both communica-

tion of color and string commands, refer to the latest version of ETSA02 RoboTalk on

Google Drive.

2.2 Monetizing the robot

One of the primary goals of the project is to maximize the proﬁt of the group, i.e.,

monetizing the robot. The business aspects of the project involves a combination of

bespoke software engineering and software engineering for an open market. All project

groups will oﬀer their robot on a highly competitive market – consisting of the other

groups, each with a e100 budget to invest in a robot team for the LU Rumble. The

monetization is split in two parts: 1) bespoke supplier-customer relationships and 2)

selling robots on Robot Market.

Figure 2.3: Example of seven purchase arrays submitted to the regulatory body.

2.2.1 Bespoke supplier-customer relationships

The project groups will market their Robot already at a robot fair already after Sprint

1. At this early point in time, only an Alpha release of the robot will be available and

an initial version of the SRS – still, the sales engineer is responsible for developing a

convincing sales pitch. All groups will get the chance to pitch their robot through a

two minute video at the robot fair, and also present it online on the Robot Market,

complemented by the most recent SRS.

After the robot fair, all project groups will submit a “purchase array” to the regu-

latory body. The purchase array consists of one element per group, and each element

should contain an integer representing how much your group is willing to pay for the

corresponding robot. You are not allowed to make an oﬀer for your own robot, and you

are not allowed to oﬀer less than e10 for any other robot. The purchase array should

be signed by the domain expert and delivered as a physical copy to the regulatory body

through the mailbox in “gr˚a sk˚apet”.

Figure 2.3 shows an example of purchase arrays submitted to the regulatory body.

The purchase arrays are never disclosed, the regulatory body matches project groups

into supplier-customer relationships. In the example, cells with bold text show winning

bids. Group D, highlighted with a white row, was particularly interested in Robots E,

F, and C – but unfortunately, other project groups oﬀered more. Group D instead got

to buy Robot B for e15. Note that the highest bid for a robot can be a tie, such as

for Robot A and G. In the case of Robot A, no project group oﬀered more than the

minimum e10, which resulted in a (possibly unexpected) bargain buy.

When all project groups have provided their purchase arrays, the regulatory body

will commence its work to establish supplier-customer relationships. For each robot, the

highest bidder turns into a customer of the group engineering the corresponding robot.

If there is a tie, the customer relationship will be assigned randomly. In the end, all

project groups will 1) pre-order a robot from a supplier, and 2) have a customer that

oﬀered at least e10 to pre-order a robot (the price of the cheapest basic bot). Note that

the decision of the regulatory body cannot be appealed.

Once robots have been pre-ordered, 25% of their costs will be transferred from the

customer to the supplier. This amount will not be refunded in any case – it represents

the risks of purchasing a robot from an external organization. The remainder of the cost

will be transferred at the delivery of the ﬁnal robot. After the ﬁnal delivery, the domain

Figure 2.4: Example of robot prices on the Robot Market, including bundle deals.

expert of the purchasing project group conducts acceptance testing of the robot. If the

acceptance testing shows that the delivered robot does not fully comply with the SRS,

the project manager of the purchasing group is entitled to ﬁle a business claim to the

regulatory body, further described in Section 4.1.

2.2.2 Selling robots on Robot Market

In the Post release phase (cf. Fig. 3.1, each project group will also oﬀer their robot on

the Robot Market. Simultaneously, all project groups will seek to complement the pre-

ordered (by now hopefully delivered) robot with additional robots to build a competitive

robot team for the LU Rumble. Throughout Sprints 2 and 3, the sales engineer is

responsible for promoting sales of the robot on Robot Market. Each group will also

set a price for its robot – a group must at least ask for as much as what the bespoke

customer has paid. Furthermore, project groups can (but are not required to) oﬀer robot

bundles to with discounts for buyers that purchase more than one robot, i.e., bundles of

two, three, or four robots. The total cost of each larger bundle most exceed the smaller

bundles. Note that the bundle options are not available for suppliers of leader bots, as

each team can ﬁeld only one leader robot.

Figure 2.4 shows an example of robot prices on Robot Market. Groups A and C

develop leader bots and are not allowed to oﬀer any bundle deals. Group E, highlighted

in the white row, oﬀers a single robot for e40 supplier of Robot E and the following

bundle deals: 2 robots for e60, 3 robots for e65, and four robots for e70. Group F

creates a bundle deal for two robots, but decides not to oﬀer special prices for three or

four robots. No bundle deals are available for the three ETSA02 basic bots. All groups

must set their prices on Robot Market no later than at L7 – no subsequent price updates

are allowed.

Figure 2.5 shows an example of how two project groups purchase robots. After the

robot fair, Group A strikes a deal with Group C for e55. As Robot C was quite costly,

Group A complements it with two cheaper Robot B droids in a e38 bundle deal to create

a team of three robots for LU Rumble. Robot B resulted from bespoke development for

Figure 2.5: Example of two project groups purchasing robots for their teams.

Group C – and they liked the result enough to buy two additional robots in a bundle

deal at the later Robot Market stage. Group C must pay the price of the 3x Robot B

bundle deal minus the price of a single robot (e56 - e20 – as they already bought one!).

Furthermore, Group C complements the cheap droids by two basic bots: a Basic Leader

Bot and a Basic Bot. Both Groups A and C spend e93 of their budgets. The remaining

e7 and e9 are counted towards the teams’ proﬁts, increasing their chances to win the

Most Proﬁtable Team award (see Section 3.4).

2.3 Strategizing to win the LU Rumble

The LU Rumble is a customized instance of a Robocode team rumble. Each project

group will compose a team of up to ﬁve robots that will compete together against other

robot teams. Each robot team must have one leader robot, which can be complemented

by normal robots or droids.

As in any rumble, the goal is to reduce the energy of enemy robots to 0. Team robots

will compete on a battleﬁeld until only one team is left. A standard robot starts with

100 energy and is equipped with a radar and a gun turret. Each time the gun is ﬁred,

the robot loses energy according to the payload. If the bullet does not hit any target,

the energy is lost. If the bullet hits another robot, energy is transferred from the hit

robot to the ﬁring robot.

Apart from the standard robots, there are two special types of robots. The leader robot

has an additional 100 energy compared the normal robot. Droids have an additional 20

energy, but are not equipped with radars.

At the end of Sprint 1, your project group will have established a relationship with

a robot supplier by pre-ordering either a leader robot, a normal robot, or a droid. The

supplier will provide you with a ﬁnal robot at the end of Sprint 3, but your group will

have a chance to inﬂuence the evolution of the robot during Sprints 2 and 3. The domain

expert in your group is responsible for developing a strategy around the robot you have

pre-ordered – to guide your feedback, you will receive two prototypes for evaluation: an

Alpha release after Sprint 1, and a Beta release after Sprint 2.

At the end of Sprint 3, you will complement the robot you have ordered with other

robots from the Robot Market. The goal of your strategizing is to identify and purchase

additional robots that can successfully cooperate with the robot from your supplier. It

is important to keep an eye on the Robot Market during Sprints 2 and 3, both to ﬁnd

the best robots to purchase, and to understand what type of features you should provide

through your own robot under development. Note that three robots are always available

at ﬁxed prices: 1) Basic Leader Bot e20, 2) Basic Bot e15, and 3) Basic Droid e10.

Each robot team must adhere to two strict constraints:

1. Each team must consist of between one and ﬁve robots, including one leader robot.

2. Each team must not exceed a total cost of more than e100 worth of robots.

After the acceptance testing, concluding with acceptance test reports and potential

business claims at L7, the regulatory body will convene and decide if any bespoke cus-

tomer should pay less than the total price initially agreed upon. Once all business claims

have been settled, all groups will know if they receive any money back – remember that

even if no ﬁnal robot is delivered, not more than 75% of the initial price will be returned.

Soon after the claims have been settled, the domain experts of all student groups shall

hand in their ﬁnal signed purchase order in “gr˚a sk˚apet” at L8. Note that all groups

must also immediately request the supplier of their leader robot which color scheme it

should communicate to the rest of the team. Note that there is not much time between

L8 and the LU Rumble – this must be given the highest priority for both domain ex-

perts and development leads! Furthermore, if a team purchases the Basic Leader Bot,

the requested color scheme must be requested from the course responsible.

3 Project phases

3.1 Project inception

The ﬁrst week of the project is referred to as the project inception. The project inception

phase is dominated by project group development, i.e., forming groups, assigning roles,

and aligning goals and expectations.

According to a well-known model of group development, proposed by Tuckman already

in 1965, four distinct phases are all necessary and inevitable for a group of people to

face up to challenges, collaborate successfully, and to deliver results. Being aware of the

four phases might accelerate the less productive phases and mitigate group conﬂicts:

1. Forming The group meets and learns about the project and the required activities.

In the beginning, individuals tend to behave quite independently – all trying to

comprehend what is about to happen. Individuals might be motivated and on their

best behavior, but typically the understanding and expectations vary considerably.

In the project, groups will be established already during the break in the ﬁrst

lecture, i.e., before lunch the very ﬁrst Monday. The individual group members

are expected to read the project instructions carefully as early as possible.

2. Storming After a while, some disagreements and personality clashes are likely to

emerge within the group. People are people, and people are diﬀerent. Tolerance

of each group member should be emphasized, otherwise the group will fail or rely

on individual “hero eﬀorts”. This phase can become destructive to the group,

and some teams will never develop past this stage. On the other hand, settling

disagreements within the team can make members stronger, more versatile, and

able to work more eﬀectively together. Note that some groups never enter this

stage at all, i.e., transitions directly from forming to norming are possible.

In the project, the supervisors and the regulatory body will be particularly re-

sponsive to questions and clariﬁcations during the ﬁrst week. Also, the group

communication will be kick-started by two physical meetings soon after the for-

mation, i.e., exercise sessions on Wednesday and Thursday the ﬁrst week.

3. Norming Resolved disagreements and personality clashes lead to a spirit of co-operation

– this typically happens when the group becomes aware of the external competition

and share a common goal. In this stage, all group members take the responsibility

and agree to work for the success of the common goal. The group members accept

others as they are and make an eﬀort to move on.

Figure 3.1: The ETSA02 process model, organized in three sprints.

In the project, the ﬁrst week concludes with assigning roles within the group, see

Section 5.1. All members of the group will also sign a collaboration contract,

specifying the roles, and the intentions to collaborate successfully. The contract

will be submitted to the regulatory body through “gr˚a sk˚apet”.

4. Performing When the group norms and roles have been established, focus is shifted

to achieving common goals. However, groups might revert to earlier circumstances

in certain circumstances, e.g., unexpected events, emerging personal conﬂicts, or

changing leadership. In the project, the goal is of course to remain in the perform-

ing stage until the LU Rumble!

3.2 Process model

The process model describing the product development encompasses three sprints, each

with a separate set of deliverables.

3.2.1 Sprint 1

The ﬁrst sprint overlaps with the project inception as the groups will start working on

robot development already at the ﬁrst exercise sessions in the ﬁrst week. The high-

level goals of Sprint 1 are to successfully do: 1) feature scoping, 2) robot prototyping,

and 3) developing a sales pitch. This means that the project group will be focused on

engineering and monetizing during Sprint 1. Some strategizing will also occur, as the

domain expert will purchase a robot from a supplier after the Robot Fair.

The ﬁrst steps of the requirements engineering involves analyzing what type of robot

would be in high demand by the other project groups. This type of market analysis is

no easy task to conduct, and surely the requirements engineer will discuss intensively

with the domain expert and the sales engineer. Engineering a software product means

making a series of successful technology and business decisions, and already during Sprint

1 the project group needs to set the direction for the engineering department. High-level

requirements are referred to as features, and the task of deciding which features to

implement in the product is called feature scoping. At the end of Sprint 1, SRS v0.5

should specify the features the group intends to implement in their robot. The features

should be promising enough to generate good oﬀers by other project groups, but do not

promise too much (aka. “over scoping”) – if you do not deliver a robot that fulﬁls the

speciﬁcation in the ﬁnal release, your customer will most likely ﬁle business claims to

the regulatory body! On the other hand, the SRS v0.5 is not carved in stone. There

will be negotiations during Sprints 2 and 3, and if both the customer and the regulatory

body accept your change requests, you can both modify and remove features later – and

adding new features is of course always possible.

A central part of the engineering in Sprint 1 is the robot prototyping, an activity

that serves two main purposes. First, it helps your project group experiment with

diﬀerent candidate features for the robot under development. There is no better way to

learn the Robocode domain than by practically implementing diﬀerent approaches and

evaluating them. Second, the prototyping will lead to an Alpha version of the Robot.

The customer will obtain the Alpha release, which will enable much richer feedback than

an SRS alone. To ensure that testing is part of the development process from the start,

Sprint 1 will introduce unit testing in the second week.

The marketing concept is the strategy that an organization implements to satisfy cus-

tomers needs, increase sales, maximize proﬁt, and beat the competition. The customers’

focus and values are the routes to achieve sales and maximize proﬁts. In the project,

the marketing concept is a customer-centered “sense and responds” philosophy. Your

project group’s job is not to ﬁnd the right customers for your robot, but rather to ﬁnd the

right robot for your customers – ﬁrst for the long-lasting supplier-customer relationship,

and later through the Robot Market. At the end of Sprint 1, the course will organize a

Robot Fair. Each group will get a 2 minute slot to pitch their product through a video.

All project groups will also have a folder to showcase promotion material on a “Display

window” Google Drive folder shared with all groups.

Table 3.1 shows the resulting deliverables from Sprint 1, their receivers, the responsible

roles, and when they are due.

Table 3.1: Deliverables due after Sprint 1, i.e., the Alpha Release.

Deliverable Receiver Responsible

role

When?

Lean canvas (latest ver-

sion)

Supervisor Project man-

ager

L3: Apr 16 - 12.00

SRS v0.5 Customer+

Supervisor

Requirements

engineer

L3: Apr 16 - 12.00

Robot Alpha version Customer+

Supervisor

Development

lead

L3: Apr 16 - 12.00

STS v0.5 Customer+

Supervisor

Test lead L3: Apr 16 - 12.00

Sales pitch + promotion

folder

Course re-

sponsible

Sales engineer L2: Apr 12 - 23.59 (before

Robot Fair!)

Purchase array “Gr˚a

sk˚apet”

Domain expert L4: Apr 17 - 23.59 (after

Robot Fair!)

To support Sprint 1, the following sessions are scheduled:

•Lecture 1: Robocode, Requirements engineering

•Lab 1: Robot development in Eclipse

•Exercise 1: Product planning

•Lecture 2: Unit testing, git, object-oriented design

•Lab 2: Refactoring and JUnit

•Exercise 2: Marketing communications

3.2.2 Sprint 2

In Sprint 2, the project group should be up to speed both regarding engineering and

monetizing. Now the monetizing will decrease and the strategizing will increase in its

place. The high-level goals of Sprint 2 is to: 1) evolve the robot, 2) maintain the customer

relationship, and 3) develop a strategy for the LU Rumble.

In Sprint 2, you will have an established customer who has received your Robot Alpha

release. As that project group will be keen to win the LU Rumble, you will likely get

feedback that they believe will guide your development to a successful robot. During

the remainder of the project, maintaining a healthy customer relationship is critical.

Your sales engineer is the main point of contact with the customer.

Based on your customer’s feedback, your own vision – and possibly some negotiation

in between – you will evolve the robot during Sprint 2. The features will be broken

down into detailed requirements, and the STS will be elaborated to also cover system

testing. At the end of Sprint 2, you will deliver Robot Beta release to your customer,

Table 3.2: Deliverables due after Sprint 2, i.e., the Beta Release.

Deliverable Receiver Responsible

role

When?

Lean canvas (latest ver-

sion)

Supervisor Project man-

ager

L5: Apr 27 - 23.59

SRS v0.9 Customer+

Supervisor

Requirements

engineer

L5: Apr 27 - 23.59

SRS review protocol Supervisor Requirements

engineer

L5: Apr 27 - 23.59

Robot Beta version

(MVP)

Customer+

Supervisor

Development

lead

L5: Apr 27 - 23.59

STS v0.9 Customer+

Supervisor

Test lead L5: Apr 27 - 23.59

constituting an MVP, i.e., a minimal product that still brings some value. To be in a

good position for the next sprint, the project group should try to let the lean canvas,

SRS, source code, STS, and marketing concept co-evolve – otherwise they might diverge

considerably, increasing the risk of a dissatisﬁed customer, wasted eﬀort within your

group, and reduced sales on the Robot Market. Make sure that any changes you make

to the SRS are traceable, i.e., make sure there is a “paper trail”, in case the regulatory

body needs to settle business claims from your customer at a later stage. Signiﬁcant

changes to the SRS must be done in agreement with the customer and documented. If

the supplier organization does not store a chain of evidence, the regulatory body is likely

to side with the customer in legal contentions.

Finally, you will develop a ﬁrst draft of your Rumble strategy. The cornerstone

of your robot team will be the robot you pre-ordered. Your domain expert will be

responsible for communication with your supplier’s sales engineer. Just like your project

group should be responsive to your customer, your supplier should respond to your

requests.

Table 3.2 shows the resulting deliverables from Sprint 2, their receivers, the responsible

roles, and when they are due.

To support Sprint 2, the following sessions are scheduled:

•Lecture 3: Black-box testing, software architecture

•Lab 3: Automated system testing with RobotTestBed

•Exercise 3: Requirements speciﬁcation

•Lecture 4: Project planning, document reviews

•Lab 4: Code coverage, static code analysis, Javadoc

•Exercise 4: Individual SRS review, review meeting

3.2.3 Sprint 3

In Sprint 3, the project group shall conclude and tie up all activities. The engineering

should lead to a successful robot, the monetizing should ensure that it is well-received

on the market, and the strategizing shall ﬁnalize the robot team shall be competitive

in the upcoming LU Rumble. The high-level goals of Sprint 3 are to: 1) complete the

product, 2) generate high-volume sales, and to 3) optimize the Rumble strategy.

The engineering department will be busy implementing the remaining requirements

and putting the ﬁnishing touches to the robot. This means completing the product

and preparing the Robot Final release. When the Final Robot is released, it is impor-

tant that the lean canvas, SRS, STS, and the marketing concept are all aligned. Your

customer will perform acceptance testing of your robot – rest assured that they will

scrutinize your deliverables to identify any discrepancies. The customer will be greatly

motivated to assure that the Robot Final release complies with the SRS – their entire

robot team for the LU Rumble might rely on it! If the customer is not satisﬁed, the

regulatory body is likely to receive a business claim based on their acceptance testing.

However, your project group will provide the regulatory body with evidence that every-

thing in the SRS has been veriﬁed by providing a complete test report based on STS

v1.0.

The sales department will keep active communications with the customer, to make

sure the ﬁnal engineering eﬀorts adhere to their expectations. Close communication

with the customer will reduce the risks of incoming business claims. However, the sales

engineer will also focus considerable eﬀort on the robot oﬀering on Robot Market – trying

to make the robot as attractive as possible on the open market, i.e., the sales engineer

will maintain the Robot webpage with the intention to generate high-volume sales.

The purchasing department will keep a close eye on the engineering eﬀorts of the

supplier. After all, this is the supplier’s last chance to deliver the robot that has been

speciﬁed in the SRS. At the same time, your domain expert will analyze the Robot

Market to make a ﬁnal decision of your robot team composition, i.e., optimizing the

Rumble strategy.

Table 3.3 shows the resulting deliverables from Sprint 3, their receivers, the responsible

roles, and when they are due.

To support Sprint 3, the following sessions are scheduled:

•Implementation support (“Kod-jour”)

•Lecture 5: Development processes

3.3 Post release

The phase following the process model is referred to as post mortem. In this phase, your

project group will perform acceptance testing of your supplier’s Robot Final release. If

the acceptance testing identiﬁes ﬂaws, you will ﬁle business claims to the regulatory body

– possibly deducting from the total payment. Furthermore, after settling the business

Table 3.3: Deliverables due after Sprint 3, i.e., the Final Release.

Deliverable Receiver Responsible

role

When?

Lean canvas (ﬁnal ver-

sion)

Supervisor Project man-

ager

L6: May 11 - 23.59

SRS v1.0 Customer+

Supervisor

Requirements

engineer

L6: May 11 - 23.59

Robot Final version Customer+

Supervisor

Development

lead

L6: May 11 - 23.59

STS v1.0 Customer+

Supervisor

Test lead L6: May 11 - 23.59

Table 3.4: Deliverables due after Sprint 3, i.e., the Final Release.

Deliverable Receiver Responsible

role

When?

Fixed Robot Market

prices

Robot Mar-

ket

Sales engineer L7: May 15 - 23.59

Acceptance test report Supervisor Domain expert L7: May 15 - 23.59

Business claims (op-

tional)

Course re-

sponsible

Project man-

ager

L7: May 15 - 23.59

Purchase orders and

team composition

Course re-

sponsible

Domain expert L8: May 17 - 23.59

claims, the domain expert will submit the ﬁnal purchase orders to the regulatory body,

i.e., the robot team composition for the LU Rumble will be ﬁnalized.

Table 3.4 shows the resulting deliverables from the post release phase, their receivers,

the responsible roles, and when they are due.

To support the post release phase, one session is scheduled:

•Lecture 6: Conﬁguration management, software product lines

3.4 LU Rumble

The ﬁnal phase consists of one single event: the LU Rumble. The LU Rumble will take

place during the ﬁnal lecture of the course on May 20, 2019. LU Rumble will follow a cup

pairing according to single elimination knockout rules, see Figure 3.2. All robot teams

will enter the bracket at random. LU Rumble will also have a third place playoﬀ match.

Each match in the LU Rumble will be played in a best-of-ﬁve format, and displayed live

at reasonable speed for the entertainment of the spectators. Standard rules for Robocode

team matches will apply on a 1200x1200 battleﬁeld.

Immediately after the LU Rumble, three awards will be given:

Figure 3.2: The LU Rumble bracket. In addition, there will be a third place playoﬀ

match.

•The Strategizer Award goes to the student group that won the LU Rumble.

•The Monetizer Award goes to the most proﬁtable student group. The proﬁt is

calculated as income from robot sales plus any money left from the initial e100

budget.

•The Engineering Award goes to the most valuable robot during LU Rumble. The

robot’s value will be calculated as the total score of all robot instances during the

LU Rumble, divided by the (non-zero) number of robot appearances (each round

a robot instance enters the battle is counter as one appearance).

4 Inter-group communication

To be written...

4.1 The regulatory body

To be written...

Formal document templates:

•Contract of sale between supplier and customer

•Purchase order for Robot Market

•Business claims

4.2 Maintaining supplier-customer relations

To be written...

What to do and what not to...

Guidelines for suppliers:

•The customer is always right

•Do not sacriﬁce the chance to succeed on the open market

•Be open to new ideas from the customer.

•Embrace change – it is inevitable anyway.

•Negotiate nicely.

Guidelines for customers:

•Accept what you’ve pre-booked.

•Do not provide feedback that deviates from the original vision of the robot.

•Be open to alternative solutions proposed by the supplier.

•Negotiate nicely.

4.3 Group conﬂicts

To be written...

5 Detailed instructions

This section presents some aspects of the course in detail: 1) the roles you should

assign within the project group, 2) expectations on the deliverables, and 3) the course

infrastructure.

5.1 Role assignment

During the course, all students are expected to contribute to all activities. The purpose

of the roles is not to isolate work tasks that could be individually completed. Software

engineering is a collaborative eﬀort, and completing work tasks in isolation is not part of

a scalable methodology. Instead, we stress the value of “collective ownership” during the

project, not only for the source code as described in Section 2.1.2, but for all artifacts

produced.

The purpose of assigning roles in the project is to comply with the ETSA02 course

description regarding “judgment and approach”, i.e., understanding that software engi-

neering is a complex endeavor involving several diﬀerent roles, and that working as a

software engineer might result in a variety of roles in an organization. Second, all roles

with be responsible for some deliverables. The regulatory body will use the group mem-

ber with the corresponding role as the primary point of contact in case any deliverable

is missing or critically incomplete.

As the project progresses through phases and sprints, diﬀerent roles with have diﬀerent

expectations. The project group will track the variation through weekly time reporting,

submitted by the project manager to the regulatory body. The reported ﬁgures should

be complemented by a qualitative analysis of the causes, and the project manager is

responsible for balancing the workload to make sure the contributions are comparable,

see 5.2 for further information. Below are the diﬀerent roles, ordered alphabetically:

Development lead Design, implementation, source code quality. Assign a group mem-

ber comfortable with the art and science of programming. – jar_v0.5,jar_v0.9,

jar_v1.0

Domain expert Mastering Robocode, LU Rumble strategy, supplier communication,

negotiations, acceptance testing. The domain expert needs to be willing to learn

about the game aspects of Robocode, thus pick your gamer. – Signed contract (as

customer), acceptance test report, team jar-ﬁle

Project manager Coordination, time reporting, communication with the regulatory

body. Identify a group member with leadership skills willing to shoulder over-

all responsibilities. – Weekly time reports with reﬂections, business claims (based

on failed acceptance test)

Requirements engineer End-user perspective, feature scoping, detailed requirements.

A requirements engineer bridges engineering and business, identify a generalist. –

SRS v0.5, SRS v0.9, SRS v1.0

Sales engineer Marketing, sales pitch, customer communication, negotiations. Identify

your natural salesman, a person with excellent communication skills. – Sales pitch,

signed contract (as supplier)

Test lead Test strategy, unit testing, system testing. Suitable for an individual with an

eye for details. – Unit tests, STS v1.0 (incl. test code), test results

5.2 Time reporting

To be written...

Report time per role on a weekly basis. Reﬂect on the ﬁgures after each sprint. Plan

changes if needed to better balance the work load.

5.3 Software Releases: Alpha, Beta, and Final

The robot shall be released after each development sprint, each time constituting a more

mature software product. In ETSA02, you shall create each software release in two

variants: 1) a customer release and 2) a regulatory body release. Groups will upload

their releases in designated folders on Google Drive.

The customer release shall contain the latest versions of the following:

•SRS

•Robot packaged as a jar-ﬁle – without source code!

•STS

•Optional: Release notes – if you want to clarify anything related to the release.

Simply create a text ﬁle called ReleaseNotes_vX.txt and replace X with 0.5, 0.9,

or 1.0.

The regulatory body release shall contain everything in the customer release, but

also the latest version of the following artifacts:

•Lean canvas

•Robot packages as a jar-ﬁle – including source ﬁles!

•Class diagram (excluding test code)

•Javadoc (excluding test code)

•A review protocol from the review meeting at Exercise 4 (only for the Beta release)

6 Expectations per deliverable

This section brieﬂy explains what is expected of the various deliverables.

Collaboration contract The ﬁrst deliverable is a contract signed by all group members,

stating agreed upon collaboration rules and the role assignment within the group.

Sales pitch A video pitch to be played at the Robot Fair, not longer than 2 min. The

video shall be recorded in a standard video format, but you are free to choose the

structure and content. For example, you can choose whether to record yourself

speaking, a screencast, or a mix of both. The sales pitch shall communicate your

message, you are not supposed to complementing it during the Robot Fair with

live talking. You are of course no allowed to include any oﬀensive or illegal content

in the marketing communications. You will also get a shared folder on Google

Drive which you can use freely to promote your sales – be creative!

SRS The software requirements speciﬁcation shall be delivered in three versions. Each

version should be a more mature speciﬁcation of the robot under development.

v0.5 A skeleton of an SRS adhering to the provided template. The main features

that will be implemented shall be listed.

v0.9 The features shall be broken down into detailed requirements.

v1.0 A ﬁnal SRS that provides a complete speciﬁcation of the robot.

SRS review protocol The review meeting at Exercise 4 will result in a formal review

protocol according to the provided template. The protocol shall report all issues

that were identiﬁed during individual reviews, and also estimate the number of

remaining issues based on the capture-recapture method.

The robot The robot shall be released in three versions: Alpha, Beta, and Final. The

lead developer shall each time package the robot as jar-ﬁles using the Robot Pack-

ager in Robocode, in two diﬀerent versions per release: 1) without source ﬁles

for the customer, and 2) including source ﬁles for the supervisor. The source

code shall be maintainable, e.g., well-structured, commented, and using suitable

variable names.

Alpha An early prototype of the robot. No expectations regarding features, but

the customer shall be able to ﬁeld it in a Robocode battle.

Beta A minimum viable product (MVP), i.e., a robot with just enough features

to satisfy your customers.

Final A polished robot, ready for LU Rumble.

Class diagram The object-oriented design shall be documented in a UML class diagram.

You can use any tool to create the diagram, either a tailored UML tool or a

standard drawing tool – you can even scan a pen and paper sketch or take a

picture of a whiteboard drawing.

Javadoc The robot source code shall be documented and packaged using the standard

Javadoc tool.

STS The document shall describe how the group uses testing to increase the quality of

the robot, i.e., what measures are taken to decrease the risk of releasing a product

with bugs. Furthermore, system test cases used to verify that the SRS is completed

shall be speciﬁed.

v0.5 An initial STS skeleton adhering to the provided template.

v0.9 A fairly complete draft of the STS, partly specifying unit testing and system

testing.

v1.0 A ﬁnal STS that speciﬁes a trustworthy veriﬁcation of the SRS.

Test report The ﬁnal release shall be accompanied by a test report that shows the

result of executing the STS. The test report shall follow the structure in the STS

Appendix.

Purchase array The purchase array shall specify valid oﬀers for all other groups robots

and be signed by the domain expert.

Robot Market prices The groups shall specify the price of their robot on Robot Market,

and also any bundle deals.

Acceptance test report When the ﬁnal release of another group’s robot has been re-

ceived, you shall test it to see if it complies with its SRS. You shall write an

acceptance test report clearly stating how you tested the robot and what the re-

sults were. You are free to choose any format for this deliverable.

Business claims This is an optional deliverable that you can send to the regulatory

body. If you are not satisﬁed with the ﬁnal release you received from another

group, you can argue for your case in a written business claim. You are free to

choose any format for the deliverable.

6.1 Project infrastructure

To be written...

The following infrastructure is central during the project:

SRS template

Slack workspace

Contract templates

Collaboration contract

Contract of sales

Time reporting

Robot team composition sheet

Project Instructions For The LU Rumble

Navigation menu

Versions of this User Manual:

Views

Navigation