Managing Object-Oriented Projects

1
Managing OO Development at MarshA case study in
transforming an organisation formerly versed in
'legacy' (client server, PC, mainframe)
development, to a new Web Based Object Oriented
Development Paradigm.
2
Classic Benefits of OO

• Source - P. Coad, E. Yourdon 1991
• Tackle more challenging problem domains
• Improve analyst problem domain interaction
• Increase internal consistency of analysis results
• Explicitly represent commonality
• Build specifications resilient to change
• Reuse of analysis results
• Provide a consistent underlying representation
  for analysis

3
Agenda

• OO at Marsh
• CSFs for OO Process introduction
• Barriers to OO adoption overcome
• Benefits derived vs. the classics
• Our context
• Realities of software development
• requirements are constantly evolving
• Schedule, cost quality pressures will always be
  severe
• the business model and the applications are
  complex

4
OO Development At Marsh
Initiation
Develop preliminary estimate
Conceptualization
Deployment
Define the scope of the system
Deploy into production and maintenance
Architectural Design
Develop essential architecture
Evolution
Analysis
Build scenarios and business classes
Develop and Review Code
Write, unit test and review code
5
OO deliverables at Marsh
6
Phases build on the same deliverables
7
Current Status

• Number of Mature OO based Projects
• Critical mass of staff who understand the process
• A significant investment
• Over time have improved the ROI

8
Process introduction Transition

• To transition staff
• Training experience
• The process has been painful, CSFs (critical
  success factors)
• Recognize not everybody will make it
• Gartner Group
• 25 of people need retraining (Marsh 100)
• 25 never make the transition to OO (inc project
  mangers)
• You must have a strategy to allow a graceful exit
• Consistent message dedicated Marsh only training
  by selected vendor personnel
• Just in time vs. cost efficient training
• Workshops focused on specific application
  projects
• Coaching trainer stays with project to provide
  guidance and QA
• Train project managers test them

9
OO Test for Project Managers

• Explain Principals
• Objects and Classes?
• OO System?
• Aggregation?
• Abstraction?
• Inheritance?
• Components?
• Behaviour before data?

• Explain Approach
• Planning approach?
• Estimation?
• OO deliverables?
• Use of tools?
• Team roles?

10
Process introduction Recruitment

• Successful OO Analyst
• Good listener, fast learner
• Thinks logically, not intuitively
• Some formal education
• mathematics, computer science, engineering
• Excellent interpersonal skills
• Very detail-oriented person
• Some software project experience

• Successful OO Designer
• OO coding experience
• in more than 1 language
• Experience in several technical environments
• Able to understand business requirements
• Flexible approaches to problem solving
• Recent degree in computer science

• CSF question and test resume
• Its hard to get experience look for potential

11
Process introduction CSFs

• Implement process incrementally
• Start use case-driven build to class
  model-driven
• Do not rely on the use case document for analysis
• People think procedurally
• Result a procedural functional decomposition in
  a use case template
• Class model at analysis phase is key, helps team
  to think in terms of aggregation, inheritance,
  etc to build an abstract model
• With a new team use the coach to produce the
  class model, while the staff learn use case,
  sequence diagrams scenarios

12
Process introduction CSFs

• Implement tools incrementally
• Marsh does not have full Rational suite
• Using Rose, Word, SourceSafe
• Define the QA points into the process
• Phase based checklist on OO terms
• Structured walkthroughs within each phase
• Recognise and reward adoption

13

• Analysis Checklist
•      The context diagram is up-to date for this
  release and is checked into SourceSafe as
  
•      The use case diagram is up-to-date for this
  release and is checked into SourceSafe as
  ..cat
•      The use case document
•      All administrative details are complete and
  correct.
•      The scenarios which have been approved as
  being within scope for this release are complete
  and correct.
•      The use case diagram has been checked into
  SourceSafe as
•      The business object model
•      The business objects from the previous
  software release have been reconciled with this
  new version of the business objects.
•      All classes which need to exist, do exist
  in the model.
•      All operations have been named.
•      There is a clear and complete English
  description for each operation.
•      All attributes which need to exist in the
  object model, do exist.
•      There is a clear definition of each
  attribute.
•      All associations are indicated correctly,
  including multiplicity, role names and
  qualifiers.
•      The object model has been checked into
  SourceSafe as cat.
•      The normal scenario for each approved use
  case is diagramed as a sequence diagram, using
  the objects in the class model. One of the
  objects could be the User Interface Object.
•           Workflow
•      High level scenarios are implemented using
  sequence diagrams

14
Barriers to Adoption

• Many project already in progress
• Conflicting priorities
• Learning curve high profile strategic project
• Management support
• Is it possible to have a light weight flexible
  methodology?
• Takes too long !
• the rush to to prototype screens or to cut code
• Cost to much !
• Cost of implementing methodology tracked to
  project more effectively than benefits (or non
  compliance elsewhere)
• We are doing fine !
• Culture of analysis by expertise

15
Benefits Derived

• Common understanding,
• Assign well-defined, encapsulated tasks
• Documentation consistency
• standard format for scenarios and class models
• consistent use of design patterns, coding style
• Movement across projects
• Fast resolution of bugs, low repeat failure
• with automated regression testing, key to 90 day
  cycle
• Depth accuracy of documentation - 9/11 recovery
• Limited reuse
• At the component not enterprise level
• Career investment by the firm in the team

16
Benefits Derived

• Estimation - Cost and Time
• Process falls from the OO deliverables
• Refined though out life cycle
• Use Cases Order of magnitude 40 / -20
• Scenarios and business classes Project estimate
  20 / -10
• Design Classes Build estimate 10 / -5
• Metrics used have been refined across projects
• Scenario with UI 45 days
• Scenario without UI 38 days

17
Benefits Derived

• Managing the client - Scope
• Use cases
• Scenarios
• Functionality by release matrix

18
(No Transcript)
19
Project Scope
20
Benefits Derived

• Enable control of Offshore development
• Contracts are fixed price
• Price is as fixed as the scope definition
• Any CMM level 5 vendor is very good at change
  control
• Accurate specification is a key to managing off
  shore
• Functional acceptance
• Technical acceptance of code Vs Marsh design
  standards
• Class model passed between Marsh and vendor
• Used metrics based on per use case, scenario
  and class
• Develop independent estimates
• compare quotes over time
• Have a 110 cost over run where not properly
  implemented
• Achieved 15 cost reduction where process
  followed

21
Managing OO Development at MarshA case study in
transforming an organisation formerly versed in
'legacy' (client server, PC, mainframe)
development, to a new Web Based Object Oriented
Development Paradigm.