Tuesday, 26 November 2024

My latest Rhapsody MBSE training feedback summary

I have owned and developed my own Mastering MBSE with SysML and Rhapsody training over the last 10 years with international delivery via a variety of business partners. I moved to capturing feedback via google forms which gives me ability to create summary. Past performance is a good indication of future performance. This is the latest feedback summary. 





What did you like most about the training?

  • The labs really helped enforce the theory and brought the material full circle.
  • It's a new tool for me that can capture big picture ideas and decompose to manageable chunks.
  • Labs are great. Good examples.
  • Instructor & the labs
  • Flexibility to demonstrate tasks on demand, make it easy in this environment.
  • lots of tips and short cuts for action users 
  • I had no prior knowledge regarding Rhapsody however leaving the training I feel like I'm able to perform task via Rhapsody. The trainer was also very knowledgeable and kept the participants engaged. 
  • Practical Lab
  • The trainer was very cool!
  • Learned a new piece of software that could be quite useful as my team embarks on new R&D Designs.
  • Constant examples - learn by doing a lot more efficiently
  • I really enjoyed the fact that it was a small class and there was a lot of interaction between class attendees and the instructor
  • Hands-on lab activities
  • Drilling the concepts through "labs"
  • Technically involving course. Fraser is very knowledgeable on the topics and is happy/ready to answer and help with any questions.
  • Really good & detailed resources, instructor very knowledgeable, easy to follow exercises
  • Practical labs and engagement were good.
  • Lab work
  • Hands on experimenting on Skytap virtual machine very useful. Having a cleanly setup environment with all the notes and lessons ready is great.
  • Doing the labs
  • Loved the labs, it was fun going through and manipulating the system and learning how it all works. I am a hands on learner so this was great for me. 
  • The material provided was very informative. It answered most questions I had, and I didn't need to ask the instructor for much of anything. 
  • Fraser was very knowledgeable; online collaboration tools
  • As someone who has never used this software (or similar) before, just the introduction and basic principals were extremely helpful.
  • I enjoyed that this course was hands on training. The instructor was helpful and knowledgeable on the topics.
  • The labs were fun and Fraser made this course something to look forward to.
  • The instructor
  • Building models as a team and seeing how they are built into the tool.
  • Labs, Kahoot
  • The exercises.
  • The Instructor was very knowledgeable and also did a great job of keeping everyone's attention and keeping everyone actively engaged.  He often tailored his training and responses to the feedback he received from the group.  Great Instructor!
  • The slides were very informational. 
  • The games and doing the exercises together
  • I liked the sequence of the lab training. I think it helped build our skills to become more independent when creating our own systems. 
  • The fact that the instructor walked us through the material, showed how the tool was used, and then we had the chance to do it on our end. This helps confirm if we understood or not as well as improve our familiarity with the tool.
  • Presenter was very good at communicating and keeping students engaged.
  • It was presented in an easy to follow format and the trainer answered any questions I had along the way.
  • Interactive training and hands-on labs hands-on activities were helpful in understanding the course
  • Practicals organising the material
  • Labs
  • Labs with support if needed
  • Relating what we learned to current projects we are working on
  • I liked working through subjects in the tools.  I also liked the kahoot tests.
  • well organized with live explanation and time to play in Labs
  • The interaction and presentation.
  • Hands on the VM.
  • VM setup for the lab practices
  • Lots of different training activities (theory, labs, quizzes, workshop)
  • Open dialog helped to drive understanding and application of training to current work.
  • Completing the labs because we got to practice what we reviewed
  • The labs were very well detailed. 
  • Hands -on training
  • Detailed steps in pdf
  • Well detailed slides, easy to understand
  • The hands on labs
  • Systematic way of doing a model by understanding what should be the System
  • Interactive exercises
  • Enough structure but not too rigid for taking questions or related topics
  • The flow of topics was organized and clear. Fraser is very knowledgeable and welling to answer/discuss all the questions. 
  • I really enjoyed the labs - I thought that they were really helpful in applying what we have learned. 
  • The remote desktop environment, where we can practice actually using Rhapsody
  • "- Allowed me to really think about the systems that I work on and how they break down into individual elements.
  • - Gave me a strong beginner foundation of MBSE and is encouraging me to learn more and gain more experience in and outside of my current role.
  • - Labs and lesson plans were easy to follow along.
  • - Training was interactive and fun but still challenging. I liked the Kahoot quizzes :)" 
  • Kahoot game.
  • The trainer was very proficient and lab exercises were useful
  • The labs are outstanding
  • I really enjoyed the pace, detailed descriptions, attention to detail, and patience with working through all of our various issues and understanding hurdles to make sure we all were moving through the course and not falling behind.
  • The applicability of content and case study topics.
  • Range of Topics
  • getting to know Rhapsody, I've used other tools but I'm new to Rhapsody and will be using it for work so it was great to practice with it
  • I liked most the fact that this training requires so much interaction... really forces the attendees to practice what they learn, not just absorb it
  • The labs were really easy to follow and helped with my understanding of the elements of Rhapsody that I will use most often.
  • Liked the hands-on learning experience of using the tool and working on the labs.
  • The labs, the practical exercises
  • good opportunity to learn about very powerful tool for MBSE process.
  • Interaction of the instructor 
  • Engagement, Kahoot
  • Labs
  • There was a lot of time to follow along and ask questions as needed. Room for flexibility.
  • Lots of labs and participation to try out the software functionality.
  • The interactive labs
  • The multiple ways that the instructor explained the same topic. The material was provided in a concise, assertive, and practicable.
  • Clear, Concise and effective presentation. Training material was hands-on and in-depth. Instructor (Fraser) is very knowledgeable and patient with answering questions and simplifying the concepts so that even novice trainees could understand. 
  • How clear all the material was; it make it very easy to follow. 
  • Trainers willingness to provide guidance on topics not directly in the training materials.
  • The examples were relevant
  • The instructor's knowledge and expertise
  • Provided documentation is awesome. Searches can be performed within the documents to find topics of interest. Pace was good in that there was time to work in the tools and time to learn theory. 
  • I love the presentations and videos before practicing on our own
  • Understanding the power of the Rhapsody tool and the lab practices.
  • Building own practical examples (vs following lab)
  • Real time training 
  • The labs
  • I liked getting to work through the examples and use a case study to reference throughout the day.
  • The training showed additional features for testing within a model that I had not used before.
  • knowledgable responsive instructor
  • The VM used to be able to do the Labs
  • I always enjoy the hands-on feel of Fraser's trainings.  The format of theory and then a "go do" really makes sense to me.
  • The hands-on labs
  • THE INSTRUCTOR INPUT AND GUIDANCE
  • The instructor knows the software capabilities very well, and he relayed those capabilities to the group.
  • Practical Labs
  • Clear training material with clear delivery. I understood everything delivered. Good entry level training.
  • Good format of explanations followed by labs.
  • Plenty of hands on on relevant subjects
  • In-depth discussion on UML and SysML background and diagrams
  • The instructor answer questions related to the product but not necessarily to the training
  • It was pretty thorough.
  • Comfortable and friendly
  • I love that it was flexible and trainer shifter for our specific requirements in many instances.  That's why the lower score on training objectives, we really didn't know what we were getting.
  • the hands on labs
  • I did not know much about MBSE or its role in the context of an engineering project. I didn't just learn the tools, but also why they are being used. That was very helpful.
  • test format (game)
  • The knowledge and expertise of the trainer. Very helpful and learned a lot about Rhapsody and integration with DOORs NG
  • New experience
  • The interaction with creating Systems Engineering Diagrams
  • Tool agnostic
  • Tests and exercises were quite entertaining 
  • The relaxed, informal and collaborative style.
  • Instructor seemed experienced and was personable.
  • Hands-on workshops
  • Practicals and Kahoot challenges - really tested our knowledge
  • Broad focus on Rhapsody 
  • The combination of theory, labs and quizzes was well suited to remember and understand the content.
  • The practical labs
  • Good balance between slides, labs and quizzes to break up the course.
  • Kahoot quizes were a good way the break up the course in a fun and relevant way

