EGYPT SPIN Newsletter (Issue2)

8/10/2019 EGYPT SPIN Newsletter (Issue2)

http://slidepdf.com/reader/full/egypt-spin-newsletter-issue2 1/14

Egypt–SPIN Newsletter

Issue 2, Apr – June 2003

Sponsored by SECC

Egypt -SPIN Newsletter Issue 2, Apr - June 2003Sponsored by SECC Page 1 of 14

From the Editor

Welcome to the second issue of Egypt-SPIN newsletter. The feedback to the firstissue was high but we still need to keep it higher. Fujitsu Egypt was sponsoringSPIN event on (April 7 th ,2003), in this issue Eng. Walid Gad the CEO of Fujitsu Egyptis presenting their experience to implement CMM ® in their organization under thetitle “Fujitsu Total Quality Roadmap”.

Dr. Adel Ghanam, the CIT chamber member in our steering committee is sharing inthis issue with an article under the title of “An Opportunity that shouldn’t belost”. Dr. Adel has 37 years of IT experience in local and internationalorganizations. He is a member of ACM & IEEE since 1967 and the AmericanProduction and Inventory Control Systems (APICS) since 1996. Dr. Adel is thechairman of the software and manufacturing chapters of the CIT , FEI And the vicepresident of IT export council you can contact him at [email protected] .

Marian Tadros is also contributing in this issue with an article “SoftwareMeasurement (Why, What and How)” Marian is a Certified Software QualityEngineer (CSQE) from ASQ /USA. She is also a Certified Quality Expert (CQE) and aCertified Quality Management Representative (CQMR) from TUV/Germany. She hasover 10 years experience in building quality teams and applying quality practiceswithin local software houses. You can contact her at [email protected]

Mohamed Shawky is contributing in this issue with an article “ Defect-FreeSoftware through Inspection”. Mohamed has a Masters degree in Computerscience from the University of Victoria Canada. He worked for over two years atMotorola Canada as a Senior Software Engineer developing software for wirelesssystems. You can reach him at [email protected]

Enjoy these articles and give us your feedback. Again I want to remind you thatyour contribution is greatly appreciated, it can be an article , point of discussion,comment, suggestion or others. Our newsletter is always in need of interestingarticles dealing with the related subjects. Please send general correspondence orarticles that you would have considered for publication to me (Madiha A. Hassan –Smart Village- Egypt) Also you can reach me at [email protected] The deadtime for expressing your interest to share in the next issue is 15 – July – 2003.

Table of ContentsSteering Committee Meetings Summary ........................................................... 2

Fujitsu Total Quality Roadmap…………………………………………………………………………………..…3 Featured Article …………………………………………………………………………………………………………… .7

Software Measurements ............................................................................... 8 Defect Free Software through Inspection ………………………………………………………………… 12




Steering Committee Meetings Summary

The Steering Committee had continued itsdiscussions on how to apply an appropriatemechanism for the organizations whichstarted its program for implementingCMM®, And a realistic local model forimplementing Software ProcessImprovement in small companies.

The committee referred companies, whichhas started implementation since 2002,and had conducted gap analysis or in itsway to do it through the MCIT/SECCprogram as Phase I Companies . Othercompanies which are categorized undersmall companies and cannot affordapplying CMM® in the near future but stillthere is a need to distinguish them byapplying a realistic local model as PhaseII Companies .

P h a s e I Co m p a n i e s

StatusImplementation cost is very high, adding tothat the down economy attributes (lowsales, deficit in revenue,….) are greatconstraints for our local companies toafford the formal assessment cost.

Recommendations:

o MCIT/SECC should continue its supportfor these companies by developingfunding mechanism for formalappraisals as a kind of incentives orawards for these pilot companies. Thiswill speed up the implementation of themodel in Egypt.

o Criteria of this financial support shouldbe clear and applicable.

o Any company, which receives thissupport, should work as a guide forPhase II companies (the kind ofguidance will be discussed with thecommunity in large).

o A detailed program plan will bedeveloped and presented in the nearfuture.

P h as e I I C o m p a n i e s

Status

