Search

A project-based course involving the design, analysis, manufacturing, testing, and launching of mid-power solid-propellant rockets over a ten-week period has been developed and taught as an approach to enhance the education and preparation of aerospace engineers at the university level. The course consists of a sequence of structured laboratory assignments that expose students to common software tools, aerospace materials, manufacturing techniques, and testing methods that directly inform and run parallel to the project. Teams of four to five students complete the project (and portions of the labs) collaboratively within an engineering competition framework. Individual students within each team are assigned specific engineering roles (e.g. design engineer, manufacturing engineer) to create an interdependence that reflects a typical integrated product team in industry and exposes students to realistic social dynamics. Student teams conduct design reviews as progressive milestones for assessment, in addition to laboratory assignments. At a per-student cost on the same order as a textbook, the project-based course combines theoretical content from several subjects with a high-order learning approach (create, evaluate, analyze) to advance the engineering skills of university students.

Purpose. This article discusses the process of developing an ergonomic desk for students through an integrated product team approach. Methodology. Using an integrated product team approach, numerou...

The Integrated Product Team (IPT) is a multidisciplinary and multi-university STEM educational project whose goal is to provide the opportunity for undergraduate scientists and engineers to translate stakeholder needs and requirements into viable science and engineering design solutions via a distributed multidisciplinary team environment in a Pre-Phase A design activity. The core of the project is a two-semester senior design sequence where science, engineering, and liberal arts undergraduate students form multidisciplinary competitive teams to develop system concepts of interest for NASA Science Mission Directorate. The two-semester design sequence for the IPT project emphasizes four key principles that are critical for any new scientist/engineer in the competitive environment of today: systems thinking, communication, teamwork, and design. These four principles are taught over four phases in the two-semester sequence: requirements development, team formation and mission architecture development, system definition and development, and system design. Replicating the real world of spacecraft design, the science team members determine the science requirements for the mission, develop the science traceability matrix, select the correct instrumentation to meet the science requirements, and develop the science operations plan. The engineering team members design and develop the spacecraft(s) necessary to accomplish the science requirements and provide computer-aided design models of each spacecraft.

Nora Tgavalekos is chief software engineer for Corporate Engineering at Raytheon Company, a leader in defense, civil government, and cybersecurity solutions. Referred to as a "rising star," Nora was named to this position in 2016 after several years working in different capacities on the Sea-Based Radar (XBR) program. She has been a flight test director, a design and analysis lead, and a deputy integrated product team lead. She also led the radar discrimination team, where she earned a patent for her work developing the technologies that allow the XBR to discern targets among other real-world clutter. Her work earned her the honor of being named to Aviation Week's "40 Under Forty" in the aerospace industry.

Composite airframe structures have been successfully used in civil airplane products for more than 50 years. The service history of these composite applications has generally been very good with few exceptions. A summary of that service history is provided with some emphasis on transport aircraft applications. The few safety-related problems are identified, including some ongoing efforts to document solutions.

A case study approach, based on interviews and document reviews, was used to analyze the systems engineering processes of the SEP (Armored Multirole Vehicle, in Swedish) and the Visby class corvette cases respectively. The focus was on signature management. The result is a thorough investigation of what worked in the cases studied. The main conclusions can be summarized in three points. 1) A preferred workflow from mission analysis to sub system design has been derived from lessons identified; 2) The three main success factors identified were: building technology demonstrators, having an Integrated Product Team approach, and establishing stealth as a key system design goal; 3) Coherence and traceability between military needs on the battlefield and signature requirements need further research.

Analyses of the interactions among quality requirements (QRs) have often found that optimizing on one QR will cause serious problems with other QRs. As just one relevant example, one large project had an Integrated Product Team optimize the system for Security. In doing so, it reduced its vulnerability profile by having a single-agent key distribution system and a single copy of the data base – only to have the Reliability engineers point on that these were system-critical single points of failure. The project’s Security-optimized architecture also created conflicts with the system’s Performance, Usability, and Modifiability. Of course, optimizing the system for Security had synergies with Reliability in having high levels of Confidentiality, Integrity, and Availability. This panel aims at fostering discussion on these relationships among QRs and how the use of data repositories may help discovering them.

Since the decision of blanket redesign by 2007 ITER design review, the blanket system is being developed in the framework of Blanket Integrated Product Team (BIPT) composed mainly of ITER Organizat...

