Jidoka in Software
Development
Emanuele Danovaro, Andrea Janes, Giancarlo Succi
Center for Applied Software Engineering Free University of Bolzano/Bozen, Italy
{emanuele.danovaro, andrea.janes, giancarlo.succi}@unibz.it http://www.case.unibz.it
Agenda
•
Lean Thinking•
A Jidoka Framework•
Overview•
Components•
ConclusionsLean Thinking
•
Initiated by Toyota when Ford was dominatingthe market using mass production.
•
Initial idea: produce cars of different type on the same production line with similar costs andThe starting point
Time
Lean Thinking Strategy 1:
Removing Muda
Time Set-up
Lean Thinking Strategy 2:
Use
Jidoka
to ensure quality
http://sese.hpu.edu.cn/ie/mirror/leanword.htm
•
Machines that can detect a problem with the produced output and interruptproduction automatically ("Quality at the source")
Examples for Lean Thinking
in Software Engineering
Muda Jidoka Product Process Agility ? Automatic Testing RefactoringJidoka Framework
Plan
Do
Check
Interrupting software
production
•
Alerts•
shown in the development environment•
shown in the tray area•
E-mail•
Deny check-inStopping software
production
•
We need rules to decide whether asoftware artifact is ready to proceed to the next production step
•
Rules use collected measurements to evaluate•
if a situation is critical or not•
evaluate which kind of alert to fireDefine data collection needs
Finding good rules
•
Align rules to busines goals•
Create rules that are understood as useful by stakeholders•
Alignment involving stakeholders in setting the goals before actualimplementation has been found to
Examples for rules
•
Bad smells in code•
Shotgun surgery (on a development level or also across the team)•
Workflow conformance•
Verify if software is developed test-first•
Verify if software is released within a maximum time frameMeasurement Probes
Inputs
Activities
Inputs
•
Main cost driver typically effort•
Time spent editing artifacts like code or documentation•
We built probes that track the time spent within IDEs like Eclipse, Microsoft Visual Studio, Sun NetBeans, etc., and personal productivity suites like OpenOffice andOutputs
•
Output consists of artifacts like code and documentation•
Properties can be observed to determine the quality: dynamically or statically•
dynamically: execute and report problems•
statically: verify source code quality using size, complexity, and object orientedmetrics and report problems
CruiseControl
Source code metric
Activities
•
Identifying activities is not straightforward, it depends on the specific problemActivity
example Possible identification strategy
Testing Editing of files with filename like "test*.java" Editing of file with filename like
Activities
•
We adopt a rule based approach to decide if an activity took place or not•
Rules can be updated "a posteriori" and all events can be re-evaluated again•
The output of this component is the sequence of identified activities, the respective timestamps and users.Conclusions
•
The idea to continuously monitor software artifacts and to alert the developer ofpossible mistakes or problems is not new
Conclusions
•
Novelties•
We measure not only the artifactsproduced but also the resources used as well as the activities performed
•
We use rules to build quality into the process, i.e., to enforce these rules without the need of a person toConclusions
•
Novelties (continued)•
We see a dominance of the "pull" paradigm (stakeholder uses tool toanalyze software development process)
•
We want to promote a "push" paradigm (tool autonomously analyzes software development process according topredefined rules and notifies stykeholders)