3.Stand design approaches to typically challenging areas—including exception handling, internationalization andlocalization, portability, string storage, input/output, memory management, data storage, floating-point arithmetic,database design, performance, and reuse4.Design considerations unique to the application domain—such as financial, scientific, embedded systems, real-timesystems, and safety-critical software.5.Architectural schemes—such as subsystem organization, layering6.Use of design tools.Design serves as the foundation for construction, project scheduling, project tracking, and project control.
Fundamentals1.Coding practices—including variable and function naming, layout, and documentation2.Data-related concepts --such as scope, persistence, and binding3.Guidelines for using specific types of data—such as integer, floating-point, arrays …4.Control-related concepts—including organizing strait-line code, using conditionals, controlling loops …5.Assertions and other code-centered error-detection practices6.Rules for packaging code into routines, modules, classes, and likes7.Unit-testing and debugging practices8.Integration strategies—such as incremental integration, big-bang integration, and evolutionary development9.Code-tuning strategies and practices10.The ins and outs of the particular programming language you’re using11.Use of constructions tools—including environments, group work support, and code generators
4.Software Configuration Management
Is the practice of managing project artifacts so that the project stays in a consistent state over time.Includes practices for evaluating proposed changes, tracking changes, and handling multiple versions.Without configuration management, your teammates can change part of the design and forget to tell you.
When a software product has too many defects, developers spend more time fixing the software than they spend writing it.Some projects try to save time by reducing the time spent on quality assurance practices such as design and code reviews. Other projects—running late—try to make up for lost time by compressing the testing schedule, which is vulnerable to reduction because it’susually the critical path item at the end of the project.Poor quality is one of the most common reasons for schedule overruns.Up to four times the normal number of defects are reported for released products that were developed under excessive schedule pressure.Rule of thumb, every hour you spend on defect prevention will reduce your repair time 3 to 10 hours. The further from its origin that adefect is detected, the more it will cost to fix.
A.Error Prone Modules
About 20% of the modules in a program are typically responsible for about 80 % of the errors.Error prone modules tend to be more complex than other modules in the system, less structured, and unusually large.If development speed is important, make identification and redesign of error-prone modules a priority.
The two basic kinds of execution testing are (1) units tests, in which the developer checks his or her own code to verify that it workscorrectly, and (2) system tests, in which an independent tester checks to see whether the system operates as expected.
Used to detect defects in requirements, design, code, test cases, or other project artifacts.1.Walkthroughs—refers to any meeting at which two or more developers review technical work with the purpose of improving its quality. They are useful to rapid development because you can use them to detect defects well beforetesting.2.Code reading—the author of the code hands out source listing to two or more reviewers. The reviewers read the code andreport any errors to the author.3.Inspections—are a kind of formal technical review that has been shown be extremely effective in detecting defectsthroughout a project. Developers receive special training in inspections and play specific roles during the inspection:moderator, reviewers, author, and scribe. May be up to 20 times more efficient than testing.