Thursday, 22 August 2024

IBM Engineering Rhapsody Tip #110 - The Function Block Method

This video shows how it's possible to build a very powerful description of a systems structure and behavior using only two SysML diagram types, if you embrace the notation of function blocks and using BDDs and IBDs to do both. To get this to really work, I've had to extend Rhapsody with my open-source profile called ExecutableMBSEProfile. 


The video creates a project from scratch including bdd/ibds for both behaviour and structure and then shows some of the notation that's possible dove-tailing them together. The ability to show functions inside structural elements together with signals is something similar to Capella/Arcadia. Personally I find it interesting that you don't need something complex to describe something complex. Somehow by limiting the notation you can achieve more, especially as it means that you only really need to understand two SysML diagram types to read the diagrams.

This is the transcript in case that helps:

00:00:00

In this video I'm going to show you the executable MBSE profile again, and then I'm going to do something a bit different with this, which is to explain one of the workflows you can do with this profile without using activity diagram, sequence diagrams or state charts and instead doing an entire project with just two diagrams.

The intent of that methodology is to simplify SysML so, if you understand how to do block definition diagrams and internal block diagrams for structure, then you would understand how to do it for behavior and then you can take those two compositional trees and dovetail them together. This is an approach around function block modeling. I'll do the insulin pump system again.

