1. Software Engineering 3156 Fall 2001 Section 1 17-Sep-01 Class #3: Life Cycles, XML, and Tools Phil Gross

2. 2 Administrivia Recitations M: 5:30-6:30 CEPSR 415 T: 2:30-3:30 CEPSR 415 Except next Monday, 24 September – 6:15-7:15 IAB 410 Would Friday be better?

3. 3 More Admin Stuff Groups – Proposals in by tomorrow night – Advantages of the disadvantaged Tight schedule

4. 4 Review Standard Model Teams

5. 5 Standard Model Requirements Specification Design Implementation Integration Maintentance Retirement

6. 6 Requirements What are we doing and why? Interviews – Getting a problem specification out of busy, threatened, very-much-not-programmer types – Difficult to simulate in a course, so we’re skipping Prototypes and negotiation Metric: requirements volatility

7. 7 Specification Creating the contract What it will do, not how Detailed, so duration and cost can be estimated Classical: DFD, FSM, Petri Nets OO: Use cases, class modeling, state diagrams

8. 8 Design Fill in the “How” Interaction diagrams – Sequence – Collaboration Interactions determine actions Determine object clients Create detailed design

9. 9 Implementation Pick a language: C, C++, Java, Ada, COBOL, LISP, FORTRAN, Standard ML, Forth, PL/SQL, Assembly, etc. Programming standards: comments, meaningful variable names, named constants, etc. Black-box and Glass-box testing

10. 10 Integration Top-down finds design faults early Bottom-up finds operational faults early and isolates them So, “Sandwich Integration” does both at once Product and acceptance testing

11. 11 Maintentance Corrective (fix problems) Perfective (improvements) Adaptive (environment changes) Difficult, important, programmers hate it Carefully designed processes are critical

12. 12 Maintenance Costs Money Lots and lots of money Far and away most expensive component When doing cost-benefit analysis, anything that cheapens maintenance generally wins

13. 13 Retirement Diminishing returns from patching old code At some point better to rip up and start fresh

14. 14 Note What’s Not A Step Testing Documentation Supposed to be continuous Particularly Documentation

15. 15 Capability Maturity Model Not a life-cycle model Set of strategies for improving the software process – SW–CMM for software – P–CMM for human resources (“people”) – SE–CMM for systems engineering – IPD–CMM for integrated product development – SA–for software acquisition These strategies are being unified into CMMI (capability maturity model integration)

16. 16 SW–CMM A strategy for improving the software process – Put forward in 1986 by the SEI – Fundamental idea: – Improving the software process leads to Improved software quality Delivery on time, within budget – Improved management leads to Improved techniques Five levels of “maturity” are defined – Organization advances stepwise from level to level

17. 17 Level 1. Initial Level Ad hoc approach – Entire process is unpredictable – Management consists of responses to crises Most organizations world-wide are at level 1

18. 18 Level 2. Repeatable Level Basic software management – Management decisions should be made on the basis of previous experience with similar products – Measurements (“metrics”) are made – These can be used for making cost and duration predictions in the next project – Problems are identified, immediate corrective action is taken

19. 19 Level 3. Defined Level The software process is fully documented – Managerial and technical aspects are clearly defined – Continual efforts are made to improve quality, productivity – Reviews are performed to improve software quality – CASE tools are applicable now (and not at levels 1 or 2)

20. 20 Level 4. Managed Level Quality and productivity goals are set for each project – Quality, productivity are continually monitored – Statistical quality controls are in place

21. 21 Level 5. Optimizing Level Continuous process improvement – Statistical quality and process controls – Feedback of knowledge from each project to the next

22. 22 Summary

23. 23 Key Process Areas There are key process areas (KPAs) for each level Level 2 KPAs include: – Requirements management – Project planning – Project tracking – Configuration management – Quality assurance Compare – Level 2: Detection and correction of faults – Level 5: Prevention of faults

24. 24 Experience It takes: – 3 to 5 years to get from level 1 to level 2 – 1.5 to 3 years from level 2 to level 3 – SEI questionnaires highlight shortcomings, suggest ways to improve the process Original idea: Defense contracts would be awarded only to capable firms

