Version control is a way to keep a track of the changes in the code so that if something goes wrong, we can make comparisons in different code versions and revert to any previous version that we want.

One of the most used tools is Git, which has amongst other, the next features:

• Provides strong support for non-linear development.
• Distributed repository model.
• Compatible with existing systems and protocols like HTTP, FTP, ssh.
• Capable of efficiently handling small to large sized projects.
• Cryptographic authentication of history.
• Pluggable merge strategies.
• Toolkit-based design.
• Periodic explicit object packing.
• Garbage accumulates until collected.

As every tool, Git has some Pros and some Cons, let’s review them:

Pros

• Super-fast and efficient performance.
• Cross-platform
• Code changes can be very easily and clearly tracked.
• Easily maintainable and robust.
• Offers an amazing command line utility known as git bash.
• Also offers GIT GUI where you can very quickly re-scan, state change, sign off, commit & push the code quickly with just a few clicks.

Cons

• Complex and bigger history log become difficult to understand.
• Does not support keyword expansion and timestamp preservation.

Now let’s see what about CVS:

Features

• Client-server repository model.
• Multiple developers might work on the same project parallelly.
• CVS client will keep the working copy of the file up-to-date and requires manual intervention only when an edit conflict occurs
• Keeps a historical snapshot of the project.
• Anonymous read access.
• ‘Update’ command to keep local copies up to date.
• Can uphold different branches of a project.
• Excludes symbolic links to avoid a security risk.
• Uses delta compression technique for efficient storage.

Pros

• Excellent cross-platform support.
• Robust and fully-featured command-line client permits powerful scripting
• Helpful support from vast CVS community
• allows good web browsing of the source code repository
• It’s a very old, well known & understood tool.
• Suits the collaborative nature of the open-source world splendidly.

Cons

• No integrity checking for source code repository.
• Does not support atomic check-outs and commits.
• Poor support for distributed source control.
• Does not support signed revisions and merge tracking.

SVN is yet another tool for Version Control:

Features

• Client-server repository model. However, SVK permits SVN to have distributed branches.
• Directories are versioned.
• Copying, deleting, moving and renaming operations are also versioned.
• Supports atomic commits.
• Versioned symbolic links.
• Free-form versioned metadata.
• Space efficient binary diff storage.
• Branching is not dependent upon the file size and this is a cheap operation.
• Other features – merge tracking, full MIME support, path-based authorization, file locking, standalone server operation.

Pros

• Has a benefit of good GUI tools like TortoiseSVN.
• Supports empty directories.
• Have better windows support as compared to Git.
• Easy to set up and administer.
• Integrates well with Windows, leading IDE and Agile tools.

Cons

• Does not store the modification time of files.
• Does not deal well with filename normalization.
• Does not support signed revisions.

Finally, why should we use one of these? Well, it allows you to revert selected files back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more. Using a VCS also generally means that if you screw things up or lose files, you can easily recover. In addition, you get all this for very little overhead.

Bibliography:

Git – About Version Control. (n.d.). Git. https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control

Top 5 BEST Version Control Software (Source Code Management Tools). (2020, November 13). Software Testing Help. https://www.softwaretestinghelp.com/version-control-software/

Software reviews may be divided into three categories:

• Software peer reviews are conducted by the author of the work product, or by one or more colleagues of the author, to evaluate the technical content and/or quality of the work.
• Software management reviews are conducted by management representatives to evaluate the status of work done and to make decisions regarding downstream activities.
• Software audit reviews are conducted by personnel external to the software project, to evaluate compliance with specifications, standards, contractual agreements, or other criteria.

The most obvious value of software testing (especially formal testing) is that it can identify problems earlier and at a lower cost than would be identified through testing or through field use (the defect detection process) [citation needed]. The cost of finding and correcting a defect through a well-conducted examination can be one to two orders of magnitude less than when the same defect is found through testing or in the field [citation needed].

A second, but ultimately more important, value of software reviews is that they can be used to train technical authors to produce documents with extremely low defects, and also to identify and eliminate process deficiencies that foster defects (the defect prevention process).

This is particularly true for peer reviews if they are done in advance and often on work samples, rather than waiting for the work to be completed. Early and frequent reviews of small work samples can identify systematic errors in the Author’s work processes, which can be corrected before other defective work is done. This improvement in the Author’s skills can dramatically reduce the time needed to develop a high quality technical document, and dramatically decrease the error rate in the use of the document in subsequent processes.

Different types of Peer reviews

• Code review is a systematic examination (often as a peer review) of computer source code.
• Peer programming is a type of code review in which two people develop code together on the same workstation.
• Inspection is a very formal type of peer review in which reviewers follow a well-defined process for finding defects.
• Peer review is a form of peer review in which the author directs members of the development team and other interested parties to review a software product and the participants ask questions and comment on the defects.
• Technical review is a form of peer review in which a team of qualified personnel examines the suitability of the software product for the intended use and identifies discrepancies with respect to specifications and standards.

1028-2008 – 1028-2008 – IEEE Standard for Software Reviews and Audits – IEEE Standard. (2008, August 15). IEEE. https://ieeexplore.ieee.org/document/4601584

 Weinberg, Gerald M. (1971). The Psychology of Computer Programming. Van Nostrand Reinhold.

Verification and Validation is the process of investigating that a software system satisfies specifications and standards and it fulfills the required purpose. Barry Boehm described verification and validation as the following:

