1. Effort Estimation for Changing Requirements
Wim Codenie, Wilfried Verachtert
OO Partners
Patrick Steyaert
Vrije Universiteit Brussel

2. Overview PSI: Framework development in practice Maxims Challenges
Reuse Contracts

3. 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.

4. 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

5. 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)

6. 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.

7. 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

8. 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 ?

9. 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

10. ? 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 ?

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

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

13. 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

14. 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)

15. 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

16. 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

17. 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).

18. 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

19. 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 !