Or do like what the dutch railways are doing: run the old and new systems in parallel on real inputs and check if the outputs match. Then proceed to only use the output for the old system until you're reallyreally sure there's no bugs.
I'd imagine so, I just knew about the dutch railways for certain. IIRC they are doing a mechanized translation from COBOL to C++. The idea being to first test that exhaustively, and then slowly manually translate the COBOL-y-C++ to more idiomatic C++.
>they are doing a mechanized translation from COBOL to C++.
That sounds interesting; do you mean that they are converting the current working system written in COBOL to C++ using a transpiler? Do you have any links to more information on this?
I do mean that. I can't find it now, but I read it some years ago in a news article. The project was slated to run for a loooong time so I've assumed it's still going on.
No problem, a search for "COBOL to C++ transpiler" actually brings up a couple of companies which is interesting. But how do they verify the resultant output? Mere testing cannot be enough for critical systems software.
Yes/no. The (formal) reason SFMTA went with the Thales/Alcatel system was the ability to overlay the new setup over the old. None of the other bidders met that requirement. Depending on the hardware side of things it's entirely possible you couldn't/wouldn't want to run the two systems in tandem with BART.
That said BART wanted to run AATCS trials on the mainline in Oakland. No clue if they actually managed to do that before GE pulled the plug on the project.
Running trains is rather expensive and generally not something you'd do to test software. Especially given that in this case a software crash can result in a train crash.
