Topic
  • 3 replies
  • Latest Post - ‏2013-10-18T00:13:32Z by AE91_SHINJI_KANAI
Ursanio
Ursanio
15 Posts

Pinned topic What is the Best Repository Structure for Concurent Work

‏2013-10-14T08:35:58Z |

Hi Guys,

 

I have the following dilema.

We are a team of around 10 developers concurrently working  on a project. My task is to set up the best repository structure to cater

our needs. I have read the IBM's Team Colaboration Guide but haven't found any decisive (or final) answers.

My use case goes as follows:

The software is divided into 5 different entites. For repository we use Team Foundation Server 2012; Using Rhapsody 8.0.2

My proposal is as follows:

Model organization by domains
>
>Every domain (i.e.: security, I/O, measurement...) is a standalone rpy.>
>Project is another rpy that has several components that include packages as reference from the domain rpys.
>
>
>(SCC) picture::
>
>MAIN
>|-> DOMAINS
>        |-> SECURITY
>            |->securiry_rpy
>                 |->*.cmp; *.sbs
>            |->security.rpy
>       |->CONSOLE
>            |->console_rpy
>            |->console.rpy
>|->PROJECTS
>            |->Project_A
>                 |->Bootloader_CMP
>                          |->security.sbs (REF) //added to model from SECURITY Domain and part of the Bootloader_CMP
>RELEASES
>     |->V1
>           |->DOMAINS

 

I wonder what are the best practices used? I also wonder if my proposal is too complicated and there is a better solution?

What I do now already is that I will use packages as the smallest unit on version control.

 

Thanks for reply and best regards
 

 