The purpose of the Observatory Software System (OSW) is to integrate all software and hardware components of the Thirty Meter Telescope (TMT) to enable observations and data capture; thus it is a complex software system that is defined by four principal software subsystems: Common Software (CSW), Executive Software (ESW), Data Management System (DMS) and Science Operations Support System (SOSS), all of which have interdependencies with the observatory control systems and data acquisition systems. Therefore, the software development process and plan must consider dependencies to other subsystems, manage architecture, interfaces and design, manage software scope and complexity, and standardize and optimize use of resources and tools. Additionally, the TMT Observatory Software will largely be developed in India through TMT’s workshare relationship with the India TMT Coordination Centre (ITCC) and use of Indian software industry vendors, which adds complexity and challenges to the software development process, communication and coordination of activities and priorities as well as measuring performance and managing quality and risk. The software project management challenge for the TMT OSW is thus a multi-faceted technical, managerial, communications and interpersonal relations challenge. The approach TMT is using to manage this multifaceted challenge is a combination of establishing an effective geographically distributed software team (Integrated Product Team) with strong project management and technical leadership provided by the TMT Project Office (PO) and the ITCC partner to manage plans, process, performance, risk and quality, and to facilitate effective communications; establishing an effective cross-functional software management team composed of stakeholders, OSW leadership and ITCC leadership to manage dependencies and software release plans, technical complexities and change to approved interfaces, architecture, design and tool set, and to facilitate effective communications; adopting an agile-based software development process across the observatory to enable frequent software releases to help mitigate subsystem interdependencies; defining concise scope and work packages for each of the OSW subsystems to facilitate effective outsourcing of software deliverables to the ITCC partner, and to enable performance monitoring and risk management. At this stage, the architecture and high-level design of the software system has been established and reviewed. During construction each subsystem will have a final design phase with reviews, followed by implementation and testing. The results of the TMT approach to the Observatory Software development process will only be preliminary at the time of the submittal of this paper, but it is anticipated that the early results will be a favorable indication of progress.

Program Managers responsibilities lie in effectively executing cost, performance, and schedule management of acquisition programs and services throughout the Army. Program managers cannot execute programs without the support and assistance of many stakeholders working with members of the program office in an integrated product team fashion under the leadership of the program manager. The U.S. Army contracting command is a key stakeholder in the execution of all Army acquisition programs.The research provides insight on the planning and development of acquisition as bound by regulation, law, and guidelines then explores opinions of the acquisition workforce through a survey. The survey data reveals valuable information detailing the experiences acquisition personnel share working together as a team. The data shows many areas needing improvement in integrated product team contract planning and development. A disconnect exists in roles and responsibilities as well as early participation by all stakeholders. Integrated team members express a lack of empowerment, risk averse contracting officers, non-participating legal staffs, and diminishing accountability by many. Training under experienced personnel and over tasked workforce dynamics are other areas addressed by the research. The purpose of the research is to provide data derived from multiple Army organizations to explain challenges facing the acquisition workforce. The research provides insight for leadership to actively plan and develop process improvements aimed at alleviating these challenges. The research will promote more efficient contract planning and development in an age where the Army expects to do more with less.

The availability of the ITER machine to perform its scientific program is strongly dependent on the performance of the different Remote Handling (RH) systems constituting the ITER Remote Maintenance System (IRMS). The lifecycle of the IRMS will largely exceed 40 years from initial concept design and proof testing through to machine decommissioning. Such a long lifecycle requires that a rigorous approach is put in place to guarantee the technical capabilities of the highly innovative IRMS, its efficiency and its availability. For this purpose, an IRMS System Engineering and IRMS lifecycle management approach has been adopted by ITER. The approach aims at ensuring the IRMS full operability and availability at an acceptable cost of ownership over the full ITER machine assembly and operations period. The IRMS lifecycle management method described in this paper covers such subjects as specific requirements for IRMS design reviews, monitoring during manufacture, factory and site acceptance testing, integrated commissioning, decontamination, maintenance and re-qualification strategies, requirements for Integrated Logistical Support during operations. The updating and implementation of the IRMS lifecycle strategy and this procedure will be managed and monitored by the Remote Handling Integrated Product Team (RH-IPT). Although developed for the IRMS, the basic principles and procedures of lifecycle management could be applied to other ITER plant systems whose reliability and availability will be essential for the continued operation of the ITER machine.

Since the recommendation of blanket redesign by 2007 ITER design review, the blanket system has been developed in the framework of blanket integrated product team composed mainly of ITER organizati...

The problems of quality management (QM) in traditional consecutive development were analyzed, and it was pointed out that there were essential differences between QM in concurrent development mode and that in consecutive development mode. One was modification or change in work process, and the other was cooperation within Integrated Product Team (IPT) members aiming at product quality improvement. According to the characteristics of concurrent development, QM mode and process models appropriate to Concurrent Engineering (CE) were established. The models were able to demonstrate QM responsibility distribution, specific QM work patterns and flow, as well as quality information processing and transfer among the development phases. The models provided guidance and reference about how to enhance quality management of product development process.

