Saturday, July 05, 2014
Wednesday, July 02, 2014
Facts and Fallacies of Software Engineering
About Management
People
#Fact 1 - The most important factor in software work is not the tools and techniques used by the programmers, but rather the quality of the programmers themselves.
#Fact 2 - The best programmers are up to 28 times better than the worst programmers, according to "individual differences" research. Given that their pay is never commensurate, they are the biggest bargains in the software field.
#Fact 3 - Adding people to a late project makes it later.
#Fact 4 - The working environment has a profound impact on productivity and product quality.
Tools and Techniques
#Fact 5 - Hype is the plague on the house of software. Most software tool and technique improvements account for about a 5 to 35 percent increase in productivity and quality. But at one time or another, most of those same improvements have been claimed by someone to have "order of magnitude" benefits.
#Fact 6 - Learning a new tool or technique actually lowers programmer productivity and product quality initially. The eventual benefit is achieved only after this learning curve is overcome. Therefore, it is worth adopting new tools and techniques, but only (a) if their value is seen realistically and (b) if patience is used in measuring benefits.
#Fact 7 - Software developers talk a lot about tools. They evaluate quite a few, buy a fair number, and use practically none.
Estimation
#Fact 8 - One of the two most common causes of runaway projects is poor estimation.
#Fact 9 - 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.
#Fact 10 - Most software estimates are made either by upper management or by marketing, not by the people who will build the software or their managers. Estimation is, therefore, done by the wrong people.
#Fact 11 - Software estimates are rarely adjusted as the project proceeds. Thus those estimates done at the wrong time by the wrong people are usually not corrected.
#Fact 12 - Since estimates are so faulty, there is little reason to be concerned when software projects do not meet estimated targets. But everyone is concerned anyway
#Fact 13 - There is a disconnect between management and their 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.
#Fact 14 - The answer to a feasibility study is almost always "yes."
Reuse
#Fact 15 - Reuse-in-the-small (libraries of subroutines) began nearly 50 years ago and is a well-solved problem.
#Fact 16 - Reuse-in-the-large (components) remains a mostly unsolved problem, even though everyone agrees it is important and desirable.
#Fact 17 - Reuse-in-the-large works best in families of related systems and thus is domain-dependent. This narrows the potential applicability of reuse-in-the-large.
#Fact 18 - There are two "rules of three" in reuse: (a) It is three times as difficult to build reusable components as single use components, and (b) a reusable component should be tried out in three different applications before it will be sufficiently general to accept into a reuse library.
#Fact 19 - Modification of reused code is particularly error-prone. 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.
#Fact 20 - Design pattern reuse is one solution to the problems inherent in code reuse.
Complexity
#Fact 21 - For every 25 percent increase in problem complexity, there is a 100 percent increase in complexity of the software solution. That's not a condition to try to change (even though reducing complexity is always a desirable thing to do); that's just the way it is.
#Fact 22 -Eighty percent of software work is intellectual. A fair amount of it is creative. Little of it is clerical.
About the Life Cycle
Requirements
#Fact 23 - One of the two most common causes of runaway projects is unstable requirements
#Fact 24 - Requirements errors are the most expensive to fix when found during production but the cheapest to fix early in development.
#Fact 25 - Missing requirements are the hardest requirements errors to correct.
Design
#Fact 26 - When moving from requirements to design, there is an explosion of "derived requirements" (the requirements for a particular design solution) caused by the complexity of the solution process. The list of these design requirements is often 50 times longer than the list of original requirements.
#Fact 27 - There is seldom one best design solution to a software problem.
#Fact 28 - Design is a complex, iterative process. The initial design solution will likely be wrong and certainly not optimal.
Coding
#Fact 29 - Programmers shift from design to coding when the problem is decomposed to a level of "primitives" that the designer has mastered. If the coder is not the same person as the designer, the designer's primitives are unlikely to match the coder's primitives, and trouble will result.
#Fact 30 - COBOL is a very bad language, but all the others (for business data processing) are so much worse.
Error Removal
#Fact 31 - Error removal is the most time-consuming phase of the life cycle.
Testing
#Fact 32 - Software that a typical programmer believes to be thoroughly tested has often had only about 55 to 60 percent of its logic paths executed. Using automated support, such as coverage analyzers, can raise that roughly to 85 to 90 percent. It is nearly impossible to test software at the level of 100 percent of its logic paths.
#Fact 33 - Even if 100 percent test coverage were possible, that is not a sufficient criterion for testing. Roughly 35 percent of software defects emerge from missing logic paths, and another 40 percent from the execution of a unique combination of logic paths. They will not be caught by 100 percent coverage.
#Fact 34 - It is nearly impossible to do a good job of error removal without tools. Debuggers are commonly used, but others, such as coverage analyzers, are not.
#Fact 35 - Test automation rarely is. That is, certain testing processes can and should be automated. But there is a lot of the testing activity that cannot be automated.
#Fact 36 - Programmer-created built-in debug code, preferably optionally included in the object code based on compiler parameters, is an important supplement to testing tools
Reviews and Inspections
#Fact 37 - Rigorous inspections can remove up to 90 percent of errors from a software product before the first test case is run
#Fact 38 - In spite of the benefits of rigorous inspections, they cannot and should not replace testing.
#Fact 39 - Postdelivery reviews (some call them "retrospectives") are generally acknowledged to be important, both from the point of view of determining customer satisfaction and from the point of view of process improvement. But most organizations do not do postdelivery reviews.
#Fact 40 - Peer reviews are both technical and sociological. Paying attention to one without the other is a recipe for disaster
Maintenance
#Fact 41 - Maintenance typically consumes 40 to 80 percent (average, 60 percent) of software costs. Therefore, it is probably the most important life cycle phase of software.
#Fact 42 - Enhancement is responsible for roughly 60 percent of software maintenance costs. Error correction is roughly 17 percent. Therefore, software maintenance is largely about adding new capability to old software, not fixing it.
#Fact 43 - Maintenance is a solution, not a problem.
#Fact 44 - In examining the tasks of software development versus software maintenance, most of the tasks are the same—except for the additional maintenance task of "understanding the existing product." This task consumes roughly 30 percent of the total maintenance time and is the dominant maintenance activity. Thus it is possible to claim that maintenance is a more difficult task than development.
#Fact 45 - Better software engineering development leads to more maintenance, not less.
About Quality
Quality
#Fact 46 - Quality is a collection of attributes.
#Fact 47 - Quality is not user satisfaction, meeting requirements, meeting cost and schedule targets, or reliability.
Reliability
#Fact 48 - There are errors that most programmers tend to make.
#Fact 49 - Errors tend to cluster.
#Fact 50 - There is no single best approach to software error removal.
#Fact 51 - Residual errors will always persist. The goal should be to minimize or eliminate severe errors.
#Fact 52 - Efficiency stems more from good design than from good coding.
#Fact 53 - High-order language (HOL) code, with appropriate compiler optimizations, can be about 90 percent as efficient as the comparable assembler code. Or even higher, for some complex modern architectures.
#Fact 54 - There are tradeoffs between size and time optimization. Often, improving one degrades the other.
About Research
#Fact 55 - Many software researchers advocate rather than investigate. As a result, (a) some advocated concepts are worth far less than their advocates believe, and (b) there is a shortage of evaluative research to help determine what the value of such concepts really is.
People
#Fact 1 - The most important factor in software work is not the tools and techniques used by the programmers, but rather the quality of the programmers themselves.
#Fact 2 - The best programmers are up to 28 times better than the worst programmers, according to "individual differences" research. Given that their pay is never commensurate, they are the biggest bargains in the software field.
#Fact 3 - Adding people to a late project makes it later.
#Fact 4 - The working environment has a profound impact on productivity and product quality.
Tools and Techniques
#Fact 5 - Hype is the plague on the house of software. Most software tool and technique improvements account for about a 5 to 35 percent increase in productivity and quality. But at one time or another, most of those same improvements have been claimed by someone to have "order of magnitude" benefits.
#Fact 6 - Learning a new tool or technique actually lowers programmer productivity and product quality initially. The eventual benefit is achieved only after this learning curve is overcome. Therefore, it is worth adopting new tools and techniques, but only (a) if their value is seen realistically and (b) if patience is used in measuring benefits.
#Fact 7 - Software developers talk a lot about tools. They evaluate quite a few, buy a fair number, and use practically none.
Estimation
#Fact 8 - One of the two most common causes of runaway projects is poor estimation.
#Fact 9 - 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.
#Fact 10 - Most software estimates are made either by upper management or by marketing, not by the people who will build the software or their managers. Estimation is, therefore, done by the wrong people.
#Fact 11 - Software estimates are rarely adjusted as the project proceeds. Thus those estimates done at the wrong time by the wrong people are usually not corrected.
#Fact 12 - Since estimates are so faulty, there is little reason to be concerned when software projects do not meet estimated targets. But everyone is concerned anyway
#Fact 13 - There is a disconnect between management and their 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.
#Fact 14 - The answer to a feasibility study is almost always "yes."
Reuse
#Fact 15 - Reuse-in-the-small (libraries of subroutines) began nearly 50 years ago and is a well-solved problem.
#Fact 16 - Reuse-in-the-large (components) remains a mostly unsolved problem, even though everyone agrees it is important and desirable.
#Fact 17 - Reuse-in-the-large works best in families of related systems and thus is domain-dependent. This narrows the potential applicability of reuse-in-the-large.
#Fact 18 - There are two "rules of three" in reuse: (a) It is three times as difficult to build reusable components as single use components, and (b) a reusable component should be tried out in three different applications before it will be sufficiently general to accept into a reuse library.
#Fact 19 - Modification of reused code is particularly error-prone. 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.
#Fact 20 - Design pattern reuse is one solution to the problems inherent in code reuse.
Complexity
#Fact 21 - For every 25 percent increase in problem complexity, there is a 100 percent increase in complexity of the software solution. That's not a condition to try to change (even though reducing complexity is always a desirable thing to do); that's just the way it is.
#Fact 22 -Eighty percent of software work is intellectual. A fair amount of it is creative. Little of it is clerical.
About the Life Cycle
Requirements
#Fact 23 - One of the two most common causes of runaway projects is unstable requirements
#Fact 24 - Requirements errors are the most expensive to fix when found during production but the cheapest to fix early in development.
#Fact 25 - Missing requirements are the hardest requirements errors to correct.
Design
#Fact 26 - When moving from requirements to design, there is an explosion of "derived requirements" (the requirements for a particular design solution) caused by the complexity of the solution process. The list of these design requirements is often 50 times longer than the list of original requirements.
#Fact 27 - There is seldom one best design solution to a software problem.
#Fact 28 - Design is a complex, iterative process. The initial design solution will likely be wrong and certainly not optimal.
Coding
#Fact 29 - Programmers shift from design to coding when the problem is decomposed to a level of "primitives" that the designer has mastered. If the coder is not the same person as the designer, the designer's primitives are unlikely to match the coder's primitives, and trouble will result.
#Fact 30 - COBOL is a very bad language, but all the others (for business data processing) are so much worse.
Error Removal
#Fact 31 - Error removal is the most time-consuming phase of the life cycle.
Testing
#Fact 32 - Software that a typical programmer believes to be thoroughly tested has often had only about 55 to 60 percent of its logic paths executed. Using automated support, such as coverage analyzers, can raise that roughly to 85 to 90 percent. It is nearly impossible to test software at the level of 100 percent of its logic paths.
#Fact 33 - Even if 100 percent test coverage were possible, that is not a sufficient criterion for testing. Roughly 35 percent of software defects emerge from missing logic paths, and another 40 percent from the execution of a unique combination of logic paths. They will not be caught by 100 percent coverage.
#Fact 34 - It is nearly impossible to do a good job of error removal without tools. Debuggers are commonly used, but others, such as coverage analyzers, are not.
#Fact 35 - Test automation rarely is. That is, certain testing processes can and should be automated. But there is a lot of the testing activity that cannot be automated.
#Fact 36 - Programmer-created built-in debug code, preferably optionally included in the object code based on compiler parameters, is an important supplement to testing tools
Reviews and Inspections
#Fact 37 - Rigorous inspections can remove up to 90 percent of errors from a software product before the first test case is run
#Fact 38 - In spite of the benefits of rigorous inspections, they cannot and should not replace testing.
#Fact 39 - Postdelivery reviews (some call them "retrospectives") are generally acknowledged to be important, both from the point of view of determining customer satisfaction and from the point of view of process improvement. But most organizations do not do postdelivery reviews.
#Fact 40 - Peer reviews are both technical and sociological. Paying attention to one without the other is a recipe for disaster
Maintenance
#Fact 41 - Maintenance typically consumes 40 to 80 percent (average, 60 percent) of software costs. Therefore, it is probably the most important life cycle phase of software.
#Fact 42 - Enhancement is responsible for roughly 60 percent of software maintenance costs. Error correction is roughly 17 percent. Therefore, software maintenance is largely about adding new capability to old software, not fixing it.
#Fact 43 - Maintenance is a solution, not a problem.
#Fact 44 - In examining the tasks of software development versus software maintenance, most of the tasks are the same—except for the additional maintenance task of "understanding the existing product." This task consumes roughly 30 percent of the total maintenance time and is the dominant maintenance activity. Thus it is possible to claim that maintenance is a more difficult task than development.
#Fact 45 - Better software engineering development leads to more maintenance, not less.
About Quality
Quality
#Fact 46 - Quality is a collection of attributes.
#Fact 47 - Quality is not user satisfaction, meeting requirements, meeting cost and schedule targets, or reliability.
Reliability
#Fact 48 - There are errors that most programmers tend to make.
#Fact 49 - Errors tend to cluster.
#Fact 50 - There is no single best approach to software error removal.
#Fact 51 - Residual errors will always persist. The goal should be to minimize or eliminate severe errors.
#Fact 52 - Efficiency stems more from good design than from good coding.
#Fact 53 - High-order language (HOL) code, with appropriate compiler optimizations, can be about 90 percent as efficient as the comparable assembler code. Or even higher, for some complex modern architectures.
#Fact 54 - There are tradeoffs between size and time optimization. Often, improving one degrades the other.
About Research
#Fact 55 - Many software researchers advocate rather than investigate. As a result, (a) some advocated concepts are worth far less than their advocates believe, and (b) there is a shortage of evaluative research to help determine what the value of such concepts really is.
Wednesday, June 25, 2014
Software Complexity
Software is more complex, for the effort and the expense required to construct it, than most artifacts produced by human endeavor. Assuming it costs $ 50 (USD) per line of code to construct a one - million line program (specify, design, implement, verify, validate, and deliver it), the resulting cost will be $ 50,000,000. While this is a large sum of money, it is a small fraction of the cost of constructing a complex spacecraft, a skyscraper, or a naval aircraft carrier.
Brooks says, “ Software entities are more complex for their size [emphasis added] than perhaps any other human construct, because no two parts are alike (at least
above the statement level). ” It is diffi cult to visualize the size of a software program because software has no physical attributes; however, if one were to print a one - million line program the stack of paper would be about 10 feet (roughly 3 meters) high if the program were printed 50 lines per page. The printout would occupy a volume of about 6.5 cubic feet. Biological entities such as human beings are of similar volume and they are far more complex than computer software, but there are few, if any, human - made artifacts of comparable size that are as complex as software.
Brooks says, “ Software entities are more complex for their size [emphasis added] than perhaps any other human construct, because no two parts are alike (at least
above the statement level). ” It is diffi cult to visualize the size of a software program because software has no physical attributes; however, if one were to print a one - million line program the stack of paper would be about 10 feet (roughly 3 meters) high if the program were printed 50 lines per page. The printout would occupy a volume of about 6.5 cubic feet. Biological entities such as human beings are of similar volume and they are far more complex than computer software, but there are few, if any, human - made artifacts of comparable size that are as complex as software.
How is the java memory pool divided?
Heap memory
The heap memory is the runtime data area from which the Java VM allocates memory for all class instances and arrays. The heap may be of a fixed or variable size. The garbage collector is an automatic memory management system that reclaims heap memory for objects.
- Eden Space: The pool from which memory is initially allocated for most objects.
- Survivor Space: The pool containing objects that have survived the garbage collection of the Eden space.
- Tenured Generation: The pool containing objects that have existed for some time in the survivor space.
Non-heap memory
Non-heap memory includes a method area shared among all threads and memory required for the internal processing or optimization for the Java VM. It stores per-class structures such as a runtime constant pool, field and method data, and the code for methods and constructors. The method area is logically part of the heap but, depending on the implementation, a Java VM may not garbage collect or compact it. Like the heap memory, the method area may be of a fixed or variable size. The memory for the method area does not need to be contiguous.
- Permanent Generation: The pool containing all the reflective data of the virtual machine itself, such as class and method objects. With Java VMs that use class data sharing, this generation is divided into read-only and read-write areas.
- Code Cache: The HotSpot Java VM also includes a code cache, containing memory that is used for compilation and storage of native code.
Monday, June 23, 2014
Sheep
Harmlessly passing your time in the grassland away
Only dimly aware of a certain unease in the air
You better watch out,
There may be dogs about
I've looked over Jordan, and I have seen.
Things are not what they seem
Only dimly aware of a certain unease in the air
You better watch out,
There may be dogs about
I've looked over Jordan, and I have seen.
Things are not what they seem
Saturday, June 14, 2014
Friday, June 13, 2014
Thursday, June 12, 2014
Sunday, June 01, 2014
Friday, May 30, 2014
Saturday, May 24, 2014
Thursday, May 22, 2014
Sunday, May 18, 2014
Saturday, May 10, 2014
Thursday, May 01, 2014
Subscribe to:
Posts (Atom)