Cpmandpert.doc

2. Overview of Software Configuration Management This section gives an overview of Software Configuration Management(SCM) in general. It focuses on defining what is SCM, the benefits of SCM and the adoption of SCM for OpenSource projects.

2.1. What is Software Configuration Management Software Configuration Management is the ability to control and manage change in a software project. Change is inherent and ongoing in any software project. The ability to track control such changes in a proper manner form the basis of a good software project. Software Configuration Management tries to bridge this gap by defining a process for change control. Change Management defines processes to prevent unauthorized changes, procedures to follow when making changes, required information, possibly workflow management as well. Change management is orders of magnitude more complex than version control of software.

2.2. Why is Software Configuration Management required SCM is the process that defines how to control and manage change. The need for an SCM process is acutely felt when there are many developers and many versions of the software. Suffice to say that in a complex scenario where bug fixing should happen on multiple production systems and enhancements must be continued on the main code base, SCM acts as the backbone which can make this happen.

3. Traditional Software Configuration Management Process Traditional SCM process is looked upon as the best fit solution to handling changes in software projects. Traditional SCM process identifies the functional and physical attributes of a software at various points in time and performs systematic control of changes to the identified attributes for the purpose of maintaining software integrity and traceability throughout the software development life cycle. The SCM process further defines the need to trace the changes and the ability to verify that the final delivered software has all the planned enhancements that are supposed to be part of the release. The traditional SCM identifies four procedures that must be defined for each software project to ensure a good SCM process is implemented. They are  Configuration Identification  Configuration Control  Configuration Status Accounting  Configuration Authentication Most of this section will cover traditional SCM theory. Do not consider this as boring subject since this section defines and explains the terms that will be used throughout this document.

3.1. Configuration Identification Software is usually made up of several programs. Each program, its related documentation and data can be called as a "configurable item"(CI). The number of CI in any software project and the grouping of artifacts that make up a CI is a decision made of the project. The end product is made up of a bunch of CIs.

The status of the CIs at a given point in time is called as a baseline. The baseline serves as a reference point in the software development life cycle. Each new baseline is the sum total of an older baseline plus a series of approved changes made on the CI A baseline is considered to have the following attributes 1. Functionally complete A baseline will have a defined functionality. The features and functions of this particular baseline will be documented and available for reference. Thus the capabilities of the software at a particular baseline is well known. 2. Known Quality The quality of a baseline will be well defined. i.e. all known bugs will be documented and the software will have undergone a complete round of testing before being put define as the baseline. 3. Immutable and completely recreatable A baseline, once defined, cannot be changed. The list of the CIs and their versions are set in stone. Also, all the CIs will be under version control so the baseline can be recreated at any point in time.

3.2. Configuration Control The process of deciding, co-ordinating the approved changes for the proposed CIs and implementing the changes on the appropriate baseline is called Configuration control. It should be kept in mind that configuration control only addresses the process after changes are approved. The act of evaluating and approving changes to software comes under the purview of an entirely different process called change control.

3.3. Configuration Status Accounting Configuration status accounting is the bookkeeping process of each release. This procedure involves tracking what is in each version of software and the changes that lead to this version. Configuration status accounting keeps a record of all the changes made to the previous baseline to reach the new baseline.

3.4. Configuration Authentication Configuration authentication (CA) is the process of assuring that the new baseline has all the planned and approved changes incorporated. The process involves verifying that all the functional aspects of the software is complete and also the completeness of the delivery in terms of the right programs, documentation and data are being delivered. The configuration authentication is an audit performed on the delivery before it is opened to the entire world.

3.5. Tools that aid Software Configuration Management Free Software Tools TODO: need some writeup here on each tool. Free software tools that help in SCM are 1. Concurrent Versions System (CVS) 2. Revision Control System (RCS) 3. Source Code Control System (SCCS) Commercial Tools 1. Rational ClearCase 2. PVCS 3. Microsoft Visual SourceSafe

3.6. SCM and SEI Capability Maturity Model The Capability Maturity Model defined by the Software Engineering Institute (SEI) for Software describes the principles and practices to achieve a certain level of software process maturity. The model is intended to help software organizations improve the maturity of their software processes in terms of an evolutionary path from ad hoc, chaotic processes to mature, disciplined software processes. The CMM is designed towards organizations in improving their software processes for building better software faster and at a lower cost. The Software Engineering Institute (SEI) defines five levels of maturity of a software development process. They are denoted pictorially below.

