Effort Estimation for Changing Requirements Wim Codenie, Wilfried Verachtert OO Partners Patrick Steyaert Vrije Universiteit Brussel Email: wim@oopartners.com, wilfried@oopartners.com, prsteyae@vnet3.vub.ac.be

Overview PSI: Framework development in practice Maxims Challenges Reuse Contracts

The Original PSI Application Original application developed for VTM (Flemish broadcast company) Groupware application for television broadcast companies Implemented in VisualWorks/Smalltalk Designed and implemented by a small team (< 7) NOTES To start, let us take a look at the original PSI application Originally the application was custom develop for a single television station. In fact the application was the result of an automatisation project at VTM, a Flemish broadcast company (the project was started in 1993). The goal was to create a groupware application to support the entire planning process of television programs, ranging from seasonal planning to daily planning. The application was developed in VisualWorks/Smalltalk by a rather small team. In fact, the development team never exceeded 6 members.

PSI Workflow Consistency checking Planning Contract & Program - 6 months External Applications Accounting Airtime sales ... Tape This diagram shows the typical workflow of the PSI application. The planning process starts a few months before the day of transmission by the creation a seasonal planning which is a rough template of the planning for the season (e.g. Each thursday evening a film is planned from eight to ten). Gradually the planning is refined by the departments of the television station. For example, The planning department is responsible for the daily planning. If they decide to plan a particular film they enter the information in the application. As a result the Tape department is notified that they must order the tape for the program. As soon as the tape arrives, they enter the tape information in the PSI application. As a consequence, the planning department is notified of the exact duration of the program. Important about the application is that their is no imposed order on the workflow. Of course, a few days before the transmission, a consistency check can be performed to check if all details are filled in. For the actual transmission, PSI is able to download program information to the specific transmission hardware. After the transmission, information from the hardware can be imported in the PSI environment and forwarded to other applications (for example accountant software). This workflow diagram indicates that PSI is a complex application that allows the different departments of a television station to work closely together on the planning of television programs. The application is used by different kinds of end-users (planners, tape reviewers, ...). Although all these users work on the same data, each category of users has its own specific application taylored to the specific needs of theqt user category. The application also incorporates the necessary security facilities (roles, passwords). - 1 day Broadcast day Consistency checking + 1 day

Evolution of PSI Need for a PSI framework ! ... Danish Television Station (TV2) Need for a PSI framework ! ... VTM Even during the installation of the original PSI application at VTM, other broadcast stations showed their interest in the product. However, installing the software at another television station does not mean merely duplicating it. Although the bulk of the application can be reused,differences exist between the planning process of broadcast companies.. So, to install the software at TV2, a Danish TV station, we started to adapt a copy of the original application to the specific needs of TV2. However, it soon became apparent that this was not the most efficient way of working. After a while there was no relation between the two applications and the architectures started to drift apart. This resulted in severe maintenance problems for our small development team. In particular reuse was difficult and harder to spot. For example we had problems porting features (added after the split) from the TV2 application back to the VTM application. What was needed was the definition of a common core (or domain specific framework) that contains all the common behavior of the planning applications. Each application would be a customisation of that framework. Since all the customisations are based on the same architecture maintenance problems could be reduced. Belgian Television Station (RTBF)

Challenges for Effort Estimation “Analysis of Changes” instead of “Analysis from Scratch” reuse as early as possible no over-featuring Iterative approach no large upfront investments ! acquire domain knowledge We observe two important challenges for effort estimation in our development process To support our particular view on analysis. Instead of performing an analysis from scratch, we perform an “Analysis of Changes”. In order words, we try to introduce reuse as soon as possible in the development process. In our context, analysis of changes is important , because we want to give our customers the feeling that the application they receive is custom-developed to their needs, free from useless features. A second important aspect of our development process is iterative design. Since OO Partners is a small company we cannot affort to make large upfront investments in building the right framework without customising it to make money. Also we are convinced that it is not possible to build a good framework without customising it in order to acquire the necessary domain knowledge.

Analysis of Changes rather informal process product as advanced proto informal reuse documentation (cookbooks) So, how is an analysis performed at OO Partners. An application engineer performs the Changes Analysis (delta analysis) at the customer’s site. During this analysis the framework is used as an advanced prototype to capture the specific requirements of the customer (differences in workflow, additional information, etc.). In particular, the differences with the protype are written down (using an informal notation). After the analysis, the application engineer returns to OO Partners. To make an effort estimation, the application engineer discusses the modifications with the framework engineers. For a number of standard situations informal reuse documentation in the form of cookbooks exists, but this is not sufficient. Direct involvment of the framework engineers is needed to make a realistic effort estimation. The challenge is to reduce the involvement of the framework engineers as much as possible by providing a better documentation about how the framework can be reused. (reflection of the mental processes that take place in the heads of the framework designers) Customer Application Engineer Framework Engineer

