Managing Object Oriented Projects

1
Managing Object Oriented Projects

• By Shady Ahmed Hassan

2
On July 20th 2008, our name has changed from
to
3
Agenda

• Complexity of the Software
• Software Development Processes
• Pragmatics

4
Software and Complexity

• The more complex the system, the more open it is
  to total breakdown
• Rarely would a builder think about adding a new
  sub-basement to an existing 100-story building.
• Amazingly, users of software systems rarely think
  twice about asking for equivalent changes.
  Besides, they argue, it is only a simple matter
  of programming.

5
Structure of Complex Systems

• Most of the problems in software development
  arise from its inherent complexities
• Examples of systems of significant complexity
• the Space Shuttle
• the England/France tunnel
• large business organizations
• complex systems appear in nature too, such as the
  human circulatory system

6
Hierarchy in Complex Systems

• Structure of a personal computer
• tracking down a timing problem in the primary
  memory , we will look at the gate-level
  architecture of the computer
• Tracking down a problem in a spreadsheet would be
  inappropriate at the same level of abstraction

7
Hierarchy in Complex Systems (Cont.)

• Structure of a of Social Institutions
• when organizations grow larger, we see a distinct
  hierarchy emerge.
• Multinational corporations contain companies,
  which in turn are made up of divisions,
• which in turn contain branches, which in turn
  encompass local offices, and

8
Why is software inherently complex?

• The complexity of the problem domain
• The difficulty of managing development process
• The flexibility possible through software

9
Designing Complex Systems

• The conception of a design for a new structure
  can involve as much a leap of the imagination and
  as much a synthesis of experience and knowledge
  as any artist is required to bring to his canvas
  or paper. And once that design is articulated by
  the engineer as artist, it must be analyzed by
  the engineer as scientist in as rigorous an
  application of the scientific method as any
  scientist must make

10
Designing Complex Systems (Cont.)

• Model Building is important
• Software designing methodologies
• Notation
• Process
• Tools
• Object Oriented Analysis and Design

11
The Unified Modeling Language

• Definition
• Diagram taxonomy
• Role of Tools

12
Traits of Successful OO Projects

• Strong Architecture Vision
• Fundamental organization of a system embodied
  in its components, their relationships to each
  other, and to the environment, and the principles
  guiding its design and evolution IEEE definition
• Well defined layers of abstraction
• Clear separation of concerns between the
  interface and implementation of each layer
• The architecture is simple

13
Traits of Successful OO Projects (Cont.)

• Iterative and Incremental Lifecycle
• the functionality of the system is developed in
  a successive series of releases (iterative) of
  increasing completeness (incremental).
• A release may be external (available to the
  customer) or internal (not available to the
  customer)
• The iterative and incremental approach is at the
  heart of most modern software development
  methods, including agile methods like Extreme
  Programming (XP) and SCRUM

14
Toward a Rational Development Process

• think of all software development processes as
  existing somewhere on a process continuum, with
  agile on one end and plan-driven on the other.
  The location of a specific process on the
  continuum is based on its key themes and its
  overall strategy.

15
Agile Processes

• Lightweight and sparse, less ceremony
• Reliant on the tacit knowledge of the team
  members
• Tactically focused rather than strategic
• Iterative and incremental
• Heavily reliant on customer collaboration
• Self-organizing and managing

16
Plan Driven Processes

• Reliant on well-documented practices
• Strategically focused rather than tactically
  focused
• Reliant on a customer contract
• Managed and controlled
• Defined up front and then continually
• improved

17
Agile Vs. Plan-driven
18
Iterative Software Lifecycle

• represents the activities of the entire
  development team
• dictates a number of measurable products and
  activities
• permit the development team to meaningfully
  assess risk and make early corrections to the
  micro process
• Allow the team to focus on the analysis and design

19
Iterative Software Lifecycle - Disciplines
20
Iterative Software Lifecycle Phases ,
Milestones and iterations
The concept of an iteration is pretty much the
same across most software development methods.
What differs is the recommended duration for each
iteration. XP recommends that iterations be one
or two weeks long, if possible. SCRUM specifies
that all iterations (sprints) should be 30 days
long. RUP recommends that iterations be two to
six weeks long.
21
Analysis and Design The Micro Process

• the micro process takes the requirements provided
  by the macro process (and any analysis and design
  specifications produced by previous iterations of
  the micro process) and produces design
  specifications (most notably, the architecture)
  that are implemented, tested, and deployed in the
  macro process

22
Analysis and Design The Micro Process (Cont.)
Analysis
Design
Architectural
Component
23
Analysis and Design The Micro Process (Cont.)

• Activities
• Identify the elements Discover (or invent) the
  elements to work with . Define the
  object-oriented decomposition.
• Define the collaborations between the elements
  Describe how the identified elements collaborate
  to provide the systems behavioral requirements.
• Define the relationships between the elements
  Define the relationships between the elements
  that support the element collaborations.
• Define the semantics of the elements Establish
• the behavior and attributes of the identified
• elements. Prepare the elements for the
• next level of abstraction.

24
Pragmatics
25
Benefits of Object Oriented Development

• Appeals to the working of human cognition
• Leads to systems that are more resilient to
  change
• Encourages the reuse of software components
• Reduces development risk
• Exploits the expressive power of object-oriented
  programming languages

26
Risks of Object Oriented Development

• Personnel shortfalls
• Unrealistic schedules, budgets, or processes
• Mismatches in requirements or user interface
• Shortfalls in architecture, performance, or
  quality
• Continuing stream of requirements changes
• Shortfalls in externally performed tasks

27
Further Reading

• The Unified modeling language user guide Grady
  Booch , James Rumbaugh, Ivar Jacobson
• Object Oriented Analysis and Design with
  applications Grady Booch Robert A. Maksimchuk,
  Michael W. Engle, Bobbi J. Young, Ph.D.
• Agile Software Development Methods Pekka
  Abrahamsson, Outi Salo, Jussi Ronkainen
• Rational Unified Process IBM Rational

28
QA
29
Thank You
Shady Ahmed Hassan
Shady.ahmed_at_its.ws