Module 1 Introduction to Systems Engineering

Module 1 Introduction to Systems Engineering
MSE607B Systems Engineering - Prof. David Shternberg MSE607B Systems Engineering Module 1 Introduction to Systems Engineering System Engineering A system is made up of various components that must function together as a single system. This module addresses how different subsystems or components work together to form a system and how to utilize a systems engineering approach to develop, operate, and maintain the components of the system. This process can be applied to any other component of a system. California State University, Northridge

Introduction to Systems Engineering
MSE607B Systems Engineering - Prof. David Shternberg Introduction to Systems Engineering Topics Importance of systems engineering in engineering practice Subject of “systems” in general Origins of systems engineering Module 1: Introduction to Systems Engineering A system is made up of various components that must function together as a single system. This module addresses how different subsystems or components work together to form a system and how to utilize a systems engineering approach to develop, operate, and maintain the components of the system. This process can be applied to any other component of a system. The topics that will be covered in this module include the following: The importance of systems engineering in engineering practice, The subject of “systems” in general, and The origins of systems engineering California State University, Northridge

MSE607B Systems Engineering - Prof. David Shternberg Learning Objectives By the end of this module, you will be able to: Explain the need for creating systems and what requirements they address Define some terms and characteristics of systems Evaluate systems based on their ability to fulfill specific needs Discuss what activities management perform to support the system engineering process Learning Objectives By the end of this module, you will be able to: Explain the need for creating systems, and what requirements they address. Define some terms and characteristics of systems necessary for further discussions about the subject of Systems Engineering Evaluate systems based on their ability to fulfill specific needs Discuss what activities management perform to support the system engineering process. California State University, Northridge

The Current Environment
Introduction to Systems Engineering MSE607B Systems Engineering - Prof. David Shternberg The Current Environment Requirements are constantly changing Greater emphasis on total systems Structures become more complex Life cycles of systems are extended; life cycles for technologies are shorter Utilize commercial off-the-shelf (COTS) equipment Increasing globalization Greater international competition Increase in outsourcing Decrease of available manufacturers Higher overall life cycle costs The Current Environment In today’s industry, the customer’s requirements for a given product are constantly changing because of changes in technology and changing priorities. There is greater emphasis on total systems versus the components of a system. Suppliers are requested to integrate components together and provide complete system solutions. As technologies evolve, structures of many systems become more complex. The life cycles of many systems are being extended while the life cycles for the technologies used to create them are being shorter because new technologies become available. This requires system designs that will allow new technologies to be incorporated. To obtain efficient procurement cycles, it is necessary to utilize commercial practices, processes, and off the shelf equipment. As the world “becomes smaller” and with increasing globalization, systems integrators depend on different countries throughout the world than even before. To support this trend, there are improved communication, packaging, and transportation methods. Along with the trends towards globalization, there is greater international competition in systems design and manufacturing. Systems manufacturing relies more and more on outside suppliers, where most of the work is done outside the manufacturing plant. As a result, there are more suppliers to monitor and manage than ever before. The increasing globalization, outsourcing, and international competition result in a decrease of available manufacturers of many products. Life cycles of most systems today are increasing, mainly because little or no attention was given about operation and support of the systems during the design phase, resulting in higher overall life cycle costs. California State University, Northridge

The Need for Systems Engineering
Introduction to Systems Engineering MSE607B Systems Engineering - Prof. David Shternberg The Need for Systems Engineering System engineering addresses various needs to be more effective and efficient in: Development and acquisition of new systems Operation and support of systems already in use Need to consider key concepts and definitions The Need for Systems Engineering System engineering addresses various needs to be more effective and efficient in the development and acquisition of new systems and the operation and support of systems already in use. In order to better understand system engineering, we need to consider some key concepts and definitions. California State University, Northridge

Why Systems Engineering?
Introduction to Systems Engineering MSE607B Systems Engineering - Prof. David Shternberg Why Systems Engineering? Mars Climate Orbiter Lost in September 1999 Root cause of loss was failed translation of English units into metric units in a segment of ground-based, navigation-relation mission software "The problem here was not the error, it was the failure of NASA's systems engineering, and the checks and balances in our processes to detect the error. That's why we lost the spacecraft.“ – Dr. Edward Weiler Why Systems Engineering? The failure of the Mars Climate Explorer is an example of a failed system. The Mars Climate Explorer was lost in space in September of 1999. The 'root cause' of the loss of the spacecraft was the failed translation of English units into metric units in a segment of ground-based, navigation-related mission software. "People sometimes make errors," said Dr. Edward Weiler, NASA's Associate Administrator for Space Science. "The problem here was not the error, it was the failure of NASA's systems engineering, and the checks and balances in our processes to detect the error. That's why we lost the spacecraft." California State University, Northridge