Associated with each level from level two onwards are key areas which an organization is required to focus on to move on to the next level. Such focus areas are called as Key Process Areas (KPA) in CMM parlance. As part of level 2 maturity, one of the KPAs that has been identified is SCM. Thus any project that has a good SCM process can be leveraged as satisfying one of the KPAs of CMM. We will cover this in more detail in the section on using SCM to leverage Open Source Projects

4. SCM for Open Source Projects Open Source Projects are typically started by a few talented individuals who wanted to "scratch a personal itch". It is then taken over by the entire world (so it seems) and it grows in all directions, eventually magically solidifying into a product that is more stable than any similar effort made by human beings. In fact, OSP at the outset, resemble a great bazaar with different agendas and different approaches by different people. How important is SCM for such an Open Source Projects project? Let us face it - OSP works and it works well. So how are such diverse interests synergized into a single mission? Looking at the extremely successful Linux example, Linus Torvalds acts as the gatekeeper to the Linux kernel. The actual development work is mostly done by others but Linus Torvalds decides on the contents of the release kernel. Each developer sends to him a patch containing the changes that have to be incorporated into the kernel. Thus for all practical purpose he acts as the one man software configuration management process offering control (incorporating patches from other developers), accounting (the changelog) and authentication of the configurable items (ensuring that the released kernel has all the pieces) - Not an easy task!

4.1. Need for SCM in Open Source Projects SCM and its supporting tools bring order into the chaotic development model of Open Source Projects. All SCM projects require "maintainers" whole job is to integrate the patches that arrive from various developers into the main code base, make sure that things are in order and put out the releases in a regular fashion. The maintainers provide the SCM for free software projects. All successful OSP projects involve one form of SCM or another. In fact they employ all the procedures as defined in the traditional SCM process (See Section 3). These procedures are evolved unconsciously. If we make a conscious effort to incorporate the traditional SCM procedures into an OSP project, definite benefits can be obtained. In the future sections, We will look at various OSP projects that are different in size and see how SCM can be effectively applied in those scenarios.

4.2. Using SCM to leverage Open Source Projects A quote comes to mind...

Take a great idea, work very hard on it and then advertise even harder! --Anonymous This adage applies to OSP more than anything else does. Open Source Projects require publicity as much, if not more, than any other project to be successful. OSP projects to compete in the commercial space will require building credibility with the external world. Credibility should be built starting with fellow developers to users to other large commercial software houses. One of the ways to build credibility is by leveraging the fact that a clearly defined SCM process exists and is followed for the OSP.

4.2.1. Developers Developers benefit from the existence of an SCM process since it makes their life easier. There is more clarity as to who is responsible for what portion of the code, how and when their patches will be integrated into the main source tree and when software releases will be made. The existence of such an operational roadmap will help keep the enthusiasm of the developer community thereby ensuring good quality software development.

4.2.2. Testers In the OSP community, a few people will act as the testers for the application by setting up the new version on their system and using it on a regular basis. To them, the availability of an SCM will help in recreating a particular release of the software. They can establish test beds easily and compare multiple releases against each other to find out the cause of a particular bug/issue.

4.2.3. Support Teams There are a few groups and commercial organizations providing support for the Linux platform. Support can be in the form of providing total solution using Open Source software to providing telephone and/or email based support for customers who have businesses running on Open Source software. SCM can help them by providing a means to quickly setup a reference platform that contains the exact same software version that is present at the customer site. Thus they can reproduce the problem easily and provide a workaround or solution for it.

4.2.4. Corporate Management Leveraging Open Source to corporate management can be done in the following ways. 1. Existence of a formal process The existence of a formal process is always reassuring to the management. It signifies "professional approach" and existence of control in the project. 2. Merges well with corporate culture Most commercial software organizations will have one form of SCM or another. Thus any OSP that is going to obtain a corporate backing will benefit from SCM since the Software Configuration Management will help integrate the OSP better with the organization's culture. 3. Satisfies one or more KPAs of SEI'sCMM.

4.2.5. Investors Investors and venture capitalists perform due diligence before investing in any particular venture. Due diligence is the fancy term for the exercise that attempts to find out whether the particular venture is worth investing into. Since I am not familiar with what is involved in due diligence, I will not be able to add finer points here. All the same, the existence of a defined process to manage the development will always help.

