Quality in a Project ETSF 01 http://cs.lth.se/etsf01 Process (L4) Lecture 6: Quality Management, Exam walk-through, Quick course re-run & Ch 13, except 13.7 and 13.9-10 [Hughes] Requirements (ETS170): Specify quality requirements (QR) Product Quality Testing (ETS200): Achieved QRs? elizabeth@cs.lth.se SW Project Management, Organisation & People Process Product Quality Project success == Meeting goals Manufacturing: obvious, e.g. set-up of automated tools and product checking processes. Software: Less obvious, much more creative and design-intense activity. Innovative. => PEOPLE involved big influence on quality Primarily four types of shortfall Delays Inadequate product functionality Inadequate product quality Cost overruns Quality management Testing (ETS200) Requirements (ETS170) Product scope Cost Time
Quality Concerns in SPM QR 1. Identify project objectives 10. Lower level planning Risk <-> Quality SW Metrics 9. Execute plan Test 0.Select project 2. Identify project infrastructure Process 3. Analyse project characteristics 4. Identify products and activities 5. Estimate effort for activity 6. Identify activity risks 7. Allocate resources 8. Review/ publicize plan Activities for Quality Cost Cost For each activity Right competence Test ETS200 RE ETS170 Quality Concerns in SPM Main 1. Identify 1.Quality-related objectives RE project objectives 2.Installation standards and Process procedures affect quality 3. Quality requirements identified RE suitable process 4.Necessary activities incl Test in/out/process for them to reach Process desired product quality 5.Ensure that quality is included inre estimates 6.Risks often affect quality + low quality is a risk! 7.Right competence & 10. Lower level experience? planning 9.Measure & Manage for quality Test 9. Execute plan RE ETS170 0.Select project 3. Analyse project characteristics 4. Identify products and activities 5. Estimate effort for activity 6. Identify activity risks 7. Allocate resources 8. Review/ publicize plan Test ETS200 2. Identify project infrastructure For each activity What is Quality? Quality is different things for different people Banker: safe & reliable service Healthcare worker: safe & timely quality health care Hotel employee: customer satisfaction Development engineer: bug-free product
How is (Software) Quality Defined? Quality is fitness for use - Joseph Juran Quality is conformance to requirements - Philip B. Crosby Quality of a product or services is its ability to satisfy the needs & expectations of the customer Quality is about meeting the minimum standard required to satisfy customer needs. High quality products meet the standards set by customers. Balancing Cost vs Benefit (Value) of Quality User benefit Excessive Competitive advantage Useful Useless Benefit view Utility breakpoint QUPER: Quality Performance Requirements Model Saturation breakpoint Differentiation breakpoint Quality level Impl cost barrier Cost view Supporting Roadmapping of Quality Requirements. Regnell, B., Berntsson Svensson, R., Olsson, T. (2008) IEEE Software, Vol.25(2), pp.42-47 Quality level Hi vs Lo Quality changes over time, eg. start-up time, battery time, screen clarity, etc Quality is relative ISO 9126 software qualities functionality does it satisfy user needs? The quality attributes to be covered by evaluation framework! Examples High quality washing-up liquid can claim that one squirt is sufficient customer prepared to pay $ Poor quality washing-up liquid requires several squirts customer accepts if cheap reliability usability efficiency maintainability portability can the software maintain its level of performance? how easy is it to use? relates to the physical resources used during execution relates to the effort needed to make changes to the software how easy can it be moved to a new environment?
ISO 9126 software qualities Functionality Suitability Accuracy Interoperability Functionality compliance Security Reliability Maturity Fault-tolerance Recoverability Reliability compliance Usability Understandability Learnability Operability Attractiveness Usability compliance Efficiency Time behaviour Resource utilization Efficiency compliance Maintainability Analysability Changeability Stability Testability Maintainability conformance Portability Adaptability Installability Co-existence Replaceability Portability conformance ISO 9126 software product quality Process process quality Process measures (ISO 15504) influences depends on Software products internal quality attributes Internal measures influences depends on external quality attributes External measures influences Effect of SW product in context of use quality in use attributes depends on Quality in use measures Quality in use Effectiveness ability to achieve user goals with accuracy and completeness Productivity avoids excessive use of resources in achieving user goals Safety within reasonable levels of risk of harm to people, business, software, property, environment etc, Satisfaction happy users! users include those maintain software as well as those who operate it. Internal and External Quality Attributes Concerning quality of a software product Examples Dev engineer: bug free, efficient algorithm internal quality User: Start-up time, screen quality external quality hassle-free usage, outdoor use in use quality
Quality Management: An holistic approach is needed RE Process Plan Product quality Testing Total Quality Management - TQM Doing things RIGHT.. Estimates People The QM gurus (Deming, Juran, Crosby) agree on that Inspection is never the answer to quality improvement, nor is policing Involvement of leadership and top management is essential to the necessary culture of commitment to quality A program for quality requires organization-wide efforts and long term commitment, accompanied by the necessary investment in training.the FIRST time, every time! PUST misslyckat IT projekt Vision/mål PUST projektet: 2 instanser 1. skräddarsydd lösning f fältarbete. ANVÄNDBARHET 2. Siebel: spara pengar med standardlösning (billigare underhåll) => anpassa verksamheten efter tekniska möjligheter. Orealistisk & biased förstudie (Oracle). Mäta användbarhet => strök kravet! Arbetssätt 1. inkrementell, användarinteraktion, utbildning 2. stängt projekt, ingen användarutbildning Resultat 1. nöjda användare, proprietärt system 2. missnöjda anv, hacka sönder -> dyrt underhåll/utv TQM Approach Focus on processes Base decisions on fact (measurements) Focus on customers Committed leadership Improve continuously Let everybody be committed B. Bergman and B. Klefsjö, Quality: from customer needs to customer satisfaction, Studentlitteratur, 2003
TQM Focus on customers: Find out what customers want, internal and external Base decisions on fact: Systematic (not random) info, relative customers needs Focus on process: incl project i/f, measure process perf Improve continuously: PDCA cycle (Deming), Improve quality of goods, services and products, processes and methodologies while using less resources Let everybody be committed: Opportunities to be committed, involved in the decision-making and improvement work, Delegation of responsibility and authority TQM Total Quality Management A total concept, where values, methodologies and tools combine to attain higher customer satisfaction with less resource consumption. Origin Deming (Am in Japan) during 1950s By the mid 1970 s Japan was beginning to seriously undermine its American and other western competitors B. Bergman and B. Klefsjö, Quality: from customer needs to customer satisfaction, Studentlitteratur, 2003 Quality Issues, Errors! Quality in a Project Errors accumulate with each stage Errors are more expensive to correct at later stages need to rework more stages later stages are more detailed and less able to absorb change Impact of change increases the later it is done Barry Boehm Error typically 10 times more expensive to correct at coding stage than at requirements stage 100 times more expensive at maintenance stage Requirements: Specify quality requirements (QR) Process (L5) SPM Product Quality Testing: Achieved QRs? - Well-defined activities - Sufficient estimates - Right resources - Risks, honest! - Monitor quality levels- -> definition of done
Activity Planning Clear criteria for activities Entry requirements pre-requisites Example for testing activity: test data + expected results prepared and reviewed against reqts Implementation requirements Example: when an error is found and corrected, all test runs must be completed, including those previously successfully passed Exit requirements Example: the testing is finished only when all tests have been run in succession with no outstanding errors Sufficient & Realistic estimates (L2) Parkinson s Law Work expands to fill the time available Brooks Law putting more people on a late job makes it later Over-estimate project likely take longer time Weinberg s Zeroth Law of reliability a software project that does not have to meet a reliability [QUALITY] requirement can meet any other requirement Under-estimate lower quality in order to meet target TK Abdel-Hamid, SE Madnick, Impact of schedule estimation on software project behaviour, IEEE Software, July 3(4), 70-75, 1986 When are we done? Decision to stop testing & release software The problem: impossible to know there are no more errors in code. Need to estimate this. With testing techniques, e.g. bug seeding Customer acceptance testing Expert opinion previous experience categorisation of bug criticality Quality plan Specifies level of quality assurance for the project Typical content: scope of plan & references to other documents quality management, incl organization, tasks, and responsibilities documentation to be produced standards, practices and conventions, reviews and audits (process) testing strategy and plan problem reporting and corrective action tools, techniques, and methodologies code, media and supplier control records collection, maintenance and retention training risk management
Project Completion Quality Management: Summary Succesful? Delivered scope & quality on time within budget Gains Quality product that meets customer need New lessons learnt (for next time!) Experience Scope + Quality Process improvements t Definition(s) of quality incl ISO standards Factors affecting quality Total Quality Management Good SPM practices for managing quality Recommended exercises: Ex 13.4-5 Submission: Final Project Report Bonus poäng gäller t o m omtentan i augusti via email (not moodle) to etsf01@cs.lth.se, etsf01.lu@analys.urkund.se with subject line = Report + <Group ID> + <student IDs of group> Kolla - Project descr: Grading criteria - SPA I & II checklistorna - Mottagen SPA feedback Mål: projektbedömning klar till 2 juni:ish Example: Attach - Report - Progress log
Tenta Anmälan! To 2 juni kl 14-19, Vic 1 Inga hjälpmedel, dvs closed book Max 60 poäng på tentan Max 10 bonuspoän på projektet Tentaupplägg 2016 ETSF01 SOFTWARE ENGINEERING PROCESS ECONOMY & QUALITY Exam + bonus points >=30 of which at least 27 is for exam 3 >=41 4 >=51 5 Grade Tenta Max 60 poäng Uppgift 1: definition och exempel på 6 termer Max 3 p / term = Totalt max 18 p Uppgift 2: utföra praktisk övning och visa förståelse för den (frågor) Max 14-16 p Uppgift 3-4: uppsats med nyckelord o max sidantal. Max 8-16 p / uppgift Kursinnehåll Allt som ingår i kursmaterialet == föreläsningar + kurslitteratur == bok + artiklar P1-P7, se läshänvisningar i kursprogrammet dvs SPM, Managing people, Project and Program organisation, Sw Procee Improvement (SPI), SW Metrics och SW Quality + relationer mellan dessa
Kursmål För godkänd kurs skall studenten kunna beskriva hur ett utvecklingsprojekt planeras, kostnadsskattas, leds och följs upp förklara tekniker för planering, kostnadsskattning, risk hantering och ledning & uppföljning av utvecklingsprojekt beskriva hur mjukvaruprocessförbättring går till ta fram en detaljerad projektplan m kostnadsskattningar f delmoment delta i arbete med mjukvaruprocessförbättring föreslå, utföra och analysera mått utifrån ställda målsättningar skriva en teknisk rapport Ha förståelse för hur kvalitetsarbete på organisationsnivå går till projektledning och mjukvaruprocessförbättring kan använda mått TENTA EXEMPEL & TIPS Exempel på uppgift 1: Terminologi Definiera följande termer (1 p per term) och ge tydliga klargörande exempel på termen och dess användning (2 p per term): a) kritisk väg (critical path) b) resurshistogram (resource historgram) + c-f) Examinationsmål Beskriva och visa förståelse av koncept, terminologi och tekniker som ingår kursinnehållet Exempel på lösning: Uppgift 1a) a) Kritisk väg Definition: En kedja av beroende aktiviteter som avgör projektets ledtid (duration), dvs försening i nån av dessa aktiviter försenar hela projektet pga beroenden till andra aktiviteter. (1p) Exempel inkl användningsområde: Den kritiska vägen för exempel planen i bilden utgörs av aktiviteterna F och G (se bild) då dessa behöver göras efter varandra med ett glapp (float) på 0 dagar. (1p) Kritiska vägar används t ex inom riskhantering då dessa utgör en risk för förseningar av hela projektet, dvs om en aktivitet på den kritiska vägen försenas så försenas också uppstarten av efterföljande aktiviteter. (1p)
Exempellösning Uppgift 1b) b) resurshistogram Definition: Ett diagram som visar den totala mängden behövda (eller ev använda) resurser av en viss kategori över tid. (1p) Exempel inkl användningområde: Diagrammet visar mängden behövda resurser enligt gjord aktivitetsplanering. (1p) Resurshistogrammet kan användas vid resursallokering för resursutjämning (resource levelling) då det visualiserar ojämnheter i resursbehovet över tid. Resursbehovet kan då jämnas ut genom att flytta aktiviteter från perioder med hög resursåtgång (toppar i diagrammet) till perioder med tillgängliga resurser (dalar i diagrammet). (1p) Tentaskrivnings tips Skriv fullständiga meningar, inte punktform. Exempel: Projekt risk: osäker händelse, negativ påverkan 0 p En risk är en händelse som inte ännu inträffat, om det gör det har det en negativ påverkan på projektets möjligheter att uppnå sina mål gällande scope, tid och/ eller kostnad. 1 p Undvik rundgångsdefinitioner. Tillför mening/semantik, t ex andra förklarande ord eller beskrivningar. Exempel: Projekt risk: En risk som kan inträffa i ett projekt. Ge ett exempel som täcker alla koncept i definitionen T ex, för en risk, tydligt beskriver både orsak (försening av hårdvaruleverans) o verkan (försenad testning och minskad produktkvalitet) Komplettera gärna textuell beskrivning med bilder, men inte bara bild! 0 p Exempel på uppgift 2: Praktiskt Ett företag XYZ har två nya projekt kandidater, nämligen projekt R och projekt T. Pga resursbegränsningar kan bara ett av projekten genomföras. Anta att du ska avgöra vilket projekt som ska utföras då avkastningsvärde (net present value, NPV) för dessa projekt påverkas av marknaden. Det finns 3 möjliga marknadssituationer, S1, S2, och S3: - för S1, är projekt Rs NPV 8000 Euros och projekt Ts NPV 6000 Euros. - för S2, är projekt Rs NPV 20% lägre än S1s + projekt Ts NPV 10% högre än S1. - för S3, är projekt Rs NPV 10% högre än S1s + projekt Ts NPV 5% lägre än S1. Vilken marknadssituation som faktiskt kommer att inträffa är okänt men marknadsavdelning på företag XYZ har uppskattat sannolikheterna för varje situation. Sannolikheten att S1 kommer att inträffa är 50%, sannolikheten för S2 är 40%, och sannolikheten för S3 är 10%. Exempel på uppgift 2 (forts) a) Konstruera ett beslutsträd (decision tree) för detta fallet (2 p) b) Vilket projekt bör väljas och varför? (2p) c) Beskriv hur beslutsträdet är konstruerat och hur det används för att svara på fråga b). (max 4-8 meningar) (2 p) d) Antag att marknadsavdelningen kan påverka sannolikheterna för de framtida marknadssituationerna S1, S2 och S3 genom att investera i en reklamkampanj. Antag att reklamkampanjen kostar 1200 Euros och förändrar sannolikheterna för S1, S2 och S3 till 30%, 0%, respektive 70%. Rita ett nytt beslutsträd (decision tree) för valet att investera i reklam. (2 p) e) Vore denna investering lönsam för projekt R? För projekt T? Ge argument för dina svar. (2 p)
Exempellösning Uppgift 2 a) Konstruera ett beslutsträd (decision tree) för fallet ovan (2p) B Projekt R Projekt T S1 0.5 S2 0.4 S2 0.4 S3 0.1 NPV (Euro) S1 0.5 S3 0.1 8000 6400 8800 6000 6600 7600 b) Vilket projekt bör väljas och varför? (2p) Projekt R bör väljas då dess förväntade vinst är högre (7440) än projekt Ts (6400). c) Beskriv hur beslutsträdet är konstruerat och hur det används för att svara på b) (max 4-8 meningar) (2 p) Valet mellan projekt R o T ritas som grenar från Beslutsroten. För vardera av dessa finns tre möjliga situationerna som då ritas som en gren vardera för varje projekt (R o T) med en viss sannolikhet att det inträffar. Slutligen har varje lövnod ett värde (NPV) som resultat av att följa den 'vägen' genom trädet. Man fattar ett beslut mha beslutsträdet genom att beräkna förväntat värde av varje beslutsalternativ. Detta görs genom att addera värdet för varje gren i del-trädet x sannolikheten för den grenen. I detta exempel blir värdet för Projekt R= 0.5*8000 + 0.4*6400 + 0.1*8800 = 4000 + 2560 + 880 =7440 och värdet för Projekt T=0.5*6000 + 0.4*6600 + 0.1*7600 = 3000 + 2640 + 760 = 6400 B Exempellösning Uppgift 2 (forts) Projekt R Projekt T NPV (Euro) S1: 0.3 6800 S2: 0.0 5200 S3: 0.7 7600 4800 S1: 0.3 S2: 0.05200 S3: 0.7 6400 d) Antag att marknadsavdelningen kan påverka sannolikheterna för de framtida marknadssituationerna S1, S2 och S3 genom att investera i en reklamkampanj. Antag att reklamkampanjen kostar 1200 Euros och förändrar sannolikheterna för S1, S2 och S3 till 30%, 0%, respektive 70%. Rita ett nytt beslutsträd (decision tree) för valet att investera i reklam. (2 p) e) Vore denna investering lönsam för projekt R? För projekt T? Ge argument för dina svar. (2 p) Nej, investeringen är inte lönsamt för nåt av projekten då den förväntade vinsten minskar för båda. Nämligen förväntad vinst för projekt R blir nu=0.3*6800 + 0.0*5200 + 0.7*7600 = 7360 och för projekt T = 0.3*4800 + 0.0*5200 + 0.7*6400 = 5920. Examinationsmål för uppgift 2 Förmåga att kunna utföra SPM uppgifter som kostnadsestimering, aktivitetsplanering, riskhantering, resursallokering, uppföljning o hantering (monitor & control). Specifikt gäller detta de moment och uppgifter som visats exempel på under föreläsningarna och/eller täcks av de rekommenderade övningsuppgifterna. Detta inkluderar diagramtyper som tagits upp, t ex Gantt schema, burn-down charts, precedensnätverk, trafik ljus etc. Tentaskrivnings tips Läs beskrivningen noga! Redovisa hur du gjort, t ex, vilken metod, beräkningar etc. Ev slarvfel kan då leda till (bara) mindre avdrag. Svara utförligt på frågorna och inkludering tydliga motiveringar. Examinationsmål: Demonstrera praktiska färdigheter i att ta fram detaljerad projektplan, delta i SPI arbete, utföra och analysera mått. Och förståelse för dessa!
Kursmål För godkänd kurs skall studenten kunna beskriva hur ett utvecklingsprojekt planeras, kostnadsskattas, leds och följs upp förklara tekniker för planering, kostnadsskattning, risk hantering och ledning & uppföljning av utvecklingsprojekt beskriva hur mjukvaruprocessförbättring går till ta fram en detaljerad projektplan m kostnadsskattningar f delmoment delta i arbete med mjukvaruprocessförbättring föreslå, utföra och analysera mått utifrån ställda målsättningar skriva en teknisk rapport Ha förståelse för hur kvalitetsarbete på organisationsnivå går till projektledning och mjukvaruprocessförbättring kan använda mått Exempel på uppgift 3 & 4: Essä Ämne: Relationen mellan mjukvarukvalitet (software quality) och processförbättring (software process improvement). Diskutera och resonera. Max 8 p, 2 A4 sidor. Nyckelord: utvecklingsprocess, produktkvalité, kundtillfredsställelse, TQM (total quality management), top-down vs bottom-up processförbättring Examinationsmål Visa förmåga att beskriva, förklara och resonera omkring projektledning/styrnings (SPM) områden och situationer inklusive process, organisations- och kvalitetsfrågor inkl. relationer mellan dessa och för- och nack-delar med olika teknikerna och angreppssätt. T ex, CMMI, agil vs traditionell SPM, ledarskapsstil, analogi vs expertuppskattningar etc. Examples: iflap, Retrospective Tentaskrivnings tips Notera vilka aspekterna som efterfrågas. De kompletterar nyckelorden. Gör FÖRST en mind map omkring nyckelorden & aspekterna. SEN skriv, strukturera texten Top-Down enligt mind mappen Förklara begrepp och diskutera kopplingar, styrkor & svagheter. MOTIVERA! VAR TYDLIG! Ge förtydligande exempel. Komplettera gärna med illustrationer! 2. SW process Definition of quality Customer satisfaction Internal vs External quality attributes SPI 1. Product quality Bottom-up Top-down SPI for SW Quality 3. TQM + Involves staff - sub-optimisation Example: CMMI + full modell, best practice - complex, expensive - lack of staff involvement Customer focus Process focus Fact-based / measurements Continuous improvement Management & Staff involvement
Exempellösning på uppgift 3 Det är allmänt vedertaget att produktkvalité till stor del avgörs av utvecklingsprocess som används. Kontinuerlig processförbättring är därför ofta en viktig del av ett företags kvalitetshantering (quality management) och är en huvudkomponent i TQM approachen tillsammans med ett fokus på kundtillfredsställelse och på att engagera hela organisationen i kvalitetsarbetet. Till vilken grad processförbättringsramverk (SPI ramverk) leder till högre kvalité kan diskuteras. Denna fråga angående huruvida SPI ramverk kan leda till högre mjukvarukvalité kan analyseras genom att jämföra de mål och metoder som ingår i CMMI (som applicerar top-down processförbättring) med de aspekter och tekniker som används för mjukvarukvalitet. Till exempel, CMMI innehåller ett specifikt mål om att utföra granskningar (peer reviews). Syftet med dessa granskningar är att avlägsna defekter (fel) från mjukvaruprodukten tidigt i processen vilken kan göras med en mycket mindre arbetsinsats än om felen upptäcks sent i projektet. Alltså, färre buggar i slutprodukten kan ses som högre kvalité. Dessutom är kravhantering ett annat specifik mål inom CMMI vilken innefattar en tydlig förståelse för kraven på mjukvaran. En förbättrad kravhanteringsprocessen kan leda till att projektet har ett bättre förståelse av kundens krav och förväntningar och därmed utvecklar en produkt som bättre överensstämmer med dessa. Kundtillfredsställelsen blir då högre vilket är en av definitionerna på produktkvalité. Exempellösning på uppgift 3 (forts) Om ett bottom-up SPI ramverk används, t ex QIP (Quality Improvement Paradigm or iflap) så fokuseras processförbättringarna på de problem som identifierats för den specifka organisationen eller projektet. T ex, om testtäckningen av kraven är låg så kan en specifik processförbättring vara att införa granskningar av testfallen gentemot kravspecen. Detta kan leda till en mer heltäckande testning av kundkraven och att fler defekter upptäcks innan mjukvaruprodukten släpps. Dvs, produkten har en högra kvalitet. + svårigheter & negativa effekter som kostnad, ovilja till förändring, komplexiteten av CMMI etc Low on details Lecture 1 QUICK COURSE WALK- THROUGH Course + Project Introduction & Overview, Activity Planning, GQM [Hughes] Ch 1 [not 1.8, 1.9, 1.11, 1.14], Ch 3, Ch 6 [not 6.16] and P1
L1: Course Overview Context Content Sw vs non-sw projects time (lead time) scope (of deliverables) cost (effort/ resources) Dev organisation Dev project(s) Requirements WHAT? Architectural design Tech HOW? Code Implement reqts Test Verify reqts Goal: make $ by meeting needs Process Practical HOW? SPM HOW reach goal? Measurements Definition Project = Specific target & temporary (ends) Project vs Job Project management Quality DONE? L1: Activity Planning Identifying activities and dependencies Practical: Work-breakdown structure (WBS), Product-based structure (PBS), Hybrid approach Activity networks Practical: Precendence networks incl ES, LS, EF, LF, Float Practical: Critical path, sub-path Do B Do A Do C Earliest start Duration Do D Activity label, activity description Latest start Float Earliest finish Latest finish L1: Metrics & GQM (also at Ex1) Practical: Define measurements and scales using GQM method [P1] Exercise 1 Rhetorical disposition Top-down writing & moves: Introduction section GQM: metrics for activity planning
L2: Project Organisation Lecture 2 Project roles: Sponsor, Steering group, PM, Customers, Vendors, Dev team Effort estimation (Ch 5, not 5.11-12) Resource allocation (Ch 8 [Hughes]) Organisation Project sponsor / director Project manager Customer representative Customers Stakeholders ++ Vendors Steering committee Project team members L2: Effort Estimation Effort vs Cost Problems w estimation: subjective, changes, variations, politics, safe guarding Over/Under estimation: Parkinson s Law, Brooks law, Weinberg s Zeroth Law of Reliability Bottom-up vs Top-down approach Analogy, Parametrics/Algorithimic (COCOMO, function points) Parkinson & price to win Expert opinion, planning poker L2: Resource Allocation Practical: Resource types, requirements list, 5 histogramme, schedule Practical: Effort vs Duration Practical: Resource smoothing Practical: Prioritized allocation Burman s prio list Connection to cost schedules 4 3 2 1 WEEK 1 2 3 4 5 6 7
Burman s prio Give priority to: Shortest critical (path) activities Other critical activities Shortest non-critical activities Non-critical activities with least float Non-critical activities Lecture 3 Risk Management Ch 2.6, Ch 7 [not 7.3, 7.8 & 7.11] [Hughes] Agile Project Management P3, Ch 4.10-11, 4.13-15 [Hughes] L3: Risk Management Def Risk + top risks (Boehm) Uncertain event + effect on project s objective Consists of cause and effect RM = Assessment (Id, Prio) + Control (Plan/Mitigate, Monitor) Practical: Checklists, Brainstorming, Causal mapping Practical: Risk assessment w probability impact matrix, decision trees Risk planning: Acceptance, Avoidance, Reduction, Mitigation, Transfer Risk reduction f estimation: PERT (Progr Eval & Review Tech) + Critical Chain L4: Agile Project Management Agile principles, e.g. F2F, working SW > documentation, Customer coll > Following plan XP, Scrum, Kanban Activity planning prioritized backlog w user stories, tasks XP & Scrum: timeboxing in sprints (iterations) Effort estimate: Early rough, Sprints: Planning game Resource allocation: Self-managing teams == team pull Risk mangmnt: Implicit, Continuous feedback incl customer Monitor & control: Cont feedback, Burn-down charts (Scrum), Sprint retrospectives
Lecture 4 Monitor & Control Ch 9 [not 9.6], 12.4 [Hughes] L4: Monitor & Control Reporting: Formal/Informal, Oral/Written, Regular/AdHoc Practical: Gantt charts w progress, Slip chart, Burn-down charts, Traffic lights/rag Critical chain: Fever chart Progress vs Remaining work Prioritized monitoring Back on track Software Process Improvement P4-Sect 3.2, P5-Sect 1-3, P6 L4: Software Process Improvement (SPI) Processes relative Product quality, SPM, People, Dev technology Software certification: ISO, CMMI Practical: PDSA/Deming cycle (PUMA) Prescriptive/Top-down SPI: CMMI (SPICE) Inductive/Bottom-up: (QIP, iflap), Lean Six Sigma, Info flow analysis, Retrospective analysis CCMI: Staged vs continuous, process areas/levels S A D P Lecture 5 Portfolio & Program Management Ch 2 [not 2.9, 10-13], Ch 4.2, Ch 10.1-2) with Guest Lecturer
L5: Programme & Portfolio Management Business case Types of contract: fixed price, T&M, fixed price/unit Cost-benefit analysis, ROI, lifetime ROI, net profit, payback period Project roles: Sponsor, Steering group, PM, Customers, Vendors, Dev team Product portfolio Programme mgmt Project spons or / directo r Steering committee Project manag er Customer representativ e Custom ers Stakeholders ++ Vendors Project team members Lecture 6 Managing People Ch 11.1-3, 11.6, 11.8 [Hughes] and P7 Secions 1, 5-6 incl guest lecture L6: Managing People Hawthorne effect, Theory X / Theory Y Motivation: Maslow s hierarchy of needs Vroom: Work Performance Reward Value Stress vs XP practice of 40-h work week Communication paths and distances Lecture 7 Quality Management [Hughes] Ch 13 [not 13.7, 13.9-10] Exam set-up Course Walk Through
L6: Quality Management Def Quality: ability to satisfy customer needs & expectations Excessive Relative concept (QUPER) ISO9126: quality attributes Competitive advantage Useful Useless Utility breakpoint process internal external Saturation breakpoint Differentiation breakpoint quality in use Ge feedback & förslag! Fri text svar är actionable! TQM: continuous + holistic, customer, process, involvement, metrics based COURSE