MSE607B Systems Engineering - Prof. David Shternberg Definition of System Generated from the Greek word systēma An “organized whole” Merriam-Webster Dictionary A regularly interacting or interdependent group of items forming a unified whole Another definition Any set of interrelated components working together with the common objective of fulfilling some designated need Definition of System The word System is generated from the Greek word systēma, meaning an “organized whole.” Merriam Webster’s Collegiate Dictionary defines a system as “a regularly interacting or interdependent group of items forming a unified whole.” Another definition is that a system is any set of interrelated components that could be seen as working together with the common objective of fulfilling some designated need. We will now consider some additional definitions of system. California State University, Northridge

Additional Definitions
Introduction to Systems Engineering MSE607B Systems Engineering - Prof. David Shternberg Additional Definitions International Council on Systems Engineering (INCOSE) An interdisciplinary approach and means to enable the realization of successful systems MIL-STD-499 An interdisciplinary approach that encompasses the entire technical effort to evolve and verify an integrated and life cycle balanced set of people, products, and process solutions that satisfy customer (stakeholder) needs Additional Definitions The International Council on Systems Engineering (INCOSE) defines System as “an interdisciplinary approach and means to enable the realization of successful systems.” One of the early Military Standards on the subject, MIL-STD-499, defines a system as “an interdisciplinary approach that encompasses the entire technical effort to evolve and verify an integrated and life cycle balanced set of people, products, and process solutions that satisfy customer (stakeholder) needs.” California State University, Northridge

Additional Definitions (cont.)
Introduction to Systems Engineering MSE607B Systems Engineering - Prof. David Shternberg Additional Definitions (cont.) General Characteristics Complex combination of resources Contained within some form of hierarchy May be broken down into subsystems and related components Allows for simpler approach and analysis of the system and its functional requirements Must have a purpose Functional Able to respond to identified need Able to achieve its objective Cost-effective Must respond to an identified functional need A “system” may be defined further in terms of the following general characteristics: A complex combination of resources - to accommodate many functions often requires large amount of personnel, equipment, facilities, and data. These have to be effectively combined. A system is contained within some form of hierarchy – a freeway may be part of a freeway system, which is part of the overall transportation system, which is operated in a specific geographic environment, which is part of the world, and so on. A system may be broken down into subsystems and related components, depending on how complex it is. Dividing the system into smaller units allows for simpler approach and analysis of the system and its functional requirements. A system must have a purpose – it must be functional, able to respond to some identified need, and able to achieve its overall objective in a cost-effective manner. A system must respond to an identified functional need. Thus, the elements of a system must be available, in place, and ready to respond to a given need in order to ensure successful completion of a mission. California State University, Northridge

Origins of Systems Engineering
Introduction to Systems Engineering MSE607B Systems Engineering - Prof. David Shternberg Origins of Systems Engineering Foundation in the Natural and Physical Sciences Driven by: Complex Systems Military, Space, Aerospace Longer Life Cycles Systems Failures Origins of Systems Engineering Systems Engineering has its foundation in the natural and physical sciences. It was driven by complex systems design requirements. The functions systems had to fulfill became more complex, and so were the military, space, and aerospace specifications detailing their operations. As projects became more costly, it was necessary to ensure that the system design addressed the need for the system to function over a longer life cycles. Lastly, as various systems failed, future requirements became more and more demanding, requiring a methodical, specific discipline to address this need. California State University, Northridge

Origins of Systems Engineering (cont.)
Introduction to Systems Engineering MSE607B Systems Engineering - Prof. David Shternberg Origins of Systems Engineering (cont.) Example: Transportation System Physical Features Main lanes, ramps, connectors, and carpool lanes Operational controls Speed limits, regulatory restrictions, and management controls All components must work together to achieve the common objective For example, let’s consider a freeway as a transportation system in and of itself. It includes physical features, such as main lanes, ramps, connectors, and carpool lanes and operational controls, such as speed limits, regulatory restrictions, and management controls. All components must work together to achieve the common objective of the freeway: the safe and efficient movement of people and goods. California State University, Northridge

