Direct aan de slag met Software Inspectie van IFSQ

The OSQR Group T: 088 077 6767 E: [email protected] W: www.the-osqr-group.com

Direct aan de slag met Software Inspectie van IFSQ Inleiding Overweegt u een kwaliteitsinspectie te laten uitvoeren op uw maatwerk software om de technische risico’s te minimaliseren? Dan krijgt u niet alleen inzicht in de kwaliteit maar u doet tevens veel mensen een plezier. De doelstelling van een software inspectie is namelijk niet zozeer om zoveel mogelijk fouten te ontdekken maar om de kwaliteit van de source-code te optimaliseren. Daaruit komt positieve energie, zowel voor de business managers als voor de betrokken it-ers.

What’s in IT for me? Aan een Software Inspectie programma zijn voordelen verbonden voor alle betrokken partijen. Onderstaande tabel zet de voordelen voor u op een rij: Businessmanager

IT Manager

Programmeur

De businessmanager heeft vaak geen manier waarop hij zelfstandig de geschreven source-code kan beoordelen. Terwijl de risico’s verbonden aan kwalitatief slechte source-code een directe invloed hebben op de business. Een Software Inspectie geeft de businessmanager input om een gefundeerde mening te vormen over de kwaliteit van de opgeleverde systemen. De verantwoordelijkheid voor het goed functioneren van maatwerksoftware bij oplevering zal doorgaans liggen bij de IT manager. De IT manager heeft daardoor een direct belang bij het systematisch toepassen van software inspecties bij ontwikkelingstrajecten. Software Inspectie brengt echter meer dan alleen zekerheid over de kwaliteit van de source-code met zich mee. Software Inspectie helpt bij het project management, stimuleert teamwerk en geeft een impuls aan de ontwikkeling van de competenties binnen het team van programmeurs. Voor het leveren van een stuk kwaliteitswerk mag waardering worden verwacht. Een software programmeur krijgt vanuit de business zelden de waardering voor zijn werk die hij verdient. Op zich verklaarbaar omdat de kennis ontbreekt om een kwaliteitsoordeel te geven. Bij een Software Inspectie verandert die situatie.

"The OSQR Group is licensed by IfSQ, The Institute for Software Quality, to inspect, rate and certify Computer Program Source Code in accordance with the requirements set out in The IfSQ Level-2 Standard for Computer Program Source Code." IfSQ, The Institute for Software Quality, Cambridge, UK Pagina 1


Controller

Softwareontwikkeling is een kostbare activiteit. Om een gezonde ROI op nieuwe maatwerksoftware te garanderen is het van groot belang dat de opgeleverde programmatuur van hoge kwaliteit is. Het onderhouden van kwalitatief slechte software is namelijk onevenredig duur. Door het uit laten voeren van een Software Inspectie kan de controller gericht sturen op de kwaliteit van de software en daarmee op de kwaliteit van de investering.

Software Inspectie Bij een Software Inspectie inspecteert The OSQR Group de source-code op “noncompliance” ten op zichte van de richtlijnen van de “IfSQ Level-2 Standard for Computer Program Source Code”. De inspectiemethode is gebaseerd op 15 “Defect Indicators”. Een zogenaamde “Defect” is een fout of gebrek in de source code waardoor de software slecht kan functioneren. Bij software inspectie wordt er naar Defect Indicators gezocht: dit zijn patronen dat geassocieerd zijn met storingen, onbetrouwbaarheid en hoge onderhoudskosten. De hiervoor gebruikte “Defect Indicators” zijn door IfSQ als volgt gerubriceerd:

    

Work In Progress (WIP): there are clear indications that the program is not yet finished Structured Programming (SP): there are clear indications that part of the program is too complex Single Point of Maintenance (SPM): values have been hard-coded into the program, or pieces of code have been duplicated at various places Defensive Programming (DP): there are indications that the program does not defend itself against inconsistent data or subsystem failures Causes for Concern (CfCs): there are concerns about the completeness, correctness and/or maintainability of the program



Per “Defect” categorie inspecteert The OSQR Group op een aantal indicatoren die het IfSQ heeft opgesteld. Deze indicatoren worden per categorie toegelicht op basis van de officiële IfSQ definities.

WIP: Work In Progress Work In Progress means there are indications in the code that the programmer had intended (or is intending) to perform some work, but that this work has not been completed. At the very least, a work in progress indicator causes confusion for maintenance programmers, wasting their time. At worst, it may indicate missing functionality, which could later lead to software failure. There are three forms of Work In Progress that are easy to detect: 1. WIP-1: Vague "To Do" A programmer has left a note to himself or his colleague indicating that a piece of work needs to be done. However it is clear that the work has not been carried out, and there is no indication as to when the work needs to be done. 2. WIP-2: Disabled Code Code has been written and the programmer has disabled it, or switched it off, without making it clear why it has been disabled, or when or whether it will be reenabled. 3. WIP-3: Empty Statement Block The programmer has left a statement block or placeholder empty. When a programmer designs a program top-down he will often first outline the structure of the program in the form of statement blocks and fill in the content of each block in the course of his work. An empty statement block therefore indicates that there may be missing logic and that some extra code may be required.



