Next: 6 Reference List Up: Appnotes Index Previous:4 Implementation of the RASSP Configuration and Authorization Management Models

RASSP Information Management Appnote

5.0 Lessons Learned

The following lessons were learned from the application of the RASSP enterprise system to the benchmark programs:

It was discovered that the concept of a private workspace, as defined within the RASSP CM model, is very difficult to apply to the domain of electronic systems design. This is because many of the CAD tools, used for designing electronic systems, create a single design database and partition it internally to permit access by multiple designers. So the concept of each designer storing portions of a CAD tool design database within his private workspace will not work. For example, the schematic for a PCB cannot be stored in one designer's private workspace while the layout information is stored in another designer's private workspace because the CAD tool stores all the information regarding the PCB design within one design database.
The solution to this problem was to modify the RASSP CM model to include the concept of a group workspace. A group workspace is defined as the place where shared data resides during development. It exists at the same level as a private workspace within the workspace hierarchy. The difference between a group workspace and a private workspace is that all designers have access to the group workspace. It is implemented at the file system level as a common directory to which all designers have access. An example of shared data, which would reside in the group workspace, is a Mentor Graphics Corp. design database. Upon completion of the design cycle, the shared data is then promoted up to either the shared or global workspace, as defined in the RASSP CM model, by checking it into the AIM PDM system.
The RASSP electronic design workflows, in general, represent the ideal "best case" design cycle. The benchmark programs did not follow best case design scenarios and customization of the workflows was required to handle unique situations. Even with the customizations in place, situations were encountered that the workflows were not set up to handle. On-the-fly modifications were required because it is difficult to predict and anticipate what problems will be encountered during the design cycle. When this happens, designers cannot wait for the workflow changes to be implemented and will work outside of the system to stay on schedule and to accomplish their goals. The lessons learned here are:
- more communication is required between the domain experts (e.g. FPGA designers) and the workflow developers so that workflows may be developed which better models their design process
- workflows must provide for as many contingencies as possible, i.e. be "worst case" vice "best case" design that uses the philosophy of "what could go wrong will go wrong"
- further advances in workflow tool technology are required to provide a capability to better handle exceptions to design cycles and ad-hoc situations so designers are not forced to work outside of the workflow tool
A complex system such as the RASSP enterprise system is going to require fundamental changes during its use on any project. Examples of fundamental changes include encapsulating new CAD tools, modifying the workflows, and adding new users. These types of changes cannot be avoided because things like new people being added to a project, or changes in project scope often occur. In order to make these types of changes to the enterprise system, it had to be taken off line. After making the modifications, the enterprise system had to be brought back on line and restored back to its original state. The lessons learned here include:
- the need to better plan for changes, perform them after hours so as not to adversely affect the benchmark teams
- the need for better communication between the benchmark teams and the enterprise system developers to minimize the frequency of these changes
System administration of the RASSP enterprise system needs to be performed by someone who is part of the regular systems administration group. Due to the developmental nature of the Enterprise system, the role of RASSP enterprise system administrator was performed by a member of the enterprise development team during the benchmark programs. The lack of communication between the RASSP enterprise system administrator and the services group caused some problems. For example, the upgrade of one designer's machine from the SunOS 4.1 operating system to the Solaris operating system resulted in that designer not being able to use the enterprise system. The way to prevent these types of problems from occurring is to have the RASSP enterprise system administration functions performed by someone who is cognizant of system administration and is part of an organization's services group. This can easily be accomplished through training and is not expected to be a large burden on the system administration staff.
The RASSP enterprise system was still in development while being used on the benchmark programs. Consequently, the benchmark teams encountered problems that should have been discovered and corrected during a normal testing phase. An example of a problem encountered was the inability of the DMM workflow tool to permit multiple designers to execute the same workflow step. Encountering problems like this often resulted in the benchmark teams working outside the enterprise system until they were corrected. The lesson learned here is that if a system, such as the RASSP enterprise system, is to be used while still in development, a plan must be put in place governing its use. The plan must specify the current and planned capabilities along with the development schedule. Upgrades to the system, such as installing new versions of Oracle, AIM, and DMM need to be performed during off-hours because they involve taking the system off line during the time the upgrade is being performed.
New users of the RASSP enterprise system should receive at least one week of training before using it. During the benchmark programs, insufficient time was allocated for training the users of the enterprise system. Due to ambitious project schedules, members of the benchmark teams were only able to attend a 1 hour training class before using the system.

Next: 6 Reference List Up: Appnotes Index Previous:4 Implementation of the RASSP Configuration and Authorization Management Models

Approved for Public Release; Distribution Unlimited Dennis Basara