Managing the Object-Oriented Development Process

Object-oriented (OO) design offers many promises: increased usability, faster project development, reduced bug counts, and easier program maintenance are all readily achievable goals. Nonetheless, these advantages cannot be realized without a thorough commitment to OO, and adopting OO successfully requires more changes than management typically imagines.

Back in 1968, Mel Conway noted that "the structure of a system tends to mirror the structure of the group producing it." The inverse also holds, if a group is structured to work in a certain way, it will be difficult or impossible for that group to work in a new way without also changing the group organization and dynamics. For OO to succeed, a complex network of support mechanisms and process must exist to support it: the physical site, the internal organization of the company, the allocation of tasks and resources to departments, the ways in which the programmers work and interact with one another and with other departments-all of these areas are effected.

Changes of this magnitude cannot be attempted, of course, unless management (at all levels) is thoroughly familiar with the OO process and how to support it. This class addresses this problem by providing managers with a thorough introduction to OO concepts and OO design and development techniques, with a focus on group structure and workflow. Participants will come away from this course with a solid grounding in OO concepts, a thorough understanding of appropriate software-development processes, and a game plan for successfully adopting OO processes within an organization.

Outline

• An historical overview
  • Procedural methodologies
  • The waterfall Model (doesn't work)
  • The origins of OO (Simula '67).
• Why use OO?
• Why not to use OO?
• OO myths
• OO realities
• Conway's Law
• The design environment
  • Written communication is ineffective
  • Beware the cargo cults
  • CASE Tools (or lack thereof)
  • The physical plant
• What makes something object oriented?
  • Principles and maxims
  • Determinism and complexity
  • An example (life)
  • An example (more-complex cellular automata)
  • An example (sim city)
    • Objects
    • Classes
    • Interfaces
    • Managing complexity through decomposition, encapsulation, and delegation
  • Yet more Examples:
    • Employees
    • UI Objects
    • ATM Machines
  • Data Flow
  • OO Structure Doesn't Guarantee OO
  • Other Buzz Words
    • Cohesion
    • Coupling
    • Executable Release.
    • Problem Domain
    • Problem Statement
    • Use Case
  • More Key OO Concepts:
    • Attributes
    • Messages
    • Code Reuse
    • Derivation
    • Polymorphism
    • Code reuse and application frameworks
• OO Modeling
  • The dynamic model.
  • Cunningham/Beck CRC cards
  • The static model
• OO Methodologies
  • The ideal development curve
  • Core concepts found in all methodologies
  • Programming as writing
  • There's no such thing as "data"
  • Build exactly what's required: no more, no less.
  • Do the UI early (and Often)
  • Design with the User in Mind
    • Goal-oriented design
  • Developing organic Processes
  • Special needs of OO Environments
    • Team structure
    • The physical environment
  • Example Processes
    • SEI and high-ceremony processes.
    • SEI Capability Maturity Model
    • A case study.
    • RUP
    • Recursive/Parallel Development
    • Spiral Development Models
    • Agile Development
    • Crystal
    • Extreme Programming (XP)
    • Options Pricing for Software
    • XP Practices
• The OO Process:
  • Why Traditional Requirements Documents Don't work
  • Why feature Lists Don't Work
  • The "Problem statement"
  • Use Cases
    • Marketing or Engineering?
    • Roles vs. Actors
    • Activities (vs. Workflow)
    • An in-depth look at a formal use case
  • Use-Case Based UI Design.
  • UML Modeling
    • What is it and how is it used?
    • The dynamic model.
    • The static model.
    • Conceptual and implementation models.
  • From the Model to Code