Overview of the TriBITS Lifecycle Model

Overview of the
TriBITS Lifecycle Model
First Workshop on Maintainable
Software Practices in e-Science
(SoftwarePractice12)
October 9, 2012
Dr. Roscoe A. Bartlett, Ph.D.
•  CASL Vertical Reactor Integration Software
Engineering Lead
•  Trilinos Software Engineering Technologies
and Integration Lead
•  Computational Eng. & Energy Sciences
•  Computer Science and Mathematics Div
•  Co-authors:
•  Mike Heroux (Sandia National Labs)
•  Jim Willenbring (Sandia National Labs)

TriBITS Lifecycle Model 1.0 Document

http://www.ornl.gov/~8vt/TribitsLifecycleModel_v1.0.pdf
2 Managed by UT-Battelle
for the U.S. Department of Energy Presentation_name

Motivation for the TriBITS
Lifecycle Model


Overview of Trilinos

•  Provides a suite of numerical solvers and discretization methods so support
predictive simulation.
•  Provides a decoupled and scalable development environment to allow for algorithmic
research and production capabilities => “Packages”
•  Mostly C++ with some C, Fortran, Python …
•  Advanced object-oriented and generic C++ …
•  Freely available under open-source BSD and LGPL licenses ...

Current Status
•  Current Release Trilinos 10.12 (July 2012)
•  Next Release Trilinos 11.0 (October 2012)

Trilinos website
http://trilinos.sandia.gov (soon to be http://trilinos.org)


VERA Visualization

VERA GUI/workflow
Reactor-Aware
FACADEs
Embedded
Reactor Geometry DB Automatic Mesh
Generation

VERA Foundation

Data Mapping Simulation workflow External Physics
control scripting Models (e.g.
StarCCM+, …)
Multi-physics coupling
toolkit Simulation post-
processing

Concrete
VUQ (i.e Dakota)
numerical
algorithms
(e.g. Epetra,
Epetra, ML,
VERA-Supported Physics Ifpack, …)
Models (e.g. Denovo, Drekar,
Materials Interface SCALE, DeCART, ...)

Basic Automatic Mesh
Abstract
Generation
Reactor-aware input numerical
algorithms
(e.g. Thyra,
NOX, Rythmos,
…)
Advanced Mesh
5
DOE CASL NE Hub
Managed by UT-Battelle
Generation

The CSE Software Engineering Challenge
•  Develop a confederation of trusted, high-quality, reusable, compatible, software
packages/components including capabilities for:
o  Discretization: a) geometry, b) meshing, b) approximation, c) adaptive refinement, …
o  Parallelization: a) parallel support, b) load balancing, …
o  General numerics: a) automatic differentiation, …
o  Solvers: a) linear-algebra, b) linear solvers, c) preconditioners, d) nonlinear solvers,
e) time integration, …
o  Analysis capabilities: a) embedded error-estimation, b) embedded sensitivities, c)
stability analysis and bifurcation, d) embedded optimization, d) embedded UQ, …
o  Input/Output …
o  Visualization … APP1 e.g. Denovo
o  ...
CSE Confederation Pkg A Pkg B

Pkg A Pkg B Pkg C ... e.g. Drekar
APP2

... Pkg X Pkg Y Pkg Z Pkg A Pkg B Pkg C

6
CASL VERA is a larger example of this.
Managed by UT-Battelle Pkg X Pkg Y
Trilinos is a smaller example of this.

Obstacles for the Reuse and Assimilation of
CSE Software
Many CSE organizations and individuals are adverse to using externally developed
CSE software!
Using externally developed software can be as risk!
•  External software can be hard to learn
•  External software may not do what you need
•  Upgrades of external software can be risky:
•  Breaks in backward compatibility?
•  Regressions in capability?
•  External software may not be well supported
•  External software may not be support over long term (e.g. KAI C++)
What can reduce the risk of depending on external software?
•  Apply strong software engineering processes and practices (high quality, low defects,
frequent releases, regulated backward compatibility, …)
•  Ideally … Provide long term commitment and support (i.e. 10-30 years)
•  Minimally … Develop Self-Sustaining Software (open source, clear intent, clean design,
7
extremely well tested, minimal dependencies, sufficient documentation, …)

Background

TriBITS, Lifecycle Models,
Lean/Agile