MSE607B Systems Engineering - Prof. David Shternberg Multiple Disciplines System Engineer Responsible for integration of multiple components into one system Must have knowledge in: Mechanical Electrical Computer Science Civil Chemical Engineering Cross-functional, multi-discipline engineers Multiple Disciplines Systems engineering includes in it multiple engineering disciplines. A system engineer is responsible for the integration of multiple components into one system, and has to have knowledge in: Mechanical, Electrical, Computer science, Civil, and Chemical engineering. Many companies who perform systems integration do that by utilization of cross-functional, multi-discipline engineers. California State University, Northridge

MSE607B Systems Engineering - Prof. David Shternberg Elements of a System Primary Components Physical objects, concepts, processes, feelings, and beliefs System Boundary Encompasses components that can be directly influenced or controlled Environment Factors that have influence on the effectiveness of a system, but cannot be controlled Elements of a System A system is comprised of primary elements or components, which may be physical objects, concepts, processes, feelings, and beliefs represent some system components; system boundary, which encompasses components that can be directly influenced or controlled; and environment that includes all factors that have influence on the effectiveness of a system, but cannot be controlled. California State University, Northridge

Elements of a System (cont.)
Introduction to Systems Engineering MSE607B Systems Engineering - Prof. David Shternberg Elements of a System (cont.) Example: Freeway System Environment System Boundary Weather/Season Access Roads Vehicle Characteristics Operational Control Guidance/Navigation Origins/Destinations As an example, let’s consider the elements of a freeway system. System Boundary contains main lanes, guidance and navigation, operational control, ramps and connectors, law enforcement, High Occupancy Vehicles, and access roads. Only those elements that can be directly influenced by the traffic engineer are inside the boundary. In the freeway system, components such as weather, driving population, vehicle characteristics, traffic composition, drivers’ origins and destinations are all part of the environments since they cannot normally be controlled or influenced by the traffic engineer. HOV Main Lanes Enforcement Traffic Composition Ramps and Connectors Driving Population California State University, Northridge

MSE607B Systems Engineering - Prof. David Shternberg Types of Systems Natural Systems Came into being through natural processes Examples: River System and Energy System Man-Made Systems Developed by human beings Physical and Conceptual Systems Static and Dynamic Systems Closed and Open-Loop Systems Types of Systems There are 5 different types of systems: natural systems, man-made systems, physical and conceptual systems, static and dynamic systems, and closed and open-loop systems. Natural systems include those that came into being through natural processes. Examples include a river system and an energy system. Man-made systems are those that have been developed by human beings. Examples include bridges, airplanes, and space vehicles. Physical and conceptual systems. Physical systems are those made up of real components occupying space. Examples include a lake, aquarium, and Earth. Conceptual systems can be an organization of ideas or a set of specifications and plans. Examples include flight simulation, construction plans, and mathematical models. Static and dynamic systems. Static systems include those having structure, but without activity. Examples are a highway bridge, a warehouse, and a house. A dynamic system is one that combines structural components with activity. Examples are manufacturing capability of a company, airport system, and freeway systems. Closed and open-loop systems. A closed system is one that is relatively self-contained and does not significantly interact with its environment. It involves feedback to ensure that set conditions are met. Examples are chemical equilibrium process, electrical circuit, and a central heating system. Conversely, open-loop systems interact with their environments. In open loop control, the sequence of commands in a program is carried out irrespective of the consequences. Boundaries are crossed and there are interactions among the system components. Examples are steering of a car, a stove top burner, and a watering hose. California State University, Northridge

Costs of New System Development
Introduction to Systems Engineering MSE607B Systems Engineering - Prof. David Shternberg Costs of New System Development Costs of New System Development The figure shows how the costs of systems engineering increase due to changes imposed later in the program development phase. Changes are easier to make during the design phases. However, as overlooked elements are being discovered during prototype and production manufacturing, documents have to be revised, customer approval needs to be obtained, and hardware needs to be scraped or modified. These latter changes drive the program costs over the initial estimated costs. California State University, Northridge

MSE607B Systems Engineering - Prof. David Shternberg When Things Go Wrong Easy to say “design was bad” What is the “right” way to do it? Most systems have to be modified in order to ensure better performance Systems engineering is about learning from experience When Things Go Wrong When things go wrong and systems don’t perform as expected, it is easy to say that the design was bad. But what is the “right” way to do systems engineering? Reality indicates that most systems, complex as well as simple, have to be modified in order to ensure better performance. Systems engineering is all about learning from experience and integrating the elements of engineering and manufacturing early in the design phase to ensure that all concerns are being addressed and that the design will perform as required with minimum changes. California State University, Northridge

