*   Rational Unified Process
    RUP
    *   created in 1996
    *   iterative, architecture-centric,
        use-case driven 
        and very potentially flexible

    *   architecture-centric?
        ...focus on the architecture from an
	early stage

    *   use-case driven - functionality
        is derived from use cases
	*   use case: relatively simple
	    description of the interactions
	    between the system and its users

        *   to ensure that only features of value
	    to the users are developed

    *   some RUP best practices:
        *   develop software iteratively (risk-driven)
        *   manage requirements
	*   use component-based architectures
        *   visually model software
        *   continuously verify software quality
        *   control changes to software

    *   RUP is a set of GUIDELINES
        ...a FRAMEWORK that is meant to be flexible

    *   SPIRIT of RUP?
        *   attack major risks early and continuously
	    -- or they attack you
        *   use WORKING software as the
	    primary measure of progress
        *   produce only artifacts you need
	    (if in doubt, don't produce it)
        *   ...

    *   We'll call a RUP project a collection of
        CYCLES (they sometimes use project --
	so there are multiple projects -- we're
	not going there...)

        *   each cycle results in a working
	    deliverable

	*   each cycle is a sequence of four 
	    PHASES
	    *   inception
	    *   elaboration
	    *   construction
	    *   transition

            *   inception - launching the
	        current cycle

            *   elaboration - address the major
	        technical risks of the cycle

            *   construction - moving from
                the executable architecture
                from the elaboration phase
		to a beta version ready for
		evaluation

            *   transition - ends with the
	        cycle release milestone --
		get it to the users,
		ensure that it is working,
		evaluate to prepare for the
		next cycle

		...release and evaluation;

    *   subprocesses of requirements,
        design, coding, testing, etc.,
	are considered as active throughout
	the cycles of a project,
	although the intensity of each
	can vary from phase to phase
	within different cycles

*   Timeboxing 
    *   to speed up development, employ
        parallelism between different iterations

    *   does this mean working on different
        to-be-deliverable iterations at the SAME
	time? YES

    *   really, uses the idea of PIPELINING
        
    *   ...carefully set up, for a project
        suitable for such an approach!

    *   in the timeboxing model,
        the basic unit of development is a
	time box, of FIXED duration

	*   since the duration is fixed,
	    a key factor in selecting the
	    requirements or features to be
	    built in a time box is what can
	    FIT in that time amount;

    *   each time box is divided into a
        sequence of STAGES,
	each STAGE performs a clearly-defined task
	for the time box iteration,
	and produces a clearly-defined output;

	and, such that each stage is of the
	same duration
	(if 4 stages in a time box,
	set up so each stage takes 1/4 of the time of
	the time box;

	if 3 stages in a time box,
	set up so each stage takes 1/3 of the time
	of the time box)

    *   and note: the people working on a stage
        work on *that* stage for different
	iterations of the time box,
	over and over;

	this does mean a BIGGER team of people,
	(more people for getting releases/iterations
	to the user more quickly)

        *   takes the same amount of time for
	    each iteration/deliverable,
	    BUT using more people working
	    in a pipelined-parallel fashion
	    to get more frequent releases
	    of those iterations to the users

	    ...uses additional workforce to
	    reduce delivery time;

    *   what projects can the timeboxing model be 
        suitable for?
	*   large number of features
	*   that can be developed in a relatively
	    short time
	*   around a stable architecture using
	    stable technologies