synergy tech software reuse with cbd

®

IBM Software Group

© 2008 IBM Corporation

Best Practices for Component Based Development with Synergy

Telelogic Federal, Aerospace & Defense

IBM Software Group | Rational software

Agenda

Why Component Based Development?

How are reused components represented in Synergy?

CM process patterns for CBD

Customer examples of advanced CBD practices



Component Based Development (CBD) helps organizations:

Manage Complexity

Complex systems

The skills and knowledge needed to develop system component lies in different and possibly distributed teams

Reuse – Product Line Engineering – SW Product Lines

Common components shared across multiple products

Service Oriented Architecture

Application integration

Note: For more details refer to the Synergy_Sales_Software Reuse with CBD v1.0.ppt


How are reused components represented?

As a file (a product file) Library files

JAR files

As a Synergy project Application A version v1.1 uses 2 components

B version V3

C version V7.1

Component hierarchy is then represented as a Synergy project hierarchy

A-v1.1

B-v3 C-v7.1


Agenda



CM process patterns for CBD Using the out-of-the-box Task Based workflow

Controlled Update

Workflow Variants

Incremental Update

Incremental Update with active development of sub-components

Incremental Update from published baselines

Customer examples of advanced CBD practices


Component Based DevelopmentControlled Update

Each component has its own development/release cycle

Each component is maintained by a specific development team

Component consumers reuse static versions of components

Task Based workflow

Assign a task to use a new sub-component static version

The Developer…

selects the assigned task,

attaches the new sub-component version to the task,

performs the necessary changes and tests,

completes the task.

A-v1.1

B-v3 C-v7.1

A-V1.2int

B-v3 C-v7.1

A-Patrick

B-v3 C-v7.1

A-John

B-v3 C-v7.1

A V1.2 development

C-v8.2

All completed A/v1.2 tasks


A-Patrick

B-v3 C-v7.1

A-V1.2int

B-v3 C-v7.1

Component Based DevelopmentControlled Update

Each component has its own development/release cycle

Each component is maintained by a specific development team

Component consumers reuse static versions of components

Task Based workflow

Assign a task to use a new sub-component static version

The Developer…

selects the assigned task,

attaches the new sub-component version to the task,

performs the necessary changes and tests,

completes the task.

When the task is completed it follows the workflow like any other task

A-John

B-v3 C-v7.1

A V1.2 development

C-v8.2

All completed A/v1.2 tasks

C-v8.2

C-v8.2

A-v1.1

B-v3 C-v7.1


The Controlled Updated: summary

Works with standard process rules

Good for managing systems that are configured by combining specific versions of many different components.

Clear separation between the component committer (responsible for creating the new versions of the component) and the possibly numerous component consumers Not ideal for teams who work closely on enhancing different “layers” for the same delivery,

who want to integrate and test incremental changes on a regular basis.


Incremental Update

Closer relationship between the component committer and the component consumer(s) Less likely to have many consumers

Each component team works on their component

One common integration space for integrating all completed changes for all components Rapid integration cycles


Incremental Update – Workflow example

B V3.1 development

B-Mary B-Ed

Collaborative Development Collaborative Development

C V8.2 development

C-Chris C-Nancy


A-v1.2int

B-v3.1int C-v8.2int

A V1.2 integrationIntegration Testing

Integration TestingIntegration Testing

A-John

B-v3.1int C-v8.2int

Collaborative Development

A-Patrick

B-v3.1int C-v8.2int


A V1.2 development


Incremental updateModified Process Rules for Component A

Integration Testing and Collaborative Development process rules for Component A include 2 folders:

Integration testing project tasks for B/V3.1 release

Modifiable By: Build Managers

Query:

In State: task_automatic

For Release: B/V3.1

Custom: member_status=”integrate”

Integration testing project tasks for C/V8.2 release


Query:


For Release: C/V8.2


A-v1.2int

B-v3.1int C-v8.2int



A-John

B-v3.1int C-v8.2int


A-Patrick

B-v3.1int C-v8.2int


A V1.2 development


Incremental update

Good for teams whose components changes are often developed specifically for a customer, either internal (for example, testing) or external (for example, a third-party tool vendor) or work in a tightly coupled product.

Not ideal for teams who want to explicitly control the component versions they use and when they upgrade to new versions. It is also not recommended for applications that are built by combining specific releases of many different components where compatibility between the component versions is difficult to test.


Incremental Update with active development of subcomponents – Workflow example

B V3.1 development

B-Mary B-Ed


C V8.2 development

C-Chris C-Nancy

Collaborative Development Collaborative DevelopmentA-v1.2int

B-v3.1int C-v8.2int



A-John

B-John C-v8.2int


A-Patrick

B-v3.1int C-v8.2int


A V1.2 development

CollaborativeDevelopment for B/V3.1


Incremental update with active development of subcomponents