Iteration:Propagation of Changes Framework Framework Refinement (Iteration) Customisation Framework PSI NOTES Let’s look at an example off the typical development starting from the framework. In the most ideal situation, building an application boils down to filling in the hooks of the framework. This process is called customisation of the framework. However, this presumes that the framework is already mature enough. In practice it is rarely the case that an application can be built by merely filling in hooks. Often the framework has to be redesigned (albeit sometimes slightly).This is typical for the iterative development process. Due to limited resources we cannot afford to make a large initial investment in building the right framework. Instead the framework is stabilised during each customisation. This makes maintaining and upgrading of the software difficult.( Emphasis on consistency between the versions). This is an example that reuse does not necessarily corresponds to making large upfront investments. For example: Tape numbers. Originally, Tapes and numbers were in the same class: namely Tapes. In a later stage this was refactored into two separate class hierarchies QUESTIONS ?

Need for ... Reuse Contract Asset Provider Asset Reuser declares how an asset can be reused (formally) declares how an asset is reused (formally) rules for change propagation So asset providers and asset reusers need to work together so that the asset reuser can profit from enhancements made to the assets he/she reuses and the asset provider can profit from the knowledge and improvements asset reusers make to assets. They need a contract to do so. Let’s have a look at the problems first: black-box, or generic components: adaptation in a predefined way white-box: everithing can be adapted/changed, no indication on what is adapted/changed So, clearly, the asset provider must expose some of the internal workings, but only part of it only those parts that he can commit to that if they change, reusers are notified. It’s an interface, but one that not only hides the internal workings, but also one that can change. Asset reusers need to declare how the rely on this interface, so that if it changes we know which reusers, and which part of the reusers of will need attention. Reuse Contract

? Example: How to Reuse What to override ? Set add(Element) Class Set method add (e:Element) = 0 method addAll(aSet:Set) = begin for e in aSet do self.add(e) end End Set add(Element) addAll(Set) CountingSet Counts all elements added to the set explain problem notice that we need to look at the implementation to detect this problem add(Element) addAll(Set) ? What to override ?

Documenting the Design documenting (part of) the specialisation interface Set add(Element) addAll(Set) Set abstract add(Element) addAll(Set) {add} invokes add

! Effort Estimation Set add(Element) addAll(Set) {add} CountingSet --- effort estimate # subclassing set # concretisation of add

Propagation of Changes Set OptimizedSet add(Element) add(Element) addAll(Set) addAll(Set) CountingSet CountingSet count+1 count+1 add(Element) add(Element) explain problem notice that we need to look at the implementation to detect this problem addAll(Set) addAll(Set) Not all elements are counted

Documenting the Reuse Set Set add(Element) documenting different kinds of reuse add(Element) addAll(Set) addAll(Set) {add} Concretisation add CountingSet CountingSet add(Element) add(Element)

Different Kinds of Reuse Design “preserving” Concretisation: filling in the “hotspots” Refinement: refining the overall design Extension: adding new behaviour Design “breaching” Coarsening: performance optimisation Abstraction: generalisation Cancellation: fixes

Effort Estimation Coarsening Set OptimizedSet add(Element) addAll(Set) {-add} Set OptimizedSet add(Element) add(Element) addAll(Set) {add} addAll(Set) {} Concretisation add Concretisation add CountingSet CountingSet We can detect the inconsistent method problem with reuse contracts what are the advantages ? add(Element) add(Element) --- effort estimate # addAll needs to be overriden also

Rules for Detecting Conflicts Formal rules … …automated checking ! inconsistentMethods(Aexch,A,Mapp, I) :- affectedMethods(Affected,Mapp), client(CAexch,Aexch), findAllSet(inconsistency(N,M), (member(N,CAexch), member(M,Affected), spec(SpecAN,A,N), member(M,SpecAN), transSpecClause(SpecAexchN,Aexch,N), not member(M,SpecAexchN)), I).

Effort Estimation with Reuse Contracts Asset Provider Asset Reuser Set Concretisation add add(Element) addAll(Set) {add} Allows estimating the effort for reuse Allows estimating the effort for change propagation Scaling Up: Integration with other effort estimation techniques Inter-object Reuse Contracts

Conclusion Framework development characteristics analysis of changes (use advanced prototype) iterative (limit upfront investment) OOA/OOD notations today do not provide sufficient information for estimating the effort for : reusing an asset change propagation Reuse Contracts are a solution have a broader scope !