Your SlideShare is downloading. ×
0
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Synergy Tech Software Reuse With Cbd
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Synergy Tech Software Reuse With Cbd

808

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
808
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
24
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Standard template for internal and external Rational presentations. If internal presentations are confidential, please add: “IBM Confidential” to the slide masters. Select: View / Master / Slide Master and add “IBM Confidential”
  • Transcript

    • 1. Best Practices for Component Based Development with Synergy Telelogic Federal, Aerospace & Defense
    • 2. Agenda <ul><li>Why Component Based Development? </li></ul><ul><li>How are reused components represented in Synergy? </li></ul><ul><li>CM process patterns for CBD </li></ul><ul><li>Customer examples of advanced CBD practices </li></ul>
    • 3. Why Component Based Development? <ul><li>Component Based Development (CBD) helps organizations: </li></ul><ul><li>Manage Complexity </li></ul><ul><ul><ul><li>Complex systems </li></ul></ul></ul><ul><ul><ul><li>The skills and knowledge needed to develop system component lies in different and possibly distributed teams </li></ul></ul></ul><ul><li>Reuse – Product Line Engineering – SW Product Lines </li></ul><ul><ul><ul><li>Common components shared across multiple products </li></ul></ul></ul><ul><li>Service Oriented Architecture </li></ul><ul><ul><ul><li>Application integration </li></ul></ul></ul>Note: For more details refer to the Synergy_Sales_Software Reuse with CBD v1.0.ppt
    • 4. How are reused components represented? <ul><li>As a file (a product file) </li></ul><ul><ul><li>Library files </li></ul></ul><ul><ul><li>JAR files </li></ul></ul><ul><li>As a Synergy project </li></ul><ul><ul><li>Application A version v1.1 uses 2 components </li></ul></ul><ul><ul><ul><li>B version V3 </li></ul></ul></ul><ul><ul><ul><li>C version V7.1 </li></ul></ul></ul><ul><ul><li>Component hierarchy is then represented as a Synergy project hierarchy </li></ul></ul>A-v1.1 B-v3 C-v7.1
    • 5. Agenda <ul><li>Why Component Based Development? </li></ul><ul><li>How are reused components represented in Synergy? </li></ul><ul><li>CM process patterns for CBD </li></ul><ul><ul><li>Using the out-of-the-box Task Based workflow </li></ul></ul><ul><ul><ul><li>Controlled Update </li></ul></ul></ul><ul><ul><li>Workflow Variants </li></ul></ul><ul><ul><ul><li>Incremental Update </li></ul></ul></ul><ul><ul><ul><li>Incremental Update with active development of sub-components </li></ul></ul></ul><ul><ul><ul><li>Incremental Update from published baselines </li></ul></ul></ul><ul><li>Customer examples of advanced CBD practices </li></ul>
    • 6. Component Based Development Controlled Update <ul><li>Each component has its own development/release cycle </li></ul><ul><li>Each component is maintained by a specific development team </li></ul><ul><li>Component consumers reuse static versions of components </li></ul><ul><li>Task Based workflow </li></ul><ul><ul><li>Assign a task to use a new sub-component static version </li></ul></ul><ul><ul><li>The Developer… </li></ul></ul><ul><ul><ul><li>selects the assigned task, </li></ul></ul></ul><ul><ul><ul><li>attaches the new sub-component version to the task, </li></ul></ul></ul><ul><ul><ul><li>performs the necessary changes and tests, </li></ul></ul></ul><ul><ul><ul><li>completes the task. </li></ul></ul></ul>A-John B-v3 C-v7.1 A V1.2 development All completed A/v1.2 tasks A-v1.1 B-v3 C-v7.1 A-V1.2int B-v3 C-v7.1 A-Patrick B-v3 C-v7.1 C-v8.2
    • 7. Component Based Development Controlled Update <ul><li>Each component has its own development/release cycle </li></ul><ul><li>Each component is maintained by a specific development team </li></ul><ul><li>Component consumers reuse static versions of components </li></ul><ul><li>Task Based workflow </li></ul><ul><ul><li>Assign a task to use a new sub-component static version </li></ul></ul><ul><ul><li>The Developer… </li></ul></ul><ul><ul><ul><li>selects the assigned task, </li></ul></ul></ul><ul><ul><ul><li>attaches the new sub-component version to the task, </li></ul></ul></ul><ul><ul><ul><li>performs the necessary changes and tests, </li></ul></ul></ul><ul><ul><ul><li>completes the task. </li></ul></ul></ul><ul><ul><li>When the task is completed it follows the workflow like any other task </li></ul></ul>A-John B-v3 C-v7.1 A V1.2 development All completed A/v1.2 tasks A-Patrick B-v3 C-v7.1 A-V1.2int B-v3 C-v7.1 C-v8.2 C-v8.2 C-v8.2 A-v1.1 B-v3 C-v7.1
    • 8. The Controlled Updated: summary <ul><li>Works with standard process rules </li></ul><ul><li>Good for managing systems that are configured by combining specific versions of many different components. </li></ul><ul><li>Clear separation between the component committer (responsible for creating the new versions of the component) and the possibly numerous component consumers </li></ul><ul><ul><li>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. </li></ul></ul>
    • 9. Incremental Update <ul><li>Closer relationship between the component committer and the component consumer(s) </li></ul><ul><ul><li>Less likely to have many consumers </li></ul></ul><ul><li>Each component team works on their component </li></ul><ul><li>One common integration space for integrating all completed changes for all components </li></ul><ul><ul><li>Rapid integration cycles </li></ul></ul>
    • 10. 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 integration Integration Testing Integration Testing Integration 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
    • 11. Incremental update Modified Process Rules for Component A <ul><li>Integration Testing and Collaborative Development process rules for Component A include 2 folders: Integration testing project tasks for B/V3.1 release </li></ul><ul><ul><li>Modifiable By : Build Managers </li></ul></ul><ul><ul><li>Query : </li></ul></ul><ul><ul><ul><li>In State: task_automatic </li></ul></ul></ul><ul><ul><ul><li>For Release: B/V3.1 </li></ul></ul></ul><ul><ul><ul><li>Custom: member_status=”integrate ” </li></ul></ul></ul><ul><li>Integration testing project tasks for C/V8.2 release </li></ul><ul><ul><li>Modifiable By : Build Managers </li></ul></ul><ul><ul><li>Query : </li></ul></ul><ul><ul><ul><li>In State: task_automatic </li></ul></ul></ul><ul><ul><ul><li>For Release: C/V8.2 </li></ul></ul></ul><ul><ul><ul><li>Custom: member_status=”integrate ” </li></ul></ul></ul>A-v1.2int B-v3.1int C-v8.2int A V1.2 integration Integration Testing Integration Testing Integration 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
    • 12. Incremental update <ul><li>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. </li></ul><ul><li>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. </li></ul>
    • 13. 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 Development A-v1.2int B-v3.1int C-v8.2int A V1.2 integration Integration Testing Integration Testing Integration Testing A-John B-John C-v8.2int Collaborative Development A-Patrick B-v3.1int C-v8.2int Collaborative Development A V1.2 development Collaborative Development for B/V3.1
    • 14. Incremental update with active development of subcomponents <ul><li>Variant of the previous process where developers of the consuming components want to have the possibility to update the consumed components </li></ul><ul><ul><li>The Consumer is also a Contributor </li></ul></ul><ul><li>Collaborative Development process rules for Component A has a complementary folder: Project Task for %owner for B/V3.1 release </li></ul><ul><ul><li>Modifiable By : Owner </li></ul></ul><ul><ul><li>Query : </li></ul></ul><ul><ul><ul><li>In State: task_automatic </li></ul></ul></ul><ul><ul><ul><li>For Release: B/V3.1 </li></ul></ul></ul><ul><ul><ul><li>With Resolver: %owner </li></ul></ul></ul><ul><ul><ul><li>Custom: member_status=”collaborative ” </li></ul></ul></ul>A-v1.2int B-v3.1int C-v8.2int A V1.2 integration Integration Testing Integration Testing Integration 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 Collaborative Development for B/V3.1
    • 15. Incremental update from published baselines <ul><li>Variant of the incremental update where only sub-component baselines are used by the consumer </li></ul><ul><ul><li>Enable an Application to consume a published baseline of a component </li></ul></ul><ul><ul><li>Insulates the Application from unstable component changes until they have been tested and baselined </li></ul></ul>
    • 16. 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 integration Integration Testing Integration Testing Integration 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 C-v8.2int B-V3.1bas
    • 17. Incremental Update from Published baselines – Set-Up <ul><li>Create a new process rule: Latest Baseline </li></ul><ul><ul><li>Purpose: Latest baseline </li></ul></ul><ul><ul><li>Baseline: </li></ul></ul><ul><ul><ul><li>Latest baseline </li></ul></ul></ul><ul><ul><ul><li>With release and purpose: %baseline_release, Integration Testing </li></ul></ul></ul><ul><ul><ul><li>With release and purpose: %baseline_release, Any </li></ul></ul></ul><ul><ul><li>Task: None </li></ul></ul><ul><li>Create a new release for Component B called B/V3.1Latest baseline </li></ul><ul><ul><li>From release B/V3.1 </li></ul></ul><ul><ul><li>With a single process rule: Latest Baseline </li></ul></ul><ul><li>Create a new release for Component C called C/V8.2Latest baseline </li></ul><ul><ul><li>From release C/V8.2 </li></ul></ul><ul><ul><li>With a single process rule: Latest Baseline </li></ul></ul>
    • 18. Incremental update from published baselines Modified Process Rules for Component A <ul><li>Integration Testing and Collaborative Development process rules for Component A include 2 folders: Integration testing project tasks for B/V3.1 Latest baseline release </li></ul><ul><ul><li>Modifiable By : Build Managers </li></ul></ul><ul><ul><li>Query : </li></ul></ul><ul><ul><ul><li>In State: task_automatic </li></ul></ul></ul><ul><ul><ul><li>For Release: B/V3.1 </li></ul></ul></ul><ul><ul><ul><li>Custom: member_status=”integrate ” </li></ul></ul></ul><ul><li>Integration testing project tasks for C/V8.2 Latest baseline release </li></ul><ul><ul><li>Modifiable By : Build Managers </li></ul></ul><ul><ul><li>Query : </li></ul></ul><ul><ul><ul><li>In State: task_automatic </li></ul></ul></ul><ul><ul><ul><li>For Release: C/V8.2 </li></ul></ul></ul><ul><ul><ul><li>Custom: member_status=”integrate ” </li></ul></ul></ul>A-v1.2int B-v3.1Latest C-v8.2Latest A V1.2 integration Integration Testing Integration Testing Integration 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
    • 19. CM Process Patterns summary <ul><li>Controlled Update </li></ul><ul><li>Incremental Update from published baselines </li></ul><ul><li>Incremental Update </li></ul><ul><li>Incremental Update with active development of subcomponents </li></ul><ul><li>Use of a single release (no project hierarchy with multiple releases) </li></ul>Stability Large number of consumers Speed Collaborative Work Limited number of consumers
    • 20. Agenda <ul><li>Why Component Based Development? </li></ul><ul><li>How are reused components represented in Synergy? </li></ul><ul><li>CM process patterns for CBD </li></ul><ul><li>Customer examples of advanced CBD practices </li></ul><ul><ul><li>Component Based Development in a single development stream </li></ul></ul><ul><ul><li>Component Hierarchy and Multi-layer Development Streams </li></ul></ul><ul><ul><li>Collaboration on a Shared Component Repository </li></ul></ul>
    • 21. Component Hierarchy developed in a single development stream <ul><li>When should you use this approach? </li></ul><ul><ul><li>Specific teams in the organization have the component expertise (“expert” teams own key business components), </li></ul></ul><ul><ul><li>Requirements for a component can be managed in a single development stream, </li></ul></ul><ul><ul><li>Evolutions of the component hierarchy can be synchronized in a single common development stream </li></ul></ul>Component A Component B Component Z Component X Component Y Sub-System I Sub-System J Platform P1 Platform Pn Product … … … …
    • 22. CBD in a single development stream - the process (1) <ul><li>Agile Requirements Management : </li></ul><ul><ul><li>Functional Requirements for an iteration are identified using an Agile Requirements Management process with requirement prioritization, </li></ul></ul><ul><ul><li>The definition of the requirements for the next iteration is done in parallel with the development activities for the previous iteration. </li></ul></ul>
    • 23. CBD in a single development stream - the process (2) <ul><li>Component development: </li></ul><ul><ul><li>Development tasks are assigned to the development team at the beginning of the new iteration development phase: </li></ul></ul><ul><ul><li>The development team is organized into sub-teams working on different software components for greater scalability and efficiency, </li></ul></ul><ul><ul><li>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 </li></ul></ul>
    • 24. CBD in a single development stream - the process (3) <ul><li>Continuous integration and testing </li></ul><ul><ul><li>The software is continuously rebuilt and tested to speed up the development process while maintaining a consistent and stable software configuration, </li></ul></ul><ul><ul><li>Developers work on a stable software configuration that they can update on a frequent basis to get the latest integration stage </li></ul></ul><ul><ul><li>The rapid integration cycle limits the number of parallel and concurrent versions </li></ul></ul>
    • 25. CBD in a single development stream - the process (3) <ul><li>Freezing a baseline </li></ul><ul><ul><li>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. </li></ul></ul><ul><ul><li>A software baseline is created and the development of the next iteration starts immediately </li></ul></ul>requirements development test Iteration i Iteration i+1 requirements development test T0 T0+10d
    • 26. CBD in a single development stream - the process (3) <ul><li>Quality assurance </li></ul><ul><ul><li>The QA & release cycle activities (2-4 days) are performed in parallel to the development activities for the next iteration </li></ul></ul><ul><ul><li>Verify the quality of the iteration through appropriate functional and operational testing, </li></ul></ul><ul><ul><li>Make the necessary hot fixes which may require developer intervention, </li></ul></ul><ul><ul><li>Release the SW iteration. </li></ul></ul>requirements development test Iteration i Iteration i+1 requirements development test T0 T0+14 d T0+10d
    • 27. CBD in a single development stream - the process (3) <ul><li>Releasing the component </li></ul><ul><ul><li>An iteration is released every 10 days, </li></ul></ul><ul><ul><li>It usually takes 12 to 14 days from the decision on requirements implementation, or on defects to fix, to release </li></ul></ul>requirements development test Iteration i Iteration i+1 requirements development test T0 T0+20d T0+14 d T0+10d T0+24 d
    • 28. CBD in a single development stream Conclusion <ul><li>This development process avoids development team downtime: </li></ul><ul><ul><li>Developers are always working towards the “next” iteration; </li></ul></ul><ul><ul><ul><li>They do not have to worry in which SW iterations their tasks are going to be included, </li></ul></ul></ul><ul><ul><ul><li>They do not have to worry about creating new development workspaces for the next iteration development </li></ul></ul></ul><ul><ul><li>There are no interruptions of development activities between 2 development iterations, </li></ul></ul><ul><ul><li>Every 2 weeks during the 2-4 days of the iteration release process developers may be asked to perform a hot fix, </li></ul></ul><ul><ul><ul><li>They work in a hot fix environment. </li></ul></ul></ul>
    • 29. CM Process Patterns summary <ul><li>Controlled Update </li></ul><ul><li>Incremental Update from published baselines </li></ul><ul><li>Incremental Update </li></ul><ul><li>Incremental Update with active development of subcomponents </li></ul><ul><li>Use of a single release (no project hierarchy with multiple releases) </li></ul>Stability Large number of consumers Speed Collaborative Work Limited number of consumers CBD in a single development stream
    • 30. Component hierarchy and multi-layered development streams <ul><li>The context: </li></ul><ul><ul><li>Components may have a different release cycle from their consumers. </li></ul></ul><ul><ul><ul><li>Often the case when components have many consumers and complex dependency relationships, </li></ul></ul></ul><ul><ul><ul><li>It is not possible to coordinate the evolution of the SW product and its entire component set in a single development stream. </li></ul></ul></ul><ul><ul><li>It is difficult to pull a build together because the dependencies between the components are often broken. </li></ul></ul>Component A Component B Component Z Component X Component Y Sub-System I Sub-System J Platform P1 Platform Pn Product … … … … Layer 1 Layer 2 Layer 3
    • 31. Component hierarchy and multi-layered development streams (2) <ul><li>Multi-layer component stream: </li></ul><ul><ul><li>An development stream can correspond to a single component, or correspond to a group of components that evolve together, </li></ul></ul><ul><ul><li>Each component is modified in a single development stream </li></ul></ul><ul><ul><li>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. </li></ul></ul>Component A Component B Component Z Component X Component Y Sub-System I Sub-System J Platform P1 Platform Pn Product … … … … Layer 1 Layer 2 Layer 3
    • 32. Component hierarchy and multi-layered development streams (3) <ul><li>When should you use this approach ? </li></ul><ul><ul><li>The Components developed have many consumers </li></ul></ul><ul><ul><li>Components have independent and possibly uncoordinated release development cycles </li></ul></ul><ul><ul><li>Requirements for each Component can be centralized and prioritized </li></ul></ul><ul><ul><li>For each component there is a dedicated team with complete responsibility </li></ul></ul>Component A Component B Component Z Component X Component Y Sub-System I Sub-System J Platform P1 Platform Pn Product … … … … Layer 1 Layer 2 Layer 3
    • 33. CM Process Patterns summary <ul><li>Controlled Update </li></ul><ul><li>Incremental Update from published baselines </li></ul><ul><li>Incremental Update </li></ul><ul><li>Incremental Update with active development of subcomponents </li></ul><ul><li>Use of a single release (no project hierarchy with multiple releases) </li></ul>Stability Large number of consumers Speed Collaborative Work Limited number of consumers Component Hierarchy and multi-layered development streams
    • 34. Shared Component Repository <ul><li>Context </li></ul><ul><ul><li>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. </li></ul></ul><ul><ul><li>This approach lacks flexibility when organizations developing families of products need to be more reactive to customer requests. </li></ul></ul>
    • 35. Shared Component Repository Collaborative Process <ul><li>When should you use this approach ? </li></ul><ul><ul><li>The Organization is developing product families that share a common set of components, </li></ul></ul><ul><ul><li>There are independent projects that reuse and possibly require modifications on shared components, </li></ul></ul><ul><ul><li>It is not possible for a central team maintaining the shared components to cope with the change and adaptation requests, </li></ul></ul><ul><ul><li>Project managers want full control on everything on the path to releasing their product, </li></ul></ul><ul><ul><li>There is a strong focus on project execution, shared components must not get in the way of delivering the projects, </li></ul></ul><ul><ul><li>The organization is open to new development techniques such as those established in the Open Source community, and accept coordination of shared components changes, </li></ul></ul><ul><ul><li>Ideally, projects have the skills to update shared components or have temporary access to resources with the appropriate skills </li></ul></ul>
    • 36. Shared Component Repository Collaborative Process (2) <ul><li>Principles: </li></ul><ul><ul><li>No dedicated team for the shared components, </li></ul></ul><ul><ul><li>No (permanent) component ownership, </li></ul></ul><ul><ul><li>Component Customers that find bugs, need new features, new components, become contributors to the Consumed Components, </li></ul></ul><ul><ul><li>When changes to a component are performed and verified they are published on the repository, so they become available for the other projects. </li></ul></ul><ul><li>An Architecture Board composed of the architects from the various customers & contributors defines and updates the roadmap for the shared component: </li></ul><ul><ul><li>What is / What should / What will be in the repository </li></ul></ul><ul><ul><li>What is required for components / Who will use them </li></ul></ul>
    • 37. Shared Component Repository Collaborative Process (3) <ul><li>An Executive Board decides which project can modify a component and helps avoid unnecessary parallel modifications: </li></ul><ul><ul><li>Explicit separation between component interfaces and implementation </li></ul></ul><ul><ul><li>Permission to fix the implementation does not give the right to modify the interface </li></ul></ul>B V1.0 B V1.1 B xx Committer A Consumer B B V1.2 B yy B V1.3 Consumer A Committer B
    • 38. CM Process Patterns summary <ul><li>Controlled Update </li></ul><ul><li>Incremental Update from published baselines </li></ul><ul><li>Incremental Update </li></ul><ul><li>Incremental Update with active development of subcomponents </li></ul><ul><li>Use of a single release (no project hierarchy with multiple releases) </li></ul>Stability Large number of consumers Speed Collaborative Work Limited number of consumers Shared Components repository Collaborative process - Consumer Shared Components repository Collaborative process - Committer
    • 39. Shared Component Repository Open Source Like Process Variant <ul><li>Each Component is still “owned” by a team: the committer </li></ul><ul><li>Each consumer has the right to modify the component for its own needs </li></ul><ul><ul><li>Bug fixes </li></ul></ul><ul><ul><li>New features </li></ul></ul>B V1.0 B V1.1 Committer Consumer A B xx B yy Consumer B
    • 40. Shared Component Repository Open Source Like Process Variant (2) <ul><li>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 ). </li></ul><ul><li>Consumers are now contributors </li></ul>B V1.0 B V1.1 Committer Contributor A B xx B yy Consumer B
    • 41. Shared Component Repository Open Source Like Process Variant (3) <ul><li>Committer can now release more often and with more content as he gets input from contributors </li></ul><ul><li>Consumers get new versions of the components and have to merge their own specific changes into the new version </li></ul>B V1.0 B V1.1 Committer B xx B yy Consumer B B V1.2 Contributor A Merge B yy’ Contributor B
    • 42. CM Process Patterns summary <ul><li>Controlled Update </li></ul><ul><li>Incremental Update from published baselines </li></ul><ul><li>Incremental Update </li></ul><ul><li>Incremental Update with active development of subcomponents </li></ul><ul><li>Use of a single release (no project hierarchy with multiple releases) </li></ul>Stability Large number of consumers Speed Collaborative Work Limited number of consumers Shared Components repository Collaborative process - Consumer Shared Components repository Collaborative process – Consumer and Contributor
    • 43. References <ul><li>More info on how to set-up CM process patterns is provided in a new training course: “Synergy – Process tailoring” </li></ul><ul><li>White Papers </li></ul><ul><ul><li>“ Software reuse with successful CBD v1.4 02202008” </li></ul></ul><ul><ul><li>Software Reuse for Business Success </li></ul></ul><ul><ul><li>A Framework for Managing Component Based Development - 040915 </li></ul></ul><ul><li>To-the-Point guide: Synergy_CBD_TTP_02202008 </li></ul><ul><li>Success Story: SYN_SS_PrintingTechConglomerate_FINAL_080228 </li></ul><ul><li>Demo script: SYNERGY_CBD_Demo_script_02042008 </li></ul><ul><li>All the above resources can be found on SC2 </li></ul>
    • 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. <ul><li>Learn more at: </li></ul><ul><li>IBM Rational software </li></ul><ul><li>IBM Rational Software Delivery Platform </li></ul><ul><li>Process and portfolio management </li></ul><ul><li>Change and release management </li></ul><ul><li>Quality management </li></ul><ul><li>Architecture management </li></ul><ul><li>Rational trial downloads </li></ul><ul><li>Leading Innovation Web site </li></ul><ul><li>developerWorks Rational </li></ul><ul><li>IBM Rational TV </li></ul><ul><li>IBM Business Partners </li></ul><ul><li>IBM Rational Case Studies </li></ul>

    ×