Search NASA⌕ Search

SEARCH · Search NASA

Results for “Project Life Cycle”

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.

At least 235 records · Page 13
All sourcesNASA NTRSDOE OSTI
NASA NTRS2008

XTCE and XML Database Evolution and Lessons from JWST, LandSat, and Constellation

The database organizations within three different NASA projects have advanced current practices by creating database synergy between the various spacecraft life cycle stakeholders and educating users in the benefits of the Consultative Committee for Space Data Systems (CCSDS) XML Telemetry and Command Exchange (XTCE) format. The combination of XML for managing program data and CCSDS XTCE for exchange is a robust approach that will meet all user requirements using Standards and Non proprietary tools. COTS tools for XTCEKML are very wide and varied. To combine together various low cost and free tools can be more expensive in the long run than choosing a more expensive COTS tool that meets all the needs. This was especially important when deploying in 32 remote sites with no need for licenses. A common mission XTCEKML format between dissimilar systems is possible and is not difficult. Command XMLKTCE is more complex than telemetry and the use of XTCEKML metadata to describe pages and scripts is needed due to the proprietary nature of most current ground systems. Other mission and science products such as spacecraft loads, science image catalogs, and mission operation procedures can all be described with XML as well to increase there flexibility as systems evolve and change. Figure 10 is an example of a spacecraft table load. The word is out and the XTCE community is growing, The f ~ sXt TCE user group was held in October and in addition to ESAESOC, SC02000, and CNES identified several systems based on XTCE. The second XTCE user group is scheduled for March 10, 2008 with LDMC and others joining. As the experience with XTCE grows and the user community receives the promised benefits of using XTCE and XML the interest is growing fast.

Gal-Edd, Jonathan↗
NASA NTRS2011

Circumstellar Environments of Luminous Infrared Stellar Objects in the Magellanic Clouds

Young stars are formed out of the interstellar medium (ISM) which is replenished by mass loss rates from evolved stars. Circumstellar matter around young and evolved stellar objects usually emits energy in the infrared (IR) wavelength range as the matter is heated by the central star. Surveys of the Magellanic Clouds with the Spitzer Space Telescope in the 3.6-160 micron range have previously been completed. These surveys have led to catalogs of infrared sources: which include HII regions, young stars, super giants, asymptotic giant branch (AGB) stars, post-asymptotic giant branch (post-AGB) stars, and planetary nebulae. The utility of such surveys can be improved upon by using Hubble Space Telescope (HST) data. HST provides higher angular resolution than Spitzer and has allowed for more detailed investigation of these luminous IR objects. This project used previously obtained HST archival data to examine luminous IR objects at optical wavelengths. This allows for the reclassification of stellar objects previously thought as one type of object or in a particular stage of their stellar evolution. An overall objective of this project included looking for extended nebulosity around evolved stars to better understand the life cycle of such objects and classify these nebulae by shape.

large Magellanic clouds↗
NASA NTRS2013

Development of Hybrid Product Breakdown Structure for NASA Ground Systems

The Product Breakdown Structure is traditionally a method of identification of the products of a project in a tree structure. It is a tool used to assess, plan, document, and display the equipment requirements for a project. It is part of a product based planning technique, and attempts to break down all components of a project in as much detail as possible, so that nothing is overlooked. The PBS for ground systems at the Kennedy Space Center is being developed to encompass the traditional requirements including the alignment of facility, systems, and components to the organizational hierarchy. The Ground Operations Product Breakdown Structure is a hybrid in nature in that some aspects of a work breakdown structure will be incorporated and merged with the Architecture Concept of Operations, Master Subsystem List, customer interface, and assigned management responsibility. The Ground Operations Product Breakdown Structure needs to be able to identify the flexibility of support differing customers (internal and external) usage of ground support equipment within the Kennedy Space Center launch and processing complex. The development of the Product Breakdown Structure is an iterative activity Initially documenting the organization hierarchy structure and relationships. The Product Breakdown Structure identifies the linkage between the customer program requirements, allocation of system resources, development of design goals, and identification logistics products. As the Product Breakdown Structure progresses the incorporation of the results of requirement planning for the customer occurs identifying facility needs and systems. The mature Product Breakdown Structure is baselined with a hierarchical drawing, the Product Breakdown Structure database, and an associated document identifying the verification of the data through the life cycle of the program/product line. This paper will document, demonstrate, and identify key aspects of the life cycle of a Hybrid Product Breakdown Structure. The purpose is to show how a project management and system engineering approach can be utilized for providing flexible customer service in an evolving manned space flight launch processing environment.

Monaghan, Mark W.↗
NASA NTRS2013

Development of Hybrid Product Breakdown Structure for NASA Ground Systems

