科技管理
輔仁大學
全人教育中心
MANAGEMENT OF TECHNOLOGY
AND INNOVATION
代碼; D-NT00-04161
授課 吳剛鳳
1
系統工程與管理學術之關係
2
系統工程管理
強調
科技管理在
系統生命週期
中之作為
3
科學管理Scientific Management
• 科學管理之父-Fredrick W. Taylor 。
–Midvale 鋼鐵公司工作期間觀察員工生產力。
–1895年向機械工程學會發表管理觀念。
–1903-1911年著書闡述理念。
• 科學管理基本原理
– 以科學方法，尋求最佳工作方式。
– 以科學方法選用訓練工人。
– 增加工人個人績效，提高工資激勵工人，增進生產
能力，降低產品成本。
–工作劃分，促使管理階層與員工相互依賴。
4
• 科學管理是人員與工作間關係之哲學，並非僅
強調技術或效率 。
• 科學管理之基本理念-兼顧適當之工作設計，
並且關心員工。
• 科學管理曾被誤解為僅為增加產量，而實施非
人性之做法-1912年曾遭國會調查。
5
• 其他科學管理先驅
– Henry Gantt
• 成就:生產管制及甘特圖 。
• 倡言:管理階層及企業之社會責任 。
– Frank and Lillian Gilbreth
• 成就:
– Frank:動作研究(Motions Study)及工作方法(Work
Method)研究 。
•細分人體動作為基本動作-Therblig
•無效運動刪除或減少，有效運動改善或加強。
– Lillian:管理心理學
• 培育而非壓抑員工。
6
– Henri Fayol (法國人)
• 1888年接掌一瀕臨破產之煤礦及鋼鐵公司，使之財務健全
，聲譽卓著。
• 1916年出版工業及一般性管理(Administration Industrielle et
Generale) ， 1930年譯成英文 ， 1950年方廣為流傳，管理
界公認之經典著作。
• 1918退休，演講推展其管理理論。
• 討論管理原則及構成要素。
• 將管理理論用於政府部門 。
•強調組織管理。 (Taylor強調作業活動管理)
•管理程序理論之父
• 列舉管理要素為
–
–
–
–
–
計畫
組織
命令
協調
控制
7
• 確定十四項管理原則
(運用時保持彈性，環境不同，限制不同)
–
–
–
–
–
–
–
–
–
–
–
–
–
–
分工:工作專業化
授權:正式對個人授權
紀律:基於服從及尊敬
命令一致:每一位員工僅能從一位上司處接獲命令
指揮統一:同一作業團體僅有一位領導者及一份計畫和相同
目標
個人利益置於團體利益之下
報酬:薪資支付決定於多項因素
集權:集權程度取決於授權情形及正式之溝通管道
授權階級鏈:顯示授權之層級關係及正式之溝通管道
秩序:確保每一事件皆能定位
公平:仁慈及公正
人事穩定:須有條理之人事規劃
自動自發:對所有工作均需發揮個人 之熱誠及活力
團隊精神:組織中需塑造和諧一致之氣氛
8
管理科學(Management Science)
• 科學管理只能應用於生產任務上
–目的在獲得人與機器之效率-解決工作階層之工作
問題。
–無法解決決策階層之決策問題。
–決策錯誤，效率愈高，愈是不利。
•二次大戰後，由於電子計算機之發明，數學和
統計之演進，步入管理科學時期。
• 管理科學
– 為一種解決問題之技術，如系統分析(S.A.)及作業
研究(O.R.) 。
–主要用在決策程序。
9
10
日本美國及Z組織理論
11
科管概論
•科技管理是一個組織為了達成策略及運用目標
，整合工程、科學和管理的專業學問，用以計
畫、開發和建立組織中的科技能力。
•產業界所探討的幾個主要課題是
–技術的預測與影響評估
–研究發展的管理
–技術與企業整體營運之整合
–新科技在產品和製程中之實行
–技術的淘汰和取代
12
•產業界對科技管理的主要需求，包括
以下幾方面
–如何將技術與公司整體上長期目標整合
–如何更快和更有效率地引入或移出技術
–如何更有效率地去評估或評價技術
–如何完美地完成技術移轉
–如何縮短新產品的開發時間
–如何管理大型、複雜、跨領域或跨組織的
專案或系統
–如何管理組織內部的技術應用
–如何提昇技術人員的效能
13
• 科管發展重點
– 探討知識與技術密集產業中的經營管
理課題：
• 知識與技術密集產業，大多具有技術快速
進步、市場變化快、產品生命週期短等特
性，使得該等產業所面臨的經營課題，如
策略、組織、行銷、人事、研發、財務等
，皆與傳統產業有所不同，需系統性之研
究，以建立新的經營典範。
14
• 這些新興課題包括：
– 創造力培養
– 技術與研發管理
– 技術預測與評估
– 技術移轉與貿易
– 風險投資
– 知識管理
– 創新管理
– 智慧財產權
– 政府科技政策
– 科技、人文與環保
15
–探討社會體系中各個層次的創新課題
：
•如何形成塑造一個良好的創新環境，是未
來經濟發展的關鍵。
•創新相關課題均值得深入檢討，形成新的
理論。這些課題包括:
–國家與區域層次的「創新環境與政策」
–產業與企業層次的「新興科技產業與經營
策略」
–產品與技術層次的「創新組織與技術管理
」等。
16
The development process in
system engineering
• The term system engineering dates back to
Bell Telephone Laboratories in the early
1940s.
• The first attempt to teach systems
engineering as we know it today came in
1950 at MIT by Mr.Gilman, Director of
System Engineering at Bell.
17
• The Department of Defense entered the world of
system engineering in the late 1940s with the
initial development of ballistic missiles and
missile-defense systems.
• The RAND Corporation was founded in 1946 by
the United Air Force and created system analysis,
which is an important part of system engineering.
18
Introduction to System
Engineering
• System Engineering – the orderly
process of bringing a system into
being.
• A system constitutes a complex
combination of resources( in the
form of human beings, materials,
equipment, software, facilities,
data, etc.)
19
• A system is developed to accomplish
a specific function.
• A system may be broken down into
subsystems and various smaller
components.
20
The Current Environment
• The complexity of systems is
increasing.
• New technologies are being
introduced on a continuing basis,
while the life cycles for many
system are being extended.
21
Increasing System Complexities
Constantly Changing Requirements
Eroding Industrial Base
Dwindling Resources
Changing Technology
Longer Acquisition Time
Greater International Competition
The
Current
Environment
Higher overall costs
Extended System Life Cycles
Multiple Prime/Supplier Teams
22
• The overall requirements for the
system in question were not well
defined from the beginning.
• Traditionally, engineers do not want to
be forced into design-related
commitments any earlier than
necessary.
• There are a lot of last-minute changes
in the design. Theses changes are
actually incorporated at a later stage,
which can be quite costly.
23
Cost of design changes
Current practices
Desired practices
Conceptual
design
Preliminary
Detail design Production and/or
design
and development
construction
Major program phases
The cost impact due to changes
24
• The complexities of many systems
have been greater.
• With the ever-increasing emphasis on
performance at the sacrifice of other
key design parameters such as
reliability and quality, the overall
effectiveness of these systems has
been decreasing and the costs have
been going up.
25
High lifecycle cost
•Research, design, and
development cost
•Construction cost
•Production cost
•System operation cost
•Maintenance and support cost
•Retirement, material recycling,
and disposal cost
Low system
effectiveness
•System performance
•Availability, dependability,
reliability, maintainability,
humanability, and supportability
•Constructability and producibilty
•System quality
•Disposability
•Other technical factors
The imbalance between system cost and effectiveness factors
26
• There is a lack of total cost visibility.
• For many systems, design and
development costs are relatively well
known.
• The costs associated with system
operation and maintenance support are
somewhat hidden.
• Decisions made during the early phases
of system development can have a great
impact on total life-cycle cost.
27
Acquisition costs
(research, design, test
construction, production)
Costs due to
system operations
Costs due to system
effectiveness and/or
performance losses
Costs due to maintenance and lifecycle support
(personnel, spares, test equipment,
facilities, data, computer resources)
Costs due to
retirement
(material recycling or
disposal
Total cost visibility-iceberg effect
28
Percent of life-cycle cost
100%
Life-cycle costreduction
opportunity
Projected lifecycle
cost(cumulative)
Actual program
expenditures
System
design and
development
Production
and/or
construction
System utilization
and sustaining
support
Commitment of life-cycle cost
29
Constraints
•Technology
•Economic
•Social
•Political
•Environmental
System
Input
Identification
of consumer
requirement;
i.e., need
•Transportation
•Communications
•Manufacturing plant
•Power distribution
•Information processing
•Water reuse and distribution
•Waste disposal
•Satellite/space
•University/college
•Chemical processing plant
•Office complex
•Electrical, electronic, mechanical
•Other functional entities
Output
A system that will
respond to a
consumer need in
an effective and
efficient manner
Mechanisms
(resource requirements)
•Human(people)
•Equipment/software
•Facility/Data
•Materials
•Maintenance Support
The system
30
Prime
operating
equipment
Operating
personnel
Operating
software
Technical
training
Consumable
resources
Transportation
and handling
equipment
Test and
support
equipment
The
system
Maintenance
software
Maintenance
personnel
Technical
data
Maintenance
data
Maintenance
facilities
Other
elements
Supply support
(spares/inventories)
The major elements of a system
31
Transportation
system
Airplane
system
Vehicular
system
Waterway
system
Automobile
Transmission
Fuel
Electrical
The hierarchy of systems
32
The System Life Cycle
• The life cycle includes the entire
spectrum of activity for a given
system.
• Needs may change.
• Obsolescence may occur.
• The various phase of activity may
overlap somewhat.
33
Identified
need
Design and
development
Production
and/or
construction
Operational use and
maintenance support
Retirement and
material disposal
Feedback
The system life cycle
34
System life cycle
Conceptual
design
Preliminary
system
design
Detail design
and
development
Production
System operations
(consumer use)
System
retirement
Production capability
Design
Utilization
System support capability
Design
Utilization(consumer maintenance)
Example of system life cycles
(Airplane,ground transportation,electronic device)
35
System life cycle
Conceptual
design
Preliminary
system
design
Detail
design and
development
Construction
Production operations
System
of physical
(system operational use) retiremen
plant
t
System support capability
Design
Utilization(consumer maintenance)
Example of system life cycles
(Manufacturing plant, chemical processing plant,
satellite ground tracking facility)
36
System Engineering
• Broadly defined, system engineering is
the effective application of scientific
and engineering efforts to transform an
operational need into a defined system
configuration through the top-down
iterative process of requirements
analysis, functional analysis, and
allocation, synthesis, design
optimization, test and evaluation and
validation.
37
• The system engineering process is
continuous, iterative, and incorporate the
necessary feedback provisions to ensure
convergence.
• System engineering involves the efforts
pertaining to the overall design and
development process employed in the
evolution of a system from the point when a
need is first identified, through production
and/ or construction and the ultimate
installation of that system for consumer use.
• The objective is to meet the requirements of
the consumer in an effective and efficient
manner.
38
Area of emphasis
System
retirement and
material
disposal
System
requirements
Feedback
Full-scale
production,system
utilization,maintenanc
e and support system
evaluation
Functional analysis
and requirements
allocation
Design integration
component
acquisition, test
and evaluation
Startup and early
production,system
evaluation
Construction and
installation of
capital assets
Top-down/bottom-up system development process
39
Define the
system
requirements
Compare test
data with
requirements
and
objectives
Test the
system
Interface
control
Measured
characteristics
Identified
need
Understand
the
objectives
Consider
alternative
configurations
Choose the
best
configuration
Actual
characteristics
Design the
system
Accomplish
system
integration
Developed
physical
system
Update system
characteristics
and data
Feedback in the system engineering process
40
The integration of the hardware, software, and human life cycle
41
System engineering within the acquisition process
42
Evolution of
design
Design requirements (criteria)
Design tasks/methods
System design
(System
configuration)
Preliminary
design
(Configuration
item level)
Detail
design and
development
Developmental
test and
evaluation
Production
and/or
construction
The top-down trace-ability of requirements
43
The waterfall model of the software life cycle
44
Flow activity in spiral life cycle
45
The spiral model for the software life cycle
46
The generic Vee development model
47
The systems versus software engineering boundary
48
DEFINITIONS OF
SYSTEMS ENGINEERING
•
MIL-STD-499A [1974]defines
systems engineering as:
The application of scientific and
engineering efforts to
a. transform an operational need into
a description of system
performance parameters and a
system configuration through the
use of an iterative process of
definition, synthesis, analysis,
design, test, and evaluation;
49
b. integrate related technical
parameters and ensure
compatibility of all physical,
functional, and program interfaces
in a manner that optimizes the
total system definition and design;
c. integrate reliability,
maintainability,safety,survivability
, human engineering, and other
such factors into the total
engineering effort to meet cost,
schedule, supportability, and
technical performance objective.
50
• MIL-STD-499B [1993]defines systems
engineering as:
– An interdisciplinary approach
encompassing the entire technical effort to
evolve and verify an integrated and lifecycle balanced set of system people,
product, and process solutions that satisfy
customer needs.
51
– Systems engineering encompasses
a. The technical efforts related to the
development, manufacturing, verification,
deployment, operations, support, disposal
of, and user training for system products
and processes;
b. The definition and management of the
system configuration;
c. The translation of the system definition
into work breakdown structures;
d. development of information for
management decision making.
52
• In its simplest terms, system
engineering is both a technical process
and a management process.
• DSMC favors the management
approach and defines system
engineering as follows:
– Management function which controls the
total system development effort for the
purpose of achieving an optimum balance
of all system elements.
– It is a process which transforms an
operational need into a description of
system parameters and integrate those
parameters to optimize the overall system
effectiveness.
53
•
•
System engineering is essential in the
earliest planning period, in
conceiving the system concept and
defining system requirements.
As the detailed design is being done,
system engineering assure:
a. balanced influence of all required
design specialties;
b. resolve interface problems;
c. conduct design reviews;
d. perform trade-off analyses;
e. assist in verifying system performance;
54
•
During the production phase,system
engineering is concerned with
a. verifying system capability;
b. maintaining the system baseline;
c. forming an analytical framework for
producibility analysis;
•
During the operation and support
phase, system engineering:
a. evaluates proposed changes to the
systems;
b. establishes their effectiveness;
c. facilitates the effective incorporation
of changes, modification, and updates.
55
THE SYSTEM
ENGINEERING PROCESS
•
The system engineering process is
iteratively applied. It consists
primarily of 4 activities for best
accomplishing system design task:
a.
b.
c.
d.
Functional analysis;
Synthesis;
Evaluation and decision;
Description of systems elements.
56
SYSTEM ENGINEERING
OBJECTIVES
a. Ensure that system definition
and design reflects requirements
for all system
elements:equipment, software,
personnel, facilities, and data.
b. Integrate technical efforts of the
design team specialists to
produce an optimally balanced
design.
57
c. Provide a comprehensive indentured
framework of system requirements
for use as performance, design,
interface, support, production, and
test criteria.
d. Provide source data for development
of technical plans and contract work
statements.
e. Provide a systems framework for
logistic analysis, integrated logistic
support (ILS) trade studies and
logistic documentations.
58
f. Provide a systems framework
for production engineering
analysis, producibility trade
studies and
production/manufacturing
documentations.
g. Ensure that life cycle cost
considerations and requirements
are fully considered in all phases
of the design process.
59
SYSTEMS ENGINEERING
IMPLEMENTATION
•
Successful application of systems
engineering requires:
a. Mutual understanding and support
between the user and contractor
Program Managers. They must be
willing to make the systems engineering
process the backbone of the overall
development program.
b. Understanding the need to define and
communicate among the engineering
specialty programs.
60
c. Recognition of the role of
formal technical reviews and
audits, as described in MILSTD-1521B, including the
value, objective, and uniqueness
of each formal review and audit.
d. Knowledge of the objectives of
the program.
e. A thorough interpretation of the
user’s requirements.
61
SYSTEMS ENGINEERING
OUTPUTS
• The output of the systems
engineering process is
documentation.
• Systems engineering prepares a
number of technical management
and engineering specialty plans
which define how each phase of
the acquisition cycle will be
conducted.
62
• Draft plans are usually submitted with
the proposal and final plans are
delivered in accordance with the
Contract Data Requirements List
(CDRL).
• Top level specifications are
incorporated into the statement of
work (SOW) and provided to the
developer.
• The developer will allocate these top
level requirements to lower level
system components.
63
• The status of system development
progress is tracked and
documented in the form of
technical review data packages,
technical performance
measurement (TPM) reports,
analysis and simulation reports,
and other technical
documentation pertinent to the
program.
• In summary, this documentation
may include:
64
a. System Engineering Management
Plan (SEMP)
b. Specifications
c. Design Documentation
d. Interface Control Documents
(ICDs)
e. Risk Analysis Management Plan
f. Survivability/Vulnerability(S/V)
Hardness Plan
g. Mission Analysis Report
h. Reliability Plan
i. Maintainability Plan
65
j.
k.
l.
m.
n.
o.
p.
q.
r.
s.
Integrated Logistics Support Plan
(ILSP)
Software Development Plan (SDP)
Test and Evaluation Master Plan
(TEMP)
Producibility Plan
Functional Flow Block Diagrams
(FFBD)
Requirements Allocation Sheets (RAS)
Audit Reports
EMI/EMC Control Plan
Human Engineering Plan
Trade Study Reports
66
• System Analysis
– Throughout system design and development
there are many different alternatives(or
trade-offs) requiring an evaluation efforts in
some form.
– To accomplish this activity in an effective
manner, the engineer(or analyst) relies on
the use of available analytical
techniques/tools to include operations
research methods such as simulation, linear
and dynamic programming, integer
programming, optimization, and queuing
theory to help solve problems.
– System analysis includes that on going
analytical process of evaluating various
system design alternatives, employing the
application of mathematical models and
associated analytical tools as appropriate.
67
• System Engineering in the Life Cycle
– In the early stage of conceptual and
preliminary design, the emphasis is on
understanding the true needs of the consumer
and in the determination of requirements.
– These requirements must be traceable from
the top and on down to the component level
as necessary.
– Given the basic requirements, the emphasis is
then shifts to the iterative analysis, synthesis,
design optimization, and validation process.
– System engineering activities continue
through the construction and/or production
processes to ensure that the designed system
configuration is compliant with the initially
specified requirements.
68
– Next, there is an ongoing iterative effort of
assessment throughout the operational use
and maintenance support phases.
– A baseline configuration must be
established for the purposes of
benchmarking and the initiation of a
continuous process improvement activity.
– When changes are being initiated ( whether
for corrective action or for product/process
improvement), the consequences of such
changes must be evaluated from a top-level
system perspective, assessing the impact of
a change on the overall system.
69
System Engineering
Management
• The successful implementation of system
engineering concepts and principles is
dependent not only on technological issues
but management issues as well.
• The best tools/models may be available to
implement the process; however, there is no
guarantee for success unless the proper
organization environment has been created
and effective management structure is in
place.
70
The system acquisition process and major milestones
71
• During the early stages of conceptual
design
– Good communications between producer and
the consumers be established from the
beginning.
– Defining the true need, conducting feasibility
analyses, developing operational
requirements and the maintenance concept,
and identifying specific quantitative and
qualitative requirements at the system level
are critical.
– These requirements must be properly
conveyed through a well-prepared System
Specification (Type A).
– This top-level system specification constitutes
the most important technical document, form
which all the lower-level specification evolve.
– Without a good foundation from the
beginning, all subsequent lower-level
requirements may be questionable. 72
• During the latter stages of conceptual
design
– A comprehensive System Engineering
Management Plan (SEMP) must be
developed.
– The SEMP
• evolves from the top-level Program
Management Plan (PMP)
• provides the integration of all lower-level
planning documents.
• includes
– the design-related tasks necessary to enhance
the day-to-day system development effort.
– the implementation of concurrent engineering
methods,
– the integration of the appropriate
organizational entities into a team approach.
• must directly support the requirements in the
System Specification (Type A) from a
management perspective.
73
• During the latter stages of
conceptual design
– A Test and Evaluation Master Plan (TEMP)
must be developed for the purpose of
assessment and ultimate validation.
• The method/techniques to be used for
measuring and evaluating the system to ensure
compliance with requirements that are initially
specified in the System Specification (Type A)
must be described.
• This plan must address test and evaluation
activities on a fully integrated basis.
74
• As system design and development
progresses, there is a need to schedule
a series of formal design reviews at
discrete points where the design
configuration evolves from one level
of definition to another.
– Conceptual Design Review (System
Requirement Review, SRR)
– System Design Review (SDR)
– Equipment/Software Design Review
– Critical Design Review (CDR)
• The purpose of these reviews is
– to ensure that the specified requirements are
being met prior to entering into a
subsequent phase of effort
– To ensure that the necessary
communications exist across organizational
line.
75
• Toward the latter stages of detail
design, throughout the
construction/production phase, and
during the operational use and
maintenance support phase, there is a
need to provide an ongoing system
assessment and validation effort.
– The objective is
• to ensure that the consumer requirements are
being met
• to establish a baseline for the purpose of
benchmarking and the initiation of a
continuous process improvement activity.
76
Design
review
Define System
requirements
Design
review
Implement
program to
develop a system
to meet the
requirements
Measure and evaluate
the system in terms
of compliance with
the requirements
Design
review
Yes
Have the
requirements
been met?
No
Feedback and
correctiveaction loop
The basic system requirements, evaluation, and review process
77
Related Terms and Definitions
• Concurrent Engineering
– A systematic approach to the integrated,
concurrent design of products and their
related processes, including manufacture
and support.
– The design must consider the prime
elements of the system, the manufacturing
and/or construction process, and the
maintenance and support process on an
integrated and concurrent basis.
– Concurrent engineering should be
included within the system engineering
process.
78
• Integrated Product and Process
Development (IPPD) - mid-1990.
– IPPD can be defined as a management
technique that simultaneously integrates
all essential acquisition activities through
the use of multidisciplinary teams to
optimize the design, manufacturing, and
supportability processes.
– IPPD facilitates meeting cost and
performance objectives from product
concept through production, and
including field support.
79
• Total Quality Management (TQM)
– TQM can be describe as totally
integrated management approach that
addresses system/product quality during
all phases of the life cycle and at each
level in the overall system hierarchy.
– TQM is a unification mechanism
linking human capabilities to
engineering, production, and support
processes.
– Emphasis is placed on total customer
satisfaction, the iterative practice of
continuous improvement, and total
integrated organization approach.
– The principles of TQM must be inherent
within the system engineering process.
80
• Configuration Management (CM)
– CM is a management approach used to
identify the functional and physical
characteristics of an item in the early phases
of its life cycle, control changes to those
characteristics, and record and report change
processing and implementation status.
– CM involves 4 functions
• Configuration identification
• Configuration control
• Configuration status accounting
• Configuration audit
– CM is the concept of baseline management.
81
• Integrated System Maintenance and
Support
– ILS (integrated Logistic Support) is a
management function that provides the initial
planning, funding, and controls that help to
assure that the ultimate consumer receives a
system that will not only meet the
performance requirement, but one that can be
supported expeditiously and economically.
– ILS is a disciplined, unified, and iterative
approach to the management and technical
activities necessary to:
• Integrate support considerations into system and
equipment design
• Develop support requirements that are related
consistently to readiness objectives, to design and
to each other.
• Acquire the required support.
• Provide the required support during the operational
82
phase at minimum cost.
• Total Productive Maintenance (TPM)
– A concept originally developed by JIPM
(Japanese Institute for Plant Maintenance) in
1971.
– Top-down system-oriented life-cycle approach
to maintenance with the objective of
maximizing productivity.
– TPM is directed primarily to the commercial
manufacturing environment, and
• promotes the effectiveness and efficiency of
equipment in the factory.
• establishes a complete preventive maintenance
program for factory equipment based on life-cycle
criteria.
83
• is implemented on a team basis involving various
departments to include engineering, production
operations and maintenance.
• involves every employee in the company, from the
top management to the workers on the shop
floor.(even equipment operators are responsible for
the care and maintenance of the equipment they
operate.)
• is based on the promotion of preventive maintenance
through motivational management (establishment of
autonomous small-group activities for the
maintenance and support of equipment. )
84
Integrated Product and
Process Development (IPPD)
IPT (Integrated Product Team)
Functional organization structure showing IPPD/IPTs
85
• Total System Value
• A system should be measured in
terms of total life value to the
consumer.
• One need to consider both sides
of the balance, i.e. technical
factors and economic factors.
• Life-cycle cost involves all costs
associated with the system cycle.
86
Value
Total System Value
87
• Research and development
(R&D) cost - the cost of:
– Feasibility studies
– Developing operational and
maintenance requirements
– System analyses
– Detail design and development
– Fabrication, assembly and test of
engineering models
– Initial system test and evaluation
– Associated documentation
88
• Production and construction cost - the
cost of:
– Fabrication,assembly and test of operating
systems (production models)
– Operation and the sustaining maintenance
and support of the manufacturing
capability
– Facility construction
– Acquisition of an initial system support
capability, e.g.
• Test and support equipment
• Spare/repair parts
• Technical documentation
89
• Operational and maintenance cost - the
cost of:
– System operation and the sustaining
maintenance and support of the system
through its planned life cycle, e.g.
•
•
•
•
•
•
•
•
Manpower and personnel
Spare/repair parts and related inventories
Test and support equipment
Transportation and handling
Facilities
Software
Modification
Technical data
90
• System retirement and phase-out
cost - the cost of:
– Phasing the system and its
components out of the inventory
because of obsolescence or wearout.
– Recycling of items for further use.
– Condemnation and the disposal of
materials.
91
The system engineering process in the life cycle
92
Current deficiency
• A design effort is initiated as a
result of a personal interest or a
political whim.
• In the software area, there is the
tendency to accomplish a lot of
coding before identifying the
need.
93
Development of consumer need
• It is important to describe the
customer(consumer) requirements in
a functional manner in order to avoid
a premature commitment to a
specific design concept or
configuration.
• The ultimate objective is to define
the WHATs and not HOWs
94
• Accomplishing the needs analysis ：
Team approach involving
–
–
–
–
Customer
Contractor
Producer
Major suppliers
• Methods such as
– Surveys
– Interviews
– Checklist
– Quality Function Deployment (QFD)
may be employed
95
System feasibility analysis
• Through the needs analysis, the
function that the system must
perform are identified.
• All possible functions must be
identified.
• The most rigorous functions being
selected as the basis for defining
system-level design requirement.
96
• It is necessary to
– Identify the various possible design
approaches that can be pursued to meet the
requirements.
– Evaluate the most likely candidates in terms
of
•
•
•
•
performance
effectiveness
Logistic requirement
Life-cycle economic criteria
– Recommend a preferred approach.
– The number of possibilities must be
narrowed down to a few feasible options,
consistent with the availability of resources.
97
System operational requirement
• The operational concept includes the
following information:
– Operational distribution or deployment
• Where is the system to be utilized?
– Mission profile or scenario
• What is the system to accomplish?
• How will it accomplish its objective?
– Performance and related parameters
• What are the critical system performance
parameters necessary to accomplish the
mission at the various consumer sites ?
98
Sample system operational profiles
99
– Utilization requirements
• How are the various system components to be
utilized?
– Effectiveness requirement
• How effective or efficient will it be?
– Operational life cycle
• How long will the system be in use by the
consumer?
– Environment
• To what will the system be subjected during
its operational use and how long?
• In addition to operations, environment
consideration should address
– Transportation
– Handling
– Storage
100
The maintenance and support
concept
• System support must be considered
from the beginning (e.g. during the
feasibility analysis)
• Maintenance concept must be
developed on how the proposed
system is to be supported on a life
cycle basis.
101
System operational and maintenance flow
102
• Levels of maintenance
– Organizational maintenance
• Performed at the operational site.
• Includes tasks performed by the using
organization on its own equipments.
• Is limited to
–
–
–
–
Periodic checks of equipment performance
Visual inspection
Cleaning of system elements
Removal and replacement of some
components
• Personnel do not repair the removed
components, but forward them to intermediate
level.
103
• Intermediate maintenance
– Performed by mobile, semi-mobile
and/or fixed specialized
organizations and installations.
– Items may be repaired by the
removal and replacement of major
modules, assemblies, or piece parts.
– Scheduled maintenance requiring
equipment disassembly may also be
accomplished.
104
• Depot or supplier maintenance
– The highest type of maintenance
– Includes
• Complete overhauling
• Rebuilding
• Calibration of equipment
105
Major levels of maintenance
106
System maintenance concept flow
107
Identification and prioritization of Technical
Performance Measures (TPMs)
• The use of an objective tree may aid in
facilitating the prioritization task.
• In objective tree, requirements are
often expressed in very qualitative
terms.
• An attempt should be maid to establish
quantitative measures for each block
in the objective tree.
108
Objectives tree
109
• An excellent tool that can be applied to
aid in the necessary communications
between designers and consumer (i.e.
customer) is the Quality Function
Deployment QFD.
• QFD constitutes a team approach to
help ensure that the voice of the
customer is reflected in the ultimate
design.
• Consumer requirements and
preferences are defined and
categorized as attributes, which are
then weighted based on the degree of
importance.
110
• QFD method provides the design team
an understanding of customer desire,
forces the customer to prioritize those
desires, and enable a comparison of
one design approach against another.
• Each customer attribute is then
satisfied by a technical solution.
111
• The QFD process involves
constructing one or more matrices.
• The first matrix is referred to as
House of Quality (HOQ).
– Starting on the left side of the HOQ is the
identification of customer needs and the
ranking of those needs in terms of
priority.
• This reflects the WHATs.
• A team, with representation from both
consumer and design organization determines
the priorities through an iterative process of
review, evaluation, revision, reevaluation, and
so on.
112
– The top part of the HOQ identifies the
designer’s technical response relative to
the attributes that must be incorporated
into the design in order to respond to the
needs.
• This constitutes the HOWs.
• There should be at least one technical solution
for each identified customer need.
• The interrelationships among attributes
(technical correlation) are identified, as well as
possible areas of conflict.
113
– The center part of the HOQ conveys the
strength or impact of the proposed
technical response on the identified
requirement.
– The bottom part allows for a comparison
between possible alternatives.
– The right side of the HOQ is used for
planning purposes.
114
House of Quality
115
– The QFD method is used to facilitate the
translation of a prioritized set of
subjective customer requirements into a
set of system-level requirements during
conceptual design.
– A similar approach may be used to
subsequently translate system-level
requirement into a more detailed set of
requirements at each stage in the design
and development process.
116
– The HOWs from one house become
the WHATs for a succeeding house.
– Requirements may be developed for
the system, subsystem, component,
the manufacturing process, the
support infrastructure, and so on
– The objective is to ensure the
required justification and traceability of requirements from top
down.
117
Family of houses (trace-ability of requirements)
118
The four phases of QFD
119
Level of Customer Requirements
• Expecters
– The basic qualities you must offer to be competitive
and remain in business.
– Customers rarely ask about them, because they expect
them as standard features.
• Spokens
– Specific features customers say they want in a product
or service.
– Items a company is willing to provide to satisfy its
customers.
120
• Unspokens
– Product or service characteristics customers
don’t talk about.
– Though silent, they are important and cannot be
ignored.
– Fall into one of three groups
• Didn’t remember to tell you.
• Didn’t want to tell you.
• Didn’t know what it was.
121
• Exciters
– unexpected features of a product or service
– make the product unique and distinguish it from
the competition.
– may be easy or inexpensive to provide.
– begin as unique features that later become
industry standards.
122
Types of customer requirements
123
Correlation
Matrix
Hows
Objective
Relationship
Matrix
Customer
Competitive
Assessment
Importance Rating
Whats
Target Goals
Technical Competitive
Assessment
(How Much)
Probability Factor
Absolute Score
Relative Score
Components of QFD Model
124
What are the
important
elements of
Delivery?
Import.
Rating
(1 to 5 )
Mat’l
Handlg
Prod.
Sched.
Invent.
Control
Ship.
& Rec.
On-time
3
3(9)
5(15)
1(3)
5(15)
Quantity
3
3(9)
5(15)
3(9)
5(15)
Rec’d
condition
4
5(20)
0(0)
0(0)
5(20)
Marking
5
5(25)
1(5)
0(0)
3(15)
No inspection
1
5(5)
1(1)
0(0)
3(3)
Paperwork
4
5(20)
5(20)
3(12)
5(20)
Cost &
logistics
2
5(10)
5(10)
5(10)
3(6)
Absolute Score
98
66
34
94
Relative Score
1
3
4
2
Relationship Matrix with relative scores
125
The Roof
Target Goals
How
#1
Legend:
How
#2
How
#3
How
#4
How
#5
Maximize or Increase
Minimize or Reduce
Target Value
Target Goals assigned to Matrix
126
How
#1
How
#2
How
#3
How
#4
How
#5
Strong Positive Relationship
Positive Relationship
Negative Relationship
Strong Negative Relationship
Using the Correlation Matrix to determine Interrelationships among Hows
127
Hows
Improved
Exhaust
More
Powerful
Engine
New
Engine
Design
News
seats
New
Brake
Design
2
4
3
5
1
Target Goals
Technical
Competitive
Assessment
Excellent 5
4
3
2
Poor
1
Technical Competitive Assessment
128
Hows
Improved
Exhaust
More
Powerful
Engine
New
Engine
Design
News
seats
New
Brake
Design
Less
Than
68
Decibels
25%
HP
Increase
(Min)
30
MPG
3.5”
More
Rear
Leg
Room
25%>
MTBF
Target Goals
How
Much
Objective
Values
Objective Values
129
2
4
5
Good
3
Excellent
1
Poor
0
N/A
Company
A B C D
Rating
Highest
score
Competitive
Company
Analysis
What
#1
What
#2
What
#3
What
#4
What
#5
Customer competitive assessment with company analysis
130
Objective
Statement
Absolute
Score
Difficulty
Factor
Conclusio
n:
How
A
How
B
How
C
10
9
8
X3
X4
X5
30
36
40
Probability Factor
131
Functional Analysis
• The development of a functional
description of the system
– To serve as a basis for the identification of
the resources for the system to accomplish its
objective.
• A function refers to a specific or discrete
action (or series of actions) that is
necessary in order to achieve a given
objective; i.e.
– An operation that the system must perform to
accomplish its mission.
– A maintenance action that is necessary to
restore the system to operational use.
132
• The functional analysis is an iterative
process of breaking requirements
down from the system level, to the
subsystem and far down the
hierarchical structures as necessary to
identify input design criteria and/or
constraints for the various elements of
the system.
• The accomplishment of a functional
analysis can be facilitated through the
use of functional flow block diagrams.
133
System functional breakdown
134
Evolutionary development of functional requirements (1)
135
Evolutionary development of functional requirements (2)
136
Operate
Functional block diagram (partial)
137
Identify
problem
(diagnostics)
Accomplish
maintenance
(repair)
138
Maintenance functional flow diagram
139
Functional flow diagram for a manufacturing system
140
Functional
Identification of resource requirements (i.e. mechanisms)
141
Identification of commercial off-the-shelf(COTS) items from functional analysis
142
Manufacturing system (critical integration points)
143
• In completing a functional analysis,
care should be taken to ensure that the
required resources are properly
identified for each function.
• It may be possible to share resources
in some instances, i.e. the same
resources may be utilized to
accomplish more than one function.
• Every effort should be made to avoid
the specification of resources that are
not necessary.
144
Document format for resource requirements
145
• Functional analysis forms a baseline for
many activities that are conducted
subsequently. It serves as a basis in the
development of the following：
– Electrical and mechanical design for functional packaging,
condition monitoring and diagnostic provision.
– Reliability models and block diagrams
– Failure mode, effect and criticality analysis (FMECA)
– Fault tree analysis (FTA)
– Reliability-centered maintenance(RCM) analysis
– System safety/hazard analysis
– Maintainability analysis
– Level-of-repair analysis
– Maintenance task analysis (MTA)
– Operator task analysis (OTA)
– Operational sequence diagrams (OSDs)
– Logistic support analysis (LSA)
– Operating and maintenance procedures
– Producibility and disposability analysis
146
Requirements Allocation
• Given a top-level definition of the system
through the functional analysis, the next
step is to break the system down into
components by partitioning.
• The challenge is to identify and group
closely related functions into packages,
employing a common resource (e.g.
quipment software ) to accomplish
multiple functions to the extent possible.
147
• The questions are
– What hardware or software can be
selected that will perform multiple
functions?
– How can new functions be added
without adding any new physical
elements to the system structure?
148
• The partitioning of the system
into elements
– Common functions may be grouped
or combined in such a way as to
provide a system packaging scheme
with the following objective in
mind:
• System elements may be grouped by
geographical location, a common
environment, or by similar types of
equipment.
149
• Individual system packages should be
as independent as possible with a
minimum of interaction effects with
other packages.
• Breaking down the system into
packages where there are high rates of
information exchange between these
packages should be avoided.
150
In breaking down a system into
subsystem, select a configuration
where the communications between
the subsystems is minimized.
– Subsystem internal complexity
may be high
– The external complexity should be
low.
151
Hierarchy of system components
152
153
• Given the identification of systems
elements, the next step is to allocate
the requirements specified for the
system down to the level desired to
provide a meaningful input to design.
• The depth to which requirements are
specified is somewhat dependent on
the priorities.
– If there is a highly critical requirements
from the perspective of the consumer,
allocation may be accomplished down to
the assembly level.
– If the allocation is accomplished
unnecessary to a very detailed level, the
designer may be overly constrained to
what can be accomplished through the
trade-off analysis and evaluation process.
154
Allocation of system requirements
155
• By not properly specifying the
requirements from the top down,
the results can be costly in terms
of over-design, under-design, or
both.
• The risks may be high if the
requirements are not addressed
from the beginning!
156
Prioritization of technical performance measures (TPMs)
157
System Synthesis
• Synthesis refers to the combining and
structuring of components in such a
way as to represent a feasible system
configuration.
• Synthesis is design.
– Initially, synthesis is employed to
develop preliminary concepts and to
establish basic relationships among the
various components of the system.
158
– Later, when sufficient functional
definition and decomposition have
occurred, synthesis is used to further
define the HOW in response to the
WHAT requirement.
– Synthesis involves the selection of a
configuration that could be
representative of the form that the
system will ultimately take, although a
final configuration is not to be
assumed at this point.
159
• Synthesis process usually leads to
the definition of several possible
alternative design approaches,
which will be the subject of
further analysis, evaluation,
refinement, and optimization.
• It is essential that the appropriate
technical performance parameters
be properly aligned to applicable
components of the system.
160
• Technical performance
parameters may include factors
such as weight, size, speed,
capacity, accuracy, volume,
range, processing time, along
with the reliability and
maintainability factors.
• These parameters, or measures
must be prioritized and aligned to
the appropriate elements of the
system.
161
Order of evaluation parameters
162
Evaluation of alternatives
163
• Given a number of alternative,
the evaluation procedure
progresses through the general
steps described as follows
– Definition of analysis goals
• The clarification of objectives
• The identification of possible
alternative solutions to the problem at
hand
• A description of the analysis approach
to be employed
164
– Selection and weighting of evaluation
parameters
• The criteria used in the evaluation may vary
considerably.
• In any event, parameters are selected,
weighted in terms priority of importance and
are tailored to the system in a meaningful
manner.
– Identification of data needs
• In the early stages of system development
– available data are limited
– The analyst must depend on the use of various
estimating relationships, projection based on
past experience and intuition.
• As the system development progresses,
improved data are available (through analyses
and predictions).
165
– Identification of evaluation
techniques
• Monte Carlo simulation –prediction of
random events.
• Linear programming-determination of
transportation resource requirements.
• Queuing theory- determination of
production /maintenance shop
requirement.
• Networking-establishment of
distribution need.
• Accounting-life cycle costing
166
– Selection and/or the development of
a model
• Combining of various analytical
techniques into the form of a model or
a series of model.
• The model should
– Represent the dynamics of the system
configuration being evaluated
– Highlight those factors that are most
relevant to the problem at hand
– Be comprehensive by including all
relevant factors and be reliable in terms of
repeatability of results.
– Be simple enough in structure so as to
enable its timely implementation in
problem solving.
167
– Be designed such that the analyst
• can evaluate the applicable system
configuration as an entity
• analyze different components of the
system on an individual basis
• integrate the results into the whole
– Be designed to incorporate provisions for
easy modification and/or expansion to
permit the evaluation of additional factors
as required.
168
Example application of models
169
– Generation of data and model application
• Verify or test the model to ensure that it is
responsive to the analysis requirement
• Evaluation of the model can be accomplished
through the selection of a known system entity
and the subsequent comparison of analysis
results with historical experience.
• Input parameters may be varied to ensure that
the model design characteristics are sensitive
to these variations and will ultimately reflect
an accurate outputs as a results.
170
– Evaluation of design alternative
• Each of the alternatives being considered is
then evaluated using the technique and model
selected.
• The required data are collected from
– Existing data banks
– Prediction based on current design data
– Gross projections using analogous and
parametric estimating relationships
• The results are then evaluated in terms of the
initially specified requirements for the system.
171
Example of evaluation results –
possible feasible solutions fall within the desired shaded areas
172
– Accomplishment of a sensitivity analysis
• There may be a few key system parameters
about which the analyst is uncertain because
of
– Inadequate data input
– Poor prediction procedure
– Pushing the state of the art
• Several questions need to be addressed:
– How sensitive are the results of the analysis to
possible variations of these uncertain input
parameters?
– To what extent can certain input parameters be
varied before the choice of alternative shifts
away from the initially selected approach?
173
• With the objective of minimizing the risks
associated with making an incorrect decisions,
the analyst may wish to vary the input factors
over a designated range of value to see what
impact this variation has on the outputs
results.
• If a relatively small variation of an input factor
have a large impact on the results of analysis,
then
– The parameter might be classified as being
critical TPM in the overall design review and
evaluation process, monitored closely as
design progresses.
– An additional effort might be generated to
modify the design for improvements and to
improve the prediction method.
174
– Identification of risk and uncertainty
• The aspect of risks and uncertainty must be
integrated into the program risk management
plan.
– Recommendation of preferred approach
• The final step in the evaluation process
• The results of analysis should be fully
documented and made available to all applicable
project design personnel.
• The analysis report should include:
– A state of assumptions
– A description of the evaluation procedure that was
followed
– A description of the various alternatives that were
considered
– An identification of potential areas of risk and
uncertainty
175
The system engineering process in the life cycle
176
The system engineering process
177
IEEE P1220 Requirements analysis task area
178
Functional architecture example
179
Time analysis sheet
180
Requirements allocation sheet (example)
181
Functional/physical matrix
182
radio
computer
Concept description sheet
183
Schematic block diagram example
184
Requirements allocation sheet (example)
185
• Design integration
– Design integration commence during
the early stages of conceptual design
– As the requirement for a new system
are established, the design team is
formed, initially performing systemlevel design functions.
• At this stage, the design team may
include only a small number of selected
individuals with the objective of
developing a comprehensive system
specification (Type A).
186
– As system development progresses,
the appropriate design specialist are
added to the team.
• The objective is to ensure that
– the right specialists are available at the time
required
– the individual contributions of the right
specialists are properly integrated into the
whole
• The selection of domain specialist is
highly dependent on the requirements
developed through the functional
analysis and allocation process.
187
– During the latter phases of the life
cycle (i.e. production/construction,
system utilization and support),
• the role of system engineering continues,
but in the form of evaluation/validation
• the introduction and processing of design
changes as necessary.
• The requirements of changes may
– Stem from some identified deficiency ( the
failure to meet an initially specified
requirement)
– For the purposes of continuous process
improvement
188
– The colocation of personnel in one
geographical area(eyeball-to eyeball
contact)is preferred.
– The trends toward outsourcing and
decentralization often result in the
introduction of many different supplier
located throughout the world
– The design team becomes heavily
dependent on the utilization of
computer-aided tool, operating in a
network.
189
The integration of design requirements
190
Design communication network
191
The data environment
192
• Test and evaluation
– There are many functions that can now be
accomplished with computerized simulation
that formerly required a physical mockup of
the system, a pre-production prototype model,
or both.
– The availability of
•
•
•
•
computer-aided design (CAD)
computer-aided manufacturing (CAM)
computer-aided logistic support (CALS)
and related technologies
has made it possible to accomplish much in
the area of system evaluation, relatively early
in the system life cycle when the incorporation
of changes can be accomplished with
minimum cost.
193
– As specific technical performance measures
(TPMs) are established, it is necessary to
determine the methods by which compliance
with these factors will be verified.
– Categories of test and evaluation
• Analytical
• Type 1 testing
• Type 2 testing
• Type 3 testing
• Type 4 testing
194
Stages of system evaluation during the life cycle
195
• Analytical
– Design evaluation can be conducted early in the system
life cycle using computerized techniques
• Type 1 testing
– Usually performed in the producer/supplier’s laboratory
facility by engineering technicians using jury-rigged test
fixtures and engineering notes for procedures.
– During this initial phase, design concepts and
technology applications are validated.
• Type 2 testing
– Includes formal tests and demonstrations accomplished
during the latter stages of the detail design and
development phase when pre-production prototype
equipment and software are available.
196
– A series of individual tests, tailored to the need,
including the following:
• Environmental qualification:temperature cycling,
shock and vibration, humidity, sand and dust, salt
spray, acoustic noise, explosion proofing, and
electromagnetic interference.
• Reliability qualification: sequential testing, life
testing, environmental stress screening (ESS), and
test, analyze and fix (TAAF)
• Maintainability demonstration:verification of
maintenance tasks, task times and sequences,
maintenance personnel quantities and skills levels,
degree of testability and diagnostic provisions,
prime equipments-test equipment interfaces,
maintenance procedures, and maintenance facilities.
197
• Support equipment compatibility: verification
of the compatibility among the prime equipment ,
test and support equipment, and ground handling
equipment.
• Technical data verification: the verification and
validation of operating procedures, maintenance
procedures, and supporting data.
• Personnel test and evaluation: verification to
ensure the compatibility among the human and
equipment, the personnel quantities and skill
levels required, and training needs.
• Software compatibility: verification that
software meets the system requirement, the
compatibility between software and hardware.
198
– Production sampling test
• Production sampling test used when multiple
quantities of an item are being produced.
• Although the system and its components
may have successfully passed the initial
qualification tests, there needs to be some
assurance that the same level of quality has
been maintained throughout the production
process.
• The results are measured and evaluated in
terms of whether improvement or
degradation has occurred.
199
• Type 3 testing
– Type 3 testing includes the formal tests at
designated field test sites by user personnel over
an extended period of time.
– These tests are usually conducted after initial
system qualification and prior to the completion
of the production/construction phase.
– Type 3 testing Is the first time that all elements
of the system are operated and evaluated on an
integrated basis.
– A series of simulated operational exercises are
usually conducted.
– The system is evaluated in terms of performance,
effectiveness, the compatibility between the
prime mission-oriented segments of the system
and the elements of support, and so on.
– Type 3 testing does not completely represent a
fully operational situation.
200
• Type 4 testing
– Type 4 testing is conducted during the system
operational use and life-cycle support phase.
– Type 4 testing includes formal tests that are
sometimes conducted to acquire specific information
relative to some area of operation or support.
– It may be desirable to vary the mission profile or the
system utilization rate to determine the impact on
total system effectiveness.
– It may be feasible to evaluate several alternative
maintenance support policies to see whether system
operational availability can be improved.
– Type 4 testing is accomplished at one or more user
operational sites, in a realistic environment, by
operator and maintenance personnel, and is
supported through the normal maintenance and
logistic capability.
– This is the first time that we will really know the
capability of the system.
201
• Integrated test planning
– Test planning starts in the conceptual
design phase when system requirements
are initially established.
– If a requirement is to be specified, there
needs to be a way to evaluate and
validate the system at a later point in
time to ensure that the requirement has
been met.
– One of the key objectives of the TEMP
(Test and Evaluation Master Plan) is the
complete integration of the various test
requirements for the overall system.
202
– In situations where there are new design
technology applications, more up-front
evaluation may be desirable.
– In areas where the potential technical risks
are high, the requirements for a more
extensive evaluation effort early in the
system life cycle may be feasible.
– In the defense sector, the TEMP is required
for most large programs and includes the
planning and implementation of procedure
for
• Development test and evaluation (DT&E)
– DT&E is equivalent to analytical, type 1 and type2
testing
• Operational test and evaluation (OT&E)
– OT&E is equivalent to type 3 and type4 testing
203
DT&E during system acquisition
204
OT&E during system acquisition
205
DT/OT comparison
206
• Preparation for system test and
evaluation
– Selection of test item
• Up-to-date design or production
configuration
– Selection of test site
• Characteristic for user operations
– Testing procedures
• Both operator and maintenance tasks
• Formal approved procedures
– Test personnel
• Operate and maintain the system
• Provide assistance in conducting the overall
test program
207
– Test and support equipment/software
•
•
•
•
Ground handling equipment
Test equipment
Software
And/or a combination thereof
– Supply support
• Spares, repair parts, consumables and
supporting inventories
– Test facilities and resources
• Special facilities, test chamber, capital
equipment, environmental controls, special
instrumentation, and associated resources.
208
• Test performance and evaluation
– The system (or element thereof) is operated and
supported in a designated manner, as defined in
the TEMP.
– The results are compared with the initially
specified requirements.
– With the system in operational status(either real
or simulated) the following questions arise:
• How well did the system actually perform and did it
accomplish its mission objective?
• What is the true effectiveness of the system?
• What is the true effectiveness of the system support
capability?
• Does the system meet all of the requirements as
covered through the specified technical performance
measures (TPMs)?
• Does the system meet all consumer requirements?
209
System evaluation and corrective-action loop
210
– The final step in the overall evaluation
effort is the preparation of a final test
report:
• The report should
– reference the initial test planning document (I.e. the
TEMP)
– Describe all test conditions and the procedures
followed in conducting the test, identify data
sources and the results of the analysis
– Include any recommendations for corrective action
and/or improvement
• The generation of a good comprehensive test
report is essential from the historical
standpoint.
211
• System modifications
– A change in any given component of the system
will likely have an impact (of some kind) on
most, if not all, of the other major components of
that system.
– Recommendations for changes, evolving from
test and evaluation, must be dealt with on an
individual basis.
– Each proposed change must be evaluated in terms
of its impact on the other elements of the system,
and on life-cycle cost, prior to a decision on
whether or not to incorporate the change.
212
• Production and/or construction
– There are certain unique challenges that must be
addressed to ensure that the system configuration,
which has been initially designed and verified
through evaluation, retains the same high-quality
characteristics as it progresses through the
production or construction processes.
– Degradation may occur as a result of a
combination of allowable variances in design
and/or variances in the different manufacturing
processes used in production.
– In the defense sector, the DOD (Department of
Defense) has recognized these design-production
interfaces, and there is a great deal of emphasis
being placed on concurrent engineering. 213
• System operational use and sustaining support
– Degradation should not take place as a result of
inadequate maintenance and support practices.
• System retirement and material disposal
– There are many systems in use today that, when
they become obsolete, will be costly to phase out
of the inventory.
– There are a number components that cannot be
consumed without creating a detrimental impact
on the environment.
– The design for disposability or design for the
environment should be included in the criteria for
analyses and early design decisions.
214
System design requirements
• System design requirements evolves
from the identification of a consumer
need and are developed through
– the accomplishment of a feasibility
analysis
– the definition of system operational
requirements and the maintenance
concept
– the development and prioritization of
technical performance measures (TPMs)
– the completion of a top-level functional
analysis and allocation
215
• These requirements are developed to
provide a complete definition of the
system in functional terms, along with
the appropriate metrics.
• The results are presented in the form
of a system specification (Type A)
• As system development progresses,
these requirements are broken down in
sufficient detail as to describe the
performance, effectiveness, and related
characteristics for each major
component of the system.
• The makeup of the design team will
likely vary as the overall system
development process evolves.
216
The major steps of system design and development
217
• Development of specifications and design
criteria
– The initial definition of system requirements is
projected through a combination of
• Formal specifications
• Planning documentation
– Specifications basically cover the technical
requirements for system design
•
•
•
•
•
System specification (Type A)
Development specification (Type B)
Production specification (Type C)
Process specification (Type D)
Material specification (Type E)
– Planning documentation includes all management
requirements necessary to fulfill program
objectives.
218
Hierarchy of technical specifications
(MIL-STD-490)
219
– System specification (Type A)
• Includes the technical, performance,
operational, and support characteristics
for the system as an entity.
• Includes the allocation of requirements
to functional areas
• Defines the various functional-area
interfaces.
• The information derived from the
feasibility analysis, operational
requirements, maintenance concept,
and the functional analysis is covered.
220
– Development specification (Type
B)
• Includes the technical requirements for
any item below the system level where
research, design, and development are
accomplished.
• This may cover an equipment item,
assembly, computer program, facility,
critical item of support, and so on.
• Each specification must include the
performance, effectiveness, and
support characteristics that are
required in the evolving of design
form the system level and down.
221
– Product specification (Type C)
• Includes the technical requirements for
any item below the top system level that
is currently in the inventory and can be
procured off the shelf.
• This may cover standard system
components (equipment, assemblies,
units, cables), a specific computer
program, a spare part, a tool, and so on.
222
– Process specification (Type D)
• Includes the technical requirements that
cover a service that is performed on any
component of the system(e.g. machining,
bending, welding, plating, heat treating,
sanding, marking, packing, and
processing).
223
– Material specification (Type E)
• Includes the technical requirements that
pertain to raw materials, mixture (e.g.
paints, chemical compound), and /or
semi-fabricated materials (e.g. electrical
cable, piping) that are used in the
fabrication of a product.
224
– The system specification is prepared
during the conceptual design phase.
– Development and product
specifications are based on the results
of make-or-buy decisions, and are
generally prepared during preliminary
design.
– Process and material specifications are
more oriented to production and /or
construction activities, and are
generally prepared during the detail
design and development phase.
225
Sample specification tree
226
Example type A system specification format
227
System design requirement
228
Selected design
engineering disciplines
• Reliability engineering
– Reliability can be defined as the
probability that a system or product will
perform in a satisfactory manner for a
given period of time when used under
specified operating conditions.
– Experience indicates that the
transportation, handling, maintenance,
and storages modes are often more critical
from a reliability standpoint than the
environmental conditions during the
periods of actual system utilization.
229
– Define the reliability in terms of
some specific mission scenario.
• Reliability can be defined as the
probability that a system will perform
a designated mission in a satisfactory
manner.
– This definition may imply the
accomplishment of maintenance
activities, as long as It does not interfere
with the successful completion of the
mission.
230
– The basic reliability function R(t), may be
stated as
R(t)=1-F(t)
where
R(t) is the probability of success,
F(t) is the probability that the system
will fail by time t.
F(t) represents the failure distribution
function.
231
– When dealing with failure distributions, one often
assumes average failures rates and attempts to
predict the expected (or average) number of failures
in a given period of time.
• To assist in this prediction, the Poisson distribution (which
is somewhat analogous to the binomial distribution) can be
applied.
– This distribution is generally expressed as

t x e  t
P ( x, t ) 
x!
where  represents the average failure rate, t is
the operating time, and x is the observed number of
failures.
232

t x e  t
P ( x, t ) 
x!
– This distribution states that if an average failure
rate  is known for an item, then it is possible to
calculate the probability P(x,t), of observing
0,1,2,3,….,n number of failures when the item is
operating for a designated period of time t.
– The Poisson expression may be broken down into a
number of terms:
2  t
3  t





t
e

t
e
1  e t  t e t 

2!
3!

t n e  t
 ... 
n!
– Where
e  t
represents the probability of zero failures
occurring in time t.
t e t
is the probability that one failure will
occur, and so on.
233
In addressing the reliability objective, dealing
with the probability of success, the first term in
the Poisson expression is of significance.
• This term representing the exponential distribution is
often assumed as the basis for specifying, predicting,
and later measuring the reliability for a system. In
other words,
R = e-λt = e-t/M
where
M is MTBF (Mean Time Between Failure).
• If an item has a constant failure rate, the reliability of
that item at its mean life is approximately 0.37, or
there is a 37% chance that the item will survive its
mean life without failure.
234
Traditional reliability exponential function
235
Typical failure-rate curve relationships
236
– The bathtub curve will vary
somewhat depending on
• the type of equipment (whether
electronic or mechanical)
• the degree of system/equipment
maturity (new design or production
versus state-of-the-art), and so on.
– As the system evolves from the
design and development stage to the
operational utilization phase, the
ongoing maintenance of software
often becomes a major issue.
237
– The maintenance of software often
has a negative effect on the overall
system reliability.
• The performance of software
maintenance on a continuing basis,
along with the incorporation of system
changes in general, usually impacts the
overall failure rate.
• When a change or modification is
incorporated, bugs are usually
introduced, and it takes a while for
these to be worked out of the system.
238
Failure-rate curve with maintenance(software application)
239
– The failure rate constitutes the number of
failures during a specified interval of
time, or
λ= number of failures/total operating hours
– When defining failures in a pure
reliability sense, this refers to primary or
catastrophic failures
• I.e. instances when the system is not operating
in accordance with specification requirements
due to an actual component failure stemming
from an overstressed condition.
– A component failure may, in turn, cause
other components to fail through a chain
reaction of events.
240
Reliability components relationships
241
– A series network
• All component must operate in a
satisfactory manner if the system
is to function properly
Rs=(RA)(RB)(RC)
• If the system operation is to be
related to a specific time period
Rs  e
- A   B  C t
242
– A parallel redundant network with
two components
• The system will function if either A or
B or both are working
Rs=RA+RB- (RA)(RB)
– A network with three components
in parallel
• For the system to fail, all three
components must fail individually
Rs=1-(1-RA )(1-RB )(1-RC )
243
• In the event that all three components
are identical
Rs=1-(1-R )3
• For a system with n component, the
expression becomes
Rs=1-(1-R )n
– Incorporating redundancy in design
helps to improve system reliability
244
Effect of redundancy on reliability in design
245
– The flight control capability
(incorporating electronic, digital and
mechanical alternatives) in an aircraft is
an example where there are alternate
paths in case of a failure in any one.
– At detailed piece-part level, redundancy
may be incorporated to improve the
reliability of critical functions,
particularly in areas where the
accomplishment of maintenance is not
feasible.
• For example, electronic circuit boards.
246
– The incorporation of extra components in
the design requires additional space and
the costs are higher.
– In evaluating combined series-parallel
networks, like D in the left figure, the
analyst should first evaluate the parallel
redundant elements to obtain the unit
reliability, and then combine the units
with the other elements of the system in a
series format.
Rs=(RA)[1- (1-RB )(1-RC )(1-RD )] [RE+RF- (RE)(RF)] (RG)
247
– Through various applications of seriesparallel networks, a system reliability
block diagram can be developed for use in
reliability allocation, modeling and
analyses, predictions, and so on.
– The reliability block diagram is derived
directly from the system functional
analysis, and is expanded downward.
248
Progressive expansion of the reliability block diagram
(source: MIL-HDBK-338, Electronic Reliability Design Handbook)
249
– When implementing a reliability program
for a typical large-scale system, the
reliability task can be categorized under
three basic areas
• Programming planning, management, and
control(Tasks 1-5).
– Must be closely integrated with system
engineering activities and reflected in the system
engineering management plan (SEMP)
• Design and analysis (Tasks 6-16)
– Constitutes tools used in support of the
mainstream design engineering effort, in response
to reliability program requirements.
• Test and evaluation (Tasks 17-20)
– Must be integrated with system-level testing
activities and covered in the TEMP.
250
Reliability engineering program tasks
251
– Reliability program plan
• developed as part of, or in conjunction with,
the SEMP.
• reliability activities must be closely integrated
with maintainability and logistic support
functions, and must be included in the
respective plans for these program areas.
– Reliability modeling
• The reliability block diagram should evolve
directly from, and support, the system
functional analysis and associated functional
flow diagrams.
• The results of the analysis and predictions of
the reliability block diagram are provided as a
major input for maintainability, human factors,
logistics, and safety analysis.
252
Reliability program tasks in the system life cycle
253
– Failure mode, effect, and criticality
analysis(FMECA)
• an excellent design tool for determining causeand-effect relationships and identifying weak
links.
• useful in maintainability for the development of
diagnostic routines.
• is required in the accomplishment of logistic
support analysis (LSA) relative to the
identification of both corrective and preventive
maintenance requirements.
• constitutes a major input to the reliabilitycentered maintenance(RCM) program.
• Is used to supplement both the fault-tree
analysis and the hazard analysis accomplished
in a system safety program.
254
Application of FMECA to a package handling system.
255
– Fault tree analysis (FTA)
• analysis of different ways in which a particular
system failure can occur, and the probability
of its occurrence.
• a separate fault tree may be developed for
every critical failure mode, or undesired toplevel event.
– Reliability-centered maintenance (RCM)
• Includes an evaluation of the system/process,
in terms of the life cycle, to determine the best
overall program for preventive maintenance.
• emphasis is on the establishment of a costeffective preventive maintenance program
based on reliability information derived from
the FMECA.
256
General approach to conducting a FMECA
257
RPN=(severity rating)(frequency rating)(probability of detection rating)
Sample FMECA worksheet
258
An illustrative fault tree
259
Fault-tree constructive symbology
260
– Failure reporting, analysis, and
corrective-action system
(FRACAS)
• Identified as a reliability program task
designed to address recommendations
for corrective action as a result of
catastrophic failures,
• the overall task objective relates
closely with the system engineering
feedback and control loop.
261
– Reliability qualification testing
• Usually accomplished as part of Type 2 testing.
• There are numerous possibilities for reducing cost
(while still gathering the necessary information)
through the accomplishment of an integrated
testing approach.
– In accomplishing environment test, it may be
possible to gather some reliability information by
observing system operating time, failures, and so
on.
– The gathering of maintainability data during the
performance of formal reliability testing.
• As failures occur during the test, maintenance
actions can be evaluated in terms of elapsed
times and resource requirements.
– Thus, reliability testing must be viewed in the
context of the overall system test effort, and this
requirements for this must be covered in the
TEMP.
262
• Maintainability engineering
– It deals with component packaging,
diagnostics, part standardization
accessibility, interchangeability, mounting
and labeling, and so on.
– A system should be designed such that it
can be maintained without large
investments of time and resources.
– Maintainability is the ability of an item to
be maintained, whereas maintenance
constitutes those actions taken to restore
an item to (or retain an item in) a specified
operating condition.
– Maintainability is a design parameter,
whereas maintenance is the result of
design.
263
– Maintainability, defined in the broadest sense,
can be measured in terms of a combination of
maintenance time, personnel labor hours,
maintenance frequency factors, maintenance cost,
and related logistic support factors.
• There is no single measure that will address all issues.
– To shorten the elapsed time for accomplishing
maintenance by adding more personnel
• Reduce the time required
• Cause an increase in personnel requirements
• A resultant increase in life-cycle cost.
– To reduce the frequency of unscheduled maintenance by
adding the requirements for more scheduled
maintenance.
• There may be an increase in the overall frequency
of maintenance
• Life cycle cost may increase as well.
264
– One of the most commonly used
measures of maintainability is the
aspect of time.
• Uptime pertains to the elapsed time
applicable to the system when
– in operational use, or when
– in a standby or ready state awaiting for
use.
• Downtime refers to the total elapsed
time required, when the system is not
operational, to accomplish
– Corrective maintenance and/or
– Preventive maintenance
265
– Corrective maintenance
• The unscheduled action, initiated as a
result of failure (or a perceived failure),
that are necessary to restore a system to
its required level of performance.
• Such activities may include
–
–
–
–
–
–
–
Troubleshooting,
disassembly,
repair,
remove and replace,
reassembly,
alignment and adjustment
checkout, and so on.
266
– Preventive maintenance
• The scheduled action necessary to retain a
system at a specified level of
performance.
• This may include
– periodic inspection,
– servicing,
– calibration,
– condition monitoring,
– replacement of designated critical items
267
– Total maintenance downtime (MDT)
• the elapsed time required
– to repair and restore a system to full
operational status, and/or
– to retain a system in that condition.
– MDT can be broken down into the
following components
• Active maintenance time
• Logistic delay time (LDT)
• Administrative delay time (ADT)
268
– Active maintenance time
• That portion of downtime when corrective maintenance
and/or preventive maintenance activities are being
accomplished
M
 M ct    fpt M pt 
  fpt
Where
M is the mean active maintenance time
M ct is the mean corrective maintenance of time
M pt is the mean preventive maintenance time
fpt is the frequency of preventive maintenance

is the failure rate
(or frequency of corrective maintenance)
269
– Logistic delay time (LDT)
• The portion of downtime when the system is
not operational because of delays associated
with the support capability, for example
– Waiting for a spare part
– Waiting for the availability of test equipment
– Waiting for the use of a special facility
270
– Administrative delay time (ADT)
• The portion of downtime when the necessary
maintenance is delayed for reasons of an
administrative nature, for example
– The unavailability of personnel because of other
priorities
– Organizational constraints
– Labor strikes
271
– From the design engineer’s perspective, it
is quite common to address only the
active maintenance segment (i.e. M )
– The producer (i.e., contractor) is
responsible for, and usually can control,
active maintenance time, whereas the
LDT and ADT factors are primarily
influenced by the consumer (i.e.
customer)
272
– From the perspective of system
engineering, one needs to deal with the
entire downtime spectrum.
– There is little point in constraining the
design of prime equipment (i.e. an item
must be designed such that it can be
repaired in 30 minutes) if the support
capability is such that it takes 3 months to
acquire the necessary spare part.
273
– The mean corrective maintenance time
M ct


M



  
i
ct i
i
Where
M ct represents the time that it takes to progress
through the corrective maintenance cycle for
the ith item
 i is the corresponding failure rate
i
274
• In the event of fixed number of maintenance
actions, n, then
the mean corrective maintenance time,
M ct
n
M ct 
–
M ct

i 1
M cti
n
which is a weighted average of repair
times using reliability factor, is equivalent
to the mean time to repair (MTTR)
275
Time relationship
276
• The time dependency relationship between
– the probability of corrective maintenance
and
– the time allocated for accomplishing
corrective maintenance
can be expected to produce a probability
density function in one of three common
forms
– The normal distribution
– The exponential distribution
– The log-normal distribution
277
Maintainability distributions
278
– Experience has indicated that in most
instances, the distribution of maintenance
times for complex systems follows the lognormal approximation.
– The median active corrective maintenance
~
time.M ct
n
log M ct




log
M
~
 i
ct
M ct  anti log
 anti log i 1
n
 i
i
279
i
– The maximum active corrective maintenance
time Mmax can be defined as that value of
downtime below which a designated percent
of all maintenance actions can be expected to
be completed.
• Selected points, in the log-normal
distribution, at the 90th or 95th percentile
are generally used.
280

M max  anti log meanlog M ct   Z logM ct
i

where
meanlog M ct  is the mean of the logarithms of M ct
Z is the standard variate at the point where Mmax is
defined
(1.65 at 95%, 1.28 at 90%, 1.04 at 85%, and so on)
 log Mcti is the standard deviation of the sample
logarithms of average repair times, M ct
i
281
i
– In the area of preventive maintenance,
both the mean and the median measures
are used.
– The mean preventive maintenance time
M ptcan be determined by
n
M pt
M



 fpt  M



i
  fpt 
i
where
pti
i 1
pti
n
fpti is the frequency of the individual
(ith ) preventive maintenance
action
M pti is the associated elapsed time to
perform the preventive
maintenance required.
282
– The median value for preventive
~
maintenance M pt is determined from

 fpti  log M pti
~

M pt  anit log
  fpti 
– Preventive maintenance may be
accomplished while the system is
• in full operation, or
• the requirements for such could result
in downtime
283

– Maintenance actions that do not result in
system down time are basically accounted for
through the personnel labor-hour and
maintenance cost measures of maintainability.
– When dealing with the ease and economy in the
performance of maintenance, an objective is to
obtain the proper balance between
• elapsed time
• labor hours
• personnel skills at minimum maintenance
cost
284
– Personnel time may be expressed in
terms of
• maintenance labor hours per system
operating hour (MLH/OH)
• maintenance labor hours per cycle of
system operation (MLH/cycle)
• maintenance labor hours per maintenance
action (MLH/MA)
• maintenance labor hours per month
(MLH/month)
– Any of these factors can be presented
in terms of mean values, such as mean
corrective maintenance labor hours,
MLHc
285
Mean corrective maintenance labor hours,
MLHc
ML H C
 MLH 


  
i
i
i
where
 i is the failure rate of the ith
MLHi
item
maintenance labor hours
necessary to accomplish the
related corrective maintenance
actions
286
– A third measure of maintainability is
maintenance frequency (in addition to
the time and labor-hour factors).
– The frequency factors associated with
primary and secondary failures are
basically reflected through the reliability
MTBF and
.
• these measures are important for
determining the overall frequency of
unscheduled maintenance.
287
– Mean time between maintenance
(MTBM)
• The total spectrum of maintenance
1
MTBM 
1 / MTBM u  1 / MTBM s
• MTBMu is the mean interval of
unscheduled (or corrective) maintenance.
• MTBMs is the mean interval of scheduled
(preventive) maintenance.
288
– The reciprocals of MTBMu and MTBMs are
equivalent to the maintenance rates, or the
maintenance actions per hour of system
operation.
– MTBMu should be equivalent to MTBF
assuming that the possibilities of operatorinduced defects, maintenance-induced defects,
and so on, have been designed out of the system.
– MTBR Mean time between replacement
• some maintenance actions result in
– the removal and replacement of components
– the requirement for spare parts
• MTBM factors reflects all maintenance actions, some
of which result in item replacements.
289
System XYZ unscheduled maintenance actions
290
– Reliability and maintainability factors
are key inputs in determining system
availability A
uptime
A
uptime  downtime
• Operational availability, Ao
• Achieved availability, Aa
• Inherent availability , Ai
– In dealing with system engineering
requirement, the Ao factor is more relevant than
the Aa or Ai.
291
– Operational availability
MTBM
Ao 
MTBM  MDT
• consumer’s operational environment.
• MTBM reflects all maintenance
requirements.
• MDT represents all downtime
considerations.
292
– Achieved availability
MTBM
Aa 
MTBM  M
•
M is mean active maintenance time
• in instance where
– a producer is responsible for designing a system
to meet a certain availability requirement.
– the producer has no influence or control of the
consumer’s support structure.
• LDT and ADT factors are not considered
293
– Inherent availability
MTBF
Ai 
MTBF  M ct
• employing this figure of merit may be
appropriate from a contractual standpoint
where the producer is somewhat isolated
from the consumer environment.
• preventive maintenance is not included.
294
Ai=1
MTBF
MTBF
Ai=C
Ai=C
Ai=0
MTTR
MTBF vs. MTTR
1/MTTR
MTBF vs. 1/MTTR
295
– The maintainability program tasks can be
categorized under
• program planning, management, and control
• design and analysis
• test and evaluation
296
– Program planning, management, and
control
• Maintainability program plan
• Review and control of suppliers or
subcontractors
• Maintainability program reviews
• Data collection analysis, and corrective-action
system
297
– Design and analysis
•
•
•
•
•
•
•
•
Maintainability modeling
Maintainability allocation
Maintainability prediction
FMECA-maintainability information
Maintainability analysis
Maintainability task analysis (MTA)
Level-of repair analysis (LORA)
Maintainability data for the detailed
maintenance plan and the LSA (Logistic
support analysis)
– Test and evaluation
• Maintainability demonstration
298
– Maintainability program plan
• developed as part of, or in conjunction with , both the
reliability program plan and the SEMP.
– Maintainability modeling
• the completion of maintainability modeling , along
with several others (e.g., allocation, prediction,
FMECA, maintainability analysis), depends on the
development of functional-level diagrams.
• the objective is to illustrate system packaging concepts,
diagnostic capabilities ( depths of localization and fault
isolation), items that are repaired in place or removed
for maintenance, and so on.
• the results of this task constitute a major input to the
MTA and LSA, and must be provided in a timely
manner.
299
– FMECA
• used as an aid in the development of system packaging
schemes and diagnostic routines, and is employed to
assist in determining critical preventive maintenance
requirements.
– Maintainability analysis
• includes the design-related studies dealing with system
functional packaging concepts, levels of diagnostics,
levels of repair, built-in versus external test, and so on.
300
– Maintenance task analysis (MTA)
• includes a detailed analysis and evaluation of
the system to
– assess a given configuration relative to the degree
of incorporation maintainability characteristics in
design and compliance with the initially specified
requirements
– determine the maintenance and logistic support
resources required in order to support the system
throughout its planned life cycle. Such resources
may include
• maintenance personnel quantities and skill
levels
• spares and repair parts and associated
inventory requirements
• tools and test equipment
• transportation and handling requirements
• facilities, technical data, computer software,
and training requirements
301
– Maintainability demonstration
• usually accomplished as part of Type 2 testing,
should be defined in the context of the total
system test and evaluation effort.
• the objective is to
– simulate different maintenance task sequences
– record the associated maintenance times
– verify the adequacy of the resources required to
support the demonstrated maintenance activities.
• the results should
– determine whether maintainability requirements
have been met
– help to determine whether the supportability
objectives have been met in response to logistic
support requirements
• the requirements must be covered in the TEMP.
302
System/decomposition for maintainability analysis and prediction
303
Maintainability program tasks in the system life cycle
304
Example of the relationships between selected reliability and maintainability
305
Abbreviated logic troubleshooting flow diagram
306
Maintenance task analysis (part1)
307
Maintenance task analysis (part2)
308
Repair versus discard evaluation (Assembly A-1)
309
Summary of repair-level decisions
310
System Engineering Program Planning
• The SEMP(System Engineering Management Plan)
– which is generally developed during the conceptual design
and advanced planning phase,
– covers all system engineering management activities
through out the system life cycle, including
•
•
•
•
those pertaining to system operations,
support,
retirement,
and modifications to the system configuration.
311
• The SEMP constitutes the Chief Engineer’s
plan for identifying and integrating all
major engineering activities, i.e. the top
technical plan that causes the integration of
the many more subordinate plans such as
– The mechanical engineering design plans
– The reliability and maintainability program
plans.
– The human factors and safety program plans.
312
System engineering planning
313
• Preparation of the SEMP is the
responsibility of the System Manager, and
may be accomplished
– by the customer(consumer/user) or
– by a major contractor(producer).
• In some instances (particularly for large
programs), an initial SEMP
– for the overall system may be prepared by the
customer,
– with a lower-level SEMP prepared by the
producer
314
• Three sources that include coverage of the
SEMP are
– IEEE-STD-1220
Standard for the Application and Management
of the Systems Engineering Process
– IS-632 (EIA Electronic Industries Association)
System Engineering
– DSMC (Defense System Management College)
System Engineering Management Guide
315
System Engineering Management Plan
(EIA Engineering Standard 632)
316
System Engineering Management Plan (SEMP) outline
( MIL-STD-499A)
317
Statement of Work (SOW)
• SOW is a narrative description of the work
required for a given project.
• With regard to the SEMP, it must be developed
from the overall project SOW described in the
PMP (Program Management Plan).
• SOW forms a basis for
– the definition and costing of detailed tasks
– the establishment of subcontractor and supplier
requirements
318
• SOW should include
– A summary statement of the tasks to be accomplished.
– An identification of the input requirements from the
other tasks.
– Reference to applicable specifications (to include the
System A Specification), standards, procedures, and
related documentation as necessary for the completion
of the defined scope of work.
– A description of the specific results to be achieved.
•
•
•
•
Deliverable equipment
Software
Design data
Reports and/or related documentation
319
Output Requirements for
Functional Analysis and Allocation
• Specific functional requirements need to be
communicated to program/project personnel
through
–
–
–
–
–
Time line analysis sheets
Requirements allocation sheets (RASs)
Trade-off study reports
Test requirements sheets
Design criteria sheets
320
• Time line analysis sheets (TLS)
– Time line analysis adds considerable detail in defining
the duration of various functions.
– TLS is used to perform and record the analysis of timecritical functions and functional sequences.
• Time critical function are those affect reaction time, down
time, or availability
– TLS complements the FFBD in its ability
• to show a lower levels of details
• to illustrates the impact of concurrent functions within a given
sequence.
– TLSs are used to support the development of design
requirements for the operation, test and maintenance
functions.
321
• Requirements allocation sheets (RASs)
– The primary document for the identification of specific
design requirements based on the functional analysis.
– A RAS is developed for each block in the FFBD
(Functional Flow Block Diagram)
322
– The RAS serves three purposes in documenting the
systems engineering process
• Initially, record the performance requirements established for
each function.
• During the synthesis, show the allocation of the functional
performance requirements to individual system elements or a
combination of elements.
• Following evaluation and decision, provide the functionally
oriented data required in the description of the system
elements.
323
System engineering documents
(for large-scale system)
324
Development of a
Work Breakdown Structure (WBS)
• SOW
WBS
• WBS is product-oriented family tree that leads to
the identification of
–
–
–
–
–
Activities
Functions
Tasks
Subtasks
Work packages
325
• During the early stages of system planning, a
Summary Work Breakdown Structure (SWBS) is
usually prepared by the customer and included in a
Request for Proposal (RFP) or an Invitation for
Bid (IFB).
• SWBS
– Developed from the top-down
– Primarily for budgetary and reporting purposes
– Covers all programs functions
326
Partial work breakdown structure development
327
• SWBS
CWBS
(Contract Work Breakdown Structure )
• The CWBS
– is tailored to a specific contract (or procurement
action)
– may be applicable to prime contractors,
subcontractors, and /or suppliers.
328
Example summary work breakdown structure
329
• The WBS
– is not an organizational chart in terms of project
personnel assignments and responsibilities
– does represent an organization of work
packages prepared for the purposes of
•
•
•
•
program planning
budgeting
contracting
reporting
330
• If the WBS
– does not contain enough levels then the
management visibility and the integration of
work packages may prove to be difficult.
– contain too many levels, too much time may be
wasted in performing program review and
control actions.
331
CWBS expansion showing system engineering activities
Conceptual design and advance planning phase
332
CWBS expansion showing system engineering activities
Preliminary system design phase
333
• The element of the WBS may represent
– an identifiable item of equipment or software
– a deliverable data package
– an element of logistic support
– a human service
– a combination thereof
334
• WBS element should be selected to permit
– the initial structuring of budgets
– the subsequent tracking of technical
performance measures (TPMs) against cost.
335
• Program activities are broken down to the lowest
level that can be associated with both an
organization and a cost account.
• In developing the WBS, it is essential that a good
comprehensive WBS Dictionary be prepared.
– WBS Dictionary contains the terminology and
definition of each element.
336
Organizational integration with CWBS
337
• In the initial generation of a CWBS by a
contractor during the preparation of a proposal,
budgets may be allocated downward to specific
tasks.
• After contract award as tasks are being
accomplished, costs are then collected upward for
reporting purposes.
• The WBS provides the vehicle for measuring
work package progress in terms of schedule and
cost.
338
風 險 定義
•風險
:不如意事件之可能發生及其後果
•不確定性:只考慮發生之可能性
•風險三大要素 - 事件 或然率 損失程度
•風險量RE - 不幸結果發生機率P(UO)與其
造成損失L(UO)之乘積 RE = P(UO)*L(UO)
•計畫之目標 - 風險量最小化 效益最大化
339
風險概念
低度風險
(
發
生
之
機
率
不
確
定
性
高度風險
中度風險
)
低度風險
增加
後果嚴重性
340
風險等級
1.0
高
0.75
發
生
機
率
0.5
中
0.25
低
0
0
500
1000
衝擊嚴重性*
*可為 成本 時程 性能 或其他可量測因素 亦可為 不同 權
重比之組合
341
風險種類
•
•
•
•
•
技術性風險- 與性能有關
支援性風險- 與性能有關
計畫性風險- 與環境有關
成本風險
時程風險
342
五種風險間之關係
技術
計畫
支援
成本
時程
343
過去的風險架構
風險管理責任
規劃
評估
風險評估
產生變通方式
變通方式評鑑
風險評估
風險評估
變通方式選擇
風險降低
實施
風險降低
風險管理
風險降低
風險管理
風險分析
344
更新的風險管理架構
風險管理
風險規劃
風險評估
風險分析
風險處置
345
計畫生命週期中風險
與所造成損失間關係
全計畫生命週期
完成
策劃
第一階段
概念
風
險
增
加
第二階段
發展
第三階段
實施
第四階段
完成
機會及風險
最大風險
發生時段
最大風險
衝擊時段
損失量
損
失
增
加
時間
346
風險管理程序
執行階段
風險規劃
•資
源
•焦
點
•技
術
•需
求
•責
任
風險評估
•專家訪
談
•同類比
較
•規劃審
查
•教訓探
討
•技術評
鑑
風險分析
•網路分析
•工作細分模擬
•生命週期模式
•快速反應模式
•決策分析
•列表檢查
•轉移樣板
•性能追蹤
風險處置
•規避
•控制
•承擔
•轉移
•知識與研究
347
應用技術
項
次
1
2
3
4
5
6
7
8
9
1
1
1
1
1
1
1
1
1
1
2
0
1
2
3
4
5
6
7
8
9
0
技
專
同
規
轉
決
預
網
生
成
工
風
性
成
獨
獨
風
風
風
風
風
知
家
類
劃
移
策
測
路
命
本
作
險
能
本
立
立
險
險
險
險
險
識
訪
比
審
樣
分
關
分
週
風
細
因
追
性
技
成
處
規
控
承
轉
與
●
術
談
較
查
板
析
係
析
期
險
分
子
蹤
能
術
本
理
避
制
擔
移
研
主
名
風
評
稱
險
估
風
分
●
●
●
●
分
/
模
報
術
預
技
析
擬
告
評
測
術
模
分
鑑
險
析
○
○
○
○
○
○
●
●
●
●
●
○
○
○
●
●
●
●
○
●
方
式
險
置
○
○
○
○
○
○
○
式
析
究
要
風
處
○
次
要
方
式
○
○
○
○
○
●
●
●
●
●
●
348
風險因子評估法則
鑑別風險項目
求出失敗機率
求出失敗後果
計算風險因子
高 度 風 險
RF>0.7
是
?
否
1.風險報告
2.風險減免規劃
3.特別評估
4.計畫室列管
中 度 風 險
RF>0.3
?
否
是
1.風險報告
2.風險減免規劃
3.正常評估
4.系統列管
低 度 風 險
1.正常評估
2.屬計畫工作報
告之追蹤項目
3.分系統列管
349
風險因子計算公式
RF  Pf  C f  Pf C f
P f  a P M h w  b P M s w  c PC h w  d PC s w  e P D
C
f
RF
 fC t  g C c  h C s
風 險 因 子
Pf
失 敗 機 率
C f
失 敗 後 果
P M hw 硬 體 技 術 成 熟 度 造
t
對 其 他 項 目 依 賴 造 成 之 失
敗 機 率
技 術 問 題 造 成 之 失 敗 後 果
c
成 本 改 變 造 成 之 失 敗 後 果
s
時 程 改 變 造 成 之 失 敗 後 果
PD
C
C
C
成 之 失 敗 機 率
P M sw 軟 體 技 術 成 熟 度 造
P C hw
P C sw
成
硬
失
軟
失
之
體
敗
體
敗
失
複
機
複
機
敗 機 率
雜 度 造 成 之
率
雜 度 造 成 之
率
a  b  c  d  e  1
失 敗 機 率 各 項 目 權 重
f  g  h  1
失 敗 後 果 各 項 目 權 重
350
風險評估失敗機率表
大小
成 熟 因 子
複 雜 因 子
PMhw ， PMsw
PChw ，PCsw
0.1
現有
簡單設計
0.3
局部重新設計
複雜度低度增加
0.5
重要改變可行
複雜度中度增加
0.7
技術備便設計複雜
複雜度高度增加
0.9
新技術
硬體部份研究完成
軟體以前未曾做過
極度複雜
依 賴 度 因 子
PD
不依賴現有系統、設施與相關合約
商
時程依賴現有系統、設施與相關合
約商
性能依賴現有系統、設施與相關合
約商
時程依賴新的系統、設施與相關合
約商
性能依賴新的系統、設施與相關合
約商
351
風險評估失敗後果表
技術因子
大小
Ct
成本因子
Cc
時程因子
Cs
0.1 影響微小
未超過原定預算，部份子科 對計畫之衝擊可忽略、少量
目轉移
時程更動仍在預留時程裕
度內
0.3 少部份技術性能變差 超過原定預算1％～5％
微量時程延後（少於一個
月），部份評審點需作調整
0.5 部份技術性能變差 超過原定預算5％～20％ 少量時程延後
0.7 技術性能顯著變差 超過原定預算20％～50％ 時程延後超過三個月
0.9 技術目標不可能達成 超過原定預算50％以上
時程大幅落後，影響部份評
審點或全系統評審點
352
風險等級
Pf
RF = Cf + Pf - Cf Pf
高
0.7
中
0.3
低
RF=0.7
RF=0.3
0.3
0.7
Cf
353
品質機能展開法簡介
(Quality Function Deployment)
•1960年代末始於日本 - 三菱造船
•1970年代日本企業普遍應用
•1980年代導入美國
•早期用於新產品開發
•為產品或服務規劃之一套程序方法論
•以顧客的心聲為出發點
•需要之輸入決定最好透過團體完成
•特性滿足研究發展計畫風險管理需求
354
品質機能展開風險管理架構
風險策略
風險影響
風險分類
使
用
者
需
求
風
險
分
類
風
險
影
響
風險處置矩陣
風險分析矩陣
風險評估矩陣
355
風險管理實施階段
風險評估階段
•發 掘 可 能
產生風險
之因素並
予分類
•使 用 者 需
求
•風 險 分
類
•關 係 係
風險分析階段
風險處置階段
•分 析 風 險
因素造成
之影響
•決 定 風 險
處置策略
•風 險 分
類
•風 險 影
響
•關 係 係
•風 險 影
響
•風 險 策
略
•關 係 係
356
使用者需求訂定之準則
•技術成效
範圍、品質、執行初期所訂技術需求達成度。
•計畫執行效率
成本、時程等目標符合程度。
•管理與組織的作為
委託使用者滿意程度，計畫策略，團隊合作策略，計畫達成而不
影響團隊合作文化及價值。
•人員成長
專業發展，計畫團隊成員對工作興趣、挑戰性及專業能力成長之
滿意度。
•計畫結案
結案後查帳分析之品質，結案時之完整性，無遺留問題。
•技術創新
核心技術競爭能力，鑑定及解決技術問題之能力。
•可製造能力及經營績效
357
計畫成品量產簡易性及其商業市場獲利能力。
風險分類
•技術性風險
技術變更、系統複雜度、需求變更、性能、整合介面。
•支援性風險
。
材料可用性、人員可用性、裝備可用性、人員技能素質
•計畫性風險
管理、時程、成本、資金流動、喪失潛能。
•外在性風險
市場、環境衝擊、社會問題、通貨膨漲、自然災害。
•法規性風險
証照、專利權、契約利潤、取締、規定調整變更。
358
風險影響
•效益
•完成度
•成本
•可靠度
•計畫環境
359
風險處置策略
•規避
因潛在不良後果，不接受此種風險。
•降低防範
用再評估或發展突發事件處理方案等必要方式，
防範控制該風險。
•接受(承擔)
瞭解該風險可能造成後果，接受它。
•轉移(分擔)
與其他單位人員分擔甚或全數轉移此風險；亦可
能化風險為機會。
•知識研究
發展測試模擬方法預估結果。
360
關係係數
• 表示
•
•
•
•
 使用者需求與風險分類兩者間之關係
 風險分類和風險影響兩者間之關係
 風險影響和風險策略兩者間之關係
9表示二者間有強烈關係。
5表示二者間有中等關係。
1表示二者間有微弱關係。
0表示二者間沒有任何關係。
361
風險評估矩陣表
日 期 :
風 險 分 類
系 統 /分 系 統
風 險 評 估 矩 陣
使 用 者 需 求
輕
重
權
衡
數
填 表 人 :
審 核 人 :
362
風險分析矩陣表
日 期 :
風 險 影 響
系 統 /分 系 統
風 險 分 析 矩 陣
風 險 分 類
填 表 人 :
審 核 人 :
輕
重
權
衡
數
363
風險處置矩陣表
日 期 :
風 險 策 略
系 統 /分 系 統
風 險 處 置 矩 陣
風 險 影 響
填 表 人 :
審 核 人 :
輕
重
權
衡
數
364
風險評估程序
程序一
•訂定使用者需求項目
•決定輕重權衡數
•與會人員需達成共識
•輕重權衡數 -1與10間之任何實數
• 1表低度重要
• 5表中度重要
• 9表高度重要
程序二
•訂定風險分類項目
•與會人員需達成共識
程序三
•決定使用者需求與風險分類項目
間之關係數值
程序四
•計算各關係係數值與對應輕重權
衡數乘積總和
•積分高者代表優先等級高
•下一階段風險分析矩陣內風險分
類對應項目其輕重權衡數應較高
365
風險分析程序
程序一
•運用上一階段風險分類項目，依總
和積分訂定輕重權衡數
•與會人員需達成共識
•輕重權衡數 -1與10間之任何實數
• 1表低度重要
• 5表中度重要
• 9表高度重要
程序二
•訂定風險影響項目
•與會人員需達成共識
程序三
•決定風險分類與風險影響項目間
之關係數值
程序四
•計算各關係係數值與對應輕重權
衡數乘積總和
•積分高者代表優先等級高
•下一階段風險處置矩陣內風險影
響對應項目其輕重權衡數應較高
366
風險處置程序
程序一
•運用上一階段風險影響項目，依總
和積分訂定輕重權衡數
•與會人員需達成共識
•輕重權衡數 -1與10間之任何實數
• 1表低度重要
• 5表中度重要
• 9表高度重要
程序二
•訂定風險處置項目
•與會人員需達成共識
程序三
•決定風險影響與風險處置項目間
之關係數值
程序四
•計算各關係係數值與對應輕重權
衡數乘積總和
•積分高者代表優先等級高
367