00:00:48

And I'm going to use the executable MBSE profile. This is the four three E version. If you look on my executable mbse website here (www.executablembse.com), then you can see that there is a link to be able to get this profile from GitHub.

00:01:13

Now, conventionally you might start a project with use cases and use cases you might decompose with, say, an activity model. An alternative to that is to start with blocks and do a decomposition using a block model, so the first thing I'm going to say is let's define a system architecture structure.

00:01:32

Using a block definition diagram and this is for an insulin pump system.

00:01:45

And the insulin pump system has an insulin pump, a continuous glucose sensor, and a blood glucose meter.

00:02:09

This is something called a block definition diagram in SysML, and it's derived from the class diagram in UML and allows me to do directed decomposition to be able to create part property relationships between elements.

00:02:31

The insulin pump system now has three part properties typed by these subsystems.

00:02:40

Well, if I did the same within the behaviour domain then I could do it with something very similar and this profile adds the concept of a feature which might be to deliver basal insulin.

00:03:02

This, rather than being a structural block, is a functional block. I'm able to say well to deliver basal insulin, I need to measure glucose level, calculate basal adjustment and deliver insulin.

00:03:29

Obviously, there might be more detail than the real world, but this is just an example.

00:03:40

I use decomposition to show that there's a functional decomposition and the only real difference here between the feature block and function block is I'm saying the feature block is at system boundary level and I do have some relationships that I can do between the system block and the feature block to say that a feature is a system, for example, using generalization, that I don't allow with these function blocks.

00:04:06

But I do allow function blocks to be decomposed to any arbitrary level as do I allow within the structural model subsystems to be decomposed into any any level but not systems. So we're making a language choice within the profile to put meaning around these different types of block, but fundamentally it's a block definition diagram and the notation is the same across both.

00:04:30

So you would say conventional systems projects such as Magic Grid with Cameo or Harmony/SE with Rhapsody would start with use cases and I could could do that but I'll show you an alternative which is that I've added the idea of a context diagram.

00:04:51

Where the context diagram is going to show me the relationships that the system has with external actors.

00:04:59

So it's very similar to a use case diagram. This is an internal block diagram. It's got parts which are typed by actors.

00:05:07

Obviously I haven't really got drivers using an insulin pump system, I've probably got a patient so if I rename that actor as a patient, I could say that there's an interaction between the patient and the system. The patient might request a bonus correction and the system delivers insulin.

00:05:44

This simplified internal block diagram does have very simplified palette and we're using flows between part properties, and the flow is carrying signals or what Rhapsody calls events, because that's one of one of the easiest things to hook other things into. Lots of different diagrams within SysML are able to capture exchange items using Events/Signals. I could show within this insulin pump system using

00:06:16

A feature usage which is typed by that (Feature).

00:06:22

And establish the flows to those features. If you think of this as similar to what a use case would do, the difference is instead of having an ellipse here and having a use case, I've got a block.

00:06:36

To do this (project), I've only actually used two different types of SysML diagram so far. I've used block definition diagrams to do decomposition. I've used a high level internal block diagram. When I say high level, I mean an internal block diagram where the part properties are global. I've got the concept of a block called a feature which decomposable into functions.

00:06:57

And I can then establish relationships between these blocks, and although I could do it with allocation dependencies, what this opens up quite easily is the ability to do allocation through composition. I could say, that my.

00:07:16

Calculation of basal adjustment is done by the insulin pump.

00:07:25

My deliver of insulin is actually also done by the insulin pump.

00:07:34

