Learning Center
Plans & pricing Sign in
Sign Out
Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>

Successful Software Management Style steering and Balance By


  • pg 1
									     Successful Software
Management Style: steering and
  Balance By: Walker Royce
         Presentation by:
       Sergey Melderis and
           Brian Merritt
      Who is Walker Royce?
• Walker Royce is vice president of IBM’s
  Worldwide Rational Services Organization
• Working in software development for 16
• Active project manager for 7 years
• Also a principal contributor to the
  management philosophy inherent in
  Rational’s Unified Process
       Overview of his paper
• Is software development a rigorous
  engineering process?
• Royce compares software development
  with a movie production
• An iterative approach to software
• Four patterns for successful steering
• Economic benefits of a leadership style
         According to Royce
• No, software development is not a
  rigorous engineering process
  – No laws of physics to constrain the problems
    or solutions
  – Almost anything can be changed during a
    software project
    • Plans, people, funding, etcetera
  – Economic performance has proven to be the
    best measure for software success
• Royce describes software management as a
  discipline of software economics rather than
  software engineering
• This is based on the decisions of a software
  –   Cost trade-offs
  –   Human factors
  –   Market strength
  –   Timing
• He recommends using a steering leadership
     Steering leadership style
• Comprised of:
  – Active management involvement
  – Frequent course correction
• Royce advocates that this styles is better
  than the traditional project management
• This is known as an iterative development
  IBM Rational Unified Process
• An accepted benchmark of modern
  iterative development process
• It’s life cycle has four phases
  – Inception
  – Elaboration
  – Construction
  – Transition
• Each phase is a project state, not a
  sequential-activity-based progression
    Iterative management style
• Results-rather than activity-based
  – Real results are executable programs
  – Everything developed, requirement documentation,
    use case models, plans, etcetera, is just a way to get
    to the final result

• In a movie production
  – Real result is motion picture on a screen
  – Scripts, storyboards, set mockups, costume designs,
    etcetera is not tangible enough to judge its effect until
    you commit it to film
       Precision vs. Accuracy
• Software managers must accurately
  forecast estimates, risks, and the effects of

• Unjustified precision in requirements or
  plans is a recurring obstacle
     Four patterns for successful

• Scope management

• Process rigor

• Progress honesty

• Quality control
         Scope Management
• Conventional life cycle is usually presented
  as a sequential thread of activities:
  requirements, analysis, design, code, test,
• Successful projects implement this,
  however, the boundaries are not strictly
  defined or enforced
• They don’t use “requirements”
• The most misused word in our industry
• Required means nonnegotiable, but in
  every successful project we see changed,
  negotiated requirements
• Use word specification instead
• Specifications are changeable and are
  understood as the current state of our
     Form of user specification
• Vision statement captures the contrast
  between the development group and user.
  (text, mockups, use cases)

• Evaluation criteria - glimpses of objectives
  for a given intermediate lifecycle checkpoint
  like a demo of some sort
               Process rigor
• More rigorous processes are appropriate
  – the teams are distributed
  – many stakeholders are involved
  – the quality specifications are extreme
  – the constraints are externally imposed
  – the project is later in the lifecycle phases.
• Process rigor should act like gravity
       Process Rigor (cont.)
• Successful software development
  processes show well-defined transitions in
  all phases
• Software projects fail because of the lack
  of emphasis on process rigor
• Another reason software projects fail is
  – Over-engineering early in the life-cycle
  – Under-engineering during the production
          Progress Honesty
• Stakeholder relationships deteriorate
  during the classical development process
• Trust is essential
• Using a more iterative model coupled with
  communication will allow everyone to
  focus on the project rather than the
• Must deliver value but in a profitable way
           Iterative process
• The transition to a demonstration-driven
  life cycle results in a very different project
• Instead of a linear progression, which was
  said to be dishonest, an honest sequence
  of developments will promote a healthy
    More on progress honesty
• There shouldn’t be a negative reaction if
  flaws are found during the early life cycle
• Initial deliveries will not perform like a final
• Must provide honest indicators of progress
            Quality Control
• Completing early testing can help resolve
  architectural issues at the beginning of the
  life cycle
• Can also serve as a way for continuous
  progress and performance
• Using an iterative development will allow
  integration testing to come before
  component testing
         Testing and testers
• Conventional approach
  – Testers come up with plans, procedures, and
    papers that work under the analysis and
    design artifacts
  – They do not predict project success
• Iterative approach
  – Testers responsible for effective “analysis”
    activities and results
     Documentation problems
• Testers use a documentation driven
  approach by developing
  – System-test-plan documents
  – System-test-procedure documents
  – Integration-test-plan documents
  – To name a few..
• This can lead into problems:
  – Rework
  – Scrapping parts of the project to start over
            Testing defined
• The author defines testing as
  – “the explicit evaluation by executing some set
    of components under a controlled scenario
    with an expected and objective outcome”
      Economic benefits of a
        leadership style
• Three projects profiles were measured in
  executable (testable) code completed
• Modern
• Conventionally
• Future
How did they do?
• Sequence of conventional project
  – Early success on paper
  – Code commitment late in the life cycle
  – Unforeseen implementation issues
  – Heavy budget and schedule pressure
  – Late fixes
  – Unmaintainable product that was delivered
• Provided a progression of demonstrable
  – Avoided late patches
  – Robust and maintainable product delivered
    Little statistics from Royce
• Conventional
  – Still the norm, about half of the projects today
    resemble this

• Modern profile
  – About 1 in 4 projects today
               The End
• Questions?
• Comments?

To top