Introduction 2IM24/2IM25

Introduction 2IM24/2IM25 • Erik Luit Nicola Zannone MF 6.071B MF 6.064 4338 2646 e.j.luit@tue.nl n.zannone@tue.nl • Website 2IM24/2IM25: www.win.tue.nl/2IM22: Documents, previous projects (2IM22), slides

2IM22 Website: www.win.tue.nl/2IM22 • process description • Previous years’ results • Other materials (exercise, UML related) 2IM24: 4sp 2IM25: 5sp • Spend one third in quartile a • Spend two thirds in quartile b Participation in the project is a commitment! If youdrop out later on, you seriouslyhamper your colleagues! Please decide nowif you’re not sure! !!!

Goal • Learn hands-on about software engineering projects • Limited number of hours, so • a relatively simple project • a simplified process • Nevertheless, hopefully a good impression how software engineering projects are done • Dr. Tom Verhoeff will give a short overview of software engineering • September 111h, 1st hour • September 18th, 1st hour • September 25th, 1st hour

This year’s assignments • All groups develop a Snake program with (slightly) different requirements • Requirements: first by analyzing the game and the explanation given • Each group has a client that is represented by one of the teaching staff and a Technical Advisor (TA) that is another member of the teaching staff • As each group and student has more time to spend compared to previous years, some extra activities will have to be done, in particular, we require systematic testing of part of the product and writing the URAR (explained later on)

I will give a short introduction to the assignments which have mainly been defined by Hans Zantema. As he is teaching, he couldn’t present the assignments himself. All groups are required to make an appointment with him (preferably together with their customer) to discuss the assignments in detail. Your customer may add additional requirements Before going to your customer, be sure you understand the game in detail an be sure you know what to ask (use the customer’s time sparingly!)

Software Engineering Project Develop an application through a well-defined process: • Gather requirements (User Requirements phase) • Model the problem (Software Requirements phase) ================================= • Design the architecture (Architectural Design phase) • Detailed design and implementation (DD phase) =============================== • Testing phases Requirements Phases Design/ implementation phases

Quartile a • Organize the team • Gather and elicit the requirements; write User Requirements Document (URD) and the User Requirements Analysis Report (URAR) • Introduction Software Engineering • Introduction UML • Modeling exercise to • learn about modeling • learn about UML • Notice that UML knowledge will necessarily be limited • Model the game and do the better part of the Software Requirements Document (SRD) • Write management (process) documents • Do some experiments/preparation

Quartile b • Finish SRD • Design the game (write Architectural Design Document) • Implement the game (write/generate Detailed Design Document) • Keep management documents up to date • Write test documents and test the game (scoring part systematically with IDE) • Write the Acceptance Test Report (ATP) • Do Acceptance Test (AT) with customer • Final presentations

The process • most organizations have a well-defined process with well-defined deliverables I wouldn’t do business with an organization that does not • we use a very much watered-down version of the ESA standard – in itself already a relatively light-weight standard but still quite a lot of documentation overhead • documentation: there is a good reason for every document, even if this is less obvious in our “simple” project • Deadlines and deliverables in “A process for 2IM24/2IM25” • materials (including sheets) can be found on the web site

Roles in project • Project Manager (PM): • identifies and divides tasks (as primus inter pares!) • keeps track of hours spent/ hours still to be spent for each phase and task • identifies risks and corresponding actions required • resolves conflicts • writes Software Project Management Plan (SPMP) • Quality Manager (QM) • defines standards for documents, including code • organizes and takes part in reviews • writes Software Quality Assurance Plan (SQAP) • Configuration Manager (CM) or librarian • organizes and oversees the project repository • writes the Software Configuration Management Plan (SCMP) • Team Leaders (TL) for each phase • Vice PM, QM, CM, TL so continuity is assured in case of, e.g., illness

Process documents: SPMP very important to keep project on track! • what are the tasks that need to be done • when should a task be finished and how many man hours are needed for completion • who will do the work • risk management: identification, impact, severity and action • planning • global (how much time for each phase) • detailed (current/next phase) • initially: estimates from data of previous years; please honestly report your hours spent! • man hour accounting: for each team member (spreadsheet on website) • number of hours spent • number of hours to spend weekly in order to finish project • record how many man hours different tasks actually required

Effect of not spending your hours really PMs: please calculate how many hours per week to spend in order to compete project for each student at least during the second quartile

Process documents: SQAP • “how can we ensure that our product is of sufficient quality?” • standards for documentation, models (SQAP/SR,AD) and code (SQAP/DD), e.g., • word processing system (Latex, Word,…), cover page, layout, template definition • style for the requirements (layout, identification) • rules for names of classes, methods, attributes • rules for code: line length, maximum number of method parameters, comments,… • review procedure: • what is reviewed, who takes part, who asks for review, walk-through or read in advance • keep it simple!

Process documents: SCMP • “how do we store our project data?” • SCMP should define • repository (SVN): • directory structure • rules for updates (e.g. only code that compiles may be uploaded, who may upload where ) • trunk/tagged versions • version numbering (x,y,z start at 0) • always send me the trunk version (always the latest version, no version number in file name) • Repository will be created as soon as I have data of all participants (sxxxxxx) • keep simple as well! • I will request space on our SVN server unless you prefer another type of repository (GIT, Dropbox) – but we need access! x .y .z successful external review successful internal reviewminor change

Product documents: URD • contract with the customer so needs customer’s approval! • “what are the requirements for the product?” • requirements • from analysis of the game (but customer might want something different sometimes) • from the customer • only go to customer after thorough preparation! • each requirement must: • be uniquely numbered • be unambiguous • be non-compound (if it needs two tests, it can’t be non-compound) • be testable (from this: URAR which defines method/principle of testing) • … (see flow diagram from website) • have a priority • defines order of implementation and which may be left out when time runs out • related requirements may be summarized using sub-numbering (UR-FC1a, UR-FC1b) to avoid undue repetition (see process description for examples)