Verification: Are we building the product right?
Validation: Are we building the right product?

Verification is the process of verifying that a software achieves its objective without errors. It is the process to ensure whether the product that is developed is correct or not. Check if the developed product meets the requirements we have. Verification is a static test.

Activities involved in verification:

1. Inspections
2. Reviews
3. Walkthroughs
4. Desk-checking

Validation:
Validation is the process of checking whether the software product is up to scratch or, in other words, whether the product has high-level requirements. It is the process of checking the validation of the product, that is, it checks that what we are developing is the right product. It is the validation of the real and expected product. Validation is the dynamic test.

Activities involved in validation:

1. Black box testing
2. White box testing
3. Unit testing
4. Integration testing

The main standard for Quality, V&V is the IEEE, Software verification and Validation (V&V) processes, which determine whether developments products of a given activity conform to the requirements of that activity, and whether the software satisfies its intended use and user needs, are described. This determination may include analysis, evaluation, review, inspection, assessment, and testing of software products and processes. V&V processes assess the software in the context of a system, including the operational environment, hardware, interfacing software, operators and users.

IEEE. (1998). IEEE. https://people.eecs.ku.edu/~hossein/Teaching/Stds/1012.pdf

Software Engineering | Verification and Validation. (2019, April 17). GeeksforGeeks. https://www.geeksforgeeks.org/software-engineering-verification-and-validation/

Verification vs Validation. (2020, September 10). SOFTWARE TESTING Fundamentals. https://softwaretestingfundamentals.com/verification-vs-validation/

Capability Maturity Model Integration(CMMI)

Capability Maturity Model Integration (CMMI) evolved from Capability Maturity Model (CMM). CMM was proposed and research began by the Software Engineering Institute (SEI) in 1986. CMMI defines processes that should be implemented in an organisation, but it does not describe the way the processes should be implemented. CMM assists to improve product quality, organisation’s processes, productivity and project development life-cycle. CMMI is successfully applied in safety critical environments like healthcare. Also it is widely deployed in government and military projects. CMMI is widely used in large enterprises, also possible for small teams to incorporate with a little modification of the processes.

Comparison with CMMI & ISO/IEC 15504,SPICE

Similarities

Similar systematic evaluation: Both of them provide a structured approach with different level to get software process improvement. They represent a continuous conception in software process improvement. Software organization follows the first level at the beginning to achieve goals in each stage, to get the highest level at last.

Similar coverage area: Compared the structure of CMMI & ISO/IEC 15504, it is not difficult to find most of coverage of their key processes are the same. That means we can find corresponding CMMI process in 15504 process, and also can find corresponding 15504 process in CMMI process.

Differences

Different goal: CMMI and ISO/IEC 15504 have the different goals. CMMI’s goal is to improve the whole process capability in one’s organisation, but it depends on an assumption, process is the base of product’s quality. CMMI tells the company HOW TO improve the process and its capability.

Different method for evaluation: CMMI evaluates the capability of software process in according with data collection and analysis. The data collection and analysis of 15504 is based on each process, evaluate their properties.

Different structure: CMMI is a concept model on levels. For each level, they are associated with each other. And there is different concentration on each level. To reach one level, the organisation should achieve accomplish goals in all key process areas.

The future of CMM and ISO

All standards have a reputation for being process and document heavy, and for getting «in the way» of the development process. IS0 9000/9001 in particular is seen as a paper exercise and a good example of the «certification doesn’t guarantee good product» issue mentioned previously.

For any of the standards, figuring out how they can be mapped to Agile methods is a significant challenge. Some work has been done on this already, but it is yet to achieve widespread adoption. In fact, it may never be widely adopted as it is not necessary.

Herbsleb, Anita Carleton, et al., Benefits of CMM-Based Software Process Improvement Initial Results (CMU/SEI-94-TR-13). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University.

Mapping TSP and CMMI, McHale and Wall, 2004.

Let’s begin by defining this topics main concept: according to ASQ «Software quality is defined as a field of study and practice that describes the desirable attributes of software products. There are two main approaches to software quality: defect management and quality attributes.» (ASQ, 2020).

This approach to software quality is best exemplified by fixed quality models, such as ISO/IEC 25010:2011. This standard describes a hierarchy of eight quality characteristics, each composed of sub-characteristics:

1. Functional suitability
2. Reliability
3. Operability
4. Performance efficiency
5. Security
6. Compatibility
7. Maintainability
8. Transferability

The standards are a good measure for the software quality process so, some of them are:

ISO/IEC 9126

This standard deals with the following aspects to determine the quality of a software application −

• Quality model
• External metrics
• Internal metrics
• Quality in use metrics

ISO/IEC 9241-11

Part 11 of this standard deals with the extent to which a product can be used by specified users to achieve specified goals with Effectiveness, Efficiency and Satisfaction in a specified context of use.

ISO/IEC 25000:2005

ISO/IEC 25000:2005 is commonly known as the standard that provides the guidelines for Software Quality Requirements and Evaluation (SQuaRE). This standard helps in organizing and enhancing the process related to software quality requirements and their evaluations.

Software Testing – ISO Standards – Tutorialspoint. (n.d.). Tutorialspoint. https://www.tutorialspoint.com/software_testing/software_testing_iso_standards.htm

What is Software Quality? | ASQ. (2020). ASQ. https://asq.org/quality-resources/software-quality