The Product Breakdown Structure is traditionally a method of identification of the products of a project in a tree structure. It is a tool used to assess, plan, document, and display the equipment requirements for a project. It is part of a product based planning technique, and attempts to break down all components of a project in as much detail as possible, so that nothing is overlooked. The PBS for ground systems at the Kennedy Space Center is being developed to encompass the traditional requirements including the alignment of facility, systems, and components to the organizational hierarchy. The Ground Operations Product Breakdown Structure is a hybrid in nature in that some aspects of a work breakdown structure will be incorporated and merged with the Architecture Concept of Operations, Master Subsystem List, customer interface, and assigned management responsibility. The Ground Operations Product Breakdown Structure needs to be able to identify the flexibility of support differing customers (internal and external) usage of ground support equipment within the Kennedy Space Center launch and processing complex. The development of the Product Breakdown Structure is an iterative activity Initially documenting the organization hierarchy structure and relationships. The Product Breakdown Structure identifies the linkage between the customer program requirements, allocation of system resources, development of design goals, and identification logistics products. As the Product Breakdown Structure progresses the incorporation of the results of requirement planning for the customer occurs identifying facility needs and systems. The mature Product Breakdown Structure is baselined with a hierarchical drawing, the Product Breakdown Structure database, and an associated document identifying the verification of the data through the life cycle of the program/product line. This paper will document, demonstrate, and identify key aspects of the life cycle of a Hybrid Product Breakdown Structure. The purpose is to show how a project management and system engineering approach can be utilized for providing flexible customer service in an evolving manned space flight launch processing environment.

Monaghan, Mark W.↗
NASA NTRS2004

Software Quality Assurance Metrics

Software Quality Assurance (SQA) is a planned and systematic set of activities that ensures conformance of software life cycle processes and products conform to requirements, standards and procedures. In software development, software quality means meeting requirements and a degree of excellence and refinement of a project or product. Software Quality is a set of attributes of a software product by which its quality is described and evaluated. The set of attributes includes functionality, reliability, usability, efficiency, maintainability, and portability. Software Metrics help us understand the technical process that is used to develop a product. The process is measured to improve it and the product is measured to increase quality throughout the life cycle of software. Software Metrics are measurements of the quality of software. Software is measured to indicate the quality of the product, to assess the productivity of the people who produce the product, to assess the benefits derived from new software engineering methods and tools, to form a baseline for estimation, and to help justify requests for new tools or additional training. Any part of the software development can be measured. If Software Metrics are implemented in software development, it can save time, money, and allow the organization to identify the caused of defects which have the greatest effect on software development. The summer of 2004, I worked with Cynthia Calhoun and Frank Robinson in the Software Assurance/Risk Management department. My task was to research and collect, compile, and analyze SQA Metrics that have been used in other projects that are not currently being used by the SA team and report them to the Software Assurance team to see if any metrics can be implemented in their software assurance life cycle process.

McRae, Kalindra A.↗
NASA NTRS1993

Cost and schedule estimation study report

This report describes the analysis performed and the findings of a study of the software development cost and schedule estimation models used by the Flight Dynamics Division (FDD), Goddard Space Flight Center. The study analyzes typical FDD projects, focusing primarily on those developed since 1982. The study reconfirms the standard SEL effort estimation model that is based on size adjusted for reuse; however, guidelines for the productivity and growth parameters in the baseline effort model have been updated. The study also produced a schedule prediction model based on empirical data that varies depending on application type. Models for the distribution of effort and schedule by life-cycle phase are also presented. Finally, this report explains how to use these models to plan SEL projects.

Condon, Steve↗
NASA NTRS1989

Computer-aided software development process design

The authors describe an intelligent tool designed to aid managers of software development projects in planning, managing, and controlling the development process of medium- to large-scale software projects. Its purpose is to reduce uncertainties in the budget, personnel, and schedule planning of software development projects. It is based on dynamic model for the software development and maintenance life-cycle process. This dynamic process is composed of a number of time-varying, interacting developmental phases, each characterized by its intended functions and requirements. System dynamics is used as a modeling methodology. The resulting Software LIfe-Cycle Simulator (SLICS) and the hybrid expert simulation system of which it is a subsystem are described.

Lin, Chi Y.↗
NASA NTRS2010

Planning and Estimation of Operations Support Requirements