This paper describes the impact of heavier and larger United States Marine Corps (USMC) vehicles, equipment, and aircraft on amphibious ship structure and stability characteristics. The impacts described herein represent the results of an ongoing analysis and study as part of the air combat element (ACE)/ground combat element (GCE) integrated product team (IPT). There has been a growing concern regarding newer USMC GCE equipment and their effects on vehicle deck structural integrity and ship load limitations. Additionally, growth in the ACE and GCE has impacted the overall ship stability characteristics of in-service amphibious ships. This paper aims to provide the reader, whether a novice or an expert in the field of naval architecture, with useful information, describe tools in development, as well as outline the impacts that future designs of equipment may have on existing platforms.

The development process of vibration roller is a collaborative and concurrent process involved with mechanics, electronics and hydraulic disciplines. Poor collaboration among multiple design disciplines can result in frustrating re-work, delayed product launches, blown budgets and sometimes even expensive recalls of shipped products, which is a big challenge to vibration roller development for the traditional Chinese manufacturing enterprises.Workflow technology in vibration roller development is studied and applied in this paper. A workflow model is given, which comprises team member management model and process model. Team member management model defines the organization, the role and the authority of integrated product team (IPT) members involved in the development process of vibration roller. Process model described the general development process of vibration roller, which includes activities, roles related to activities and rules in detailed. According to the models defined above, new workflow software, which is named “Workflow Management System for Mechatronic System” is developed and used to implement the workflow of “the cooperative development of Vibration roller (YZ18JA) of ChangLin Company”. Practice indicates that the implementation of workflow technology can ensure that right information can be delivered to right person at right time in a right way so as to improve the management and control of the whole process, shorten product development cycle and reduce cost.

Successful execution of a program and full satisfaction of the Customer's requirements is a challenge for any contractor. Raytheon Company responds to this challenge by following a proven program execution methodology. The methodology includes all program aspects from financial planning to engineering to validation and test. This paper discusses the engineering team and the role of the mechanical engineer. A radar system is ultimately an assembly of advanced electronics and software. However, the design, fabrication, assembly, integration and test of this complex system require a coherent multi-disciplinary approach. Raytheon, like many contractors, chooses to assemble an integrated product team (IPT) including all engineering disciplines. Mechanical engineering is integral to satisfying performance requirements, performing preliminary and detailed design, transition of the design to manufacturing, and implementation of the hardware in the field. During definition, mechanical engineering assists fundamental architecture development, conceptual design, and requirements development which precludes issues that are sometimes ignored to the detriment of many programs. These design issues include environmental protection, structural stiffness to meet deflection requirements, cooling system capacity to properly remove dissipated heat, manufacturability to control cost, maintainability to enable repair in the field, and transportability. Recognizing and trading off these issues early greatly increases the probability of satisfying Customer objectives. This paper discusses the approach Raytheon is taking to ensure an overall multi-disciplinary solution to our design challenges from the perspective of the mechanical engineer.

The US Navy is currently developing a new class of surface combatant ships referred to as DDG 1000. Unlike past ship designs, DDG 1000 is explicitly focused on the execution of a user-centered approach—one that captures the requirements, capabilities, and limitations of sailors expected to operate the ship. Additionally, DDG 1000 presents a number of significant human factors and challenges related to its greatly reduced crew size (compared with similar legacy ships) and high reliance on automated systems. Usability testing and usability assessments (UT and UAs) for the purpose of validation of human systems integration (HSI) principles, and the validation of the DDG 1000 Sailor Systems Specification (S3), play a key role in the DDG 1000 Human-Centered Design (HCD). Through the use of summative and formative design analysis and design verification events, UT/UA is critical in identifying and rectifying issues early in the design process, and verifying system functionality later in the design process. For the DDG 1000 program, the Human Systems Integration—Design Verification Integrated Product Team (HSI-DV-IPT) has also combined its efforts with both the DDG 1000 Safety and Training Cross Product Teams to realize the economies of scale associated with conducting these tests to obtain data for the needs of all three HCD disciplines. Through the course of the DDG 1000 detailed design phase, UTs and UAs have become a defined procedural process, which is governed by both the DDG 1000 Human Systems Integration Plan and as an extension of the total testing plan for the DDG 1000 ship. Almost all DDG 1000 HSI-DV-IPT evolutions combine the efforts of system engineering and design teams with HSI engineers and fleet users to ensure that the combined test output product has received a “cut” from the entire chain of influence from concept to end user. To date, over 30 user interaction and test events employing 1,100 users have been conducted to verify the utility of aspects of the DDG 1000 design, from the most sophisticated to the most mundane systems and processes. In addition, a series of tools that includes 3D visualization aids for modeling and simulation, and weighted assessment systems like NASA-TLX have been included in the DDG 1000 HSI test engineers' tool bag to provide the best of breed solutions to HCD-oriented testing. The test results obtained to date provided valuable insight into the validity of the DDG 1000 HCD and provided feedback that led to optimization of both crew and ship as its HCD objectives intended, in addition to providing cost-effective and timely feedback into the DDG 1000 design.