SP: Structured Programming The costs of producing and maintaining a computer program are largely determined by its complexity. In writing computer programs a programmer typically uses structured programming techniques to break complex problems down into simpler problems that are easier to understand and solve. This "divide and conquer" process can be repeated until each component is small enough and simple enough to understand, build and maintain. There are various indications that the divide and conquer process has not been completed: 1. SP-1: Routine Too Long Routines longer than 150 lines (excluding comments and blank lines) have been shown to be less stable, more subject to change, and more expensive to fix than shorter routines. 2. SP-2: Nesting Too Deep Studies have shown that few people can understand nesting of conditional statements to more than 3 levels. 3. SP-3: Routine Too Complex Control-flow complexity has been correlated with low reliabilty and frequent errors. 4. SP-4: Module Not Cohesive Routines which are cohesive are typically easier to modify, easier to fix and contain less errors than routines wth diverse tasks. 5. SP-5: Poor Choice of Name A name used in a program too short, too long, too cryptic, too similar to another name or inconsistent with other names



SPM: Single Point of Maintenance The task of a maintenance programmer is to implement a requested change to a piece of software in a consistent fashion, for example, a change to the calculation of sales tax affecting multiple programs. This task is made unnecessarily difficult if the program is constructed in such a way that algorithms and values are duplicated throughout the code, for example through the use of copy and paste, or by hard-coding values into a program. The concept of a single point of maintenance dictates that frequently used elements should be defined, and modified, in a single location. Duplication of such elements increases the difficulty of change, may decrease clarity and increases the likelihood of inconsistency. There are three contraventions of Single Point of Maintenance that are easy to detect: 1. SPM-1: Magic Numbers Numeric literals (other than 0 or 1) have been hard-coded into the program. 2. SPM-2: Magic Strings A string literal has been hard-coded into a statement that influences the flow of a program. 3. SPM-3: Copy/Paste Programming An identical or largely similar section of code appears in two or more places in a program or set of programs. Copy and Paste is considered by many industry experts to be a design error.



DP: Defensive Programming In focussing on the main logic of a program, programmers may fail to take into account abnormal situations, such as invalid data input, or a hard disk becoming full. As a result, their programs are vulnerable to unexpected events or conditions. In essence, such programs have holes in their defenses. In particular, interfaces between programs are some of the most error-prone areas in a system. One often-cited study found that 39% of all software errors were internal interface errors, i.e., errors in communication between programs. Clearly to ensure more robust programs, we need not only to protect ourselves from our own mistakes, but also to isolate our programs from the potential errors of others. We refer to this approach as Defensive Programming. There are various causes of program malfunction that we can defend against: 1. DP-1: Parameter Not Checked A parameter received by a program is used without first checking if its contents are present and within the expected range. 2. DP-2: Status Ignored After Call Error status codes or exceptions from the run-time environment are suppressed or ignored, masking internal processing errors. 3. DP-3: Unexpected State Not Trapped Part of a program that uses a value to switch between different branches does not trap unexpected cases. 4. DP-4: Unused Variables There are unreferenced variables in the code. Unreferenced variables are a strong indicator for other errors. 5. DP-5: Information Exposed Information internal to a module has been made available to other modules. The practice of information hiding makes it much easier to modify large programs.



CfCs: Causes for Concern The quickest and most cost-effective way to inspect software is to read it. Studies have shown that reading source code typically catches 60% of defects, is 20% more effective than testing and that each hour spent reading avoids 33 hours of maintenance work. There are three perspectives from which a program can be read: 1. CfC-NC: Not Complete Some element appears to be missing from the program. 2. CfC-WR: Wrong Result Some part of the program looks likely to produce an incorrect result. 3. CfC-HtM: Hard to Maintain The program looks likely to be unnecessarily difficult to maintain. By their nature, these aspects are difficult to verify. It is also important to note that in inspecting for CfCs, an assessor is being asked for his professional opinion, which is inevitably subjective. However, the goal of this more subjective level of assessment is precisely to initiate discussion with the programmer, with a view to raising awareness of overall quality issues during the development process.

Meer weten? Wilt u meer weten over het beheersen van bedrijfsrisico’s bij de ontwikkeling van maatwerk software? The OSQR Group is gespecialiseerd in software inspectie conform de IfSQ “Level-2 Standard for Computer Program Source Code”, zoals opgesteld door het IfSQ, Institute for Software Quality. Deze standard definieert de “Defect Indicators” binnen de volgende categorieën:  Work in Progress  Structured Programming  Single Point of Maintenance  Defensive Programming  Causes for Concern Neem vrijblijvend contact met ons op voor meer informatie over de mogelijkheden van software inspectie binnen uw organisatie of project. "The OSQR Group is licensed by IfSQ, The Institute for Software Quality, to inspect, rate and certify Computer Program Source Code in accordance with the requirements set out in The IfSQ Level-2 Standard for Computer Program Source Code." IfSQ, The Institute for Software Quality, Cambridge, UK Pagina 7

Direct aan de slag met Software Inspectie van IFSQ

Recommend Documents