[QUOTE=xtisme]
The government awards the contract and a contracting officer oversee’s the project (perhaps by assigning some GS as a project manager, perhaps assigning additional personnel…it varies) to ensure that goals are met and that the project is completed to satisfaction. An evaluation is done of the final product to make sure it meets the original RFP as well as any changes requested by the government during the project (I’m glossing over a bunch here to save space as you probably realize). Once the government signs off then they have accepted the product as meeting their requirements. [.QUOTE]
Correct, as far as it goes, but there is still recourse if the end product is so horrible that no corrections can be made. Usually that is not the case. We’re not talking about minor bugs due to requirements creep or unforeseen gotchas that always crop up, we’re talking about the really horrible stuff, like if it doesn’t work at all.
They’d have a rough time of it. The defects would have to be so bad, that there is no other recourse. If the flaws are in the government spec or RFP, and the top documents that the government wrote or signed off on, it would be some government guy who’d be in deep shit. The saying “be careful what you ask for” still holds. If the company (Diebold) did what they were told to do, then they are not at fault. Software is complex. You can not account for every “what if” that may (or not) happen. You can only deal with the known quantities. There are numerous versions of the software before you get the final version, and each is a snapshot of the requirements as you saw them at the time. That is why the certification of compliance always includes the words “to our knowledge”. No company would sign off a cert that says the software is completely and absolutely perfect. They will sign off that it meets the Understood requirements and will function - but not that it is perfect.
Well, if the government did it themselves, they would get a big increase in cost, with no guarantee that the product would be any better, or even equal. They’d have to hire and train programmers, and then manage them. They’d have to design and install the testbeds. It’s much cheaper to go to a company that already has the resources. Also, the software and the hardware are often designed, built and tested concurently. So, neither the software nor the hardware side knows for sure just what the final system will really be until near the end. This generates more requirements creep, as things get firmed up. Bugs found during FCA/PCA and testing get reflected back into the design. Then back to more testing. Back and forth until everyone is happy.
Again, with an oversimplification, if Diebold did what they were told to do in the RFP and performance specs, they are blameless. “Be careful what you ask for, you might get it”.