Abstract image of a woman sitting on books and studying on a laptop

Synergy Tech Software Reuse With Cbd

Download as PPT, PDF
Bill Duncan, profile picture
Bill Duncan

This document summarizes different component-based development (CBD) process patterns and workflows that can be used when developing systems using reusable software components in Synergy Telelogic. It describes approaches such as controlled updates, incremental updates, using published baselines, developing component hierarchies in a single stream or using multiple streams, and collaborating on shared components. The key tradeoffs of each in terms of stability, number of consumers, speed, and enabling collaboration are also summarized.

Technology
1 of 44
Downloaded 29 times
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
Best Practices for Component Based Development with Synergy Telelogic Federal, Aerospace & Defense
Agenda Why Component Based Development? How are reused components represented in Synergy? CM process patterns for CBD Customer examples of advanced CBD practices
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
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 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
Component Based Development Controlled 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-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
Component Based Development Controlled 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 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
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 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
Incremental update Modified 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 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
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 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
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 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
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 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
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 baselines Modified 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 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
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) Stability Large number of consumers Speed Collaborative Work Limited number of consumers
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
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 Z Component 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.
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
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
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 requirements development test Iteration i Iteration i+1 requirements development test T0 T0+10d
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. requirements development test Iteration i Iteration i+1 requirements development test T0 T0+14 d T0+10d
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 requirements development test Iteration i Iteration i+1 requirements development test T0 T0+20d T0+14 d T0+10d T0+24 d
CBD in a single development stream Conclusion 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.
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) Stability Large number of consumers Speed Collaborative Work Limited number of 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. 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
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 Z Component X Component Y Sub-System I Sub-System J Platform P1 Platform Pn 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 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
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) Stability Large number of consumers Speed Collaborative Work Limited number of consumers Component Hierarchy and multi-layered development 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 Repository Collaborative 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 Repository Collaborative 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 Repository Collaborative 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
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) Stability Large number of consumers Speed Collaborative Work Limited number of consumers Shared Components repository Collaborative process - Consumer Shared Components repository Collaborative process - Committer
Shared Component Repository Open 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 A B xx B yy Consumer B
Shared Component Repository Open 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 A B xx B yy Consumer B
Shared Component Repository Open 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 Contributor A Merge B yy’ Contributor B
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) 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
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
© 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

More Related Content

PDF
Build & Release Engineering
Pranesh Vittal
 
PPT
Software Development Life Cycle Model
NainaKhan28
 
PPTX
DevOps and Build Automation
Heiswayi Nrird
 
PPTX
Version control Flow
Luis Ginanjar
 
PPTX
SDLC
Vidya-QA
 
PPTX
SDLC
Sachin-QA
 
PPSX
Software Development Life Cycle - SDLC
ANKUR-BA
 
PPSX
SDLC
Fayis-QA
 
Build & Release Engineering
Pranesh Vittal
 
Software Development Life Cycle Model
NainaKhan28
 
DevOps and Build Automation
Heiswayi Nrird
 
Version control Flow
Luis Ginanjar
 
SDLC
Vidya-QA
 
SDLC
Sachin-QA
 
Software Development Life Cycle - SDLC
ANKUR-BA
 
SDLC
Fayis-QA
 

What's hot (19)

PDF
Release management introduction v1.0 tj
Tijs -T.J.- van Velthoven, MBA - AVAILABLE
 
PPT
Application slides
IBM Rational software
 
PDF
DevOps Service | Mindtree
AnikeyRoy
 
PDF
Icsm2012 selective codeintegration
SAIL_QU
 
PDF
Enabling Mobility through Continuous Delivery
Michael Medin
 
PPTX
Build it, Test it, Ship it: Continuous Delivery at Turner Broadcasting System...
Atlassian
 
PPT
Digite - Microsoft Project Integration
Digite, Inc.
 
PDF
Automation of Release and Deployment Management - Maveric
Maveric Systems
 
PDF
Agile & ALM tools
Larry Cai
 
PDF
Marval Release Management - the political process
Marval Software
 
PDF
VMworld 2013: Best Practices for Application Lifecycle Management with vCloud...
VMworld
 
PDF
Continuous Integration Practices
Marcelo Freire
 
PPTX
Alm 11.0 qa training
Alejandro Ibarra Chavez
 
PDF
Automate virtualize and smart test the new testing realities
manoj7698
 
PDF
Build vs. Buy: Designing an Effective Software Update Delivery Solution
Flexera
 
PPTX
Steer at the Team Level with Rational Team Concert
IBM Rational software
 
PDF
6 sigma LTE release management process improvement
Jeffrey Gardner CMgr FCMI IEng MIET
 
PDF
The best testing of agile model
SanthaseelP
 
