• No results found

Chapter 7: Interface Management Framework

7.3 Interface Identification

Management of interfaces starts with the identification of the interfaces. The interfaces occur between the sub-systems and components as described in the SBS. The FBS, RBS and SBS are used as three main perspectives from which the interfaces could be subtracted. The functional decomposition could reveal functional interfaces, which might be missed when only considering the objects and requirements. Relations between the sub-functions could be recognized as functional interfaces. Looking at the requirement decomposition; all contractors derive the requirements which are related to their scope. Some requirements have to be fulfilled by multiple parties, leading to a relationship between the contractors which have to be managed. Think for instance of a requirement for the minimum capacity of a lock. This capacity depends on the size of the lock, the speed of the lock doors to open and close, the time to fill and empty a lock, and the reliability and response time of the software used to operate the lock. These aspects are designed by several parties and all have to be integrated in order to fulfill the underlying requirement.

The most sufficient way to reveal the physical interfaces is to look at the physical decomposition as elaborated in the SBS. A N²-chart, which is a matrix with the sub-systems or components on both axis, could be used as tool to identify all internal interface possibilities (Prorail and Rijkswaterstaat, 2013). One of the major advantages of the N²-chart is that the developer is encouraged to systematically think about any possible relationship, between all objects in the system. See the figure below for a simplified example of a small tunnel for badgers.

Figure 33: N²-chart of a tunnel for badgers (Prorail and Rijkswaterstaat, 2013).

The N²-chart could entail different levels of detail. The lower the level of detail, the more interfaces will arise and the bigger the chart will be. A higher breakdown level, like the sub-systems, would allow the N²-chart to have a better overview. However, in practice the decomposition should be implemented to the level at which the entire system can be managed. It is not advised to work with a higher breakdown level since crucial information could be lost, and interfaces may be missed. It requires some experience to draw an N²-chart and determine the correct breakdown level so that no critical interfaces are missed. Therefore, it is advised to hold on to the decompositions as defined in the SBS.

71

Technical University of Delft Ballast Nedam At the beginning of the project, when not all detailed components are known yet, the main types of interfaces between the sub-systems could already be identified. With the help of a N²-chart in where all project teams, and main sub-systems, are placed, all main, high level, interfaces could be identified. A simplified version of such a N²-chart of the Johanfriso Sluis is displayed in Figure 29, on page 56. The different types of interfaces will help to understand what the main interfaces are, and could assist during the identification of the interfaces between all objects. As the project progresses, new indentified interfaces could be categorized by the main interface types, and be placed in the Interface Breakdown Structure (IBS).

All interfaces between the components are identified with the help of a N²-chart based on these components. It is recommended to order the component based N²-chart on the contractors involved. By dividing the chart into the several contractors, the inter- and intra-disciplinary interfaces can be distinguished relatively quick. As described in chapter 6, especially the inter-disciplinary interfaces are responsible for the current interface issues. An example of a N²-chart, based on the SBS of the Johan Frisosluis in Stavoren, can be found in Figure 34. Each square, or ID-number, will represent an interface between those parts.

Figure 34: Example of a discipline based N²-chart.

The colors in the N²-chart quickly reveal what parties are involved regarding an interface. Each block shows all possible interfaces between two contractors. As can be seen in Figure 34, the involvement of four contractors in the project means there are four possible contractors to have interfaces with. Interfaces between components of the same company, the intra-disciplinary interfaces, could easily be recognized by color and should not be covered in the interface meetings. These are the responsibility of the individual contractors, and will be handled internally.

Next to a division by contractor, the N²-chart could also be ordered by components falling under the same sub- system. Because the sub-systems of a project are usually based on physical locations or other strong relations, most interfaces are likely to fall within the sub-system itself. Especially in larger projects, where the sub-system is managed by a separate person, it could be sufficient to see what interfaces fall within the sub-system (and the scope of this manager), and what interfaces exist with other sub-systems. See appendix B for an example of a sub-system based N²-chart. By ordering the N²-chart in these two ways, it becomes clear what interfaces fall within and outside the sub-system, and what interfaces fall inside or outside the scope of the involved contractors.

The identification of interfaces mainly happens during so called interface meetings. These meetings are arranged by the interface manager, in where all involved parties are invited. Next to the design teams, also members of other project disciplines like planning, construction and maintenance should participate in the process. These interfaces will be identified by all team members of the project, using the design documents, SBS, FBS, RBS, and all contract documents. If available, interface registers or lessons learned documents of

72

Technical University of Delft Ballast Nedam reference projects could be consulted. However, the identification of interfaces is mainly based on the experience and common knowledge of the project members.

As explained, the earlier interfaces are identified the better. Therefore, the emphasis should be on identifying all interfaces as soon as possible. The first interface meeting ‘the interface kick-off workshop’ will be a workshop in where the majority of interfaces should already be identified and specified. At the workshop all possible options in the N²-chart will be discussed, one by one, to reveal all interfaces. For all the inter- disciplinary marks in the matrix, an Interface Register (IR) will be developed in where all interfaces are listed by ID-number, while all interfaces are also placed in the IBS based on the main types of interfaces. In addition, it is advised for each contractor to open an additional IR for their intra-disciplinary interfaces.

When all possibilities have been discussed, the majority of interfaces, including their involved contractors, should be identified. However, as said, the identification of interfaces is a dynamic process. During detailing more and more interfaces will be revealed. When a project member discovers a new interface, he has to report this interface to the interface coordinator of his design team. The interface coordinator will consult the interface manager who will place the interface in the IR. As the project progresses, interface meetings will be held on a frequent basis to handle new or changed interfaces, and to work out all crucial and outstanding interfaces.

Related documents