sw engineering management
DESCRIPTION
Literature overview on SW engineering and management processesTRANSCRIPT
SOFTWARE ENGINEERING & MANAGEMENT
"software work is the most complex that humanity has ever undertaken.” [Brooks, 95]
[email protected] (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.
2
[email protected] (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.
[email protected] (2010)
3
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!
5
[email protected] (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
7
[email protected] (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.
8
[email protected] (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!
9
[email protected] (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.
10
[email protected] (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.
11
[email protected] (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.
12
[email protected] (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.
14
[email protected] (2010)
Quality (cont.)
There is no correct, generalized ordering of these quality attributes.
However, for 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!
15
[email protected] (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.
16
[email protected] (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!
17
[email protected] (2010)
You cannot controlwhat you cannot measure
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%
18
[email protected] (2010)
Bottom Five Software Metrics Reported UsingModule/design complexity 24%Number of source lines delivered 22%Documentation size/complexity 20%Number of reused source lines 16%
Number of function points 10%
19
[email protected] (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.
21
[email protected] (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).
22
[email protected] (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.
23
[email protected] (2010)
Man-Month Myth [Brook’s law]
Complex / Undividable
Simple/ Dividable
Most typical / Only partially dividable
24
[email protected] (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!
25
[email protected] (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.
26
[email protected] (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
28
[email protected] (2010)
Suggested schedule guide
Usually on time• 30% Planning• 15% CodingHard 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.
29
[email protected] (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.
30
[email protected] (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.
31
[email protected] (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)
32
[email protected] (2010)