You are here: Wiki>SE Web>ResearchHome>ErrorHome>MicroprocessHome (20 Dec 2005, jekutschPCPOOL.MI.FU-BERLIN.DE)Edit

Micro-process of software development

We shortly present the micro-process of software development, its theory, recoding, and usage. A micro-process is the detailed, every-day process of programming (low-level designing, coding, comprehending, testing, understanding) described as a sequence of activities, i.e. events.

Definition

Usually a "software development process" deals with high-level tasks and phases like designing, performing integration tests, or delivering prototypes. This is a "macro" point of view, since it does not cover the details of the tasks, i.e. how they are performed activity by activity. Now, the "micro-process" of software development looks behind the scenes. In software engineering a lot of research has of course been done on how one should perform tests, or conduct module implementation, but only very little on micro-process observation, analysis, and later improvement.

The term "micro-process" is frequently being used in our research group in Berlin. Since "micro-process" has been used for many other research topics in software engineering, we officially use the term "Actual Process" to stress the point that we are observing processes, not defining them. Studying actual processes start naturally bottom-up at the micro level of developer activities.

Take as an example the micro-process of coding, i.e. implementation. Lots of different activities can be observed, like
  • Changing code parts
  • Browsing through code
  • Browsing the documentation
  • Executing the program
  • Pausing for a while, etc.
These activities can be described in even more detail, e.g. changing code parts could be
  • Adding a new method/procedure/function
  • Changing a loop's termination clause
  • Any refactoring, etc.
These activities actually are events in the micro-process. Of course, these events are related. Typical episodes (= row of events) of programming can be extracted, like
  • Change-execute-test cycles
  • Scanning the API documentation for specific keywords
  • Copy-paste-change code fragments, etc.

One of the main tasks in studying the micro-process of programming is for example the identification of these episodes, analysing their relation to each other and to product quality measures, or finding correlations to programmer's expertise in solving a problem. For these studies, it is necessary to automatically capture the events and episodes as detailed as possible.

Applications

Some possibilities of utilizing the micro-process of programming are presented below. They can be divided into process-improving and work-supporting applications, plus those that study programmer's behavior.

Improving the micro-process and techniques

Examining the mirco-process during work can highlight some critical process weaknesses.
  • Error prevention: Specific error-prone coding episodes may give hints on built-in defects. (See ErrorHome for a more general discussion.)
  • Defect statistics: Usually, defect statistics are based on defect tracking data or revision control history. But these sources only provide information on a small amount of the defects which have actually been removed. Many of the removals are only visible in the micro-process data, since they have been removed by the programmer without notice by others.
  • Analysing programmer tests: Usually - even with test first strategy - the programmer is performing some tests on her code just being written. Carefully examining these ad-hoc tests (using code coverage compared to the code just being changed) will give some helpful test quality metrics for the programmer herself or for the quality assureance later.
  • Reviewing: It would be interesting to get a handy kind of replay of a coding episode for a programmer to review her own work or to see how and why others have constructed the code as it is.

Supporting work

  • Tracking code copies: Although often classified as bad behavior, copying and slightly modifying a piece of code is a common practice in coding. By using the micro-process it may be possible to keep track of the copies and its origins and to give a warning in case one of them (but not both) is altered.
  • Supporting refactorings: Speaking about changing copies, it may be possible to inductively learn from code copy changes and suggest reuseable patterns of code.
  • Learning anti-patterns: Code constructs (e.g. typical API usage) which often have been changed later seem to be anti-patterns which can be collected via analysing the micro-process of coding.

Studying the programmer's behavior

  • Performing studies: Please see related work on studies about a programmer's behavior. These studies can be supported by mechanisms for automatically capturing the micro-process.
  • Education: This can also be used for educational purposes to have a review of the work done by a novice on programming.

Environments

We are currently developing an environment for automatically and manually collecting and storing micro-process events with a general mechanism for episode recognition. The collected data can be used for analysing and utilizing the micro-process of programming. For more information, please see the "ECG" Home.

We are aware of three tools for micro-process capturing, the first being the most developed one.

World-wide Interest Group

There's an interest group in micro-processes forming. See the related pages.

Comments

Please add comments below or get in contact with SebastianJekutsch for questions and suggestions.

 

SWTIDSR
Topic revision: r14 - 20 Dec 2005, jekutschPCPOOL.MI.FU-BERLIN.DE
 
  • Printable version of this topic (p) Printable version of this topic (p)