Updated on 2013-10-14T08:36:27Z at 2013-10-14T08:36:27Z by Ursanio
  • AE91_SHINJI_KANAI
    AE91_SHINJI_KANAI
    146 Posts

    Re: What is the Best Repository Structure for Concurent Work

    ‏2013-10-15T04:46:47Z  

    Hello Ursanio,

    Generally, concurrent/parallel development is achieved by mixing the use of CM tool and design pattern in a optimal proportion to suit a need. Design Patter here includes having your model layered by domain or framework, organized into components, or do equivalent things that minimize the possibility of update made to one area in the model unnecessarily impacts other non-related areas. I'm not sure how CM tool fits in your scenario but only looking at the proposed model organization, I see nothing unusual especially if one of two items below is your top priority. 
     
    1. To enforce tight separation of ownership between different domain groups (i.e Developers in Security domain can't make changes to other domains) 
    2. To prevent each domains from growing quickly to make the entire project monolithic and slow in performance; if performance is only matter, you might consider using On Demand Loading feature. 
     
    I'm not so sure what makes you think your proposal is"too complicated". From my experience, I won't surprise even if a project contains more than 10 REFs for a large scale project. Anther thing is that, if I were in the same situation with you, I probably go with the simplest solution in the list. I often here that people tend to choose a complicated option at beginning and later regret for various reasons :-)
     
    Btw, Team Collaboration Guide is now part of Information Center for Rational Rhapsody, the link is below:
     
     
    Best Regard,
     
    --Shinji Kanai
  • Ursanio
    Ursanio
    15 Posts

    Re: What is the Best Repository Structure for Concurent Work

    ‏2013-10-16T07:59:31Z  

    Hello Ursanio,

    Generally, concurrent/parallel development is achieved by mixing the use of CM tool and design pattern in a optimal proportion to suit a need. Design Patter here includes having your model layered by domain or framework, organized into components, or do equivalent things that minimize the possibility of update made to one area in the model unnecessarily impacts other non-related areas. I'm not sure how CM tool fits in your scenario but only looking at the proposed model organization, I see nothing unusual especially if one of two items below is your top priority. 
     
    1. To enforce tight separation of ownership between different domain groups (i.e Developers in Security domain can't make changes to other domains) 
    2. To prevent each domains from growing quickly to make the entire project monolithic and slow in performance; if performance is only matter, you might consider using On Demand Loading feature. 
     
    I'm not so sure what makes you think your proposal is"too complicated". From my experience, I won't surprise even if a project contains more than 10 REFs for a large scale project. Anther thing is that, if I were in the same situation with you, I probably go with the simplest solution in the list. I often here that people tend to choose a complicated option at beginning and later regret for various reasons :-)
     
    Btw, Team Collaboration Guide is now part of Information Center for Rational Rhapsody, the link is below:
     
     
    Best Regard,
     
    --Shinji Kanai

    Hi Shinji,

    Thank you, for your reply.

     

    Our project is an "embedded System" with aorund 12 domains and 5 different entities (Bootloader, Core, Application,..). Those entities are physical sub-images that  comprise overall firmware image (what I mean as a domain is Meaurement, Security, PowerQuality, LoadControl,...). By "to complicated" I mean that are there more simple ways of dividing our work. Instead of every domain is its own rpy and there is one project rpy that includes packages of domain rpys.  We could go with 5 different projects representing entities and a single project rpy that includes entities' packages.

     

    I wander which solution is better and if someone has similar problem and can share some light on my problem.

     

    Thanks for providing the link; i guess this is Rhapsody Design Manager Client Extension using Jazz platform, right?

     

    best regards.

     

     

  • AE91_SHINJI_KANAI
    AE91_SHINJI_KANAI
    146 Posts

    Re: What is the Best Repository Structure for Concurent Work

    ‏2013-10-18T00:13:32Z  
    • Ursanio
    • ‏2013-10-16T07:59:31Z

    Hi Shinji,

    Thank you, for your reply.

     

    Our project is an "embedded System" with aorund 12 domains and 5 different entities (Bootloader, Core, Application,..). Those entities are physical sub-images that  comprise overall firmware image (what I mean as a domain is Meaurement, Security, PowerQuality, LoadControl,...). By "to complicated" I mean that are there more simple ways of dividing our work. Instead of every domain is its own rpy and there is one project rpy that includes packages of domain rpys.  We could go with 5 different projects representing entities and a single project rpy that includes entities' packages.

     

    I wander which solution is better and if someone has similar problem and can share some light on my problem.

     

    Thanks for providing the link; i guess this is Rhapsody Design Manager Client Extension using Jazz platform, right?

     

    best regards.

     

     

    Hi Ursanio

    I read some papers published in Japanese related to concerns of modeling Domain Concept and  Functional Components (Entities?) in a project. This particular concern is not openly discussed, but seemingly exists for quite sometime in embedded world, at least my research goes. I believe examples of artifacts produced in Domain area is more related to designing such as use case, structural diagrams, etc which likely to be produced by domain experts. On the other hand, examples of artifacts produced in Entity area is ones actually define fuctionality or behavior of the system (e.g. Behavioural classes/files, component, etc). And I believe, earlier in development work flow, artifacts in domain and entity realm has to be mapped appropriately. Does it apply to your case as well?

    If that's the case, why don't you simply create a single project (*.rpy) containing a package (*.sbs) called "domains/architecture" with 12 sub-packages and another package called "entity/functionality" with 5 sub-packages, to begin with? You  might consider to split up some of packages into other RPYs later as the size of project grow if it's absolutely necessary. I believe the combination of a decent CM tool and careful fragmentation (by use of unit files and well-defined pkg structure) sounds enough to solve most of concurrent development  issues. You might use Component/Package diagrams to draw relation between Domain packages and Entity package, this we complexity of inter-relationship can be mitigated.

    As said earlier, I'm not expert on this topic, so please take my update as a comment from novice. If you haven't checked out yet, you might find following materials interesting.

    1. Systems Engineering Best Practices with the Rational Solution
    2. The Distiller model uses Rhapsody's SysML Profile to re-construct the case study example described in Sandy Friedenthal's SysML Tutorial
    (..\Samples\SystemSamples\Distiller)

    >Thanks for providing the link; i guess this is Rhapsody Design Manager Client Extension using Jazz platform, right?

    The link provided is not only for Rhapsody DM, but also contains links relevant to collaboration in general. For example, "Organizing models for team collaboration in Rational Rhapsody" or "Developing in parallel with Rational Rhapsody DiffMerge" can be useful for you.

    That's all I can provide. I'm also interested in hearing different ideas from others.

    Best Regard,

    --Shinji