ASML – Optimizing software release policy #SWI2006

ASML is a company located in Veldhoven that builds machines for manufacturers
of computer chips. The software of these machines ASML sells now consists of one
large package, a so called monolith. Their current policy is to release a new version
of this entire monolith approximately every nine months.
This monolithic approach has a few disadvantages. Suppose a client asks for
a new functionality in the software. ASML will develop, implement and test this
new functionality and add it to the new version of their monolith. This means that
the client has to wait a few months before it can install this new version of the
entire package, containing the requested functionality, but also a lot of changes they
haven’t asked for.
Therefore ASML is considering other approaches for their release method. An
option is to split their software into smaller pieces (we will call these pieces functional
units or FU’s). The implementation of a requested functionality will only affect a
few FU’s. Once implemented and tested, the client can install a new version of
the affected FU’s without changing the other FU’s. This means that there will
be a broad range of configurations ”in the field” (on the different machines of the
clients). Of course ASML only has a limited number of programmers to maintain,
and a limited number of machines to test the software.
The main question in this approach is: In how many FU’s can ASML split their
monolith so that they can still manage all versions of these FU’s?
Assume the monolith will be split up in k functional units: FU1, FU2, . . . FUk.
Each unit FUi can exist in different consecutive versions, for simplicity numbered
by 1, 2, . . . , ni. Version j of FUi will be denoted by FUj i . All the FU’s communicate
with each other through interfaces. These interfaces remain unchanged when one
or more FU’s get a new version. The configuration where FU1 has version j1, FU2
has version j2, and so on, will be denoted by (FUj1 1 , FUj2 2 , . . . , FUjk k ).
Suppose that for each unit a corresponding probability distribution is given that
models the probability that a client orders a new version in a certain time interval.
Releasing a new version of a FU brings a certain amount of work that, globally,
can be divided into three parts: implementation, testing and maintenance (=bug
fixes, …). It is reasonable to assume that the work needed for the implementation
and maintenance of a new version of an FU is independent of the other FU’s. The
testing on the other hand depends heavily on the number of versions of the other
FU’s, because a FU version (ideally) should be tested in all combinations of all
versions of the other FU’s. In practice ASML will only support (and thus only test
a new FUi version in) the configurations with one of the lj last versions of FUj for
j 6= i.
The practical limitations inside ASML (number of programmers, machines, …)
give an upper bound to the amount of work ASML can handle. The question thus
becomes: Find the maximal k and l1, . . . , lk such that the total work needed stays
below this upper bound”

DOWNLOAD & PRINT

Download scientific

Download

Print this page

Print

ASML – Optimizing software release policy