SMEs in the local software community havedifficulties in implementing anyinternational quality management system.CMM® as the recommended model shouldbe interpreted / tailored for smallorganizations as it is cost prohibitive toincorporate all processes and proceduresthat would normally implemented in largeorganizations. Administrat ive work requiredto apply CMM® for SMEs is beyond theirlimited resources. But we need todistinguish these companies and have asolid foundation to build capability forEgypt software industry. This kind ofquality mark or certification as thecommunity will agree upon will create acompetitive edge in the local market.

Recommendations:

o Accept a local certification model basedon CMM® which will serve as anintermediate step towards theinternational certification.

o

This local certification should be given inits initial startup by an internationalconsultant (strategic partner fordeveloping the local industry).

o This local certification should be a mustfor any local business.

o Comprehensive training program shouldbe developed for this purpose .

Egypt-SPIN Upcoming Events

July, 2003 EDS SPI Case Study

October, 2003 Raya Software Case Study




FUJITSU TOTAL QUALITY ROADMAPEng. Walid Gad

I n t r o d u c t i o n

The objective is to demonstrate Fujitsu'sWay to achieve TQM, concentrating on S/WDevelopment.

We applied different quality standards andmodels. All these models have commonattributes:

• NON PERSPECTIVE - they all specifyrequirements but do not tell or imposehow to achieve,

• LEADERSHIP - all focus on theimportance of full backing andsustained commitment of leadership.

• SELF ASSESSMENT - ISO 9001(audit), EFQM (self assessment), CMM(appraisal)

• PEOPLE & PROCESS BASEDMANAGEMENT SYSTEM - thatsatisfies both the standard and thecompany specific requirements,

• COMPETENCE - of both managementand staff

• MEASUREMENT - as a tool for continualimprovement.

1 9 8 7 : A P P LYI N G I E EE S TA N D A R D S

Applying IEEE standards to S/Wdevelopment was a UK decision.

A local S/W Development Methodology wastailored from the company's methodology,and supported by " Structured Analysis &Design".

1 9 9 1 : TQ M AW A R EN E SS

TQM principles have been presented to allmanagement and staff. It referred toCrosby's and Deming's steps for achievingtotal quality, to Crosby's 4 absolutes ofQuality.

The following was introduced through"Process Management" awareness:

" BUSINESS SUCCESS depends onachieving CONFORMANCE to CUSTOMER

REQUIREMENTS through correct operationand control of CAPABLE PROCESSES andPLANNED RESOURCES used effectivelyand efficiently".

OR simply " PROFITS through PROCESS through PEOPLE "

"5 steps of success" supported themessage, both seems to be very modern:

1. REQUIREMENTS - clear, understoodand agreed

2. PROCESS - adds value, understood anddefined

3. PROCESS CONTROL - main area tocontrol is the interfaces betweenprocesses

4. PROCESS CAPABILITY - ability tosatisfy requirements every time,measured by:a. Product Conformance,b. Process Performance

5. PROCESS RESULTS - reviewed forimprovement

P R O C ES S M O D E L :

• Objectives, goals, policies, constraints,• Procedures & work instructions,• Customer, output & its specification,• Suppliers, input & its specification,

• Skills and, tools

Many concepts were introduced concerning"Process Management":

All work is a process, We all have an

output/product, We all have customersInternal and External, We all have suppliers,

All products have requirements, Allprocesses have requirements, Processesare chained by requirements that add value,

All work needs a process capable of doingthe job, Prevention designed into processesleads to success, Feedback provides thebasis of control and improvement,




Requirements change with time processowner, and Continuous improvement is key.

1 9 9 3 : I SO 9 0 0 1 : 1 9 8 7R E GI S T R AT I O N

It was a UK initiative as response to theneed to integrate with the European Market.

As the Process Concept was alreadyestablished, it has been used to documentthe Quality Management System.

This was the real start of commitment toQuality company-wide. It also enhanced thealready used S/W DevelopmentMethodology and its deployment.

Being the first company registered in Egypt,we started giving training and consultationthat helped many companies achieve thecertification.

1 9 9 4 : E FQ M EU R O P EA NE X C E L L E N C E M O D E L :

The HQ in UK saw ISO 9001 to beinsufficient to evaluate or benchmark thecompany's performance. The model wasselected to achieve the objective.

