< Day Day Up > |
5.3 Complex products
5.3.1 Structures of complex products
Most relevant products consist of many components and are developed as complex systems. A complex system consists, per definition, of many parts (called subsystems or components), and to cope with this complexity its development process is performed by different teams. The teams use different technologies and procedures to develop their specific type of documents and components. The result from each team is assembled on the system level to give a final product ready for production or delivery. Common to all product development activities is the necessity to manage data on the system level, between the teams, and within the teams.
On the system level, in addition to information about components, information about the contents of the products, customers, vendors, suppliers, baselines, releases, prices, and markets are needed. The project manager must know if the project is following the time schedule. The CM manager needs to know the current product configuration and its status, as well as related documents for the entire system and for all components (subsystems) included in the system. The designer must have access to requirements documents, project specification, and all information related to the product to be developed. The production engineer needs to find all documents related to a product ready for manufacturing. The sales person needs to find information about the product to present to a customer. There are many different roles within the company that need access to the right information about the right product at the right time. All of this data, created by different subsystems, must be available on a system level.
Figure 5.5 shows examples of systems and subsystems of different kinds of products. Figure 5.5(a) shows a system containing three different subsystems developing-mechanical, ASIC, and electronic. Products developed from the different subsystems will be integrated and tested on a system level before the product will be manufactured and shipped to customers. Figure 5.5(b) shows a pure software product in which all subsystems develop different parts (components) [4] of the software. The software will then be integrated and tested on the system level before it will be available for delivery to customers. While the required support at the subsystem level is strongly software related, at the system level the support required is more similar to the support for hardware products. On the system level, mostly data about the products (i.e., metadata) is used, rather than direct product data. Figure 5.5(c) shows an example of a complex product that includes both software and hardware components. Once again, the procedures, technologies, and hence the support required are specific at the subsystem level, but common at the system level. At the system level, the differences between the subsystems are disregarded and each subsystem is treated in the same way, irrespective of whether it is a software or a hardware component.
Figure 5.5: Product development configurations.
5.3.2 Information flow
The information flow is not directed only from the subsystem level to the system level. In the beginning of the development process, much of the information that will be used at the subsystem level is generated at the system level. A development process begins at the system level in which the overall goals, constraints, and requirements are identified, and an overall design of the system is prepared. Further, the system is developed by a successive division into subsystems, which can be developed in parallel, followed by their integration. This process is shown in Figure 5.6, in which we distinguish processes from life cycle models. A process consists of activities, while a life cycle is characterized by states and milestones. A system or a component is in a state during the performance of particular activities. The activities are concluded when their goals, which are indicated by milestones, are achieved. The entire process can be divided into three parts-a common part in which activities related to the system are performed and information needed later in all subprocesses is obtained, an independent part in which the subprocesses are progressed in parallel and the information in each subsystem is generated independently of other subprocesses, and finally an integrated part in which the information from all processes must be accessible and integrated in common information.
Figure 5.6: Complex PLC.
In Figure 5.6 we can also see when, at certain points in the development life cycle, common activities are divided into separate activities and when they are merged together again. At these points, it is important that all system-related information is easily accessible and that it is possible to import this information into the tools used in the activities in the subsystems. Figure 5.1 and Figure 5.2 show the information flow through the phases of the parallel subprocesses. From these figures, we can summarize that we need the information flow of the following assets:
From common activities to the parallel hardware and software activities, we need requirements, CRs, and overall system design (defined partly by a product structure). We also need information related to the project management.
From the parallel activities to the integration phase, we need the refined requirements, final detailed design, and final deliverables (executable code for software, prototype specifications for hardware, and documentation for both).
From this, we can conclude that both hardware and software development processes should follow common procedures for product structure management, RM, change management, and document management in general.
5.3.3 Integration
PDM tools deal with metadata and have advanced functions for data retrieval, data classification, and product structure management. This implies that PDM tools are suitable for managing the system level. For development of hardware products, PDM includes or is well integrated with many development tools (e.g., CAD/CAM). In this way, PDM supports procedures at the subsystem levels. However, there is no, or inadequate, integration of PDM tools with software development environments. This means that for a product configuration shown in Figure 5.5(a), a PDM tool can be used successfully, while this is impossible for products of the types shown in Figure 5.5(b, c).
SCM tools are, of course, not integrated with hardware development environments and therefore do not support product configurations as shown in Figures 5.5(a) (pure hardware) and 5.5(c) (hardware and software). The question is whether SCM can support pure software products. SCM tools do not provide complete support on the system level. As a product becomes increasingly complex, many activities at the system level are not strictly related to the pure software domain, and the efficiency of SCM support then becomes much less than at a subsystem (development) level.
[4]There is a difference between subsystems and components. A subsystem is an integral part of the system, while a component can be a part that is independent of the system. A component can be used in different systems, developed independently of the systems, and easily replaced. Most of the hardware products are developed from components. This is also a noticeable trend in software development, although many concepts of component-based development of software systems are not yet precisely defined and established in practice.
No comments:
Post a Comment