tokyo electron software technologies 1/5 iwfst2005 - testing & quality – issues on...

5
1/5 TOKYO ELECTRON SOFTWARE TECHNOLOGIES IWFST2005 - Testing & Quality – Issues on implementation quality in our project Nov 8, 2005 Tokyo Electron Software Technologies Lt d. Hidekatsu Matsuda

Upload: drusilla-mcbride

Post on 03-Jan-2016

215 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: TOKYO ELECTRON SOFTWARE TECHNOLOGIES 1/5 IWFST2005 - Testing & Quality – Issues on implementation quality in our project Nov 8, 2005 Tokyo Electron Software

1/5TOKYO ELECTRON SOFTWARE TECHNOLOGIES

IWFST2005- Testing & Quality –

Issues on implementation quality in our project

Nov 8, 2005

Tokyo Electron Software Technologies Ltd.

Hidekatsu Matsuda

Page 2: TOKYO ELECTRON SOFTWARE TECHNOLOGIES 1/5 IWFST2005 - Testing & Quality – Issues on implementation quality in our project Nov 8, 2005 Tokyo Electron Software

2/5TOKYO ELECTRON SOFTWARE TECHNOLOGIES

Overview of our project• Developing GUI screen programs for

semiconductor manufacturing equipment.• Language: C++• More than 100 screens.• Total 550KLOC.• Team of 25-35 engineers.• Engineer Profile:

– Experience on software development:1 to 15 years. Average 8 years.

– Experience on OOD / C++:1 to 6 years. Average 3 years.

Page 3: TOKYO ELECTRON SOFTWARE TECHNOLOGIES 1/5 IWFST2005 - Testing & Quality – Issues on implementation quality in our project Nov 8, 2005 Tokyo Electron Software

3/5TOKYO ELECTRON SOFTWARE TECHNOLOGIES

Defect classification by injected phase

• In our project, 38% of defect has been injected in implementation phase.

• Type of errors:- Incorrect conditional

logic- Access to deleted

object- Memory leak- Lack of error

handling- Etc,…

Page 4: TOKYO ELECTRON SOFTWARE TECHNOLOGIES 1/5 IWFST2005 - Testing & Quality – Issues on implementation quality in our project Nov 8, 2005 Tokyo Electron Software

4/5TOKYO ELECTRON SOFTWARE TECHNOLOGIES

To reduce defect injection in Implementation phase…

• We tried to introduce source code inspection, but it didn’t work because:– Under tight development schedule, design phase tended to

delay, resulting shortened implementation time. This makes engineers reluctant to try new and time-consuming practices.

– Everybody knows that code inspection is one of the “best practices”, but are not sure the degree of its positive impact in their own project.

Best practices are easy to understand but difficult to promote in real project without showing their positive impact to engineers usingexample or data from their own project. It would be nice if we haveeasy-to-use models that can show the impact of best practices tosoftware engineers.

Page 5: TOKYO ELECTRON SOFTWARE TECHNOLOGIES 1/5 IWFST2005 - Testing & Quality – Issues on implementation quality in our project Nov 8, 2005 Tokyo Electron Software

5/5TOKYO ELECTRON SOFTWARE TECHNOLOGIES

Measuring implementation quality• We refactored one of a module to measure the result using several met

rics. Improvement by the refactoring was not very obvious by the metrics. Are there more practical metrics?

MetricOriginal Refactored

Overall Per Module Overall Per Module

Number of modules 22   73  Lines of Code 1921 87.3 3431 47.0

McCabe's Cyclomatic Number 459 20.9 650 8.9

Lines of Comment 646 29.4 1531 21.0

Information Flow (Square(Fan-in * Fan-out)) 1346 61.2 3558 48.7

  Original Refactored

Max CBO (Coupling Between Objects) 13 20

Average CBO 3.47 4.57

Max Information Flow 1296.0 1936.0

Average Information Flow 70.8 52.3