. SCM strategy in Open Source Projects We will now examine SCM strategies for OSP projects of different sizes and suggest suitable models for each. This should serve as a guidebook for SCM when starting new OSP projects

5.1. SCM for a small OSP OSP projects can be considered as "small sized" if they fall within the following criteria.  Small User Base The user base of the OSP project will typically be small in the order of magnitude, less than 100. One possible reason would be that the project addresses a very niche area of a problem domain that does not interest the average public. Another reason could be that the project is just starting out and so the user base is small due to its relative obscurity.  Small Code Base The size (number of files/lines) of the source code for the application will typically be small. Thus the various versions of the source code can be maintained without using a tool.  Releases are not frequent In any Open Source Projects project, the dictum is to "release early and release often". But some projects do not necessarily have a need for frequent releases. Small sized OSP projects tend to fall in that category. Such projects do not need a release management mechanism in place. Applying the traditional SCM procedures (See Section 3) for a small Open Source Projects, 1. Configuration Identification For a small project, we have said that the code base will tend to be small. In that case, identifying configurable items can be a straight forward exercise. It will be the list of all the source files plus other documentation that accompanies the code. 2. Configuration Control

8.1 SCM Policy An SCM policy is what defines how your organisation will manage software change. The basis of an effective SCM policy is a revision control system. An SCM policy can be as simple as a procedure in which CVS is used as a revision control system and an understanding by CM staff (documented or otherwise) in how releases are produced and distributed. An SCM policy should also include the implementation of some kind of problem tracking system. There are plenty of problem tracking systems available, ranging from lots of yellow sticky notes and shouting, to software packages such as GNATS or xpts. Many organisations (far too many, in my opinion) have their own internally developed problem tracking software packages. A more complex SCM policy (perhaps based on MIL-STD-973) will include elements of Configuration Identification, Configuration Status Accounting, and auditing procedures as well as all of the above items.

8.2 Configuration Identification Configuration identification includes the selection of CIs; the determination of the types of configuration documentation required for each CI; the issuance of numbers and other identifiers affixed to the CIs and to the technical documentation that defines the CI's configuration, including internal and external interfaces; the release of CIs and their associated configuration documentation; and the establishment of configuration baselines for CIs. [MIL-STD-973]

Configuration Identification is the process whereby your organisation selects and determines how the individual components of a software project are to be identified. You can assist in the basic process of configuration identification by following these procedures:  Make sure that there exists a modules file in your CVS repository (in the CVSROOT directory). This is what CVS uses to identify each software module.  Ensure that there is a document somewhere (inside or outside of the repository) that describes each of the software modules, and what its purpose is.  Put comments into the modules file that refer back to the document, or put extracts from the document into the CVS modules file as comments (remember that "modules" is a text file, not a word processing document, and each comment should be preceded with a hash sign -- "#").  Ensure that there is an effective release procedure. The release procedure should involve a system of tagging, identification, numbering, and backup. Release procedures are described in more detail later.

8.3 Configuration Control Configuration Control is:

The systematic proposal, justification, evaulation, coordiation, approval or disapproval of proposed changes, and the implementation of all approved changes, in the configuration of a CI after establishment of the configuration baseline for the CI.

8.4 Implementation of Configuration Control Having established a change authorisation procedure, your organisation will be in a position to use CVS as a change control mechanism. As stated previously, CVS cannot be used as a change authorisation method, and so at best it provides one half (the machine half) of the configuration control policy that your organisation requires. The process of implementing configuration control includes the following:  Restricting access to the CVS repository to allow authorised changes only.  Ensuring that established product baselines are changed by virtue of work authorities only. A work authority in this case will be a change request derived from a trouble report or an engineering change. In the CVS repository, there is a directory called "CVSROOT". This directory contains a number of control files used by CVS. These files are site-dependant (that is, they can be modified and maintained by the CVS administrators at each CVS site), and can be used by your site to implement configuration control. In section 7.5.1 (Release strategies) I examined two possible architectures of release methods using CVS tags. These depend on whether local builds are created from tagged or head revisions from the CVS repository. If you are building local builds from head revisions, your organisation will need to perform configuration control at the commit stage. If you are building local builds from tagged revisions, your organisation will need to perform change control at the tag stage.

A version control glossary 

Help index



About source code version control with CVS  A version control glossary  What is version control?  Key terms in version control  The copy-modify-merge development cycle  Using command-line CVS to access project source files  Managing project files and directories with CVS