Three Laws of Systems Engineering
Introduction to Systems Engineering MSE607B Systems Engineering - Prof. David Shternberg Three Laws of Systems Engineering Everything interacts with everything else Anything done to the system creates impacts that ripple throughout the system Everything goes somewhere When working with a system, one deals with multiple interfaces Account for interface and follow where it goes There is no such thing as a free lunch Everything comes at a price Three Laws of Systems Engineering There are three unspoken laws of systems engineering that come to mind for the various activities within the systems engineering process. They are: Everything interacts with everything else. Anything done to the system creates impacts that ripple throughout the system and can never be ignored. Everything goes somewhere. When working with a system, one deals with multiple interfaces. These interfaces have to be consistent and account for all things generated. You must account for everything at the interface and follow where it goes. If it leaves some place, then it must arrive someplace else. There is no such thing as a free lunch. Never become so enamored with a design decision that you forget the negative aspects of that decision. Everything comes at a price. California State University, Northridge

Who Does Systems Engineering?
Introduction to Systems Engineering MSE607B Systems Engineering - Prof. David Shternberg Who Does Systems Engineering? Military/Govt Companies and Agencies Raytheon, Eaton, Parker, Boeing, Airbus, NASA International Council on Systems Engineering (INCOSE) Non-profit membership organization founded in 1990 International Centers for Telecommunication Technology (ICTT) Specializes in solving its clients’ complex systems problems All Companies and Engineers Who Does Systems Engineering? Military and government companies and agencies, like Raytheon, Eaton, Parker, Boeing, and NASA use systems engineering to support project development for the aerospace and defense systems. The International Council on Systems Engineering (INCOSE) is a non-profit membership organization founded in INCOSE is an international authoritative body promoting the application of an interdisciplinary approach and means to enable the realization of successful systems. International Centers for Telecommunication Technology (ICTT) specializes in solving its clients’ complex systems problems, whether mechanical, hydraulic, chemical, biological, electronic, computer software, communication network, or integrated processes spanning manufacturing, service delivery, and business organizations. All companies and engineers perform some level of systems engineering. Companies whose product is used in a higher-level system must take into account how the components they design and produce will perform when installed on the end use system. California State University, Northridge

Characteristics of a System Engineer
Introduction to Systems Engineering MSE607B Systems Engineering - Prof. David Shternberg Characteristics of a System Engineer Big picture person Focus on the objectives of the end user/stakeholder Be able to take a broad perspective. Leave nothing out and pay attention to details Be able to consider and address all contingencies Characteristics of a System Engineer A system engineer needs to be a “big picture” person, who has a thorough understanding of the system. He or she must also focus on the objectives of the end user/stakeholder, be able to take a broad perspective, leave nothing out and pay attention to details and be able to consider and address all contingencies to provide a total solution. California State University, Northridge

A Mental Model for Systems Engineering
Introduction to Systems Engineering MSE607B Systems Engineering - Prof. David Shternberg A Mental Model for Systems Engineering Systems engineering is like peeling an onion Outer Layers System description more abstract and contains low level details Inner Layers System description less abstract and contains more design requirements and elements A Mental Model for Systems Engineering Systems engineering is like peeling an onion. There are less details on the outer layers, where the system description is more abstract and contains low level details. As we penetrate into the inner layers, the system description is less abstract and contains more design requirements and elements. California State University, Northridge

What Systems Engineers Do
Introduction to Systems Engineering MSE607B Systems Engineering - Prof. David Shternberg What Systems Engineers Do Key Foundations Systems Design Systems Analysis Tools and Methods Project Management High Level Design Planning, Modeling Quality and Statistical Analysis Decision/Risk Analysis Simulation, Testing Configuration Mgmt Six Sigma, DFSS What Systems Engineers Do? Systems engineers need to have solid background or key foundations and knowledge in systems design and analysis. They need to posses knowledge in the tools and methods listed in order to be able to understand the phases of system development and effectively communicate with the individuals who work on them. DFSS means Design for Six Sigma. DFSS is used to design or re-design a product or service from the ground up. California State University, Northridge