25. 25 Experience (contd) Profitability – Hughes Aircraft (Fullerton, CA) spent $500K (1987–90) Savings: $2M per year, moving from level 2 to level 3 – Raytheon moved from level 1 in 1988 to level 3 in 1993 Productivity doubled Return of $7.70 per dollar invested in process improvement

26. 26 Other SPI Initiatives Other software process improvement (SPI) initiatives: – ISO 9000-series – ISO/IEC 15504

27. 27 ISO 9000 Set of five standards for industrial activities – ISO 9001 for quality systems – ISO 9000-3, guidelines to apply ISO 9001 to software – There is an overlap with CMM, but they are not identical – Not process improvement – Stress on documenting the process – Emphasis on measurement and metrics – ISO 9000 is required to do business with the E.U. – Also by many U.S. businesses, for example, GE – More and more U.S. businesses are ISO 9000 certified

28. 28 ISO/IEC 15504 Original name: Software Process Improvement Capability dEtermination (SPICE) – International process improvement initiative – Started by British Ministry of Defence (MOD) – Includes process improvement, software procurement – Extends and improves CMM, ISO 9000 – Framework, not a method CMM, ISO 9000 conform to this framework – Now referred to as ISO/IEC 15504 – Or just 15504 for short

29. 29 Process Improvement Data SEI report on 13 organizations in the original study They used a variety of process improvement techniques, not just SW–CMM

30. 30 Process Improvement Data (contd) Results of 34 Motorola projects

31. 31 Democratic Teams Egoless programming Social engineering “Please find bugs in my code” Problem: “I order you all to be egoless”

32. 32 Chief Programmer Teams Brooks’s approach Chief Programmer Back-up Programmer Secretary Just Plain Programmers

33. 33 Chief Programmer Problems Chief supposed to be manager and programmer Back-up Programmer just waiting for Chief Programmer to be hit by a truck – Cf. Vice President of the USA Secretary does paperwork all day Doesn’t scale to 100 programmers

34. 34 Typical Modern Team Programmers have a Technical Leader and a separate Team Manager Manager is administrative only Tech Lead is Technical only Can increase the hierarchy

35. 35 Microsoft Model Synchronize and stabilize Programmers can do whatever they want, but have to check in their code on time every day for integration Lets hackers run (relatively) free Good model for firms that can attract the very best programmers

36. 36 Extreme Teams Code in pairs No specialization A writes test cases, then B writes code while A watches Designed to be turnover-resistant Not for those who don’t like to be watched

37. 37 Your Teams Probably a mix of democratic and specialized Need to inventory skills of team Probably some manager type is a good idea – Call people if stuff is late – Watch big picture Not everyone needs to be coder – Lots of documentation needed

38. 38 More On Project Three main parts – Client – Server – AI Each group will work on one of the three http://www.gamasutra.com http://www.gameai.com

39. 39 Client Graphical tile-based UI Network communication with server Running animations Sending commands from user to server Displaying what the server tells it to Editor mode Untrusted

40. 40 Server Network communication with client Modeling of entire game world – Combat – movement Management of game clock Storage to LDAP server

41. 41 AI Determine NPC/Monster actions Determine shortest path between points Scripting Conversation

42. 42 Overview Build-and-fix model Waterfall model Rapid prototyping model Incremental model Extreme programming Synchronize-and-stabilize model Spiral model Object-oriented life-cycle models Comparison of life-cycle models

43. 43 Software Life-Cycle Models Life-cycle model (formerly, process model) The steps through which the product progresses – Requirements phase – Specification phase – Design phase – Implementation phase – Integration phase – Maintenance phase – Retirement

44. 44 Build and Fix Model Problems – No specifications – No design Totally unsatisfactory Need life-cycle model – “Game plan” – Phases – Milestones

45. 45 Waterfall Model (contd) Characterized by – Feedback loops – Documentation-driven Advantages – Documentation – Maintenance easier Disadvantages – Specifications Joe and Jane Johnson Mark Marberry

46. 46 Rapid Prototyping Model Linear model “Rapid”

47. 47 Three Key Points Do not turn into product Rapid prototyping may replace specification phase—never the design phase Comparison: – Waterfall model—try to get it right first time – Rapid prototyping—frequent change, then discard

