Quality is the degree to which a component, system or process meets specified requirements or customer needs and expectations.
Software quality is the degree of conformance to explicit or implicit requirements and expectations summry it into simple words
Software quality can be understood as how well a piece of software meets the specified requirements and fulfills the expectations of its users. It's about how closely the software matches what it's supposed to do and how well it performs the tasks it's designed for.
what is meant by external and internal charactersitics of software
External characteristics of software refer to aspects that are directly observable by the users, such as user interface design, ease of use, response time, and performance. These characteristics are concerned with how the software behaves and interacts with its users.
On the other hand, internal characteristics of software are not directly observable by the users and pertain to the design and structure of the software. These include aspects such as maintainability, reliability, scalability, and security. Internal characteristics focus on the software's ability to be maintained, modified, and reused, as well as its ability to operate under various conditions without failure.
explain internal characterstics in more simple words
Internal characteristics of software are like the hidden qualities of a cake. While you can't see them from the outside, they're crucial for the cake to be tasty and hold together. Similarly, in software, internal characteristics are about how well the software is built and how easy it is to maintain, keep secure, and make it work well as more people use it.
Characteristics of Software Quality
External quality characteristics include the following
Correctness The degree to which a system is free from faults in its specification, design, and implementation.
Usability The ease with which users can learn and use a system.
Efficiency Minimal use of system resources, including memory and execution time.
Characteristics of Software Quality
Reliability The ability of a system to perform its required functions under stated conditions whenever required—having a long mean time between failures.
Integrity The degree to which a system prevents unauthorized or improper access to its programs and its data. The idea of integrity includes restricting unauthorized user accesses as well as ensuring that data is accessed properly— that is, that tables with parallel data are modified in parallel, that date fields contain only valid dates, and so on.
Characteristics of Software Quality
Adaptability The extent to which a system can be used, without modification, in applications or environments other than those for which it was specifically designed.
Robustness The degree to which a system continues to function in the presence of invalid inputs or stressful environmental conditions. summry it into simple words
Software quality characteristics can be understood as the different ways we measure how good the software is.
External characteristics are about what users see and feel:
Reliability: How dependable the software is, and how long it can go without breaking. Integrity: How well the software keeps data safe and secure. Adaptability: How well the software can be used in different situations needing big changes. Robustness: How well the software keeps working, even things go wrong.
Characteristics of Software Quality
Programmers care about the internal characteristics of the software as well as the external ones.
Some of the internal quality characteristics are
Maintainability The ease with which you can modify a software system to change or add capabilities, improve performance, or correct defects.
Flexibility The extent to which you can modify a system for uses other than those for which it was specifically designed.
Characteristics of Software Quality
Portability The ease with which you can modify a system to operate in an environment different from that for which it was specifically designed.
Reusability The extent to which and the ease with which you can use parts of a system in other systems.
Readability The ease with which you can read and understand the source code of a system, especially at the detailed-statement level
Characteristics of Software Quality
Testability The degree to which you can unit-test and system-test a system; the degree to which you can verify that the system meets its requirements.
Understandability The ease with which you can comprehend a system at both the system-organizational and detailed-statement levels. Understandability has to do with the coherence of the system at a more general level than readability does. summry it into simple words
Programmers also pay attention to the internal qualities of software, not just how it looks and feels to users.
Internal quality characteristics include:
Software quality assurance is a planned and systematic program of activities designed to ensure that a system has the desired characteristics.
Although it might seem that the best way to develop a high-quality product would be to focus on the product itself, in software quality assurance you also need to focus on the software-development process.
Techniques for Improving Software Quality
Some of the elements of a software-quality program are:
Software-quality objectives
Explicit quality-assurance activity
Testing strategy
Software-engineering guidelines
Informal technical reviews
Formal technical reviews
External audits
Change-control procedures
Measurement of results
Prototyping
Techniques for Improving Software Quality
Software-quality objectives
One powerful technique for improving software quality is setting explicit quality objectives from among the external and internal characteristics described in the previous section.
Without explicit goals, programmers might work to maximize characteristics different from the ones you expect them to maximize.
Techniques for Improving Software Quality
Explicit quality-assurance activity
One common problem in assuring quality is that quality is perceived as a secondary goal. Indeed, in some organizations, quick and dirty programming is the rule rather than the exception.
Programmers who litter their code with defects and “complete” their programs quickly, are rewarded more than programmers who write excellent programs and make sure that they are usable before releasing them.
In such organizations, it shouldn’t be surprising that programmers don’t make quality their first priority.
The organization must show programmers that quality is a priority.
Making the quality-assurance activity explicit makes the priority clear, and programmers will respond accordingly.
Techniques for Improving Software Quality
Testing strategy
Execution testing can provide a detailed assessment of a product’s reliability.
Part of quality assurance is developing a test strategy in conjunction with the product requirements, architecture, and design.
Techniques for Improving Software Quality
Software-engineering guidelines
Guidelines should control the technical character of the software as it’s developed.
Such guidelines apply to all software development activities, including problem definition, requirements development, architecture, construction, and system testing.
Techniques for Improving Software Quality
Informal technical reviews
Many software developers review their work before turning it over for formal review.
Informal reviews include desk-checking the design or the code or walking through the code with a few peers.
Techniques for Improving Software Quality
Formal technical reviews
One part of managing a software-engineering process is catching problems at the “lowest-value” stage—that is, at the time at which the least investment has been made and at which problems cost the least to correct.
To achieve such a goal, developers use “quality gates,” periodic tests or reviews that determine whether the quality of the product at one stage is sufficient to support moving on to the next.
Quality gates are usually used to transition between requirements development and architecture, architecture and construction, and construction and system testing.
The “gate” can be an inspection, a peer review, a customer review, or an audit.
Techniques for Improving Software Quality
External audits
An external audit is a specific kind of technical review used to determine the status of a project or the quality of a product being developed.
An audit team is brought in from outside the organization and reports its findings to whoever commissioned the audit, usually management.
Techniques for Improving Software Quality
Change-control procedures
One big obstacle to achieving software quality is uncontrolled changes.
Uncontrolled requirements changes can result in disruption to design and coding.
Uncontrolled changes in design can result in code that doesn’t agree with its requirements, inconsistencies in the code, or more time spent modifying code to meet the changing design than spent moving the project forward.
Techniques for Improving Software Quality
Uncontrolled changes in the code itself can result in internal inconsistencies and uncertainties about which code has been fully reviewed and tested and which hasn’t.
Handling changes effectively is a key to achieving high quality levels.
Techniques for Improving Software Quality
Measurement of results
Unless results of a quality-assurance plan are measured, you’ll have no way to know whether the plan is working.
Measurement tells you whether your plan is a success or a failure and also allows you to vary your process in a controlled way to see how it can be improved.
You can also measure quality attributes themselves—correctness, usability, efficiency, and so on—and it’s useful to do so.
Techniques for Improving Software Quality
Prototyping
Prototyping is the development of realistic models of a system’s key functions.
A developer can prototype parts of a user interface to determine usability, critical calculations to determine execution time, or typical data sets to determine memory requirements.
A survey of 16 published and 8 unpublished case studies compared prototyping to traditional, specification-development methods.
The comparison revealed that prototyping can lead to better designs, better matches with user needs, and improved maintainability (Gordon and Bieman 1991).
When to Do Quality Assurance
As Chapter 3 (“Measure Twice, Cut Once: Upstream Prerequisites”) noted, the earlier an error is inserted into software, the more entangled it becomes in other parts of the software and the more expensive it becomes to remove.
A fault in requirements can produce one or more corresponding faults in design, which can produce many corresponding faults in code.
A requirements error can result in extra architecture or in bad architectural decisions.
The extra architecture results in extra code, test cases, and documentation.
When to Do Quality Assurance
Or a requirements error can result in architecture, code, and test cases that are thrown away.
Just as it’s a good idea to work out the defects in the blueprints for a house before pouring the foundation in concrete, it’s a good idea to catch requirements and architecture errors before they affect later activities.
When to Do Quality Assurance
In addition, errors in requirements or architecture tend to be more sweeping than construction errors.
A single architectural error can affect several classes and dozens of routines, whereas a single construction error is unlikely to affect more than one routine or class.
For this reason, too, it’s cost-effective to catch errors as early as you can.
When to Do Quality Assurance
Defects creep into software at all stages. Consequently, you should emphasize quality assurance work in the early stages and throughout the rest of the project.
It should be planned into the project as work begins; it should be part of the technical fiber of the project as work continues; and it should punctuate the end of the project, verifying the quality of the product as work ends.
CHECKLIST: A Quality-Assurance Plan
Have you identified specific quality characteristics that are important to your project?
Have you made others aware of the project’s quality objectives?
Have you differentiated between external and internal quality characteristics?
Have you thought about the ways in which some characteristics might compete with or complement others?
CHECKLIST: A Quality-Assurance Plan
Does your project call for the use of several different error-detection techniques suited to finding several different kinds of errors?
Does your project include a plan to take steps to assure software quality during each stage of software development?
Is the quality measured in some way so that you can tell whether it’s improving or degrading?
Does management understand that quality assurance incurs additional costs up front in order to save costs later?
Key Points
Quality is free, in the end, but it requires a reallocation of resources so that defects are prevented cheaply instead of fixed expensively.
Not all quality-assurance goals are simultaneously achievable. Explicitly decide which goals you want to achieve, and communicate the goals to other people on your team.
No single defect-detection technique is completely effective by itself. Testing by itself is not optimally effective at removing errors. Successful quality-assurance programs use several different techniques to detect different kinds of errors.
Key Points
You can apply effective techniques during construction and many equally powerful techniques before construction. The earlier you find a defect, the less intertwined it will become with the rest of your code and the less damage it will cause.
Quality assurance in the software arena is process-oriented. Software development doesn’t have a repetitive phase that affects the final product like manufacturing does, so the quality of the result is controlled by the process used to develop the software. summry it into simple words
Software quality assurance is a set of planned and systematic activities aimed at ensuring that a software system has the desired characteristics. It's not just about the final product but also about focusing on the process of developing the software. Here are the key points in simple words:
Quality characteristics: Include both external factors that users can see and internal factors that affect how the software is built and maintained.
Techniques for improvement: Explicit quality objectives, quality-assurance activities, testing strategies, engineering guidelines, reviews, audits, change-control procedures, measurement of results, and prototyping are important techniques for improving software quality.
When to do quality assurance: Quality assurance activities should be emphasized in the early stages of a project and continue throughout development. Early detection of errors is crucial to prevent them from causing larger problems later on.
Checklist for quality assurance plan: Identify specific quality characteristics, communicate quality objectives, use multiple error-detection techniques, measure quality, and understand that quality assurance may incur upfront costs but saves costs in the long run.
Key points: Quality assurance is a process-oriented approach aimed at preventing defects cheaply rather than fixing them expensively later. It's important to communicate goals clearly, use multiple techniques for detecting errors, and prioritize early detection of defects.
In essence, software quality assurance is about setting clear goals, using effective techniques to detect and prevent errors, and focusing on a process-oriented approach from the beginning to ensure a high-quality end product.
Techniques for Improving Software Quality
Software-quality objectives
One powerful technique for improving software quality is setting explicit quality objectives from among the external and internal characteristics described in the previous section.
Without explicit goals, programmers might work to maximize characteristics different from the ones you expect them to maximize.
Techniques for Improving Software Quality
Explicit quality-assurance activity
One common problem in assuring quality is that quality is perceived as a secondary goal. Indeed, in some organizations, quick and dirty programming is the rule rather than the exception.
Programmers who litter their code with defects and “complete” their programs quickly, are rewarded more than programmers who write excellent programs and make sure that they are usable before releasing them.
In such organizations, it shouldn’t be surprising that programmers don’t make quality their first priority.
The organization must show programmers that quality is a priority.
Making the quality-assurance activity explicit makes the priority clear, and programmers will respond accordingly.
Techniques for Improving Software Quality
Testing strategy
Execution testing can provide a detailed assessment of a product’s reliability.
Part of quality assurance is developing a test strategy in conjunction with the product requirements, architecture, and design.
Techniques for Improving Software Quality
Software-engineering guidelines
Guidelines should control the technical character of the software as it’s developed.
Such guidelines apply to all software development activities, including problem definition, requirements development, architecture, construction, and system testing.
Techniques for Improving Software Quality
Informal technical reviews
Many software developers review their work before turning it over for formal review.
Informal reviews include desk-checking the design or the code or walking through the code with a few peers.
Techniques for Improving Software Quality
Formal technical reviews
One part of managing a software-engineering process is catching problems at the “lowest-value” stage—that is, at the time at which the least investment has been made and at which problems cost the least to correct.
To achieve such a goal, developers use “quality gates,” periodic tests or reviews that determine whether the quality of the product at one stage is sufficient to support moving on to the next.
Quality gates are usually used to transition between requirements development and architecture, architecture and construction, and construction and system testing.
The “gate” can be an inspection, a peer review, a customer review, or an audit.
Techniques for Improving Software Quality
External audits
An external audit is a specific kind of technical review used to determine the status of a project or the quality of a product being developed.
An audit team is brought in from outside the organization and reports its findings to whoever commissioned the audit, usually management.
Techniques for Improving Software Quality
Change-control procedures
One big obstacle to achieving software quality is uncontrolled changes.
Uncontrolled requirements changes can result in disruption to design and coding.
Uncontrolled changes in design can result in code that doesn’t agree with its requirements, inconsistencies in the code, or more time spent modifying code to meet the changing design than spent moving the project forward.
Techniques for Improving Software Quality
Uncontrolled changes in the code itself can result in internal inconsistencies and uncertainties about which code has been fully reviewed and tested and which hasn’t.
Handling changes effectively is a key to achieving high quality levels.
Techniques for Improving Software Quality
Measurement of results
Unless results of a quality-assurance plan are measured, you’ll have no way to know whether the plan is working.
Measurement tells you whether your plan is a success or a failure and also allows you to vary your process in a controlled way to see how it can be improved.
You can also measure quality attributes themselves—correctness, usability, efficiency, and so on—and it’s useful to do so.
Techniques for Improving Software Quality
Prototyping
Prototyping is the development of realistic models of a system’s key functions.
A developer can prototype parts of a user interface to determine usability, critical calculations to determine execution time, or typical data sets to determine memory requirements.
A survey of 16 published and 8 unpublished case studies compared prototyping to traditional, specification-development methods.
The comparison revealed that prototyping can lead to better designs, better matches with user needs, and improved maintainability (Gordon and Bieman 1991). summry it into simple words
In simple terms, here are the techniques for improving software quality:
Set explicit quality objectives: Clearly define the desired characteristics of the software to ensure that programmers focus on the right aspects.
Prioritize quality-assurance activities: Explicitly make quality a priority within the organization to encourage programmers to prioritize quality over speed.
Implement a testing strategy: Develop a comprehensive testing plan to assess the reliability of the software based on its requirements, architecture, and design.
Follow software-engineering guidelines: Establish and enforce technical guidelines to control the development process, including problem definition, requirements development, architecture, construction, and system testing.
Conduct informal technical reviews: Encourage software developers to review their work informally, such as by checking the design or code with peers before formal reviews.
Utilize formal technical reviews: Implement quality gates, like inspections or peer reviews, to catch and correct problems at early stages to minimize cost.
External audits: Bring in an outside audit team to assess the status of the project or product and report findings to management.
Implement change-control procedures: Establish processes to control requirements, design, and code changes to avoid disruptions and inconsistencies.
Measure results: Regularly measure the results of the quality-assurance plan to assess its effectiveness and identify areas for improvement.
Use prototyping: Develop realistic models of key system functions to assess usability, execution time, memory requirements, and to ensure better designs and user needs alignment.
Introduction
Collaboration is the action of working with someone to produce something.
Collaboration in the workplace is when two or more people work together through idea sharing and thinking to accomplish a common goal.
All collaborative construction techniques are attempts to formalize the process of showing your work to someone else for the purpose of flushing out errors.
Overview of Collaborative Development Practices
Collaborative construction refers to
pair programming
formal inspections
informal technical reviews
document reading
as well as other techniques in which developers share responsibility for creating code and other work products.
Overview of Collaborative Development Practices
All collaborative construction techniques, despite their differences, are based on the ideas that developers are blind to some of the trouble spots in their work, that other people don’t have the same blind spots, and that it’s beneficial for developers to have someone else look at their work.
Studies at the Software Engineering Institute have found that developers insert an average of 1 to 3 defects per hour into their designs and 5 to 8 defects per hour into code (Humphrey 1997), so attacking these blind spots is a key to effective construction.
Overview of Collaborative Development Practices
Some benefits of collaborative development practices are
Collaborative Construction Complements Other Quality-Assurance Techniques.
Collaborative Construction Provides Mentoring in Corporate Culture and Programming Expertise.
Collective Ownership Applies to All Forms of Collaborative Construction.
Pair Programming
When pair programming
one programmer types in code at the keyboard
the other programmer watches for mistakes
and thinks strategically about whether the code is being written correctly and whether the right code is being written.
Keys to Success with Pair Programming
The basic concept of pair programming is simple, but following guidelines are key to success with pair programming
Support pair programming with coding standards
Don’t let pair programming turn into watching
Don’t force pair programming of the easy stuff
Rotate pairs and work assignments regularly
Keys to Success with Pair Programming
Encourage pairs to match each other’s pace
Make sure both partners can see the monitor
Don’t force people who don’t like each other to pair
Avoid pairing all newbies
Assign a team leader
Benefits of Pair Programming
Pair programming produces numerous benefits:
It holds up better under stress than solo development. Pairs encourage each other to keep code quality high even when there’s pressure to write quick and dirty code.
It improves code quality. The readability and understandability of the code tends to rise to the level of the best programmer on the team.
Benefits of Pair Programming
It shortens schedules. Pairs tend to write code faster and with fewer errors. The project team spends less time at the end of the project correcting defects.
It produces all the other general benefits of collaborative construction, including disseminating corporate culture, mentoring junior programmers, and fostering collective ownership.
Formal Inspections
An inspection is a specific kind of review that has been shown to be extremely effective in detecting defects and to be relatively economical compared to testing.
Inspections were developed by Michael Fagan and used at IBM for several years before Fagan published the paper that made them public.
Formal Inspections
Although any review involves reading designs or code, an inspection differs from a review in several key ways:
Checklists focus the reviewers’ attention on areas that have been problems in the past.
The inspection focuses on defect detection, not correction.
Reviewers prepare for the inspection meeting beforehand and arrive with a list of the problems they’ve discovered.
Distinct roles are assigned to all participants.
Formal Inspections
The moderator of the inspection isn’t the author of the work product under inspection.
The moderator has received specific training in moderating inspections.
The inspection meeting is held only if all participants have adequately prepared.
Data is collected at each inspection and is fed into future inspections to improve them.
General management doesn’t attend the inspection meeting unless you’re inspecting a project plan or other management materials. Technical leaders might attend.
Formal Inspections
Individual inspections typically catch about 60 percent of defects, which is higher than other techniques except prototyping and high-volume beta testing.
The combination of design and code inspections usually removes 70–85 percent or more of the defects in a product.
Designers and coders learn to improve their work through participating in inspections, and inspections increase productivity by about 20 percent.
On a project that uses inspections for design and code, the inspections will take up about 10–15 percent of project budget and will typically reduce overall project cost.
Roles During an Inspection
One key characteristic of an inspection is that each person involved has a distinct role to play.
Here are the roles (details from book, Pg. 486)
Moderator
Author
Reviewer
Scribe
Management
General Procedure for an Inspection
An inspection consists of following distinct stages:
Planning
Overview
Preparation
Inspection Meeting
Inspection Report
Rework
Follow up
Third hour Meeting
General Procedure for an Inspection
Planning:
The author gives the design or code to the moderator.
The moderator decides who will review the material and when and where the inspection meeting will occur; the moderator then distributes the design or code and a checklist that focuses the attention of the inspectors.
Materials should be printed with line numbers to speed up error identification during the meeting.
General Procedure for an Inspection
Overview
When the reviewers aren’t familiar with the project they are reviewing, the author can spend up to an hour or so describing the technical environment within which the design or code has been created.
Having an overview tends to be a dangerous practice because it can lead to a glossing over of unclear points in the design or code under inspection.
The design or code should speak for itself; the overview shouldn’t speak for it.
General Procedure for an Inspection
Preparation
Each reviewer works alone to scrutinize the design or code for errors.
The reviewers use the checklist to stimulate and direct their examination of the review materials.
Some organizations have found that inspections are more effective when each reviewer is assigned a specific perspective.
A reviewer might be asked to prepare for the inspection from the point of view of the maintenance programmer, the customer, or the designer, for example. Research on perspective-based reviews suggests that perspective-based reviews might uncover more errors than general reviews.
General Procedure for an Inspection
Inspection Meeting
The moderator chooses someone other than the author to paraphrase the design or read the code.
All logic is explained, including each branch of each logical structure.
During this presentation, the scribe records errors as they are detected, but discussion of an error stops as soon as it’s recognized as an error.
The scribe notes the type and the severity of the error, and the inspection moves on.
General Procedure for an Inspection
The rate at which the design or the code is considered should be neither too slow nor too fast.
If it’s too slow, attention can lag and the meeting won’t be productive.
If it’s too fast, the group can overlook errors it would otherwise catch.
Don’t discuss solutions during the meeting.
The group should stay focused on identifying defects
General Procedure for an Inspection
Rework
The moderator assigns defects to someone, usually the author, for repair.
The assignee resolves each defect on the list.
General Procedure for an Inspection
Inspection Report
Within a day of the inspection meeting, the moderator produces an inspection report (e-mail or equivalent) that lists each defect, including its type and severity.
The inspection report helps to ensure that all defects will be corrected, and it’s used to develop a checklist that emphasizes problems specific to the organization.
If you collect data on the time spent and the number of errors found over time, you can respond to challenges about inspection’s efficacy with hard data.
Otherwise, you’ll be limited to saying that inspections seem better.
General Procedure for an Inspection
Follow-Up
The moderator is responsible for seeing that all rework assigned during the inspection is carried out.
Depending on the number of errors found and the severity of those errors, you might follow up by
having the reviewers re-inspect the entire work product
having the reviewers re-inspect only the fixes
allowing the author to complete the fixes without any follow-up.
General Procedure for an Inspection
Third-Hour Meeting
Even though during the inspection participants aren’t allowed to discuss solutions to the problems raised, some might still want to.
You can hold an informal, third-hour meeting to allow interested parties to discuss solutions after the official inspection is over.
Other Kinds of Collaborative Development Practices
Some other collaborative development practices are “Walk-throughs” and “Code Reading”.
Walk-Throughs
A walk-through is a popular kind of review.
The term is loosely defined, and at least some of its popularity can be attributed to the fact that people can call virtually any kind of review a “walk-through.”
Because the term is so loosely defined, it’s hard to say exactly what a walk-through is.
Certainly, a walk-through involves two or more people discussing a design or code.
Walk-Throughs
Walk-through might be as informal as a casual session around a whiteboard; it might be as formal as a scheduled meeting with an overhead presentation prepared by the art department and a formal summary sent to management.
In one sense, “where two or three are gathered together,” there is a walk-through.
Walk-Throughs
A few things that all walkthroughs have in common are:
The walk-through is usually hosted and moderated by the author of the design or code under review.
The walk-through focuses on technical issues—it’s a working meeting.
All participants prepare for the walk-through by reading the design or code and looking for errors.
Walk-Throughs
The walk-through is a chance for senior programmers to pass on experience and corporate culture to junior programmers. It’s also a chance for junior programmers to present new methodologies and to challenge timeworn, possibly obsolete, assumptions.
A walk-through usually lasts 30 to 60 minutes.
The emphasis is on error detection, not correction.
Management doesn’t attend.
Code Reading
Code reading is an alternative to inspections and walk-throughs.
In code reading, you read source code and look for errors.
You also comment on qualitative aspects of the code, such as its design, style, readability, maintainability, and efficiency.
Code Reading
A study at NASA’s Software Engineering Laboratory found that code reading detected about 3.3 defects per hour of effort.
Testing detected about 1.8 errors per hour.
Like the idea of a walk-through, the concept of code reading is loosely defined.
A code reading usually involves two or more people reading code independently and then meeting with the author of the code to discuss it.
Code Reading
Here’s how code reading goes:
In preparation for the meeting, the author of the code hands out source listings to the code readers. The listings are from 1000 to 10,000 lines of code; 4000 lines is typical.
Two or more people read the code. Use at least two people to encourage competition between the reviewers. If you use more than two, measure everyone’s contribution so that you know how much the extra people contribute.
Code Reading
Reviewers read the code independently. Estimate a rate of about 1000 lines a day.
When the reviewers have finished reading the code, the code-reading meeting is hosted by the author of the code. The meeting lasts one or two hours and focuses on problems discovered by the code readers. No one makes any attempt to walk through the code line by line. The meeting is not even strictly necessary.
The author of the code fixes the problems identified by the reviewers.
Code Reading
The difference between code reading on the one hand and inspections and walkthroughs on the other is that code reading focuses more on individual review of the code than on the meeting.
The result is that each reviewer’s time is focused on finding problems in the code.
Less time is spent in meetings in which each person contributes only part of the time and in which a substantial amount of the effort goes into moderating group dynamics.
Less time is spent delaying meetings until each person in the group can meet for two hours.
Code readings are especially valuable in situations in which reviewers are geographically dispersed. summry it into simple words
Collaborative development practices encompass various methods such as pair programming, formal inspections, walk-throughs, and code reading. Each approach serves the purpose of involving multiple developers in the creation and review of code and work products to enhance quality and reduce defects.
Pair programming involves two developers working together, with one writing code while the other observes for mistakes and strategic thinking. This method improves code quality, shortens schedules, and encourages collaborative ownership.
Formal inspections, developed by Michael Fagan, are extremely effective in detecting defects. They involve distinct roles such as moderator, author, reviewer, scribe, and management. The process includes planning, overview, preparation, inspection meeting, inspection report, rework, follow-up, and, optionally, a third-hour meeting for discussing solutions.
Walk-throughs are working meetings where two or more people discuss a design or code, hosted and moderated by the author, focusing on error detection and technical issues. It's a means for knowledge transfer and challenges timeworn assumptions.
Code reading involves independent review of code by multiple developers who then meet with the author to discuss issues discovered. It focuses on individual review of the code, and the meeting is not strictly necessary.
In summary, these collaborative development practices are aimed at involving multiple developers in the creation and review of code and work products to enhance quality and reduce defects. Each method has specific processes to identify and rectify issues, ultimately improving the overall product output.