This document discusses NASA's efforts to develop common processes across centers for project management in accordance with NASA Procedural Requirements (NPRs). It notes that while centers share the goal of NPR compliance, their organizational structures differ. Two centers, GRC and MSFC, are working to define standard processes focused on the organization rather than individual projects. GRC has organized efforts since 2007, developing requirements and obtaining buy-in, while MSFC's efforts began in 2008 by building on GRC's work. The goals are to improve planning and estimates, create standard tools and templates, and institutionalize best practices across centers.
The document discusses the development of guidance material to help NASA implement its software engineering requirements and best practices. It describes:
1) The creation of an electronic handbook on the NASA Engineering Network to provide guidance on NASA's software engineering requirements and examples/templates.
2) The process of gathering input from NASA's software community, prioritizing topics, and developing the content for the handbook.
3) The benefits of an electronic handbook such as easy updating and searchability.
POLARIS is a web-based tool developed by NASA to help project managers access information and requirements related to project management. It provides a searchable database of NASA's project management requirements and templates. Future enhancements may include additional requirements, review content, and linking the tool to NASA's metadata database to integrate more project information. The tool aims to be continually improved based on user feedback to better support NASA's project management community.
The document discusses lessons learned from turbulence experienced during a NASA aeronautics research project. Key points include: a new project manager was selected who was unfamiliar with the role and processes, which led to leadership issues; the program was undergoing changes that created an unclear vision and shifting requirements, adding turbulence; clear communication between project leadership and open discussion of challenges is important for navigating periods of turbulence; selecting candidates well-suited for open roles and providing needed training and mentoring can help address issues that arise.
The document provides an overview of NASA's policy for independent program reviews:
1. NASA policy mandates independent reviews at key decision points to validate programs' readiness and identify risks. This includes NPD 1000.0 requiring checks and balances like independent reviews.
2. The Standing Review Board process in NPR 7120.5 standardizes independent reviews across NASA. Reviews assess technical and programmatic status at life cycle milestones.
3. The SRB Handbook provides guidance for Standing Review Boards to apply review criteria consistently across programs in accordance with NASA's technical and program management requirements. It outlines the roles, processes, and expected work products for the reviews.
This document summarizes the findings of a NASA survey of various centers regarding compliance with Office of the Chief Engineer (OCE) policy. It describes the survey objectives, methodology, elements reviewed, and schedule. Some key findings included inconsistent implementation of configuration management, risk management, and technical authority across centers. Strengths identified included lessons learned processes and software engineering at JPL. Opportunities for improvement included updating directives, validating Earned Value Management Systems, and clarifying the roles of technical authority and systems engineering.
The document discusses upcoming changes to NASA's independent review policies and processes. Some of the key changes include standardizing terms of reference, implementing a 1-step or 2-step review timeline, updating required lifecycle products, revising review criteria and maturity tables, and changes to review team composition and decision memos. The changes aim to improve the effectiveness and efficiency of NASA's review processes.
The document discusses an update to NASA's software engineering requirements in NPR 7150.2. It provides an overview of the topics to be covered, including the NPD/NPR architecture, lessons learned from the previous NPR, updates to NPR 7150.2, and future work. It then summarizes lessons learned from developing the original NPR 7150.2, such as forming a strong core team, selecting the target audience wisely, understanding where the NPR fits in directives, setting inclusion/exclusion criteria early, and getting professional help. The document outlines changes between the 2004 and 2009 versions, including some added and deleted requirements. It concludes by noting innovations incorporated in the updated NPR 7150.2
This document provides an overview of project scheduling from NASA's perspective. It discusses NASA's large, complex projects and the requirements for project scheduling. The presentation covers key project scheduling processes including activity definition, sequencing, duration estimating, schedule development, status accounting, and performance reporting. It provides examples and definitions for these processes. The goal is to give attendees a basic understanding of project scheduling as it relates to NASA projects.
The document discusses the development of guidance material to help NASA implement its software engineering requirements and best practices. It describes:
1) The creation of an electronic handbook on the NASA Engineering Network to provide guidance on NASA's software engineering requirements and examples/templates.
2) The process of gathering input from NASA's software community, prioritizing topics, and developing the content for the handbook.
3) The benefits of an electronic handbook such as easy updating and searchability.
POLARIS is a web-based tool developed by NASA to help project managers access information and requirements related to project management. It provides a searchable database of NASA's project management requirements and templates. Future enhancements may include additional requirements, review content, and linking the tool to NASA's metadata database to integrate more project information. The tool aims to be continually improved based on user feedback to better support NASA's project management community.
The document discusses lessons learned from turbulence experienced during a NASA aeronautics research project. Key points include: a new project manager was selected who was unfamiliar with the role and processes, which led to leadership issues; the program was undergoing changes that created an unclear vision and shifting requirements, adding turbulence; clear communication between project leadership and open discussion of challenges is important for navigating periods of turbulence; selecting candidates well-suited for open roles and providing needed training and mentoring can help address issues that arise.
The document provides an overview of NASA's policy for independent program reviews:
1. NASA policy mandates independent reviews at key decision points to validate programs' readiness and identify risks. This includes NPD 1000.0 requiring checks and balances like independent reviews.
2. The Standing Review Board process in NPR 7120.5 standardizes independent reviews across NASA. Reviews assess technical and programmatic status at life cycle milestones.
3. The SRB Handbook provides guidance for Standing Review Boards to apply review criteria consistently across programs in accordance with NASA's technical and program management requirements. It outlines the roles, processes, and expected work products for the reviews.
This document summarizes the findings of a NASA survey of various centers regarding compliance with Office of the Chief Engineer (OCE) policy. It describes the survey objectives, methodology, elements reviewed, and schedule. Some key findings included inconsistent implementation of configuration management, risk management, and technical authority across centers. Strengths identified included lessons learned processes and software engineering at JPL. Opportunities for improvement included updating directives, validating Earned Value Management Systems, and clarifying the roles of technical authority and systems engineering.
The document discusses upcoming changes to NASA's independent review policies and processes. Some of the key changes include standardizing terms of reference, implementing a 1-step or 2-step review timeline, updating required lifecycle products, revising review criteria and maturity tables, and changes to review team composition and decision memos. The changes aim to improve the effectiveness and efficiency of NASA's review processes.
The document discusses an update to NASA's software engineering requirements in NPR 7150.2. It provides an overview of the topics to be covered, including the NPD/NPR architecture, lessons learned from the previous NPR, updates to NPR 7150.2, and future work. It then summarizes lessons learned from developing the original NPR 7150.2, such as forming a strong core team, selecting the target audience wisely, understanding where the NPR fits in directives, setting inclusion/exclusion criteria early, and getting professional help. The document outlines changes between the 2004 and 2009 versions, including some added and deleted requirements. It concludes by noting innovations incorporated in the updated NPR 7150.2
This document provides an overview of project scheduling from NASA's perspective. It discusses NASA's large, complex projects and the requirements for project scheduling. The presentation covers key project scheduling processes including activity definition, sequencing, duration estimating, schedule development, status accounting, and performance reporting. It provides examples and definitions for these processes. The goal is to give attendees a basic understanding of project scheduling as it relates to NASA projects.
The NASA Schedule Management Handbook provides guidance on developing and maintaining an integrated master schedule for NASA projects. It outlines roles and responsibilities, considerations for schedule management tools, and processes for pre-schedule development, developing the integrated master schedule, and ongoing status updates and maintenance. The handbook aims to help project managers and teams adhere to NASA requirements for sound schedule management practices.
The document describes NASA's Baseline Performance Review (BPR) process. The BPR provides NASA senior leadership with objective information on the performance of NASA programs, projects, and operations relative to their baseline plans. It aims to identify performance trends, issues, and risks. The BPR involves monthly reporting from Mission Directorates and support offices. Independent assessors evaluate performance metrics. The BPR process helps improve communication, identify cross-cutting issues, and inform decision-making.
Blythe ortiz7120 5e handbooks 2 15-2012 finalNASAPMC
This document discusses updates to NASA guidance documents for program and project management. The NPR 7120.5 has been streamlined and implementation guidance is now contained in a new Program and Project Management Handbook and an updated Standing Review Board Handbook. These handbooks provide best practices and guidelines to implement the requirements of NPR 7120.5. The speakers discuss the status and future plans for completing these handbooks, including aligning them with the revised NPR 7120.5E set to be released in summer 2012. The handbooks are intended to provide practical support for program/project managers in satisfying NASA's management requirements.
The document summarizes changes made in the latest revisions of two NASA policy documents: NPR 7120.5 Rev E regarding space flight programs and projects, and NPR 7120.7 regarding IT and infrastructure. For NPR 7120.5 Rev E, key changes included streamlining requirements, establishing clear objectives for project reviews, and empowering project managers. Major topics of change in the latest revision included applicability, tailoring, compliance matrices, and project formulation agreements. The document provides an overview of the objectives and history of revisions to both policy documents.
The document discusses how configuration management (CM) helps projects innovate and communicate. It compares project management and CM processes, and describes traditional CM versus CM II approaches. It also outlines two project management models - Kepner-Tregoe and Deming's Plan-Do-Check-Act cycle. CM expands on these models by managing both requirements definition and physical project tasks in synchronized cycles. The document argues that CM helps address common problems that cause project failures, such as poor communication, requirements, documentation, and change control. CM is positioned to support the entire project management process.
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 discusses the process for developing Joint Confidence Level (JCL) assessments of cost and schedule estimates for programs and projects. It outlines the roles of programs/projects and the independent review board (SRB) in developing probabilistic cost estimates, risk analyses, and JCL assessments to present at key decision points. Both the program/project and SRB will develop their own analyses, then reconcile differences through iterative reviews and updates until agreeing on a final JCL assessment to report out. The goal is for estimates to have a 70% confidence level that costs and schedules will be equal to or less than predicted.
The document summarizes an NSC Audits and Assessments Workshop from September 2009-2010. It discusses the background and purpose of different types of NASA safety audits conducted by the NSC Audits and Assessments Office. The document analyzes audit findings from 2007-2010 and identifies potential systemic safety issues across multiple NASA centers, particularly in electrical safety, inspection records, and probabilistic risk assessment. Action plans were developed to address these issues and improve safety audit processes.
The document discusses establishing a performance measurement baseline (PMB) in a cost effective manner. It defines key Earned Value Management (EVM) concepts like the PMB, which is a time-phased budget plan used to measure contract performance. It emphasizes the importance of thorough upfront planning, including developing a work breakdown structure (WBS) and schedule to fully capture the work scope. Establishing the PMB is a three-step process of defining the work, scheduling it, and allocating budgets to control accounts and work packages.
The document describes a proposed task tracking portal that would allow NASA project managers and team members to easily track tasks, assignments, and status. It would provide a simple interface with pre-defined reporting functionality. The tool would standardize input and provide on-demand, automatically generated reports. This would help improve coordination, schedules, and availability of project metrics for management. Examples of the portal's prototype displays are provided, including charts and matrices.
The document discusses NASA's plans to replace aging facilities through its Renovation by Replacement (RbR) program. It analyzes two RbR projects: the NASA Ames Sustainability Base and the Langley New Town AOB1 facility. For the NASA Ames project, the key factors for project initiation success were establishing a compelling business case, incorporating NASA technologies, and meeting tight budget and schedule goals of $26 million by July 2009.
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 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 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 discusses a presentation given at the NASA PM Challenge 2011 conference on scheduling challenges and opportunities at NASA. The presentation covered establishing a NASA Planning & Scheduling Community of Practice to share best practices, scheduling tools and resources available from NASA, hot topics in NASA project scheduling, and how to continuously improve NASA's approach to scheduling. The goal is to have an open dialogue on how to strengthen NASA's scheduling processes.
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.
The document discusses the importance of establishing an integrated cost and schedule baseline in the earned value management process. It describes a systematic planning process involving multiple phases that results in key planning documents and an integrated baseline. The planning process involves defining the project scope, organizing the work breakdown structure, scheduling tasks, estimating costs, and negotiating and approving the performance measurement baseline.
The document discusses a project management approach to source evaluation boards (SEBs) being implemented at NASA's Johnson Space Center. It aims to align SEB processes with project management principles by treating each SEB like a project, focusing on requirements, scheduling, teamwork, and control. Feedback from industry and assessments identified issues like unclear processes and schedules. The new approach establishes common vocabulary, templates, and training to bring more consistency to SEBs handled as projects.
This document provides an overview of NASA's Joint Cost and Schedule Confidence Level (JCL) policy and its implementation status across various NASA programs and projects. Key points include:
1) The JCL policy aims to provide stronger assurance that NASA can meet cost and schedule targets and be more transparent about impacts of funding changes.
2) Programs are implementing JCLs with guidance from a working group. Some programs have completed JCLs while others are in process.
3) Developing integrated schedules, assigning probabilities and uncertainties, and producing the JCL models requires significant time and resources from project teams.
4) Next steps include exploring alternative JCL calculation methods, publishing uncertainty guidelines, and developing
This document outlines improvements made to NASA's independent program review process in fiscal year 2010. It discusses the reviews completed, including 8 program and 20 project reviews. Process improvements included quick look reports, increased coordination, readiness assessments, and streamlining of review documentation. The roles and responsibilities of review board members are covered, including ensuring member competency, currency, and independence. Coordination between review boards and NASA mission directorates and centers is also summarized.
1. Define clear program needs, objectives, and constraints up front, including safety, to guide subsequent work.
2. Organize the program with a safety focus, clear management structure, and responsibilities.
3. Specify safety and reliability through fault tolerance, failure probability bounds, and proven practices/standards.
The NASA Schedule Management Handbook provides guidance on developing and maintaining an integrated master schedule for NASA projects. It outlines roles and responsibilities, considerations for schedule management tools, and processes for pre-schedule development, developing the integrated master schedule, and ongoing status updates and maintenance. The handbook aims to help project managers and teams adhere to NASA requirements for sound schedule management practices.
The document describes NASA's Baseline Performance Review (BPR) process. The BPR provides NASA senior leadership with objective information on the performance of NASA programs, projects, and operations relative to their baseline plans. It aims to identify performance trends, issues, and risks. The BPR involves monthly reporting from Mission Directorates and support offices. Independent assessors evaluate performance metrics. The BPR process helps improve communication, identify cross-cutting issues, and inform decision-making.
Blythe ortiz7120 5e handbooks 2 15-2012 finalNASAPMC
This document discusses updates to NASA guidance documents for program and project management. The NPR 7120.5 has been streamlined and implementation guidance is now contained in a new Program and Project Management Handbook and an updated Standing Review Board Handbook. These handbooks provide best practices and guidelines to implement the requirements of NPR 7120.5. The speakers discuss the status and future plans for completing these handbooks, including aligning them with the revised NPR 7120.5E set to be released in summer 2012. The handbooks are intended to provide practical support for program/project managers in satisfying NASA's management requirements.
The document summarizes changes made in the latest revisions of two NASA policy documents: NPR 7120.5 Rev E regarding space flight programs and projects, and NPR 7120.7 regarding IT and infrastructure. For NPR 7120.5 Rev E, key changes included streamlining requirements, establishing clear objectives for project reviews, and empowering project managers. Major topics of change in the latest revision included applicability, tailoring, compliance matrices, and project formulation agreements. The document provides an overview of the objectives and history of revisions to both policy documents.
The document discusses how configuration management (CM) helps projects innovate and communicate. It compares project management and CM processes, and describes traditional CM versus CM II approaches. It also outlines two project management models - Kepner-Tregoe and Deming's Plan-Do-Check-Act cycle. CM expands on these models by managing both requirements definition and physical project tasks in synchronized cycles. The document argues that CM helps address common problems that cause project failures, such as poor communication, requirements, documentation, and change control. CM is positioned to support the entire project management process.
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 discusses the process for developing Joint Confidence Level (JCL) assessments of cost and schedule estimates for programs and projects. It outlines the roles of programs/projects and the independent review board (SRB) in developing probabilistic cost estimates, risk analyses, and JCL assessments to present at key decision points. Both the program/project and SRB will develop their own analyses, then reconcile differences through iterative reviews and updates until agreeing on a final JCL assessment to report out. The goal is for estimates to have a 70% confidence level that costs and schedules will be equal to or less than predicted.
The document summarizes an NSC Audits and Assessments Workshop from September 2009-2010. It discusses the background and purpose of different types of NASA safety audits conducted by the NSC Audits and Assessments Office. The document analyzes audit findings from 2007-2010 and identifies potential systemic safety issues across multiple NASA centers, particularly in electrical safety, inspection records, and probabilistic risk assessment. Action plans were developed to address these issues and improve safety audit processes.
The document discusses establishing a performance measurement baseline (PMB) in a cost effective manner. It defines key Earned Value Management (EVM) concepts like the PMB, which is a time-phased budget plan used to measure contract performance. It emphasizes the importance of thorough upfront planning, including developing a work breakdown structure (WBS) and schedule to fully capture the work scope. Establishing the PMB is a three-step process of defining the work, scheduling it, and allocating budgets to control accounts and work packages.
The document describes a proposed task tracking portal that would allow NASA project managers and team members to easily track tasks, assignments, and status. It would provide a simple interface with pre-defined reporting functionality. The tool would standardize input and provide on-demand, automatically generated reports. This would help improve coordination, schedules, and availability of project metrics for management. Examples of the portal's prototype displays are provided, including charts and matrices.
The document discusses NASA's plans to replace aging facilities through its Renovation by Replacement (RbR) program. It analyzes two RbR projects: the NASA Ames Sustainability Base and the Langley New Town AOB1 facility. For the NASA Ames project, the key factors for project initiation success were establishing a compelling business case, incorporating NASA technologies, and meeting tight budget and schedule goals of $26 million by July 2009.
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 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 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 discusses a presentation given at the NASA PM Challenge 2011 conference on scheduling challenges and opportunities at NASA. The presentation covered establishing a NASA Planning & Scheduling Community of Practice to share best practices, scheduling tools and resources available from NASA, hot topics in NASA project scheduling, and how to continuously improve NASA's approach to scheduling. The goal is to have an open dialogue on how to strengthen NASA's scheduling processes.
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.
The document discusses the importance of establishing an integrated cost and schedule baseline in the earned value management process. It describes a systematic planning process involving multiple phases that results in key planning documents and an integrated baseline. The planning process involves defining the project scope, organizing the work breakdown structure, scheduling tasks, estimating costs, and negotiating and approving the performance measurement baseline.
The document discusses a project management approach to source evaluation boards (SEBs) being implemented at NASA's Johnson Space Center. It aims to align SEB processes with project management principles by treating each SEB like a project, focusing on requirements, scheduling, teamwork, and control. Feedback from industry and assessments identified issues like unclear processes and schedules. The new approach establishes common vocabulary, templates, and training to bring more consistency to SEBs handled as projects.
This document provides an overview of NASA's Joint Cost and Schedule Confidence Level (JCL) policy and its implementation status across various NASA programs and projects. Key points include:
1) The JCL policy aims to provide stronger assurance that NASA can meet cost and schedule targets and be more transparent about impacts of funding changes.
2) Programs are implementing JCLs with guidance from a working group. Some programs have completed JCLs while others are in process.
3) Developing integrated schedules, assigning probabilities and uncertainties, and producing the JCL models requires significant time and resources from project teams.
4) Next steps include exploring alternative JCL calculation methods, publishing uncertainty guidelines, and developing
This document outlines improvements made to NASA's independent program review process in fiscal year 2010. It discusses the reviews completed, including 8 program and 20 project reviews. Process improvements included quick look reports, increased coordination, readiness assessments, and streamlining of review documentation. The roles and responsibilities of review board members are covered, including ensuring member competency, currency, and independence. Coordination between review boards and NASA mission directorates and centers is also summarized.
1. Define clear program needs, objectives, and constraints up front, including safety, to guide subsequent work.
2. Organize the program with a safety focus, clear management structure, and responsibilities.
3. Specify safety and reliability through fault tolerance, failure probability bounds, and proven practices/standards.
This document summarizes a presentation about lessons learned from NASA's Stardust comet sample return mission. The Stardust mission returned the first solid samples from a comet in 2006. Key lessons included the value of detailed pre-flight measurements and instrumentation that were not included due to budget and schedule constraints. Future missions could benefit from more proactive "planning for learning" approaches rather than just reactive "lessons learned." Careful recovery operations are also important for preserving samples and data about the heatshield's condition upon reentry.
The document discusses building communities of engineers to share technical expertise. It describes how NASA has established communities of practice on the NASA Engineering Network to facilitate knowledge sharing across distributed engineering disciplines. Specifically, it provides examples of communities of practice in fault management and autonomous rendezvous and docking that bring together experts from across NASA to collaborate on challenges in those fields.
This document discusses increasing the robustness of flight project concepts. It proposes several improvements and innovations, including establishing new concept maturity levels (CML) to better communicate a concept's readiness. A new P4 document is suggested to provide requirements and guidelines for incorporating and evaluating a concept's robustness. Additional proposed enhancements involve new tools and templates, increased project team support, organizational changes, and training for the pre-phase A community. The overall goal is to address current challenges around assessing risks, communicating maturity, and guidelines for robustness evaluations in NASA's competitive funding environment.
This cycle represents the ongoing process of leadership. A leader continually refines their vision, sets goals aligned with that vision, plans concrete steps to achieve those goals, takes action by working diligently, and seeks counsel from others to improve. Repeating this cycle allows the leader to continuously learn and grow in their abilities.
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 describes the Space Shuttle Systems Engineering processes used to mitigate risks from debris during launch (liftoff debris). Key aspects of the process include implementing requirements and controls to understand, limit, and disposition debris hazards. Technical boards and teams integrate skills and resources to characterize debris, assess risks, and implement repairs or other mitigations to control risks and improve safety.
Phoenix was a Mars lander mission conceived to study water ice discovered at the Martian poles. It landed successfully in May 2008 in the northern polar region to examine the potential for life. Key objectives were to determine if water ice had melted, analyze soil chemistry and nutrients, and study climate change indicators. The lander used pulsed thrusters for precision landing and deployed instruments like cameras, a robotic arm, and chemistry labs to analyze soil and ice samples. Initial images showed a flat terrain suitable for studying Martian polar geology and potential habitability.
The Constellation Program is transitioning from defining requirements to preliminary design and development of hardware and software for its systems. It leverages a nationwide team from NASA and industry. This team is focused on designing and incrementally integrating and verifying a set of increasingly capable systems over the next decade to meet exploration goals of completing the ISS, retiring the Shuttle, developing Orion and Ares launch vehicles, and returning to the Moon by 2020.
This document summarizes Insight Web Services & Portal Integration. It discusses C/S Solutions' products for business intelligence and project management tools. Key points include that C/S Solutions has been in business since 1993, their tools are used on most government programs, and their wInsight product has over 40,000 users worldwide in industries like aerospace, IT, and government. Sample customers are listed and screenshots of the desktop and web applications are provided. The benefits of using their portal solution for integration and collaboration are also highlighted.
The document discusses essential planning steps for small projects with limited budgets. It recommends thoroughly planning work at the lowest level using a work breakdown structure to capture all technical scope, resources, milestones, and descriptions. Automated tools should be used to consolidate this planning data and enable analysis of things like what work is being done at each organization. Maintaining accurate and up-to-date planning data is important for project management and cross-checks between elements like budget and schedule. Communication is also key when changes are made to planning processes or formats.
This document discusses software measurement and selecting useful measures. It provides examples of measures that NASA software managers have found useful, including measures tracking progress, functionality, quality, requirements, staffing and more. The document emphasizes selecting measures that help manage projects by answering questions and providing early warnings of potential issues.
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 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.
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 the importance of healthy skepticism in NASA program management. It argues that skepticism leads to mission success, safety, integrity and excellence. While cynicism questions people, skepticism questions analyses and assumptions without being personally critical. The document provides examples of healthy skepticism, such as asking analysts to explain uncertainties and verifying hazard controls. It concludes that the system must support skeptics by making rationales for procedures readily available.
The document summarizes lessons learned from NASA's Breakthrough Propulsion Physics Project from 1996 to 2002. The project investigated concepts like gravity control and faster-than-light travel by assessing 10 approaches. It produced 16 journal articles, an award-winning website, and positive media coverage for NASA, all for a total cost of $1.6 million. The key tactic was to combine visionary goals with rigorous research methods. Some lessons included pursuing divergent options through small, incremental tasks; publishing all results; and linking research to goals and credible foundations through a "traceability map." The project tactfully distinguished crackpot ideas from visionary concepts worth exploring further.
This document summarizes lessons learned from NASA's experience with pursuing LEED certification for construction projects. It discusses the importance of including all relevant team members, understanding what motivates each person, and maintaining commitment. Technical lessons involve thoroughly researching new building technologies before using them and paying close attention to details with complex systems. Contractual lessons relate to specifying requirements early to avoid costs and delays.
This document summarizes the findings of a NASA survey of various centers regarding compliance with Office of the Chief Engineer (OCE) policy. It describes the survey objectives, methodology, elements reviewed, and schedule. Some key findings included inconsistent implementation of configuration management, risk management, and technical authority across centers. Strengths identified included lessons learned processes and software engineering at JPL. Opportunities for improvement included updating directives, validating Earned Value Management Systems, and clarifying the roles of technical authority and systems engineering.
This document discusses the challenges of partnering on major research platforms and facilities. It notes that the high costs and complexity of such projects have driven increased partnering between U.S. agencies and with international entities. However, ensuring alignment between partner processes and practices can be challenging. The document analyzes the practices of three science agencies - DOE, NASA, and NSF - to identify similarities and differences in their approaches to developing and managing large science projects. Understanding these comparative practices is important for facilitating effective interagency and international cooperation on major research infrastructure initiatives.
This document discusses the challenges of partnering on major research platforms and facilities. It notes that the high costs and complexity of such projects have driven increased partnering between U.S. agencies and with international entities. However, ensuring alignment between partner processes and practices can be challenging. The document analyzes the practices of three science agencies - DOE, NASA, and NSF - to identify similarities and differences in their approaches to developing and managing large science projects. Understanding these comparative practices is important for facilitating effective interagency and international cooperation on major research infrastructure initiatives.
This document summarizes a presentation given by Toshi Mukai of JAXA on the challenges of international space projects. Mukai discusses lessons learned from successful US-Japan collaborations on space science missions like GEOTAIL. He emphasizes that both parties must share the goal of finding overall optimal solutions, recognize and respect differences in culture, and build trust between partners. Developing mutual understanding and establishing trust were cited as critical factors for the GEOTAIL program's outstanding success.
The document summarizes the establishment of an IT Program Management Office (PMO) at NASA's Goddard Space Flight Center. It discusses how the CIO proposed transforming IT management to increase consolidation and standardization. An Information Management Council and CIO Technical Advisory Committee were formed. The PMO was created to lead IT projects using consistent project management practices and provide oversight of projects. It aims to improve outcomes, grow project managers, and support customers.
A matrix organization structure combines functional and project-based organization to balance specialized expertise and project accountability. However, it can also lead to role confusion, conflicting goals, and duplication of work between line managers and project managers. The line manager is responsible for organizational goals, resources, external relationships, and staff development, while maintaining awareness of customer needs. Effective collaboration between line managers and project managers is needed to overcome challenges in the matrix structure.
The document outlines the mission of the Launch Services Program at NASA's Kennedy Space Center, which provides support for spacecraft throughout their lifecycle including mission planning, engineering, manufacturing, launch site operations, and post-launch operations. The LSP interfaces with other NASA centers and provides support for over 50 successful launches including recent missions like THEMIS, MMS, JUNO, and upcoming ones such as MSL, LRO, and JWST.
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 also describes the healthy tension between the Ares I-X Mission Management Office, which prioritized an aggressive schedule, and the Technical Authorities, which emphasized safety. This tension was instrumental to the flight test's success by helping balance priorities. The document also outlines NASA's governance model, which separates programmatic and technical authorities to provide checks and balances, and how this model was implemented for Ares I-X.
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 document provides an overview of the HandSimDroid project. It includes an agenda for a meeting covering the project overview, process, requirements, risk management, system architecture, next steps, and accomplishments. The team used the Team Software Process and developed requirements, risk management plans, architectural diagrams, and plans to move forward with additional training, prototyping, and formalizing the project scope. They discussed accomplishments from the first part of the project and took questions.
The document discusses the role of in-house consulting at NASA. It proposes that staff offices at NASA centers can take on the perspective of internal consultants by understanding project manager needs, interpreting policies, developing expertise, and providing ongoing support. This would help staff offices maintain relevance and justify their roles, rather than focusing only on processes. Examples are provided of how NASA Goddard's Policy and Standards Office takes a consulting approach to activities like Integrated Baseline Reviews. Potential benefits include improved consistency, training, and cultural alignment across NASA. Risks of undesirable roles like being an "enforcer" or "going native" are also discussed.
The document describes a project management toolkit developed by NASA Glenn Research Center to help with space flight projects. The toolkit provides a collection of standardized project planning and management tools accessible through a web portal. It aims to facilitate rigorous and compliant project proposal, planning, execution, and control according to NASA requirements and best practices. The development of the operational toolkit was driven by a strategic goal of delivering project management excellence for successful customer missions.
The document discusses integrated testing plans for the Constellation program at KSC. It describes plans to conduct Multi-Element Integrated Tests (MEITs) to test interactions between Constellation flight elements launched on different vehicles before they are integrated in space. MEITs found significant problems in previous programs that could have impacted safety and mission objectives. The tests are intended to reduce risks by identifying issues early.
The document discusses NASA's independent review process for programs and projects. It aims to ensure the highest probability of mission success. Key points:
1. Independent reviews are conducted by Standing Review Boards at each project life-cycle milestone to objectively assess technical approach, schedule, resources, risk, and management approach.
2. Reviews provide independent validation of projects' readiness to proceed and reassure stakeholders that commitments can be delivered. Preparing for reviews allows holistic project examination.
3. Reviews follow NASA governance involving senior management, technical authorities, and decision authorities. Standing Review Boards comprised of independent experts conduct the actual reviews.
4. The process helps ensure projects receive independent assurance they are on
This document discusses the challenges faced during an engineering career at ISRO. It describes shifts from technical to project management roles and the skills required, such as people management, breadth of understanding, and optimal resource utilization. Key challenges included paradigm shifts in job descriptions, cultural differences between laboratory and management environments, and balancing advisory and line functions through coordination and demonstration.
The document discusses challenges faced in re-engineering the Mission Operations Directorate's (MOD) Flight Production Process (FPP). Key challenges include: 1) Building support for adopting Model Based Systems Engineering (MBSE) and Enterprise Architecture (EA) methodologies, 2) Resource limitations, 3) Maintaining management support, and 4) Establishing tools for MBSE and EA development. The FPP must be redesigned as an integrated system to address issues like duplication, data errors, and lack of interoperability between its separate processes for Space Shuttle and ISS programs.
This document outlines a presentation by NASA on adapting project management practices to research-based projects. It discusses the challenges of managing science research using traditional project management techniques due to differences in culture and goals between scientists and project managers. It provides perspectives from both scientists and project managers and examples of how NASA has worked to bridge this gap on human research projects through matrix organizational structures, collaboration between project managers and scientists, and involvement of scientists in requirements development.
Brescia program management_dame-na-pre-0030INAF-OAC
The DAME Program Management Strategy, Tools and Organization document discusses program and project management. It defines a project as a series of time-limited activities with a shared goal, such as creating a new product or service. It describes the key features of projects and the goal of projects to develop unique products or services progressively through a step-by-step process. The document also discusses project management, including defining the scope, schedule, costs, resources, quality, risks, and other aspects of a project. It provides examples of work breakdown structures and phases of project management.
The document provides an outline for contract and construction management. It discusses managing the construction period through 15 activities including organization, planning, survey checks, site organization, construction methods, time control, cost control, quality control, site meetings, progress reports, claims and disputes, completion of works, and inspection of works. It also discusses managing the defects liability period through inspection of works, defects liability certificate, and final certificate. Project controls are discussed including time and cost control through critical path scheduling, float, resources, and progress reporting.
The document discusses the Spacecraft Software Engineering Branch's use of the CMMI models to oversee space flight software development. It provides an overview of the branch's selection of the CMMI-DEV model and definition of projects for a CMMI Maturity Level 2 rating. It also describes the branch's software oversight role for the Orion project, trials in planning software oversight projects, and emphasis on key CMMI process areas like project planning, project monitoring and control, and requirements management for its oversight work.
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.
GridMate - End to end testing is a critical piece to ensure quality and avoid...ThomasParaiso2
End to end testing is a critical piece to ensure quality and avoid regressions. In this session, we share our journey building an E2E testing pipeline for GridMate components (LWC and Aura) using Cypress, JSForce, FakerJS…
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
A tale of scale & speed: How the US Navy is enabling software delivery from l...sonjaschweigert1
Rapid and secure feature delivery is a goal across every application team and every branch of the DoD. The Navy’s DevSecOps platform, Party Barge, has achieved:
- Reduction in onboarding time from 5 weeks to 1 day
- Improved developer experience and productivity through actionable findings and reduction of false positives
- Maintenance of superior security standards and inherent policy enforcement with Authorization to Operate (ATO)
Development teams can ship efficiently and ensure applications are cyber ready for Navy Authorizing Officials (AOs). In this webinar, Sigma Defense and Anchore will give attendees a look behind the scenes and demo secure pipeline automation and security artifacts that speed up application ATO and time to production.
We will cover:
- How to remove silos in DevSecOps
- How to build efficient development pipeline roles and component templates
- How to deliver security artifacts that matter for ATO’s (SBOMs, vulnerability reports, and policy evidence)
- How to streamline operations with automated policy checks on container images
Removing Uninteresting Bytes in Software FuzzingAftab Hussain
Imagine a world where software fuzzing, the process of mutating bytes in test seeds to uncover hidden and erroneous program behaviors, becomes faster and more effective. A lot depends on the initial seeds, which can significantly dictate the trajectory of a fuzzing campaign, particularly in terms of how long it takes to uncover interesting behaviour in your code. We introduce DIAR, a technique designed to speedup fuzzing campaigns by pinpointing and eliminating those uninteresting bytes in the seeds. Picture this: instead of wasting valuable resources on meaningless mutations in large, bloated seeds, DIAR removes the unnecessary bytes, streamlining the entire process.
In this work, we equipped AFL, a popular fuzzer, with DIAR and examined two critical Linux libraries -- Libxml's xmllint, a tool for parsing xml documents, and Binutil's readelf, an essential debugging and security analysis command-line tool used to display detailed information about ELF (Executable and Linkable Format). Our preliminary results show that AFL+DIAR does not only discover new paths more quickly but also achieves higher coverage overall. This work thus showcases how starting with lean and optimized seeds can lead to faster, more comprehensive fuzzing campaigns -- and DIAR helps you find such seeds.
- These are slides of the talk given at IEEE International Conference on Software Testing Verification and Validation Workshop, ICSTW 2022.
How to Get CNIC Information System with Paksim Ga.pptxdanishmna97
Pakdata Cf is a groundbreaking system designed to streamline and facilitate access to CNIC information. This innovative platform leverages advanced technology to provide users with efficient and secure access to their CNIC details.
Unlocking Productivity: Leveraging the Potential of Copilot in Microsoft 365, a presentation by Christoforos Vlachos, Senior Solutions Manager – Modern Workplace, Uni Systems
Essentials of Automations: The Art of Triggers and Actions in FMESafe Software
In this second installment of our Essentials of Automations webinar series, we’ll explore the landscape of triggers and actions, guiding you through the nuances of authoring and adapting workspaces for seamless automations. Gain an understanding of the full spectrum of triggers and actions available in FME, empowering you to enhance your workspaces for efficient automation.
We’ll kick things off by showcasing the most commonly used event-based triggers, introducing you to various automation workflows like manual triggers, schedules, directory watchers, and more. Plus, see how these elements play out in real scenarios.
Whether you’re tweaking your current setup or building from the ground up, this session will arm you with the tools and insights needed to transform your FME usage into a powerhouse of productivity. Join us to discover effective strategies that simplify complex processes, enhancing your productivity and transforming your data management practices with FME. Let’s turn complexity into clarity and make your workspaces work wonders!
Observability Concepts EVERY Developer Should Know -- DeveloperWeek Europe.pdfPaige Cruz
Monitoring and observability aren’t traditionally found in software curriculums and many of us cobble this knowledge together from whatever vendor or ecosystem we were first introduced to and whatever is a part of your current company’s observability stack.
While the dev and ops silo continues to crumble….many organizations still relegate monitoring & observability as the purview of ops, infra and SRE teams. This is a mistake - achieving a highly observable system requires collaboration up and down the stack.
I, a former op, would like to extend an invitation to all application developers to join the observability party will share these foundational concepts to build on:
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
Pushing the limits of ePRTC: 100ns holdover for 100 daysAdtran
At WSTS 2024, Alon Stern explored the topic of parametric holdover and explained how recent research findings can be implemented in real-world PNT networks to achieve 100 nanoseconds of accuracy for up to 100 days.
UiPath Test Automation using UiPath Test Suite series, part 5DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 5. In this session, we will cover CI/CD with devops.
Topics covered:
CI/CD with in UiPath
End-to-end overview of CI/CD pipeline with Azure devops
Speaker:
Lyndsey Byblow, Test Suite Sales Engineer @ UiPath, Inc.
Full-RAG: A modern architecture for hyper-personalizationZilliz
Mike Del Balso, CEO & Co-Founder at Tecton, presents "Full RAG," a novel approach to AI recommendation systems, aiming to push beyond the limitations of traditional models through a deep integration of contextual insights and real-time data, leveraging the Retrieval-Augmented Generation architecture. This talk will outline Full RAG's potential to significantly enhance personalization, address engineering challenges such as data management and model training, and introduce data enrichment with reranking as a key solution. Attendees will gain crucial insights into the importance of hyperpersonalization in AI, the capabilities of Full RAG for advanced personalization, and strategies for managing complex data integrations for deploying cutting-edge AI solutions.
Threats to mobile devices are more prevalent and increasing in scope and complexity. Users of mobile devices desire to take full advantage of the features
available on those devices, but many of the features provide convenience and capability but sacrifice security. This best practices guide outlines steps the users can take to better protect personal devices and information.
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...
Phillip.hall
1. National Aeronautics and Space Administration
Collaborative Multi-Center
Implementation of NPR 7123.1A
Phillip Hall
NASA MSFC
Nancy McNelis
NASA GRC
Used with Permission www.nasa.gov 1
2. National Aeronautics and Space Administration
Can Centers Develop “Common” Processes?
• Common Goal is Compliance with NPRs
– NASA Procedural Requirements Establish “What” NASA
HQ Expects of the Centers
– Center Level Procedural Requirements Establish “How” it is
Done at that Given Center
• Centers Do Not Have Common Organizational
Structure
• NPR 7120 Series is Project Focused, Not
Organizational Focused
The Question Then Becomes …
• Is the Project Structure from Center to Center Similar
Enough to Allow “Common” Processes?
www.nasa.gov 2
3. National Aeronautics and Space Administration
Can Centers Develop “Common” Processes?
Matrix from Space Flight Directorate
Matrix from Engineering Directorate
Matrix from S&MA
WBS01
GRC Typical Project Structure
Project Manager Matrix from Other Directorates
Deputy PM
Project Chief Engineer
WBS03 WBS01
Safety & Mission Assurance Business Support Office
Chief Safety Officer Project Support Staff
WBS02 WBS04 WBS05 WBS (n) WBS (n)
Systems Engineering Element 4 Element 5 Element (n) Element (n)
Lead Systems Eng Element Lead Element Lead Element Lead Element Lead
www.nasa.gov 3
4. National Aeronautics and Space Administration
Can Centers Develop “Common” Processes?
NASA Administrator
Deputy Administrator NASA Chief Engineer
Associate Administrator
MSFC Typical Project Structure
Mission Directorate AA MSFC Center Director
Program Manager MSFC Eng Director
MSFC Eng Deputy MSFC Chief Eng MSFC Eng
Center Discipline Leads
Directors - Senior Eng Manager Dept/Lab Managers
Independent Reviews
Program assigned Management Presence
MSFC Deputy
Program Manager MSFC Program
Chief Eng* MSFC Eng
Division Chiefs
Project Manager MSFC Project
Chief Eng MSFC Eng
Branch Chiefs
Program Authority MSFC Chief Eng
Technical Authority Manager’s Staff
Direct Report
MSFC
Senior Eng Presence Institutional Eng
Independent Reviews
www.nasa.gov 4
5. National Aeronautics and Space Administration
Common Goals
• Comply with NASA Procedural Requirements (“What”)
– Requirements traceability from NPRs to Center Level Procedures
• Provide Sufficient Detail (“How”)
– Outline a Step by Step Process of “How” for Project Execution
– Define Roles and Responsibilities of the Project Teams
– Incorporate Best Practices
– Provide Commonality on How Projects Conduct Business within the
Organization
• Prevent Shelf-ware Mentality
– Provide Forms/Templates for Project Use
• Templates which are Annotated Outlines of Project Documentation
• Forms which are Available Electronically
Develop “Common” Processes for the Organizations
Rather Than on a Program/Project Basis
www.nasa.gov 5
6. National Aeronautics and Space Administration
Achieving Common Goals
Where We’ve Been?
• Minimal Confidence in Project Planning and
Estimates because assumes LOE-based rather than
Task-based
• Lack of “Standard Toolbox”
– Inconsistencies in Deliverables and Products
– Results in a lot of re-work
• Project-by-Project Approach Rather than
Institutionalized
• Unclear Use of Best Practices and Lessons Learned
www.nasa.gov 6
7. National Aeronautics and Space Administration
Achieving Common Goals
Where Are We?
• GRC
– Organized Management Steering Group in 2007
– Defined and Documented Development Approach
– Obtained Executive Sponsorship and Organizational Buy-in
– Began Collaborative Development with MSFC
– Launched the Space Mission Excellence Program for Systems
Engineering in 2006
• MSFC
– Organized Engineering Directorate Management Steering Group in
2008
– Leveraging Work Defined at GRC
– Gaining Executive Sponsorship and Organizational Buy-in
– Working with Office of Strategic Analysis and Communications
(OSAC) to tie into Project Management
– Introduction to the MSFC Systems Engineering Leadership
Development program
www.nasa.gov 7
8. National Aeronautics and Space Administration
GRC Procedural Requirement Documents
GLPR7120.5.10
GRC Space Flight Projects
Center Mgmt (NPR 1400.1)
GRC Development & Implementation
Formulation & Implementation
Requirements SM&A (NPD 8700.1)
GLPD 1410.2 GLPR 1410.1 GLPR 8730.5
GRC Doc GRC Directives Quality System GLPR 8700.4 Safety - Text in Doc -
Management Management Manual Safety & Mission Operations &
Assessment Sustainment
GLPR7120.5.20 GLPR 1410.3 -Text in Doc- GLPR 7120.5.30
Deviations & Waiver Lower Level Center Doc Training Safety & Assurance Requirements (SAR)
Document Mgmt
Quality Assurance Reliability & GLPR 1270.1
Maintainability Corrective &
Preventative
Action
Program/Project Management (NPR 7120.5)
GLPD7120.1 GLHB-B-7120.1 GLPR7120.5.41 GLPR7120.5.43 Text in Doc
EVM EVM System Project Review Acquisition 10 Sections in
Handbook Board GLPR7120.5.10
GLPR7120.5.42 GLPR 7120.0.6 GLPR7120.5.40 GLPR 7123.34
Management Lessons Learned GRC Project and Project Config Item
Reporting Technical Planning & Data
Management
Engineering Management (NPR 7123.1)
GLPR 7123.11 GLPR 7123.12 GLPR 7123.32 GLPR 7120.5.40 GLPR 7123.34 GLPR 7123.34 -Text in Doc- GLPR 7150.1
Requirements Def Design Interface GRC Project and Project Config Item Project Config Item 6 Sections in Software
& Mgmt Solutions Mgmt Technical Planning & Data Management & Data GLPR7120.5.10 Engineering
Management Requirements
GLPR 7123.21 GLPR 7123.22 GLPR 7123.23 GLPR7120.0.4 GLPR 7123.35 GLPR 7123.36 GLPR 7123.37
Product Transition Verification & Implementation & Risk Management Project Technical Engineering Decision Analysis
Validation Integration Reviews Review Board
https://knowledgeshare-in.grc.nasa.gov/eRoom/NASAc1f1/GRCProjectandSERequirementsWebContent
www.nasa.gov 8
9. National Aeronautics and Space Administration
Standard GLPR Architecture
GRC Development & Implementation
Project
Objective
Project Project Project
Requirement Deliverables Results
N PR’s Define
“What”
Process
Processes
Deliverables
Techniques
Templates Work Products
Activities
GL PR’s Forms
Define “How” Concepts
at GRC Tasks Lessons Components
Learned
Best Practices
www.nasa.gov 9
10. National Aeronautics and Space Administration
Standard GLPR Formatting
GRC Development & Implementation
Activity (Sub-chapter level designee)
Grouping of tasks that create a logical
deliverable (or group of deliverables)
Flow chart WITH SWIMLANES
Graphical illustration relationships of the
tasks within an activity
Task (Sub-Sub-chapter level designee)
Title of specific work to be performed
necessary to build the deliverable.
Should follow the Verb-Noun format
Task Descriptor (Letter designee)
Specific description of work performed
necessary to build the deliverable.
• Should begin with the responsible role
Will contain Shall statements if applicable.
Additional Guidance (Not shown)
Addition information provided to help the
responsible person perform this task
www.nasa.gov 10
11. National Aeronautics and Space Administration
GLPR Development Procedure
GRC Development & Implementation
3.1 3.2 3.3 3.4 3.5 3.6
Identify and
Owner Review MSG Executive BMS
Document Peer Review
(CEO, M, Q, etc.) Inspection Presentation Submittal
Procedure
• Identify New • Owner • Peer Review • Formal • Present • Completed
Processes or Reviews is Initiated Inspection Completed GLPR
Revision High Level Process document to submitted to
Process Executives BMS
• Assign • Feedback
Resources • GLPR Provided to • Pilot
Finalized Inspectors Approved
• Use Std Processes
Templates
Success Criteria
• Leverage
SMEs • Owner • MSG Leads • MSG Will • Executive • Formally
Review and Will Determine Awareness Manage
• Draft Process Concur Determine Executive Document
Flow MSG Review
• Pre-MSG Inspection Readiness
• Draft GLPR
Inspection Readiness
Document
Readiness
www.nasa.gov 11
12. National Aeronautics and Space Administration
GLPR Development Status
Review Gates
Owner MSG Executive BMS
GRC Development & Implementation
GLPR # Document Name Peer Review
Review Inspection Review Status
Wave One
7123.36 Engineering Review Board (ERB) Complete Complete Complete Complete GLPR
7123.35 GRC Project Technical Reviews Complete Complete Complete Complete GLPR
GRC Requirement Development and
7123.11 Complete Complete Complete Complete GLID
Management Process
7120.14 Waivers/Deviations Process Complete Complete Complete Complete Not Submitted
7120.5.40 Project and Technical Planning Complete Complete Complete Complete GLPR
7123.22 Product Verification and/or Validation Complete Complete Complete Complete GLID
7123.34 Data and Configuration Management Complete Pending TBD 1/19/10 Not Submitted
7120.5.10 Space Flight Project Requirements Complete Complete Complete Complete GLID
7123.37 Decision Analysis Complete Complete 10/20/09 11/20/09 Not Submitted
7120.5.41 Project Review Board (PRB) Complete Complete Not Applicable Complete GLPR
7120.5.42 Management Reporting Complete 10/30/09 11/16/09 1/14/10 Not Submitted
7123.33 Risk Management Complete Complete KO 12/7 TBD Not Submitted
7120.5.30 Space Assurance Requirements (SAR) Complete Complete Complete Complete GLPR
8700.5 Problem Reporting and Resolution Complete NA NA NA Not Submitted
7123.32 Interface Management TBD TBD TBD TBD Not Submitted
7123.21 Product Transition Wave 3 Wave 3 Wave 3 Wave 3 Not Submitted
7123.23 Product Imp and Integration Wave 3 Wave 3 Wave 3 Wave 3 Not Submitted
7120.xx EVM Wave 3 Wave 3 Wave 3 Wave 3 Not Submitted
7120.5.43 Project Acquisition Wave 3 Wave 3 Wave 3 Wave 3 Not Submitted
7123.12 Design Solutions Wave 3 Wave 3 Wave 3 Wave 3 Not Submitted
7123.41 Design and As-Built Wave 3 Wave 3 Wave 3 Wave 3 Not Submitted
www.nasa.gov 12
13. National Aeronautics and Space Administration
MSFC Doc Tree – Before
NPR 7123.1
NASA Systems Engineering Processes and Requirements
(Requirements [68] / Processes [17] / Best Practices [105] / Reviews [16])
MSFC Development & Implementation
MPR 7123.1 MPR 7123.2
MSFC Systems Engineering Technical Reviews and Review Item Discrepancy (RID)
Processes and Requirements Processing, MSFC Programs and Projects
Requirements [68] / Processes [17] / Best Practices [105] (Reviews [16]) + MSFC RID Process
AS42/Jeff Moore ED10/Phillip Hall PS01/Felecia Wilson ED10/Phillip Hall QD40/William Powell ED11/Amy Hemken ED11/Amy Hemken
MWI 6410.1 MWI 8050.1 MPR 5000.1 MWI 7123.1 MWI 7120.6 MPR 8040.1 MWI 7120.2
Handling, Storage, Verification and Purchasing Reqts Development Prog/Proj Risk Configuration Data Reqt
Packaging, Preserv., Validation of EM03/Patricia Johnson and Management Mangement Management Ident. / Def
and Delivery (HSPPD) Hardware, Software, MPR 1280.2 (5 of 17 Processes) DA01/Mary Demurray ED11/Eugena Goggans
and Ground Support Process Control MPR 1280.1 MWI 7120.4
Equipment for MSFC PS01/Felecia Wilson Management Doc. Prep.
MWI 5100.1 Review Prog/Proj
Initiating Proc. Req.
EI41/Ronie Akins
MWI 1280.1
Mechanical Fab.
Request Instructions
System Design Processes
1 - Stakeholder Expectations Definition Process
2 - Technical Requirements Definition Process
3 - Logical Decomposition Process
*4 - Design Solution Definition Process
We developed 3 MSFC Product Realization Processes
5 - Product Integration Process
documents to fill in the gaps *6 - Product Implementation Process
shown by the initial 7 - Product Verification Process
8 - Product Validation Process
9 - Product Transition Process
compliance analysis Technical Management Processes
*10 - Technical Planning Process
11 - Technical Requirements Management Process
* = 4 additional MWI's needed [4, 6, 10 & 17] 12 - Interface Management Process
13 - Technical Risk Management Process
14 - Configuration Management Process
Existing MWI's replacement [in future]
15 - Technical Data Management Process
16 - Technical Assessment Process
*17 - Decision Analysis Process
www.nasa.gov 13
14. National Aeronautics and Space Administration
MSFC Doc Tree - Proposed
NPR 7123.1
NASA Systems Engineering Processes and Requirements
MSFC Development & Implementation
( Requirements [68] / Processes [17] / Best Practices [105] / Reviews [16] )
MPR 7123.2
MPR 7123.1
Technical Reviews and Review Item Discrepancy (RID)
MSFC Systems Engineering Processes and Requirements
Processing, MSFC Programs and Projects
( Requirements [68] / Processes [17] / Best Practices [105] )
( Reviews [16] ) + MSFC RID Process
MWI 7123.1
MSFC Systems
Engineering Processes
MSE 7123.1 MSE 7123.2 MSE 7123.3 MSE 7123.4 MSE 7123.5 MSE 7123.6 MSE 7123.7 MSE 7123.8 MSE 7123.9
Stakeholder Technical Logical Design Product Product Product Product Product
Expectation Requirement Decomposit’n Solution Implementat’n Integration Verification Validation Transition
Definition s Definition Definitions
System Design Processes Product Realization Processes
MSE 7123.10 MSE 7123.11 MSE 7123.12 MSE 7123.13 MSE 7123.14 MSE 7123.15 MSE 7123.16 MSE 7123.17
Technical Requirement Interface Technical Technical Technical Technical Decision
Planning Management Management Risk Config Data Assessment Analysis
Management Management Managemen
t
Technical Management Processes
Checklists
Specific Practice
Templates
Forms
Roles & Responsibilities
Process Metrics
www.nasa.gov 14
15. National Aeronautics and Space Administration
Content Structure
MWI 7123.1 MSE 7123.1
• MWI 7123.1 will contain information
MSFC Development & Implementation
MWI Groups the 17 NASA SE Engine
SE Processes
common to all MSEs
MSE Process
• MSEs set the standards for complying
1 MSE for each of the
17 SE Processes with NPR 7123.1 requirements
• Process metrics to allow for continuous
MSE 7123.2
improvement
MSE Primary Content Points to Toolboxes
MSE Process Process Overview Specific Practice (steps)
(including R&R)
Process Objectives
• Specific Practices will contain Templates
recommended implementation Process Metrics
guidance
• Augmented by toolbox
Checklists
containing templates &
checklists
• Format allows for seamless
import into SEG
www.nasa.gov 15
16. National Aeronautics and Space Administration
MSFC Procedure
MSFC Development & Implementation
(1) Perform (2) Develop (3) Review (4) Review with (5) Develop
Literature Search Process Flow Process Flow Stakeholders Document
Collect and outline Develop top-level Internal review of Coordinated effort to Develop detailed
industry and SE data flow for the proposed process obtain stakeholder content for the MSE
discipline best MSE and IDEF0 for flow. buy-in on how and Specific
practices. the Specific MSFC is going to Practices.
Practices. proceed in doing
business
(6) Develop (7) Conduct Mgmt (8) Finalize (9) Implement into (10) Submit Doc for
Toolbox Inspection of Doc Document SEG Formal Release
Develop the Conduct internal Incorporate Review Post and make Update SEG, as
associated review within ED10 Team comments content available to required
Templates and and applicable MSFC programs &
Checklists (artifacts) stakeholders (e.g., a projects
pre-established
review team of
SMEs to review and
provide comments
on each MSE before
finalizing
www.nasa.gov 16
17. National Aeronautics and Space Administration
MSFC Systems Engineering Framework
MSFC Development & Implementation
Process Tools Training People Time
National Vision
Human Capital
NPR’s NEN APPEL Mission Needs
Agency NID’s, etc. MBSE NPR Training
Strategy &
Agency Goals
Investments
MSFC DCB, DGA APPEL CMS Center Goals &
RID, ICE
Enterprise Processes UAH, etc. Center Staff Missions Objectives
Safety/Reliability St ARM/IRMA (Risk) Integrated Staff
SMA Specialty
SMA andards Reliability & Other
Courses
w/in Product Life-Cycle
Quality Standards Analytical Tools Programs/Projects
Marshall Inc
ARM/IRMA (Risk)
Programs/
7120 Processes Schedule APPEL Project Offices Product Lifecycle
Projects EVM
SE Leader
7123 SEG, Cradle, Development Engineering
Engineering 17 Processes DOORS Program Directorate
System Lifecycle
APPEL
Domain Processes CAD/Pro-E, EMC,
Line Engineers
Design (Bluebook) MAT Lab APPEL
Lab Personnel
Major Milestones
CDMS, Thermal
Across Centers
www.nasa.gov 17
18. National Aeronautics and Space Administration
Achieving Common Goals
Where Are We? (Continued)
• Establish MOU Between GRC and MSFC Focused at
Developing “Common” Center Level Procedures
• Benefits of the Collaborative Effort Between GRC
and MSFC
– Establishing common terminology and definitions
– Consistency in process steps leading to product and design
solutions with tighter integration
– Consistency in templates and checklists leading to less time
to translate between common products
– Better understanding of process interrelationships, leading to
more efficient analysis of inputs and outputs that support
other teams
– Consistency in the quality of work products or artifacts
– Better understanding of each centers’ governance processes
and associated roles & responsibilities
www.nasa.gov 18
19. National Aeronautics and Space Administration
Achieving Common Goals
Where Are We? (Continued)
• Specific Goals and Objectives of the Collaboration:
– Review of current development processes
– Share development processes and tools
– Provide access to or make center procedural requirement
documents available
– Create a common Project Asset Repository
– Participate in each other’s peer reviews
– Participate in each other’s procedural formal inspections
– Co-develop (and delivery) training, communication,
continuous improvement and plans
www.nasa.gov 19
20. National Aeronautics and Space Administration
Achieving Common Goals
Where Do We Want To Be?
• Institute a Holistic, Systems Approach to Develop
Procedures and Processes within NASA
– Gain Consensus Between Multiple Centers to Accomplish
Common Goals
– Build Sponsorship from the Respective Engineering
Directorates
– Leverage the Collective Intellect Across NASA
– Common workforce development strategies for Systems
Engineering
• Define, Develop and Maintain Consistent Capabilities
and Competencies Across NASA
• Provide Process to NASA Enterprise Architecture
Key to Fostering Future Collaborative
Programs/Projects between NASA Centers
www.nasa.gov 20