Quality Gates in UseCase Driven Development

1
Quality Gates in Use-Case Driven Development

• Wilson P. Paula Filho
• Federal University of Minas Gerais
• Brazil

2
Paper Outline

• Controlling use-case driven software development
  projects
• development proceeds through a series of
  workflows that derive from the use cases
• use case development states
• quality gates for development states
• results and conclusions.

3
Use Case Development States

• Problem-oriented states
• use cases ? use case event flows ? collaborations
  of analysis classes.
• Solution-oriented states
• design use cases ? test specifications ?
  collaborations of internal design classes ? code
• Quality-oriented states
• verified use cases ? validated use cases ?
  quality audited use cases.

4
Quality Assurance

• Objective quality assurance gates
• verification procedures
• performed by
• independent reviewers
• automated scripts
• state transitions do not depend on the
  developers personal appraisal.

5
Quality Assurance

• Kinds of quality gates

6
Quality Assurance

• Inspections
• performed by authors peers
• process-standardized
• based on checklists
• inspection reports record
• defects
• efforts.

7
Quality Assurance

• Tests
• test-driven development
• unit tests written with product code
• layered architecture entity control -
  boundary
• some tests perform multiple role
• control layer unit tests functional integration
  tests
• boundary layer unit tests complete integration
  tests, acceptance tests
• Verification and Validation
• include manual destructive tests.

8
Quality Assurance

• Tests

9
Quality Assurance

• Quality audits
• independent evaluation of conformance
• recheck selected items
• check traceability and consistency
• check other quality gates
• check configuration management
• used for grading in educational applications.

10
Quality Assurance

• Reuse
• improves quality proactively
• reducing opportunities for defect injection
• Praxis reusable framework
• external and internal design classes
• test specifications
• product and test code.

11
Application Results

• Application opportunities
• standard process
• industry-oriented graduate program
• 100 function point course projects
• metrics collection for size, efforts and defects
• this paper two classes Sample.
• tailored process
• real-life applications
• mostly qualitative analysis.

12
Application Results

• Reuse results
• average Java class size similar to Sample
• induced by framework design style, coding
  standard
• lines of code per FP 25 lower than for Sample
• students took profit of reusable framework
• positive side
• students made good use of the framework
• better productivity and product robustness
• negative side
• students did not exercise harder design issues
• project statements should be enhanced with
  additional functional constraints.

13
Application Results

• Test results
• test coverage was good
• further manual testing uncovered just a few minor
  issues
• test case counts for specified tests and each
  architecture layer are as expected
• increasing reuse increased test case counts
• test-driven implementation was significant factor
  in improving quality and productivity
• confirmed by application in real-life projects.

14
Application Results

• Quality audit results
• design and code inspections rechecked
• audit confirmed satisfactory design artifacts
• probably consequence of wide reuse
• many remaining defects in code, despite detailed
  code inspection checklists
• many defects in managerial artifacts
• more guidance is needed for filling them
• there is room for improving productivity
• most productivity losses result from rework.

15
Conclusions

• Use case quality gates improved control of
  software development
• design and standards were indeed applied
• significant reuse
• automated testing correctly applied
• manual tests confirmed quality improvement
• current practices suffice for design material
• need to be improved for other artifacts.

16
Conclusions

• Study limits and consequences
• data provided by just two student classes
• but data agree with trends found in previous
  classes
• for code and test size data, variances found are
  quite low, and data seem reliable and consistent
• recently introduced some improvements in effort
  log and inspection report forms.