Applying the model was mandatory only inthe European branches, but we decided togo through the pain and to go through theprocess to its end that is delivering aSubmission for External Assessment.

In brief the model is based on 5 "result"criteria and 4 "enabler" criteria, each hasdetailed requirements, measures and score.

Applying the model you will feel its dynamicnature, studying results leads to enablers'improvement that leads to better results .

1 9 9 8 : P R O JE CT M A N A G EM E N TS TA N D A R D I S AT I O N :

The UK Government mandated PRINCE-2,and Fujitsu committed to apply world wide.

1 9 9 9 : Ti c k I T CER TI F I C AT I O N :This was a local decision in order to meetthe market trend " Specialized certification inS/W Development".

TickIT was selected for being the applicationof ISO 9001 in the IT industry.

The Gap Analysis lead to crucialenhancement in the methodology, mostlycommitment to its deployment , e.g.:• Verification of Test Plans against

Requirement Specifications

•

Clear identification and mutualagreement of the acceptance criteria,• Documenting Maintenance procedure,

including problem handling

• Tighter Subcontractors evaluation andcontrol,

• Formal design reviews,• Keeping records of testing planning and

results,

Tick-IT was re-issued in Jan 2001, toconform with ISO 9001:2000 whichintroduced new requirements for processdefinition, process monitoring and continualimprovement:

Part E, Software Quality ManagementSystem requirements, StandardsPerspective - contains guidance to helpinterpret the new ISO 9001 requirementsand to be used as a substitute for ISO 9000-3 (there is uncertainty about it and is beingrevised).

Part E, Software Quality ManagementSystem requirements, Process Perspective -

contains a much expanded and improvedversion. There are many examples of goodpractices

2 0 0 1 : I S O 9 0 0 1 2 0 0 0R EG I S T R AT I O N :

It has two main objectives, which areembedded in all the requirements:• Customer Satisfaction• Continual Improvement

• Beside the new requirements of processmodeling and Measurement of ProcessPerformance and Product Conformance,

ISO 9004 Quality Management Systems -Guidelines for Performance Improvement;has been developed to form a consistentpair with ISO 9001, by having similarstructures. As 9001 focuses on theEFFECTIVENESS of the QualityManagement System in meeting customerrequirements, 9004 gives guidance on a




wider range of QMS objectives than does9001 particularly the organization's overallperformance and effectiveness. However itis NOT intended for certification.

2 0 0 2 : CM M P L A N , TH R O U GH

A P P R E CI AT E D S U P P O RT " S EC C" 1. AWARENESS PLAN; courses run by

SECC, and internal training to SWEngineering Management and Staff

2. MAPPING TICKIT TO LEVEL 2 CMMKPAs, (Crucial GOALS are common):

• RM: Same concept of AllocatedRequirements, its review & changemanagement, its use as baseline for allthe project activities, and theimportance of keeping requirements,plans and technical products consistent

as the requirements change.• SPP: Identification of s/w product & all

its components and volume estimationare the base for the planning activities,The use of repositories for informationand data to be used for estimation,Selection and tailoring of appropriateSoftware Life CycleClear Assignments of responsibilities,and interface between different groups

• SPTO : Tracking actual performanceagainst the plan,

Taking corrective actions in case ofdeviation, All parties agree changes tocommitments

• S S M : Having criteria for evaluation andselection,Having procedure for agreeingcommitmentsHaving means for cooperation andmonitoring subcontractor's actualperformance against commitments

• S Q A : By Qualified Independent

Personnel,Having formal schedule for process,products, and activities review andaudit,

A Mechanism for regular reporting ofSQA activities status and results,

A Mechanism for escalating problems• S C M : Planning SCM activities

A Mechanism for Configuration Itemsunique identification, and Traceability,Establishing Baselines and a procedurefor change identification,documentation, review, authorizationand implementation, and traceability

between authorized Change Requestsand the modified Configuration ItemsControl of CIs; back-ups, access tosuperseded items,

Auditing configuration managementeffectiveness,Version Release Management; BuildStatements and records of deliveredproducts for Re-buildConfiguration Status Accounting andReporting

3. PRE-ASSESSMENT;•