PDF
Agile ALM Tool Comparison
Venkat Janardhanam, MS, MBA
 
Release management introduction v1.0 tj
Tijs -T.J.- van Velthoven, MBA - AVAILABLE
 
Application slides
IBM Rational software
 
DevOps Service | Mindtree
AnikeyRoy
 
Icsm2012 selective codeintegration
SAIL_QU
 
Enabling Mobility through Continuous Delivery
Michael Medin
 
Build it, Test it, Ship it: Continuous Delivery at Turner Broadcasting System...
Atlassian
 
Digite - Microsoft Project Integration
Digite, Inc.
 
Automation of Release and Deployment Management - Maveric
Maveric Systems
 
Agile & ALM tools
Larry Cai
 
Marval Release Management - the political process
Marval Software
 
VMworld 2013: Best Practices for Application Lifecycle Management with vCloud...
VMworld
 
Continuous Integration Practices
Marcelo Freire
 
Alm 11.0 qa training
Alejandro Ibarra Chavez
 
Automate virtualize and smart test the new testing realities
manoj7698
 
Build vs. Buy: Designing an Effective Software Update Delivery Solution
Flexera
 
Steer at the Team Level with Rational Team Concert
IBM Rational software
 
6 sigma LTE release management process improvement
Jeffrey Gardner CMgr FCMI IEng MIET
 
The best testing of agile model
SanthaseelP
 
Agile ALM Tool Comparison
Venkat Janardhanam, MS, MBA
 
Ad

Viewers also liked (7)

PDF
Bejmuk bo
NASAPMC
 
PDF
Ralph.basilio
NASAPMC
 
PDF
Baniszewski john
NASAPMC
 
PDF
Lockwood.scott
NASAPMC
 
PDF
Wood frank
NASAPMC
 
PDF
Yew manson
NASAPMC
 
PPTX
Luat nguyen
NASAPMC
 
Bejmuk bo
NASAPMC
 
Ralph.basilio
NASAPMC
 
Baniszewski john
NASAPMC
 
Lockwood.scott
NASAPMC
 
Wood frank
NASAPMC
 
Yew manson
NASAPMC
 
Luat nguyen
NASAPMC
 
Ad

Similar to Synergy Tech Software Reuse With Cbd (20)

PDF
Increase the Velocity of Your Software Releases Using GitHub and DeployHub
DevOps.com
 
PDF
EMEA Regional OSUG
Catarina Manta Pereira
 
PPTX
Presentacion testing-procesos
Dilia Ortega
 
DOCX
2
Chandrakant Shinde
 
DOCX
2
shital904928
 
PDF
Continuous Delivery at Oracle Database Insights
Michael Medin
 
PDF
Drupal Europe 2018: Hackers automate but the drupal community still downloads...
hernanibf
 
PPTX
DevOps Interview Questions Part - 1 | Devops Interview Questions And Answers ...
Simplilearn
 
PPTX
Kentico Connection 2014 Boston Upgrade Like a Pro
Brian McKeiver
 
PPT
A Brief Introduction to Software Configuration Management
Md Mamunur Rashid
 
PDF
DevOps CI Automation Continuous Integration
IRJET Journal
 
PPTX
Integration Group - Lithium test strategy
OpenDaylight
 
PDF
Backup Exec Partner Toolkit
Symantec
 
PPTX
Introducing Visual Studio Online
Ed Blankenship
 
PPT
BPMN MIWG Status Update June 2013
Denis Gagné
 
PPTX
BitBucket Pull request vs Crucible
Dinesh Babu
 
PDF
Agile lifecycle handbook by bhawani nandan prasad
Bhawani N Prasad
 
PPTX
Modernize deployment pipeline
Takeshi Takizawa
 
PDF
Quality Assurance Guidelines
Tim Stribos
 
PDF
Quality Assurance Guidelines for Mobile App Development
Moqod
 
Increase the Velocity of Your Software Releases Using GitHub and DeployHub
DevOps.com
 
EMEA Regional OSUG
Catarina Manta Pereira
 
Presentacion testing-procesos
Dilia Ortega
 
2
Chandrakant Shinde
 
2
shital904928
 
Continuous Delivery at Oracle Database Insights
Michael Medin
 
Drupal Europe 2018: Hackers automate but the drupal community still downloads...
hernanibf
 
DevOps Interview Questions Part - 1 | Devops Interview Questions And Answers ...
Simplilearn
 
Kentico Connection 2014 Boston Upgrade Like a Pro
Brian McKeiver
 
A Brief Introduction to Software Configuration Management
Md Mamunur Rashid
 
DevOps CI Automation Continuous Integration
IRJET Journal
 
Integration Group - Lithium test strategy
OpenDaylight
 
Backup Exec Partner Toolkit
Symantec
 
