M882 – Section 6
From a management perspective this is true. From a developer perspective this is largely false. The developer will know that there are often times when you can develop system updates, new architectures, etc.. at a speed that will largely satisfy most people. The problem arises with the users/market. The market will not be ready for the latest and greatest a company has to offer in the beginning, and frequently this will continue until a certain software maturity has been reached. The cost and risk factors also play large roles here. Spending, when weighed up, contrasted with all of the relevant factors and so on, will usually fall back to “If it ain’t broke….”. It frequently just isn’t cost/risk effective to update to the cutting edge, when the investment for the dull hammer has already been made and still works just fine.
2. Unless work is applied to counteract the appearance of legacy symptoms, any business-critical software is likely to become a legacy system sooner or later
Basically this statement boils down to two items: it can be maintained, or it can be evolved. Maintenance will involve fixing little bits and pieces, keeping things ticking over. Evolution will take the existing processes, tacit or otherwise, and create a newer, leaner, meaner and keener beast out of it. Its the football equivalent of keeping a team chugging along with the same players because they get along ok, and nothings reeeeeeally broken… whereas evolving the tem with new players, new trining methods, new coach, etc… will make it a world class competitor.Wrapping legacy systems, acquiring FOSS, modular development; all of these things are good and will, but its down to corporate mentality as well.. willingness to change and evolve will be core here..
3. Wrapping legacy software and it’s integration with newer software should be considered when replacement is too risky or too expensive
I’d agree and disagree here. Yes, wrapping should be considered if absolutely necessary, but NOT at the risk of compromising the system – from my point of view this would mean not wrapping if there is a reasonable justification for re-engineering the system/process/whatever, extracting all of the lessons learned from the current implementation. There should be some sort of bias in the judging system towards a new implementation, obviously backward compatible with the old junk, but this should nearly always be the best option. Preserving the old stuff for the sake of it or for penny pinching, etc, is just wrong.
4. In COTS-based projects the requirements are limited, shaped and conditioned to what the COTS vendors can offer
5. Component-based development provides value through cost efficiencies and trhough the emergent properties of the integrated applications
6. There are still limitations to the wide use of components, including issues of reliability, risk, trust and lack of support for the future evolution of the component
7. Successful open source acquisition and deployment requires tapping into other diverse sources for support and this requires a more diverse approach than when depending on a single supplier
8. Acquisition of open source software can be primarily motivated by a cost reduction strategy and not by the availability of the source code
9. Outsourcing beefits from a number of economic and technical efficiencies. However, this option may lead to a client’s loss of control over the software
10. Advances in methods and process capability of software organisations expand the types of software activities that can offshored
11. Instead of owning or licensing the software to run on your machines, you can rent time using it at some service provider
12. Software acquisition as a service (e.g. web services) requires adequate resolution of issues of responsibility, trust, risk and security
13. Software provision does not end with the selection of a source and the acquisition of the software and its documentation
14. Software acqusition consequences go beyond the immediate decision: they may have far-reaching impact
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=c5466d4e-1599-4282-a00b-299a2f8fb08d)

