![]() |
Telelogic SYNERGY (steve huntington) | ![]() |
Topic Title: How can I put a Compatibility matrix within CMSynergy Topic Summary: Created On: 13-Aug-2004 15:52 Status: Read Only |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() Answer: Hi Tom, Your questions has 2 parts, but they have got mixed together because your framework is CM centric. Q1. Can we substitute Component C ver 2.0 with Component ver 1.0 and will it still work? A1. Please see Mert's reply, this approach provides us with some quality assurance, we at least know the alternate configurations have been tested. Note: Technically once we substituted Component C with ver 1.0 then System is technically no longer ver 1.0 ![]() Q2. Is Synergy a suitable tool for tracing possible Component substitutions? A2. I personally would track this "as built" or "as delivered" information somewhere else. Normally this sort of has other metadata associated with it, ie maybe serial numbers, customer info, date of installation, etc, etc and normally is associated with some form of "in service support" system, Synergy is not the right place to store this associated metadata. Cheers, Peter | |
![]() |
|
Hello,
When I make a release of my software on system level, it consists of a version af several components like: System ver 1.0, is built up out of: -- Component A ver 1.1 -- Component B ver 3.4 -- Component C ver 2.0 For configuration management, it is important to know all the possible combinations (called Compatibility matrix) e.g. A problem occurs on C ver 2.0. Then the question is "Is it possible to install version 1.0 for component C and still have a working System when A ver 1.1 and B ver 3.4 are kept?" This information I want to capture within CMSynergy.. does anybody know if this is possible within CMsynergy??, else I have to stay with my Excel sheets for the Compatibility matrix. |
|
![]() |
|
![]() |
|
Hi Tom !
Guess, thats a typical "multi-release" project problem. if there not too many possible subsystem combinations, I would store this information by releasing the master or grouping project with all those possible combinations. So, you would have a released "System ver 1.0" project with -- Component A ver 1.1 -- Component B ver 3.4 -- Component C ver 2.0 and another one with -- Component A ver 1.1 -- Component B ver 3.4 -- Component C ver 1.0 Well, as I said this might work, if there are not too many combinations. There is another way, but I will have a coffee break first ![]() Regards, Mert |
|
![]() |
|
![]() |
|
Hoi,
Thanks for the reply. Our product consists of 15 sub-components. I think the matrix is quite large. Average: each of these sub-components van have 5 versions. The problem is that all these version also have dependancies with eachother System ver 1.0, is built up out of: -- Component A ver 1.1 -- Component B ver 3.4 -- Component C ver 2.0 another combination: System ver 1.0, is built up out of: -- Component A ver 1.1 -- Component B ver 2.2 -- Component C ver 1.0 (Then the version 2.2 of component B is used, Only version 1.0 of component C is working.) I'm curious of your other solution. Greetings Tom |
|
![]() |
|
![]() |
|
Hi Tom,
quite a long coffeebreak, but I was a bit busy with CM Synergy ![]() Second method Well, a 15 component system might produce a quite complicate matrix. But in most cases - I guess - compatibility can be broken down a bit and thus stored in CM by creating a "project" task, containing those project versions valid for a release variant. So, You do not freeze the complete super-project structure with any valid component combination, but just the appropriate information stored in a task. The creation of a task like that could be done by: - a recursive query for all project version inside the superstructure - create a new task and associate these objects As a result each variant is stored in one task and you also could use queries to find out, which component is used in which environment. Thus a task "Projects for release Ver 1.0 variant a" contains objects Component A-1.1: Project:1 Component B-3.4: Project:1 Component C-1.0: Project:1 and task "Projects for release Ver 1.0 variant b" contains objects Component A-1.1: Project:1 Component B-3.4: Project:1 Component C-2.0: Project:1 A configuration could be restored by including such a task to the reconfigure properties. (You need something like that anyway, in order to keep a multi-release project in shape) In contrast to a spreadsheet document, the information stored in a task is directly used in CM Synergy. Ok, the spreadsheet looks much nicer, but perhaps its possible to generate it from CMS data. As always, just my way..... Regards, Mert Edited: 26-Aug-2004 at 08:29 by Mert Vuraldi |
|
![]() |
|
![]() |
|
Thank you for this option. I will think about it, and see how it will fit out way of working. It is an good idee when it is possible to generate some kind of a matrix.
Greetings Tom |
|
![]() |
|
![]() |
|
Hi Tom,
Your questions has 2 parts, but they have got mixed together because your framework is CM centric. Q1. Can we substitute Component C ver 2.0 with Component ver 1.0 and will it still work? A1. Please see Mert's reply, this approach provides us with some quality assurance, we at least know the alternate configurations have been tested. Note: Technically once we substituted Component C with ver 1.0 then System is technically no longer ver 1.0 ![]() Q2. Is Synergy a suitable tool for tracing possible Component substitutions? A2. I personally would track this "as built" or "as delivered" information somewhere else. Normally this sort of has other metadata associated with it, ie maybe serial numbers, customer info, date of installation, etc, etc and normally is associated with some form of "in service support" system, Synergy is not the right place to store this associated metadata. Cheers, Peter |
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.