• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Managing Complexity and Change with Scalable Software Design
 

Managing Complexity and Change with Scalable Software Design

on

  • 1,949 views

This is a presentation I gave to a group of IT managers. It explains what 'scalable design' is about, discusses its motivations by a number of facts and figures about software development, and ...

This is a presentation I gave to a group of IT managers. It explains what 'scalable design' is about, discusses its motivations by a number of facts and figures about software development, and illustrates the approach through a real-world case.

Statistics

Views

Total Views
1,949
Views on SlideShare
1,945
Embed Views
4

Actions

Likes
0
Downloads
16
Comments
0

1 Embed 4

http://www.linkedin.com 4

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • (c) 2010 steX bv – www.stexbv.com
  • IS = Information Systems MIS = Management Information Systems (c) 2010 steX bv – www.stexbv.com
  • (c) 2010 steX bv – www.stexbv.com
  • BTW: this is very closely related to software architecture design, but then applied recursively until the remaining components are rather small individual building blocks. (c) 2010 steX bv – www.stexbv.com
  • focus here on the design part of technology.. SoC == divide and conquer (c) 2010 steX bv – www.stexbv.com
  • beloningssysteem aanpassen (c) 2010 steX bv – www.stexbv.com
  • 06/25/10
  • RoI factors: 400-4000% 70-1000% 150-700% -500% (c) 2010 steX bv – www.stexbv.com
  • 06/25/10

Managing Complexity and Change with Scalable Software Design Managing Complexity and Change with Scalable Software Design Presentation Transcript

  • MANAGING COMPLEXITY & CHANGE WITH SCALABLE SOFTWARE DESIGN Lodewijk Bergmans
  • Software engineering: a 3D balancing act
  • Plan of this talk
    • discuss impact of complexity and change on software project succes
    • present an approach to tackle this: ‘scalable design’
      • some of its ingredients
      • illustrated by a case (ASML)
  • Challenges in software development
    • managing complexity
      • we build increasingly (inherently) complex systems
      • which carry more and more accidental complexity
    • continuous change
      • change starts on day one..
      • causes large maintenance costs
    • these are strongly related:
      • Study by Banker et.al. (1993) :
      • 25% of the maintenance costs are due to high complexity
  • experience: complexity vs project risk source: Wallace, Keil & Rai, “Understanding software project risk: a cluster analysis”, Information & Management 42 (2004)
  • The only constant: Change Year maintenance costs (%) Definition Reference 2000 >90% sw.cost devoted to system maintenance & evolution / total sw. costs Erlikh (2000) 1993 75% sw. maintenance / IS budget (in Fortune 1000 companies) Eastwood (1993) 1990 >90% sw. cost devoted to system maintenance & evolution / total sw. costs Moad (1990) 1990 60-70% sw. maintenance / total MIS operating budgets Huff (1990) 1988 60-70% sw. maintenance / total MIS operating budgets Port (1988) 1984 65-75% Effort spent on sw. maintenance / total available SE effort. McKee (1984) 1981 >50% Staff time spent on maintenance / total time (in 487 organizations) Lientz & Swanson (1981) 1979 67% Maintenance costs / total sw. costs Zelkowitz  et al. (1979)
  • proportional maintenance costs source: Banker et.al., “Software Complexity and Maintenance Costs”, CACM, Nov. 1993
  • Solution approach: scalable design
    • A scalable design is a software design that can scale up with growing requirements and change requests .
    • goal: reduce costs of changes and extensions
      • avoid “architectural detoriation”
    • a new paradigm?
      • no: just a coherent set of best practices
      • must be tailored to specific project & organization
  • Scalable design approach - technology
    • model-oriented (domain models)
      • understand the core/essence
      • identify and focus on stable parts
    • composition-oriented!
      • separation of concerns
      • create variability by composing & configuring components
        • not by source code & compiler directives & build files & XML files & configuration files & parameters & ..
      • goal: conceptual integrity of the design
  • Scalable design approach - people
    • incremental growth & design iteration*
    • good separation of concerns:
      •  assigning jobs to right people (and lets them focus)
    • the mindset of people must be adapted
      • focus on long-term & variability
      • requires different evaluation/reward system.
    source: fact 28 in R. Glass., “Facts and Fallacies of Software Engineering”, Addison-Wesley 2003
  • Scalable design approach - value
    • work incremental:
      • prioritize
      • build only what is needed
        • but be prepared for the future!
    • scalable design yields systems that are much more flexible
        •  this will make your business more flexible and agile
    • requirements will change during project
      • a scalable design can better handle that
  • Software Complexity in an Industrial Case:
    • large embedded system in the lithography domain
      • 400 sensors, 300 actuators, 50 processors
    • Software: 15-20 MLoC (mostly C)
  • Industrial case
      • 4 concepts ‘crosscut’ the system (-30% of code)
      • error-prone, hard to maintain, ...
    int get_kng(KNG_struct* KNG_ptr) { const char* func_name = "get_kng"; int result = OK; timing_handle timing_hdl = NULL; TIMING_IN; trace_in(mod_data.tr_handle, func_name); if (result == OK) { /* Retrieve current KNG */ *KNG_ptr = mod_data.KNG; } HE(result, "GET_KNG FAILED"); trace_out(mod_data.tr_handle, func_name, result); TIMING_OUT; return result; } primary functionality error handling
  • Industrial case: approach
    • capture the essence of the 4 concepts
      • separate these into independent abstractions
    KNG_struct get_kng() { return ( mod_data.KNG); } note: ASML focused first on only one aspect
  • Industrial case: how to achieve this
    • Technology:
      • identify & implement core (crosscutting) concepts
        • as general as possible but no more
      • + used special composition tooling (‘aspect weaver’)
    • People:
      • a few developers focus on crosscutting concerns
      • key benefit: developers make less mistakes!
    • Value:
      • business case focused on bug reduction
        • + consistency + simplicity + maintainability
  • Improvement potential source: Walker Royce, “Improving Software Economics”: IBM white paper (2009) costs (per person year) 10-35% 5-10% <5% 200-1000% 25-100% 15-35% 5-25% impact (productivity) 25-50%
  • Conclusion
    • One empirical study* has shown that well-structured code is:
      • 2x easier to change
      • 8x less prone to defects
    • In addition:
      • better project predictability
      • flexible products (=flexible business)
    • By consistently applying existing techniques:
      • scalable designs are feasible & worthwhile
    * source:a study by The Software Technology Support Center and The Mitre Corporation
  • Questions?
  • questions/discussion items
    • in your practice, do you think complexity of software is a key factor in project success?
    • how important is maintainability of software for you?
      • how big are maintenance costs (relative to overall costs)?
    • how do you try to achieve/receive maintainable software?
      • and how do you assess this?
  • Applicability of scalable design
    • NO if:
      • the requirements are completely fixed (..)
      • the size of the software is so small one person can keep it in his/her head
      • you do not care about costs after first release
    • YES if:
      • requirements may change/improve/become more detailed
      • there is even a modest size or complexity
  • Wat can you do?
    • as a customer : evaluate projects differently:
      • e.g. include life-cycle costs
        • what are costs of realizing new/changing requirements?
        • measure economical lifespan of products?
      • acceptance test could include change scenarios
        • see: architectural assessment (e.g. SAAM)
    • as project management :
      • create a culture that supports scalable design
        • but avoid big, isolated, efforts!
          • e.g. large framework investments decoupled from projects
  • Scalable Design Paradox
    • design is an iterative process... *
      • this means that the first design is never the right & final one.
      • it implies that getting the ‘right’ scalable design the first time is impossible
      • and that any design will repeatedly change
    • when you start with a scalable design:
      • you will be able to handle the changes much easier
      • iterations have less impact on the overall system!
    • this implies that a scalable design pays back early!!  
    source: fact 28 in R. Glass., “Facts and Fallacies of Software Engineering”, Addison-Wesley 2003
          • Slide