Project Lifecycle Reviews
Explore the source record for details and available documents.
Lifecycle Project Reviews↗
SEARCH · Search NASA
Results for “Lifecycle Project Reviews”
Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.
Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.
Engineering Innovations for Exploration Challenges
This slide presentation reviews some of the engineering innovations requirements for the challenges of space exploration which NASA has and will be involved in. It reviews some significant successes in space transportation, exploration and science accomplished during 2009, and it reviews some of the places that are available for exploration in the near term and the specific missions that NASA has assigned to Marshall. It also reviews the project lifecycle management model, that is designed to reduce undefined, but known, risks. It also demonstrates the sustainable long-term program of block upgrades that contribute to long-term success of programs.
Dumbacher, Daniel L.↗
ASK Magazine
Not everyone looks forward to reviews. Dog and pony shows I've heard them called. Exercises in putting together Power Point charts. Other less tasteful descriptions abound, but I won't bother to summarize these. This is a tasteful magazine after all. In this issue, we've assembled a number of articles on the subject of reviews, particularly as they occur in the NASA project world (although we cover the subject from other perspectives too). Veteran NASA Project Manager Marty Davis, in his article Tangled Up in Reviews, writes, "Many people regard reviews as something onerous, but if we can tailor them so that they're not as bad as they have to be, it can be a great benefit to a project manager." Great benefits to the project manager is what you'll find in Marty's story as he describes not only tailoring a single review but the entire lifecycle of reviews in his project. In Jo Gunderson's story, Calling Down the Fire on Yourself, she describes a young NASA Project Manager who does just that because, as he tells her, I needed to know if there was anything that I had overlooked." How he brings fire down on himself at his project review will inspire other young Project Managers, seasoned managers, and anyone else who reads this powerful story. Leave Your Ego at the Door, by Jenny Baer-Reidhart and Ray Morgan, uses reviews to highlight the creative collaboration that existed between NASA and one of its industry partners. The protagonist of this story is a company who took advantage of NASAs expert advice during reviews and accomplished amazing feats as a result. The story also examines how disasters might well have been avoided by two other NASA partners had they been as open-minded as the first company during their reviews. In Roy Malone's story, Standing Offer, a NASA Project Manager describes how he used a crack review team to help him pass a critical certification inspection while he was a Combat Systems Officer in the Navy. Malone invited the reviewers to come back several times so that they would be able to focus in detail on the many areas of the program that would be scrutinized during the certification inspection. These are just a sampling of some of the articles you'll find in this issue of ASK. We believe this issue offers ample evidence that talented Project Managers know how to use reviews to the great benefit of their projects. A talented Project Manager will typically figure out a way to turn any onerous task into a useful learning exercise. These Project Managers demonstrate that the real value of reviews is that they provide a chance to learn something. No dog and pony shows here.
Laufer, Alexander↗
Promoting a Culture of Tailoring for Systems Engineering Policy Expectations
NASA's Marshall Space Flight Center (MSFC) has developed an integrated systems engineering approach to promote a culture of tailoring for program and project policy requirements. MSFC's culture encourages and supports tailoring, with an emphasis on risk-based decision making, for enhanced affordability and efficiency. MSFC's policy structure integrates the various Agency requirements into a single, streamlined implementation approach which serves as a "one-stop-shop" for our programs and projects to follow. The engineers gain an enhanced understanding of policy and technical expectations, as well as lesson's learned from MSFC's history of spaceflight and science missions, to enable them to make appropriate, risk-based tailoring recommendations. The tailoring approach utilizes a standard methodology to classify projects into predefined levels using selected mission and programmatic scaling factors related to risk tolerance. Policy requirements are then selectively applied and tailored, with appropriate rationale, and approved by the governing authorities, to support risk-informed decisions to achieve the desired cost and schedule efficiencies. The policy is further augmented by implementation tools and lifecycle planning aids which help promote and support the cultural shift toward more tailoring. The MSFC Customization Tool is an integrated spreadsheet that ties together everything that projects need to understand, navigate, and tailor the policy. It helps them classify their project, understand the intent of the requirements, determine their tailoring approach, and document the necessary governance approvals. It also helps them plan for and conduct technical reviews throughout the lifecycle. Policy tailoring is thus established as a normal part of project execution, with the tools provided to facilitate and enable the tailoring process. MSFC's approach to changing the culture emphasizes risk-based tailoring of policy to achieve increased flexibility, efficiency, and effectiveness in project execution, while maintaining appropriate rigor to ensure mission success.
Blankenship, Van A.↗
Managing Space Technology Development at NASA
NASA uses a structured process for managing projects that develop advanced space technologies and transition them into the designs of flight systems. The four-part process consists of formulation, approval, implementation, and transition. In the formulation phase, technology needs are derived from mission concept studies, various technical approaches for meeting the technology needs are identified, technical performance goals called Key Performance Parameters (KPPs) are established, and a project plan is developed. Prior to project approval, an Independent Formulation Review is conducted to ensure that the project objectives are aligned with the mission needs, and that the project is well planned to meet the objectives. In the implementation phase, the technology development project matures the technology, and progress towards the KPPs is evaluated in periodic status reviews. Technology Readiness Levels (TRLs) are used throughout the project lifecycle to assess the progress of technology maturation. In the transition phase, technologies that are successful in achieving the required level of maturity are transitioned to a customer for further development, are used in system designs, or are thoroughly documented for resumption of development at a later date. The customer or end-user of the technology is involved in all phases of the technology development process.
Moore, Christopher L.↗
Reusable Rocket Engine Advanced Health Management System. Architecture and Technology Evaluation: Summary
In this study, we proposed an Advanced Health Management System (AHMS) functional architecture and conducted a technology assessment for liquid propellant rocket engine lifecycle health management. The purpose of the AHMS is to improve reusable rocket engine safety and to reduce between-flight maintenance. During the study, past and current reusable rocket engine health management-related projects were reviewed, data structures and health management processes of current rocket engine programs were assessed, and in-depth interviews with rocket engine lifecycle and system experts were conducted. A generic AHMS functional architecture, with primary focus on real-time health monitoring, was developed. Fourteen categories of technology tasks and development needs for implementation of the AHMS were identified, based on the functional architecture and our assessment of current rocket engine programs. Five key technology areas were recommended for immediate development, which (1) would provide immediate benefits to current engine programs, and (2) could be implemented with minimal impact on the current Space Shuttle Main Engine (SSME) and Reusable Launch Vehicle (RLV) engine controllers.
Pettit, C. D.↗
Large project experiences with object-oriented methods and reuse
The SSVTF (Space Station Verification and Training Facility) project is completing the Preliminary Design Review of a large software development using object-oriented methods and systematic reuse. An incremental developmental lifecycle was tailored to provide early feedback and guidance on methods and products, with repeated attention to reuse. Object oriented methods were formally taught and supported by realistic examples. Reuse was readily accepted and planned by the developers. Schedule and budget issues were handled by agreements and work sharing arranged by the developers.
Wessale, William↗
Tool for Human-Systems Integration Assessment: HSI Scorecard
This paper describes the development and rationale for a human-systems integration (HSI) scorecard that can be used in reviews of vehicle specification and design. This tool can be used to assess whether specific HSI related criteria have been met as part of a project milestone or critical event, such as technical reviews, crew station reviews, mockup evaluations, or even review of major plans or processes. Examples of HSI related criteria include Human Performance Capabilities, Health Management, Human System Interfaces, Anthropometry and Biomechanics, and Natural and Induced Environments. The tool is not intended to evaluate requirements compliance and verification, but to review how well the human related systems have been considered for the specific event and to identify gaps and vulnerabilities from an HSI perspective. The scorecard offers common basis, and criteria for discussions among system managers, evaluators, and design engineers. Furthermore, the scorecard items highlight the main areas of system development that need to be followed during system lifecycle. The ratings provide a repeatable quantitative measure to what has been often seen as only subjective commentary. Thus, the scorecard is anticipated to be a useful HSI tool to communicate review results to the institutional and the project office management.
Whitmore, Nihriban↗
Case for Deploying Complex Systems Utilizing Commodity Components
When the International Space Station (ISS) finally reached an operational state, many of the Payload Operations and Integration Facility (POIF) hardware components were reaching end of life, COTS product costs were soaring, and the ISS budget was becoming severely constrained. However, most requirement development was complete. In addition, the ISS program is a fully functioning program with at least fifteen years of operational life remaining. Therefore it is critical that any upgrades, refurbishments, or enhancements be accomplished in realtime with minimal disruptions to service. For these and other reasons, it was necessary to ensure the viability of the POIF. Due to the to the breadth of capability of the POIF (a NASA ground station), it is believed that the lessons to be learned by other complex systems are applicable and any solutions garnered by the POIF are applicable to other complex systems as well. With that in mind, a number of new approaches have been investigated to increase the portability of the POIF and reduce the cost of refurbishment, operations, and maintenance. These new approaches were directed at the Total Cost of Ownership (TCO); not only the refurbishment but also current operational difficulties, licensing, and anticipation of the next refurbishment. Our basic premise is that technology had evolved dramatically since the concept of the POIF ground system and we should leverage our experience on this new technological landscape. Fortunately, Moore's law and market forces have changed the landscape considerably. These changes are manifest in five (5) ways that are particularly relevant to POIF: 1. Complex Instruction Set Computing (CISC) processors have advanced to unprecedented levels of compute capacity with a dramatic cost break, 2. Linux has become a major operating system supported by most vendors on a broad range of platforms, 3. Windows(TradeMark) based desktops are pervasive in the office environment, 4. Stable and affordable WindowsTM development environments and tools are available and offer a rich set of capabilities, 5. The WindowsTM 2000 provides a stable client platform, Therefore, five studies were proposed, developed, and are in the current process of deployment which dramatically reduces the cost of operations, maintenance, refurbishment, and deployment of a ground system. Restating and refining the basic premise stated earlier, it is possible to enhance operations through the replacement of hardware and software components with commodity based items wherever applicable. This will dramatically reduce the overall lifecycle cost of the project. The first study leveraged the POIF S secure, three-tier, web architecture to replace the client workstations with lower cost PC platforms. A second study initiated a review of COTS products to examine the level of added value of each product. This study included replacement of some COTS products with custom code, deletions, substitutions, and consolidation of COTS products. Studies three and four reviewed the server architectures of the data distribution systems and Enhanced HOSC System (EHS) command and telemetry system to propose migration to new platforms, both software and hardware. The final study reviewed current IP communication technologies, developed an operational model for flight operations, and demonstrated that voice over IP was practical and could be integrated into operations.
Bryant, Barry S.↗
The OSIRIS-REx Asteroid Sample Return Mission Operations Design
OSIRIS-REx is an acronym that captures the scientific objectives: Origins, Spectral Interpretation, Resource Identification, and Security-Regolith Explorer. OSIRIS-REx will thoroughly characterize near-Earth asteroid Bennu (Previously known as 1019551999 RQ36). The OSIRIS-REx Asteroid Sample Return Mission delivers its science using five instruments and radio science along with the Touch-And-Go Sample Acquisition Mechanism (TAGSAM). All of the instruments and data analysis techniques have direct heritage from flown planetary missions. The OSIRIS-REx mission employs a methodical, phased approach to ensure success in meeting the mission's science requirements. OSIRIS-REx launches in September 2016, with a backup launch period occurring one year later. Sampling occurs in 2019. The departure burn from Bennu occurs in March 2021. On September 24, 2023, the Sample Return Capsule (SRC) lands at the Utah Test and Training Range (UTTR). Stardust heritage procedures are followed to transport the SRC to Johnson Space Center, where the samples are removed and delivered to the OSIRIS-REx curation facility. After a six-month preliminary examination period the mission will produce a catalog of the returned sample, allowing the worldwide community to request samples for detailed analysis. Traveling and returning a sample from an Asteroid that has not been explored before requires unique operations consideration. The Design Reference Mission (DRM) ties together spacecraft, instrument and operations scenarios. Asteroid Touch and Go (TAG) has various options varying from ground only to fully automated (natural feature tracking). Spacecraft constraints such as thermo and high gain antenna pointing impact the timeline. The mission is sensitive to navigation errors, so a late command update has been implemented. The project implemented lessons learned from other "small body" missions. The key lesson learned was 'expect the unexpected' and implement planning tools early in the lifecycle. This paper summarizes the ground and spacecraft design as presented at OSIRIS-REx Critical Design Review(CDR) held April 2014.
mission operations↗
Engineering America's Future in Space: Systems Engineering Innovations for Sustainable Exploration
This viewgraph presentation reviews systems engineering innovations for Ares I and Ares V launch vehicles. The contents include: 1) NASA's Exploratoin Roadmap; 2) Launch Vehicle Comparisons; 3) Designing the Ares I and Ares V in House; 4) Exploring the Moon; and 5) Systems Engineering Adds Value Throughout the Project Lifecycle.
Dumbacher, Daniel L.↗
Collaborative Systems Engineering in the Ascent Abort-2 Crew Module/Separation Ring Project
Generally speaking, systems engineering (SE) tool-sets face a dilemma balancing power and accessibility. High-powered SE tools (MagicDraw, Cradle, Core, etc.) tend to be specialized and are available only to highly trained Systems Engineers, and/or through the use of a 'back room' developer team making the output products available to the broader team. On the other hand, highly accessible tools (MS Word, Excel, etc.) do not have the power to implement SE in a rigorous manner. NASA has to test all aspects of the new human-rated Orion Multi-Purpose Crew Vehicle spacecraft prior to its first crewed mission. The test program includes uncrewed launch abort flight tests to demonstrate the capability to save the crew in the event that a launch failure occurs. Orion's second abort flight test will be a low-altitude flight test known as "Ascent Abort 2 (AA-2)." This test is currently scheduled to be carried out at Cape Canaveral Air Force Station's Space Launch Complex 46 (SLC-46) in Florida in 2019. NASA's in-house AA-2 Crew Module and Separation Ring (CSR) Team is producing the crew module and separation ring. Operating jointly as both an Advanced Exploration Systems (AES) Project and an Orion Project, the CSR project charter includes development of innovative, streamlined and generally more efficient practices for creation of flight hardware and software. One result of this tasking has been development of a collaborative and data-centric systems engineering environment within the team's shared web environment (Microsoft SharePoint). Through the use of built-in, 'out of the box capabilities' present in MS SharePoint, the CSR Systems Engineering team has created (with some limited developer support) a data-centric architecture for the project's SE implementation, including functional and interface analysis, requirements development and management, risk management, verification planning and management, test results, and end item management. Data elements are linked between data structures so as to define and control relationships between item types, link requirements to parents and children, and link tests to the requirements that they verify. The overall project team integration is increased by also linking SE content to project management content over the project life cycle, including team communication, action items, configuration management, decisional and meeting materials, and life cycle reviews. This presentation will provide an overview of the collaborative SE environment, showing how it provides the power for a number of SE tasks while still providing the accessibility and transparency to allow the full project team to collaborate and succeed. Given the project phase, we'll be able to present a nearly full lifecycle discussion, from concept through verification and approaching delivery.
Systems Engineering environments↗
Advancing the practice of systems engineering at JPL
In FY 2004, JPL launched an initiative to improve the way it practices systems engineering. The Lab's senior management formed the Systems Engineering Advancement (SEA) Project in order to "significantly advance the practice and organizational capabilities of systems engineering at JPL on flight projects and ground support tasks." The scope of the SEA Project includes the systems engineering work performed in all three dimensions of a program, project, or task: 1. the full life-cycle, i.e., concept through end of operations 2. the full depth, i.e., Program, Project, System, Subsystem, Element (SE Levels 1 to 5) 3. the full technical scope, e.g., the flight, ground and launch systems, avionics, power, propulsion, telecommunications, thermal, etc. The initial focus of their efforts defined the following basic systems engineering functions at JPL: systems architecture, requirements management, interface definition, technical resource management, system design and analysis, system verification and validation, risk management, technical peer reviews, design process management and systems engineering task management, They also developed a list of highly valued personal behaviors of systems engineers, and are working to inculcate those behaviors into members of their systems engineering community. The SEA Project is developing products, services, and training to support managers and practitioners throughout the entire system lifecycle. As these are developed, each one needs to be systematically deployed. Hence, the SEA Project developed a deployment process that includes four aspects: infrastructure and operations, communication and outreach, education and training, and consulting support. In addition, the SEA Project has taken a proactive approach to organizational change management and customer relationship management - both concepts and approaches not usually invoked in an engineering environment. This paper'3 describes JPL's approach to advancing the practice of systems engineering at the Lab. It describes the general approach used and how they addressed the three key aspects of change: people, process and technology. It highlights a list of highly valued personal behaviors of systems engineers, discusses the various products, services and training that were developed, describes the deployment approach used, and concludes with several lessons learned.
process improvement↗
Configuration Management Process Assessment Strategy
Purpose: To propose a strategy for assessing the development and effectiveness of configuration management systems within Programs, Projects, and Design Activities performed by technical organizations and their supporting development contractors. Scope: Various entities CM Systems will be assessed dependent on Project Scope (DDT&E), Support Services and Acquisition Agreements. Approach: Model based structured against assessing organizations CM requirements including best practices maturity criteria. The model is tailored to the entity being assessed dependent on their CM system. The assessment approach provides objective feedback to Engineering and Project Management of the observed CM system maturity state versus the ideal state of the configuration management processes and outcomes(system). center dot Identifies strengths and risks versus audit gotcha's (findings/observations). center dot Used "recursively and iteratively" throughout program lifecycle at select points of need. (Typical assessments timing is Post PDR/Post CDR) center dot Ideal state criteria and maturity targets are reviewed with the assessed entity prior to an assessment (Tailoring) and is dependent on the assessed phase of the CM system. center dot Supports exit success criteria for Preliminary and Critical Design Reviews. center dot Gives a comprehensive CM system assessment which ultimately supports configuration verification activities.*
Henry, Thad↗
Modeling NASA’s Procedural Requirement Processes - Implications for Digital Future
The National Aeronautics and Space Administration (NASA) has an ongoing Digital Transformation effort and to leverage and showcase the power of Digital Transformation, an effort is underway to develop an integrated, datacentric, model representing NASA’s key process requirements. The task was divided into three phases: As Is modeling, Analysis, and To Be Planning. As part of this effort, a team has completed the first Phase I of the modeling task and is nearing completion of the second phase. This effort will capture the key elements as requirements, responsibilities, allocations, roles, products, and associated lifecycle elements. The scope of modeling included NASA’s NPR 7120.5 (Project and Program Management), NPR 7123.1 (Systems Engineering) and NPRs 8705.2 (Risk classification for Robotic Missions) and 8705.4 (Human-Rating Requirements for Space Missions). This paper will summarize the approach, scope, parsing patterns applied, metamodel, and associated workflows for the As-Is modeling. It will also summarize the results and insights gleaned during that phase, including the review process. These insights have informed the analysis and will be discussed. The analysis modeling phase will also be summarized including how the stakeholders were engaged, how the common elements were handled and dispositioned, and will also describe some of the plans for the future of NASA NPDs and NPRs.
Systems Engineering↗
Cirrus Cloud Modeling: Overview and Issues
A review of cirrus cloud modeling will be given with special attention to the role of dynamical processes in regulating cloud microphysical properties and the interactions with radiative process in determining cloud lifecycle. The talk will draw heavily on the papers by Starr and Quante, Quante and Starr and Demoz et al., as well as recent results from the GEWEX Cloud System Study (GCSS) Working Group on Cirrus Cloud Systems (WG2) Idealized Cirrus Model Comparison and Cirrus Parcel Model Comparison projects, as described in Starr et al. and Lin et al. Key issues in current cirrus cloud modeling will be described and discussed.
Starr, David OC.↗
An Agile-Like Approach to Hardware Development: The Ejectable Data Recorder (EDR) for Orion's Ascent Abort 2 (AA-2) Test Flight
On July 2, 2019, the Ascent Abort 2 (AA-2) Flight Test Vehicle was launched from Cape Canaveral, with the goal of demonstrating the performance of Orion’s Launch Abort System (LAS) and collecting data from hundreds of sensors throughout the vehicle. The data collected during this test flight is of paramount importance, as it will be used to certify the Orion vehicle for human spaceflight. Originally, the data was to be downlinked via a single string network of antennas on the LAS, with the associated risk of potential data dropouts, as well as loss of data once the LAS was jettisoned. Thus, additional antennas were added onto the crew module (CM) to support data downlink post-LAS jettison, a buffer rebroadcast capability was added to fill in any gaps in data downlink transmissions, and an ejectable data recorder (EDR) subsystem was added to the CM as a redundant measure to collect all the instrumentation data. The EDR subsystem was added to the project about one year after the project commenced, which significantly reduced the available development time when compared with the other subsystems of the AA-2 Test Flight. The project was further accelerated by six months, around the critical design review gate. Due to the schedule compression challenge and the fact that the EDR subsystem was a backup system and not flight critical, the EDR subsystem was further challenged to find a new and more efficient way to develop hardware. Thus, the EDR subsystem experimented with different management and systems engineering processes, team sizes, communication methods, and tools. Some examples are novel uses of SharePoint as a Data-centric Project Management & Systems Engineering environment, a continuous testing approach through the lifecycle, and a Skunkworks approach to managing the team. The EDR subsystem blended Commercial Off The Shelf (COTS) hardware with in-house developed hardware and software to create a novel data retrieval capability. The capability evolved rapidly through a hardware in the loop simulation environment that enabled incremental component updates for not only the EDR subsystem but across the entire Crew Module. This paper will present an overview of how the EDR subsystem was managed and compare it to an Agile approach to managing projects. The paper will further provide a recommended approach to future Agile-like hardware development that incorporates lessons learned from the EDR experience.
Agile↗
Human Factors Engineering as a System in the Vision for Exploration
In order to accomplish NASA's Vision for Exploration, while assuring crew safety and productivity, human performance issues must be well integrated into system design from mission conception. To that end, a two-year Technology Development Project (TDP) was funded by NASA Headquarters to develop a systematic method for including the human as a system in NASA's Vision for Exploration. The specific goals of this project are to review current Human Systems Integration (HSI) standards (i.e., industry, military, NASA) and tailor them to selected NASA Exploration activities. Once the methods are proven in the selected domains, a plan will be developed to expand the effort to a wider scope of Exploration activities. The methods will be documented for inclusion in NASA-specific documents (such as the Human Systems Integration Standards, NASA-STD-3000) to be used in future space systems. The current project builds on a previous TDP dealing with Human Factors Engineering processes. That project identified the key phases of the current NASA design lifecycle, and outlined the recommended HFE activities that should be incorporated at each phase. The project also resulted in a prototype of a webbased HFE process tool that could be used to support an ideal HFE development process at NASA. This will help to augment the limited human factors resources available by providing a web-based tool that explains the importance of human factors, teaches a recommended process, and then provides the instructions, templates and examples to carry out the process steps. The HFE activities identified by the previous TDP are being tested in situ for the current effort through support to a specific NASA Exploration activity. Currently, HFE personnel are working with systems engineering personnel to identify HSI impacts for lunar exploration by facilitating the generation of system-level Concepts of Operations (ConOps). For example, medical operations scenarios have been generated for lunar habitation in order to identify HSI requirements for the lunar communications architecture. Throughout these ConOps exercises, HFE personnel are testing various tools and methodologies that have been identified in the literature. A key part of the effort is the identification of optimal processes, methods, and tools for these early development phase activities, such as ConOps, requirements development, and early conceptual design. An overview of the activities completed thus far, as well as the tools and methods investigated will be presented.
Mihriban Whitmore↗