The acquisition of Operational Test Program Sets (OTPSs) has been a recurring effort requiring standardization, refinement, and continuous process improvement. Established in 1989, by the ‘Red Team’ integrated product team (IPT) and updated in 2005 as the NAVAIR Generic OTPS Request for Proposal (NGOR), the NGOR acquisition package is used as a Government template in the procurement of OTPSs being obtained for the Consolidated Automated Support System (CASS) Family of Testers (FoT). This acquisition package has been through several minor and major changes since inception. It has included review and recommendations from all Department of Defense services to include the U.S. Air Force, U.S. Army, U.S. Marines, and U.S. Navy. These services and commercial industry use the NGOR as a reference and guidance for future bids and proposals. Foreign entities have also attributed ideas to include approved Foreign Military Sales (FMS). In 2014, the NGOR was revamped to include the NAVAIR Systems Engineering Technical Review (SETR) process. The rigorous and defined process assesses the technical, logistical, and programmatic health of design and development of an OTPS procurement. This paper will further enhance the understanding of this process by assessing the role and value the NAVAIR SETR process has in the acquisition, development, and over all life cycle management of Test Program Sets (TPSs) for the CASS FoT. This assessment will include the total acquisition life cycle from the Analysis of Alternatives (AoA) to the Materiel Support Date (MSD). Additionally, this paper will identify the changes made to the NGOR to incorporate SETR relative to the Statement of Work (SOW), Performance Specification, Contract Attachments, and Contract Data Requirements Lists (CDRLs). This assessment comprises a discussion on OTPS and TPS system performance specification requirements (both generic and specific), SETR milestone and technical events' entry criteria, SETR checklist prerequisites specific to planned contract events, logistical needs, and federal regulatory and statutory requirements.

In the early 1990s, U.S military leaders began to copy commercial enterprises by assembling integrated product teams (IPTs) to adapt and implement commercial cost reduction programs (CCRPs) for military organizations. However, no evidence existed in literature that military IPT performance related to CCRP success. A non-experimental quantitative correlational study was conducted to find whether or not a relationship existed between military IPT performance and CCRP success. A questionnaire distribution yielded 80 acceptable responses, and Spearman’s rank order correlation and ordinal regression were employed for correlation and predictor significance analyses, respectively. The Spearman correlation coefficient analysis results revealed a strong positive relationship between the IPT Performance and CCRP Success, rs = .70, p < .01. The correlation coefficients between each of the six variables of IPT Performance and CCRP Success were IPT Communication rs = .64, p < .01, IPT Coordination rs = .57, p < .01, IPT Balance of Member Contributions rs = .51, p < .01, IPT Mutual Support rs = .65, p < .01, IPT Effort rs = .36, p < .01, and IPT Cohesion rs =.67, p < .01. Ordinal regression analysis yielded three significant predictors, IPT Coordination (Estimate = .23), IPT Effort (Estimate = -.40), and IPT Cohesion (Estimate = .24). Military managers should first assess whether or not their organizational systems are conducive to hosting IPTs and whether or not their organizations contain the necessary resources for hosting IPTs. Future researchers should employ a larger sample and a qualitative study to observe team interactions for identifying characteristics of teams and team members. Keywords: commercial cost reduction programs, integrated product teams, military, team performance, program success, integrated product and process development.

There is a growing body of knowledge in the systems engineering arena trending towards the expansion of traditional systems engineering scope because the most complex, indeed complex adaptive, part of any system is the human. (1) (2) (3) This is particularly important where interfaces with external environments of the system unknowingly directly and heavily influence system requirements. This paper will describe complex domain attributes and utilizing model based systems engineering tools for complex systems. Nomenclature ConOps = Concept of Operations IPT = Integrated Product Team MBSE = Model Based Systems Engineering OMG = Object Management Group SE = Systems Engineering SysML = Systems Modeling Language UML = Unified Modeling Language

The Federal Aviation Administration (FAA’s) Oceanic and Offshore Integrated Product Team is developing a set of performance metrics and identifying methodologies for calculating them. These metrics...

Semantic understanding of the domain for which a system or solution is being developed is crucial. Defining the ontology as part of domain modelling at the onset of a project permits effective effort as you communicate with stakeholders and move into formal definition of requirements. However, there is another Universe of Discourse in play when working as an integrated product team (IPT) on a project. Many times the terms used by the project team are assumed to be understood, but with the complexity of today's systems, the tools used to create project artefacts, and the teams needed to realize solutions, this is not always the case. This paper will present a case study illustrating the method applied to model, using UML, the ontology for a Universe of Discourse that represents the problem domain and the ontology of the project team developing the solution.

