10/9/2013 ETSN05 -- Lecture 5 The last lecture Today • About final report and individual assignment • Short introduction to “problems” • Discussion about “typical problems in the course” 1 10/9/2013 Plan-Do-Study-Act Plan Act Do E.g. Bergman, Klefsjö, Quality, Study Studentliteratur, 1994. Quality Improvement Paradigm 1. Characterize 2. Set goals 3. Choose model 4. Execute Proj org EF 5. Analyze 6. Package V. Basili, G. Caldiera, D. Rombach, Experience Factory, in J.J. Marciniak (ed) Encyclopedia of Software Engineering, pp. 469-576, Wiley, 1994. (Also summarized in C. Wohlin, P. Runeson, M. Höst, M. C. Ohlsson, B. Regnell, A. Wesslén, "Experimentation in Software Engineering", Springer, 2012.) 2 10/9/2013 Learning organization • “A learning organisation is an organisation skilled at creating, acquiring, and transferring knowledge, and at modifying its behaviour to reflect new knowledge and insights” D. A. Garvin, “Building a Learning Organization”, in Harward Business Review on Knowledge Management, pp. 47–80, Harward Business School Press, Boston, USA, 1998. • Requires: systematic problem solving, experimentation, learning from past experiences, learning from others, and transferring knowledge Postmortem analysis • IEEE Software, May/June 2002 3 10/9/2013 Postmortem analysis cont. • “Ensures that the team members recognize and remember what they learned during the project” •“Identifies improvement opportunities and provides a means to initiate sustained change” Three sections of the PFR • Historical overview of the project – Figures, tables, diagrams, etc – Comparison between actual values and estimations • Evaluation of what went well and what went not so well – Analyze reasons for problems/issues/etc • Software process improvement proposals Read PH:9.10 4 10/9/2013 In PFR include at least • Effort per phase • Start and end dates for each phase • Effort per document • Start and end dates for each document • Effort for different activities in each phase • Effort per group & week • Analysis of problem reports in phases Project Final Report Evaluation • Extent • how far does the report get in: WHAT has happened (data reporting) WHY it happened so (cause analysis) WHAT can be done to improve (Software Process Improvement) • Quality • how well are the chosen topics reported 5 10/9/2013 Individual report (max 3 pages, 10 pt times) See course homepage Monday next week, 14.10.2013 Objectives: • to stimulate reflection on large-scale software development continuously through the course, • to encourage a viewpoint on industrial practice in large-scale software development, • to build on and integrate with what you have learned from previous courses Identify relevant areas and motivate your conclusions. Analyse: • What was challenging and what was easy in your own work? • What was challenging and what was easy in your fellow project members work? • What are the similarities and differences between the controlled course situation and industrial practice? • What is realistic about the course setting, and what is not so realistic? • What role does the scale (in terms of size and complexity) play in the challenges you have had during the project? • What is easy in a small-scale project while significantly more challenging in a large-scale project? • Which problems are not more or less difficult to address when carried out in a large-scale setting compared to a smaller scale setting? 6 10/9/2013 Deadline etc • E-mail the report to me in pdf-format • [email protected] • Deadline: Monday Nov 4th, 23:59 • Max 3 pages (+ front page etc), 10 pt Times • Don’t forget to write your name on the report. Examples of real difficulties in real industrial projects 1. What is actually the best set of requirements? 2. How much uncertainty in effort estimation can we cope with? 3. At what level of detail should we document requirements? 4. How to minimize waiting time for other parts to be ready before we can start our part? 5. How to make more parts in parallel without generating confusion and unnecessary rework? 6. How to know when the product is reliable enough to be released? 7. How to incorporate changes without generating spaghetti and excessive cost of rework? 7 10/9/2013 Some examples of “problems” that probably are not very big in your project Multi-project environment Risks: - Sub-optimization - Uncoordinated -… CC BY-NC 2.0 weeta 8 10/9/2013 Elementary or advanced process? CC BY-NC 2.0 i a walsh Chasm between marketing and development CC BY-NC 2.0 Travis S. 9 10/9/2013 Living with changing requirements Requirements are invented rather than discovered Innovation capability is critical CC BY-NC 2.0 Adi Respati 10 10/9/2013 Unacceptable behavior …and an example of a problem that you maybe have seen: • It is unclear what the requirements are, and what the customer really expects… …and I promise, we have never been unclear on purpose… 11 10/9/2013 “If I had asked people what they wanted, they would have said faster horses.” 24 Getting the requirements is not trivial “You can't just ask customers what they want and then try to give that to them. By the time you get it built, they'll want something new.” 25 12 10/9/2013 Eliciting and understanding is difficult because • Stakeholders often don’t know what they want from the computer system • Stakeholders naturally express requirements in their own terms and with implicit knowledge of their own work • Different stakeholders have different requirements, which they express in different ways • Political factors may influence the requirements • The economic and business environment in which the analysis takes place is dynamic requirements may change during the project Sommerville, Software Engineering, 8:th ed, Addisson-Wesley, 2007 Perspectives on a future system Different stakeholders, views, systems, etc Process Req. 13 10/9/2013 Conclusion • Large-scale development require processes, organizations and tools that can cope with increasing complexity • Most of you will work in – Large companies – Small- or medium-size companies that deliver software or systems to large companies • Your engineering skills depend also on – How you can combine technology and economics – Work in teams and with big organizations Before you start writing your PFR report conduct a brainstorming session • Identify a problem you have encountered in the course, and that we can discuss • Identify something that went well in the course, that we can discuss 14 10/9/2013 Discussion For each slide, identify/discuss - Underlying problem/issue/area - Is this a realistic/real problem? - What process improvements could be made? Old problems 15 10/9/2013 Old problems • Problem: att få testgruppen att arbeta parallellt med de andra • Koordinera ut information till grupperna • Lätt göra själv, men svårt dela ut i rätt tid • Tighta deadlines i början. Inget att göra i början men sedan mycket Old problems • Hantering av PR. De rör många dokument • Obalanserad arbetsbelastning • Skillnad i ambitionsnivåer i gruppen dålig arbetsmoral • Teknisk kompetens skiljer sig i grupperna 16 10/9/2013 Old problems • Det tar för mycket tid från projektet att reda ut missförstånd och tolka PH på rätt sätt. • The different UGs work and write the documents a bit different. It is a challenge to keep the documents consistent. • En beskrivning på Telecom utvecklingsmodell hade varit bra att ha, då det verkar vara, enligt litteraturen, det viktigaste dokumentet i kursen. • Testarna har feltolkat kravet • Inte alla grupper följer standarder OLD Feedback • ibland har det uppstått situationer där det inte har gått att jobba med någonting, tex att det inte känns bra att börja skriva på SVVI förrän SVVS är satt i baseline, helt enkelt för att man hade fått göra om för mycket arbete. 17 10/9/2013 OLD Feedback • “Jag skulle gärna ha någon diskussion kring tillgången till automatiserade verktyg för att hantera projekten. Tidsrapportering och planering känns som att det borde finnas rätt bra verktyg till.” OLD Feedback • “Det skulle även vara intressant att diskutera hur mycket som är lagom när det gäller hård koll på rapportering, rutiner o s v. Någonstans måste det ju finnas en gräns där systemet snarare är i vägen än att det hjälper. T ex kan jag tänka mig att utvecklare börjar lösa problem utan att rapportera om proceduren att rapportera är för jobbig.” 18 10/9/2013 Projects and Products that went terribly wrong Projects and Products that went terribly wrong http://www.dailymail.co.uk/news/article-2265616/Boeing-787-Dreamliner-battery-did-NOT-catch-overcharged- say-air-accident-investigators.html The polish Airline LOT is requesting about 100 000 000 PLN ( over 200 MSEK) in compensation from Boeing. 19 10/9/2013 Projects and Products that went terribly wrong Projects and Products that went terribly wrong 20 10/9/2013 Testing is far from trivial The top 20 most expesive software bugs - Mariner Bugs Out (1962) • Cost: $18.5 million •Disaster: The Mariner 1 rocket with a space probe headed for Venus diverted from its intended flight path shortly after launch. Mission Control destroyed the rocket 293 seconds after liftoff. • Cause: A programmer incorrectly transcribed a handwritten formula into computer code, missing a single superscript bar. • Without the smoothing function indicated by the bar, the software treated normal variations of velocity as if they were serious, causing faulty corrections that sent the rocket off course 21 10/9/2013 Hartford Coliseum Collapse (1978) • Cost: $70 million, plus another $20 million damage to the local economy •Disaster:Just hours after thousands of fans had left the Hartford Coliseum, the steel-latticed roof collapsed under the weight of wet snow. • Cause: The programmer of the CAD software used to design the coliseum incorrectly assumed the steel roof supports would only face pure compression. But when one of the supports unexpectedly buckled from the snow, it set off a chain reaction that brought down the other roof sections like dominoes.