In my previous post on analytics and retrofitting measurability, I talked about the first two phases of getting to grips with metrics and analytics in an existing system. I divvied it up so because otherwise it would have been too long to read. Continue reading
Measurability operates over an incredible range. It’s the ‘gravity’ of the metrics universe. Why do I say so? Because it is a quality attribute that manifests itself at business-level decision-making, without being constrained to that realm in the least.
Measurability permeates everything; it goes past the business level, down through engineering and development activities, and even further still, to actual infrastructure.
And what exactly is measurability, you might ask? It is the ability to quantify the behaviour of a system along with its most important outputs or results. This ‘quantitative’ aspect suggests the use of statistics and tabular data, the gathering of which exposes a well-known-yet-oft-poorly-solved problem: with a probability that is almost certainly ONE, your system has NOT been designed to fess up the numbers you need. Continue reading
As discussed earlier, localisation generally depends on skinability. Often too, localisation will require a deeper level of adaptive behaviour: This is the role of customisation. In fact, localistion projects are often hybrids (blended localisation *and* customisation projects).
In what follows, remember that the topic is about retroffitting the adaptations needed to support localisation. In brand new projects, a lot of these issues can be planned for and dealt with differently. In a retroactive scenario however, these are some of the issues that come up during customisation: Continue reading
If you’ve read part one of this topic, you’re ready to look at the two main types of presentation-level adaption : re-skinning and localisation. The end-result for this phase of activity is fairly simple:
1) To arrive at a new version of the application that looks like, and behaves like the old one, but with all presentation-level assets externalised, and…
2) The application accomodates a new set of external assets flawlessly, when those external assets are changed.
Once this is achieved, the possibility of localisation now exists.
Continue reading
Sooner or later, a modern software app will need to spread its wings and go global, making itself available everywhere – or failing that, at least available in lots of different countries. Or failing that, available to lots of different regions. Or clients. No matter what the type of spread is, the inevitability of catering to different sets of end-users means that software needs to be built with some kind of customisation in mind right from the start.
But what if you you’re retrofitting such adaptive behaviour to an existing application? Before you get bogged down in the quagmire of international language codes and glyphs from utterly alien fonts, understand the larger picture (adaptation) that your efforts need to be a part of… Continue reading
How might control systems theory, at the heart of cybernetics, inform the way we develop software? Well, cybernetics can be brought into play at 3 different levels: