Analysis and Applications of Design Structure Matrix, Domain ... - MIT

More documents

Recommendations

Info

the OSI, and then the degree of coupling is much larger, and probably problematic to designers, than what was originally anticipated by viewing the DSM. Additionally, it is important to distinguish whether systems are built to standards or built to the prevailing Commercial Off-The-Shelf (COTS) system when determining degrees of coupling. (Dahlgren 2007) While the use of COTS in government systems was meant to provide an option (a right but not an obligation) to use commercially developed products produced under commercial Research & Development efforts, the unfortunate reality has become that as some COTS products have come to dominate the industry, then the use and upgrade of these products become an obligation and thus is no longer an option. Each coupling identified in the DSM should be evaluated according to whether COTS products are used and the degree of coupling. In an effort to quantify degrees of coupling, and then to be able to quantify whether systems are tightly or loosely coupled, the following formula was developed. (Dahlgren 2007) These formulas attempt to take into account the couplings identified in the DSMs, the possible considerations for each level of the OSI stack, and the coupling to COTS. These formulas are not all inclusive. Systems not related to Information Technology may not need to be evaluated according to the OSI stack. Systems Engineers should attempt to determine if a modified factor needs to replace the OSI factors and the COTS factor. m n Coupling Coefficient = ∑ OSI i [ ∑ S i S j ] number of possible tight couplings i = 1 j = 1 j = 1 n COTS Portion of Coupling Coefficient = ∑ S (COTS)i S (COTS)j /Years to upgrade j = 1 j = 1 When subsystems are found to be tightly coupled, engineers need to determine if new interfaces should be inserted such that the subsystems are tightly coupled to the interfaces, yet can still evolve separately. In some cases, those interfaces may become system standards for future designs. Theoretically, if each system remains coupled to the standard, then they can be loosely coupled to each other and evolve separately at their own clock speed. Systems engineers and program managers should attempt to include standards and show that coupling in the DSM/ESM framework. A judicious use of standards and interfaces can greatly lower the degree of coupling on a major system. Unfortunately commercial vendors can attempt to “tweak” the implementation of standards to form what might be considered a “semi-proprietary” solution, leading to a developer-forced proprietary solution and tight coupling for most customers and applications. 16 of 31
Coupling can also relate to processes and organizations. For instance, DSM techniques can be applied to the original design of an organization or to the redesign of an organization (Dahlgren and Cokus 2007). The type of information provided in an organizational DSM can also aid designers to determine the degree of coupling that is required between individuals performing the functions. For instance, in a small world network an organization has a mix of tight and loose couples. Those people requiring tight couples may need to communicate or interact frequently. Those people may also need to be collocated together to improve efficiency and effectiveness. Furthermore, by looking across social and technical domains, a DSM that shows the linkage between people on a project and between tasks may help engineers and managers improve understanding of the organization evolution. The clustering coefficient (CC) is the organizational equivalent of the coupling coefficient for component DSMs: CC = # tight connections/# possible tight connections (Barabasi 2003). Too many tight connections will lead to a task or project that fails to utilize long-reach connections to leverage work done by other organizations (Dahlgren 2007). MITRE recently applied coupling techniques to analyze a components-based DSM for VISA International. (Cokus and Dahlgren 2007) MITRE used high level DSMs in the analysis of historical changes of the four major subsystems of VISA International: credit card, card information reader, transmission system, and data base. The case study visually demonstrated the system change over time and how VISA International’s subsystems became more loosely coupled. Interactions were ranked as High, Medium, or Low to show historical system changes. As the subsystems became more loosely coupled, the overall VISA International system became more efficient to operate and easier for the customers to use (Cokus and Dahlgren 2007). Transactions were completed much faster and likely with much greater accuracy, which helped make credit cards a useful tool. Real Options To better manage the uncertainties surrounding engineering systems, engineers are devising new methods to designing systems that are flexible. “One of the challenges for designers is to identify where in the system to lay in flexibility, or real options, that allow systems designers and managers to easily change the system in order to maximize benefit and minimize cost.” (Bartolomei 2007) Strategies and methods for valuing flexibility are well documented in real options literature; however few have focused on how to screen a system to identify the best opportunities for options, or the “hot” spots in the design. Real Options Analysis (ROA) can be applied “on” a system or “in” a system. (Wilds and Bartolomei, et al 2007) When analyzing options “on” a system, flexibility is external to the physical design. Alternatively, real options analysis “in” a system requires the flexible option be internal to the physical design. A real option “in” requires deep knowledge about the structure and behavior of the technical system. ROA tools can be used by system designers, manufacturers, and consumers alike to make informed decisions about the value of adding flexibility to the system at various stages of development. This is most useful early in the development process when opportunities 17 of 31
Page 1 and 2: Massachusetts Institute of Technolo
Page 3 and 4: ut rather removes all or some relat
Page 5 and 6: DSMs do not work well with negative
Page 7 and 8: Figure 2 DSM/DMM Framework (Source:
Page 9 and 10: System Drivers Stakeholders Objecti
Page 11 and 12: Table 1 Classical DSM Techniques fo
Page 13 and 14: ack to the depot maintenance units.
Page 15: the connectedness of each node. And
Page 19 and 20: identification of exogenous sources
Page 21 and 22: Figure 5 Example of Clustering Appl
Page 23 and 24: The stakeholder domain implies a cl
Page 25 and 26: differed over time, and thus warran
Page 27 and 28: information from multiple domains i
Page 29 and 30: Danilovic, M. and T. R. Browning (2
Page 31: Suh, N. P. (1995). “Designing-in

Analysis and Applications of Design Structure Matrix, Domain ... - MIT

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?