Lockheed Martin's C-130J Avionics/Software Integrated Product Team (IPT) creates software that runs a wide variety of systems on the C-130J aircraft. This team develops embedded safety-critical real-time air vehicle software and a ground-based data analysis system for aircraft analysis. The IPT operates within the infrastructure of the C-130J Software Factory, which consists of Sun workstations and PCs networked to Web servers, a configuration management server, an aircraft simulator implemented in software, and laboratories are composed of the aircraft's hardware mounted in equipment racks for easy access. The article discusses the IPT's diverse education and training needs, focusing on how to address shortfalls in conventional computer science and engineering education that result in mismatched expectations between the new hire and the company.

Reducing aircraft design cycle time while improving product quality requires improved information e ow, process optimization, and use of advanced computational methods, including optimization, at critical times during the design process. Computer technology allows the use of highly precise mathematical analysis at all stages of product design. However, mathematical analysis must create added value that exceeds its cost. Selected Russian structural design research references are reviewed to show how novel ideas to improve aircraft structural design have developed during the past four decades. It is also shown how special purpose structural e nite element models (FEM-1 and FEM-2 ), together with formal structural optimization during early design stages, improve integrated product team interaction,identify technicalproblems, and exploitbenee tsforconventionalaswell asradically new designs. This approach includes scientie c weight estimation of critical components. The result is increased quality and reduced development time. Three examples illustrate this improved approach: a mounting bracket design, a fuselage bulkhead connected to a vertical tail, and a wing box design.

The development process of Large and complex systems are a highly complex process involving different disciplines which shall take decision and develop interrelated subsystems. Integrated Product Team is a management tool used to improve system development performance. Among the potential benefits of implementing the integrated product team principles are reduced development time, reduced risk of failure, enhanced quality, flexibility and better knowledge sharing. This paper provides an overview of the integrated product team’s principles and evaluates the lessons and guidance in existing literature applicable to develop large and complex systems. Recommendations based on own experience and lessons learned developing large and complex systems are presented here.

What happens when practices and disciplines overlap? – Wasted efforts, turf battles, redefinition of lifecycle models based on different management, engineering, manufacturing, finance, maintenance and support viewpoints. In short, a proliferation of the ‘way we do things around here’. Systems engineering has become a set of complex processes that are difficult to implement and improve. Too often, either sub processes are developed for lower tier Integrated Product Team performance or for large enterprise level practices which are promoted as ‘Best Practices’ (Heibler 1998). Most often, the linkage at different levels of abstraction is very difficult to see, much less apply. These are difficult to implement for management of larger and smaller projects. Also many projects in an enterprise are at different stages of development, which makes process improvement across the organization difficult to assess and implement. Lifecycle ‘Practices’ and ‘Standards’ are generated as panaceas for good systems engineering and are evidenced as: Systems integration, Systems design, Systems validation, Software engineering, Design to Cost (DTC), Design for Manufacture and Assembly (DFMA), Cost as an independent variable (CAIV), Affordability, Quality Function Deployment (QFD), Supply Chain Management, Robust Design, Risk management, Requirements management, Time-to-market, and Just-in-Time Manufacturing The purpose of this paper is to show how a set of capability improvement models (SW-CMM 1995, SECM-EIA731 1998, CMMI 2000, ISO 9001 1994, ISO 15504 1998) and process definition standards (IEEE1220 1998, EIA-632 1998, ISO 15288 2000, and ISO12207 1995) can be used to test these megapractices for commonality and redundancy. Object oriented (OO) techniques are be used to: 1) identify the validity of megaprocesses, 2) determine which processes belong to megapractices and are common throughout the chosen set, and 3) assist assessors and process improvement practitioners in selection and optimization of best set of practices for the top level enterprise down to team level performance. Conclusions from this analysis are: Systems Integration includes Design Reviews, Integrated Schedules, and Integrated Planning CAIV includes Trade Studies, Requirements, Risk, Cost, Performance (TPMs), and Decision Making Software Development is a large subset of Systems Integration in software-intensive systems

The Affordability Through Commonality Office (PMS 512) of PEO Surface Strike, in order to promote and enable the implementation of Open Systems Architecture (OSA) for Navy systems, established the Total Ship Open Systems Architecture (TOSA) Industry/Navy Integrated Product Team (IPT). TOSA has developed a notional open C4I template which incorporates an OSA. The application of OSA to C4I spaces will increase flexibility, upgradability, scalability, and adaptability and decrease total ownership cost over the lifecycle of the ship. Open systems concepts are well established in the commercial information technology (IT) field as a means to increase competition among vendors (broaden the market applicability and reduce costs). While the benefits of OSA are easily discernable for IT systems, the use of OSA for HM&E ship systems inter-faces represents a new and unproven application. An important feature of the adaptable ship concept is the Functional Element (FE) zone, which represents physical divisions of a ship with managed functions, configurations, interfaces, and characteristics. This paper describes how the OSA process was applied to develop an example FE Zone template for a specific space, a notional Combat Information Center (CIC) zone. The resulting concept may be used to develop a family of templates to open the remaining Command, Control, Communications, Computing and Intelligence (C4I) zones on a ship.

