Theory Lecture Plan 2 Lecture 2 Software Engineering TDDC88/TDDC93 Autumn 2008 Slides by Presented by Kristian Sandahl Department of Computer and Information Science Linköping University, Sweden krisa@ida.liu.se Last update: 2007-09-10 - Changes on slides 44-45 L1 - Course Introduction and Overview L2 - L3 - Requirements L4 - Acceptance Testing and Quality Factors L5 UML L6 - Design Patterns L7 - System Design and Architecture L8 - Testing Theory L9 - Testing in Practice L10 - Inspection L11 - Software Life Cycles and Configuration L12 - Software Quality L13 - Course Summary, Exam examples, Questions I A Software Life-cycle Model Which part will we talk about today? 3 Maintenance Agenda - What will you learn today? 4 Requirements Validate Requirements, Verify Specification Acceptance Test (Release testing) I System Design (Architecture, High-level Design) Verify System Design System Testing (Integration testing of modules) Module Design (Program Design, Detailed Design) Verify Module Design Verify Implementation Module Testing (Integration testing of units) Implementation of Units (classes, procedures, functions) Unit testing, Software Quality Assurance (SQA), Supporting Tools, Education I I 1
5 What is a project? 6 Climb Mount Everest Build a house Take a course Create a software I I Typical properties of a project? 7 Who are involved in a software project? 8 Start and stop Customer A budget User Pays for the system Development Organization Goal Uses the system Stakeholders Provides the system An orderer A single-time occurrence Primary Secondary Indirect A person or organization with a major interest in the project outcome. Supplier I I 2
Model Some roles of a life-cycle in a Development Team 9 Approaches to Manage Projects 10 Requirements Analyst Project Manager, Team Leader Maintenance Team Trainer An ad-hoc shoot-from-the-hip approach Architect Designer Programmer Developer Configuration Manager, (Librarians) Quality Coordinator Tester A structured project planning approach Example of project management models PROPS (In Swedish "Projekt för projektstyrning") By Ericsson RUP (Rational Unified Process) By Rational, part of IBM Much more than just project management One person can have many roles. One role can be assigned by several persons. I I Dependent project parameters 11 SMART Goals 12 Specific Must be straightforward and answer the questions: What will you do? Why is it important? Calendar Resources Measurable If you cannot measure it, how do you then know if the goal is reached or not? Project Agreed Upon Agreed upon with all stakeholders (e.g. customer, user etc.) Realistic Possible with the current resources, knowledge and time. You must be both willing and able to do it. Features Quality ly A clear time frame for the goal. Note that there exists other similar versions the definition of SMART goals. I I 3
Silent Beehive Exercise 13 SMART Goals 14 2 minutes silent beehive! Individually define a goal about your plan for academic study, which is SMART. Specific Measurable Agreed Upon Realistic ly Must be straightforward and answer the questions: What will you do? Why is it important? If you cannot measure it, how do you then know if the goal is reached or not? Agreed upon with all stakeholders (e.g. customer, user etc.) Possible with the current resources, knowledge and time. You must be both willing and able to do it. A clear time frame for the goal. Note that there exists other similar versions the definition of SMART goals. I I One example 15 16 Specific What: Earn at least 20 ECTS credits Why: To get money Measurable < 20 Credits goal not accomplished. >= 20 credits goal accomplished My goal is to have earned at least 20 ECTS credits at the end of the semester (fall 2007) so that I get money from CSN. I Agreed Upon Get the money if enough credits. However, maybe only one stakeholder here. E.g. I got 28 credits last semester. I'm very motivated. Realistic End of the semester (fall 2007) ly I I 4
A project 17 A project 18 Work breakdown Lots of things to do... I I A task or an activity 19 Dependencies between tasks 20 Examples: Implement encryption module Interview users Design user-interface prototype Task (or activity) Task1 and Task2 are precursors (predecessors) to Task3 Task1 Duration, e.g. 10 days Task2 Task1 Task3 I I 5
Tool Support 21 Tasks, Duration, and Dependencies 22 Phases Predecessors Microsoft Project OpenProj Gantt-chart Phase Dependency IDA's MSDN Academic Alliance (see "Resources" on course page) http://openproj.org Tasks Duration Task I I Milestone and Tollgate 23 Critical Path, Slack and Real time 24 Critical Path Milestone Tollgate Slack (float) time Verify internal sub-goal fulfillment Properties of a SMART goal External decision point E.g. after a pre-study phase, the customer decides if the project should continue or not. Real time (estimated) Available time = Slacktime + Real time I I 6
PERT-diagram, CPM-chart 25 Resource 26 Who is going to "do" the task and with what? Resource planning PERT = Program Evaluation and Review Technique CPM = Critical Path Method Task1 I I Resource 27 Resource 28 Total Estimated Resource name Type of resource Cost Resource assigned to task Over allocated Harry the hacker I I 7
A key to success - buffer time 29 Effort Estimation in reality 30 Buffer How long time does it take for you to implement the encryption layer? No idea. I have never done this before... I wonder if it is even possible. 8 months +- 2 months Internal Deadline External Deadline Sam the seller Harry the hacker Buffer To whom should you communicate the deadlines? I I Effort Estimation 31 32 Expert Judgment - the Delphi technique Experts make individual predictions secretly Calculate Mean Mean is presented to expert group [An expert changes its estimate] [No change] Algorithmic Methods - COCOMO and COCOMO II COCOMO (Boehm, 1981) An formula where parameters are estimated using real projects. Input: No of code lines Output: Effort (time) COCOMO II Takes into account changes in SE, such as component reuse, prototyping Other inputs than number of code lines. E.g. function-points (e.g. external in/out, user interactions, files) I I 8
What is a risk? 33 Kinds of risks 34 Something that can eliminate full success of the project Examples: General Project Specific Staff turnover - Experienced team members will leave the project Requirement change - Significant requirements will change late in the process. Size underestimated - The size project was larger then expected "A team member gets sick" "There is a risk that the project gets delayed" Direct "The delivery of the development hardware environment is delayed." "Anders needs to visit his family, since his father is dying." Indirect The project has great control "The Windows platform will not scale" where the project has little control "The servers will stop running due to an earthquake" I I What is risk management? 35 1. Identification 36 Brainstorming with the whole team for 10 minutes. What can go bad?!? identification List of potential risks analysis Prioritized list planning plan monitoring assessment "What can go wrong" "How bad is it" "What shall we do with it" "Has the probability changed?" Types of risks Technology risks - Hardware/software technology used for development, e.g. using Java People risks - people in the development team Organizational risks Tools risks - s with the current tool used Requirements risks - Changes in customer requirements Estimation risks - Wrong project estimations I I 9
2. Analysis 37 3. 38 1. Avoidance " problem between develop sites in Stockholm and India - localize all development in India?" low 1 moderate 2 Probability Probability x Impact = high 3 very high 4 Magnitude Indicator catastrophic 4 serious 3 Impact tolerable 2 insignificant 1 Sort list after risk magnitude Reorganize so that the risk disappears. 2. Transfer Reorganize so that someone else takes the risk, insurance, customer, bank. 3. Acceptance Live with it "the web-server fails often - low accessibility outsource the operation?" "Changes of requirements late in project - a prototype?" Mitigate the risk Lower the probability. "The key architect starts to work for another company - 2 architects?" Define A plan B... Contingency plan I I Beehive Exercise Analyze Plan 5 minutes beehive! Imagine you are working in a team which develops a new version of SJ railway booking system. The project has just been started. 39 Discuss in pairs Analyze and plan for the following risk If time: Identify and analyze a new risk. Description Probability Impact Factor During implementation it is discovered (1-4) (1-4) (1-16) that the new web-platform cannot talk to the legacy database system avoidance? transfer? acceptance? => (Mitigate risk - Contingency plan) Example Analyze No Description Probability Impact Factor 1 During implementation it is discovered that the new web-platform cannot Moderate (2) Serious (3) 6 talk to the legacy database system Plan 40 Avoid risk Do not introduce a new web-platform. Use the existing platform. Transfer risk Sign a contract with a contractor, who guarantees access to the system. Accept risk Mitigate Create a prototype early in the process. Solve issues before implementation phase Contingency plan Transfer the whole old legacy database system to a modern DBMS. I I 10
Make the risks useful 41 42 Few (3-10) Project Specific Regular meetings I I The Project Plan 43 The Project Plan - Content 44 Why a project plan? Tool for the project manager medium to project members and other stakeholders What should be done, when and by who When is the plan finished? v1 v2 v3 v4 More information... Abstraction Project Description Identification Background to the project Relevant constraints (budget etc.) Project Goal Start and expected end date. Project Organization Roles Knowledge / skill and reports s, Probability and Impact Mitigation and Contingency plan and Resource Plan Milestones Tollgates Deliverables Activities Resources Training Plan Needed knowledge and skills. Who needs what? Budget? Change and configuration management (In larger projects, this part is a document of its own.) I I 11
Project Status Reports 45 10. Follow-up 46 Content of a status report? Summary - current status What has happened since last report What happens next (both in long and short term) Schedules, resources, deliverables, estimates... Important risks outcome follow-up periods Status Report I Status Report II Status Report III v1 v2 v3 v4 More information... initial plan time I I Finally, never underestimate... 47 Summary - What have we learned today? 48 I... a project Kick-off I I 12