Systems Engineering Process
Introduction to Systems Engineering MSE607B Systems Engineering - Prof. David Shternberg Systems Engineering Process Systems Approach Problem Definition (planning) Analytical Solution (design) Verification (operations) Systems Engineering Process The system engineering approach is an iterative process, whereby system concepts and objectives are established, potential solutions are developed and evaluated, new solutions are identified, and system objectives are redefined. Through each iteration, the level of detail in the design and analysis of the system is increased. This iterative process continues throughout the entire life cycle of the system (problem definition, analytical solution, mechanization, and verification) with most of the iterations occurring during the planning and design phase of the system. Mechanization (construction) California State University, Northridge

Expertise on the Systems Team
Introduction to Systems Engineering MSE607B Systems Engineering - Prof. David Shternberg Expertise on the Systems Team Management SE Process Domain/ Stakeholders Technology (Engineering Disciplines) Modeling, Simulation, Analysis Expertise on the Systems Team Systems engineering integrates the various functions to allow for project management, modeling and simulation, utilization of available technology, and customer/stakeholder input. California State University, Northridge

MSE607B Systems Engineering - Prof. David Shternberg Key Terminology Life Cycle Requirements Functional vs. Physical Qualification - Verification/Validation The ‘Ilities’ Risk Key Terminology To better understand systems engineering, we need to discuss some key terminology associated with it. Life Cycle, Requirements, Functional (What) vs. Physical (How), Qualification - Verification/Validation, The ‘Ilities’, and Risk California State University, Northridge

MSE607B Systems Engineering - Prof. David Shternberg System Life Cycle Includes entire spectrum of activity Identification of need through system design and development Production and/or construction Operational use Sustaining maintenance and support System retirement Material disposal System Life Cycle The life cycle includes the entire spectrum of activity for a specific system, from the identification of need through system design and development, production and/or construction, operational use and sustaining maintenance and support, and system retirement and material disposal. California State University, Northridge

System Life Cycle Stages
Introduction to Systems Engineering MSE607B Systems Engineering - Prof. David Shternberg System Life Cycle Stages Development Manufacturing Deployment Training Operations, maintenance, support Refinement Retirement System Life Cycle Stages The following are the stages through which most systems undergo from conception to retirement. Development Manufacturing Deployment Training Operations, maintenance, support Refinement Retirement Similar to the cycle of life from birth to death, systems go through stages throughout their life cycle. Automobiles may last 5 to 10 years, while the B-52 bomber, produced more than 50 years ago, is still flying. Autos – 5 to 10 Years B-52 Bomber – 50 Years California State University, Northridge

MSE607B Systems Engineering - Prof. David Shternberg Systems Failures Result from: Incorrect assumptions Oversights Mistakes Example Columbia Space Shuttle Miscalculated seriousness of damage inflicted on isolation panels of orbiter during lift off Systems Failures Systems failures are most often result from incorrect assumptions, oversights, or mistakes in one or more of the life cycle stages. For example, the loss of the Columbia Space Shuttle on re-entry due to miscalculating the seriousness of the damage inflicted on the isolation panels of the orbiter during lift off. California State University, Northridge

Systems Failure Example: Firestone Tires on Ford Explorer
Introduction to Systems Engineering MSE607B Systems Engineering - Prof. David Shternberg Systems Failure Example: Firestone Tires on Ford Explorer Low tire air pressure 175 deaths and 700 injuries 20 million tires replaced Cost of $6 billion Confluence of events in extreme conditions Another example of systems failure is the failure of the Firestone tires installed on Ford Explorer models as a result of low tire air pressure. The failure caused 175 deaths and 700 injuries. In addition, 20 million tires were replaced. The cost of the failure was $6 billion. The failure was said to be “a confluence of events in extreme conditions”. California State University, Northridge

Systems Failure Example: Firestone Tires on Ford Explorer (cont.)
Introduction to Systems Engineering Systems Failure Example: Firestone Tires on Ford Explorer (cont.) MSE607B Systems Engineering - Prof. David Shternberg Failure Factor Design Mfg Operation Service Tread Notch Stress ● Rubber Inflation Specification Tire pressure Temperature Repair of Punctures Years !! Lets evaluate the various factors that contributed to the Ford Explorer failure. Years went by before the problem associated with the tire pressure, temperature and repair of punctures had surfaced. Such elements were addressed early in the design and specification of the tires parameters. The compromise of tire characteristics was discovered only after thousands of tires went into operation and service on board Ford Explorers. The damage inflicted on Ford and Firestone is hard to grasp – reliability costs, reputation, and lost of customers. California State University, Northridge

