I.Bider (IbisSoft, Stockholm, email: ilia@ibissoft.se)

M.Khomyakov (M7, Moscow)

Position paper for an ECOOP'97 workshop. Published in: Jan Bosch and Stuart Mitchell, editors, ECOOP'97 Workshop Reader, Springer 1997, LNCS 1357, pp. 319-322 

Software production, as any other business process, consists of two parts: a creative part, and a routine one. The creative part is about finding the best way to approach the problems a software system should solve. The routine one is to complete all activities needed for producing software, e.g., coding, compiling, linking, testing, bug fixing, etc. Both parts need management. However, the creative part is very much dependent on the individuals in charge of the overall system architecture, just good management can’t solve the problems of good design. The creative part, though the proportion of it in the software industry might be greater than in other industries, doesn’t solve all the problems of software production. All routine operations should be properly carried out in order for a software project to succeed. These operations are easier to formalize, and thus model.

The quality of the software production process has direct impact on the quality of the resulting software system, and may be, at least partially, evaluated by studying this system. Probably, the most important factor of the software system quality is the quality of its structure. This parameter may be roughly measured as the total amount of program code. Another way of measuring the structural factor may be by measuring the reusability level of the basic program units, e.g., objects, functions, etc. (here, we mean the reusability of the basic units inside the same system). However, good software structure alone doesn’t guarantee the quality of the system. Another important factor is how well the software system structure reflects (or models) the application domain it is aimed to work in. This factor affects the tolerance of the system to changes in the specifications (which usually occur on all stages of the software production process), and its possibility to acquire new functionality without major restructuring, i.e. system adaptability.

The factors mentioned above, which characterize reusability, and adaptability, reflect the quality of the creative part of the software production process. It’s difficult to measure them directly, especially the second one. But those parameters can be evaluated indirectly by taking into account all the routine operations completed. For example, poor adaptability will result in major restructuring of the system during it’s lifetime when new functionality is added.. This will immediately result in the rapidly growing number of routine operations performed during the system lifetime. Poor reusability will affect the reported problems/bugs ratio. The better reusability, the more chances that fixing one bug will result in solving many reported problems.

Thus, one legitimate approach to evaluating the quality of software processes and systems is by studying all the operation performed in the frame of the process during the system’s lifetime. To effectively use this approach we need:

• A model that gives us a structured representation of all routine operations performed during the system’s lifetime
• A way to gather all information that we need to put in the model.

The amount of information that will be needed for this approach is enormous and there is no chance to collect it in any other way than by registering all of them in the computer. We need a system that will register information about all activities completed in the production process. To motivate people using the system, it should not only register operations, but should also help to perform and manage them. Ideally, we need a system that helps individuals with all aspects of their routine work which usually consists of:

• execution of routine activities, like writing documentation, coding, compiling
• registration of the activities performed.
• planning of new activities.
• communication with colleagues concerning the above activities.

And we need a kind of a formal model to build this system upon, and the same model may help us to analyze the information gathered by the system, and indirectly measure the quality parameters of the production processes.

The authors’ interest in management automation goes back to 1984 when we started our own CHAOS project, where CHAOS stands for Concurrent Human Assisted Object Systems. The ultimate goal of the project was to create methods and programming environment for design and implementation of distributed management automation systems. As the only business process well known to us at that time was software development, we always have in mind the task of building a computerized secretary for a programmer.

Our theoretical model was first tested in practice in 1989-90 when we were developing an application for supporting sales and marketing activities of a trading company. The system was called DealDriver to highlight that it helps the workers to "drive" their deals from the beginning to the end which is receiving payment. For this project, we devised a practical object-oriented model for representing business processes which is described in more details in [1,2]. During the project we also developed homemade object support tools which included Hi-base - an object-oriented historical database, and Navi - an object oriented user-interface system.

The object model and support tools were later successfully used for modeling business processes in other application domains. We believe that our practical model (with some modifications) can be adjusted to modeling software production processes.