Life Cycle Cost (LCC) estimates during the proposal and early design phases, as well as project replans during the development phase, are heavily focused on hardware development schedules and costs. Operations (phase E) costs are typically small compared to the spacecraft development and test costs. This, combined with the long lead time for realizing operations costs, can lead to de-emphasizing estimation of operations support requirements during proposal, early design, and replan cost exercises. The Discovery and New Frontiers (D&NF) programs comprise small, cost-capped missions supporting scientific exploration of the solar system. Any LCC growth can directly impact the programs' ability to fund new missions, and even moderate yearly underestimates of the operations costs can present significant LCC impacts for deep space missions with long operational durations. The National Aeronautics and Space Administration (NASA) D&NF Program Office at Marshall Space Flight Center (MSFC) recently studied cost overruns and schedule delays for 5 missions. The goal was to identify the underlying causes for the overruns and delays, and to develop practical mitigations to assist the D&NF projects in identifying potential risks and controlling the associated impacts to proposed mission costs and schedules. The study found that 4 out of the 5 missions studied had significant overruns at or after launch due to underestimation of the complexity and supporting requirements for operations activities; the fifth mission had not launched at the time of the mission. The drivers behind these overruns include overly optimistic assumptions regarding the savings resulting from the use of heritage technology, late development of operations requirements, inadequate planning for sustaining engineering and the special requirements of long duration missions (e.g., knowledge retention and hardware/software refresh), and delayed completion of ground system development work. This paper updates the D&NF LCC study, looking at the operations (phase E) cost drivers in more detail and extending the study to include 2 additional missions and identifies areas for increased emphasis by project management in order to improve the fidelity of operations estimates.

Newhouse, Marilyn E.↗
NASA NTRS2023

Digital Engineering Design Center (DEDC): Modelling an ISRU System

The DEDC provides immersive project-based learning on digital engineering toolsets and processes supporting NASA’s digital transformation goals: - Digital Engineering uses authoritative sources of systems' data and models as a continuum across disciplines to support integrated digital approach life cycle activities from concept through disposal. - The digital environment provided includes the state-of-the-art digital engineering suite, Siemens Xcelerator. The pilot project is developing an end-to-end integrated model of an In-Situ Resource Utilization (ISRU) system for commodities production: - ISRU uses local resources to provide mission consumables to enable a sustainable Moon or Mars surface presence. - The final digital twin product will include a methanation reactor, condenser, and electrolyzer subsystem.

Digital Engineering Design Center↗
NASA NTRS2010

Altair Lander Life Support: Requirements Analysis Cycles 1 and 2

Life support systems are a critical part of human exploration beyond low earth orbit. NASA's Altair Lunar Lander has unique missions to perform and will need a unique life support system to complete them. Initial work demonstrated a feasible minimally -functional Lander design. This work was completed in Design Analysis Cycles (DAC) 1, 2, and 3 were reported in a previous paper'. On October 21, 2008, the Altair project completed the Mission Concept Review (MCR), moving the project into Phase A. In Phase A activities, the project is preparing for the System Requirements Review (SRR). Altair has conducted two Requirements Analysis Cycles (RACs) to begin this work. During this time, the life support team must examine the Altair mission concepts, Constellation Program level requirements, and interfaces with other vehicles and spacesuits to derive the right set of requirements for the new vehicle. The minimum functionality design meets some of these requirements already and can be easily adapted to meet others. But Altair must identify which will be more costly in mass, power, or other resources to meet. These especially costly requirements must be analyzed carefully to be sure they are truly necessary, and are the best way of explaining and meeting the true need. If they are necessary and clear, they become important mass threats to track at the vehicle level. If they are not clear or do not seem necessary to all stakeholders, Altair must work to redefine them or push back on the requirements writers. Additionally, the life support team is evaluating new technologies to see if they are more effective than the existing baseline design at performing necessary functions in Altair's life support system.

Anderson, Molly↗
NASA NTRS1988

Models and metrics for software management and engineering

This paper attempts to characterize and present a state of the art view of several quantitative models and metrics of the software life cycle. These models and metrics can be used to aid in managing and engineering software projects. They deal with various aspects of the software process and product, including resources allocation and estimation, changes and errors, size, complexity and reliability. Some indication is given of the extent to which the various models have been used and the success they have achieved.

Basili, V. R.↗
NASA NTRS1991

Risk management and expert system development methodology

A risk-based expert-system development methodology has been developed to provide guidance to managers and technical personnel and to serve as a standard for developing expert systems. Expert-system development differs from conventional software development in that the information needed to prepare system requirements for expert systems is not known at the outset of a project and is obtained by knowledge engineering methods. The paper describes the expert-system life cycle, development methodology, and the approach taken in this methodology to manage and reduce the risks in expert system development. Also examined are the risks of using and of not using a methodology, the studies undertaken to validate the provisions of the expert system development methodology, and the results of these validation studies.

Hull, Larry↗
NASA NTRS1992

NASA in the 21st century: A vision of greatness