Systems Engineering Process: “V” Model
Introduction to Systems Engineering MSE607B Systems Engineering - Prof. David Shternberg Systems Engineering Process: “V” Model Development standard for IT systems of Federal Republic of Germany Standardizes activities and products in development of IT systems Guarantees Improvement in quality Curtailment of costs Improved communication between customers and contractors System Process “V” Model V-Model, the development standard for IT systems of the Federal Republic of Germany is being applied in Systems Engineering. The V-Model standardizes all activities and products in the development of systems. This procedure model has been successfully applied for more than 10 years and guarantees constant improvement in quality, curtailment of costs due to standardized procedures and improvement in the communication between customers and contractors California State University, Northridge

Systems Engineering Process: “V” Model (Cont.)
Introduction to Systems Engineering MSE607B Systems Engineering - Prof. David Shternberg Systems Engineering Process: “V” Model (Cont.) Requirements, Documents, Specifications Right System? Models Interfaces Built Right? The V model demonstrates the activities performed during system design. On the upper left side of the V model, systems engineers interact with the stakeholder to understand and develop the system requirements and design documents. These requirements, once defined, will be handed off to the design engineers. On the upper right side of the V model, systems engineers oversee the integration and qualification of the system and its components. The time line shows the progress of development from left to right. Animations: A need for a system is generated. System requirement documents and specifications are created Models are utilized to analyze and simulate the system Interfaces between the system components are defined Decomposition and definition takes place Risks are being analyzed by the various “Ilities” The ilities – Quality, reliability, usability, producibility. Design engineering address how the requirements are being accomplished Integration and qualification is performed by system engineering to ensure that the system was designed right Checks are being made to ensure that the right system was designed Risk, The Ilities Quality Reliability Usability Producibility How California State University, Northridge

Systems Engineering Process: “Waterfall” Model (cont.)
Introduction to Systems Engineering MSE607B Systems Engineering - Prof. David Shternberg Systems Engineering Process: “Waterfall” Model (cont.) Systems Requirements Software Preliminary Design Detailed Coding and Debugging Integration and Testing Operations and Maintenance Software development model Standardized, documented methodology Document system concept Identify and analyze requirements Break the system into pieces Design each piece Code the system components and test individually Integrate the pieces and test the system Deploy the system and operate it Widely used on large government systems Waterfall Model The waterfall model is a software development model used to develop computer software. The term often refers to a standardized, documented methodology for systems development. The standard waterfall model for systems development is an approach that goes through the following steps: Document System Concept Identify System Requirements and Analyze Them Break the System into Pieces (Architectural Design) Design Each Piece (Detailed Design) Code the System Components and Test Them Individually (Coding, Debugging, and Unit Testing) Integrate the Pieces and Test the System (System Testing) Deploy the System and Operate It This model is widely used on large government systems, particularly by the Department of Defense (DOD). California State University, Northridge

MSE607B Systems Engineering - Prof. David Shternberg Systems Engineering Process: “Spiral” Model Spiral Model The Spiral Model explicitly embraces prototyping and an iterative approach to system development. Start by developing a small prototype Followed by a mini-waterfall process, primarily to gather requirements Then, the first prototype is reviewed In subsequent loops, the system engineering team performs further requirements, design, implementation and review The first thing to do before embarking on each new loop is risk analysis Maintenance is simply a type of on-going development. California State University, Northridge

Systems Engineering Process: “Spiral” Model (Cont.)
Introduction to Systems Engineering MSE607B Systems Engineering - Prof. David Shternberg Systems Engineering Process: “Spiral” Model (Cont.) Advantages Estimates (budget and schedule) get more realistic as work progresses. More able to cope with the (nearly inevitable) changes that software development generally entails Disadvantages Estimates (budget and schedule) are harder at the outset The advantages of Spiral Model are that estimates (budget and schedule) get more realistic as work progresses, because the questions have been raised and that it is more able to cope with the (nearly inevitable) changes that software development generally entails. The disadvantages of Spiral Model are that estimates (budget and schedule) are harder at the outset because some of the analysis isn't done until that stage is going through design. California State University, Northridge

MSE607B Systems Engineering - Prof. David Shternberg The Stakeholder Internal or external customer Member of a group who will be involved with the system Users, purchasers, maintainers, administrators Relevant Stakeholder Describes people or roles designated in the plan for stakeholder involvement The Stakeholder The stakeholder may be an internal, or external, customer involved with the system. The stakeholder is a member of a group who will be involved with the system in some way, for example as users, purchasers, maintainers or administrators. The term "relevant stakeholder" is a subset of the term "stakeholder" and describes people or roles that are designated in the plan for stakeholder involvement. Since "stakeholder" may describe a very large number of people, a lot of time and effort would be consumed by attempting to deal with all of them. California State University, Northridge

