Edit Game
SE - Midterm
 Delete

Use commas to add multiple tags

 Private  Unlisted  Public



 Save

Delimiter between question and answer:

Tips:

  • No column headers.
  • Each line maps to a question.
  • If the delimiter is used in a question, the question should be surrounded by double quotes: "My, question","My, answer"
  • The first answer in the multiple choice question must be the correct answer.

 Import questions





 Save   61  Close
Recalculation of Severity, Occurrence and Detection rankings after implementation of recommended actions and thus calculation of revised RPN. Revised RPN=revised (SeverityĂ— Occurrence Ă— Detection)
Revised RPN
Brief descriptions of the action taken to be entered after actual actions are taken by the team.
Actions Taken
Dates Individual or group responsible for the recommended actions and target completion date to be entered.
Responsibilities and Completion
Beginning with high RPN and working in descending order The objective is to reduce one or more of the criteria that make up the RPN. Typical actions are design of experiments, revised test plans, revised material specifications, revised de
Recommended Actions
the indicator for the determining proper corrective action on the failure modes
Risk Priority Number (RPN)
Relative measures of the ability of design control to detect wither a potential cause/mechanism or the subsequent failure mode before production. Supported by physical tests, mathematical modeling, prototype testing, feasibility reviews et
Detection
control activities generally include Prevention Measures, Design Validation, and Design Verification Supported by physical tests, mathematical modeling, prototype testing, and feasibility reviews etc.
Current Design Control
the chance that one of the specific cause/mechanism will occur. In this step, it is necessary to look at the cause of a failure and how many times it occurs. Looking at similar products or processes and the failures that have been documente
Occurence
Every cause/mechanism must be listed concisely E.g. of Failure Causes are inadequate design, incorrect material, inaccurate life assumption, poor environmental protection, over stressing, insufficient lubrication etc. E.g. of Failure Mecha
Potential Cause, Mechanism of Failure
the assessment of the seriousness of the effect of the potential failure mode. In this we have to determine all failure modes based on the functional requirements and their effects. An example table of severity is given below.
Severity
As perceived by the customer (internal/end user). For e.g. erratic operation, poor appearance, noise, impaired functions, deterioration etc.
Potential Effects of Failure
Considering past failures, present reports, brainstorming. • Describe in technical terms and not as customers will see. • For e.g. cracked, deformed, loosened, short circuited, fractured, leaking, sticking, oxidized etc.
Potential Failure Mode
an analytical technique (a paper test) that combines technology and experience of people in identifying probable failure mode of product or process and planning for its abolition. FMEA is a “before-the event” action requiring a team effort
FMEA
Failures are prioritized according to how serious their consequences are, how frequently they occur, and how easily they can be detected. The purpose of the ____ is to take actions to eliminate or reduce failures, starting with the highest-
FMEA (Failure Mode and Effect Analysis
efers to studying the consequences of those failures.
Effect Analysis
means the ways, or modes, in which something might fail. Failures are any errors or defects, especially ones that affect the customer, and can be potential or actual.
Failure Modes
Iterate risk assessments throughout the project lifecycle to adapt to new information and maintain project control.
Continuous Improvement
Assess risks by severity and likelihood to focus on the most critical threats.
Quantify and Prioritize
Develop targeted actions for high-priority risks, leveraging early analysis to avoid costly redesigns.
Mitigation Strategies
Use FMEA and decision trees to systematically uncover potential failures and uncertainties in system design.
Identify Risks
used in the web development domain. It consists of three sequential phases. First, a basic prototype with all the existing pages is presented in the HTML format. Then the data processing is simulated using a prototype services layer.
Extreme Prototyping
refers to building multiple functional prototypes of the various sub-systems and then integrating all the available prototypes to form a complete system. can be like “building blocks”
Incremental Approach
also called as breadboard prototyping is based on building actual functional prototypes with minimal functionality in the beginning. The prototype developed forms the heart of the future prototypes on top of which the entire system is built
Evolutionary prototyping
also called as rapid or close ended prototyping. This type of prototyping uses very little efforts with minimum requirement analysis to build a prototype. Once the actual requirements are understood, the prototype is discarded.
Throwaway/Rapid Prototyping
a systems development method (SDM) in which a prototype (an early approximation of a final system or product) is built, tested, and then reworked as necessary until an acceptable prototype is finally achieved from which the complete system
Prototyping Model
The product may first be released in a limited segment and tested in the real business environment (UAT- User acceptance testing). Then based on the feedback, the product may be released as it is or with suggested enhancements in the target
Stage 5: Testing the ProductStage 6: Deployment in the Market Maintenance
his stage refers to the ________only stage of the product where product defects are reported, tracked, fixed and retested, until the product reaches the quality standards defined in the SRS
Stage 5: Testing the Product
This stage is usually a subset of all the stages as in the modern SDLC models, the _____ activities are mostly involved in all the stages of SDLC.
Stage 5: Testing the Product
Developers must follow the coding guidelines defined by their organization and programming tools like compilers, interpreters, debuggers, etc. are used to generate the code
Stage 4: Building or Developing the Product
In this stage of SDLC the actual development starts and the product is built. The programming code is generated as per DDS during this stage. If the design is performed in a detailed and organized manner, code generation can be accomplished
Stage 4: Building or Developing the Product
A design approach clearly defines all the architectural modules of the product along with its communication and data flow representation with the external and third party modules (if any). The internal design of all the modules of the propo
Stage 3: Designing the Product Architecture
This DDS is reviewed by all the important stakeholders and based on various parameters as risk assessment, product robustness, design modularity, budget and time constraints, the best design approach is selected for the product.
Stage 3: Designing the Product Architecture
SRS is the reference for product architects to come out with the best architecture for the product to be developed. Based on the requirements specified in SRS, usually more than one design approach for the product architecture is proposed.
Stage 3: Designing the Product Architecture
Planning for the quality assurance requirements and identification of the risks associated with the project is also done in the planning stage.
Stage 2: Defining Requirements
Once the requirement analysis is done the next step is to clearly define and document the product requirements and get them approved from the customer or the market analysts. This is done through an SRS (Software Requirement Specification)
Stage 2: Defining Requirements
the most important and fundamental stage in SDLC. It is performed by the senior members of the team with inputs from the customer, the sales department, market surveys and domain experts in the industry. This information is then used to pla
Stage 1: Planning and Requirement Analysis
a process followed for a software project, within a software organization. It consists of a detailed plan describing how to develop, maintain, replace and alter or enhance specific software. The life cycle defines a methodology for improvin
SDLC
an international standard for software life-cycle processes. It aims to be the standard that defines all the tasks required for developing and maintaining software.
ISO/IEC 12207
Also called as Software Development Process. A a framework defining tasks performed at each step in the software development process.
Software Development Life Cycle
a process used by the software industry to design, develop and test high quality software. aims to produce a high-quality software/system that meets or exceeds customer expectations, reaches completion within times and cost estimates.
Software Development Life Cycle (SDLC)
reduction in post-deployment failures using enhanced verification: simulations, SIL/HIL, prototype testing, and formal methods
50%
Provides quantitative evaluation of design choices. Ranks alternatives across multiple criteria to support decision-making.
Analytic Hierarchy Process (AHP)
Facilitates scenario testing and prediction of system behavior. Supports risk assessment and optimization of design alternatives.
Simulation Modeling
Uses formalized modeling to manage complexity. Enables abstraction, improves communication, and can cut development time by up to 30%.
Model Based System Engineering
Cross-domain analysis reduces failure modes and strengthens end-to-end performance.
System Robustness
Monitor with minimal effort; keep informed as needed.
Low Influence, Low Interest
Supporters who need regular updates and opportunities for input.
Low Influence, High interest
Stakeholders with power but less engagement; keep satisfied and informed.
High Influence, Low Interest
Key decision-makers who must be closely managed and involved in requirements definition.
High Influence, High Interest
Test and verify requirements and performance targets are met.
Validation
Specify all components, interfaces, and implementation details.
Detailed Designs
Outline components, interfaces, and initial technical solutions.
Preliminary Designs
Form high-level concepts, architecture, and key functions.
Conceptual Design
Gather needs, constraints, and objectives with stakeholders.
Requirement Analysis
Facilitates updates, fixes, and improvements with minimal disruption to overall system operation.
Maintainability
Ensures the system can handle increasing demand and adapt to growth without major redesigns.
Scalability
Designs for resilience, allowing systems to function reliably under stress or unexpected conditions.
Robustness
Enables parallel development and simplifies maintenance by dividing systems into interchangeable components.
Modularity
Reduces development risks and downstream costs while aligning solutions to stakeholder needs.
Practical Benefits if Systems Design
It Enables structured, integrated development that optimizes performance, cost, and reliability.
Systems Design
It Defines architecture, components, modules, interfaces, and data to meet requirements.
Systems Design
Your experience on this site will be improved by allowing cookies.