1

Software Engineering II - Exercise

Bernd Bruegge Helmut Naughton

Applied Software Engineering Technische Universitaet Muenchen

http://wwwbrugge.in.tum.de

May 6th 2009

Problem Statement

2

Some organizational things

•  Date for the final exam •  Wednesday, August 5th 2009

Place: MW 1350 Time: 8.30 - 10.30

•  Trying to reschedule to July 30th in the afternoon

•  The lecture on May 12th will take place as usual (contrary to the tentative timetable) •  Subject will again be testing

3

Comments on the SPMP assignment

•  The focus of this exercise is on understanding and getting familiar with •  The structure of an SPMP •  The content creation process •  Positioning of SPMP within the project lifecycle

•  Quality is more important than raw quantity •  There is no minimum or maximum page count •  If something does not make sense for your chosen

project or you really cannot find any information then enter “not applicable” or “to be done” in the SPMP section

•  Some sections make sense and can be meaningfully filled for any type of project – these are of high value

•  The aim is to produce a document that is in itself consistent and also in line with the project.

4

Comments on the SPMP assignment

•  If you base your SPMP on a real-world project, make sure to •  Try to recreate the circumstances the project was

conducted in and learn from them (“Archaeologist”) •  Write the SPMP as if you were competing for the

contract and had to write a better plan than your competition (“Entrepreneur”)

•  The second aspect is also true for projects which are not based on a real-world counterpart

•  Write the SPMP as if you are trying to convince a potential customer to award you the contract.

5

Comments on the SPMP assignment

•  A quick reminder of the parameters: •  You can work in teams with up to 6 participants •  Submission date is July 1st 2009, 2PM •  Oral presentation of these plans on July 1st 2009 in the

exercise session •  Completing the SPMP assignment is part of the

exercises and therefore required for taking part in the final exam

•  Excellent solutions and presentations will also be reflected in the final grade

6

Outline

•  Problem Statement •  Functional Requirements •  Nonfunctional Requirements •  User Interface •  Object Model •  System Decomposition •  Deployment

7

Problem Statement

•  The problem statement is developed as a description of the problem addressed by the system

•  A problem statement describes •  The current situation •  The objectives •  The functionality the new system should support •  The environment in which the system will be deployed •  Deliverables expected by the client •  Delivery dates •  A set of acceptance criteria.

8

Problem Statement

•  When do we write the problem statement? •  Before the project kickoff

•  What purpose does the problem statement serve? •  Better understand the scope and parameters of the project •  Parts of the problem statement serve as seed for

•  A first draft of the project plan itself (SPMP) •  The requirements analysis document

(RAD, “Lastenheft”) •  The system design document (SDD) •  The object design document (ODD)

•  Who writes the problem statement? •  Plan A: The customer •  Plan B: The customer and the project manager •  Plan C: You

9

Comparison: Lastenheft - Pflichtenheft

•  Lastenheft: DIN 69905-VDI/VDE 3694 - VDA 6.1: Gesamtheit der Forderungen des Auftraggebers an die Lieferungen und Leistungen eines Auftragnehmers.

•  Pflichtenheft: DIN 69905-VDI/VDE 3694 - VDA 6.1: Vom Auftragnehmer erarbeitetes Realisierungsvorhaben aufgrund der Umsetzung des Lastenheftes.

How do these terms map to our documents from the textbook? (see german translation p. 178.) How do these terms map to internationally used concepts?

10

Standards for requirement specification

•  Is there an international standard for it? •  IEEE Std 830-1998 IEEE Recommended Practice

for Software Requirements Specifications

•  This standard combines both documents into one and is common for many software projects

11

NASA has its own concepts

•  How does NASA do it? •  Two parts:

“system requirements” and “design-to specification” •  The first is written by the client and contains mission

