Download - 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
IBM Software Group | Rational software
Why Component Based Development?
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
IBM Software Group | Rational software
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
IBM Software Group | Rational software
Agenda
Why Component Based Development?
How are reused components represented in Synergy?
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
IBM Software Group | Rational software
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
IBM Software Group | Rational software
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
IBM Software Group | Rational software
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.
IBM Software Group | Rational software
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
IBM Software Group | Rational software
Incremental Update – Workflow example
B V3.1 development
B-Mary B-Ed
Collaborative Development Collaborative Development
C V8.2 development
C-Chris C-Nancy
Collaborative Development Collaborative Development
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
Collaborative Development
A V1.2 development
IBM Software Group | Rational software
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
Modifiable By: Build Managers
Query:
In State: task_automatic
For Release: C/V8.2
Custom: member_status=”integrate”
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
Collaborative Development
A V1.2 development
IBM Software Group | Rational software
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.
IBM Software Group | Rational software
Incremental Update with active development of subcomponents – Workflow example
B V3.1 development
B-Mary B-Ed
Collaborative Development Collaborative Development
C V8.2 development
C-Chris C-Nancy
Collaborative Development Collaborative DevelopmentA-v1.2int
B-v3.1int C-v8.2int
A V1.2 integrationIntegration Testing
Integration TestingIntegration Testing
A-John
B-John C-v8.2int
Collaborative Development
A-Patrick
B-v3.1int C-v8.2int
Collaborative Development
A V1.2 development
CollaborativeDevelopment for B/V3.1
IBM Software Group | Rational software
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:
In State: task_automatic
For Release: B/V3.1
With Resolver: %owner
Custom: member_status=”collaborative”
A-v1.2int
B-v3.1int C-v8.2int
A V1.2 integrationIntegration Testing
Integration TestingIntegration Testing
A-John
B-John C-v8.2int
Collaborative Development for A/V1.2
A-Patrick
B-v3.1int C-v8.2int
Collaborative Development
A V1.2 development
CollaborativeDevelopment for B/V3.1
IBM Software Group | Rational software
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
IBM Software Group | Rational software
Incremental Update from published baselines – Workflow example
B V3.1 development
B-Mary B-Ed
Collaborative Development Collaborative Development
C V8.2 development
C-Chris C-Nancy
Collaborative Development Collaborative Development
A-v1.2int
B-v3.1Latest C-v8.2Latest
A V1.2 integrationIntegration Testing
Integration TestingIntegration Testing
A-John
B-v3.1Latest C-v8.2Latest
Collaborative Development
A-Patrick
B-v3.1Latest C-v8.2Latest
Collaborative Development
A V1.2 development
B-v3.1int
Integration Testing
B-V3.1bas
C-v8.2int
IBM Software Group | Rational software
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
IBM Software Group | Rational software
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
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 Latest baseline release
Modifiable By: Build Managers
Query:
In State: task_automatic
For Release: C/V8.2
Custom: member_status=”integrate”
A-v1.2int
B-v3.1Latest C-v8.2Latest
A V1.2 integrationIntegration Testing
Integration TestingIntegration Testing
A-John
B-v3.1Latest C-v8.2Latest
Collaborative Development
A-Patrick
B-v3.1Latest C-v8.2Latest
Collaborative Development
A V1.2 development
IBM Software Group | Rational software
CM Process Patterns summary
Controlled Update
Incremental Update from published baselines
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
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 in a single development stream
Component Hierarchy and Multi-layer Development Streams
Collaboration on a Shared Component Repository
IBM Software Group | Rational software
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
…
… …
…
IBM Software Group | Rational software
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.
IBM Software Group | Rational software
CBD in a single development stream - the process (2)
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
IBM Software Group | Rational software
CBD in a single development stream - the process (3)
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
IBM Software Group | Rational software
CBD in a single development stream - the process (3)
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
IBM Software Group | Rational software
T0+14 d
CBD in a single development stream - the process (3)
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.
requirementsdevelopmenttest
Iteration i
Iteration i+1requirementsdevelopmenttest
T0 T0+10d
IBM Software Group | Rational software
T0+20d
CBD in a single development stream - the process (3)
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
requirementsdevelopmenttest
Iteration i
Iteration i+1requirementsdevelopmenttest
T0 T0+10d
T0+24 d
IBM Software Group | Rational software
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.
IBM Software Group | Rational software
CM Process Patterns summary
Controlled Update
Incremental Update from published baselines
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
CBD in a single development stream
IBM Software Group | Rational software
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.
Component A Component B Component ZComponent X Component Y
Sub-System I Sub-System J
Platform P1 Platform Pn
Product
…
… …
…
Layer 1
Layer 2
Layer 3
IBM Software Group | Rational software
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.
Component A Component B Component ZComponent X Component Y
Sub-System I Sub-System J
Platform P1 Platform Pn
Product
…
… …
…
Layer 1
Layer 2
Layer 3
IBM Software Group | Rational software
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
Component A Component B Component ZComponent X Component Y
Sub-System I Sub-System J
Platform P1 Platform Pn
Product
…
… …
…
Layer 1
Layer 2
Layer 3
IBM Software Group | Rational software
CM Process Patterns summary
Controlled Update
Incremental Update from published baselines
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
Component Hierarchy and multi-layereddevelopment streams
IBM Software Group | Rational software
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.
IBM Software Group | Rational software
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
IBM Software Group | Rational software
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
IBM Software Group | Rational software
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
IBM Software Group | Rational software
CM Process Patterns summary
Controlled Update
Incremental Update from published baselines
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
Shared Components repositoryCollaborative process - Consumer
Shared Components repositoryCollaborative process - Committer
IBM Software Group | Rational software
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
IBM Software Group | Rational software
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
B V1.0 B V1.1 Committer
Contributor AB xx
B yy Consumer B
IBM Software Group | Rational software
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 V1.0 B V1.1 Committer
B xx
B yy Consumer B
B V1.2
MergeB yy’
Contributor A
Contributor B
IBM Software Group | Rational software
CM Process Patterns summary
Controlled Update
Incremental Update from published baselines
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
Shared Components repositoryCollaborative process - Consumer
Shared Components repositoryCollaborative process – Consumerand Contributor
IBM Software Group | Rational software
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
IBM Software Group | Rational software
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