Introducing Visual Studio Online
Ed Blankenship
 
BPMN MIWG Status Update June 2013
Denis Gagné
 
BitBucket Pull request vs Crucible
Dinesh Babu
 
Agile lifecycle handbook by bhawani nandan prasad
Bhawani N Prasad
 
Modernize deployment pipeline
Takeshi Takizawa
 
Quality Assurance Guidelines
Tim Stribos
 
Quality Assurance Guidelines for Mobile App Development
Moqod
 

More from Bill Duncan (20)

PDF
Red Hat Accredited Professional - Red Hat Sales Specialist Infrastructure as ...
Bill Duncan
 
PDF
Ibm bluemix—from idea to application by karim abousedera
Bill Duncan
 
PPTX
IBM Federal Systems Integrator Forum at InterConnect
Bill Duncan
 
PDF
Create software builds with jazz team build
Bill Duncan
 
PDF
How DOORS Helps JPL Get to Mars & Beyond
Bill Duncan
 
PDF
Space Quarterly: September 2011
Bill Duncan
 
PDF
Tutorial: Create a custom work item in Rational Team Concert
Bill Duncan
 
PDF
How to implement access restrictions to your EA artifacts using Rational Syst...
Bill Duncan
 
PDF
Speed delivery of Android devices and applications with model-driven development
Bill Duncan
 
PDF
Optimize load handling for high-volume tests with IBM Rational Performance Te...
Bill Duncan
 
PDF
Improve software development project success with better information
Bill Duncan
 
PDF
Automate document generation from SysML models with Rational Rhapsody Reporte...
Bill Duncan
 
PDF
Automate document generation from sys ml models with rational rhapsody report...
Bill Duncan
 
PDF
Inadequate Security Practices Expose Key NASA Network to Cyber Attack
Bill Duncan
 
PDF
Integrate Rational DOORS and Rational Team Concert change management
Bill Duncan
 
PDF
IBM Rational Harmony Deskbook rel 3.1.2
Bill Duncan
 
PDF
Advanced Rational Performance Tester reports
Bill Duncan
 
PDF
Developing service component architecture applications using rational applica...
Bill Duncan
 
PDF
Managing requirements across Analysis and Design phases using System Architec...
Bill Duncan
 
PDF
What's New in Rational Team Concert 3.0
Bill Duncan
 
Red Hat Accredited Professional - Red Hat Sales Specialist Infrastructure as ...
Bill Duncan
 
Ibm bluemix—from idea to application by karim abousedera
Bill Duncan
 
IBM Federal Systems Integrator Forum at InterConnect
Bill Duncan
 
Create software builds with jazz team build
Bill Duncan
 
How DOORS Helps JPL Get to Mars & Beyond
Bill Duncan
 
Space Quarterly: September 2011
Bill Duncan
 
Tutorial: Create a custom work item in Rational Team Concert
Bill Duncan
 
How to implement access restrictions to your EA artifacts using Rational Syst...
Bill Duncan
 
Speed delivery of Android devices and applications with model-driven development
Bill Duncan
 
Optimize load handling for high-volume tests with IBM Rational Performance Te...
Bill Duncan
 
Improve software development project success with better information
Bill Duncan
 
Automate document generation from SysML models with Rational Rhapsody Reporte...
Bill Duncan
 
Automate document generation from sys ml models with rational rhapsody report...
Bill Duncan
 
Inadequate Security Practices Expose Key NASA Network to Cyber Attack
Bill Duncan
 
Integrate Rational DOORS and Rational Team Concert change management
Bill Duncan
 
IBM Rational Harmony Deskbook rel 3.1.2
Bill Duncan
 
Advanced Rational Performance Tester reports
Bill Duncan
 
Developing service component architecture applications using rational applica...
Bill Duncan
 
Managing requirements across Analysis and Design phases using System Architec...
Bill Duncan
 
What's New in Rational Team Concert 3.0
Bill Duncan
 

Recently uploaded (20)

PDF
Flame analysis and combustion estimation using large language and vision assi...
IAESIJAI
 
PDF
ENT215_Completing-a-large-scale-migration-and-modernization-with-AWS.pdf
ssuser28425f
 
PDF
UiPath Agentic Automation session 1: RPA to Agents
suhanisingh58689
 
PDF
How ambidextrous entrepreneurial leaders react to the artificial intelligence...
IAESIJAI
 
PDF
A proposed approach for plagiarism detection in Myanmar Unicode text
IAESIJAI
 
PDF
sbt 2.0: go big (Scala Days 2025 edition)
Eugene Yokota
 
PPTX
2018-HIPAA-Renewal-Training for executives
Mayank Mathur
 
PDF
A contest of sentiment analysis: k-nearest neighbor versus neural network
IAESIJAI
 