Notions of greatness are discussed that have guided NASA in the past, values are presented that might be delivered by NASA in the future, and the the skills required for NASA to execute a vision of greatness are examined. Three possible patterns of space development by NASA are reviewed: (1) a mission to protect the ecology of the Earth; (2) the engineering of the technologies critical to space transportation and a healthy, productive life in space; and (3) the management of a major nonterrestrial resource project. Potential sources of funds are discussed along with opportunities for sustainable collaboration, and the life cycle of NASA's funding responsibility for its space development program.

Murphy, Kathleen J.↗
NASA NTRS1994

Integrated developmental model of life-support capabilities in wheat

The objective of this project was to develop a model for CO2, O2, H2O, and nitrogen use during the life cycle of wheat. Spreadsheets and accompanying graphs were developed to illustrate plant population reactions to environmental parameters established in the Controlled Ecological Life Support System (CELSS) program at Kennedy Space Center, Fl. The spreadsheets and graphs were produced using validated biomass production chamber (BPC) data from BWT931. Conditions of the BPC during the 83 day plant growth period were as follows: The BPC area is 27.8 m(exp 2), volume is 113 m(exp 3). Temperatures during the 83 day plant growth period ranged from 16.3 to 24.8 C during the light cycle (except for day 69, when the minimum and maximum temperatures were 7.7 C and 7.9 C, respectively) and 14.5 C and 23.6 C during the dark cycle (except for day 49, when the minimum and maximum temperatures were 11.1 C and 11.3 C, respectively). Relative humidity was 85 percent for the first seven days of plant growth, and 70 percent thereafter. The plant leaf canopy area was 10 m(exp 2). Presented is a list and explanation of each spreadsheet and accompanying graph(s), conditions under which the data were collected, and formulas used to obtain each result.

Darnell, R. L.↗
NASA NTRS2009

Altair Lander Life Support: Requirement Analysis Cycles 1 and 2

Life support systems are a critical part of human exploration beyond low earth orbit. NASA s Altair Lunar Lander has unique missions to perform and will need a unique life support system to complete them. Initial work demonstrated a feasible minimally-functional Lander design. This work was completed in Design Analysis Cycles (DAC) 1, 2, and 3 were reported in a previous paper. On October 21, 2008, the Altair project completed the Mission Concept Review (MCR), moving the project into Phase A. In Phase A activities, the project is preparing for the System Requirements Review (SRR). Altair has conducted two Requirements Analysis Cycles (RACs) to begin this work. During this time, the life support team must examine the Altair mission concepts, Constellation Program level requirements, and interfaces with other vehicles and spacesuits to derive the right set of requirements for the new vehicle. The minimum functionality design meets some of these requirements already and can be easily adapted to meet others. But Altair must identify which will be more costly in mass, power, or other resources to meet. These especially costly requirements must be analyzed carefully to be sure they are truly necessary, and are the best way of explaining and meeting the true need. If they are necessary and clear, they become important mass threats to track at the vehicle level. If they are not clear or do not seem necessary to all stakeholders, Altair must work to redefine them or push back on the requirements writers. Additionally, the life support team is evaluating new technologies to see if they are more effective than the existing baseline design at performing necessary functions in Altair s life support system.

Anderson, Molly↗
NASA NTRS2013

Characterizing Wheel-Soil Interaction Loads Using Meshfree Finite Element Methods: A Sensitivity Analysis for Design Trade Studies

A wheel experiencing sinkage and slippage events poses a high risk to planetary rover missions as evidenced by the mobility challenges endured by the Mars Exploration Rover (MER) project. Current wheel design practice utilizes loads derived from a series of events in the life cycle of the rover which do not include (1) failure metrics related to wheel sinkage and slippage and (2) performance trade-offs based on grouser placement/orientation. Wheel designs are rigorously tested experimentally through a variety of drive scenarios and simulated soil environments; however, a robust simulation capability is still in development due to myriad of complex interaction phenomena that contribute to wheel sinkage and slippage conditions such as soil composition, large deformation soil behavior, wheel geometry, nonlinear contact forces, terrain irregularity, etc. For the purposes of modeling wheel sinkage and slippage at an engineering scale, meshfree nite element approaches enable simulations that capture su cient detail of wheel-soil interaction while remaining computationally feasible. This study implements the JPL wheel-soil benchmark problem in the commercial code environment utilizing the large deformation modeling capability of Smooth Particle Hydrodynamics (SPH) meshfree methods. The nominal, benchmark wheel-soil interaction model that produces numerically stable and physically realistic results is presented and simulations are shown for both wheel traverse and wheel sinkage cases. A sensitivity analysis developing the capability and framework for future ight applications is conducted to illustrate the importance of perturbations to critical material properties and parameters. Implementation of the proposed soil-wheel interaction simulation capability and associated sensitivity framework has the potential to reduce experimentation cost and improve the early stage wheel design proce

terramechanics↗