TriBITS: Tribal Build, Integrate, Test System
•  Based on Kitware open-source toolset CMake, CTest, and Cdash developed during the adoption by
Trilinos but later extended for VERA, SCALE and other projects.
•  Built-in CMake-based package architecture support for partitioning a project into ‘Packages’ with
carefully regulated dependencies with numerous features including:
–  Automatic enabling of upstream and downstream packages (critical for large projects like Trilinos, SCALE,
and CASL)
–  Integrated MPI and CUDA support
–  Integrated TPL support (coordinate common TPLs across unrelated packages, common behavior for user
configuration, etc.)
–  Removal of a lot of boiler-plateCMake code for creating libraries, executables, copying files, etc. …
•  Powerful TRIBITS_ADD_[ADVANCED]_TEST(…) wrapper CMake functions to create advanced tests
•  Integrated support for add-on repositories with add-on packages.
•  TribitsCTestDriver.cmake testing driver:
–  Partitioned package-by-package output to CDash and reporting on a package-by-package basis
–  Failed packages don’t propagate errors to downstream packages
–  Integrated coverage and memory testing (showing up on CDash)
–  Nightly and continuous integration (CI) test driver.
•  Pre-push synchronous CI testing with the Python checkin-test.py script
•  In addition: TribitsDashboardDriver system, download-cmake.py and numerous other tools

Defined: Life-Cycle, Agile and Lean
•  Software Life-Cycle: The processes and practices used to design, develop, deliver and
ultimately discontinue a software product or suite of software products.
•  Example life-cycle models: Waterfall, Spiral, Evolutionally Prototype, Agile, …
•  Agile Software Engineering Methods:
•  Agile Manifesto (2001) (Capital ‘A’ in Agile)
•  Founded on long standing wisdom in SE community (40+ years)
•  Push back against heavy plan-driven methods (CMM(I))
•  Agile Design: Simple design, continuous incremental (re)design and refactoring as
new features are developed and software is reused.
•  Agile Quality: Keep defects out using Test Driven Development (TDD), unit tests,
collaborative development.
•  Agile Integration: Software needs to be integrated early and often.
•  Agile Delivery: Software should be delivered to real (or as real as we can make them)
customers is short (fixed) intervals.
•  Becoming a dominate software engineering approach
•  Lean Software Engineering Methods:
•  Adapted from Lean manufacturing approaches (e.g. the Toyota Production System).
•  Focus on optimizing the value chain, small batch sizes, minimize cycle time, automate
repetitive tasks, …
•  Agile methods fall under Lean …
References: http:/www.ornl.gov/8vt/readingList.html

Validation-Centric Approach (VCA):
Common Lifecycle Model for CSE Software
Central elements of validation-centric approach (VCA) lifecycle model
•  Develop the software by testing against real early-adopter customer applications
•  Manually verify the behavior against applications or other test cases
Advantages of the VCA lifecycle model:
•  Assuming customer validation of code is easy (i.e. linear or nonlinear algebraic equation
solvers => compute the residual) …
•  Can be very fast to initially create new code
•  Works for the customers code right away
Problems with the VCA lifecycle model:
•  Does now work well when validation is hard (i.e. ODE/DAE solvers where no easy to
compute global measure of error exists)
•  Re-validating against existing customer codes is expensive or is often lost (i.e. the
customer code becomes unavailable).
•  Difficult and expensive to refactor: Re-running customer validation tests is too expensive
or such tests are too fragile or inflexible (e.g. binary compatibility tests)
11VCA lifecycle model often leads to unmaintainable codes that are later abandoned!

Overview of the

TriBITS Lifecycle Model


Goals for the TriBITS Lifecycle Model
•  Allow Exploratory Research to Remain Productive: Only minimal practices for
basic research in early phases
•  Enable Reproducible Research: Minimal software quality aspects needed for
producing credible research, researches will produce better research that will stand
a better chance of being published in quality journals that require reproducible
research.
•  Improve Overall Development Productivity: Focus on the right SE practices at
the right times, and the right priorities for a given phase/maturity level, developers
work more productively with acceptable overhead.
•  Improve Production Software Quality: Focus on foundational issues first in early-
phase development, higher-quality software will be produced as other elements of
software quality are added.
•  Better Communicate Maturity Levels with Customers: Clearly define maturity
levels so customers and stakeholders will have the right expectations.