MSE607B Systems Engineering - Prof. David Shternberg Requirements Key activity in system development Define Needs and wants of the stakeholders What the system must do Condition or capability To solve a problem To satisfy a contract, standard, specification Most complex and crucial part in system development Bridge between application demands and solutions Requirements Requirements definition is a key activity in system development. It is essential for major quality attributes such as system functionality, usability and development costs and time. Requirements define the needs and wants of the stakeholders and define ‘what’ the system must do. Requirement is a condition or capability needed by a user to solve a problem or achieve an objective. Requirement may also be defined as a condition or capability which must be met or possessed by a system (or component) to satisfy a contract, standard, specification or other formally imposed documents. It is perhaps the most complex and crucial part in the development of a system, since it determines in all details the functionality of a system and in so far the costs, duration and the complexity of the development process. Moreover, requirements provide the bridge between the application domain with its demands and goals and the software and hardware solution. California State University, Northridge

MSE607B Systems Engineering - Prof. David Shternberg Requirements (cont.) Four Categories Input/Output Interface between the system and other systems/components Technology/System Wide Technology being used throughout the system and its components Trade Offs Solution options and the selections made Qualification What demonstrates compliance of the system to the requirements There are four categories of requirements: Input/Output describes the interface between the system and other systems, as well as between the system components Technology/System Wide describes the technology being used throughout the system and its components Trade Offs describe the solution options and the selections made Qualification describes what demonstrates compliance of the system to the requirements. Qualification may be a series of tests to demonstrate system functionality and reliability, or may be accomplished by similarity to systems or components already qualified. California State University, Northridge

MSE607B Systems Engineering - Prof. David Shternberg Requirements (cont.) Typical Requirements Analysis Identify source material Identify stakeholder needs Identify initial set of requirements (top-level functional, non-functional, performance and interface requirements) Establish design constraints Define effectiveness measures Capture issues/risks/decisions Typical Requirements Analysis Typical requirements analysis tasks include: Identify source material Identify stakeholder needs Identify initial set of requirements (top-level functional, non-functional, performance and interface requirements) Establish design constraints Define effectiveness measures Capture issues/risks/decisions California State University, Northridge

MSE607B Systems Engineering - Prof. David Shternberg Functional Models Transforms inputs into outputs Describes what happens Problem defined by the requirements analysis in clearer detail Identify and describe the desired functional behavior of each system element or process Typically performed without consideration of a specific design solution Function Models A function transforms inputs into outputs. It also describes “what” happens. The problem is defined by the requirements analysis in clearer detail. Function models also identify and describe the desired functional behavior of each system element or process. They are typically performed without consideration of a specific design solution. California State University, Northridge

MSE607B Systems Engineering - Prof. David Shternberg Functional Analysis Define operational scenarios Derive system behavior model Reflect control and function sequencing, data flow and input/output definition Derive functional and performance requirements Allocate to behavior model Define functional failure modes and effects Functional Analysis Key tasks of the functional analysis phase include: Defining operational scenarios, Deriving system behavior model (and other models as needed) to reflect control and function sequencing, data flow and input/output definition, Deriving functional and performance requirements, and allocate to behavior model, and Defining functional failure modes and effects. California State University, Northridge

MSE607B Systems Engineering - Prof. David Shternberg Interfaces Functions connect to other functions and systems via interfaces Standards of Interfaces Used in commercial applications System failures often occur at an interface Interfaces Functions connect to other functions and systems via interfaces. To ensure compatibility of systems, there are established standards of interfaces used in commercial applications. It is important to note that system failures often occur at an interface. California State University, Northridge

MSE607B Systems Engineering - Prof. David Shternberg Architectures Operational Concept Gives the functionality, connectivity, and structure of the system Used to identify the interfaces Provide the basis for the system integration process Functional Architecture Physical Architecture Operational Architecture Architectures System architecture gives the functionality, connectivity, and structure of the system. The system architecture is used to identify the interfaces and provide the basis for the system integration process. Interface Architecture California State University, Northridge

