Likely 80% of the value of the Praxis method can be achieved without statistically provable languages.
Industry standard UML meets most of the requirements for sound formal notation.
Tooling for UML provides substantial validation of deliverables.
Iterative methods, RUP being my preference, meet the requirement for carrying out and validating the deliverables of small steps. (Note that CMMI still focusses on repeating the process, not validating the deliverables as the requirement.)
Any well structured method with low redundancy meets the requirement to say things only once. Most methods aren't well structured. RUP is pretty good, and can be made solid in this respect with a little attention.
From reasonably well done UML, test cases can be derived systematically that provide substantial coverage. Architects and designers can still create unthinkably complex solutions, but nothing in the article Praxis writes indicates that they have solved that problem in a technical way, but rather in a procedural way. Arguably, the Simplicity rule of XP comes closest to this Praxis practice, but I prefer the second half of the rule (don't add functionality before it is scheduled) to the first (do the simplest thing that could possibly work).
Any decent iterative method deals with the hard things first. RUP explicitly does in the Elaboration phase, for example, while XP has the less well articulated architectural spike and spike processes.
Having run XP and RUP projects and coached organizations around North America on the effective use of RUP, I can say that high developer productivity with low defects is eminently achievable, although not quite to the standard that Praxis achieves. A friend and CTO runs a variant of RUP for his shop and it's rare that defects are found by customers.
Likely 80% of the value of the Praxis method can be achieved without statistically provable languages.
Industry standard UML meets most of the requirements for sound formal notation.
Tooling for UML provides substantial validation of deliverables.
Iterative methods, RUP being my preference, meet the requirement for carrying out and validating the deliverables of small steps. (Note that CMMI still focusses on repeating the process, not validating the deliverables as the requirement.)
Any well structured method with low redundancy meets the requirement to say things only once. Most methods aren't well structured. RUP is pretty good, and can be made solid in this respect with a little attention.
From reasonably well done UML, test cases can be derived systematically that provide substantial coverage. Architects and designers can still create unthinkably complex solutions, but nothing in the article Praxis writes indicates that they have solved that problem in a technical way, but rather in a procedural way. Arguably, the Simplicity rule of XP comes closest to this Praxis practice, but I prefer the second half of the rule (don't add functionality before it is scheduled) to the first (do the simplest thing that could possibly work).
Any decent iterative method deals with the hard things first. RUP explicitly does in the Elaboration phase, for example, while XP has the less well articulated architectural spike and spike processes.
Having run XP and RUP projects and coached organizations around North America on the effective use of RUP, I can say that high developer productivity with low defects is eminently achievable, although not quite to the standard that Praxis achieves. A friend and CTO runs a variant of RUP for his shop and it's rare that defects are found by customers.
Cheers,
Mike Barnard