Software Engineering II - Exercise May 6 th 2009 Problem Statement Bernd Bruegge Helmut Naughton Applied Software Engineering Technische Universitaet Muenchen http://wwwbrugge.in.tum.de 1
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 30 th in the afternoon The lecture on May 12th will take place as usual (contrary to the tentative timetable) Subject will again be testing 2
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. 3
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. 4
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 1 st 2009, 2PM Oral presentation of these plans on July 1 st 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 5
Outline Problem Statement Functional Requirements Nonfunctional Requirements User Interface Object Model System Decomposition Deployment 6
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. 7
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 8
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? 9
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 10
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) 11
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. 12
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 13
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. 14
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. 15
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. 16
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. 17
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. 18
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 ) 19
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 20
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 21
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%. 22
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 23
Further steps Subsystem Decomposition Object Model Test configuration User Interface of Client User Interface of Server 24
ARENA Subsystem Decomposition User Interface Advertisement Tournament User Management Component Management User Directory Session Management Tournament Statistics 25
ARENA Object Model (application domain) Game League Tournament Style Tournament Round KOStyle RoundRobin Player Match 26
ARENA Object Model (with solution domain objects) Game TicTacToe Asteroids League Tournament Round TournamentStyle KOStyle RoundRobin Player Match Move MatchPanel Factory creates MatchPanel 27
Configuration for Client Acceptance Test (Instance-Diagram) 28
ARENA User Interface (Client) 29
ARENA User Interface (Server) 30
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 31
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 32
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 33