My measuring glucose levels is done by the continuous glucose sensor.

00:07:42

If I wanted to, I could go into using internal block diagrams.

00:07:48

I've got an internal block diagram here. I can populate the parts.

00:07:53

And I've got a helper here to to be able to do that. Some of these are function usages. Some of them are subsystem usages. If I just say, populate them all.

00:08:05

You'll see how it it dovetails the two together.

00:08:10

Just can pack this a bit than because my screen size is not so good.

00:08:14

The insulin pump then might might have connections with the continuous glucose sensor.

00:08:26

The helper is going to automatically create some interface blocks and conjugate one of the ports. If I do that, I could say that the measurement of the glucose level.

00:08:37

So might might bits or less.

00:08:41

This way, that's the way of doing it.

00:08:45

I could say measuring glucose level produces flows on this connector into these parts, so you see how I'm using part properties with a structured compartment here to be able to see both entities.

00:09:11

So that will be our flow input into that function you can see it's part of the insulin pump.

00:09:22

This gives me some sort of unique but recognizable views, which I can't quite do as clearly/closely using activities as I can with parts and blocks.

00:09:38

And this might be a pre step. I could take that feature.

00:09:44

And then take the part properties and chain them purely in a functional model.

00:09:54

So I measure glucose level.

00:09:58

And that flows.

00:10:02

I haven't typed these by events, but I could that flows to calculating the basal adjustment and then calculating the basal adjustment flows into the delivery of insulin.

00:10:14

And the helper here is creating some flow ports there, and if I wanted to I could put some conditional logic or parallel logic and I'm using business process (BPMN-inspired) notation here because that works quite well in nodes, but this is actually an internal block diagram being used to perform the function that an activity diagram would have.

00:10:39

So it's relatively powerful notation but I've got the whole port/part capability in that this measure glucose level function block here, assuming that essentially the capability and it owns things like a requirement diagram.

00:10:57

And show requirements that the function block owns. Then if I allocate this function block to a subsystem, then I'm essentially allocating the requirements.

00:11:08

And these function blocks then become these reusable elements. So I could create a completely different architecture with different subsystems and allocate the same functions if I wanted to. Or I could start to use some of the things of object orientation such as generalization and composition to assemble reusable functionality as a block, and then use that functionality in another system. It's SysML but all these diagrams are done entirely with the notation of block definition diagrams and internal block diagrams. I haven't used any use cases. I haven't used any activity diagrams, haven't used any sequence diagrams.

00:11:49

But I can achieve quite a lot with a very small syntax.

00:11:53

And once you understand that small syntax, you can express quite interesting relationships and start to assemble systems from reusable components. So it's a more fluid, dynamic way of modeling a system.

00:12:08

Which does rely on some extensions here to be able to specialize the types of blocks, but is something that may be interesting if you're into this idea of functionally decomposing system capabilities rather than trying to say, that we need to express our system in terms of a SysML sequence diagram or state chart.

00:12:26

So I thought I'd show you that it's a slightly different approach to SysML. There's lots of different ways you can use SysML, but I think the idea of only using two diagrams is actually quite clever (i.e. powerful) if you need any more information then let me know.



Sunday, 7 July 2024

IBM Engineering Rhapsody Tip #109 - Activity diagram swimlanes and allocation

Gosh, almost on a roll. This Rhapsody Tips and Tricks video which came from some new lab work I've done for my Rhapsody training labs. 

It covers both basic principles of swimlane allocation in IBM Engineering Rhapsody using SysML but it also has a fair share of advanced aspects. For example, I show how to create a context pattern table to show allocation and how Rhapsody creates inferred allocation relations. I then illustrate how it's possible to see allocation in compartments on a block definition diagram, and how Rhapsody also has a slightly hidden capability to show allocation using SysML Callouts, a type of new term comment added by the SysML profile.

Here's the transcript:

00:00:03

OK, my name is Fraser Chadburn. In this demo, I'm going to show you some things about swim lanes in activity diagrams. I'll just navigate to this activity diagram and show you what I mean. I've got double click here working with a Java helper.

00:00:22

This is an activity diagram that just shows control flow with Rhapsody and you can see how this activity diagram is quite useful for capturing the operational scenario perhaps of the system and also how we can link these actions to requirements. 

00:00:41