requirements and basic parameters (e.g. http://mars.jpl.nasa.gov/mgs/scsys/e3/e30.html for the Global Mars Surveyer)

•  The second is written by the contractor and specifies the chosen design

•  Correspondence between NASA documents and documents used in the textbook •  „system requirements” → RAD (requirements analysis document) •  “design-to specification” → SDD (system design document)

maybe even including parts of the ODD (object design document)

12

Ingredients of a Problem Statement 1.  Current situation

•  The problem to be solved •  Description of one or more scenarios

2.  Objectives 3.  Requirements

•  Functional and nonfunctional requirements •  Constraints (“pseudo requirements”)

4.  Target environment •  The environment in which the delivered system has to

perform a specified set of system tests

5.  Project schedule •  Major milestones including deadline for delivery

6.  Client acceptance criteria •  Criteria for the system tests.

13

Current situation: The problem to be solved

•  There is a problem in the current situation •  Examples:

•  The response time when playing chess is too slow. •  I want to play Go, but cannot find players on my

level.

•  What has changed? Why can address the problem now? •  Change in the application domain

•  A new function (business process) is introduced into the business

•  Change in the solution domain •  A new solution (technology enabler) has appeared

14

ARENA: The Current Situation

•  The Internet has enabled virtual communities •  Multi-player computer games now include support

for virtual communities •  Players can receive news about game upgrades, new

game levels, announcement of matches and scores

•  Currently each game company develops such community support in each individual game •  Each company uses a different infrastructure, different

concepts, and provides different levels of support

•  This redundancy leads to problems: •  High learning curve for players joining a community •  Game companies develop the support from scratch •  Advertisers contact each community separately.

15

ARENA: The Objectives

•  Provide a generic infrastructure to •  Support virtual game communities. •  Register new games •  Register new players •  Organize tournaments •  Keeping track of the players scores.

•  Provide a framework for tournament organizers •  to customize the number and sequence of matchers

and the accumulation of expert rating points.

•  Provide a framework for game developers •  for developing new games, or for adapting existing

games into the ARENA framework.

•  Provide an infrastructure for advertisers.

16

ARENA: The Objectives (2)

•  Provide a framework for tournament organizers •  to customize the number and sequence of

matchers and the accumulation of expert rating points

•  Provide a framework for game developers •  for developing new games, or for adapting

existing games into the ARENA framework

•  Provide an infrastructure for advertisers.

17

ARENA Functional Requirements

•  Players must be able to register for and play their favorite games

•  Spectators must be able to watch matches in progress without prior registration and without prior knowledge of the match

•  The operator must be able to add new games.

18

ARENA Nonfunctional Requirements

•  The system must support •  10 parallel tournaments, •  Each involving up to 64 players •  and several hundreds of spectators. •  The ARENA server must be available 24 hours a day

•  The operator must be able to add new games without modifications to the existing system •  ARENA must be able to dynamically interface to

existing games provided by other game developers.

19

Constraints

•  Constraint: Any client restriction on the solution domain and project management •  Sometimes also called Pseudo Requirements •  Constraints restrict the solution space

•  Example of constraints •  Delivery constraints (“must be delivered before

Christmas”) •  Organizational constraints (“must have a separate

testing team”) •  Implementation constraints (“must be written in

Cobol”) •  Target platform constraints (“must run on Windows

98”)

20

ARENA Target Environment

Example: •  Users must be able to run ARENA games as

applets in any Web Browser •  The web page must be validated through the W3C

Markup Validation Service •  Interaction with the ARENA Server must be via HTTP/1.1.

To be distinguished from development environment •  “Prototypes will be built with Revolution 2.6.1” •  “Games will be tested with Internet Explorer and

Firefox” •  “The implementation language will be Java 1.6” •  “The IDE will be Eclipse 3.5”

21

Project Schedule

•  The project schedule is an optional part of the problem statement •  Managerial information •  Often the seed for the schedule in the software project

management plan.

•  Lists only major milestones negotiated with the client •  3 to 4 dates (fixed dates!)

•  Example: •  Project-kickoff April 15 •  System review May 15 •  Review of first prototype Jun 10 •  Client acceptance test July 30

22

Client Acceptance Criteria

•  The system supports 10 parallel tournaments with 64 players and 10 spectators per tournament

•  The client supports the games Tic-Tac-Toe and Asteroids

•  The average response time for a command issued by a client is less than 10 msec

•  The average up-time of the ARENA server during one week of testing is 95%.

23

Reflections on the OWL problem statement

•  Pro •  You can get the basic idea of the project quickly

•  Con •  Probably better not include object diagram •  Not enough specifics, constraints •  No short abstract •  No (rough) time plan •  Team structure does not need to be in here •  In parts maybe already too specific •  No explicit mention of deliverables

24

Further steps

•  Subsystem Decomposition •  Object Model •  Test configuration •  User Interface of Client •  User Interface of Server

25

ARENA Subsystem Decomposition

Tournament

Component Management

User Management

Tournament Statistics

User Directory

User Interface

Session Management

Advertisement

26

ARENA Object Model (application domain)

Tournament

League

Game

Tournament Style

Player

Round

Match

KOStyle

RoundRobin

27

ARENA Object Model (with solution domain objects)

Tournament

League

Game

TournamentStyle

Player

Round

Match

TicTacToe

Asteroids KOStyle

RoundRobin

Move MatchPanel

Factory MatchPanel creates

28

Configuration for Client Acceptance Test (Instance-Diagram)

29

ARENA User Interface (Client)

30

ARENA User Interface (Server)

31

More Information on ARENA

•  The ARENA Website: http://sysiphus.in.tum.de/arena

•  The ARENA case study is described at the end of each chapter of the textbook, starting with Chapter 4.

•  Read Chapter 4.6

32

Research and Access to Publications

•  Most online publications (IEEE, ACM) are only available for a fee

•  TUM students can use the DocumentWeb service provided by the LRZ •  http://docweb.lrz-muenchen.de/ •  Login with your mytum account

•  Alternatively •  Proxy: http://proxy.biblio.tu-muenchen.de Port: 8080 •  Only usable in Garching or via VPN

33

Research and Access to Publications

•  Useful search tools: •  http://ieeexplore.ieee.org/search/advsearch.jsp •  http://portal.acm.org/results.cfm •  http://scholar.google.com •  http://citeseerx.ist.psu.edu

•  Collect, manage, and cite your research sources: •  http://www.zotero.org •  http://www.endnote.com