In 1996,the Office of the US Assistant Secretary of Defense (Health Affairs), Clinical Business Area, began investigating the use of object oriented technology for its Computer-Based Patient Record program. It commissioned the CIOOT project (CPR Interoperability Using Object-Oriented Technology) and tasked multiple vendors and government offices to work within an integrated product team. At first, bringing order to the many diverse and conflicting views represented on the team seemed as impossible as herding cats. To deal with the project's complexity, the CIOOT project management team developed a process definition technique based on the metaphors of OO technology. The technique brought about common understanding and a clear project plan and, as a bonus, proved valuable for many other practical purposes.

The U.S. Navy recently conducted an analysis of alternatives (AOA) to set the stage for determining the characteristics and acquisition strategy for its next generation aircraft carrier. The platform design selected is expected to be in service throughout the 21st century. The parameters under consideration for change in the new carrier design lie in the areas of propulsion and electric power generation, aviation, survivability, service life, and total ownership cost (TOC) reduction. The issue of affordability is paramount This paper focuses on the need for the program management office and its supporting cost analysis staff to understand the life cycle cost (LCC) of the existing and proposed future aircraft carriers and to then translate these LCC's into meaningful information for cost-conscious decision making. The challenge is to relate the LCC in terms the key decision-makers and the engineering team can use to satisfy their respective roles. Thus, it is necessary to translate the results of the given ship design alternative LCC's into the paradigms of the respective stakeholders: 1 Fleet User (operators of aircraft carriers) 1 Ship Designers (translators of the fleet operator requirements) 1 Program Sponsors (providers of the funding resources) 1 Program Management Office, Shipbuilder and Supporting Industry (executors of the acquisition and construction of the ship) 1 Navy and OSD decision-makers (overseers of program execution) The paper describes the aircraft carrier LCC breakdown structure that has resulted, in part from a recent navy/shipbuilder integrated product team effort to capture total ownership costs. The structure has been used in the AOA as a tool to identify cost drivers and to add the time element to the cost equation in order to perform return on investment and program affordability analysis. The expanded ship work breakdown structure (ESWBS) has emerged as the central backbone of the cost work breakdown for AOA work. The ESWBS structure is a natural choice as it is the framework within which the design and engineering community works, it forms the basis of weight estimating for ships, and it has been widely used in ship acquisition cost estimating for years. In addition, the ESWBS provides perhaps the best framework from which to relate to program requirements, as it describes the ship by ship system. The approach, for the first time, provides a breakdown of the operating and support (O&S) cost elements by ESWBS. From this nucleus structure, it is possible to present costs in other required formats such as the: Office of Secretary of Defense (OSD) cost analysis improvement group (CAIG) summary level LCC categories, by ship capability or design feature, and by cost driver hierarchy.

ABSTRACT During the past several years the US Navy and the shipbuilding industry have been working together to develop a cost estimating tool that is sensitive to manufacturing processes and techniques. The Product-Oriented Design and Construction Cost Model (PODAC) Project's charter is to develop a product-based, production driven cost estimating tool that will be used by shipbuilders and the Navy to assess the cost of innovated and advanced technologies proposed for naval application. This paper will highlight the progress of the model development and the future direction of the project. Additionally, the PODAC Integrated Product Team (IPT) has been installing and implementing the PODAC Cost model at five major U.S. shipyards and within the Naval Sea Systems Command (NA VSEA) over the last twelve months. A structured evaluation of the model has taken place at several shipyards. The evaluation process was conducted in terms of technical or engineering trade-off studies. The findings and recommendations of one of these studies are discussed.

Defense contributions to the Programmable Modular Communications System (PMCS) Integrated Product Team (IPT) included designs for an RF module based on software radio configurations useful in airborne systems. Several configurations were examined, analyzers were consolidated, and concepts of operation (CONOPS) were evaluated. Geographic separation of platforms and on-board separation of radio modules have consequences for the remote control of reconfigurable radios. This paper identifies organizational roles in software radio development, characterizes the need for software radios in airborne applications, and highlights those configurations found to be attractive. The methodology, CONOPS, and conclusions are summarized.