I'm just going to remove a customization as at the moment the drawing toolbar here has got some additional things like a derivation and that's been done through an applied profile which is a profile that which isn't globally applied but is applied if there's a dependency with applied profile on it.

00:00:59

I'm just going to delete that and then I'll reopen the activity diagram.

00:01:11

And here I've got the default drawing toolbar for an activity diagram. Let me just expand this a bit so we can see it. I've also got action pins and activity parameters.

00:01:22

I've got these swim lanes (in the toolbar). The concept of swim lanes is the ability to associate structure to those swim lanes and then, if I put the action inside of a swim lane, then there's an implicit thing in SysML that this behavioral element is allocated to this structural element. Let me just zoom out and.

00:01:42

I'll draw a swim lane frame of roughly the same size as these actions.

00:01:47

And I'll subdivide it into three different swimlanes (or partitions).

00:01:51

This is what we'd call a black box sequence; we're looking at the operational scenarios from the perspective of the user and we're treating the system as a black box.

00:02:06

Let me just resize these to be able to resize the frame. Here I need to hold down the alt key and that allows me to have some modification of the behavior of the resize.

00:02:22

I'll make them slightly bigger. The first thing with these swim lanes is that we could associate or get a swim lane to represent a structural element. Here's my first action. The operator logs in at the control panel and activates the teleportation system because this is a teleportation system.

00:02:44

I'll turn off the hovering toolbar. I'm going to say well that that's an action performed by the operator.

00:02:53

Within my use case package here I've got an operator actor so to represent that actor I could look at the features and then pick the element.

00:03:05

Or I can drag the element onto the name of the swim lane. If I drag it here I just get an object node. If I drag it directly onto the text, it will do that represents for me. This is the swim lane that represents the operator so I move this action into that swim lane.

00:03:24

I can use the arrow keys here to just shift it across.

00:03:30

What I'm saying is that this action is performed by that actor. Let me delete and redraw the initial flow. I could move it, but generally it's just easier to redraw.

00:03:43

So that's the first step. The operator has logged in at the control panel, so the second step here the Teleportee (actor) tells the Operator where they want to transport to. I'll shift that over with my arrow key on my keyboard andmove that into the second swim lane.

00:04:02

And that is an action performed by the Teleportee. Something that Rhapsody does automatically here, if I have a swimlane, if I look in here, is it it will create an inferred relationship. You can see here that an allocation relationship has been created in the model because of the presence of that action within that swimlane.

00:04:30

What I'll also show you then, is the ability to see this allocation of behavior to structure within a table. I'm going to create something powerful concept here called a context pattern table.

00:04:46

So I create a table layout of my swim lane allocations.

00:04:59

And I'll go to the features for that.

00:05:03

Go to the columns, and go to the advanced options. Not everybody needs to know how to create a context pattern, but they're useful to know what they do and how powerful they can be so that if you think well, actually it would be really useful to see this stuff in a table. You know that it's possible, perhaps as someone in your organization who's able to to understand the series of tokens you need to write to create a contacts pattern. So here's an example I'm going to say go to all the packages and any nested packages. Then if you find a use case.

00:05:34

Then list that, but underneath the use case is an activity diagram.

00:05:39

And I'll give that a token name of act, which is the system mail abbreviation. Effectively, I actually then want to have the actions.

00:05:52

These are states in Rhapsody.

00:05:55

And then I want to see the allocated to elements, so that's go to the allocation relationship and find the end element.

00:06:06

So this is a context pattern. If I collapse the first column I can use the fill defaults to populate columns from that context pattern. The table layout is like a template, so I'll create a view so this is a table view.

00:06:23

Of my swim lane allocations.

00:06:30

If I don't click Refresh, we can see that this action is performed by this actor.

00:06:40

OK, let's look at the next things. Operator sets the destination point, the Teleportee stands on it. I'll just get rid of the Interruptible Region here and what I'll do is move across these actions into the swim lanes.

00:07:00

Once they've moved across, if I go to table view and do a refresh.

00:07:04

Here you can see it's representing that (allocation).

00:07:07

So let's look at the next thing. Actually, this is something done by the system. I've got a third swim lane but I haven't actually allocated any structural element to it, and often when we use swim lanes, we actually have blocks or parts of the system that we're allocated behaviours to. If we go into the white box model. So I'll just create a package.

00:07:34

With a block in it. So I'll create a design synthesis package.

00:07:42

