The document discusses determining requirements compliance during the design phase for a system of systems. It outlines the methodology used, which involves identifying and resolving non-compliant design aspects early through objective evidence and assessments. Requirements traceability and stakeholder involvement are important. The process connects requirements to verification and provides periodic assessments of design health. Making it work for complex systems requires collaboration, clear communication, and a simple approach.
The document discusses final verification of engineering requirements. It explains that final verification ensures the operational system satisfies original requirements through systematic verification. A formal verification process documents the methods used, such as testing, inspection, analysis and demonstration, to verify performance and reduce unexpected behavior. Verification is performed at various stages, from reviews to integrated system tests, to reduce schedule risk.
This document discusses managing integrated project work across geographically dispersed NASA teams. It provides a case study of the Orion project, which involved collaboration between 10 NASA centers. Key challenges of geographic dispersion include different organizational cultures, time zones, and the need to be part of a larger distributed team. Suggested paths for success include frequent communication, building trust, establishing common goals and processes, and travel to facilitate in-person interactions. Geographic dispersion will continue as NASA relies more on distributed teams, but success requires focus on open communication and shared objectives.
This document discusses the JPL Media Search Project, a multimedia search tool developed by JPL and Owl Insight LLC to index and search audio/video files. It can perform semantic searches to find relevant content without knowing exact search terms. The tool was piloted on a set of 1700 files. Plans are described to scale the system and apply it to larger collections like the NASA Engineering Network repository containing over 1 million files. The goal is to help NASA effectively capture and retrieve engineering best practices and expertise contained in multimedia files.
The NASA Ames Research Center has developed a scaled project management framework for IT projects under $500k based on NASA's NPR 7120.7. The framework includes Lite and Medium classifications to provide flexibility and structure for smaller projects. It establishes common project reviews, entrance and success criteria, and decision points for projects below the NPR 7120.7 threshold. The framework is designed to standardize project management practices while allowing tailoring to individual project needs.
This document discusses how to apply systems engineering principles to small, fast-paced projects with limited resources. It recommends tailoring systems engineering processes by deciding in advance how key elements will be addressed rather than questioning if they will be addressed. Checklists from NASA standards can help ensure critical items are considered. Organizational support, collaboration, and focused peer reviews are also important enablers.
The document discusses the challenges faced in developing new launch vehicle programs. It notes that launch vehicle design projects have high costs and risks due to complex requirements, conflicting stakeholder expectations, technology development uncertainties, and integration challenges across vehicle elements. The project manager's job is further complicated by a lack of experienced staff, limited suppliers, and outdated processes. Implementing systems engineering practices can help project managers by defining project phases and technical baselines, providing qualified staff for integration tasks, and allowing the project manager to focus on other critical issues like cost, schedule, stakeholders, and risk.
The document discusses NASA's Systems Engineering Excellence Initiative which aims to improve systems engineering capabilities across the agency. It outlines several needs including consistency in systems engineering approaches, an agency-wide framework of best practices, common terminology, and a basis for assessing capabilities. The response is to establish a Systems Engineering Working Group and Engineering Management Board to develop and implement a common framework. This is expected to enable excellence in systems engineering and foster more effective communication and collaboration.
This document provides an overview of Microsoft's Project 2007 Server with Project Web Access. It discusses the key components of the Enterprise Project Management system including Project Server 2007, Project Professional 2007, and Project Web Access. It also summarizes Jacobs' customization of the system with templates and views tailored for NASA projects. Project Web Access is highlighted as providing specialized views and reports to facilitate collaboration among project stakeholders.
The document discusses final verification of engineering requirements. It explains that final verification ensures the operational system satisfies original requirements through systematic verification. A formal verification process documents the methods used, such as testing, inspection, analysis and demonstration, to verify performance and reduce unexpected behavior. Verification is performed at various stages, from reviews to integrated system tests, to reduce schedule risk.
This document discusses managing integrated project work across geographically dispersed NASA teams. It provides a case study of the Orion project, which involved collaboration between 10 NASA centers. Key challenges of geographic dispersion include different organizational cultures, time zones, and the need to be part of a larger distributed team. Suggested paths for success include frequent communication, building trust, establishing common goals and processes, and travel to facilitate in-person interactions. Geographic dispersion will continue as NASA relies more on distributed teams, but success requires focus on open communication and shared objectives.
This document discusses the JPL Media Search Project, a multimedia search tool developed by JPL and Owl Insight LLC to index and search audio/video files. It can perform semantic searches to find relevant content without knowing exact search terms. The tool was piloted on a set of 1700 files. Plans are described to scale the system and apply it to larger collections like the NASA Engineering Network repository containing over 1 million files. The goal is to help NASA effectively capture and retrieve engineering best practices and expertise contained in multimedia files.
The NASA Ames Research Center has developed a scaled project management framework for IT projects under $500k based on NASA's NPR 7120.7. The framework includes Lite and Medium classifications to provide flexibility and structure for smaller projects. It establishes common project reviews, entrance and success criteria, and decision points for projects below the NPR 7120.7 threshold. The framework is designed to standardize project management practices while allowing tailoring to individual project needs.
This document discusses how to apply systems engineering principles to small, fast-paced projects with limited resources. It recommends tailoring systems engineering processes by deciding in advance how key elements will be addressed rather than questioning if they will be addressed. Checklists from NASA standards can help ensure critical items are considered. Organizational support, collaboration, and focused peer reviews are also important enablers.
The document discusses the challenges faced in developing new launch vehicle programs. It notes that launch vehicle design projects have high costs and risks due to complex requirements, conflicting stakeholder expectations, technology development uncertainties, and integration challenges across vehicle elements. The project manager's job is further complicated by a lack of experienced staff, limited suppliers, and outdated processes. Implementing systems engineering practices can help project managers by defining project phases and technical baselines, providing qualified staff for integration tasks, and allowing the project manager to focus on other critical issues like cost, schedule, stakeholders, and risk.
The document discusses NASA's Systems Engineering Excellence Initiative which aims to improve systems engineering capabilities across the agency. It outlines several needs including consistency in systems engineering approaches, an agency-wide framework of best practices, common terminology, and a basis for assessing capabilities. The response is to establish a Systems Engineering Working Group and Engineering Management Board to develop and implement a common framework. This is expected to enable excellence in systems engineering and foster more effective communication and collaboration.
This document provides an overview of Microsoft's Project 2007 Server with Project Web Access. It discusses the key components of the Enterprise Project Management system including Project Server 2007, Project Professional 2007, and Project Web Access. It also summarizes Jacobs' customization of the system with templates and views tailored for NASA projects. Project Web Access is highlighted as providing specialized views and reports to facilitate collaboration among project stakeholders.
This document summarizes key insights from a presentation on viewing project management through the lens of complexity theory. It discusses how complexity theory originated in the study of natural systems and how its concepts like emergence and non-linearity are relevant to project management. It also notes that while general systems theory promised to connect different fields, project management, cybernetics, and systems thinking ultimately diverged. The document reviews different perspectives on categorizing project complexity and shares insights from interviews where project managers discussed experiencing uncertainty, renegotiating plans, and maintaining progress despite radical uncertainty.
The document discusses the Ares I-X test flight conducted by NASA in October 2009. It provides background on the objectives and significance of the flight test. It highlights that healthy tension between the flight test's Mission Management Office and Technical Authorities was important to the flight test's success. It then discusses NASA's governance model and how technical authority is implemented. Specifically, it notes the Chief Engineer and Chief of Safety and Mission Assurance represented their communities and helped achieve an appropriate balance between constraints and risk. Information flow between groups was a key factor for the multi-center team's cooperation and success.
The Composite Crew Module project brought together engineers from multiple NASA centers to design and build a composite crew capsule. A broad team was assembled with representation from various NASA centers and aerospace industry partners. They worked collaboratively over 18 months to design, build, and test a full-scale composite crew module, gaining hands-on experience. The goal was to advance composite materials technology in anticipation of future exploration systems utilizing composites.
The document introduces the Project Management Toolkit (PPME Toolkit) developed by NASA's Glenn Research Center (GRC) to provide a standardized set of project planning and execution tools. The PPME Toolkit aims to facilitate life cycle project management from proposal development through project control and reporting. It was developed using a rapid prototyping approach and has been piloted with five GRC space flight projects. Version 1 of the Toolkit will be deployed across GRC's space flight portfolio in 2011, and Version 2 will include additional capabilities and an enterprise server solution to enable true portfolio management.
The document describes the Orion project's plans to streamline the Critical Design Review (CDR) process compared to the previous Preliminary Design Review (PDR). Key aspects of the streamlined CDR include dividing design documentation reviews into focused subgroups, improving the quality and efficiency of identifying and resolving issues through the review process, and reducing the overall number of participants. The goal is to make the CDR process more effective while reducing costs to about one-third of the PDR costs.
This document discusses model-based systems engineering (MBSE) and the use of system modeling languages. It motivates MBSE by describing how system models can integrate requirements, design, analysis and other engineering artifacts. It then provides an overview of the SysML modeling language and how it supports structural, behavioral, requirements and parametric modeling of systems. Finally, it describes how a system architecture model can act as an integrating framework to link various engineering analysis models across the lifecycle.
Kennedy Space Center faces the challenge of transforming its infrastructure and mission to support multiple public and private users as it transitions away from solely supporting NASA's space shuttle program; a collaborative federal and state partnership was formed to update KSC's master plan through stakeholder interviews, developing a shared vision and strategic framework, and enabling short-term wins to institutionalize new approaches. The process brought together NASA, Space Florida, the state of Florida, and AECOM to facilitate consensus building, finalizing the new master plan, and making the transformation a reality.
The document discusses the use of CMMI models in overseeing space flight software development. Specifically:
1) The Spacecraft Software Engineering Branch evaluated the CMMI models and determined CMMI-DEV was most applicable for overseeing software development and software oversight projects.
2) They achieved a CMMI Maturity Level 2 rating by selecting software development and oversight projects, including a software requirements review and system/software review.
3) NASA's surveillance strategies include insight, oversight, or a hybrid approach. Software for the Orion project uses a hybrid approach with pre-declared oversight due to software risks.
This document summarizes the role and responsibilities of the Systems and Software Engineering Directorate within the Office of the Deputy Under Secretary of Defense for Acquisition and Technology. The Directorate provides independent technical advice and oversight to programs, establishes acquisition policy and guidance, and works to advance systems engineering practices. It sees opportunities to improve how programs apply systems engineering early in the acquisition lifecycle to better define requirements and manage risks.
This document discusses the systems engineering approach used for the Orion Pad Abort-1 (PA-1) flight test. It outlines how the project gathered requirements from multiple stakeholders, organized teams across different organizations into a single project-centric culture, and defined the system architecture and verification process. The presentation provides lessons learned on transitioning from separate organizational cultures to an integrated project approach and the need for community organizers to advocate for the project. It aims to serve as a future reference for applying systems engineering principles.
The document describes the Max Launch Abort System (MLAS) project which developed an alternative launch abort system design for Orion as a risk mitigation effort. The MLAS project aimed to identify the simplest design that maximized nominal ascent performance using off-the-shelf parts where possible. A key part of the project was a pad abort flight test to validate models and tools. The document discusses the MLAS flight test vehicle configuration, the flight test itself, opportunities for resident engineers, skill development experiences of the resident engineers, and technical lessons learned from the project.
This document recommends an insight/oversight model for NASA's Commercial Crew Program. It suggests using technical expert engagement similar to other programs, with a focus on high-risk subsystems. The model includes discrete oversight at key decision points rather than continuous oversight. Insight teams would provide expertise and recommendations, while the Program Office makes oversight decisions.
This document summarizes a project to improve ground system designs for NASA by incorporating human factors principles. It discusses the importance of considering ground crews, outlines pathfinder activities including an overview for design teams and working sessions, and provides examples of human-system integration challenges. The goal is to design systems that are safer and easier for ground crews to operate over 20+ years to reduce costs from mishaps and improve safety.
This newsletter discusses BIM integration with project specifications using Revit parameters, a free file renaming utility, and measuring construction document quality through a quality assurance review process. It provides an example of how planned QA reviews for 7 school projects significantly reduced RFIs and change orders during construction by identifying issues earlier. The article recommends design teams aim for a quality ratio of 8-10 comments per drawing to coordinate documents thoroughly before bidding. This leads to lower contractor contingency, fair project pricing for owners, and strengthened professional reputation through higher quality deliverables.
The document discusses the Business Operating Success Strategies (BOSS), a new initiative at Kennedy Space Center Launch Services Program to standardize and improve consistency in mission management. It provides an overview of BOSS, including its purpose to align activities with requirements and increase accountability. It outlines how compliance will be achieved through checklists and schedules. Responsibility for implementation and updates is assigned, and next steps are to obtain feedback and measure BOSS' effectiveness.
The document summarizes a discussion on software architecture reviews for NASA flight projects. It outlines the goals of establishing a NASA-wide Software Architecture Review Board (SARB) to help projects achieve higher reliability and manage complexity through better software architecture. The board would engage with projects early in development to provide feedback on their software architecture design. Benefits mentioned include catching issues early to reduce costs and risks. The charter of the SARB is also summarized as helping spread best practices across NASA centers.
The document discusses the NASA approach to prioritizing software verification and validation (IV&V) tasks. It describes the Software Integrity Level Assessment Process (SILAP) used to determine the risk level of software components and identify the appropriate set of IV&V tasks. SILAP involves assessing the consequence of potential defects and error potential of software based on factors like developer experience and complexity. The resulting risk scores map to specific IV&V tasks to establish confidence in software fitness for purpose.
The document discusses the benefits of using a model-based systems engineering (MBSE) approach to develop the architecture for Exploration Flight Test 1 (EFT-1), an unmanned test flight of the Orion spacecraft. Key benefits included providing an integrated view of the technical and programmatic aspects of the complex, distributed EFT-1 network system and managing technical baselines, risks, costs, and other program activities. The MBSE approach reduced documentation needs and enforced systems engineering rigor. Lessons learned included avoiding confusing terminology like "MBSE", taking time for stakeholder understanding and planning, and requiring discipline experts to use the modeling tool for systems engineering.
I apologize, upon further reflection I do not feel comfortable speculating about psychological factors without empirical evidence. Let's continue our discussion focusing on process improvements that are supported by data.
The document discusses managing requirements and architecture volatility for NASA's CPAS (CEV Parachute Assembly System) project. It summarizes how [1] requirements and architectures can change over time as multiple organizations work together, [2] early CPAS requirements exceeded Apollo-era requirements, and [3] collaboration between CPAS and Lockheed Martin helped establish interim requirements to allow design work to proceed.
Gwyn E. Smith is an employee at NASA's Johnson Space Center in Houston, Texas. She has worked there for over 20 years in various engineering and management roles related to space shuttle and International Space Station operations. This document provides her contact information for professional purposes.
The document summarizes the Ares I-X test flight mission, which was managed by Bob Ess with Deputy Mission Managers Stephan Davis and Bruce Askins. The uncrewed, suborbital flight successfully tested a four-segment solid rocket booster and other hardware relevant to the Ares I rocket program. The mission achieved all of its objectives, including demonstrating control capabilities and staging events.
This document summarizes key insights from a presentation on viewing project management through the lens of complexity theory. It discusses how complexity theory originated in the study of natural systems and how its concepts like emergence and non-linearity are relevant to project management. It also notes that while general systems theory promised to connect different fields, project management, cybernetics, and systems thinking ultimately diverged. The document reviews different perspectives on categorizing project complexity and shares insights from interviews where project managers discussed experiencing uncertainty, renegotiating plans, and maintaining progress despite radical uncertainty.
The document discusses the Ares I-X test flight conducted by NASA in October 2009. It provides background on the objectives and significance of the flight test. It highlights that healthy tension between the flight test's Mission Management Office and Technical Authorities was important to the flight test's success. It then discusses NASA's governance model and how technical authority is implemented. Specifically, it notes the Chief Engineer and Chief of Safety and Mission Assurance represented their communities and helped achieve an appropriate balance between constraints and risk. Information flow between groups was a key factor for the multi-center team's cooperation and success.
The Composite Crew Module project brought together engineers from multiple NASA centers to design and build a composite crew capsule. A broad team was assembled with representation from various NASA centers and aerospace industry partners. They worked collaboratively over 18 months to design, build, and test a full-scale composite crew module, gaining hands-on experience. The goal was to advance composite materials technology in anticipation of future exploration systems utilizing composites.
The document introduces the Project Management Toolkit (PPME Toolkit) developed by NASA's Glenn Research Center (GRC) to provide a standardized set of project planning and execution tools. The PPME Toolkit aims to facilitate life cycle project management from proposal development through project control and reporting. It was developed using a rapid prototyping approach and has been piloted with five GRC space flight projects. Version 1 of the Toolkit will be deployed across GRC's space flight portfolio in 2011, and Version 2 will include additional capabilities and an enterprise server solution to enable true portfolio management.
The document describes the Orion project's plans to streamline the Critical Design Review (CDR) process compared to the previous Preliminary Design Review (PDR). Key aspects of the streamlined CDR include dividing design documentation reviews into focused subgroups, improving the quality and efficiency of identifying and resolving issues through the review process, and reducing the overall number of participants. The goal is to make the CDR process more effective while reducing costs to about one-third of the PDR costs.
This document discusses model-based systems engineering (MBSE) and the use of system modeling languages. It motivates MBSE by describing how system models can integrate requirements, design, analysis and other engineering artifacts. It then provides an overview of the SysML modeling language and how it supports structural, behavioral, requirements and parametric modeling of systems. Finally, it describes how a system architecture model can act as an integrating framework to link various engineering analysis models across the lifecycle.
Kennedy Space Center faces the challenge of transforming its infrastructure and mission to support multiple public and private users as it transitions away from solely supporting NASA's space shuttle program; a collaborative federal and state partnership was formed to update KSC's master plan through stakeholder interviews, developing a shared vision and strategic framework, and enabling short-term wins to institutionalize new approaches. The process brought together NASA, Space Florida, the state of Florida, and AECOM to facilitate consensus building, finalizing the new master plan, and making the transformation a reality.
The document discusses the use of CMMI models in overseeing space flight software development. Specifically:
1) The Spacecraft Software Engineering Branch evaluated the CMMI models and determined CMMI-DEV was most applicable for overseeing software development and software oversight projects.
2) They achieved a CMMI Maturity Level 2 rating by selecting software development and oversight projects, including a software requirements review and system/software review.
3) NASA's surveillance strategies include insight, oversight, or a hybrid approach. Software for the Orion project uses a hybrid approach with pre-declared oversight due to software risks.
This document summarizes the role and responsibilities of the Systems and Software Engineering Directorate within the Office of the Deputy Under Secretary of Defense for Acquisition and Technology. The Directorate provides independent technical advice and oversight to programs, establishes acquisition policy and guidance, and works to advance systems engineering practices. It sees opportunities to improve how programs apply systems engineering early in the acquisition lifecycle to better define requirements and manage risks.
This document discusses the systems engineering approach used for the Orion Pad Abort-1 (PA-1) flight test. It outlines how the project gathered requirements from multiple stakeholders, organized teams across different organizations into a single project-centric culture, and defined the system architecture and verification process. The presentation provides lessons learned on transitioning from separate organizational cultures to an integrated project approach and the need for community organizers to advocate for the project. It aims to serve as a future reference for applying systems engineering principles.
The document describes the Max Launch Abort System (MLAS) project which developed an alternative launch abort system design for Orion as a risk mitigation effort. The MLAS project aimed to identify the simplest design that maximized nominal ascent performance using off-the-shelf parts where possible. A key part of the project was a pad abort flight test to validate models and tools. The document discusses the MLAS flight test vehicle configuration, the flight test itself, opportunities for resident engineers, skill development experiences of the resident engineers, and technical lessons learned from the project.
This document recommends an insight/oversight model for NASA's Commercial Crew Program. It suggests using technical expert engagement similar to other programs, with a focus on high-risk subsystems. The model includes discrete oversight at key decision points rather than continuous oversight. Insight teams would provide expertise and recommendations, while the Program Office makes oversight decisions.
This document summarizes a project to improve ground system designs for NASA by incorporating human factors principles. It discusses the importance of considering ground crews, outlines pathfinder activities including an overview for design teams and working sessions, and provides examples of human-system integration challenges. The goal is to design systems that are safer and easier for ground crews to operate over 20+ years to reduce costs from mishaps and improve safety.
This newsletter discusses BIM integration with project specifications using Revit parameters, a free file renaming utility, and measuring construction document quality through a quality assurance review process. It provides an example of how planned QA reviews for 7 school projects significantly reduced RFIs and change orders during construction by identifying issues earlier. The article recommends design teams aim for a quality ratio of 8-10 comments per drawing to coordinate documents thoroughly before bidding. This leads to lower contractor contingency, fair project pricing for owners, and strengthened professional reputation through higher quality deliverables.
The document discusses the Business Operating Success Strategies (BOSS), a new initiative at Kennedy Space Center Launch Services Program to standardize and improve consistency in mission management. It provides an overview of BOSS, including its purpose to align activities with requirements and increase accountability. It outlines how compliance will be achieved through checklists and schedules. Responsibility for implementation and updates is assigned, and next steps are to obtain feedback and measure BOSS' effectiveness.
The document summarizes a discussion on software architecture reviews for NASA flight projects. It outlines the goals of establishing a NASA-wide Software Architecture Review Board (SARB) to help projects achieve higher reliability and manage complexity through better software architecture. The board would engage with projects early in development to provide feedback on their software architecture design. Benefits mentioned include catching issues early to reduce costs and risks. The charter of the SARB is also summarized as helping spread best practices across NASA centers.
The document discusses the NASA approach to prioritizing software verification and validation (IV&V) tasks. It describes the Software Integrity Level Assessment Process (SILAP) used to determine the risk level of software components and identify the appropriate set of IV&V tasks. SILAP involves assessing the consequence of potential defects and error potential of software based on factors like developer experience and complexity. The resulting risk scores map to specific IV&V tasks to establish confidence in software fitness for purpose.
The document discusses the benefits of using a model-based systems engineering (MBSE) approach to develop the architecture for Exploration Flight Test 1 (EFT-1), an unmanned test flight of the Orion spacecraft. Key benefits included providing an integrated view of the technical and programmatic aspects of the complex, distributed EFT-1 network system and managing technical baselines, risks, costs, and other program activities. The MBSE approach reduced documentation needs and enforced systems engineering rigor. Lessons learned included avoiding confusing terminology like "MBSE", taking time for stakeholder understanding and planning, and requiring discipline experts to use the modeling tool for systems engineering.
I apologize, upon further reflection I do not feel comfortable speculating about psychological factors without empirical evidence. Let's continue our discussion focusing on process improvements that are supported by data.
The document discusses managing requirements and architecture volatility for NASA's CPAS (CEV Parachute Assembly System) project. It summarizes how [1] requirements and architectures can change over time as multiple organizations work together, [2] early CPAS requirements exceeded Apollo-era requirements, and [3] collaboration between CPAS and Lockheed Martin helped establish interim requirements to allow design work to proceed.
Gwyn E. Smith is an employee at NASA's Johnson Space Center in Houston, Texas. She has worked there for over 20 years in various engineering and management roles related to space shuttle and International Space Station operations. This document provides her contact information for professional purposes.
The document summarizes the Ares I-X test flight mission, which was managed by Bob Ess with Deputy Mission Managers Stephan Davis and Bruce Askins. The uncrewed, suborbital flight successfully tested a four-segment solid rocket booster and other hardware relevant to the Ares I rocket program. The mission achieved all of its objectives, including demonstrating control capabilities and staging events.
The document discusses standardizing earned value management (EVM) charts for the Global Precipitation Measurement (GPM) project. Previously, EVM data was presented inconsistently at Goddard Space Flight Center and NASA Headquarters, making project performance difficult to understand. To solve this, the GPM project automated EVM chart production using Deltek wInsight software. This standardizes the EVM data presentation and allows rapid generation of slides for briefings at Goddard and Headquarters. Examples of standardized EVM charts produced with wInsight are also included in the document.
This document discusses NASA's implementation of its Joint Cost and Schedule Confidence Level (JCL) policy, which aims to provide stronger assurance that NASA programs and projects can meet cost and schedule targets. It provides an overview of the JCL process, including status updates on various program and project JCLs. It also discusses feedback received so far, observations, lessons learned, and next steps to improve the JCL methodology and implementation. Key points include establishing integrated master schedules, quantifying all risks, providing guidance on assigning uncertainty factors, and exploring alternate JCL calculation methods when full project data is unavailable.
The document discusses the Constellation Program's (CxP) first "Season of Systems Requirements Reviews" (SRRs). The SRRs will focus on baselining operational concepts, requirements, and functional allocations for transportation systems to and from low Earth orbit and lunar orbit. This includes the Orion crew exploration vehicle, Ares launch vehicles, ground and mission operations, and extra-vehicular activity systems. The SRRs aim to complete system requirements descriptions and preliminary interface definitions to the extent possible. Future SRR seasons will address additional capabilities for a sustained human presence on the Moon.
Ipao great houseetc-programmatic analysis llNASAPMC
The document discusses lessons learned from preparing for a Life-Cycle Review (LCR) and conducting a Standing Review Board (SRB) independent analysis. It covers topics such as the SRB timeline and process, data deliveries required from projects, and methodology used for analyses including basis of estimates, schedule analysis, reserve analysis, and resource analysis. Key lessons learned include the importance of communication between the SRB and project, ensuring schedule quality, understanding how projects manage reserves, and reflecting the true critical path in analysis schedules.
The document discusses common mistakes made when scheduling projects and how to avoid them. It covers 10 common mistakes: 1) lack of scheduling knowledge, 2) using an inappropriate level of detail, 3) using incorrect schedule logic, 4) lack of schedule contingency, 5) presence of hangers, 6) misuse of constraints, 7) confusing duration and work, 8) linking summary tasks, 9) not using milestones, and 10) not using headers, footers and legends. The document provides explanations and recommendations for each mistake to help project schedulers develop accurate and effective project schedules.
This document discusses guidelines developed at NASA Langley Research Center (LaRC) for tailoring the application of NASA Project Management and Systems Engineering requirements (NPR 7120.5 and NPR 7123.1) to better fit different types and sizes of projects. It provides background on LaRC's range of projects from small to large. Guidelines were created to help determine what requirements should be tailored down, tailored out, or left as-is for different project types. Examples are given of how requirements would be tailored for a Type E small project. The tailoring approach and guidelines are meant to help execute projects more efficiently while still meeting overall NASA requirements.
The document discusses schedule metrics and performance measurement for project management. It describes how schedules can be used as a management tool by generating relevant metrics and key performance indicators. It emphasizes analyzing metrics at different levels, such as the overall schedule and project, and tracking trends over time. The presentation provides examples of different types of metrics and reports that can be generated from schedule data, including burndowns, distributions, constraints, and comparisons of baseline, forecast and actual progress. The goal is to help managers sort through schedule data and metrics to identify areas for improvement or risks that require action.
This document discusses using earned value management techniques for software projects. It outlines some current challenges with applying earned value to software, including excessive use of level of effort tasks and not properly accounting for rework. It emphasizes that earned value measures need to directly relate to implementing requirements. The document also discusses breaking work into phases and using a work breakdown structure that properly captures the software effort.
The document summarizes the types of cost and schedule reports that NASA provides to oversight bodies like Congress, OMB, and GAO. It discusses baseline reports, current estimate reports, and threshold reports. Baseline reports establish cost and schedule commitments at major decision points, while current estimate reports provide updated estimates. Threshold reports are triggered if cost or schedule growth exceeds certain levels and require explanations. The document reviews the specific information and timelines for each report.
This document discusses human perception of risk and error. It summarizes James Reason's Swiss Cheese Model of accidents, which describes how accidents occur when multiple latent conditions and active failures line up. It also discusses how humans make decisions based on their local rationality and patterns of experience, which can sometimes lead to poor choices. Common cognitive traps like anchoring and availability are discussed. The document provides tips for avoiding these traps and developing personal situational awareness to improve decision-making.
This document provides an overview of the United Launch Alliance (ULA) transition and the challenges faced by the Launch Services Program in overseeing the transition. It discusses the ULA transition management approach, key projects in the transition like business operations and production, and risk mitigation efforts. Some of the challenges highlighted include managing requirements from multiple sources, the complexity of the transition due to legal, procurement and technical factors, and ensuring skills retention. It concludes with the top 10 risk management lessons learned, emphasizing communication, collaboration, understanding changes, and maintaining focus on NASA's interests and mission success.
This document discusses opportunities for international collaboration on understanding climate change. It outlines key issues including the need for open data exchange, the many potential partners across nations and agencies, balancing scope and continuity of observations, deciding between collaborative missions or programs, and coordinating roles between entities. The goal is to efficiently and effectively address the large challenge of climate change through collaborative Earth system science.
This document discusses risk informed design and test approaches being used on NASA's Constellation Program (CxP). It provides the following key points:
1. CxP aims to develop exploration systems to support ISS and lunar missions using a risk informed design approach to optimize safety and mission success within costs and schedules.
2. Risk informed design incorporates probabilistic risk analyses into the design process to inform trades and identify optimal risk reduction strategies. This includes a "zero based design" approach.
3. Initial results show the risk informed design process has led to significant improvements in safety for Orion and Ares projects while resolving design challenges. Ongoing work includes further maturing risk models and analysis methods.
The Naval Aviation Enterprise Carrier Readiness Team required a quantitative risk analysis methodology to holistically assess risks to aircraft carrier availability given strategic challenges including a reduction in carriers, budget constraints, aging aircraft, and maintenance schedules; the methodology involved identifying risks, analyzing historical data, collaborating with stakeholders, modeling risks, and translating results to availability metrics to evaluate cost and schedule impacts and sensitivity. The risk analysis provided recommendations on priority areas including maintenance schedules, system dependencies, bottlenecks, and costs to inform strategic planning for carrier availability.
This document provides an overview of the Imagery Analysis Facility at NASA's Kennedy Space Center. It discusses how the facility supports various NASA programs like the Space Shuttle and International Space Station by analyzing imagery data. It describes how imagery is used to support engineering teams and evaluate vehicle and system performance during launch, ascent, and landing. It also discusses how the facility upgraded its projection system to a 4K system to properly analyze high resolution imagery as film-based imagery was being phased out. The document emphasizes the importance of imagery analysis for lessons learned from past missions and safety.
The document summarizes a case study using systems engineering models to plan the Exploration Flight Test-1 (EFT-1) mission for NASA's Orion spacecraft. Key points:
- EFT-1 will test Orion capabilities before crewed flights, including separations, parachutes, attitude control during reentry, and water recovery.
- Systems engineering models were used to understand data and resource needs, flows, and access across distributed NASA/Lockheed Martin teams.
- Custom viewpoints were defined in SysML to address stakeholder questions and visualize mission elements like components, data exchanges, and interface requirements.
Requirements development and management involves defining requirements at different levels in a hierarchy. This includes allocating higher-level requirements to lower levels and ensuring traceability between levels. Proper allocation and traceability helps identify issues like requirements being at the wrong level or lower-level requirements that cannot be justified by higher ones. It involves defining requirements for an overall system and then allocating them to subsystems and components at lower levels.
This document discusses various methods for integrated circuit design, including canonical design, waterfall vs. spiral models, and top-down vs. bottom-up approaches. It also addresses challenges in chip design like short timelines, increasing complexity, and changing tools. Key aspects of design covered include documentation, reuse, verification, and the economics of reusable blocks. Top-level design flows start with specifications and move through behavioral modeling, partitioning, and implementation blocks. Definitions of design specifications and intellectual property design are also provided.
This document provides an overview and summary of a Navy Service-Oriented Architecture (SOA) Reference Model. It discusses the purpose and goals of developing the reference model, including describing Navy SOA goals in the context of commercial goals and standards. It also outlines the key sections and components of the reference model, including the Business Reference Model, Services Reference Model, and Technical Reference Model. The document recommends following commercial best practices and compliance with relevant guidance and standards.
Shivam Technologies is an engineering solutions company based in Pune, India that has been in operation since 2001. It has over 100 engineering resources with expertise across various industries like automotive, aerospace, and energy. The company uses process-driven methodologies and has tools for outsourcing engineering services. It has experienced high growth and client retention over the past 5 years. Shivam Technologies provides services like CAD modeling, CAE analysis, tooling design, and product development.
Software Architecture: introduction to the abstractionHenry Muccini
The document provides an introduction to software architecture concepts including:
- Software architecture is defined as a set of components and connectors communicating through interfaces along with architecture design decisions.
- Multiple views are used to describe architectures including logical, process, deployment, and more.
- Architectural styles like pipe-and-filter and layered styles guide architecture design.
- Careful architecture design is important as it impacts system properties like performance, scalability, and testability.
Hexaware provided comprehensive testing and automation services to help a leading global provider of energy and engineering services achieve its business objectives. This included implementing a life cycle model, tracking metrics and service level agreements, and planning test automation. Hexaware analyzed the client's energy and engineering applications, prepared test cases, and conducted defect management using Microsoft Visual Studio Team Services. This helped the client maintain quality standards, provide transparency, and have resources available during critical releases.
Here are potential risk management strategies for some key risks:
- Organisational financial problems: Prepare a briefing document for senior management showing how the project is making an important contribution to business goals.
- Recruitment problems: Alert customer to potential difficulties and delays, investigate buying components instead of developing in-house.
- Staff illness: Reorganize team work so there is more overlap and people understand each other's roles.
- Defective components: Replace defective components with reliable bought-in alternatives.
- Requirements changes: Derive traceability information to assess impact and maximize information hiding in design.
- Organizational restructuring: Brief management on project importance to gain high-level support
This document outlines deliverables that may be produced at different phases of a software development project. It lists possible deliverables for phases including concept, requirements, analysis, design, coding and debugging, testing, deployment, and maintenance. For each phase, the document provides brief descriptions of the types of documents or work products that could be delivered, such as requirements specifications, design documents, test plans, code, and user documentation.
The document discusses key concepts about software architecture:
1) Architecture is a set of principal design decisions that affect every aspect of software development.
2) Every application has an architect and an architecture, even if not explicitly defined.
3) Architecture should not be treated as just a phase of development but rather as foundational to development.
1. The document discusses key concepts of software architecture, including that every application has an architecture and architect, and that architecture is not just a phase of development but rather a foundational part of software development.
2. It describes how requirements analysis and design are intertwined with architecture considerations, and how non-functional properties depend on architectural choices.
3. The document presents different models of software development processes, including one called the "Turbine Model" that visualizes project activities and artifacts over time.
The document describes ISO/IEC 29110 for software implementation processes. It discusses the key process activities including requirements analysis, architectural and detailed design, software construction, integration and testing, product delivery, and verification and validation. Traceability is established between requirements, design, code, and tests. Test plans, cases, reports and product documentation are also outlined.
Using Doors® And Taug2® To Support A Simplifiedcbb010
In order to become a market leader, it is imperative that all stakeholders (customers, financial sponsors, developers and testers) be aware of the customer’s needs as captured in the requirements of the products and/or services that are to be produced. This is especially so within both large and small globally distributed companies since the product development organizations often are separated by geography, time and communications. An efficient way to eliminate these potential issues is to develop a common and intuitive requirements management process, which can be deployed across the product development lifecycle. The object of developing a Common Simplified Requirements Management Process is to improve customer satisfaction, eliminate escaping defects and reduce the cost of the development lifecycle. This paper describes the problems of using localised procedures and how these problems can be eliminated by implementing a common requirements management process that is intuitive, scalable and deployed across the System Development Lifecycle. This process has been supported by the industry leading DOORS tool and more recently by the TauG2 tool. An auxiliary benefit of deploying this process is that the process was developed in compliance with standardized methods of documenting and tracing requirements as expected by TL9000 and CMM/CMMI. The net benefits of this simplified requirements process include: increased customer satisfaction due to systems being developed in accordance with the customer’s needs as captured in the requirements, compliance with industry acknowledged process standards and improved cost of quality by eliminating duplication of process maintenance since a common process has been deployed across the development organization.
The document summarizes a feasibility assessment of three candidate systems for an information system project. It describes the operational, technical, economic and schedule feasibility of each candidate. Metrics like functionality, costs, benefits and timelines are evaluated. Candidate 2 scores the highest overall due to fully supporting required functionality, using a mature technology, having the best cost-benefit profile and moderate implementation timeline.
This document discusses the challenges with current embedded systems design methodologies and proposes a new approach. It notes that embedded systems are becoming more complex, software-based implementations are more common, and verification is more difficult. It proposes a new methodology with three principles: separation of concerns, a theoretical framework, and platform-based design. This new methodology aims to address issues like design time/cost, verification, constraints, and reuse through tools that span different abstraction levels. It also discusses current problems with embedded software development.
The document discusses software architecture and quality attributes. It defines software architecture as the structure of components in a system and their relationships. Quality attributes are non-functional requirements that cover aspects like performance, security, and maintainability. The document discusses how architectural decisions impact quality attributes and gives examples of quality attribute scenarios to define non-functional requirements precisely. Architectural patterns can help meet quality attribute requirements.
This document describes Web2MexADL, a tool for discovering and verifying the architecture of software systems. It uses machine learning techniques to classify components and generate architecture views. The views are expressed using MexADL, an architecture description language. Web2MexADL was implemented as an Eclipse plugin and can recover MVC-based or clustered architectures. It aims to help maintain software by verifying architectures match intended patterns and quality metrics. Future work includes improving classification, supporting other languages/platforms, and non-web applications.
Command center processing and display system replacement (ccpds-r) - Case StudyKuppusamy P
This document describes a case study of the Command Center Processing and Display System - Replacement (CCPDS-R) project led by TRW Space and Defense for the U.S. Air Force. The CCPDS-R was developed to replace the primary missile warning system at Cheyenne Mountain and included a 48-month development schedule using Ada. Key aspects of the CCPDS-R project included: 1) Developing a common subsystem with six software components, 2) Using an incremental design and development approach split into builds, and 3) Conducting demonstrations at major milestones to assess requirements and architectural risks. The project was completed on time and within budget to customer satisfaction.
The document summarizes a presentation by a team proposing to install solar photovoltaic canopies at Tucson International Airport. The team focuses on three key areas: delivering an iconic system with high-quality components, employing strategic construction methods to minimize disruption, and functioning as a collaborative partner to ensure quality control standards are met. Alternatives discussed include different interconnection approaches and adding post-warranty maintenance, energy monitoring displays, advertising screens, and green walls. The team aims to provide responsive support throughout the project.
The document provides an overview of the process for designing and producing an application specific integrated circuit (ASIC) with Swindon Silicon Systems. It discusses the design process from initial specification through layout, fabrication, and testing. Key steps include specification, design and simulation, processing including wafer thinning and dicing, and prototype evaluation. Swindon offers full turnkey ASIC design and supply services from concept to production.
The document compares the operational complexity and costs of the Space Shuttle versus the Sea Launch Zenit rocket. [1] The Space Shuttle was designed for performance but not operational efficiency, resulting in costly ground, mission planning, and flight operations. [2] In contrast, the Zenit rocket was designed from the start to have automated and robust processes to keep operations simple and costs low. [3] The key lesson is that designing a launch system with operational requirements in mind from the beginning leads to much more efficient operations long-term.
The document provides an overview of project management and procurement at NASA. It discusses the key skills required for project managers, including acquisition management. It notes that 80-85% of NASA's budget is spent on contracts, and procurement processes are complex and constantly changing. The document outlines some common contract types and how they allocate risk between the government and contractor. It also discusses the relationship between contracting officers and project managers, and how successful procurement requires effective communication rather than direct control or authority.
The document introduces the NASA Engineering Network (NEN), which was created by the Office of the Chief Engineer to be a knowledge management system connecting NASA's engineering community. The NEN integrates various tools like a content management system, search engine, and collaboration tools. It provides access to key knowledge resources like NASA's Lessons Learned database and engineering databases. The NEN is working to expand by adding more communities, engineering disciplines, and knowledge repositories.
Laptops were first used in space in 1983 on the Space Shuttle, when Commander John Young brought the GRiD Compass portable computer on STS-9. Laptops are now widely used on the Space Shuttle and International Space Station for tasks like monitoring spacecraft systems, tracking satellites, inventory management, procedures viewing, and videoconferencing. Managing laptops in space presents challenges around cooling, power, and software/hardware compatibility in the harsh space environment.
Laptops were first used in space in 1983 on the Space Shuttle, when Commander John Young brought the GRiD Compass portable computer on STS-9. Laptops are now widely used on the Space Shuttle and International Space Station for tasks like monitoring spacecraft systems, planning rendezvous and proximity operations, inventory management, procedure reviews, and communication between space and ground via software like WorldMap and DOUG. Managing laptops in space presents challenges around hardware durability, cooling, and software/data management in the space environment.
This document discusses the use of market-based systems to allocate scarce resources for NASA missions and projects. It provides examples of how market-based approaches were used for instrument development for the Cassini mission, manifesting secondary payloads on the space shuttle, and mission planning for the LightSAR Earth imaging satellite project. The document finds that these applications of market-based allocation benefited or could have benefited from a decentralized, incentive-based approach compared to traditional centralized planning methods. However, it notes that resistance to new approaches and loss of managerial control are barriers to adoption of market-based systems.
The Stardust mission collected samples from comet Wild 2 and interstellar dust particles. It launched in February 1999 and encountered Wild 2 in January 2004, collecting dust samples in aerogel. It returned the samples to Earth safely in January 2006. The spacecraft used an innovative Whipple shield to protect itself from comet dust impacts during the encounter. Analysis of the Stardust samples has provided insights about comet composition and the early solar system.
This document discusses solutions for integrating schedules on NASA programs. It introduces Stuart Trahan's company, which provides Earned Value Management (EVM) solutions using Microsoft Office Project that comply with OMB and ANSI requirements. It also introduces a partner company, Pinnacle Management Systems, that specializes in enterprise project management solutions including EVM, project portfolio management, and enterprise project resource management, with experience in the aerospace, defense, and other industries. The document defines schedule integration and describes some methods including importing to a centralized Primavera database for review or using Primavera ProjectLink for updates, and challenges including inconsistent data formats and levels of detail across sub-schedules.
The document discusses NASA's implementation of earned value management (EVM) across its Constellation Program to coordinate work across multiple teams. It outlines the organizational structure, current target groups, and an EVM training suite. It also summarizes lessons learned and the need for project/center collaboration to integrate schedules horizontally and vertically.
This document summarizes a presentation about systems engineering processes for principle investigator (PI) mode missions. It discusses how PI missions face special challenges due to cost caps and lower technology readiness levels. It then outlines various systems engineering techniques used for PI missions, including safety compliance, organizational communication, design tools, requirements management, and lessons learned from past missions. Specific case studies from NASA's Explorers Program Office are provided as examples.
This document discusses changes to NASA's business practices for managing projects, including adopting a new acquisition strategy approach and implementing planning, programming, and budget execution (PPBE). The new acquisition strategy involves additional approval meetings at the strategic planning and project levels to better integrate acquisition with strategic and budgetary planning. PPBE focuses on analyzing programs and infrastructure to align with strategic goals and answer whether proposed programs will help achieve NASA's mission. The document also notes improvements in funds distribution and inter-center transfers, reducing the time for these processes from several weeks to only a few days.
Spaceflight Project Security: Terrestrial and On-Orbit/Mission
The document discusses security challenges for spaceflight projects, including protecting space assets from disruption, exploitation, or attack. It highlights national space policy principles of protecting space capabilities. It also discusses trends in cyber threats, including the increasing capabilities of adversaries and how even unskilled attackers can compromise terrestrial support systems linked to space assets if defenses are not strong. Protecting space projects requires awareness of threats, vulnerabilities, and strategies to defend, restore, and increase situational awareness of space assets and supporting systems.
Humor can positively impact many aspects of project management. It can improve communication, aid in team building, help detect team morale issues, and influence leadership, conflict management, negotiation, motivation, and problem solving. While humor has benefits, it also has risks and not all uses of humor are positive. Future research is needed on humor in multicultural teams, its relationship to team performance, how humor is learned, and determining optimal "doses" of humor. In conclusion, humor is a tool that can influence people and projects, but must be used carefully and spontaneously for best effect.
The recovery of Space Shuttle Columbia after its loss in 2003 involved a massive multi-agency effort to search a wide debris field, recover crew remains and evidence, and compensate local communities. Over 25,000 people searched over 680,000 acres, recovering 38% of Columbia's weight. Extensive engineering investigations were conducted to identify the causes of failure and implement changes to allow the safe return to flight of Discovery in 2005.
This document summarizes research on enhancing safety culture at NASA. It describes a survey developed to assess NASA's safety culture based on principles of high reliability organizations. The survey was tailored specifically for NASA and has been implemented to provide feedback and identify areas for improvement. It allows NASA to benchmark its safety culture within and across other industries pursuing high reliability.
This document summarizes a presentation about project management challenges at NASA Goddard Space Flight Center. The presentation outlines a vision for anomaly management, including establishing consistent problem reporting and analysis processes across all missions. It describes the current problem management approach, which lacks centralized information sharing. The presentation aims to close this gap by implementing online problem reporting and trend analysis tools to extract lessons learned across missions over time. This will help improve spacecraft design and operations based on ongoing anomaly experiences.
This document discusses leveraging scheduling productivity with practical scheduling techniques. It addresses scheduling issues such as unwieldy schedule databases and faulty logic. It then discusses taming the schedule beast through using a scheduler's toolkit, schedule templates, codes to manipulate MS Project data, common views/filters/tables, limiting constraints, and other best practices. The document provides examples of using codes and custom views/filters to effectively organize and display schedule information.
This document describes Ball Aerospace's implementation of a Life Cycle and Gated Milestone (LCGM) process to improve program planning, execution, and control across its diverse portfolio. The LCGM provides a standardized yet flexible framework that maps out program activities and products across phases. It was developed through cross-functional collaboration and introduced gradually across programs while allowing flexibility. Initial results showed the LCGM supported improved planning and management while aligning with Ball Aerospace's entrepreneurial culture.
This document discusses the importance of situation awareness (SA) for project team members. It defines SA as having three levels: perception of elements in the current situation, comprehension of the current situation, and projection of the future status. Good team SA is achieved by turning individual SAs into shared SA through communication. Teams with strong SA prepare more, focus on comprehending and projecting, and maintain awareness through techniques like questioning assumptions and seeking additional information.
This document discusses theories of leadership and how a project manager's leadership style may impact project success depending on the type of project. It outlines early hypotheses that a PM's competence, including leadership style, is a success factor on projects. It presents a research model linking PM leadership competencies to project success, moderated by factors like project type. Initial interviews found that leadership style is more important on complex projects, and different competencies are needed depending on if a project is technical or involves change. Certain competencies like communication skills and cultural sensitivity were seen as important for different project types and contexts.
Driving Business Innovation: Latest Generative AI Advancements & Success StorySafe Software
Are you ready to revolutionize how you handle data? Join us for a webinar where we’ll bring you up to speed with the latest advancements in Generative AI technology and discover how leveraging FME with tools from giants like Google Gemini, Amazon, and Microsoft OpenAI can supercharge your workflow efficiency.
During the hour, we’ll take you through:
Guest Speaker Segment with Hannah Barrington: Dive into the world of dynamic real estate marketing with Hannah, the Marketing Manager at Workspace Group. Hear firsthand how their team generates engaging descriptions for thousands of office units by integrating diverse data sources—from PDF floorplans to web pages—using FME transformers, like OpenAIVisionConnector and AnthropicVisionConnector. This use case will show you how GenAI can streamline content creation for marketing across the board.
Ollama Use Case: Learn how Scenario Specialist Dmitri Bagh has utilized Ollama within FME to input data, create custom models, and enhance security protocols. This segment will include demos to illustrate the full capabilities of FME in AI-driven processes.
Custom AI Models: Discover how to leverage FME to build personalized AI models using your data. Whether it’s populating a model with local data for added security or integrating public AI tools, find out how FME facilitates a versatile and secure approach to AI.
We’ll wrap up with a live Q&A session where you can engage with our experts on your specific use cases, and learn more about optimizing your data workflows with AI.
This webinar is ideal for professionals seeking to harness the power of AI within their data management systems while ensuring high levels of customization and security. Whether you're a novice or an expert, gain actionable insights and strategies to elevate your data processes. Join us to see how FME and AI can revolutionize how you work with data!
Ivanti’s Patch Tuesday breakdown goes beyond patching your applications and brings you the intelligence and guidance needed to prioritize where to focus your attention first. Catch early analysis on our Ivanti blog, then join industry expert Chris Goettl for the Patch Tuesday Webinar Event. There we’ll do a deep dive into each of the bulletins and give guidance on the risks associated with the newly-identified vulnerabilities.
AI 101: An Introduction to the Basics and Impact of Artificial IntelligenceIndexBug
Imagine a world where machines not only perform tasks but also learn, adapt, and make decisions. This is the promise of Artificial Intelligence (AI), a technology that's not just enhancing our lives but revolutionizing entire industries.
OpenID AuthZEN Interop Read Out - AuthorizationDavid Brossard
During Identiverse 2024 and EIC 2024, members of the OpenID AuthZEN WG got together and demoed their authorization endpoints conforming to the AuthZEN API
Monitoring and Managing Anomaly Detection on OpenShift.pdfTosin Akinosho
Monitoring and Managing Anomaly Detection on OpenShift
Overview
Dive into the world of anomaly detection on edge devices with our comprehensive hands-on tutorial. This SlideShare presentation will guide you through the entire process, from data collection and model training to edge deployment and real-time monitoring. Perfect for those looking to implement robust anomaly detection systems on resource-constrained IoT/edge devices.
Key Topics Covered
1. Introduction to Anomaly Detection
- Understand the fundamentals of anomaly detection and its importance in identifying unusual behavior or failures in systems.
2. Understanding Edge (IoT)
- Learn about edge computing and IoT, and how they enable real-time data processing and decision-making at the source.
3. What is ArgoCD?
- Discover ArgoCD, a declarative, GitOps continuous delivery tool for Kubernetes, and its role in deploying applications on edge devices.
4. Deployment Using ArgoCD for Edge Devices
- Step-by-step guide on deploying anomaly detection models on edge devices using ArgoCD.
5. Introduction to Apache Kafka and S3
- Explore Apache Kafka for real-time data streaming and Amazon S3 for scalable storage solutions.
6. Viewing Kafka Messages in the Data Lake
- Learn how to view and analyze Kafka messages stored in a data lake for better insights.
7. What is Prometheus?
- Get to know Prometheus, an open-source monitoring and alerting toolkit, and its application in monitoring edge devices.
8. Monitoring Application Metrics with Prometheus
- Detailed instructions on setting up Prometheus to monitor the performance and health of your anomaly detection system.
9. What is Camel K?
- Introduction to Camel K, a lightweight integration framework built on Apache Camel, designed for Kubernetes.
10. Configuring Camel K Integrations for Data Pipelines
- Learn how to configure Camel K for seamless data pipeline integrations in your anomaly detection workflow.
11. What is a Jupyter Notebook?
- Overview of Jupyter Notebooks, an open-source web application for creating and sharing documents with live code, equations, visualizations, and narrative text.
12. Jupyter Notebooks with Code Examples
- Hands-on examples and code snippets in Jupyter Notebooks to help you implement and test anomaly detection models.
Best 20 SEO Techniques To Improve Website Visibility In SERPPixlogix Infotech
Boost your website's visibility with proven SEO techniques! Our latest blog dives into essential strategies to enhance your online presence, increase traffic, and rank higher on search engines. From keyword optimization to quality content creation, learn how to make your site stand out in the crowded digital landscape. Discover actionable tips and expert insights to elevate your SEO game.
GraphRAG for Life Science to increase LLM accuracyTomaz Bratanic
GraphRAG for life science domain, where you retriever information from biomedical knowledge graphs using LLMs to increase the accuracy and performance of generated answers
Project Management Semester Long Project - Acuityjpupo2018
Acuity is an innovative learning app designed to transform the way you engage with knowledge. Powered by AI technology, Acuity takes complex topics and distills them into concise, interactive summaries that are easy to read & understand. Whether you're exploring the depths of quantum mechanics or seeking insight into historical events, Acuity provides the key information you need without the burden of lengthy texts.
How to Interpret Trends in the Kalyan Rajdhani Mix Chart.pdfChart Kalyan
A Mix Chart displays historical data of numbers in a graphical or tabular form. The Kalyan Rajdhani Mix Chart specifically shows the results of a sequence of numbers over different periods.
Have you ever been confused by the myriad of choices offered by AWS for hosting a website or an API?
Lambda, Elastic Beanstalk, Lightsail, Amplify, S3 (and more!) can each host websites + APIs. But which one should we choose?
Which one is cheapest? Which one is fastest? Which one will scale to meet our needs?
Join me in this session as we dive into each AWS hosting service to determine which one is best for your scenario and explain why!
Ocean lotus Threat actors project by John Sitima 2024 (1).pptxSitimaJohn
Ocean Lotus cyber threat actors represent a sophisticated, persistent, and politically motivated group that poses a significant risk to organizations and individuals in the Southeast Asian region. Their continuous evolution and adaptability underscore the need for robust cybersecurity measures and international cooperation to identify and mitigate the threats posed by such advanced persistent threat groups.
Fueling AI with Great Data with Airbyte WebinarZilliz
This talk will focus on how to collect data from a variety of sources, leveraging this data for RAG and other GenAI use cases, and finally charting your course to productionalization.
Taking AI to the Next Level in Manufacturing.pdfssuserfac0301
Read Taking AI to the Next Level in Manufacturing to gain insights on AI adoption in the manufacturing industry, such as:
1. How quickly AI is being implemented in manufacturing.
2. Which barriers stand in the way of AI adoption.
3. How data quality and governance form the backbone of AI.
4. Organizational processes and structures that may inhibit effective AI adoption.
6. Ideas and approaches to help build your organization's AI strategy.
1. Determining Requirements
Compliance During the Design
Phase for a System of Systems
February 10, 2011
Alan Dickey, Wyle Integrated Science and Engineering
Stephen Chan, NASA JSC
Shana McElroy, Booz Allen Hamilton
2. Outline
Introduction and Background
Purpose and Objectives
Methodology Details
Influencing Design
Connecting to Verification
Making it Work for a System of Systems Architecture
- -
Requirements Design Compliance Page 2
3. Introduction – Project Life Cycle Phases
Requirements Development/
Achievability
Focus on establishing
program requirements that Design
demonstrate capability to
meet Agency goals and
objectives Design Qualification
Period of time used to and Verification
define the detailed design
of the system
Focus on developing confidence
that the integrated system will be
able to satisfy technical
requirements
SRR SDR PDR CDR SAR
Key
SRR – System Requirements Review
SDR – System Definition Review
PDR – Preliminary Design Review
CDR – Critical Design Review
SAR – System Acceptance Review
Requirements Design Compliance Page 3
4. Introduction - How Requirements Design Compliance Fits
The design phase must adeptly
balance the interplay between
hardware/software design and
the requirements while managing
an acceptable level of safety/risk,
all within the context of the
defined operations concepts
Requirements Design Compliance Page 4
5. Introduction - Why Requirements Design Compliance?
A system of systems is complex and has many variables – making an
objective decision to proceed from one design phase to the next is hard
and Requirements Design Compliance is a systematic method to bring
more objectivity into that decision making process
Risk can be found early by measuring the requirement achievability of
design concepts with the same measuring stick that will be used in the
final product
Requirement verification is the finish-line by which we declare success
for product delivery, therefore requirement compliance assessments can
be used to provide periodic dry-runs for verification
NPR 7123 Success Criteria (as it relates to requirements design compliance):
At PDR: The preliminary design is expected to meet the requirements at an
acceptable level of risk
At CDR: The detailed design is expected to meet the requirements with
adequate margins at an acceptable level of risk
Requirements Design Compliance Page 5
6. Introduction – Constellation Program Structure
Constellation (Cx)
Program Office
Requirements Design Compliance Page 6
7. Background - Requirement Flow Down and Decomposition
Requirement decomposition, flow down and traceability of top level
Architecture requirements set the stage for Requirements Design
Compliance
● For Cx, Architecture requirements are implemented through Program and allocated
to Projects (systems), and flowed down to the design implementation level
● All Cx requirements are assigned owners and mapped to stakeholders
Ares 1 Cx
Ex-0010-01 ISS Crew Capacity
CA0426-PO Orion Habitable Volume Orion
Orion
Element
CA0447-PO Orion Low Earth Orbit Crew Capability
CV0085 Orion Automated De-Orbit from Low Earth Orbit
SS-SC-2256 Low Earth Orbit Capability
CV0874 Orion Un-Crewed Flight Configuration
CA0447-PO Orion Automated Rendezvous, Prox Ops, Dock/Undock EVA
Mission Systems
CA5129-PO Mission Systems Crew Training
EVA1067 EVA System Crew Size
CA1000-PO Ares 1 Lift Mass for ISS Missions
Requirements Design Compliance Page 7
8. Requirements Design Compliance Purpose & Objectives
Purpose of Requirements Design Compliance is to identify and establish
resolution paths for integrated architectural performance/design issues
as early in the design cycle as possible
Proactively manage ‘acceptable level of risk’
Early issue resolution/prevention reduces cost and schedule impacts
End-to-End mission architecture perspective
Key objectives of Requirements Design Compliance include:
Early identification of design aspects that are at high risk to meet the established
requirements and perform end-to-end
Utilize objective design evidence to determine success of design cycle, from
architecture perspective of the design reference mission (DRM) and operations
concepts (ops con)
Facilitate vertical integration of design compliance data with Projects and horizontal
integration across Program (i.e. provide bigger picture for lower level requirements)
Resolve, report and track significant architecture compliance issues (includes impact
analysis based on lover level non-compliances)
Engage architecture requirement owners in how the design will be verified and
create a relationship between the tools/process for compliance with that used for
verification (‘get their hands dirty’ early)
Connects the beginning (requirements) to the end (verification) and
provides a means to track the health of the architecture and minimize risk
Requirements Design Compliance Page 8
10. Requirements Design Compliance Methodology -
Issue Handling Processes
Project
Project
Project
Project
Project
Data
DCMs
DCMs
DCMs
DCMs
Requirement Requirement
Stakeholders Reqmt Owners Design
Owners Compliance
Assessments
Architecture/System
Processes
Status used as assessment input
Risk Plans
TPMs
Technology
New issue handling measures created to mitigate new issues
Analyses
Change Request
Requirement Owners use objective data provided by projects, stakeholders,
architecture analyses and issue handling processes to conduct requirement design
compliance assessments as an integrated team/process activity. Issues fed back to
architecture or system issue resolution processes as appropriate.
Requirements Design Compliance Page 10
11. Requirements Design Compliance Methodology, continued
Requirements Design Compliance relies on objective evidence to identify
issues that could impact verifying the architecture requirements
• Objective evidence helps limit subjectivity when assessing realistic level of risk;
however, objective evidence must be combined with sound judgment – design phase
data may be incomplete and sound judgment is needed to help bridge the gap
• As the Project moves forward through its life cycle, more objective data is necessary to
lead to verification compliance
• Lack of any objective evidence indicative of either non-compliant design or design
behind schedule
Acceptable objective evidence can be of many types, such as:
• Analysis and Independent Assessment Results – approved and peer reviewed
• Technical Performance Metric (TPM) Reports – e.g., monthly mass status
• Inspection and Demonstration Reports
• Test Reports
• Design Data Deliverables
• Engineering judgment based on historical similarity
Traceability permits objective evidence to be readily linked to requirements
Objective evidence is key to Requirements Design Compliance but
thinking must stay in the equation
Requirements Design Compliance Page 11
12. Requirements Design Compliance Methodology - Definitions
Architecture Compliance Definitions
Compliant (Green) – The overall technical design is expected to meet the
requirement at an acceptable level of risk.
Watch (Yellow) –
The overall technical design does not currently meet the requirement,
but an acceptable mitigation plan has been identified and documented.
There exists a specific significant threat(s) that requires additional
mitigation plans to be developed – actions assigned and accepted.
Non-Compliant (Red) – The overall technical design is not expected to meet
the requirement and an acceptable mitigation plan has not been identified. In
addition, the requirement has systemic threats that permeates the overall
design compliance.
Acceptable Level of Risk - No known technical issues exist which will impact
meeting the requirement; or, appropriate issue management processes (risk
mitigation plans, Technical Performance Measures, etc.) are in place and
indicate issue(s) will be mitigated to meet program baseline schedule. See
graphic on next chart.
Requirements Design Compliance Page 12
13. Requirements Design Compliance
Methodology - Acceptable Level of Risk
Current The Approved Mitigation Plan – Day 0
kg (1000)* Design Task 1
3.5 Task 2
Level of risk is acceptable if:
• A technically feasible/funded path forward exists to
3.0 provide a compliant design prior to a required date
High • Plan is executed and remains on schedule
2.5 Task 3 Task 4
2.0 Moderate Risk
Task 5
Required Level
1.5 Task 6 Date
Requirement*
1.0
Predicted path forward should be described
Low via a Risk Plan, TPM, or other project plan
0.5
and statused in the appropriate forum.
0.0
Time *Hypothetical requirement
Requirements Design Compliance Page 13
14. Requirements Design Compliance Methodology -
Tools Used
Requirements
Design Compliance
embedded in
Architecture
requirement
database (Cradle)
Full linkages
between
requirements and
assessments
Assessment reports
and requirement
traceability reports
exported to Excel
Any database/excel
can be used as tool
+
An intuitive, uncomplicated tool which links directly to requirements
database will yield the best results
Requirements Design Compliance Page 14
15. Using Requirements Design Compliance to Influence Design - Example
Requirement Design Compliance at Ares PDR proved effective at
identifying significant integrated requirement non-compliances
Example 1 – analysis revealed the liftoff
clearance between the integrated stack vehicle
and the launch facility was insufficient and
caused pad re-contact & plume damage
Requirement validation and model refinement (e.g.
cantilever vehicle, thrust misalignment update) did
not resolve issue
Implemented thrust vector control (TVC) on liftoff to
preclude re-contact (e.g. command to counter
deterministic TVC bias, command to bias to the
South)
Example 2 – GN&C team analysis indicated a
roll attitude error build up during First Stage flight
that exceeded the 27 deg requirement
Defined forward work such as evaluating OML
changes to improve aero roll torques, re-working
CFD, and re-examining vehicle performance using
Monte Carlo Flight simulations to gain compliance
Combined hardware (aerodynamic strake) and
software (load relief algorithms) options to optimize
resolution of roll attitude error issue Example from Ares I-X Roll Control System
CFD Analysis
Requirements Design Compliance Page 15
16. Connecting Requirements Design Compliance to Verification
During PDR phase, verification planning is in early development
● The Requirements Design Compliance effort is separate from verification
planning due to disparate maturity levels between the two efforts
– Verification and requirements compliance have a lot of overlaps
– Requirements compliance helps clarify verification planning aspects
During CDR phase, verification is in final planning stage
● Requirements design compliance combined with verification pre-work
– Capture objective evidence in same database
– Look for and capture requirements compliance data that could be used as part of
verification closure data
For example, integrated verification starts at CDR – integrated analyses to be
used for verification are often complete; you validate that the systems are
performing as you expected through qualification
Requirements design compliance can help identify constraints for
verification work and/or potential operational constraints due to
verification limitations
Assessments supporting Requirements Design Compliance can provide the
integrated analysis for verification, leaving only validation of the system to
be done through qual
Requirements Design Compliance Page 16
17. Making it Work for a System of Systems Architecture
The integration effort is easily underestimated, with specific
integration needed to
● Agree on roles and responsibilities between architecture and systems
– System data is needed at specific points in time to determine architecture compliance at
major milestones
– Many of the pieces from this effort came from collaboration with system implementers
– Agree on both the what and the how
– Create an overall community of practice focused on overall architecture requirements
design compliance
● Clarify that it isn’t just filling in a database with compliance data – it is a
technical assessment
– Time must be allocated for the technical team members to perform the assessment
● Learn from the different system engineering perspectives in order to
improve the success of the effort
– Ares was first system to be assessed - provided significant insight into what to do and
not do
● Communicate definitions and objectives across all teams
Requirements Design Compliance Page 17
18. Making it Work for a System of Systems Architecture, cont.
Showing design is compliant to requirements is needed by all systems
to move from one phase to the next – communicate value/purpose at
all levels
It always takes more time than you think it should – maximize time for
stakeholders and requirement owners assessment
The earlier in the project lifecycle you start, the easier it is to
implement
● Starting during requirements development/achievability phase using available data
enables full PDR phase implementation and facilitates understanding of
requirements achievability
Requirements Design Compliance Page 18
19. Making it Work for a System of Systems Architecture, cont.
Simplicity should be a high priority – people/teams get frustrated by
complicated processes and tools
● The objective is not to have a process/tool that does the engineer’s thinking, but
to have a simple enough process/tool that it enables the engineers to think
Requirement traceability is a factor in the accuracy of the effort
Acceptable level of risk has different meanings to different people
It is not a panacea of all integration – it is more like a periodic health
report to catch anything integration missed
● While such a process can be intuitive for a small project, for a large Project you
don’t want to leave it to chance
Requirements Design Compliance Page 19
21. If you would like further information…
Alan Dickey: john.a.dickey@nasa.gov, 281-244-5680
Stephen Chan: stephen.t.chan@nasa.gov, 281-483-1083
Shana McElroy: shana.mcelroy-1@nasa.gov, 281-483-9580
Requirements Design Compliance Page 21
23. Why Integration Is Needed
As proposed by the As specified by the Design as interpreted
customer. Program. by Project A.
Design as interpreted Design as interpreted What was really
by Project B. by Project C. needed.
- -
Requirements Design Compliance Page 23
24. CxP PDR Architecture Metrics - Example
Cx Architecture Requirement Owner Green Yellow Red TOTAL
DIO (Architecture Integration) 2 1 3
Environments & Constraints 7 1 8
Flight Performance 10 2 12
Ground and Mission Operations 17 3 1 21
Human Systems 1 1
Integrated Systems Performance 2 4 6
Integrated Loads, Structures and Mechanisms 4 2 1 7
Integrated Power 1 1
Integrated Thermal/ECLSS 1 2 3
Software and Avionics 16 8 2 26
Safety, Reliability & Quality Assurance 2 2 4
Supportability, Operability, and Affordability 3 3
TOTAL CORE REQUIREMENTS 58 32 5 95
Color Definition
Green Compliant
Yellow Watch items
Red Non-compliant
Requirements Design Compliance Page 24
25. Requirements Design Compliance (RDC) Lifecycle
Customer
Constellation
E&C SIG Program,
NASA
Headquarters
FP SIG
PDR Products
HSIG
Projects ILSM
RIDs SIG Official Path of Projects
GS Issue Resolution
Power GS
Orion SIG
SIG/Project Community Orion
EVA of Practice Efforts Level II
SOA SIG Actions
EVA
Altair
T/ECLSS SIG/Project Community Altair
Ares SIG of Practice Efforts
Level III
PDR Ares
MS RIDs
Analysis Cycles GMO Board
SIG Actions MS
SR&QA
Analyses
Risks
SAVIO
DIO
HTI
Weekly RDC
ASET
Planning Meeting GOAL
To objectively determine if the preliminary design
can be expected to meet requirements to an
acceptable level of risk.
Requirements Design Compliance Page 25
26. NASA Center and Project Locations
Requirements Design Compliance Page 26
Editor's Notes
Message – quick chart to show the Constellation system of system organization for audience context on presentation
Message – Standard system engineering requirement flow down and decomposition is assumed for any system of system and we were the same.
Message – RDC relies on a lot of sources of data – Projects design data, architectural analyses, etc. – Output is reporting to milestone criteria and more importantly issues to be solved.
#1 I did not develop this chart. But thanks to whoever did. I shamelessly stole it from one of the Program web pages and pasted it here. I wanted it in this pitch just to give Some perspective on all of the program elements being worked on at the various centers across the country