The more detailed versions of this essential idea do, approximately, describe the process of removing faults from a continuing sequence of releases of a software product. Bev Littlewood has a nice survey of these, together with some practical suggestions, in a recent IEEE Trans. The models have this feature because this seems theoretically sound and the actual data is not inconsistent with this class of models. Singpurwalla and Crow have a nice paper suggesting that faults are evidenced as failures with a periodicity sufficiently good to make interesting Fourier analysis of the failure data. We may take this as suggesting that some failures imply more failures at regular times in the future.
Good designs have few faults and evidence few failures.
In software this means few releases are necessary to correct faults. However, many software products interact primarily with that most flexible of io devices, people, People quickly adjust to the ideosyncracies and failures of the software they use. Good software designs start with a low initial number of faults. Good design practices seem to lead to better software. But one simply requires more data than currently exists to say much definite about the advantages of Ada vs. a more traditional practice.