SW Engineering Management

SOFTWARE ENGINEERING & MANAGEMENT "software work is the most complex that humanity has ever undertaken.” [Brooks, 95] Robert.Sayegh@gmail.com (2010)

Preface These slides reflect extensive research on what happens in the Software field worldwide. It aims to give perspective and motivate thoughts on what we do in our SW team. Robert.Sayegh@gmail.com (2010)

Disclaimer Disclaimer : all the following slides contain quotes from known books and articles – as such, each slide has a note for the relevant reference(s). Needless to mention, nothing beats reading through the references directly. Robert.Sayegh@gmail.com (2010)

Project Planning Robert.Sayegh@gmail.com (2010)

SW is Complex & Expensive! Large Software systems cost far more to build, and take much longer to construct, than the office buildings occupied by the companies that have commissioned the software. Really Large Software systems in the 250,000 FP size can cost more than building a domed football stadium, a 50-story skyscraper, or a 90,000 ton cruise ship. Not only are large systems expensive, but they also have one of the highest failure rates of any manufactured object in human history.  Software is not your typical happy ending, lives happily ever after story! Robert.Sayegh@gmail.com (2010)

SW Runway Projects Robert.Sayegh@gmail.com (2010)

Late = Defective Large systems usually run late because they contain so many defects or errors that they don’t work. Unfortunately, if this situation is not detected until testing begins it is too late for corrective actions to be fully successful. ( on-schedule until testing cycle syndrome ) Vista (125K FP) ERP SAP (300K FP) 1FP = 125 lines of code Robert.Sayegh@gmail.com (2010)

Poor Estimation #1 factor for runaway projects Most software estimates are performed at the beginning of the life cycle. This makes sense until we realize that estimates are obtained before the requirements are defined and thus before the problem is understood. Estimation, therefore, usually occurs at the wrong time. Oddly, there seems to be general agreement that this fact is correct. The practice it describes is absurd. Someone should be crying out to change things. But no one is. It is important to note that runaway projects, at least those that stem from poor estimation, do not usually occur because the programmers did a poor job of programming. Robert.Sayegh@gmail.com (2010)

Unstable Requirements #2 factor for Runway projects Nearly everyone accepts the fact that requirements must be allowed to change, and the only remaining disagreement is about how to keep control under those circumstances. If the problem was exploring requirements to lead them toward stability, the solution was seen to be prototyping. We would build a sample solution, according to this idea, and let the users try it out to see if it was what they wanted. The Extreme Programming methodology calls for a representative of the user community to reside with the software project team during development! Robert.Sayegh@gmail.com (2010)

Sounds familiar? Estimation is done at the wrong time Estimation is done by the wrong people Most software estimates are made either by upper management or by marketing. (Wrong) Estimations are not corrected Estimations are rarely adjusted as the project proceeds. Estimation is nevertheless the most important factor. As estimates are so faulty, you'd think they would be treated as relatively unimportant. Right? Wrong! There is little reason to be concerned when software projects don’t meet estimated target. But everyone is concerned anyway! There is a disconnect between management and programmers. In one research study of a project that failed to meet its estimates and was seen by its management as a failure, the technical participants saw it as the most successful project they had ever worked on. Robert.Sayegh@gmail.com (2010)

Programmers role In a research group, attendees asked to work on a small task, with deliberately too much to do and not enough time. Expectation : the attendees will try to do the whole job, do it correctly, and therefore will produce an unfinished product. Actual outcome : not so, these attendees scrambled mightily to achieve the impossible schedule, thus producing sketchy and shoddy products that appear to be complete but cannot possibly work. Robert.Sayegh@gmail.com (2010)

Programmers Role (cont.) Four factors determine the timelines: Cost, Schedule, Features, and Quality . Extreme Programmers suggest that after the “customer” chooses three of the four factors, the developers get to choose the fourth. This proposes to change the power structure that is currently such a major contributor to poor estimation. Robert.Sayegh@gmail.com (2010)

Project Quality Robert.Sayegh@gmail.com (2010)

Quality Attributes Portability a software product that is easily moved to another platform. Reliability a software product that does what it's supposed to do, dependably. Efficiency a software product that economizes on both running time and space consumption. Usability a software product that is easy and comfortable to use. Testability a software product that is easy to test. Understandability a software product that is easy for a maintainer to comprehend. Modifiability a software product that is easy for a maintainer to change. Robert.Sayegh@gmail.com (2010)

Quality (cont.) There is no correct, generalized ordering of these quality attributes. However, f or any one project, it is vitally important to establish a prioritized list of these attributes from the outset. Quality is not user satisfaction , meeting requirements , or meeting cost and schedule ! Robert.Sayegh@gmail.com (2010)

100% test coverage is far from enough Even if 100 percent test coverage (unit testing) were possible, that is not a sufficient criterion for testing. Most defects are “very complicated” 35 percent: missing logic paths (not part of code!) 40 percent: unique combination of logic paths. The goal is to minimize the number and especially the severity of those residual defects. There will always be residual defects in software, after even the most rigorous of error removal processes. There is no known magic solution to this problem. Producing successful, reliable software involves matching a variable number of error removal approaches, typically the more of them the better. Robert.Sayegh@gmail.com (2010)