Defined: Self-Sustaining Software
•  Open-source: The software has a sufficiently loose open-source license allowing the
source code to be arbitrarily modified and used and reused in a variety of contexts
(including unrestricted usage in commercial codes).
•  Core domain distillation document: The software is accompanied with a short focused
high-level document describing the purpose of the software and its core domain model.
•  Exceptionally well testing: The current functionality of the software and its behavior is
rigorously defined and protected with strong automated unit and verification tests.
•  Clean structure and code: The internal code structure and interfaces are clean and
consistent.
•  Minimal controlled internal and external dependencies: The software has well
structured internal dependencies and minimal external upstream software dependencies
and those dependencies are carefully managed.
•  Properties apply recursively to upstream software: All of the dependent external
upstream software are also themselves self-sustaining software.
•  All properties are preserved under maintenance: All maintenance of the software
preserves all of these properties of self-sustaining software (by applying Agile/Emergent
Design and Continuous Refactoring and other good Lean/Agile software development
14 practices).

TriBITS Lifecycle Maturity Levels

0: Exploratory (EP) Code

1: Research Stable (RS) Code

2: Production Growth (PG) Code

3: Production Maintenance (PM) Code

-1: Unspecified Maturity (UM) Code


0: Exploratory (EP) Code
•  Primary purpose is to explore alternative approaches and prototypes, not to create
software.
•  Generally not developed in a Lean/Agile consistent way.
•  Does not provide sufficient unit (or otherwise) testing to demonstrate correctness.
•  Often has a messy design and code base.
•  Should not have customers, not even “friendly” customers.
•  No one should use such code for anything important (not even for research results,
but in the current CSE environment the publication of results using such software
would likely still be allowed).
•  Generally should not go out in open releases (but could go out in releases and is
allowed by this lifecycle model).
•  Does not provide a direct foundation for creating production-quality code and should
be put to the side or thrown away when starting product development


1: Research Stable (RS) Code
•  Developed from the very beginning in a Lean/Agile consistent manner.
•  Strong unit and verification tests (i.e. proof of correctness) are written as the code/
algorithms are being developed (near 100% line coverage).
•  Has a very clean design and code base maintained through Agile practices of
emergent design and constant refactoring.
•  Generally does not have higher-quality documentation, user input checking and
feedback, space/time performance, portability, or acceptance testing.
•  Would tend to provide for some regulated backward compatibility but might not.
•  Is appropriate to be used only by “expert” users.
•  Is appropriate to be used only in “friendly” customer codes.
•  Generally should not go out in open releases (but could go out in releases and is
allowed by this lifecycle model).
•  Provides a strong foundation for creating production-quality software and should be
the first phase for software that will likely become a product.
•  Supports reproducible research.

2: Production Growth (PG) Code
•  Includes all the good qualities of Research Stable code.
•  Provides increasingly improved checking of user input errors and better error
reporting.
•  Has increasingly better formal documentation (Doxygen, technical reports, etc.) as
well as better examples and tutorial materials.
•  Maintains clean structure through constant refactoring of the code and user
interfaces to make more consistent and easier to maintain.
•  Maintains increasingly better regulated backward compatibility with fewer
incompatible changes with new releases.
•  Has increasingly better portability and space/time performance characteristics.
•  Has expanding usage in more customer codes.


3: Production Maintenance (PM) Code
•  Includes all the good qualities of Production Growth code.
•  Primary development includes mostly just bug fixes and performance tweaks.
•  Maintains rigorous backward compatibility with typically no deprecated features or
any breaks in backward compatibility.
•  Could be maintained by parts of the user community if necessary (i.e. as “self-
sustaining software”).

-1: Unspecified Maturity (UM) Code
•  Provides no official indication of maturity or quality
•  i.e. “Opt Out” of the TriBITS Lifecycle Model


Typical non-Agile (i.e. VCA) CSE Lifecycle
Unit and Verification Testing Acceptance Testing Portability

Research Production Production Research Production Production Research Production Production
Growth Maintenance Growth Maintenance
Growth Maintenance

Code and Design Clarity Documentation and Tutorials Space/Time Performance

Growth Maintenance Growth Maintenance Growth Maintenance

User Input Checking and Feedback Backward compatibility Cost per new feature

Growth Maintenance Growth Maintenance Growth Maintenance

Time

Pure Lean/Agile Lifecycle: “Done Done”



Time

Proposed TriBITS Lean/Agile Lifecycle

Stable Growth Maintenance Stable Stable Growth Maintenance
Growth Maintenance


Stable Growth Maintenance Stable Growth Maintenance Stable Growth Maintenance


Stable Growth Maintenance Stable Growth Maintenance Stable Growth Maintenance

for the U.S. Department of Energy
Time Presentation_name

End of Life?