Findings are based upon :- Five interviews with personnel at

various levels (7 staff members):

Projects Director (meeting of team

not scheduled interview), Project

Managers, Designers, Bid Manager,

configuration controllers, software

quality assurance personnel

- Review of some documentation

- Knowledge of team members

- Discussion among the team

- Software development activities of

two projects. Insight into the E-

Business Channel

- Key Process Areas (KPAs): Level 2

KPAs and Level 3 KPA Organization

Process Focus• COMMON Weaknesses:- Little evidence of consistent reviews

by SQA of activities of the KPAs

(Ve3)

- The measurement of the status of

the activities

- Signed organizational policies for the

KPAs for Fujitsu Cairo

- It is not clear for most KPAs that

there is formal periodic review of the




activities by the Projects

Director(Ve1)

- In a number of KPAs, there appear

to be no periodic and/or event driven

review by project managers (Ve2)

4. ACTION PLAN to overcome weaknesses




Featured Article by Dr. Adel GhanamAn Opportunity that Shouldn’t be lost

B a c k g r o u n d

The second half of the 80’s witness therise of the private sector in the EgyptianSoftware Industry. As any life activity, the

evolution of this industry needed asponsor ,to look after its development andcreating the required mass ,so that it canbecome an effective power in the society.The IDSC was the ideal candidate to takethe role of sponsorship, at that time. In theearly 90’s the number of private softwarecompanies has been almost doubled, withrespect to the late 80’s, and this growthcontinued at a rate of about 30%-to-40%annually.Companies started to cluster aroundcommon visions. This led to the formation

of a set of associations. However , all wereunited around pushing forward theindustry.They succeeded to position the IT on theNational agenda, and the MCIT wasformed in 1999.

T h e Co s t o f F r a g m e n t a t i o n

Unfortunately ,starting from 2001, itbecame clear that ,with the absence ofeffective coordination, these organizationshave created some ambiguity at thePolitical level to identify which one shouldtake the lead ,to drive the interests of theprivate sector. Especially ,with thebeginning of the recession state, and thestart of serious problems to be faced .Limited resources, was a reason enoughfor those organizations to consolidate andfocus their efforts on a small number ofeffective objectives. The cost of not doingwas high. Loosing time, the most preciousasset in our industry.

T h e O p p o r t u n i t y We need a coordinating entity, that is freefrom politics and has the power toinfluence the decision making process.I believe the SPIN group meets thesequalification . It is positioned within theNational SECC , i.e., it has accessibility tothe State decision makers. All privatesectors organizations and the academiaare presented. However, it should not beanother organization on the list. Its powerwill be inherited from its capability to work

on few and realistic projects that havegood return for the whole industry.

T h e w a y Fo r w a r d

The Software industry is facing a long listof problems, on the top of this list is thedevelopment of high quality products , toimprove their competitiveness in the localand international markets. The problem is“You Can’t Control What You Can’tMeasure”.I propose the SPIN group, to adopt settinga package that software companies canuse to measure a set of simple qualitymetrics. The data instrumentation shouldbe simple enough to reduce datacollection costs, and yet precise enough tolead to the desired quality.The following is a set of simple metrics.

• B u g s C o u n t : Av. No. ofbugs/program

• R e u s ab i l i t y : The OO softwarebased on classes, inheritance, andcomponents , is by default a reusablesoftware. It is measured on theaverage number of uses of a givencomponent ,referred to the totalnumber of programs developed overa specific period of time

• M a i n t a in a b i l it y : It is the averagenumber of days it takes to repair thecode after a problem has beendiscovered ,or modifying an existingfunction, and produces necessarydocumentation (Bowen, 1985 )

• T e st a b i l it y : Testability is measuredrelative to simplicity, modularity,instrumentation, and selfdescriptiveness criteria.

• I n s t r u m e n t a t i o n : It is the averagenumber of probing points per module(w.r.t. the total number of LOC)

•

F u n c t i o n a l Sc a la b i l it y : Theaverage number of days it takes toadd new functions to the software andproduces a full new set of documentfor the new release.

• R e l i a b i l i t y : It is the mean timebetween failure MTBF