Variant of the previous process where developers of the consuming components want to have the possibility to update the consumed components The Consumer is also a Contributor

Collaborative Development process rules for Component A has a complementary folder:

Project Task for %owner for B/V3.1 release

Modifiable By: Owner

Query:


For Release: B/V3.1

With Resolver: %owner

Custom: member_status=”collaborative”

A-v1.2int

B-v3.1int C-v8.2int



A-John

B-John C-v8.2int

Collaborative Development for A/V1.2

A-Patrick

B-v3.1int C-v8.2int


A V1.2 development

CollaborativeDevelopment for B/V3.1


Incremental update from published baselines

Variant of the incremental update where only sub-component baselines are used by the consumer

Enable an Application to consume a published baseline of a component

Insulates the Application from unstable component changes until they have been tested and baselined


Incremental Update from published baselines – Workflow example

B V3.1 development

B-Mary B-Ed


C V8.2 development

C-Chris C-Nancy


A-v1.2int

B-v3.1Latest C-v8.2Latest



A-John



A-Patrick



A V1.2 development

B-v3.1int

Integration Testing

B-V3.1bas

C-v8.2int


Incremental Update from Published baselines – Set-Up

Create a new process rule: Latest Baseline Purpose: Latest baseline

Baseline:

Latest baseline

With release and purpose: %baseline_release, Integration Testing

With release and purpose: %baseline_release, Any

Task: None

Create a new release for Component B called B/V3.1Latest baseline

From release B/V3.1

With a single process rule: Latest Baseline

Create a new release for Component C called C/V8.2Latest baseline

From release C/V8.2

With a single process rule: Latest Baseline


Incremental update from published baselinesModified Process Rules for Component A

Integration Testing and Collaborative Development process rules for Component A include 2 folders:

Integration testing project tasks for B/V3.1 Latest baseline release


Query:


For Release: B/V3.1


Integration testing project tasks for C/V8.2 Latest baseline release


Query:


For Release: C/V8.2


A-v1.2int




A-John



A-Patrick



A V1.2 development


CM Process Patterns summary

Controlled Update


Incremental Update

Incremental Update with active development of subcomponents

Use of a single release (no project hierarchy with multiple releases)

StabilityLarge number of consumers

SpeedCollaborative WorkLimited number of

consumers


Agenda



CM process patterns for CBD

Customer examples of advanced CBD practices Component Based Development in a single development stream

Component Hierarchy and Multi-layer Development Streams

Collaboration on a Shared Component Repository


Component Hierarchy developed in a single development stream

When should you use this approach?

Specific teams in the organization have the component expertise (“expert” teams own key business components),

Requirements for a component can be managed in a single development stream,

Evolutions of the component hierarchy can be synchronized in a single common development stream

Component A Component B Component ZComponent X Component Y

Sub-System I Sub-System J

Platform P1 Platform Pn

Product

…

… …

…


CBD in a single development stream - the process (1)

Agile Requirements Management: Functional Requirements for an iteration are identified using an Agile

Requirements Management process with requirement prioritization,

The definition of the requirements for the next iteration is done in parallel with the development activities for the previous iteration.



Component development:

Development tasks are assigned to the development team at the beginning of the new iteration development phase:

The development team is organized into sub-teams working on different software components for greater scalability and efficiency,

The Project manager monitors the progress of the development team members in regards of their objectives and makes the necessary adjustments to ensure that the development goals will be achieved



Continuous integration and testing The software is continuously rebuilt and tested to speed up the development

process while maintaining a consistent and stable software configuration,

Developers work on a stable software configuration that they can update on a frequent basis to get the latest integration stage

The rapid integration cycle limits the number of parallel and concurrent versions



Freezing a baseline At the end of an iteration (for instance, after 10 days of development), the

release content is decided by the Release Control Board, and only approved tasks go through the software iteration qualification and release process.

A software baseline is created and the development of the next iteration starts immediately

requirementsdevelopmenttest

Iteration i

Iteration i+1requirementsdevelopmenttest

T0 T0+10d


T0+14 d


Quality assurance

The QA & release cycle activities (2-4 days) are performed in parallel to the development activities for the next iteration

Verify the quality of the iteration through appropriate functional and operational testing,

Make the necessary hot fixes which may require developer intervention,

Release the SW iteration.


Iteration i


T0 T0+10d


T0+20d


Releasing the component An iteration is released every 10 days,

It usually takes 12 to 14 days from the decision on requirements implementation, or on defects to fix, to release

T0+14 d


Iteration i


T0 T0+10d

T0+24 d


CBD in a single development streamConclusion This development process avoids development team downtime:

Developers are always working towards the “next” iteration;

They do not have to worry in which SW iterations their tasks are going to be included,

They do not have to worry about creating new development workspaces for the next iteration development

There are no interruptions of development activities between 2 development iterations,

Every 2 weeks during the 2-4 days of the iteration release process developers may be asked to perform a hot fix,