48. 48 Waterfall and Rapid Prototyping Models Waterfall model – Many successes – Client needs Rapid prototyping model – Not proved – Has own problems Solution – Rapid prototyping for requirements phase – Waterfall for rest of life cycle

49. 49 Incremental Model Divide project into builds

50. 50 Incremental Model (contd) Waterfall, rapid prototyping models – Operational quality complete product at end Incremental model – Operational quality portion of product within weeks Less traumatic Smaller capital outlay, rapid return on investment Need open architecture—maintenance implications Variations used in object-oriented life cycle

51. 51 Incremental Model (contd) Problems – Build-and-fix danger – Contradiction in terms

52. 52 Incremental Model (contd) More risky version—pieces may not fit – CABTAB and its dangers

53. 53 Extreme Programming Somewhat controversial new approach Stories (features client wants) Estimate duration and cost of each story Select stories for next build Each build is divided into tasks Test cases for task are drawn up first Pair programming Continuous integration of tasks

54. 54 Unusual Features of XP Computers are put in center of large room lined with cubicles Client representative is always present Cannot work overtime for 2 successive weeks No specialization Refactoring

55. 55 Evaluating XP XP has had some successes Good when requirements are vague or changing Too soon to evaluate XP

56. 56 Synchronize-and Stabilize Model Microsoft’s life-cycle model Requirements analysis—interview potential customers Draw up specifications Divide project into 3 or 4 builds Each build is carried out by small teams working in parallel

57. 57 Synchronize-and Stabilize Model (contd) At the end of the day—synchronize (test and debug) At the end of the build—stabilize (freeze build) Components always work together – Get early insights into operation of product

58. 58 Spiral Model Simplified form – Waterfall model plus risk analysis Precede each phase by – Alternatives – Risk analysis Follow each phase by – Evaluation – Planning of next phase

59. 59 Simplified Spiral Model If risks cannot be resolved, project is immediately terminated

60. 60 Full Spiral Model Radial dimension: cumulative cost to date Angular dimension: progress through the spiral

61. 61 Full Spiral Model (contd)

62. 62 Analysis of Spiral Model Strengths – Easy to judge how much to test – No distinction between development, maintenance Weaknesses – For large-scale software only – For internal (in-house) software only

63. 63 Object-Oriented Life-Cycle Models Need for iteration within and between phases – Fountain model – Recursive/parallel life cycle – Round-trip gestalt – Unified software development process All incorporate some form of – Iteration – Parallelism – Incremental development Danger – CABTAB

64. 64 Fountain Model Features Overlap (parallelism) Arrows (iteration) Smaller maintenance circle

65. 65 Conclusions Different life-cycle models Each with own strengths Each with own weaknesses Criteria for deciding on a model include – The organization – Its management – Skills of the employees – The nature of the product Best suggestion – “Mix-and-match” life-cycle model

66. 66 XML Structured form of communication How components will communicate Freeform HTML Grammar and validation DOM and SAX

67. 67 History First came SGML Then HTML HTML became hugely successful XML is an attempt to recapture most of the power of SGML, without all the hassle

68. 68 Example XML Message Note: lots of examples from either http://www.w3schools.com or http://www.w3.org http://www.w3schools.com http://www.w3.org Tove Jani Reminder Don't forget me this weekend!

69. 69 Differences From HTML Stricter All tags closed Tags are case sensitive All attributes must be quoted – Avoid attributes, except for IDs True tag modifiers

70. 70 Grammar Specification DTD Schema We’re using schemas – Much nicer – Consistent: XML themselves Grammars explain structure to developers Can also be used for automated validation – Sloooooow

71. 71 XML Tools Many Apache tools among the most popular – Open source – C++ and Java versions available – Xerces DOM: suck into memory, give back tree structure SAX: parse sequentially, return events

72. 72 More XML JDOM XSLT SOAP

73. 73 CVS First, a word on race conditions Two threads within one program Both want to increment a variable Both read One writes The other writes Result: one increment, value clobbered

74. 74 More On CVS The same can happen with your coding process Two people working on same piece of code RCS: simple system for versioning and locking CVS: fancier, networkable system for checking out entire dev snapshots And then selectively committing changes

75. 75 CVS, Continued No locking Conflicts are marked inside the code You’ll also be notified if checking in a wrong version