PPTX
AI IN MARKETING- PRESENTED BY ANWAR KABIR 1st June 2025.pptx
HiraJay1
 
PDF
“A New Era of 3D Sensing: Transforming Industries and Creating Opportunities,...
Edge AI and Vision Alliance
 
PDF
CloudStack 4.21: First Look Webinar slides
ShapeBlue
 
PPT
Geologic Time for studying geology for geologist
ssuser738f5a
 
PPT
Galois Field Theory of Risk: A Perspective, Protocol, and Mathematical Backgr...
Melanie Swan
 
PDF
STKI Israel Market Study 2025 version august
Dr. Jimmy Schwarzkopf
 
PDF
Enhancing plagiarism detection using data pre-processing and machine learning...
IAESIJAI
 
DOCX
search engine optimization ppt fir known well about this
StandardCodeLearning
 
PDF
How IoT Sensor Integration in 2025 is Transforming Industries Worldwide
Rejig Digital
 
PDF
Hybrid horned lizard optimization algorithm-aquila optimizer for DC motor
IAESIJAI
 
PDF
NewMind AI Weekly Chronicles – August ’25 Week III
NewMind AI
 
PDF
Produktkatalog für HOBO Datenlogger, Wetterstationen, Sensoren, Software und ...
Metrics GmbH
 
Flame analysis and combustion estimation using large language and vision assi...
IAESIJAI
 
ENT215_Completing-a-large-scale-migration-and-modernization-with-AWS.pdf
ssuser28425f
 
UiPath Agentic Automation session 1: RPA to Agents
suhanisingh58689
 
How ambidextrous entrepreneurial leaders react to the artificial intelligence...
IAESIJAI
 
A proposed approach for plagiarism detection in Myanmar Unicode text
IAESIJAI
 
sbt 2.0: go big (Scala Days 2025 edition)
Eugene Yokota
 
2018-HIPAA-Renewal-Training for executives
Mayank Mathur
 
A contest of sentiment analysis: k-nearest neighbor versus neural network
IAESIJAI
 
AI IN MARKETING- PRESENTED BY ANWAR KABIR 1st June 2025.pptx
HiraJay1
 
“A New Era of 3D Sensing: Transforming Industries and Creating Opportunities,...
Edge AI and Vision Alliance
 
CloudStack 4.21: First Look Webinar slides
ShapeBlue
 
Geologic Time for studying geology for geologist
ssuser738f5a
 
Galois Field Theory of Risk: A Perspective, Protocol, and Mathematical Backgr...
Melanie Swan
 
STKI Israel Market Study 2025 version august
Dr. Jimmy Schwarzkopf
 
Enhancing plagiarism detection using data pre-processing and machine learning...
IAESIJAI
 
search engine optimization ppt fir known well about this
StandardCodeLearning
 
How IoT Sensor Integration in 2025 is Transforming Industries Worldwide
Rejig Digital
 
Hybrid horned lizard optimization algorithm-aquila optimizer for DC motor
IAESIJAI
 
NewMind AI Weekly Chronicles – August ’25 Week III
NewMind AI
 
Produktkatalog für HOBO Datenlogger, Wetterstationen, Sensoren, Software und ...
Metrics GmbH
 

Synergy Tech Software Reuse With Cbd

  • 1. Best Practices for Component Based Development with Synergy Telelogic Federal, Aerospace & Defense
  • 2. Agenda Why Component Based Development? How are reused components represented in Synergy? CM process patterns for CBD Customer examples of advanced CBD practices
  • 3. 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
  • 4. 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
  • 5. 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
  • 6. Component Based Development Controlled 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-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 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 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 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.
  • 9. 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
  • 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 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 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 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.
  • 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 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 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 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
  • 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 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
  • 18. Incremental update from published baselines Modified 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 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 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) Stability Large number of consumers Speed Collaborative Work Limited number of consumers
  • 20. 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
  • 21. 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 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) 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.
  • 23. 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
  • 24. 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
  • 25. 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 requirements development test Iteration i Iteration i+1 requirements development test T0 T0+10d
  • 26. 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. 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) 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 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 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.
  • 29. 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) 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 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 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) 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 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) 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 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 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) Stability Large number of consumers Speed Collaborative Work Limited number of consumers Component Hierarchy and multi-layered development streams
  • 34. 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.
  • 35. Shared Component Repository Collaborative 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
  • 36. Shared Component Repository Collaborative 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
  • 37. Shared Component Repository Collaborative 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
  • 38. 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) 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 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 A B xx B yy Consumer B
  • 40. Shared Component Repository Open 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 A B xx B yy Consumer B
  • 41. Shared Component Repository Open 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 Contributor A Merge B yy’ Contributor B
  • 42. 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) 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 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

Editor's Notes

  • #2: 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”