They work in a hot fix environment.



Controlled Update


Incremental Update





consumers

CBD in a single development stream


Component hierarchy and multi-layered development streams

The context:

Components may have a different release cycle from their consumers.

Often the case when components have many consumers and complex dependency relationships,

It is not possible to coordinate the evolution of the SW product and its entire component set in a single development stream.

It is difficult to pull a build together because the dependencies between the components are often broken.




Product

…

… …

…

Layer 1

Layer 2

Layer 3


Component hierarchy and multi-layered development streams (2)

Multi-layer component stream: An development stream can correspond to a single component, or correspond to a

group of components that evolve together,

Each component is modified in a single development stream

A hierarchy of development streams defines the workflow of changes through bottom-up promotion path: changes performed in lower level components are promoted to their higher level consumers.




Product

…

… …

…

Layer 1

Layer 2

Layer 3


Component hierarchy and multi-layered development streams (3)

When should you use this approach? The Components developed have many consumers

Components have independent and possibly uncoordinated release development cycles

Requirements for each Component can be centralized and prioritized

For each component there is a dedicated team with complete responsibility




Product

…

… …

…

Layer 1

Layer 2

Layer 3



Controlled Update


Incremental Update





consumers

Component Hierarchy and multi-layereddevelopment streams


Shared Component Repository

Context In the previous models, each component is generally owned by a specific

team, which controls its evolutions and implements the requirements of the components consumer.

This approach lacks flexibility when organizations developing families of products need to be more reactive to customer requests.


Shared Component RepositoryCollaborative Process When should you use this approach?

The Organization is developing product families that share a common set of components,

There are independent projects that reuse and possibly require modifications on shared components,

It is not possible for a central team maintaining the shared components to cope with the change and adaptation requests,

Project managers want full control on everything on the path to releasing their product,

There is a strong focus on project execution, shared components must not get in the way of delivering the projects,

The organization is open to new development techniques such as those established in the Open Source community, and accept coordination of shared components changes,

Ideally, projects have the skills to update shared components or have temporary access to resources with the appropriate skills


Shared Component RepositoryCollaborative Process (2)

Principles: No dedicated team for the shared components,

No (permanent) component ownership,

Component Customers that find bugs, need new features, new components, become contributors to the Consumed Components,

When changes to a component are performed and verified they are published on the repository, so they become available for the other projects.

An Architecture Board composed of the architects from the various customers & contributors defines and updates the roadmap for the shared component: What is / What should / What will be in the repository

What is required for components / Who will use them


Shared Component RepositoryCollaborative Process (3)

An Executive Board decides which project can modify a component and helps avoid unnecessary parallel modifications: Explicit separation between component interfaces and implementation

Permission to fix the implementation does not give the right to modify the interface

B V1.0 B V1.1

B xx Committer A

Consumer B

B V1.2

B yy

B V1.3

Consumer A

Committer B



Controlled Update


Incremental Update





consumers

Shared Components repositoryCollaborative process - Consumer

Shared Components repositoryCollaborative process - Committer


Shared Component RepositoryOpen Source Like Process Variant

Each Component is still “owned” by a team: the committer

Each consumer has the right to modify the component for its own needs Bug fixes

New features

B V1.0 B V1.1 Committer

Consumer AB xx

B yy Consumer B


Shared Component RepositoryOpen Source Like Process Variant (2)

Each consumer team modifying the component can propose their changes to the “committer” who can decide to accept them or not (guideline defining criteria for having the changes accepted are published ).

Consumers are now contributors


Contributor AB xx

B yy Consumer B


Shared Component RepositoryOpen Source Like Process Variant (3)

Committer can now release more often and with more content as he gets input from contributors

Consumers get new versions of the components and have to merge their own specific changes into the new version


B xx

B yy Consumer B

B V1.2

MergeB yy’

Contributor A

Contributor B



Controlled Update


Incremental Update





consumers

Shared Components repositoryCollaborative process - Consumer

Shared Components repositoryCollaborative process – Consumerand Contributor


References

More info on how to set-up CM process patterns is provided in a new training course: “Synergy – Process tailoring”

White Papers “Software reuse with successful CBD v1.4 02202008”

Software Reuse for Business Success

A Framework for Managing Component Based Development - 040915

To-the-Point guide: Synergy_CBD_TTP_02202008

Success Story: SYN_SS_PrintingTechConglomerate_FINAL_080228

Demo script: SYNERGY_CBD_Demo_script_02042008

All the above resources can be found on SC2


44

© Copyright IBM Corporation 2008. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.

Learn more at: IBM Rational software IBM Rational Software Delivery Platform Process and portfolio management Change and release management Quality management Architecture management

Rational trial downloads Leading Innovation Web site developerWorks Rational IBM Rational TV IBM Business Partners IBM Rational Case Studies

synergy tech software reuse with cbd

Technology