Version 4.0 of Extended IPU - one of our main projects at RomSoft, was recently delivered to Sysmex distributors to be used in their future planned installations. This is a
major milestone completion that triggered the inspiration to look closer into how this project has grown, from one iteration to another. In 2011, a team of 11 people at
RomSoft handed in the news that the first version of the Extended IPU (or short EPU) application they were working on was delivered to end users.
For those who don’t know, Extended IPU’s end users are hematology labs using Sysmex Europe’s analyzers. And
while Sysmex Europe boasts the silent design of their machines, something else has been silent over the past years: the Extended IPU team at RomSoft.
To better understand why, we talked to Sebastian Dumitrescu, a true connoisseur of anything relating to Sysmex Projects. After over a month of data scavenging, assembling figures,
reports and pie charts, here’s what we’ve found: Extended EPU is a well-oiled machine, our German engine sort of speak, running from one iteration to another without making a
big fuss. Something like that:
The Extended IPU application is made up of three main components. When comparing the number of lines of code written for each component, the distribution looks like this:
Understanding Extended IPU - The Restaurant Analogy
Although Extended IPU is a complex application designed for hematology labs, we found that anytime you want to keep it simple, you can use “the restaurant analogy”.
The recipes in a restaurant are like blue prints. If applied exactly, the result is perfect meal every time.
In Extended IPU, instead of recipes, we have rules and rule sets. Each rule/rule set is a specific combination of actions that applied to a blood sample leads to the correct result.
Rules and rule sets are produced and maintained in the CONFIGURATION area of the application. So the configuration area is where blue prints are created.
However, in a restaurant, no meal is produced before it is ordered. The same thing happens in hematology labs, where any set of analyses is based on a previously received order
(exceptions allowed on well-established sets of rules).
If in the restaurant the person responsible with taking orders and delivering the meals is the waiter, in Extended EPU, the waiter role is played by DCS – the data communication server.
Finally, the restaurant itself is the ROUTINE area - the set-up where all these actions are executed and seen.
But what happens if the restaurant becomes a franchise? It’s not about the same recipe multiplied thousands of times anymore. The restaurant is multiplied hundreds of times and each
restaurant multiplies the recipes thousands and thousands of times.
This is the level of Extended IPU today. If in 2011, version 1.0 was installed in few labs, in 2016 at version 4.0, EPU is running simultaneously in 600 hematology labs.
Quantity vs. Quality
Over the almost 6 years of work, the Extended IPU team stayed rather constant, with 11 developers and four testers. During this time, the application is not only growing in size and
complexity but every functionality is refined to match the client requests and new market challenges.
We analyzed a few metrics because we were curious to see the evolution of the development process at EPU. With every new version, a new set of new features was added, the number
slightly increasing over time, as seen in the following graph:
22 new features added in the latest version (4.0) may not look like much, but, at a closer look, the smallest feature in the change set required 18 hours of works, while the most
complex one – around 550 hours. For all the 22 features, the EPU team has worked a total of 2689 hours, which makes an average 122 hours/feature.
From the moment EPU was sent in production, it has grown approx. 600.000 lines of code.
But as an application starts to build up, one iteration at a time, your quality assurance (testing) team enters the scene, reminding you that software is not only about quantity, but
also about quality. And from their point of view, their most important task regarding software quality is to identify as many errors as possible, before a change-set gets to the client
(internally reported errors). So we wanted to calculate the number of errors per 1 k (1000) lines of code for each product release, as we wanted to have a better idea where we stand.
As you can see, the report decreased pretty constantly. The ability to improve the errors/k lines of code ratio is not some superpower but a direct effect of gaining more experience
into the project with each iteration.
Last but not least, it is most important that the product quality is measurable at the customer end, so another metric that we want to track on a permanent basis is the number of bugs
reported by the client after each release per 1000 lines of code. Thanks to our Service Tracking And Reporting application (STAR) that was easily done.
The after release bug report rate per 1k lines of code has been constantly lower, from 1.5 to 0.4. Cool, right?
Sebastian Dumitrescu explains the numbers: “As an application becomes more mature, the expertise from previous versions and iterations helps developers and testers become more
and more efficient. Also, having a pretty stable team over the project development lifespan and a dedicated test-team forging more and more automated tests with every release, has
contributed a lot to this evolution.”
A Vertical History
“Still, no matter how much progress is made and how mature an application, some things never change”, Sebastian likes to joke. “One of them is the density of reported bugs growing at a
steep rate before each delivery date.” A reality we tried to illustrate in the following vertical project history:
The facts presented in this article, though sometimes simplified to make them more straightforward are based on actual data. But behind the facts there’s a hardworking, highly
professional team of specialists doing their job every day in a modest, old-school manner. Just like a reliable German engine. And this is kind of exceptional, too.