Long-term maintenance and end of life issues for Self-Sustaining Software:
•  User community can help to maintain it
•  If the original development team is disbanded, users can take parts they are using
and maintain it long term
•  Can stop being built and tested if not being currently used
•  However, if needed again, software can be resurrected, and continue to be
maintained

NOTE: Distributed version control using tools like Git and Mercurial greatly help in
reducing risk and sustaining long lifetime.


Usefulness Maturity and Lifecycle Phases
•  NOTE: For research-driven software achieving “Done Done” for unproven algorithms
and method is not reasonable!
•  CSE Software should only be pushed to higher maturity levels if the software,
methods, etc. have proven to be “Useful”.
Definition of “Usefulness”:
•  The algorithms and methods implemented in the software have been shown to
effectively address a given class of problems, and/or
•  A given piece of software or approach makes a customer produce higher quality
results, and/or
•  Provides some other measure of value


Addressing existing Legacy Software?

•  Our definition of “Legacy Software”: Software that is too far from away from being
Self-Sustaining Software, i.e:
–  Open-source
–  Core domain distillation document
–  Exceptionally well testing
–  Clean structure and code
–  Minimal controlled internal and external dependencies
–  Properties apply recursively to upstream software

•  Question: What about all the existing “Legacy” Software that we have to continue to
develop and maintain? How does this lifecycle model apply to such software?

•  Answer: Grandfather them into the TriBITS Lifecycle Model by applying the Legacy
Software Change Algorithm!


Grandfathering of Existing Packages
Agile Legacy Software Change Algorithm:
1. Identify Change Points
2. Break Dependencies
3. Cover with Unit Tests
4. Add New Functionality with Test Driven Development (TDD)
5. Refactor to removed duplication, clean up, etc.
Grandfathered Lifecycle Phases:
Cost per new feature
1. Grandfathered Research Stable (GRS) Code
2. Grandfathered Production Growth (GPG) Code
3. Grandfathered Production Maintenance (GPM) Code
NOTE: After enough iterations of the Legacy
Software Change Algorithm the software may
Grandfathered Production
approach Self-Sustaining software and be able Legacy
Code Production Maintenance
Maintenance
to remove the “Grandfathered” prefix!

What are the Next Steps?
•  Get Trilinos to adopt the TriBITS lifecycle model:
–  Feedback from a survey of Trilinos developers seems to show they support the adoption of the
TriBITS lifecycle model.
–  Will push at the Trilinos Users Group Meeting in November 2012
•  Get CASL to adopt the TriBITS Lifecycle Model:
–  Use the vocabulary of the TriBITS Lifecycle Model.
–  Encourage CASL developers to apply the Legacy Software Change Algorithm when changing existing
CASL legacy codes.
–  Encourage CASL developers to use test-driven development and write clean code.
•  How do we teach developers the core software skills needed to create Self-
Sustaining Software?
–  Examples: unit testing, test driven development, structured incremental refactoring, Agile-emergent
design, collaborative development (code reviews), etc.
•  How do we teach developers how to apply the Legacy Software Change Algorithm?
–  Conduct a reading group for “Working Effectively with Legacy Code”?
–  Look at online webinars/presentations?
–  Day-long and multi-day hands-on workshops?
–  Start by teaching a set of mentors that with then teach other developers? (i.e. this is the Lean
approach).

Summary of TriBITS Lifecycle Model
•  Motivation:
–  Allow Exploratory Research to Remain Productive
–  Enable Reproducible Research
–  Improve Overall Development Productivity
–  Improve Production Software Quality
–  Better Communicate Maturity Levels with Customers
•  Self Sustaining Software => The Goal of the TriBITS Lifecycle Model
–  Open-source
–  Core domain distillation document
–  Exceptionally well testing
–  Clean structure and code
–  Minimal controlled internal and external dependencies
–  Properties apply recursively to upstream software
–  All properties are preserved under maintenance
•  Lifecycle Phases:
–  0: Exploratory (EP) Code
–  1: Research Stable (RS) Code
–  2: Production Growth (PG) Code
–  3: Production Maintenance (PM) Code
•  Grandfathering existing Legacy packages into the lifecycle model:
–  Apply Legacy Software Change Algorithm => Slowly becomes Self-Sustaining Software over time.
–  Add “Grandfathered” prefix to RS, PG, and PM phases.

Overview of the TriBITS Lifecycle Model

More Related Content

What's hot (16)

Viewers also liked (16)

Similar to Overview of the TriBITS Lifecycle Model (20)

Overview of the TriBITS Lifecycle Model