Product documents: URD (continued) • functional requirements (grouped by related functionality) • rules of the game • lay-out, dimensions,… • scoring • extra -functional (non-functional) requirements • requirements on platform • requirements on implementation language • scenario of typical use • formulating requirements properly is difficult! Good book: Robertson & Robertson – Mastering the Requirements Process

Product documents: URAR • “how can we test the individual requirements?” • for each requirement: a statement how this requirement can be tested in principle, e.g., • Requirement: When a trick is won by a team, the game score for this team is increased by the value of the trick Test: count trick scores by hand and check result for game score. Alternatively: inspect the scores in the debugger or add print statements in the code and check that the values are correct • Requirement: a stone always drops to the lowest possible position Test: visual inspection • Requirement: the code is written in Java Test: the entire project compiles with the java compiler or code inspection • so: just the principle of the test (the HOW IN PRINCIPLE) summarized in one or two lines per requirement • should be made by team working independently of UR team • use the flow diagram available from the web site to analyze each requirement • prevents, e.g., requirements that can’t be tested and compound requirements • UR team needs to fix problems found

Product documents: SRD • “what is our problemexactly?” • requires customer approval • models the problem, so basically the external behavior of the system • SR phase belongs to the requirements part of the project • model is used to get a good understanding of what the problem is • model is used to find missing/incomplete/inconsistent requirements • so it is normal that URD is adapted during the SR phase if this is the case, the customer needs to give his approval for the URD again! • model usually is a good stating point for design implementation may force changes, e.g. due to performance issues

Product documents: SRD (continued) • SRD contains • Class Diagrams (static structure) including descriptions (Software Requirements) of: • the classes – what is the purpose of the class? • the methods – what does the method accomplish? • attributes – what is the attribute used for? • Sequence Diagrams (SDs) and/or state transition diagrams (dynamic structure) • use cases (from scenario URD) – provide starting points for SDs • prototype (screen shots, working demo) • tracing to User Requirements (and v.v.)

Product documents: SRD (continued) • do not stop modeling too soon • e.g. 2008: rotation of a block in Tetris was not modeled at all (despite some pressure); during implementation, questions came up like • rotate around which point? • rotate even if this would be physically impossible? (other block in the way) strictly speaking, this would mean • renegotiate with customer • adapt and review URD, SRD, ADD – potentially very expensive when this comes up in DD phase! • the SR phase is meant specifically to spot these kinds of things!

Product documents: ADD • “what is the basic structure of the product and what are the interfaces of its components?” • global design of the product • division into modules • e.g., division into parts dealing with user interface, basic notions, rules scoring, … • for each module • definition of each module’s interfaces(class, method, parameters, return value, description of function of method); this enables independent development of the modules by different groups • class diagram (with same information as in SRD but more specific) • usually based on the class diagrams of the SRD • should have tracing of requirements to SRD but we may drop that • In 2009, the ADD was dropped to save time but actually this delayed the project as interfaces between different parts were unclear, so teams implementing different modules had to confer all the time!

Product documents: DDD • “how is the product implemented?” • description of the implementation • documentation similar to SRD (classes, methods, attributes) • preferably generated from code (e.g. javadoc) • not only public methods but also private and protected methods (i.e. not just a description of the API of the classes) • as an example, see e.g. the Java documentation

Product documents: test phases Unit Tests: Use testing facilities of development environment to test the scoring module and other modules (to be discussed) Integration Tests make a short document (ITP) that describes in which order the system is assembled may be skipped if time is an issue System Test • imperative: the ST is an extension of the AT, so if the ST succeeds, the AT should also succeed (internal rehearsal for the AT with extensions) • tests and procedures documented in STP • normally the ST is much more elaborate and includes, e.g., stress and performance tests, in our case just a slightly extended version

Product documents: test phases Acceptance Test (needs customer approval) • executed by customer without help from team on a system of the customer • test procedure 1: installation (by customer) • at least one test case for each user requirement • tests cases are grouped into test procedures to avoid repetition of preparing situations for tests • it may be necessary to bring the system in a particular state for a particular test, so this may need custom code or custom configurations (e.g., with Tetris, a 1 block wide grid) • ATP can, in principle be completed after the SR phase (however…) • ATP should state clearly what the requirements on the customer’s system are • AT should be planned together with customer well in advance (make appointments for two ATs, as the first one usually fails) • for each AT, make a test report in which the result of each test is recorded (deliverable)

Tasks for the coming period • Division into teams is made by the staff to ensure equal total number of hours to spend and mixed composition – group composition will be handed out after I finish • Organize the team • Write management documents (SPMP, SQAP, SCMP + UR appendices) and construct document templates (notice: Etaris cover page is not convenient) • Study the games and derive requirements from this (URD + URAR) • Turn in these 5 documents before September 17th (latest: Wednesday morning) regardless of the state these are in, so we can discuss these the 18th • Make appointment with customer shortly after the 18th to elicit his (extra) requirements

Tasks for the coming period • Lack of programming experience is a high probability, high impact risk which needs to be addressed a.s.a.p., e.g., by experimenting with simple prototypes as soon as this is feasible (all tasks with high risk and high probability need to be tackled immediately!) • Do other tasks that can be done already early in the project, e.g., construct or collect picture elements for the game (e.g. images of parts of the snake) • Read the process description • Get familiar with SVN and TortoiseSVN (or another repository) • If you want to use SVN: give me your s-numbers (needed to create the repositories) • SUCCESS!

Introduction 2IM24/2IM25