Modifying complex software is exceedingly difficult, time-consuming and hence costly. Especially if the original software is poorly structured/documented and/or the original developers have moved on to other projects. In the latter case someone new (probably less experienced) has to come in and get to grips with the system, before they can develop the new version (don't know if this applies to CAF).
There is the ever present risk of regression errors, where a change to one software function inadvertently breaks some completely different, and maybe more important, functionality. To mitigate the risk a rigorous change control process should be followed, starting with the top level requirements and flowing down through the software structure, rather than just jumping in and patching the code. Then extensive and time consuming regression testing is required, to demonstrate that none of the other functions of the system are adversely affected by the change.
Even with best practice, errors can slip through. Look how often Windows updates introduce new bugs, despite all the resources Microsoft has at its disposal. And look how long the Boeing 737 Max has already been grounded. The old adage "more haste less speed" was never more true than in software updates. Non-engineers often say "why is it taking so long? It's 'only' software." But hardware modifications are often quicker to develop and roll out, because the physical interactions of one widget with others are much easier to analyse and predict than those between software modules.
In the case of the 195/331 TMS and PIS, I expect CAF will be trying to minimise the number of software updates by grouping together collections of bug fixes into each new software version. Then this will have a limited initial release on a few units, for in service validation, before rollout across the fleet. A slow process!
