• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (25)

21 DHBernstein commented Permalink

re " I highly suspect that the failure would have been more "epic" had the team chosen to proceed with deploying into production." <div>&nbsp;</div> Nowhere did I suggest that the team should have proceeded to production. I suggested that they should have been aware of the potential for change in their business environment. The sub-prime mortgage meltdown did not occur overnight; there were plenty of warnings beforehand. The fact that others disregarded these warnings does not diminish the team's responsibility for having done so. <div>&nbsp;</div> Re "you're interpreting the Inception phase to be much heavier than either Mark nor I would", I cited specific guidance regarding Inception's objectives from "The Rational Unified Process, an Introduction" which you've failed to address, resorting to hand-waving once again. My sense is that you are significantly weakening RUP, to the detriment of those who follow your guidance. <div>&nbsp;</div> My view of RUP is not "interpretation"; I lead Rational's Product Group from 1981 to 2003, when the principles underlying RUP were identified and ultimately assembled to form a process framework.

22 ScottAmbler commented Permalink

DH, you appear to be quoting from the first edition of RUP: An Introduction, published in 1999. May I be so bold as to suggest that perhaps we've learned something about IT risks since then? Anyway, nowhere in the book do I see a statement indicating that "One cannot claim to have identified a system's critical use cases until all significant requirements risk has been identified and eliminated" as you indicate, although please correct me if I'm wrong. Otherwise, then you are in fact sharing your interpretation with us. When you stop and think about it for a moment, although you might be able to claim that you should identify all risks (or at least do your best to do so) that you're very likely not going to eliminate them all -- an important concept in risk management is that some risks you choose to accept (which you may identify contingency strategies for), some you choose to reduce the impact of (but not eliminate), and some you choose to eliminate. <div>&nbsp;</div> Regardless, this blog posting is about the DAD life cycle, not about the RUP. So, you've managed to take us on a marginally interesting tangent which is clearly out of scope. If this is a topic which you want to discuss, may I suggest that you bring it up on the RMC/RUP/... forum at http://www.ibm.com/developerworks/forums/forum.jspa?forumID=335 and see if anyone else is interested?

23 DHBernstein commented Permalink

Yes, we've learned more about managing risk since 1999, but none of what we've learned would lead anyone to reduce the intensity of effort aimed at identifying and resolving risk early. <div>&nbsp;</div> The statements in my earlier comment taken from "RUP: An Introduction" are quoted. "One cannot claim to have identified a system's critical use cases until all significant requirements risk has been identified and eliminated" was not quoted in that comment; it's obvious that one cannot reliably identify primary scenarios of behavior that will drive the system's functionality and will shape the major design tradeoffs if significant risk remains in the requirements. <div>&nbsp;</div> Establishing a contingency plan is in fact a valid way to resolve a risk. Allowing a significant risk to remain unaddressed with no contingency plan is gambling, not engineering. <div>&nbsp;</div> This thread began with the observation that the DAD lifecycle pays no attention to identifying and resolving risk. The fact that you consider this of "marginal interest" confirms your abandonment of a pillar of modern software engineering: identify and attack risk early.

24 ScottAmbler commented Permalink

Dave. as you can clearly see in the DAD lifecycle diagram milestones are clearly depicted in straightforward, easy-to-understand language. Milestones are typically considered to be part of the overall risk strategy of a process, and it's one of many aspects of risk management in DAD. The Introduction to Disciplined Agile Delivery workshop offering, see http://www-304.ibm.com/jct03001c/services/learning/ites.wss/us/en?pageType=course_description&amp;courseCode=RP251 , where we go into a bit more detail about DAD than I have gone into in this blog posting.

25 DHBernstein commented Permalink

Risk identification and mitigation is either a primary process driver, or it's not. Clearly in DAD, i'ts not.

Add a Comment Add a Comment