AA 253/MS&E 205

System and Product Development

Topic Profiles
Professor S,I,Weiss
Introduction:
As engineers and designers, we develop products and systems, but what we delver is
value to customers and stakeholders. We implement this most effectively by using
systems engineering practices in a more or less structured environment.
Specifically, systems engineering involves a translation of stakeholder values into a
succession of practices yielding the best possible products or systems over their life
cycle. Our focus will be the application of these concepts to the complex products and
systems intrinsic to industry and governments, with specific references to projects
including aerospace and non-aerospace, such as the national air transportation system and
its elements, space exploration alternatives, the healthcare industry, the New York Transit
Authority and others of interest to the class.
1. Value propositions and alignments.
Once we identify all the stakeholders, including those outside the company/customer
community, together with their values, it is important to prioritize these, recognize
conflicts among them and develop a proposition that can serve as an agreement that will
drive design, development and implementation. This agreement, representing an
alignment of values among stakeholders, is effectively a contract that can be referred to
in establishing broadly understood requirements. If there are conflicts, these must be
negotiated or they can impact the process or products of development with resulting cost,
schedule and performance problems.
2. From values to reqirements.
Values held by stakeholders generate requirements governing the performance and
deployment of a system as well as its constraints. These too must be prioritized and
conflicts reconciled. The outcomes will be the basis for system management,
performance specifications, constraint mitigation and the road to design development.
3. Quality Function Development.
One tool that has proven useful in translating values to requirements and requirements to
technical characteristics for a product is the QFD matrix, or house of quality. It
provides a means of developing relationships with a weighted scoring, helping to
prioritize requirements and design drivers. It also serves as a useful reference for
understanding the impact of downstream requirements changes during the development
process.
4. Functional analysis
Functions are actions that define the flow of activities necessary to meet the requirements
described above. Thus for a product or system the set of performance actions and their
alternates can be defined. This approach is important in ensuring inclusion of all
functions necessary for product or system performance are included, thereby providing a
basis for identifying the means-equipment or process for achieving them.
Once the functional flow is established, a schematic diagram, or functional block
diagram, describing the means by which functions can be implemented, can be drawn. It
can also show interfaces between elements and can therefore lead to defining the concept
architecture or design for the system problem. It is notable that the humans-in-the-loop
considerations become critical and influential to concept definition.
5. Concept options and interfaces
Though concepts for products or systems may be the seed for requirements, a rigorous
sequence often uses functional schematics as guides for the establishment of multiple
concepts to choose from that will satisfy requirements and become the forerunners for
design architectures.
The interfaces between elements represent interactions or relationships between/amongst
elements. For complex products these can be multifold and become key design issues as
well as key sites for potential failures. Tools for understanding, keeping track of and
controlling these must be defined.
6. Architecture and Trades.
The architecture of a product or system (P/S) is the arrangement, usually shown in
hierarchical form, of the elements making up the P/S. It can also show options as derived
from the functional analysis or alternate concepts, software or processes. These
alternates are the basis for trades for selecting favored alternatives as approaches. The
trade process of course is also implied in the establishment of requirements and functions.
The decision process can be aided by tools such as Pugh matrices, AHTC, decision trees
or Excel based decision sheets.
7. Failure modes and Reliability.
Parameters that show up early as priorities in development are safety and reliability.
These relate to an understanding of how a P/S can fail as well as the probability of
successful operation over given periods of performance. Designing for each is a critical
aspect of the development process and involves both analyses and prediction. Concepts
of safety factors, redundancies and fault tolerance are analytically or heuristically treated.
8. Fault tolerant design,
Most products and systems must have acceptable responses to failure and understanding
the character and implication of failure modes is critical for successful design. Thus if
these aspects are understood it may be possible to include performance characteristics
that permit a system to operate in some non-catastrophic mode to provide continuing
operational fail-fixable or fail-degraded. Choice of which to design for is often a
decision based on cost, reputation, or even contract incentives.
9. Risk analysis and management.
Risk analysis is based on the probability of failure and the assessment of that probability
as it influences performance, reliability, manufacture or other physical attributes of a
product or system. From a development management standpoint it deals with
expectations for schedule, cost, technology availability and insertion as well as presumed
safety. The responses to these risk concepts include many reviews, monitoring
techniques and the utilization of backup hardware or software. In new products there are
fewer historical bases for the assessments and management issues, but there are some
heuristics and methods for estimating, as well as some rules for risk mitigation.
10. Validation and Verificaion (V&V).
System and product integration lead to considerations of V & V. While these two terms
are often used interchangeably, we will define validation as the ability of a product to
meet the performance requirements set for it throughout its life cycle and in all
environments. This is normally accomplished through severe test programs simulating
extremes of the operating environment. We will define verification as the verifying or
proving by analysis, inspection and test that a product meets the quality standards
established for it through specifications and other regimen that address the unique
environments effecting each system are the focus of this discussion. While there can be
limitations to theses processes, they can sometimes be augmented by simulations or
experiments.
11. Information system analogies.
Since information systems permeate all complex products and systems, it is worthwhile
understanding some parallels and differences at the system level. This reflects the
widespread use of sensors, processors, software and transfer media in modern system
projects. Examples lie in many complex product fields, extending to nearly all involving
interconnectivity.
12. Integrated Product and Process Development (IPPD)
This definition is sometimes equated to concurrent engineering. The latter generally
refers to the involvement during design of related functions such as mechanics and
materials analysis, controls, electrical, electronic and software systems, all contributing to
the total design as well as providing the analytical bases and specialized studies in
parallel so as to both shorten the design cycle as well as reduce the necessity for changes
after design release. Added to this the inclusion of inputs from the procurement,
manufacturing, suppliers, logistics and service organizations as well as the customer, and
you have the bass for IPPD. This suggests the use of teams made up of representatives of
these areas, called Integrated Product Teams, or IPTs.

13 Design for X
This is shorthand for the considerations during the design-development process that take
into account issues such as cost, manufacturing, operations, sustainment and technology
upgrades. It is particularly necessary in addressing affordability and all aspects of the
lifecycle, from installation and startup to retrieval and repair

14. Cost analysis.
Estimating costs of development projects is more an art than a science. But there are
some important guidelines that can give a general range of probable costs, plus some
reasonable expectations of meeting established targets. Over the course of development
there are also expectations for progressive costing accuracy with methods ranging from
comparability guesstimates to bottoms-up details.
15. Project management.
Cost, schedule and performance are the normal budget and control parameters involved
in management and these can be facilitated by a number of tools including value stream
mapping and PERT networks, as well as the more common Gantt schedule charts and
earned value". Defining the right organization and contract forms for the character of
the development are also issues, as is the application of risk reduction methods noted
earlier.
16. Lean practices
Lean in this context means the elimination of waste and responsiveness to change and the
Lean Advancement Initiative addresses these in many areas, including product
development. The identification of lean practices and their implications to development
have been areas of intense study as well as generating progressive application in many
domains. The use of the Lean Enterprise Model together with assessment and
implementation tools is becoming a basis for competitive capability for not only
automobile and aerospace companies, but also for those involved in the development of
complex systems, product and services.