Errors do cluster! ~80% of the defects come from ~20% of the modules About half the modules are error free (Boehm and Basili 2001) Some components are more complex than others Some programmers are better than others Bottom line: if you find a larger than expected number of errors in some module, keep looking! Robert.Sayegh@gmail.com (2010)

You cannot control what you cannot measure Robert.Sayegh@gmail.com (2010) Top Ten Software Metrics Reported Using Number of defects found after release 61% Number of changes or change requests 55% User or customer satisfaction 52% Number of defects found during development 50% Documentation completeness/accuracy 42% Time to identify/correct defects 40% Defect distribution by type/class 37% Error by major function/feature 32% Test coverage of specifications 31% Test coverage of code 31%

Robert.Sayegh@gmail.com (2010) Bottom Five Software Metrics Reported Using Module/design complexity 24% Number of source lines delivered 22% Documentation size/complexity 20% Number of reused source lines 16% Number of function points 10%

Project Design Robert.Sayegh@gmail.com (2010)

Design, Design, Design… Efficiency stems more from good design than from good coding. Design Patterns are widely accepted as better form of reuse than traditional code reuse (“ Designers rarely start from scratch ”!) Visser 87 Extreme Programming advocates simple design followed by ongoing refactoring to fix inefficiencies and errors in the design after it is coded. Robert.Sayegh@gmail.com (2010)

People Quality matters … a lot ! “ The most important practical finding [of our study] involves the striking individual differences in programmer performance... The researchers had found differences of up to 28 to 1 while trying to evaluate the productivity difference between batch and timesharing computer usage”. (Sackman 1968) “ Within a group of programmers, there may be an order of magnitude difference in capability“ (Schwartz 1968). “ Productivity variations of 5:1 between individuals are common “ (Boehm 1975). “ The variability among student programmers is well known, but the high variability among these highly experienced subjects was somewhat surprising “ (Myers 1978). Robert.Sayegh@gmail.com (2010)

Crucial human factor Peer reviews are both technical and sociological! Paying attention to one without the other is a recipe for disaster. There are some errors that most programmers tend to make (thought traps) Uninitialized parameter Missing a switch case Omitting deep design detail ... Rigorous inspections can remove up to 60% – 90% of errors from a software product. Even before the first test case is run. Robert.Sayegh@gmail.com (2010)

Man-Month Myth [Brook’s law] Complex / Undividable Simple/ Dividable Most typical / Only partially dividable Robert.Sayegh@gmail.com (2010)

Refactoring Refactor when you add a function Refactor when you fix a bug Refactor when you code review Most common problem with Refactoring is the “social” aspect! Robert.Sayegh@gmail.com (2010)

Hype Frenzy “ Software developers talk a lot about tools. They evaluate quite a few, buy a fair number, and use practically none.” Most software tool / technique improvements account for about a 5 to 35 percent increase in productivity and quality. Fallacy: Occasionally hype improvements get claimed by someone to have "order of magnitude" benefits. Problem: SW culture puts schedule conformance above all else, that there is no time to learn about new concepts. Robert.Sayegh@gmail.com (2010)

Project Maintenance Robert.Sayegh@gmail.com (2010)

Reuse vs. Rewrite If more than 20 to 25 percent of a component is to be revised, it is more efficient and effective to rewrite it from scratch For every 25 percent increase in problem complexity, there is a 100 percent increase in complexity of the software Robert.Sayegh@gmail.com (2010)

Suggested schedule guide Usually on time 30% Planning 15% Coding Hard to plan ahead 25% Unit Testing 25% System Testing The initial estimate, although most uncertain, is the most important. Making the initial estimate leads the manager to consider the various factors bearing on the size and complexity of the tasks. Robert.Sayegh@gmail.com (2010)

Maintenance is a solution, not a problem! Maintenance activity involves in average: 60% Enhancement (new features) 18% Adaptive maintenance (OS changes, etc.) 17% Error corrections (old bug fixes) 5% Refactoring (preventive maintenance) Software makes it easy (relatively) to change the product during its lifetime. Robert.Sayegh@gmail.com (2010)

Maintenance is a solution (cont.) Better software engineering development leads to more maintenance, not less. Systems found more reliable when developed using well known methodologies, tools, and techniques. They require repair less often. Such systems also found to have longer maintenance time! More modifications were queued is such systems simply because they were easier to change. Robert.Sayegh@gmail.com (2010)

References Facts and Fallacies of Software Engineering ( Robert L. Glass, 2002) Manager's Handbook for Software Development / (NASA SEL 84-101, 1990) Return of Investment (ROI) in SW Project Management (Carpers Jones, 2009) Software conflict, the art and science of software engineering ( Robert L. Glass, 2006) Refactoring, improving the design of existing code (Martin Fowler, 1999) The Mythical Man-Month. ( Brooks Frederick P. Jr., 1995) Why Software Fails (Robert N. Charette, Spectrum.ieee.org Sept. 2005) Robert.Sayegh@gmail.com (2010)

SW Engineering Management

More Related Content

What's hot (20)

Viewers also liked (7)

Similar to SW Engineering Management (20)

Recently uploaded (20)

SW Engineering Management

Editor's Notes