In response to market pressures for higher quality and lower cost products, many organizations are implementing concurrent engineering (CE) techniques to improve their product development activities. Unfortunately, some of these implementations have not met expectations. This article reports on the use of a modified readiness assessment for concurrent engineering (MRACE) method that identifies organizations' strengths and weaknesses. This tool was derived from the original readiness assessment for concurrent engineering (RACE) method first proposed in 1992. The modified assessment, which increased emphasis on team and product development processes, supported an integrated product team (IPT) tasked with developing the Army's next generation 120mm kinetic energy tank bullet. This article discusses developing and applying MRACE, the resources required, a follow-up assessment, and how this method can be applied to other organizations.

Why a 10-centimeter cube? The trademark size of the CubeSat emerged somewhat accidentally, recalls Jordi Puig-Suari, an aerospace engineer at California Polytechnic State University. Student-built satellites date back to the 1980s, but they were often unwieldy. Not only were they expensive to launch, but commercial rocketeers were also wary of packing them alongside primary payloads. But in 1999, Puig-Suari met with Bob Twiggs, at the time an aerospace engineer at Stanford University, to discuss ways of getting more student projects into space. They focused on slimming down the spacecraft. They thought hard about the potential capabilities of a 10-centimeter cube with a mass limit of 1 kilogram and found the perfect life-size demonstration model: a plastic box used for storing Beanie Babies. A standard was born. In 2003, the first six student projects rode a Russian Eurockot into orbit, for about $30,000 a pop; early on, the biggest single expense was the ride, though in recent years, launch prices have stayed put around $100,000 for a 1U CubeSat. Many early CubeSats tackled problems in space weather, but other areas of science are opening up, and some scientists think CubeSats can play a role far beyond low-Earth orbit. CubeSats are also opening space to new participants; Bruce Yost, deputy manager of the small spacecraft integrated product team at NASA9s Ames Research Center in Mountain View, California, calls it "the democratization of space."

In its contract for development of a new amphibious ship, the LPD 17, the US Navy required the use of Integrated Product and Process Development (IPPD). Raytheon Systems Company's Naval and Maritime Systems (NAMS) is one of the four members of the partnership which won the contract. NAMS is leading the Integrated Ship Electronics Team (ISET), the top-level LPD Integrated Product Team (IPT) responsible for integrating the ship's electronic systems. In a unique adaptation, ISET purposefully enhanced its implementation of IPPD by special emphasis on two additional “Ps” people and profit. This “IPPPPD” approach produced some significant changes in certain program practices and activities. The focus on people manifested itself in how the program chose its team leaders and team members, how it aligned the individual teams and its team structure, and how it shaped the behavior of its people to support its IPPD practices. Its emphasis on profit required its teams to take responsibility not only for their technical work, but also for the related programmatics and contract issues.

The government and contractor program managers for the Navy's Advanced Deployable System (ADS) have implemented an Integrated Product and Process Development (IPPD) methodology for development of their system's Underwater Segment. A key element in the success of this methodology has been the effectiveness of the leadership provided by the government-contractor Systems Engineering and Management Team (SEMT). The team's leadership approach is focused in three areas: leadership techniques, engineering and business management activities, and technical direction efforts. The team's effectiveness has been enhanced through an investment of resources to establish and implement a clear and executable program baseline, a disciplined development approach, effective communications, which are facilitated in large part by team collocation, and responsive decision-making and course corrections. This paper describes the methods of the SEMT and how it contributed to the success of the Underwater Segment Integrated Product Team (IPT).

The potential for improved weapon load outs on advanced aircraft was recognized by the Wright Laboratories, Munitions Division as a key enabling technology for dramatic improvements in the system performance and affordability. The dilemma faced by the Laboratory was the plethora of enabling technologies, and design concepts. Their combinations were staggering. Given recent weapon technology investments and varying strongly held professional opinions on the best aircraft integration approach, the way ahead was not obvious. Over 1000 potentially feasible combinations of options were available. The laboratory was interested in demonstrating feasible technologies to reduce risk and increase the technical readiness of compressed weapons technologies. The overall goal was to increase the sortie effectiveness of small, F-16 class fighters by over an order of magnitude using new smaller more accurate munitions currently in development. Resources were available for further development of a limited number of compressed weapons technologies and aircraft carriage technologies. The way we chose to rapidly and accurately identify the high payoff concepts was the use of Quality Function Deployment (QFD) as a formal systems engineering tool in an Integrated Product Team environment. The use of QFD enabled the IPT to select high payoff technologies based upon “system requirements” and a high degree of professional knowledge and experience. The QFD process enabled us to eliminate biases built in from the different organizational views of the team which was made up of government/industry, weapon/aircraft, primes and suppliers and to identify synergistic concepts worthy of additional design and development.

