Collaborating with GENESYS - Using GENESYS in a Team Environment

For teams to work collaboratively and concurrently on the same project, GENESYS Server Edition is required. This allows multiple team members to connect to the project concurrently, always staying abreast of model changes and working together seamlessly. However, sometimes that is not possible - the collaboration is occasional, team members are distributed, or the IT environment won't support a real-time collaboration capability. For these cases, GENESYS natively supports a robust change process that allows teams to collaborate through a publish-change-merge cycle.

The basic design refinement/extension process is shown below for each design update cycle. An update cycle can be defined as a period of time (e.g., every week, at the beginning of the system engineering effort) or the accomplishment of a specific milestone (e.g., finishing the effort leading to the first draft of the System/Segment Specification). Each design cycle begins with a baseline version of the system design database and ends with an update of that system design, again captured in a database.

Start with Master Project Database

Assume there is a master database containing the system design, which is under the control of the project administrator or the configuration manager. The person responsible for maintaining the integrity and baseline of the master database will be referred to as the project administrator. The starting point for all team (or individual) updates of the database (i.e., the system design) is a COPY of the master database.

Export Database to Team Members

Assume also that there are two or more design engineers on the development team who are refining/extending the system design. Each of these team members will receive a copy of the master database. The project administrator provides these copies in the form of GNSX files that are generated by using the Export command selecting the Project Baseline export option. This file contains the current definition and is shared with the team via LAN, team collaboration site, or e-mail.

CAUTION!

When exporting the file(s), it's critical that the project administrator ensure that each exported file is set to erase history after import by selecting the Project Baseline export. At the completion of the database import, this automatically sets the merge history point so that all changes made by the team (and only those changes made by the team) are captured for future export back to the master database. Failure to properly select this option in order to erase merge history will lead to difficulty when integrating the change files from the team members.

Import Project

Each team member participating in the update cycle imports the project database into GENESYS using the Import command. When importing, team members should ensure that the data is imported into a new project using the import wizard. Team members should not import the new master database into an existing project.

Extend and Refine System Model

As each team member refines/extends the design for their segment of the system, GENESYS maintains a history of the changes. The team member should never manually erase merge history; this is handled automatically during the import process. If they do manually erase merge history, the tracking of changes made up to that point is lost, and the change file will be incomplete.

Throughout this process, team members will continue to save their work. Typically, team members will be working in a local repository and the project will be saved automatically. If an export is required, team members should export changes. Students using the University Edition should use the special Work in Progress export option.

Export Project Database Changes

Upon completion of this update cycle, each team member captures their design changes by using the export command. To ensure that only the changes are exported, the team member must select the Project Database Changes export. This file contains all changes that have been made during the update cycle. The resulting GNSX change files are submitted to the project administrator via LAN, team collaboration site, or e-mail.

Import Change Files

The change/update files are imported one at a time into a copy of the master project, incrementally updating the master until all team member files are imported. If desired, the project administrator can run the project compare report to evaluate the changes.

Any conflicts that are detected during an import operation are placed in a conflict file and the project administrator is notified. An example of a typical conflict is the case in which two team members each create a function with the same name. When the second of these change files is imported, the naming conflict is noted, and the project administrator must resolve it.

At this point, the project administrator has a new master project database and can begin the cycle again.

Planning for the Update Cycle

Since the team update cycle involves incremental updates of the master database during the last part of the cycle as described above, many problems can be avoided with proper planning. Ideally, team members can work with a segment of the design database that is uniquely theirs. Updates that involve more than one team member segment, such as interfaces, should be made at the master level. Names of entities that are in more than one segment should be changed only at the master level, not at a subordinate level. Naming conventions will minimize the number of name conflicts.

In other words, all system engineering efforts should start with a good set of policies and procedures. The use of an automated system engineering support tool does not negate the need for such practices.