What is version control? A version control system maintains an organized set of all the versions of files that are made over time. Version control systems allow people to go back to previous revisions of individual files, and to compare any two revisions to view the changes between them. In this way, version control keeps a historically accurate and retrievable log of a file's revisions. More importantly, version control systems help several people (even in geographically disparate locations) work together on a development project over the Internet or private network by merging their changes into the same source repository.

Key terms in version control Checking in a file or directory This copies your working directory back into the repository as a new version. Checking out files or directories This copies the latest revision of a file from the repository to your workspace. When you check out a directory, you check out all files and subdirectories under it. Committing a file or directory This is the same as checking in a file or directory. Often version control users will say that they have "committed a change"; this means that they made changes to their working copies of files and committed these back to the repository. Conflict When two developers make changes to their working copies of the same file and commit them to the repository, their work may conflict. When this happens, CVS will detect the conflict and require someone to resolve resolve it before committing their changes. Merging Combining multiple changes made to different working copies of the same files in the source repository. Merging is a strategy for managing conflicts by letting multiple developers work at the same time (with no locks on files), and then incorporating their work into one combined version. Merging works well when two sets of changes are made to different lines in a files and can be easily combined. When changes to a file are made on the same line or lines, conflicts occur, requiring someone to edit the file manually before the changes can be committed to the source repository successfully. Repository

A shared database with the complete revision history of all files under version control. Resolving Conflicts within a file created by two developers attempting to commit conflicting changes must be addressed by manually editing the file. Someone must go through the file line by line to accept one set of changes and delete the other set. Files with conflicts cannot be committed into the source repository successfully until they are resolved. Revision A numbered draft of specific updates to individual files. Each time you edit a file and commit it back to the repository, the file's revision number increases. Version The numbering scheme used to identify sets of files that are tagged and named at a certain point in time. Workspace Your copies of the files you want to edit on your local hard disk or Unix user account. When you edit files in your workspace, they will become out of sync with the repository. That's progress! Then you need to get your changes back into the repository so that everyone else can see them.

