1 / 70

COMS W4156: Advanced Software Engineering

COMS W4156: Advanced Software Engineering. Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu http://york.cs.columbia.edu/classes/cs4156/. The Mythical Man-Month. Fred Brooks, 1975. Background. Fred Brooks began managing IBM’s OS/360 software development effort in 1964

satin
Télécharger la présentation

COMS W4156: Advanced Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. COMS W4156: Advanced Software Engineering Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu http://york.cs.columbia.edu/classes/cs4156/ Kaiser: COMS W4156 Fall 2006

  2. The Mythical Man-Month Fred Brooks, 1975 Kaiser: COMS W4156 Fall 2006

  3. Background • Fred Brooks began managing IBM’s OS/360 software development effort in 1964 • Brooks’ previous experience was in hardware design • OS/360 was (probably) the largest software system attempted to date at that time • OS/360 “was late, took more memory than was planned, costs were several times the estimate, and it did not perform very well until several releases after the first” • Planned for released in 1965 (low-end) and 1966 (high-end), both finished a year late, so another temporary OS was cobbled together so hardware could be used • Retired in 1972 (see http://ldworen.net/fun/os360obit.html) Kaiser: COMS W4156 Fall 2006

  4. Background • The MMM book results from analyzing the OS/360 experience, which was quite different from the 360 hardware effort • MMM was first published in 1975, 20th anniversary edition published in 1995 • Brooks now a Professor at University of North Carolina, Chapel Hill, with research interests in graphics, user interfaces and virtual worlds • http://www.cs.unc.edu/~brooks/ Kaiser: COMS W4156 Fall 2006

  5. The Tar Pit • Developing large software systems is “sticky” • Projects may emerge from the tar pit with running systems, but miss goals, schedules and budgets • “No one thing seems to cause the difficulty – any particular paw can be pulled away. But the accumulation of simultaneous and interacting factors brings slower and slower motion” • Analogy meant to convey that it is hard to discern the nature of the problem(s) facing software development Kaiser: COMS W4156 Fall 2006

  6. Program to Product *3 *3 *9 Kaiser: COMS W4156 Fall 2006

  7. What makes programming fun? • Sheer joy of creation • Pleasure of creating something useful for other people • Creating (and solving) puzzles • Life-long learning • Working in a tractable medium - software is extremely malleable Kaiser: COMS W4156 Fall 2006

  8. What’s not so fun about programming? • You have to be perfect! • You are rarely in complete control of the project • Design is fun; debugging is just work • Testing takes too long! • The program may be obsolete by the time its finished Kaiser: COMS W4156 Fall 2006

  9. Why are software projects late? • Estimating techniques are poorly developed • Our techniques confuse effort with progress • Since we are uncertain of our estimates, we don’t stick to them • Progress is poorly monitored • When slippage is recognized, we add people (“like adding gasoline to a fire”) Kaiser: COMS W4156 Fall 2006

  10. Optimism • “All programmers are optimists” • “All will go well” with the project – thus we don’t plan for slippage • However, with the sequential nature of our tasks, the chance is small that all will go well • One reason for optimism is the nature of creativity • Idea, implementation and interaction • The medium of creation constrains our ideas – in software the medium is extremely malleable, thus we expect few problems in implementation Kaiser: COMS W4156 Fall 2006

  11. The Mythical Man-Month • Cost does indeed vary as the product of the number of people and the number of months • Progress does not! • The unit of man-month [person-month] implies that people and months are interchangeable • This is only true when a task can be partitioned among many workers with no communication among them • When a task is sequential, more effort has no effect on the schedule – many tasks in software engineering have sequential constraints Kaiser: COMS W4156 Fall 2006

  12. MMM • Most tasks require communication among workers • Communication consists of • Training • Sharing information (intercommunication) • Training affects effort at worst linearly • Intercommunication adds n(n-1)/2 to effort if each worker must communicate with every other worker Kaiser: COMS W4156 Fall 2006

  13. Intercommunication effort Kaiser: COMS W4156 Fall 2006

  14. Comparison graphs Adding more people then lengthens, not shortens, the schedule months No communication With communication people Kaiser: COMS W4156 Fall 2006

  15. Scheduling • Brooks’ rule of thumb • 1/3 planning • 1/6 coding • ¼ component test • ¼ system test • In looking at other projects, Brooks found that few planned for 50% testing • But most actually spent 50% of their time testing • Many were on schedule until testing began Kaiser: COMS W4156 Fall 2006

  16. Development Team • How should the development team be arranged? • The problem: good programmers are much better than poor programmers • Typically 10 times better in productivity • Typically 5 times better in terms of program elegance Kaiser: COMS W4156 Fall 2006

  17. The dilemma of team size • Consider a 200-person project with 25 experienced managers (experienced at programming, not necessarily at managing) • The previous slide argues for firing the 175 workers and use the 25 managers as the team • OS/360 had over 1000 people working on it, consumed 5000 person-years of design, construction and documentation Kaiser: COMS W4156 Fall 2006

  18. Two needs to be reconciled • For efficiency and conceptual integrity a small team is preferred • To tackle large systems considerable resources are needed • One solution: Harlan Mill’s Surgical Team approach – one person performs the work (with a co-pilot), all others perform support tasks Kaiser: COMS W4156 Fall 2006

  19. Surgeon – chief programmer Co-pilot – like surgeon but less experienced Administrator – relieves surgeon of administrative tasks Editor – proof-reads documentation 2 Secretaries – support administrator and editor Program clerk – tracks versions Toolsmith – supports work of the Surgeon Tester Language lawyer (shared among multiple projects) Harlan Mills’ Surgical Team Kaiser: COMS W4156 Fall 2006

  20. How is this different? • Normally, work is divided equally – now only surgeon and copilot divide the work • Normally each person has equal say – now surgeon is absolute authority • Note communication paths are reduced • Normally 10 people → 45 paths • Surgical Team → 15 paths (or 13?) Kaiser: COMS W4156 Fall 2006

  21. How does this scale? • Reconsider the 200 person team – communication paths →19,900! • Create 20 ten-person surgical teams • Now only 20 surgeons must work together – 20 people → 190 paths • The key problem is ensuring conceptual integrity of the design Kaiser: COMS W4156 Fall 2006

  22. Conceptual Integrity • Brooks’ analogy: Cathedrals • Many cathedrals (e.g., Worms Cathedral) consist of contrasting design ideas • But Reims Cathedral was the result of 8 generations of builders repressing their own ideas and desires to build a cathedral that embodies the key design elements of the original architect • With respect to software, design by too many people results in conceptual disunity of a system, making the program hard to understand and use • Better to leave functionality out of a system if it causes the conceptual integrity of the design to break Kaiser: COMS W4156 Fall 2006

  23. Cathedral Architectures Kaiser: COMS W4156 Fall 2006

  24. Function vs. Complexity • An important metric for evaluating a system’s design is its ratio of functionality to conceptual complexity • Ease of use is enhanced only if the functionality provides more power than it takes to learn (and remember) how to use it in the first place Kaiser: COMS W4156 Fall 2006

  25. Software Architects as Aristocrats • Conceptual integrity requires that the design be the product of one mind • The architect (or surgeon) has ultimate authority - and ultimate responsibility • Does this imply too much power for architects? • Architect sets the structure of the system • Developers can then be creative in how system is implemented Kaiser: COMS W4156 Fall 2006

  26. The Second-System Effect • An engineer is careful in designing his/her first system – he/she realizes that they are working in uncharted territory • But in the second system, the engineer has some experience and wants to throw everything into the design • Symptoms: • Functional embellishment – to an unnecessary degree • Optimizations to obsolete functionality • The OS/360 linker had a sophisticated program overlay functionality, but the application architecture no longer depended on overlays – resulting in unnecessarily slow linkage Kaiser: COMS W4156 Fall 2006

  27. How to avoid it? • Employ extra self-discipline • Avoid functional ornamentation • Be aware of changes in assumptions • Strive for conceptual integrity • How do managers avoid it? • Insist on a senior architect with more than two systems under his/her belt Kaiser: COMS W4156 Fall 2006

  28. Communicating design decisions • Written specifications - “The Manual” • Answers questions • Conceptual integrity • Demands high precision • Telephone log – make sure to capture all design decisions • Product test – external test group keeps implementation honest Kaiser: COMS W4156 Fall 2006

  29. Formal Definitions • Natural language is not precise • Notations help express precise semantics – however, natural language is often needed to “explain” the meaning to the uninitiated • What about using an implementation as the formal definition? • Advantages: precise specification • Disadvantages: Over-prescription, potential for inelegance, may be modified • Inconsistencies between multiple implementations can identify problems in the specs – with only one implementation its easier to change the manual Kaiser: COMS W4156 Fall 2006

  30. Why did the Tower of Babel Fail? • Communication (the lack of it) made it impossible to coordinate • How do you communicate in large project teams? – informal (telephone, email), meetings, workbook • Workbook • Structure placed on project’s documentation • Technical prose lives a long time, best to get it structured formally from the beginning, also helps with distribution of information Kaiser: COMS W4156 Fall 2006

  31. Reducing communication paths • Communication needs are reduced by • Division of labor • Specialization of function • A tree structure often results from applying this principle • However this serves power structures better than communication (since communication between siblings often needed) • So communication structure is often a network Kaiser: COMS W4156 Fall 2006

  32. Organizational Structure • Brooks outlines • Mission, producer, director, schedule, division of labor, interfaces between the parts • The new items are the producer and the director • Producer manages project and obtains resources (product manager) • Director manages technical detail (program manager) Kaiser: COMS W4156 Fall 2006

  33. Calling the shot • Estimates for programming in the small don’t scale – you need to add planning, documentation, testing, system integration and training in large projects • Effort vs. program size increases exponentially • Number of technical work-hours was being vastly overestimated Kaiser: COMS W4156 Fall 2006

  34. Plan to throw one away • You will anyway • Consider chemical engineers: scaling a laboratory result up to actual (and practical) use requires a pilot step – e.g., desalting water 10,000 gallons/day first, then 2,000,000 • Software projects typically plan to deliver the first thing they build to customers • Typically hard to use, buggy, inefficient, etc. • Experience shows you will discard a lot of the first implementation anyway (wrt version 2) Kaiser: COMS W4156 Fall 2006

  35. Rapid prototypes • Help gain early feedback • Intended from start to be thrown away • Brooks instead focuses on planning for change in a large software project • Management question: • Plan to build a system to throwaway • Experience gained, feedback can be applied • Plan to build a throwaway that is delivered to the customer • User is aggravated and demands support Kaiser: COMS W4156 Fall 2006

  36. Change • Causes: • Both the actual need and the user’s perception of that need will change as programs are built, tested and used • Other factors – hardware, assumptions, environment • Handling: • Modularization and subroutines • Precise and complete interfaces • Standard calling sequences • Complete documentation • High-level languages • Configuration management Kaiser: COMS W4156 Fall 2006

  37. Organizational issues • Culture must be conducive to documenting decisions, otherwise nothing gets documented • Other points to consider • Job titles • Keeping senior people trained Kaiser: COMS W4156 Fall 2006

  38. Maintenance • Two steps forward and one step back • Life cycle of bugs • Fixing a bug has a chance of adding another – lots of regression testing needed • One step forward and one step back • Maintenance is an entropy-increasing process • As maintenance proceeds, system is less structured than before, conceptual integrity degrades Kaiser: COMS W4156 Fall 2006

  39. The whole and the parts • Top-down design • Design as a set of refinement steps • Use of abstraction at each level • Modular decomposition • Other techniques • Structured programming • Object-oriented design • Reuse Kaiser: COMS W4156 Fall 2006

  40. Hatching a catastrophe • A project gets to be a year late one day at a time • Major calamities are “easy” to handle – whole team pulls together and solves it • Day to day slippage is harder to recognize Kaiser: COMS W4156 Fall 2006

  41. How to keep it on track? • Have a schedule • Overestimates come steadily down as the activity proceeds • Underestimates do not change until scheduled time draws near • Have milestones • Not “coding complete” • But “specifications signed by architects” • Or “debugged component passes all tests” • Track the critical path – who is waiting on whom to finish what • Address the “status disclosure problem” • Managers must distinguish between action meetings and status meetings – if inappropriate action taken in response to a status report, it discourages honest status reports Kaiser: COMS W4156 Fall 2006

  42. No Silver Bullet – Essence and Accident in Software Engineering Fred Brooks, 1986 Kaiser: COMS W4156 Fall 2006

  43. No Silver Bullet “There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity” Kaiser: COMS W4156 Fall 2006

  44. Why a Silver Bullet? • http://www.fvza.org/wmyths.html Kaiser: COMS W4156 Fall 2006

  45. Past Gains in Software Productivity • Came from removing artificial barriers such as severe hardware constraints, awkward programming languages, lack of machine time • Unless at least 9/10ths of what software engineers do today is still devoted to the accidental (incidental), then shrinking all the accidental activities to zero time will not give an order of magnitude improvement Kaiser: COMS W4156 Fall 2006

  46. Essence vs. Accident • Essential: • The difficulties inherent in the nature of the software • The fashioning of the complex conceptual structures that compose the abstract software entity • The specification, design and testing of these conceptual constructs • Accidental (or incidental): • Those difficulties that attend software’s production but that are not inherent • The labor of representing these abstract entities in programming languages and the mapping of these onto machine languages within space and speed constraints • Testing the fidelity of the representation Kaiser: COMS W4156 Fall 2006

  47. Past Silver Bullets(from Brooks) • High-level languages (vs. bits, registers, conditions, branches) • Time-sharing (vs. batch programming) • Unified programming environments (e.g., Unix) • All addressed accident, not essence Kaiser: COMS W4156 Fall 2006

  48. Past Silver Bullets(mentioned by others) • Stored programs • Keyboard and mouse • Subroutine and return stack • Assemblers, compilers and interpreters • Multitasking • Files and file system hierarchies • Relational databases • Video display (vs. teletype) and display editor • Data networks and modems Kaiser: COMS W4156 Fall 2006

  49. No Silver Bullet – Precise Definition “There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity” Kaiser: COMS W4156 Fall 2006

  50. Comparison with Hardware • The anomaly is not that software progress is so slow, but that computer hardware progress is so fast • No other technology since civilization began has seen six orders of magnitude price-performance gain in 30 years [written in 1986] • In no other technology can one choose to take the gain in either improved performance or in reduced costs • We cannot expect ever to see two-fold gains in software productivity every two years Kaiser: COMS W4156 Fall 2006

More Related