< Day Day Up > |
5.2 A case study-Information management and PLC
The PLC model described in the previous section describes the development and maintenance processes in general terms. In practice, companies have their own process models, which are usually a variation of the generic model. Companies frequently use their own vocabulary to emphasize particular activities or the overall goals of the development process. In this section, we will show activities and the information flow in the development process of the PLC model used by the telecommunication company Ericsson [4], which develops complex products consisting of both software and hardware.
5.2.1 Development and maintenance of a hardware-based product
Figure 5.3 shows a development process[3] and the information created during different phases. In the subprocess business opportunity, the product manager identifies customer needs that cannot be satisfied by existing products in the product portfolio, or different opportunities to increase performance, or to obtain a competitive advantage by providing a new product, or new technologies and standards that customers require. This builds the scope for the new product. The business case is stored in the PDM system. In the subprocess define product content, the prestudy is initiated, and system engineers, designers, the CM manager, and the project manager begin to define the implementation proposals, CM plans, and project specifications. The requirements are written in requirement documents and stored within the RM tools. All other documents are stored in the PDM tool. A design base including this information is defined, either created or taken from an existing base. The design base will be found in the CAD/CAM or the design archive. After the identification of requirements, a detailed content of the product is specified. The system architecture, an initial product structure, interface specifications, and function specifications will be written and fed into the PDM tool. The requirements will be redefined and refined if necessary. A product implementation description will be developed from the requirements and product content specifications. Information from the design will be imported into the CAD/CAM tool. If a requirement must be changed or added, a CR must be performed. The CR will be documented and analyzed, and the CCB will decide whether or not to introduce the change in the product. The CR will be managed in the CR tool. When the detailed specification is ready, the subprocesses design and implement and after that verify product will begin. The product structure will be refined, the design of hardware documents obtained net lists generated, test cases written, and test cases performed. For example, to verify a printed circuit board (PCB), a manufacturing team designs the PCB, tests the design, and produces a new prototype of the PCB. This procedure may be repeated several times until the PCB is tested and found to function satisfactorily. Before full-scale production begins, the manufacturing team will perform a prerelease of the PCB to check the production machinery. Before beginning production, a verification of the entire system will be performed (a test in which the system requirements will be tested against its performance, and the characteristics and performance of the system will be measured). During the development phase, CRs and trouble reports (TRs) will be managed in the TR tool. The CCB decides whether CRs and TRs are to be managed at weekly project meetings. Information will accumulate in the PDM system, in the design archive, and in CAD/CAM tools. The subprocess exhibit product in operation follows the product verification. The delivery structure is then defined, product revision information written, and the TR process initiated. Marketing activities will begin. Product catalogs, brochures, and other marketing documents will be written on the basis of the description of the new product. Product portfolio plans will be prepared in accordance with the company's business strategies. All of these documents will be stored within the PDM system.
Figure 5.3: An example of processes and information storage for hardware development.
The product information is managed by different tools (e.g., requirements will be stored in a database used by the RM tools, error reports and requests for changes in CR and TR tools, and product structures and BOM in the PDM system or in the CAD/CAM tools). Marketing documents will be stored in the PDM system.
Figure 5.3 depicts the process, activities, information, and use of different-types of databases. We can see from the figure that a PDM system has a central role.
5.2.2 Development and maintenance of a software-based product
Ericsson uses the same development process model for its software products. The particular procedures and information are, however, different. Figure 5.4 shows a development process for software products. The subprocess business opportunity is the same as for hardware products.
Figure 5.4: An example of processes and information storage for software development.
Similarly, the overall functionality for this new product will be defined in the subprocess define product content. The requirements are written in requirement documents and stored within the RM tools, and the design base is defined. The design base will be created in the design archive and saved in a PDM system, and the design-related information will be added into the SCM tool. If a requirement must be changed or added, this must be done under change management. A CR will be created and analyzed and the CCB will decide whether to introduce the change. The CR will be managed by the CR tool. When a detailed specification is ready, the subprocesses design and implement and verify product will begin. Use cases, source codes, detailed design descriptions, test cases, and user documentation will be written, executable files generated, and test cases performed. During the development phase, CR will be managed in the CR tool. Later during the product maintenance TRs will be used for reporting errors and introducing changes into existing products. As CRs and TRs are very similar, they will be processed by the same tool (e.g., the TR tool). The CCB makes decisions about CRs and TRs in weekly project meetings. The subprocess exhibit product in operation includes activities similar to those for hardware products.
However, there are two significant differences: no production machinery is used, and the product manufacturing will most often be performed by the same team (i.e., the development team). The product information needed for sales and service will be saved in the PDM system.
We can observe from Figure 5.4 that the activities are similar (or the same), but tools are used differently. The development is SCM centric (i.e., information is concentrated around SCM). We can also see that PDM tools are used also for software development.
[3]To emphasize the importance of time-to-market constraints, Ericsson designated this model as the time-to-market process.
No comments:
Post a Comment