• C o n f i g u r a b i l i t y : The number ofuser configurable function itemsrelative to the total number of functionitems




Software Measurements (Why, What and How)

By: Marian Tadros

I f Y o u Ca n N o t M e a s u r e I t Y o u

Ca n N o t M a n a g e I t . ( A n o n y m o u s )In the current business environment andmarket status every organization isengaged with a certain question, trying tofind the answer: “Are we achieving theresults we desire?. This is posed in manyways, such as: “Are we meeting ourbusiness objectives? Are we earning a fairreturn on our investment? Can we reducethe cost of producing the products orservices? How can we improve theresponse to our customers’ needs orincrease the functionality of our products?

Are we taking the right steps towards theprocess improvements? How can weassess our efforts in order to attain a CMMlevel?

The demand for increased efficiency andeffectiveness of our software processesplaces the measurement demands of thesoftware engineering community beyondthose traditionally practiced. In fact,statistical and process thinking principleslead the way to using statistical processcontrol methods, a means of determiningthe consistency and capability of the manyprocesses used in software development.

The Measurements concept (theory,methodology) is meant to be utilized bybusinesses in identifying where theystand, where they are heading to, andwhether they are taking the right path toachieve their specified targets.

M e a s u r e m e n t s a s a F u n c t i o n o fCh e c k S t e p i n t h e P l a n , D o , Ch e c k( P D C A ) M o d e l

In order to check any activity it should beplaned and already executed.

Such a software activity must be planedand applied, so as to form a fertileenvironment for checking, hence, formeasurements.

Yet, measurements data should bereliable and valid. In this context reliabilityrefers to the consistence of the number ofmeasurements taken of a metric using the

same measurement method on the same

subject. While validity refers to whetherthe metric really measures what it isintended to, and whether it adequatelyreflects the real and inherent meaning ofthe concept under consideration(inspection ).

W h a t c o u l d b e M e a s u r e d i nS o f t w a r e ?

There are several classes of entitieswhose attributes should be taken intoconsideration when designing the softwaremeasure. These are the Process, theProduct and the measure of theRecourses . For example: Size is aproduct attribute that could be measuredby KLOC, no. of modules, Functionpoints…. Etc.Actua l ly, the p rob lem l i es no t inse lec t ing ac t iv i ty to be measured , i t l i e sin d e te rmin ing the in tended goa l upo nw h i c h w e c o m e t o k n o w w h a t s h o u l d b emeasured .

H o w T o S t a r t ?

1. Measures Should Be Driven byGoals

• State the major goals, subjective andquantitative.

• Set goals priorities.• Set the sub goals.

For example : The com pany pro jec tmanagement goa l i s to con t ro l thevar ia t ion percen tage be tween the ac tua lper fo rmance o f the ac t iv i t i e s and thepro jec t sched u le

Pro jec t Mangment Goa




2- Derive Metrics from GoalsVarious frameworks have been proposedto select metrics for software project use.One such paradigm for establishing ametrics program is the Goal-Question-Metric Paradigm.

Goals

What is the organization trying toachieve? The objective of processimprovement is to satisfy these goals.

Questions

Questions about areas of uncertaintyrelated to the goals. Process knowledge isessential to derive these questions.

Metrics

Measurements to be collected to answerthe questions.

Goal-Quest ion -Metr ic Paradig m

3- Plan for Quality Data Collection A measurement process is based on

collecting and analyzing well-defined data. All too often those who shoulder the taskof collecting measurement data oranalyzing reported data, are actually notgiven sufficiently complete specificationsor descriptions of the data. Consequently,there arise assumptions that lead toincorrect collection or analyses.There are three criteria that serve asguidance in understanding the meaning ofwell-defined data [Park 92]:• Co m m u n i ca t i o n : Will the methodsused to define measures or describe

values allow others to know precisely whathas been measured and what has beenincluded in and excluded from aggregatedresults? Moreover, will every data usergets to know how the data have beencollected, so that he/she can interpret theresults correctly?• R e p e a t a b i li t y : Would someone elsebe able to repeat the measurements andget the same results?

• T r a ct a b i l i t y : Are the origins of the dataidentified in terms of time,sequence, activity, product, status,environment, measurement tools used,and collecting agent?4- Collect Data for Metrics According

