Software Engineering II - Exercise · Standards for requirement specification ... • Game...
Transcript of Software Engineering II - Exercise · Standards for requirement specification ... • Game...
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