|
|
|
|
|
|
by trcarney
1657 days ago
|
|
|
The biggest issue with software written under government contract, firm fixed price contracts. The way these are handled is not a good way to handle software. The winning contractor has a set of requirements for the software they have to deliver. If the customer wants to change anything, there has to be a bidding process and either a new contract or an add-on contract is awarded. This makes the customer very hesitant the make changes to the requirements even in the face of user feedback. There is also no way to get user feedback until after the final software is delivered. It would have made life so much easier when I was a contractor if we could have had a group of users come in and see the software and make recommendations for the UI. |
|
|
That's what seems so very puzzling in these stories. These shortcomings in the delivered software appear more like insufficiently tested requirements (of course, the execution could be the sole reason too).
I'm not sure if contractors are needed in order to test the requirements against the actual use-cases _before_ even initiating a bidding process for developing any systems/software.
After all the force probably wants to describe what's needed. Someone has to make sure the desired new capabilities align with actual existing and desired workflows.
Perhaps, in this navsystem case, the ability to efficiently analyse/visualise the region's depth profile could have been stated in concrete use-case form, including the response times, scaling etc. This would then become the basis to test at the acceptance stage.