CS 451 Software Engineering Readings on Software EngineeringWhy Software Jewels Are Rare? by David ParnasWhy Software Jewels Are Rare? by David ParnasWhy Software Jewels Are Rare?Why Software Jewels Are Rare?Why Software Jewels Are Rare?On Programming LanguagesBasic Engineering RulesSlide 9Our Worst Current Development Practices by Capers JonesOur Worst Current Development Practices by Capers JonesFailuresUndesirable PracticesUndesirable Practices (cont’d)RecommendationsSlide 16Slide 17Slide 18Essence vs. AccidentsDifficulty with Building SoftwareEssential DifficultiesPast Breakthroughs Solved Accidental DifficultiesHopes for the SilverHopes for the Silver (cont’d)Promising Attacks on the Conceptual EssenceSlide 26Toward a Discipline of SE by Anthony I. WassermanFundamental Concepts of SEFundamental Concepts of SE (cont’d)Fundamental Concepts of SE (cont’d)Fundamental Concepts of SE (cont’d)Fundamental Concepts of SE (cont’d)CS 451Software EngineeringReadings on Software Engineering 1Why Software Jewels Are Rare?by David Parnas•Who is David Parnas?•What is this paper about?2Why Software Jewels Are Rare?by David Parnas•Who is David Parnas?•What is this paper about?–What do we need to do to create jewels•What is a real jewel:–A well-structured program written in a consistent style, free of kludges, developed so that each component is simple and organized, and designed so that the product is easy to change.•Most of the s/w is ugly, unreliable, and hard to change.3Why Software Jewels Are Rare?•Why do software jewels remain rare?•Hard to distinguish between “essentials” and “luxuries” –for some, icons are important –fat vs. muscle•Customers will select “tools” over “jewels”.4Why Software Jewels Are Rare?•Designers don’t have to omit features to build “lean software”. Must design the product so that newly added features –do not eliminate useful capabilities –make good use of capabilities already present for other purposes –can be ignored or deleted by people who don’t want them.•Software ages.5Why Software Jewels Are Rare?•Performance goals and hardware limitation often interfere with structure.•Commercial success is a huge constraint (for creating jewels).•Spend time studying previous efforts and identifying the reasons for their poor structure. Avoid repeating mistakes that others made.•Being original should not be our objective – solving problems should be.6On Programming Languages•The issue is design, NOT programming language.•Beautiful, lean software have been written in Assembly, FORTRAN, and even C. Bad software have also been written with these languages.•Many times, as designers, we do not the “freedom to choose” the programming language.•Languages that prevent programming errors are as feasible as knives that can cut meat but not hands. We need sharp tools to do our work.7Basic Engineering Rules•Programs are not just written; they have to be planned.•Design before implementing.•Document the design.•Review and analyze the documented design.•Review implementation for consistency with the design.89Our Worst Current Development Practicesby Capers Jones•Who is Capers Jones?•What is this paper about?10Our Worst Current Development Practicesby Capers Jones•Who is Capers Jones?–Software consultant / researcher with lots of data.•What is this paper about?–Project Management issues.:–Our industry lacks a solid empirical foundation of measured results.11Failures•“There are two kinds of failures: those who though and never did, and those who did and never thought.”•Definition of failure:–terminated–cost or schedule > 50%–lawsuit12Undesirable Practices•No historical software-measurement data.–What kind of measurement data?–Project mgrs, executives, and clients are blind to the realities of software development.•Rejection of accurate estimates.•Failure to use automated estimating tools and automated planning tools.–Both estimation and planning tools exist•Excessive, irrational schedule pressure and creep in user requirements–Reqs change at an average rate of 1% per month ???13Undesirable Practices (cont’d)•Failure to monitor progress and to perform formal risk management.–No good indicators of possible success or failure.•Failure to use design review and code inspections.14Recommendations•Need a well-formed risk analysis and milestone tracking program.•Executives and clients should not reject well-formed estimates, just because they don’t like the results.•Milestones should include the successful completion of formal inspections of: –Requirements and Specification–Source code–Test materials–User manuals1516No Silver Bullet: Essence & Accidents of Software Engineeringby Fred Brooks•Who is Fred Brooks?•What is this paper about?17No Silver Bullet: Essence & Accidents of Software Engineeringby Fred Brooks•Who is Fred Brooks?–Managed the development of the IBM’s 360 family of computers and OSs.–Author of the Mythical Man-Month•“Adding manpower to a late software project makes it later.”–Recipient of ACM’s Turing Award (1999)•What is this paper about?–“There is no single development, in either technology or management technique, that by itself promises an even one order-of-magnitude improvement in productivity, in reliability, in simplicity”.18Essence vs. Accidents•Essence: difficulties inherent in the nature of s/w. •Accidents: difficulties that today attend the production of s/w but are not inherent.19Difficulty with Building Software•“I believe the hard part of building s/w to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. Syntax errors are fuzz compared with the conceptual errors.”20Essential Difficulties•Complexity–affects communication, dealing with all possible states of a program, understanding the structure of the program, extending the program, etc.•Conformity•Changeability–manufactured things are infrequently changed after manufacture; s/w is constantly subject to pressure to change.•Invisibility–the structure of s/w remains “univisualizable”, hard to use some of the most powerful conceptual tools we have21Past Breakthroughs Solved Accidental Difficulties•High-level languages–High-level languages have helped us be more productive and develop