to the Measurements PlanSuppose that the following is the phases’measure for a number of 10 projects

5- Analyze the Collected Data

Normal d i s t r ibu t ion o f de f in i t ion ph asefor 10 p ro jec t s

Looking at the bell shape we will find thatthe mode and the mean are not on thetarget. Also, there are variations in theprojects’ readings. Although the mode

which indicates the most frequentlyoccurring number is not far from the target,it does not reflect the control of thedefinition phase process . It may be poorlyplanned and badly executed, and theinfluence does not appear in this phasebut appears in the following phases.

Normal d i s t r ibu t ion fo r Cons t ruc t ionphase fo r 10 p ro jec t s

The construction phase is very far from thetarget; the reading distribution is nothealthy at all. There is an obvious problem




in the planning and execution of theconstruction phase activities.

Normal d i s t r ibu t ion fo r Main tenancephase fo r 10 p ro jec t s

Although the maintenance mean in theabove figure is not near from the target,which signifies that almost all projectmaintenance planned schedules are notachieved, the variation is relatively small.This indicates that the root causes of the

projects problems may be similar, and thismakes the target achievement much moreeasier.

6- Define the Root Cause AnalysisStability of a process with respect to anygiven attribute is determined by measuringthe attribute and tracking the results overtime. If one or more measurements falloutside the range of chance variation, or ifsystematic patterns are apparent, theprocess may not be stable. We must thenlook for the causes of deviation, andremove any if found so as to achieve astable and predictable state of operation.Root cause analysis is a technique usedfor establishing the most affecting causesof problemsLet’s take the construction phase as anexample:

Root Cause Ana lys i s fo r the Var iat ionprob lem of the cons t ruc t ion phase .

From the Fish Bone diagram (Root Cause Analysis) shown above, it is clear that

there are many opportunities ofimprovements related to the projectplanning and definition phase.The most affecting of them are related toplanning activities and the others arerelated to the inputs from the definition

phase. As for the other minor causes,these are related to the project trackingand resources.You can use Parato diagram to setpriorities and select the problems youshould start to solve. Then you shouldplan for the improvement procedures andsteps.

7- Using of Management andPlanning Tools to Propose Solutions

A stable and predictable process is reallyachieved only when all assignable causeshave been removed and prevented fromreoccurring in the future so that only asingle, constant system of chance causesremains.

8- Establish an Improvement Plan

9- Apply New Changes to Projects

10- Measure and Collect Data

11- Analyze Data and Evaluate theProgressWhen reaching a stabilized process withaccepted reading, such as the followingexample, just then we can use the controlchart for statistical control of our projects.

Normal d i s t r ibu t ion fo r Def in i t ion a f te ri m p r o v e m e nt




Normal d i s t r ibu t ion fo r Cons t ruc t ionsaf te r improv ement

Normal d i s t r ibu t ion fo r Main tenanceaf te r improv ement

In the above diagrams we can see anobvious improvement in the projectscheduling activities, and the reducedvariation between the planned and actualactivities. The bell shape becomes moreconcave and the curve mode and meanare closer to the target.When a process is stable, 99+% ofprocess performance variation will fallwithin 3 sigma of the mean or average ofthe variation. When the process variationfalls outside of the 3 sigma limits, thevariation is very likely caused by ananomaly in the process.When a process is stable or almost, the 3sigma limits determine the amount ofvariation that is normal or natural to theprocess. This is the "voice of the process"or the process telling us what it is capableof doing. In this stage you may take adecision of using control chart .

Finally, Measurements can serve as athermometer of our organization capabilityand maturity. Just remember that if you donot know where you’re going, then anyroad will do (Chinese Proverb), and if youdon’t know where you are, a map won’thelp (Watts S. Humphrey)




Defect-Free Software through InspectionsBy: Mohamed Shawky

Software inspection was invented byMichael Fagan in 1970 while he was workingat IBM. Inspection is a process that is widelyused in hardware design, and nowbecoming an established procedure in alllarge software organizations. The inspectionprocedure has one main goal, and that is tofind faults in the work product beinginspected.