The copy-modify-merge development cycle Because CVS is a vastly powerful tool, the learning curve might seem formidable. Certainly there are plenty of books and web sites offering comprehensive CVS knowledge bases (many good sources are referenced at the bottom of this site's main CVS page). However, it is not necessary to digest an entire tome to be able to incorporate CVS into your software development practices immediately and effectively. CVS allows you to work within your own development cycle while keeping track of the project's overall development cycle: 1. You begin working on a project by obtaining your own working copy of files, known as checking out the project repository or modules, individual groups of project source files. 2. You make your contributions to the project by modifying these files and creating new files. This part of the cycle doesn't involve cvs directly. You modify your working copies of project files using a file editor on your local machine. You can save and compile your edited files to test how your changes affect the particular project module you are working in without affecting anyone else's work on those same project files. Nothing you do affects other project participants until you merge your changes into the project repository. 3. You test and tweak your latest changes in your own workspace to make sure these work without breaking or corrupting the overall project. 4. Finally, you contribute back or check in your changes to the main or "top" body of project files, merging your work with the most recent working version known in CVS terminology as the head. Committing your changes to merge with other developers' work is the most powerful aspect of CVS, but that power also makes it the most critical aspect. It's possible to get confused and accidentally overwrite someone else's changes or your own. Your contributed changes invariably will conflict with someone else's at some point. Understanding how and when to update your working copies and how to resolve merge conflicts are two particularly critical aspects of using CVS in collaborative development projects.

This copy-modify-merge cycle is repeated throughout the life of the project by all contributing developers. CVS enables everyone to work on project files simultaneously, to stay up to date on the latest changes contributed by others, and to test how their own changes affect the overall project without interrupting other developers' cycles.

A version control glossary  

Help index About source code version control with CVS  A version control glossary  What is version control?  Key terms in version control  The copy-modify-merge development cycle  Using command-line CVS to access project source files  Managing project files and directories with CVS

What is version control? A version control system maintains an organized set of all the versions of files that are made over time. Version control systems allow people to go back to previous revisions of individual files, and to compare any two revisions to view the changes between them. In this way, version control keeps a historically accurate and retrievable log of a file's revisions. More importantly, version control systems help several people (even in geographically disparate locations) work together on a development project over the Internet or private network by merging their changes into the same source repository.

Key terms in version control Checking in a file or directory This copies your working directory back into the repository as a new version. Checking out files or directories This copies the latest revision of a file from the repository to your workspace. When you check out a directory, you check out all files and subdirectories under it. Committing a file or directory This is the same as checking in a file or directory. Often version control users will say that they have "committed a change"; this means that they made changes to their working copies of files and committed these back to the repository. Conflict When two developers make changes to their working copies of the same file and commit them to the repository, their work may conflict. When this happens, CVS will detect the conflict and require someone to resolve resolve it before committing their changes. Merging Combining multiple changes made to different working copies of the same files in the source repository. Merging is a strategy for managing conflicts by letting multiple

developers work at the same time (with no locks on files), and then incorporating their work into one combined version. Merging works well when two sets of changes are made to different lines in a files and can be easily combined. When changes to a file are made on the same line or lines, conflicts occur, requiring someone to edit the file manually before the changes can be committed to the source repository successfully. Repository A shared database with the complete revision history of all files under version control. Resolving Conflicts within a file created by two developers attempting to commit conflicting changes must be addressed by manually editing the file. Someone must go through the file line by line to accept one set of changes and delete the other set. Files with conflicts cannot be committed into the source repository successfully until they are resolved. Revision A numbered draft of specific updates to individual files. Each time you edit a file and commit it back to the repository, the file's revision number increases. Version The numbering scheme used to identify sets of files that are tagged and named at a certain point in time. Workspace Your copies of the files you want to edit on your local hard disk or Unix user account. When you edit files in your workspace, they will become out of sync with the repository. That's progress! Then you need to get your changes back into the repository so that everyone else can see them.

The copy-modify-merge development cycle Because CVS is a vastly powerful tool, the learning curve might seem formidable. Certainly there are plenty of books and web sites offering comprehensive CVS knowledge bases (many good sources are referenced at the bottom of this site's main CVS page). However, it is not necessary to digest an entire tome to be able to incorporate CVS into your software development practices immediately and effectively. CVS allows you to work within your own development cycle while keeping track of the project's overall development cycle: 1. You begin working on a project by obtaining your own working copy of files, known as checking out the project repository or modules, individual groups of project source files. 2. You make your contributions to the project by modifying these files and creating new files. This part of the cycle doesn't involve cvs directly. You modify your working copies of project files using a file editor on your local machine. You can save and compile your edited files to test how your changes affect the particular project module you are working in without affecting anyone else's work on those same project files. Nothing you do affects other project participants until you merge your changes into the project repository.

3.

You test and tweak your latest changes in your own workspace to make sure these work without breaking or corrupting the overall project. 4. Finally, you contribute back or check in your changes to the main or "top" body of project files, merging your work with the most recent working version known in CVS terminology as the head. Committing your changes to merge with other developers' work is the most powerful aspect of CVS, but that power also makes it the most critical aspect. It's possible to get confused and accidentally overwrite someone else's changes or your own. Your contributed changes invariably will conflict with someone else's at some point. Understanding how and when to update your working copies and how to resolve merge conflicts are two particularly critical aspects of using CVS in collaborative development projects. This copy-modify-merge cycle is repeated throughout the life of the project by all contributing developers. CVS enables everyone to work on project files simultaneously, to stay up to date on the latest changes contributed by others, and to test how their own changes affect the overall project without interrupting other developers' cycles. What is version control? A version control system maintains an organized set of all the versions of files that are made over time. Version control systems allow people to go back to previous revisions of individual files, and to compare any two revisions to view the changes between them. In this way, version control keeps a historically accurate and retrievable log of a file's revisions. More importantly, version control systems help several people (even in geographically disparate locations) work together on a development project over the Internet or private network by merging their changes into the same source repository. Key terms in version control

Checking in a file or directory This copies your working directory back into the repository as a new version. Checking out files or directories This copies the latest revision of a file from the repository to your workspace. When you check out a directory, you check out all files and subdirectories under it. Committing a file or directory This is the same as checking in a file or directory. Often version control users will say that they have "committed a change"; this means that they made changes to their working copies of files and committed these back to the repository. Conflict When two developers make changes to their working copies of the same file and commit them to the repository, their work may conflict. When this happens, CVS will detect the conflict and require someone to resolve resolve it before committing their changes. Merging Combining multiple changes made to different working copies of the same files in the source repository. Merging is a strategy for managing conflicts by letting multiple developers work at the same time (with no locks on files), and then incorporating their work into one combined version. Merging works well when two sets of changes

are made to different lines in a files and can be easily combined. When changes to a file are made on the same line or lines, conflicts occur, requiring someone to edit the file manually before the changes can be committed to the source repository successfully. Repository A shared database with the complete revision history of all files under version control. Resolving Conflicts within a file created by two developers attempting to commit conflicting changes must be addressed by manually editing the file. Someone must go through the file line by line to accept one set of changes and delete the other set. Files with conflicts cannot be committed into the source repository successfully until they are resolved. Revision A numbered draft of specific updates to individual files. Each time you edit a file and commit it back to the repository, the file's revision number increases. Version The numbering scheme used to identify sets of files that are tagged and named at a certain point in time. Workspace Your copies of the files you want to edit on your local hard disk or Unix user account. When you edit files in your workspace, they will become out of sync with the repository. That's progress! Then you need to get your changes back into the repository so that everyone else can see them. The copy-modify-merge development cycle Because CVS is a vastly powerful tool, the learning curve might seem formidable. Certainly there are plenty of books and web sites offering comprehensive CVS knowledge bases (many good sources are referenced at the bottom of this site's main CVS page). However, it is not necessary to digest an entire tome to be able to incorporate CVS into your software development practices immediately and effectively. CVS allows you to work within your own development cycle while keeping track of the project's overall development cycle: 1. You begin working on a project by obtaining your own working copy of files, known as checking out the project repository or modules, individual groups of project source files. 2. You make your contributions to the project by modifying these files and creating new files. This part of the cycle doesn't involve cvs directly. You modify your working copies of project files using a file editor on your local machine. You can save and compile your edited files to test how your changes affect the particular project module you are working in without affecting anyone else's work on those same project files. Nothing you do affects other project participants until you merge your changes into the project repository. 3. You test and tweak your latest changes in your own workspace to make sure these work without breaking or corrupting the overall project.

4.

Finally, you contribute back or check in your changes to the main or "top" body of project files, merging your work with the most recent working version known in CVS terminology as the head. Committing your changes to merge with other developers' work is the most powerful aspect of CVS, but that power also makes it the most critical aspect. It's possible to get confused and accidentally overwrite someone else's changes or your own. Your contributed changes invariably will conflict with someone else's at some point. Understanding how and when to update your working copies and how to resolve merge conflicts are two particularly critical aspects of using CVS in collaborative development projects. This copy-modify-merge cycle is repeated throughout the life of the project by all contributing developers. CVS enables everyone to work on project files simultaneously, to stay up to date on the latest changes contributed by others, and to test how their own changes affect the overall project without interrupting other developers' cycles.

Cigital Labs > Resources > Definitions > Software Inspection Software inspection is the manual processes of reading code to detect errors. Software inspection is neither automated parsing, nor is it dynamic testing. Generally, software inspection is carried out only by persons other than those who wrote the code. Having independent opinions almost certainly improves the number of defects found by this process. Software inspection has been used for many years, by such luminaries as Babbage and von Neumann. Other professions have similar procedures (e.g., financial auditors, medical second opinions, building inspectors, etc.). Software inspection was much more mainstream in the 60's and 70's, because of the difficulty of getting access to computer time. In the early days, it was not uncommon for a user to submit punched cards and then wait for one or more days before the results were returned. Because of this time lag, it was prudent for the developer to detect all syntactic errors before submitting a job. With computer resources scarce and programs of smaller size than today's systems, performing careful inspections of the code before compilation and execution was easily achieved. Although programs are huge today, software inspection is making a comeback. It should be obvious why software inspection detects errors; after all, having more eyes staring at code only serves to improve its quality. Freedman and Weinberg report that in large systems, inspections reduced the number of errors going into testing by a factor of 10 [1]. The advent of personal computer and compilers for PCs, caused developers to become lazy and start hacking together code, immediately trying to compile and run it. Lazy coders employ debuggers to try to find errors. Because of this, inspections got lost for a time, but today, inspections are back in heavy use, as it is widely known that fixing errors before a systems goes into test is extremely cost-effective. Software inspection can be performed at a variety of different levels. For example, there are code walkthroughs, that examine source code but ignore design and requirements documents. Formal reviews require that someone familar with the code introduce the rest of the inspectors to the code. These are more like presentations where the code itself is the subject manner. Typical inspections are not only geared toward error detection but also ensure that particular coding standards and issues such as portability are enforced