This project s purpose is to assess perceptions within the U.S. Army of qualification requirements of Army acquisition professionals since the Department of Defense implemented policies to conform to the Defense Acquisition Workforce Improvement Act passed by Congress in November 1990. This project s objective is to analyze the acquisition workforce perception of training requirements instituted by the Defense Acquisition University for professional certification in the acquisition functional areas and to determine if these requirements are perceived as an adequate technical baseline of knowledge and experience that ensures professionals will be more effective members of the acquisition Integrated Product Team. These perceptions were collected through visits to respective centers for excellence, from interviews, and from surveys of both military and civilian acquisition professionals. We acquired data from the U.S. Army Acquisition Support Center and the Defense Acquisition University, as well as surveys and interviews of acquisition leadership with a range of experience and positions.

Researchers at the University of Alabama in Huntsville (UAH) are investigating the operation of a guided parafoil for active descent control of payloads. To support the research, a graduate propulsion class (MAE 640) at UAH has engineered, tested, and delivered a solid rocket launch vehicle. The vehicle design was investigated from multiple directions. The approach included having the students work as an integrated product team, perform laboratory measurements, calibrate internal ballistics and trajectory models, and perform a flight demonstration of the system. The sounding rocket project with guided parafoil recovery proved to be an effective way to combine academic challenges in the classroom environment with research activities in the UAH Laboratories. The results are embodied is a 6 degree of freedom model that included a transient internal ballistics model. Laboratory exmerimental and flight data are compared with the models. The rocket successfully deplayed the parafol at an altititude of about 2000 ft. and was guided by radio back to a landing.

A systematic method has been applied in an Integrated Product Team environment to develop verification strategies for the International Space Station, US Laboratory Module. The method uses a graphical verification logic network and well defined verification objectives to specify a set of verification activities which are sufficient to prove compliance with the development specification.

The merits of Concurrent Engineering (CE) and Integrated Product Team (IPT) approaches are widely discussed (Miller 1993) but little attention has been given to methods to identify areas of difficulties and improve implementation. This paper describes a team based approach to capture, analyze, and deploy lessons learned. The lessons learned process is described with a process flow diagram and through charts developed in the lessons learned sessions. Several observations about learning and improving CE and IPTs are given.

Many organizations are turning to Integrated Product Development (IPPD) and Integrated Product Teams (IPT's) as a way to improve the speed and cost effectiveness of their system development process. The Secretary of Defense issued a directive on May 10, 1995 directing the use of IPPD and IPT's to the maximum extent practicable. IPPD and IPT's have proven to be an effective tool when implemented properly, but they are no panacea. One of the challenges of IPT's is that the culture of the organization must change and the implementation of the system engineering process must also change. This paper will take the DoD Guide to Integrated Product and Process Development (Version 1.0) and examine the changes that are required in the way that system engineering has been implemented within project organizations on both the government and contractor side. The applicability of this approach to purely commercial projects will also be examined. The concept of Distributed System Engineering (DSE) was developed to describe a new process for implementing SE within an IPPD structured project. DSE includes cultural changes that are required, new ways of developing and managing requirements and tradeoffs, as well the new knowledge and skills that the IPT members will need in order to step up to this challenge. The role of the project manager and the functional managers in project implementation must also change. An implementation strategy for getting started with DSE in a IPPD environment will be described.

Solid Freeform Manufacturing has emerged as a valuable tool for rapid prototyping. Its advantages over conventional manufacturing processes for quick product visualization enable companies to spend considerably less money and time in bringing products from the computer tube to the table top. However, to effectively utilize this manufacturing technique to its full potential, its process capabilities must be clearly understood. The constant advances in accuracies, resins, and casting techniques necessitate the requirement to have this data available for the Integrated Product Team. This paper will discuss the importance of relating process capabilities to product features and present a method for automated producibility analysis utilizing component features and process knowledge capture.

In an Integrated Product Team environment, the systems engineering focus can be diluted unless specific steps are taken to focus the key people working on each team, and to improve their understanding and teamwork. Team Launches and Team Workshops have been created to educate teams just coming under contract and ongoing teams, respectively. The workshops teach team techniques in a structured, facilitated setting, over a two- to four-day period, during which teams concentrate on establishing system and project goals, roles, responsibilities, and plans. This paper describes the agendas and processes involved in producing Team Launches and Team Workshops.

The goal of this paper is to demonstrate how the concurrent engineering method embodied in the Integrated Product Team (IPT) philosophy has impacted the specification development process on the F-22 program. The article will examine the concurrent engineering process as it applies strictly to specification development.[1] In particular, the success of the specification development process will be attributed to three main factors: (1) maintaining flexibility in the Preliminary Allocated Baseline (PAB) until Functional Configuration Audit (FCA), (2) Increasing communication and trust between the contractor and the customer by making the customer an integral member of the IPT, and (3) taking advantage of the automated technology to redesign the specification development process. While the F-22 program is a multi-corporate endeavor, these principles can be applied to any development effort.]