Halfwit like Sobraj
New member
...tools correct? 1/Automated tools can assist in development. For example if a monkey at a typewriter is attempting to "author" a document, an automated tool might be able to recognize that a valid word, or sentence, or sonnet even, or "line of code", has been "authored".
2/So too if an automated tool is attempting to write code, for example to "fix" some software. Another automated tool may be able to recognize that the proposed "fix" will work.
3/A system, such as Oberon submarine does/did, may have a R/R (record/reproduce) unit. In the case of Oberon, the program was also stored on the R/R unit. So it was possible that the program could be accidentally modified - this could happen a wrong change was made to the program, so that the R/R unit could modify the program. An automated tool might be warranted, to check that the program code in particular the R/R portion of it, is as originally agreed.
4/If a change is made to a program so that ranges of 0 thru 360 degrees are converted to 0 thru 359 (as apocryphically happened to Collins software), existence of an automated tool is warranted that would recognize the change was wrong and change the range back to 0 thru 360.
5/Apocryphally, for Oberon system, a supposed "release 105" contained an incorrect change. Not good. Much worse is that no automated tools were made available to recognize that the change was wrong, and change the system back to what worked. (Ideally the system would also hit Kilkenny or Kilpatrick or whoever fouled up the change, over the head with a styrofoam pointer or one of those dummy weapons they sell at the Easter Show)
6/For Oberon and also Collins, automated tool would be warranted to inject a suite of EH84 test case data blocks into the SCTT LBTS simulator and check that the simualtor handles the synthetic
weapon data blocks and "hits" the synthetic target.
Ideally there'd be automated tools to check that missile path patterns "look" correct and PACQ parameters look correct.
Without such tools you only find out years, decades, later that your key man "Kilpatrick" or was it "Kilkenny" or was it "Pee-cubed", you've forgotten their names now, fell down on the job.
7/Automated tools might be run against each other, improving each other.
8/Your system under test might possess 26 modules, and you might want at a minimum 26 automated tools. Because of overlap, quality IMPROVES with change, as opposed to falling off.
2/So too if an automated tool is attempting to write code, for example to "fix" some software. Another automated tool may be able to recognize that the proposed "fix" will work.
3/A system, such as Oberon submarine does/did, may have a R/R (record/reproduce) unit. In the case of Oberon, the program was also stored on the R/R unit. So it was possible that the program could be accidentally modified - this could happen a wrong change was made to the program, so that the R/R unit could modify the program. An automated tool might be warranted, to check that the program code in particular the R/R portion of it, is as originally agreed.
4/If a change is made to a program so that ranges of 0 thru 360 degrees are converted to 0 thru 359 (as apocryphically happened to Collins software), existence of an automated tool is warranted that would recognize the change was wrong and change the range back to 0 thru 360.
5/Apocryphally, for Oberon system, a supposed "release 105" contained an incorrect change. Not good. Much worse is that no automated tools were made available to recognize that the change was wrong, and change the system back to what worked. (Ideally the system would also hit Kilkenny or Kilpatrick or whoever fouled up the change, over the head with a styrofoam pointer or one of those dummy weapons they sell at the Easter Show)
6/For Oberon and also Collins, automated tool would be warranted to inject a suite of EH84 test case data blocks into the SCTT LBTS simulator and check that the simualtor handles the synthetic
weapon data blocks and "hits" the synthetic target.
Ideally there'd be automated tools to check that missile path patterns "look" correct and PACQ parameters look correct.
Without such tools you only find out years, decades, later that your key man "Kilpatrick" or was it "Kilkenny" or was it "Pee-cubed", you've forgotten their names now, fell down on the job.
7/Automated tools might be run against each other, improving each other.
8/Your system under test might possess 26 modules, and you might want at a minimum 26 automated tools. Because of overlap, quality IMPROVES with change, as opposed to falling off.