MSE607B Systems Engineering - Prof. David Shternberg Qualification Demonstrates that system requirements have been met Covers the system requirements System/subsystem specifications Associated interface requirements specifications Verification of a system ensures that: Right system was built right Conformance to the system specifications Validation of a system ensures that: Right system was built Stakeholder acceptance Qualification System qualification testing is performed to demonstrate to the stakeholder that system requirements have been met. It covers the system requirements in the system/subsystem specifications and in associated interface requirements specifications. Verification of a system ensures that the right system was built right. Verification also ensures conformance to the system specifications. Validation of a system ensures that the right system was built. Validation also ensures the stakeholder acceptance California State University, Northridge

MSE607B Systems Engineering - Prof. David Shternberg The “ilities” System design Meets requirements Achieved desired outcomes Reliability Quality Usability Upgradeability Flexibility Manufacturability Availability Serviceability Maintainability Interoperability The ‘Ilities’ The functions listed herein ensure that the system design meets the requirements and achieved the desired outcome. For a system to be useful and effective, it needs to meet the requirements defined by each of these disciplines. Reliability Quality Usability Upgradeability Flexibility Manufacturability Availability Serviceability Maintainability Interoperability California State University, Northridge

MSE607B Systems Engineering - Prof. David Shternberg Reliability Construction of a model that represents the times-to-failure of the entire system Based on the life distributions of the components from which it is composed Example Expressed in terms of means hours between failure System Reliability is 500 hrs Mean Time Between Failure (MTBF) If MTBF changes to 300 hrs, then: More spare parts needed More service people needed More service tools and space needed Reliability The main objective of system reliability is the construction of a model that represents the times-to-failure of the entire system based on the life distributions of the components from which it is composed. For example, system reliability may be expressed in terms of means hours between failure. System reliability is 500 hrs Mean Time Between Failure (MTBF). If the mean time between failures is changed to 300 hours, that would mean that more spare parts are needed, more service people are needed, and more service tools and space are needed. California State University, Northridge

MSE607B Systems Engineering - Prof. David Shternberg Risk Analysis Analyzing and quantifying risk in: Technology Experience, Knowledge base Project Schedule Project Budget Undesirable events are identified and then analyzed separately For each undesirable event, possible improvements are formulated Risk Analysis Analyzing and quantifying risk in technology, experience and knowledge base, project schedule, and project budget which could transform a potential hazard into an accident or failure of a system or its components. The possible undesirable events are identified first and then analyzed separately. For each undesirable events or hazards, possible improvements, or preventive measures are then formulated. California State University, Northridge

MSE607B Systems Engineering - Prof. David Shternberg Summary Importance of systems engineering in engineering practice Subject of “systems” in general Origins of systems engineering Summary In this module, the following topics were covered: The importance of systems engineering in engineering practice, The subject of “systems” in general, and The origins of systems engineering California State University, Northridge

MSE607B Systems Engineering - Prof. David Shternberg Interactive Workshop A system is a: Group of dependent but related elements comprising a unified whole Group of independent but interrelated elements comprising a unified whole Group of elements Group of components California State University, Northridge

MSE607B Systems Engineering - Prof. David Shternberg Interactive Workshop “Systems Engineering” is: The process of defining, developing and integrating quality systems. The process of defining and developing quality systems. The application of engineering to solutions of a complete problem The set of activities controlling overall design and integration of interacting components to meet the needs of stakeholders. California State University, Northridge

MSE607B Systems Engineering - Prof. David Shternberg Interactive Workshop Systems engineering requirements: Stems from the Greek word requēma Last activity in system development Define the needs and wants of the stakeholders Define the needs and wants of the engineers California State University, Northridge

MSE607B Systems Engineering - Prof. David Shternberg Interactive Workshop A “life cycle” is the entire spectrum of activity: From system design and development through retirement and material disposal. From system operations through retirement and material disposal. From system design through operation and material disposal. From system development through material disposal. California State University, Northridge

MSE607B Systems Engineering - Prof. David Shternberg Interactive Workshop A “stakeholder” is a: A person or group who studies systems A member of a group involved with the system in some way A member of a group involved with Engineers in some way None of the above California State University, Northridge

MSE607B Systems Engineering - Prof. David Shternberg Homework Assignment Page 44 problems 2 3 4 9 Use homework format provided in course website Read Chapter 2 Pages California State University, Northridge

Questions? Comments?

Module 1 Introduction to Systems Engineering

Similar presentations

Presentation on theme: "Module 1 Introduction to Systems Engineering"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Module 1 Introduction to Systems Engineering

Similar presentations

Presentation on theme: "Module 1 Introduction to Systems Engineering"— Presentation transcript:

Similar presentations

About project

Feedback