COCOMO theoretical point of view
COCOMO is a model based on a statistical correlation between size of the software in KLoc and effort. The intermediate model that you seem to have used also takes into account some additional cost drivers in from of estimation adjustment factors.
The COCOMO's estimation principle is that the product is an independent software that forms a whole. So if you can split your code into 2x50 Kloc, and each part could run independently of the other, your calculation would be correct.
COCOMO and the reality
However, this seems an ideal and improbable case:
- if both parts are somewhat interdependent, the EAF would increase because of the added complexity in each part (due to the interdependence with the other one), and the increased reliability requirement (since the other part depends on it). If this would bring the EAF of the split products to, say 1.3 instead of 1, the overall effort would be of 795. So higher than the initial 100KLoc estimate
- if both parts are more interdependent or even highly interdependent, the KLoc size of the whole will certainly not be 100KLoc = 2*50KLoc anymore, because of the extra coordination, synchronisation and communication effort. Moroever the EAF would increase as well, inter alia because of additional synchronisation/performance constraints on the top of complexity.
In conclusion, your ideal case is very hypothetic, and certainly far from reality.
Intuitively, we can feel that this less ideal figure is certainly more realistic: spliting a big product in two will require more efforts because of the additional interactions to be handled. Managing code reuse between the two parts also brings extra challenges as it can no longer be modified in isolation.
You must be aware that:
- COCOMO figures are based on a relatively small number of big projects (older sources state 70-80 such projects, more recent work mentions figures above 300);
- COCMO assumes that all the requirements are known in advance, so that there is no discovery overhead.
- COCOMO is not really adapted to cope with incremental development methods
- Finally KLOC is no longer a meaningful and consistent measure when it comes to derive the effort from it: we all can write long code with lots of repetitive part whereas a better design could result in less lines of code but would require a higher effort.