Categories
Search


Advanced Search
 »  Home  »  General  »  Independent Systems Engineering vs. Programmatic Systems Engineering
Independent Systems Engineering vs. Programmatic Systems Engineering
by Testability.com Author | Published  4/22/2008 | General | Rating:
Independent Systems Engineering vs. Programmatic Systems Engineering
The awarding of DoD Programs has continued to evolve over the recent decades toward a culture that exploits the concept of “Teaming” on the development of complex products or systems for many major programs. This concept appears to allow contractors to leverage each Team member’s particular strengths in their respective areas of expertise into a unified partnering environment. To facilitate this objective, the partnering environment must agree upon a mutual acceptable means and mechanism to integrate these individual products together into the developing of a superior end-product.


This is truly a noble concept and may have the potential to harvest many broad-based benefits. However, these benefits fail to be substantially realized due to converging design areas that must bear the burden of cross-partner product development gaps. These gaps are not easy to identify or manage without strong system-level product design resulting from specific diagnostic requirements flowed and tracked down to suppliers and across to team partners via a mechanism that can effectively “communicate” with this information exchange. We are not speaking of a simple mechanism that merely addresses the exchanging of data, but rather to a much more eloquent mechanism used for the exchanging of the knowledge of the interrelationships of the design and their interrelated diagnostic characteristics as they ultimately become grouped and buried within the various complexities of the system.  Additionally, this mechanism must be able to respect the sensitivities and the proprieties of lower-level design contractors and suppliers while contemporaneously enriching the overall diagnostic capabilities of the integrated system.  And further, this same mechanism must be able to perform this cross-partner diagnostic development and integration role while serving as an effective means in the assessing and accounting for each partners’ or suppliers’ individual product(s) to the overall integrate diagnostic performance within the end-product or system.


To date, such mechanisms that facilitate the cross-partnering development of the diagnostic or prognostic design, have not been recognized as a practice that extends beyond the boundaries of the individual diagnostic development within each independent Systems Engineering practice adopted by each Team partner on the end-product design or Systems Integration program. Systems Engineering, with respect to the development of the diagnostics, has not been traditionally used, nor properly taught to consider the requirement to incorporate the concept of cross-partnering through the walls erected on either sides of the individual Systems Engineering practices by each individual contractor or supplier on this partnering “Team”. Each Team partner may often maintain its own Systems Engineering practice that it shall employ in the development of it’s component that it designs for the Program.


 

Comments
Article Options
Popular Articles
  1. Optimizing Test Strategies
  2. The Birth of Design for Testability
  3. Independent Systems Engineering vs. Programmatic Systems Engineering
  4. Designing for Health; A Methodology for Integrated Diagnostics/Prognostics
Popular Authors
  1. Testability.com Author