In that I'll create a block definition diagram. This is a BDD of the teleportation system.

00:07:56

And there's a block on it called Teleportation System.

00:08:04

And what I want to show with this is also compartment. So firstly let me take that block and I'll allocate it, or get the swim lane here, to represent it.

00:08:22

And then I'll move this action into that swim lane.

00:08:36s

And I'll check that it then appears OK (in the table). So here we go, we've got an allocation of the system analyzes target location to the teleportation system.

00:08:47

If I go to the display options of this block then what I could do is show that allocation in a compartment.

00:08:57

And an allocated from compartment is available in the pull down list here.

00:09:02

And now I can see the allocation of that behaviour to that structural element on my block definition diagram in a compartment using the specification view.

00:09:15

In terms of the activity if I go to the display options of this action, then there isn't the ability to do compartments, but there is this option to use the SysML callout tool. It's a type of stereotype comment and if I set the display options to the anchored info on here and I make sure that box style isn't shown.

00:09:38

And I anchor it.

00:09:41

Comment to that action.

00:09:44

It's going to pick up the allocated to relationship and show that in system. SysML call out notation.

00:09:52

I'll just show you this final thing here. If I had a a core behaviour here which is dematerialise and rematerialise and I'll just move that in to a swimlane.

00:10:13

Then the question is, is it the call behaviour, or the referenced activity, that I want to allocate to the teleportation system?

00:10:26

Now. If I look at the activity model that's underneath the activity diagram here.

00:10:35

You'll see that there are two different things I've got.

00:10:39

An activity which is dematerialized and rematerialized and then I've got the action that then invokes that activity.

00:10:48

So if I want this activity to be allocated soon, then rather than using inferred, I actually have to use an explicit relationship to allocate. The right click (menu) here would require me to create a dependency and then select that this activity is performed by the teleportation System block.

00:11:11

I'm explicitly creating a dependency here and making that an allocation new term.

00:11:20

And that means that it will then also appear in the allocated from compartment.

00:11:30

If I had the activity on here, we can see that relationship. The display options of the activity on a block definition diagram do allow me to put compartments.

00:11:50

So that’s it. A quick introduction to the idea of using swim lanes to do allocation of behaviors to structures from activity diagrams.

00:12:00

And also some of the support within Rhapsody for inferred allocation that comes from the presence of an action within and from lane.

00:12:10

Or explicit allocation which comes from creating allocation dependencies from the behavioral element to the structural element, in this case, and how we can see these in either compartments on a block definition diagram, or using call out notation on an activity diagram.

00:12:28

Hope that helps. My name is Fraser Chadburn and I do a lot of work with customization, specialization of Rhapsody. If you have any questions then give us a call. Thank you.





Thursday, 20 June 2024

IBM Engineering Rhapsody Tip #108 - Creating models quickly, incl. package diagrams automatically

In some ways this is more of the same. However, this video has some of my very latest work for auto-creating package diagrams for model navigation which has gone through a few iterations but is getting quite promising, considering that I used to think that package diagrams weren't that useful in SysML.

The video shows how I create models quickly using a mosaic SysML package approach with an open-source profile I've created called the Executable MBSE Profile. The beginning point for a lot of projects is often a use case and requirements-driven approach but this 11 min video does show that the profile goes beyond that with functional and system architecture packages. This video ends with the auto-creation of package diagram - index for model navigation of the project that was created.



Friday, 26 January 2024

New release of SysMLHelper

The latest SysMLHelper package (4.3.b.Release) is now available on Github. This is an open-source profile and helper collection. The ExecutableMBSE profile part of this as well as providing a Harmony/SE like approach includes function block and function chain modeling enhancements using advanced profile features of Rhapsody. It works with 8.3.1 upwards. 

See my other website which is: http://www.executablembse.com

Monday, 27 November 2023

IBM Engineering Rhapsody Tip #107 - Create a use case package structure

This video represents training Module A on creating use case package structures using the Executable MBSE Profile, a GPL-licensed extension to Rhapsody development by MBSE Training and Consulting Ltd to enhance SysML with method-aware helpers. 

The Executable MBSE Profile takes a mosaic approach by adding new term packages which have specific purposes.. The methodology is designed to support team-based development in Rhapsody with an awareness of both DOORS Next external requirements and configuration of Rhapsody projects using Rhapsody Model Manager and the IBM Jazz platform.