Fagan argues that practicing the Faganinspection results in finding more than 90%of all operational defects before testing,which in turn would result to better quality,shorter time to delivery, lower costs, andbetter system availability.

Though the most obvious work product inthe software lifecycle to be inspected iscode, all work products in the developmentlifecycle need to be inspected. How manytimes did you start writing code for a designthat did not completely fulfill therequirements and specifications of thesystem? Hence, all deliverables need to beinspected, from requirements, designdocuments, code, and test documents.

Inspectors typically are looking for all kind offaults in the work product, in a requirementsdocument they are ensuring that therequirements are complete, accurate, andclear, in a piece of code, they are ensuringthat the implementation is complete(satisfies all the low level design),correctness of functionality and logic,conformance to coding standards, amongother things.

Inspection teams are formed of a moderator,the author, a reader, a tester and inspectors.

The moderator leads the inspection teamthrough the inspection process, while beingan active inspector. The moderator needs tokeep the inspections objective, keep theinspections focused, be sensitive to theeffectiveness of the inspection team, andexercise good judgement where re-inspections maybe required. The author isthe creator of the work product that is beinginspected, and is an active inspector. The

author should have a vested interest inensuring that the inspection finds all the

defects that are present so as to avoidfinding these defects later, and is therefore,not defensive as faults are being discussedin his/her work product. The reader willparaphrase each statement in the his/herown words, expressing the meaning of eachstatement with a level of understandingsufficient to demonstrate that she of heunderstands the work product beinginspected well enough to carry out the nextstage of development, or to fully use thework product. The tester will consider howthe work product will be tested and ask

questions during the inspection meeting thatresembles test cases.

There are three kind of items that can bereported in an inspection, an operational(major) defect, a minor defect, or aninvestigate item. An operational (major)defect is a condition that could causeoperational failure or produce anunexpected result within a range of aspecified operation. This includes anythingthat may be identified by a customer asneeding correction. A minor defect is acondition of bad workmanship in theproduct, including any case that could causedifficulty during maintenance, but would notcause operational failure. An investigateitem is a questionable condition that can notbe proven to be or not to be a defect withthe information available in the inspectionmeeting. It will be investigated and resolvedduring the rework.

A typical inspection process has sevensteps. Inspection planning, kick-off meeting,preparation, inspection meeting, inspectionanalysis, rework, and follow-up. During theinspection planning, the inspection teammembers are chosen, and the materials forthe inspection are checked to ensure theymeet the entry criteria for the inspectionprocess. The remaining six steps areplanned for. The kick-off meeting is held withthe inspection team members for the authorto provide an overview of the material to beinspected to allow the inspectors to have




sufficient background to proceed with thepreparation. During the preparation, eachindividual inspector learns the inspectionmaterial to fulfill their assigned role throughwriting questions concerning apparentlyproblematic or unclear areas that they wouldraise during the inspection meeting. Duringthe inspection meeting, the inspector teammembers meet and systematically gothrough the work product to discuss and finddefects. Inspectors should refrain from tryingto find solutions to problems. After themeeting is over, the inspection teamanalyzes the first five inspection steps. Thisinvolves isolating fault causes andidentifying improvements to the inspectionprocess. During the rework phase, alldefects identified are fixed by the author,and all investigate items are resolved todetermine if a defect exists or not. Themoderator then follows up to verify all faultfixes and ensure that all investigate itemsare resolved. The moderator may call for are-inspection meeting if the rework resultedin a major changes to the originallyinspected work product.

Typical guidelines for inspection ratessuggest to have inspection meetings notexceed two hours and the following rates forthe preparation and inspection meeting:

Code Text

Preparation 125-300LOC/Hr

10-20Pages/Hr

Inspection 100-200LOC/Hr

10-20Pages/Hr

Following this process of inspection in

software development have proven to be aneffective method for improving the quality ofthe software produced, reducing the cycletime, and increasing productivity. MotorolaGlobal Software Group have reported in theSEPG national conference that after twoyears of following this process, their shippeddefect density have been reduced 20 times,with 50% reduction in cycle time, two timesincrease in productivity, 55% increase in

customer satisfaction and $45 millionestimated cost avoidance for coding defectsalone.




Documents

EGYPT SPIN Newsletter (Issue2)