Learning Center
Plans & pricing Sign in
Sign Out

Let connect the dots OTUG


									    Welcome from


Shveta Mehtani presenting :

“Lets Connect the Dots…...”
Connecting the Dots ……...
   Patterns, Anti-patterns, Iterative development, Rational Unified
    Process (RUP), XP, SCRUM, Refactoring, - are they just new
    buzz words to be catalogued and forgotten with thousands of
    others or do they hold the potential for a bright new future?

    Can these new gizmos break this long tradition of failures? As
    software professionals, how do we make sense of all this new
    technology and leverage it's potential into powerful cost effective

    Join the discussion in this exciting shift from methodologies,
    processes and tools that were seldom successful to those that
    give us the potential to excel. Explore and unravel some of the
    mystique and gain a clearer understanding of this new software
    engineering paradigm!
The Problem
 Only16%   on time, within budget and
  with features
 53% over run (time, budget, lack
 31% outright cancelled

 Source: Standish “Chaos” Report,
“How does a project get to be
a year late?…
One day at a time.”

       - Frederick P. Brooks
 Getting to know the masterminds
 Defining the dots
     Patterns and Anti-Patterns
     Refactoring
     Extreme Programming(XP)
     Rational Unified Process(RUP)
     SCRUM

   Connecting the dots
 Getting to know the masterminds
 Defining the dots
     Patterns and Anti-Patterns
     Refactoring
     Extreme Programming(XP)
     Rational Unified Process(RUP)
     SCRUM

   Connecting the dots
          The Masterminds
 Grady Booch
 James Rumbaugh
 Ivar Jacobson
 Phillipe Kruchten
 Christopher Alexander
 Erich Gamma
 Richard Helm
 Ralph Johnson
 John Vlissides
 Kent Beck
      The Masterminds
 James Coplien
 Martin Fowler
 Linda Rising
 Frank Buschmann
 Alistair Cockburn
 Getting to know the masterminds
 Defining the dots
     Patterns and Anti-Patterns
     Refactoring
     Extreme Programming(XP)
     Rational Unified Process(RUP)
     SCRUM

   Connecting the dots
 What is a Pattern ?
 “Apattern addresses a recurring problem that
 arises in specific situations.”

          document existing, well-proven
 “Patterns
 design experience.”

          identify and specify abstractions that
 “Patterns
 are above the level of single classes and
What is a Pattern ?

 “Patterns provide a common vocabulary and
  understanding for design principles.”
 “Patterns are a means of documenting
  software architectures.”
 “Patterns support the construction of software
  with defined properties.”
 “Patterns help you build complex and
  heterogeneous software architectures.”
 “Patterns help you manage software
          Types of Patterns
   Design Patterns

   Analysis patterns

   Software architecture patterns

   Process patterns

   Organizational patterns

   Pedagogical patterns
             Design Patterns
   Design patterns provide abstract, reusable
    “micro-architectures” that can be applied
    (“instantiated”) to resolve specific design
    issues (forces) in previously-used, high-
    quality ways

   GoF defined widely used 23 design patterns
    like Factory, Observer, Visitor, State, Strategy
          Analysis Patterns
 By  Martin Fowler :
 “Patterns that reflect conceptual
  structures of business processes rather
  than actual software implementations.”
 Fowler uses a simple, specialized
  notation (very similar to entity-
  relationship diagram notation) to depict
  graphical models of analysis patterns.
Software Architecture Patterns

   “Architectural patterns are templates for
    concrete software architectures. They specify
    the system-wide structural properties of an
    application, and have an impact on the
    architecture of its subsystems. “
      Other Pattern Types
 Process   Patterns
   patternsthat deal with software
    development process issues
   work by Scott Ambler

 Organizational   Patterns
   patterns  that deal with organizational issues
    that arise in software development teams,
    groups and departments
   these can often be related to software
    process patterns
       Other Pattern Types
 Pedagogical          Patterns
   patterns that deal with best practice
    solutions to software technology education
    and training (object-oriented software
    development in particular)
   see work by Mary Lynn Manns et al.
         Benefits of Patterns
 Potential   benefits of the use of patterns
   provides  a common vocabulary and
    understanding of high-quality design elements
    for software designers
   increases productivity in design process due to
    “design reuse”
   promotes consistency and high quality of
    system designs and architectures due to
    application of high quality, high reliability,
    tested design expertise and solutions
    embodied by patterns
       Benefits of Patterns
 allowsall levels of designers, from novice to
 expert, to gain these productivity, quality and
 consistency benefits
 Training
         and education in common
 and proprietary patterns
      benefits are dependent upon architects, analysts and
       designers understanding the patterns to be used
      benefits are enhanced significantly only if ALL
       software development personnel understand the
       patterns as a common “design vocabulary”
      such training can be costly, and in many cases is
       proprietary and cannot be obtained externally
 Evolution
          and maintenance to insure
 continued value
      specific funding and effort must be directed toward
       maintenance and evolution of patterns as reusable
       assets or they tend to devolve into
       project/application-specific artifacts with dramatically
       reduced reusability characteristics
      the necessary funding, technical or organizational
       infrastructure supports may not exist to allow
       effective maintenance and evolution of patterns
       within an organization to insure continued high
     AntiPatterns                (from Brown, et al.)

   “An AntiPattern is a literary form that describes a
    commonly occurring solution to a problem that
    generates decidedly negative consequences.”
     Primal Forces
   AntiPatterns, like other patterns, deal with forces
    (concerns, issues) that exist in a specific problem

   Vertical forces are problem domain-specific

   Horizontal forces are applicable across multiple
    domains or problem settings
     Primal Forces
   Primal Forces are horizontal forces that are
    pervasive in software architecture and
    development. They include:
       Management of functionality: meeting the requirements
       Management of performance: meeting required speed of operation
       Management of complexity: defining abstractions
       Management of change: controlling the evolution of software
       Management of IT resources: controlling the use and implementation
        of people and IT artifacts
       Management of technology transfer: controlling technology change
   Design Patterns to Anti-Patterns
            Design Patterns                            AntiPatterns

                                                      Context & Causes

                                   Time passes
                                   yielding new                       AntiPattern
                                      context                          Solution
           Context & Forces

                                                  Symptoms & Consequences


Benefits         Related    Consequences
                                           Benefits      Related      Consequences
 Getting to know the masterminds
 Defining the dots
     Patterns and Anti-Patterns
     Refactoring
     Extreme Programming(XP)
     Rational Unified Process(RUP)
     SCRUM

   Connecting the dots
   “Refactoring is the process of changing a
    software system in such a way that it does
    not alter the external behavior of the code yet
    improves its internal structure”

   “A change made to the internal structure of
    the software to make it easier to understand
    and cheaper to modify without changing its
    observable behavior”

   “When you refactor you are improving the
    design of the code after it has been written “
                - Martin Fowler
Why Refactor ?
 Improves   the design of Software

 Makes   software easier to understand

 Helps   to find bugs

 Helps   to program faster
When to Refactor ?
 The   Rule of three
   When   you add function

   When   you need to fix a bug

   When   you do a code review
 Getting to know the masterminds
 Defining the dots
     Patterns and Anti-Patterns
     Refactoring
     Extreme Programming(XP)
     Rational Unified Process(RUP)
     SCRUM

   Connecting the dots
Processes and Methodologies
 From  Nothing, to Monumental, to Agile
 Attempt a useful compromise between
  no process and too much process,
  providing just enough process to gain a
  reasonable payoff.
 Agile methods are adaptive rather than
 Agile methods are people-oriented rather
  than process-oriented
Current Agile methods
 XP


What is Extreme Programming?
   “XP is a lightweight (agile) methodology for small-
    medium-sized teams developing software in the
    face of vague or rapidly changing requirements. “

   “It's a team-centric way of developing software
    focused on delivering business value quickly,
    without it being a hack.”

   “It is called “ extreme as it takes the common
    sense principles and practices to extreme levels”
                - Kent Beck
Why is XP extreme ?
       12 XP Practices
 Planning  Game
                      Continuous
 Short Releases
 Simple Design
                      On-site Customer
 Testing
                      40 Hour Week
 Refactoring
                      Metaphor
 Pair Programming
                      Coding Standards
 Collective
Rational Unified Process(RUP)

  Evolved  from Unified Process
   developed by the “the three Amigos “ –
   Booch, Rambaugh and Jacobson.
  Phillepe Krutchen made a detailed
   refinement on UP and hence came RUP
  Main focus on Iterative and Incremental
Is RUP agile ?

 RUP can be used in a very traditional
  waterfall style or in an agile manner.
 “You can use RUP as a agile process, or as a
  heavyweight process - it all depends on how
  you tailor it in your environment. “ – Martin
 Craig Larman is a strong proponent of using
  the RUP in an agile manner
What is SCRUM ?
 Scrum is an agile, lightweight process to
  manage and control development work.
 Scrum is a wrapper for existing engineering
 Scrum is a team-based approach to
  iteratively, incrementally develop systems and
  products when requirements are rapidly
 Scrum is a process that controls the chaos of
  conflicting interests and needs.
    What is SCRUM ?
 Scrum is a way to improve communications and
  maximize co-operation.
 Scrum is a way to detect and cause the removal of
  anything that gets in the way of developing and
  delivering products.
 Scrum is a way to maximize productivity.
 Scrum is scalable from single projects to entire
  organizations. Scrum has controlled and organized
  development and implementation for multiple
  interrelated products and projects with over a
  thousand developers and implementers.
 Scrum is a pattern.
Project Management Patterns
  Patterns  “mined” from
  Based on comments from participants.
  Observed in at least three projects.
  Industry experience or research verifies
  Patterns are living and grow based on
   experience with use.
 Getting to know the masterminds
 Defining the dots
     Patterns and Anti-Patterns
     Refactoring
     Extreme Programming(XP)
     Rational Unified Process(RUP)
     SCRUM

   Connecting the dots
Connecting the dots ……..
 Are we missing the big picture ?
 What are the key overlapping areas ?
 How do these methodologies and
  processes compliment each other?
 How do they contrast against each
  other ?
       The Big Picture

 Maximize  Reuse
 Keep it Simple
 Develop in small teams
 Focus on incremental development
 Schedule in a Time-boxed fashion
 Follow adaptive and agile processes
   Martin Fowler Modeling Thoughts
 “But  simple models are always worth the
  effort. Not only do they make things easier
  to build, but more importantly they make
  them easier to maintain and extend in the
  future. That’s why it is worth replacing
  software that works with simpler software
  that also works.”
 This is a value-based argument against “If
  it isn’t broken, don’t fix it”
The Overlaps
 XP and CMM
 XP and RUP
 SCRUM and XP
 XP and Refactoring
 Patterns and Refactoring
 SCRUM and Patterns
Oh ! The Possibilities !
 How   do they apply to me ?

 Do   I have to pick a camp ?

 Can   I pick the best of all worlds ?
The Answer
 “Whatever process you start with will
 not be the process that'll really work for
 you. You have to take charge of your
 process, monitor it and adapt it to your
 circumstances. In the end it must
 become your process, any other labels
 are secondary. “ – Martin Fowler
   “Design Patterns: Elements of Reusable Object-
    Oriented Software” - GoF
   “Refactoring : Improving the Design of Existing Code “
    - Martin Fowler
   “Extreme Programming Explained : Embrace
    Change”- Kent Beck
 “Anti-Patterns: Refactoring Software, Architectures,
    and Projects in Crisis” - Brown et al
   RUP online documentation
 Gary   Berosik
 Kyle   Larson
 Pam    Rostal
Question and Answer...

    Questions?
    Comments

To top