Business processes are represented in our model as objects which we call organizing objects (or orgobjects for short) to stress their importance in organizing all activities of the business process. The state of an orgobject reflects the current state of the business process; the consecutive order of all its previous states shows the evolution of the process in time. The orgobject’s state, sometimes together with its history indicates what further steps should be completed to transfer the object to the final state which means that the goal of the process has been reached.

Object is a central notion of the model. Not only are business processes represented as objects, but also all other entities of the application domain, such as software modules, the project’s personnel, etc., are also represented as objects. Objects are complex and dynamic. The complex nature of objects is reflected by links that show the inclusion of one object into another. The dynamic properties of objects are expressed by concepts of history, events, and activities.

History is the time-ordered sequence of all the previous states of objects. Events present additional information about transitions from one state of the object to another, like date and time when the event had occurred, date and time when the event was registered in the system (may differ from the previous one), the person whose actions caused changes in the object (if applicable), etc. Activities represent actions that take place in the world of application domain, like performing a software module compilation. In the model, the activity moves an orgobject to the next stipulated state.

Our model implements an approach to management of routine work that we call a process-oriented management. The main characteristics of this management scheme is dynamic and distributed planning. Dynamic planning involves planning only the first few activities at the first stage. As soon as one or several of these are completed, new activities are planned with regard to the emerging state of the relevant orgobject. Distributed planning implies that the worker who has completed a planned activity himself plans the subsequent activities, thus there is no central planning. Moreover, he/she can assign these new activities not only to himself, but to other people too.

The principle of dynamic and distributed planning is realized in our model by a notion of planned activity. A planned activity is an object that contains such information as type of activity (compilation, etc.), planned date and time, deadline, reference to the person who is responsible for performing the activity, etc. Planned activities are included in the orgobjects which they will affect when executed. All planned activities included in the given orgobject compose the immediate plan of the process evolution. When executed, a planned activity changes the orgobject to which it belongs. This change may include adding new planned activities and deleting the old ones thus helping the user to modify the process plan.

• Orgbjects provide a perfect insight into the process’ state of affairs. The information stored in the objects is of great help to the management staff as it permits to evaluate the state of any process quickly (without going into t history).
• Histories make it easy to trace all the activities completed within the given process, which helps to draw up plans for complicated cases. They are also a very important source of data for all kinds of process evaluation and statistical analysis.
• The project staff becomes goal- and process conscious as it is easy for any person to overview all the activities (one’s own and those of others) completed in the process he/she is involved in. The history of an old orgobject is useful for "learning by example", which may help to find solutions in difficult cases.
• Distributed planning is a very powerful tool for coordinating the work which makes unnecessary the intensive communication among the workers engaged in the same processes
• Since all the information on the past activities is being stored, the management is in a better position to resolve various kinds of conflicts.

When applying our model to a new application domain, the following tasks should be completed:

• orgobjects to represent the production processes should be designed
• simple activities that moves the process to its final goal should be identified
• rules for chaining these activities should be figured out and implemented in additional actions behind each of the activities identified

Though we started our work with the idea to create a secretary for a programmer, we never had a chance to try our model for this domain so far. However, object-oriented software is already structured in terms of objects. Thus the most elementary business process could be the one that concern the full life-cycle of a software object. An orgobject to represent this process would include all the components of the software object, e.g.: source file, include file, documentation file, etc., together with immediate activities planned: compile, adjust documentation, include in the next test release, etc.

The advantage of the software production with respect to our model is that most of the routine operations completed in the frame of this process are executed in the computer. This makes it possible to achieve the maximum automation of the process in the support system.

1. Bider,I. ObjectDriver - a Method for Analysis, Design and Implementation of Interactive Applications. In Data Base Management. Auerbach RIA Group, February 1997.
2. Bider,I. Developing Tool Support for Process Oriented Management. In Data Base Management. Auerbach, RIA Group, February 1997.