It is a very interesting book. I am reading it mainly for the UML modeling aspects, as it came well-recommended.
I like it so far, but I'm not convinced about this whole "don't worry about the requirements now, we'll sort them out in the end" attitude that the UP (and certainly eXtreme Programming) tend to favour.
I am certainly all for agile approaches, and using processes (and designs!) that are flexible enough to cope with change, at all phases of the project.
But I think I'm missing something about UP... In the inception phase, you don't fully specify requirements. But you don't in the elaboration phases either - or rather, you incrementally define use cases and gather requirements and do your design.
Now I certainly like aspects of the old spiral approach (another older name for the UP's incremental model) but what I don't get is how you can size a project, and thus come up with realistic budgets and milestones or deadlines, without having either a domain model or requirements anywhere close to the start of the project? Do you only agree on a contract half way through the development or something? What am I missing here? Or are the PMs so good that they can size these projects without this information (that I would call kinda critical)?
Everyone should use Waterfall once, if only to know why it shouldn't be used. One thing I like about FDD is that you have a good handle on the size of the project (and thus can scope it, plan for risk, etc etc) at a fairly early stage, before too much is committed.
So how do you size a project with UP? Or XP for that matter... Guess I'll have to read another book for that...
Spiral Approach and UP Incremental model
I've not read the Larman book, so I'm checking assumptions here. Does the book state that UPs incremental model is the same as the Spiral model? I guess there's two assumptions I need to check here. Also, what the "Spiral Model" is that is being referred to?
When I read "Spiral Model" or "Spiral Approach" I immediately think of Barry Boehm's famous Spiral Development Model. In that model it is risk analysis that determines if you go around the spiral again (do another phase). I've not seen that in RUP.
UP and Spirals
It's not the same as Boehm's Spiral model then. I think it's more like the Spiral model discussed in Pressman's SWEng book (don't have it here to get a page reference), where each cycle is a complete iteration of Requirements-Design-Build-Test.
So the UP (as I currently understand it) is incremental, in that it delivers a subset of all features at the end of each cycle, and iterative in that it goes through a whole dev cycle each time through. I guess these two add up to Spiral.
Requirements and modeling are treated in each cycle, and the idea is that the requirements (and thus the design and then code) will converge on the desired baseline (hopefully not asymptotically!).
Incidentally, something I quite like about the book: at the end of each chapter, ther e is a summary section that says "You know you don't understand Boiling Water when...", followed by some common misconceptions, like:
1. You put the match into the pot to try to heat up the water.
RUP and requirements
Gavin
I started to write what turned out to be a long ramble on development processes, so I'll start again and try and give you a simple answer.
Most software devlopment, at least until recently, was done in-house with more-or-less fixed resources. Managers had the luxury of being able to vary both deliverables and delivery date and IMO RUP reflects this. RUP tries to deliver the most in the fastest time (I'm being charitable here). I.e. it is not oriented towards guaranteeing either deliverables or delivery dates. It does this by allowing deliverables and dates to vary throughout a development.
If you are bidding as an outside vendor, you clearly want to fix all three primary variables - deliverables, resources and delivery dates. To cut a long story short this is not possible without complete knowledge of deliverables (whether it is possible with complete knowledge is a separate topic).
So you either fix time and vary deliverables through a project as RAD (XP is a RAD process in my view) does, or you try and fix deliverables and give yourself flexibility in time as BDUF does. FDD tries to plot a middle course by learning enough up front about the deliverables to best-guess a fixed delivery date while retaining some flexibility in both deliverables and delivery dates. Jeff highlighted this in the last newsletter.
Phil