Software Engineering Methods Course 302, Autumn 2006

1
Software Engineering MethodsCourse 302, Autumn
2006

• Michael Huth
• Department of Computing
• Imperial College London
• M.Huth_at_doc.imperial.ac.uk
• www.doc.ic.ac.uk/mrh

2
Lecture 4
3
Unified Process (UP )

• Popular iterative process framework, especially
  its refinement Rational Unified Process (RUP )
• Key practices and guidelines
• Short time-boxed iterations
• Develop high-risk elements in early iterations
• Deliver value to customer
• Accommodate change early on in project
• Work as one team

4
Classification of UP

• Average project iteration length of 2-6 weeks
• Very flexible in degree of ceremony, over 50 work
  products usable to increase ceremony if needed
• Typically higher degree of ceremony than Scrum,
  yet encourages light touch
• Works for all kinds of projects essential money,
  life critical, 4-100 people, etc

5
Characteristics of UP

• Iterative process framework, typically customized
  to process description of organization
• All work products (artifacts) optional, their
  order arbitrary
• RUP is process framework and licensed product
  (tool web pages)
• Artifacts are information abstractions, e.g.
  Vision, Risk List, and organized in disciplines,
  e.g. Requirements Discipline

6
Disciplines within iterations

• Example disciplines Requirements, Design,
  Project Management, Implementation
• Development Case of UP UP tailored for each
  project, choose sets of practices and work
  products (less is better)
• Disciplines addressed in each iteration but to
  varying degree

7
UP Life cycle in four phases

• Inception
• Elaboration
• Construction
• Transition
• The Enterprise Unified Process (EUP) adds two
  more phases to this
• Production keep system useful/productive after
  deployment to customer
• Retirement archive, remove, or reuse etc.

8
Inception and Elaboration

• Inception business case, vision, identify high
  risks 10 of key requirements in detail,
  estimate elaboration effort
• Elaboration core architecturally significant
  parts coded/tested, key risks identified/mitigated
  , 80 of major requirements evolved/defined

9
Construction and Transition

• Construction builds remaining system in short
  iterations, (hoped to be) efficient and
  predictable due to solid elaboration phase
• Transition exposes release candidate for
  review/feedback, then deploys

10
Prominent UP work products

• Vision summary of objectives, features, and
  business case
• Software Architecture Document short learning
  aid to understand the system
• Test Plan summary of goals and methods for
  testing
• Iteration Plan detailed plan for next iteration
• Change Request uniform way to track all requests
  for work, e.g. defects

11
Example roles in UP

• Stake Holder customer, product manager, etc.
• Software Architect established and maintains
  architectural vision
• Process Engineer leads definition and refinement
  of Development Case
• Graphic Artist assists in user interface design,
  etc.

12
Some UP guidelines

• Attack risks early on and continuously so, before
  they will attack you
• Stay focused on developing executable software in
  early iterations
• Prefer component-oriented architectures and reuse
  existing components
• Quality is a way of life, not an afterthought

13
Six best must UP practices

• Time-boxed iterations avoid speculative
  PowerPoint architectures
• Strive for cohesive architecture and reuse
  existing components
• e.g. core architecture developed by small,
  co-located team
• then early team members divide into sub-project
  leaders

14
Six best must UP practices

• Continuously verify quality test early often,
  and realistically by integrating all software at
  each iteration
• Visual modeling prior to programming, do at
  least some visual modeling to explore creative
  design ideas

15
Six best must UP practices

• Manage requirements find, organize, and track
  requirements through skillful means
• Manage change
• disciplined configuration management protocol,
  version control,
• change request protocol
• baselined releases at iteration ends

16
How to fail with UP

• Elaboration phase goal is to create a throwaway
  prototype
• prototypes are acceptable in UP, e.g. during
  inception
• but elaboration goal is creation of a subset of
  final system
• Each phase is one iteration each of the four
  phases consists of several iterations (except
  perhaps inception)

17
How to fail with UP (2)

• Iterations too long iterations should typically
  be 2-6 weeks long, not months longer iterations
  require focus and permanence in vision
• Software Architecture Document finished before
  end of elaboration UP SAD is learning aid, so
  this would imply up-front design

18
How to fail with UP (3)

• Team should do lots of modeling and UML diagrams,
  and use CASE tool UP contains optional models
  with potential use of UML but UP also compatible
  with agile approach, e.g. use of whiteboard etc.
• Development Case too complex, too many work
  products less is better, UP recommends adding
  work products that all real value

19
How to fail with UP (4)

• Not conforming with official UP work product or
  phase names common vocabulary vital within
  organization and across global UP-conforming
  teams
• Inception phase several weeks long if you spend,
  e.g., four weeks on gathering initial
  requirements the project begins with a lack of
  focus, purpose, and direction your team will be
  affected by this
• Dont stress importance of early programming
• Encourage more and more work product creation

20
UP in large industrial project

• Canadian Air Traffic Control System
• ten years
• life critical, 400 people
• Ada C
• test bed for UP practices, lead to RUP
• Previous failed waterfall attempt of 11 years and
  2.6 billion (yes, billion) US

21
UP in medium-sized project

• Ogre Nextgen Economic Modeling System
• Decision support system for oil/gas asset holders
• 2 years
• Essential money, 20 people
• Java technologies

22
UP in small industrial project

• QUICKcheck point-of-sale
• Self-checkout system for grocery stores
• 1 year
• Six people
• Java technologies
• Main developer Kyrus

23
History of UP

• Some roots in the Spiral Model of Barry Boehm
• Core initial development around 1995-1998
• Large Canadian Air Traffic Control project as
  test bed
• Philippe Kruchten chief architect of UP/RUP
• Rational Corporation had commercial product in
  mind (RUP, now owned by IBM) but also reached out
  to public domain (UP)

24
Recommended Reading

• Applying UML and Patterns An Introduction to
  OOA/D and the Unified Process, Prentice Hall,
  2002, by G. Larman
• The Rational Unified Process - An Introduction,
  Addison-Wesley Professional, 2002, by its lead
  architect Ph. Kruchten