Engineering Papers⌕ Search

SEARCH · Engineering Papers

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 19 records
All sourcesNASA NTRSDOE OSTI
NASA NTRS2004

Error Cost Escalation Through the Project Life Cycle

It is well known that the costs to fix errors increase as the project matures, but how fast do those costs build? A study was performed to determine the relative cost of fixing errors discovered during various phases of a project life cycle. This study used three approaches to determine the relative costs: the bottom-up cost method, the total cost breakdown method, and the top-down hypothetical project method. The approaches and results described in this paper presume development of a hardware/software system having project characteristics similar to those used in the development of a large, complex spacecraft, a military aircraft, or a small communications satellite. The results show the degree to which costs escalate, as errors are discovered and fixed at later and later phases in the project life cycle. If the cost of fixing a requirements error discovered during the requirements phase is defined to be 1 unit, the cost to fix that error if found during the design phase increases to 3 - 8 units; at the manufacturing/build phase, the cost to fix the error is 7 - 16 units; at the integration and test phase, the cost to fix the error becomes 21 - 78 units; and at the operations phase, the cost to fix the requirements error ranged from 29 units to more than 1500 units

Stecklein, Jonette M.↗
NASA NTRS2007

POLARIS: Helping Managers Get Answers Fast!

This viewgraph presentation reviews the Project Online Library and Resource Information System (POLARIS) system. It is NASA-wide, web-based system, providing access to information related to Program and Project Management. It will provide a one-stop shop for access to: a searchable, sortable database of all requirements for all product lines, project life cycle diagrams with reviews, project life cycle diagrams with reviews, project review definitions with products review information from NPR 7123.1, NASA Systems Engineering Processes and Requirements, templates and examples of products, project standard WBSs with dictionaries, and requirements for implementation and approval, information from NASA s Metadata Manager (MdM): Attributes of Missions, Themes, Programs & Projects, NPR7120.5 waiver form and instructions and much more. The presentation reviews the plans and timelines for future revisions and modifications.

program management↗
NASA NTRS2017

Using Model-Based Systems Engineering To Provide Artifacts for NASA Project Life-Cycle and Technical Reviews

The ability of systems engineers to use model-based systems engineering (MBSE) to generate self-consistent, up-to-date systems engineering products for project life-cycle and technical reviews is an important aspect for the continued and accelerated acceptance of MBSE. Currently, many review products are generated using labor-intensive, error-prone approaches based on documents, spreadsheets, and chart sets; a promised benefit of MBSE is that users will experience reductions in inconsistencies and errors. This work examines features of SysML that can be used to generate systems engineering products. Model elements, relationships, tables, and diagrams are identified for a large number of the typical systems engineering artifacts. A SysML system model can contain and generate most systems engineering products to a significant extent and this paper provides a guide on how to use MBSE to generate products for project life-cycle and technical reviews. The use of MBSE can reduce the schedule impact usually experienced for review preparation, as in many cases the review products can be auto-generated directly from the system model. These approaches are useful to systems engineers, project managers, review board members, and other key project stakeholders.

SE Product↗
NASA NTRS2017

Using Model-Based Systems Engineering to Provide Artifacts for NASA Project Life-cycle and Technical Reviews

This paper is for the AIAA Space Conference. The ability of systems engineers to use model-based systems engineering (MBSE) to generate self-consistent, up-to-date systems engineering products for project life-cycle and technical reviews is an important aspect for the continued and accelerated acceptance of MBSE. Currently, many review products are generated using labor-intensive, error-prone approaches based on documents, spreadsheets, and chart sets; a promised benefit of MBSE is that users will experience reductions in inconsistencies and errors. This work examines features of SysML that can be used to generate systems engineering products. Model elements, relationships, tables, and diagrams are identified for a large number of the typical systems engineering artifacts. A SysML system model can contain and generate most systems engineering products to a significant extent and this paper provides a guide on how to use MBSE to generate products for project life-cycle and technical reviews. The use of MBSE can reduce the schedule impact usually experienced for review preparation, as in many cases the review products can be auto-generated directly from the system model. These approaches are useful to systems engineers, project managers, review board members, and other key project stakeholders.

MBSE↗
NASA NTRS2012

Engineering Technical Review Planning Briefing

The general topics covered in the engineering technical planning briefing are 1) overviews of NASA, Marshall Space Flight Center (MSFC), and Engineering, 2) the NASA Systems Engineering(SE) Engine and its implementation , 3) the NASA Project Life Cycle, 4) MSFC Technical Management Branch Services in relation to the SE Engine and the Project Life Cycle , 5) Technical Reviews, 6) NASA Human Factor Design Guidance , and 7) the MSFC Human Factors Team. The engineering technical review portion of the presentation is the primary focus of the overall presentation and will address the definition of a design review, execution guidance, the essential stages of a technical review, and the overall review planning life cycle. Examples of a technical review plan content, review approaches, review schedules, and the review process will be provided and discussed. The human factors portion of the presentation will focus on the NASA guidance for human factors. Human factors definition, categories, design guidance, and human factor specialist roles will be addressed. In addition, the NASA Systems Engineering Engine description, definition, and application will be reviewed as background leading into the NASA Project Life Cycle Overview and technical review planning discussion.

Gardner, Terrie↗
NASA NTRS2016

Implementing Effective Mission Systems Engineering Practices During Early Project Formulation Phases

Developing and implementing a plan for a NASA space mission can be a complicated process. The needs, goals, and objectives of any proposed mission or technology must be assessed early in the Project Life Cycle. The key to successful development of a space mission or flight project is the inclusion of systems engineering in early project formulation, namely during Pre-phase A, Phase A, and Phase B of the NASA Project Life Cycle. When a space mission or new technology is in pre-development, or "pre-Formulation", feasibility must be determined based on cost, schedule, and risk. Inclusion of system engineering during project formulation is key because in addition to assessing feasibility, design concepts are developed and alternatives to design concepts are evaluated. Lack of systems engineering involvement early in the project formulation can result in increased risks later in the implementation and operations phases of the project. One proven method for effective systems engineering practice during the pre-Formulation Phase is the use of a mission conceptual design or technology development laboratory, such as the Mission Design Lab (MDL) at NASA's Goddard Space Flight Center (GSFC). This paper will review the engineering process practiced routinely in the MDL for successful mission or project development during the pre-Formulation Phase.

Processes↗
NASA NTRS2003

Charting the Course: Life Cycle Management of Mars Mission Digital Information

This viewgraph presentation reviews the life cycle management of MER Project information. This process was an essential key to the successful launch of the MER Project rovers. Incorporating digital information archive requirements early in the project life cycle resulted in: Design of an information system that included archive metadata, Reduced the risk of information loss through in-process appraisal, Easier transfer of project information to institutional online archive and Project appreciation for preserving information for reuse by future projects

information life cycles↗
NASA NTRS1997

Application of Domain Knowledge to Software Quality Assurance

This work focused on capturing, using, and evolving a qualitative decision support structure across the life cycle of a project. The particular application of this study was towards business process reengineering and the representation of the business process in a set of Business Rules (BR). In this work, we defined a decision model which captured the qualitative decision deliberation process. It represented arguments both for and against proposed alternatives to a problem. It was felt that the subjective nature of many critical business policy decisions required a qualitative modeling approach similar to that of Lee and Mylopoulos. While previous work was limited almost exclusively to the decision capture phase, which occurs early in the project life cycle, we investigated the use of such a model during the later stages as well. One of our significant developments was the use of the decision model during the operational phase of a project. By operational phase, we mean the phase in which the system or set of policies which were earlier decided are deployed and put into practice. By making the decision model available to operational decision makers, they would have access to the arguments pro and con for a variety of actions and can thus make a more informed decision which balances the often conflicting criteria by which the value of action is measured. We also developed the concept of a 'monitored decision' in which metrics of performance were identified during the decision making process and used to evaluate the quality of that decision. It is important to monitor those decision which seem at highest risk of not meeting their stated objectives. Operational decisions are also potentially high risk decisions. Finally, we investigated the use of performance metrics for monitored decisions and audit logs of operational decisions in order to feed an evolutionary phase of the the life cycle. During evolution, decisions are revisisted, assumptions verified or refuted, and possible reassessments resulting in new policy are made. In this regard we implemented a machine learning algorithm which automatically defined business rules based on expert assessment of the quality of operational decisions as recorded during deployment.

Wild, Christian W.↗
NASA NTRS2017

NASA's Robotics Mining Competition Provides Undergraduates Full Life Cycle Systems Engineering Experience

NASA has held an annual robotic mining competition for teams of university/college students since 2010. This competition is yearlong, suitable for a senior university engineering capstone project. It encompasses the full project life cycle from ideation of a robot design to actual tele-operation of the robot in simulated Mars conditions mining and collecting simulated regolith. A major required element for this competition is a Systems Engineering Paper in which each team describes the systems engineering approaches used on their project. The score for the Systems Engineering Paper contributes 25% towards the team's score for the competition's grand prize. The required use of systems engineering on the project by this competition introduces the students to an intense practical application of systems engineering throughout a full project life cycle.

Stecklein, Jonette↗
NASA NTRS2017

NASA's Robotic Mining Competition Provides Undergraduates Full Life Cycle Systems Engineering Experience

NASA has held an annual robotic mining competition for teams of university/college students since 2010. This competition is yearlong, suitable for a senior university engineering capstone project. It encompasses the full project life cycle from ideation of a robot design, through tele-operation of the robot collecting regolith in simulated Mars conditions, to disposal of the robot systems after the competition. A major required element for this competition is a Systems Engineering Paper in which each team describes the systems engineering approaches used on their project. The score for the Systems Engineering Paper contributes 25% towards the team’s score for the competition’s grand prize. The required use of systems engineering on the project by this competition introduces the students to an intense practical application of systems engineering throughout a full project life cycle.

Stecklein, Jonette↗
NASA NTRS1977

Evaluation of ERDA-sponsored coal feed system development

Coal feeders were evaluated based upon criteria such as technical feasibility, performance (i.e. ability to meet process requirements), projected life cycle costs, and projected development cost. An initial set of feeders was selected based on the feeders' cost savings potential compared with baseline lockhopper systems. Additional feeders were considered for selection based on: (1) increasing the probability of successful feeder development; (2) application to specific processes; and (3) technical merit. A coal feeder development program is outlined.

Phen, R. L.↗
NASA NTRSDate not supplied

Tracking Critical Thermal Metrics throughout the Life Cycle of a Large Observatory Thermal Model

Observatory thermal models for large, complex missions, such as the Wide Field InfraRed Survey Telescope (WFIRST) mission, produce an immense amount of data to be processed. Configuration management of the model throughout the project life cycle has mainly focused on which versions of the subsystem models form the current observatory level configuration. However, the results produced by the model are not nearly as well tracked and traceable. Given the various states of design maturity for each of the components in the WFIRST design, an updated component model is nearly ready to be integrated at the next higher level of assembly about every month or two. With each subsystem model delivery, the observatory model needs to remove the old component, integrate the new one, execute the model, and inspect the results. Usually, this inspection focuses primarily on the newly integrated component. Recently, a Metric Tracking Spreadsheet was developed to help provide a “big picture” view of the entire observatory highlighting key parameters critical to mission performance. This spreadsheet helps track impacts on subsystems by updates of other subsystems that were not intuitively obvious. Metrics tracked include: absorbed environmental loading (to determine effectiveness of sunshield), temperatures of critical avionics, electrical dissipations, heater power predictions, stability of critical optics, parasitic heat leaks in cryogenic region, high level heat flows between elements, and model run time. Producing this data for the same operational configuration with each model update has helped produce a trail of data to evaluate the impact of model updates. While the metrics selected are specific for WFIRST, other large, complex observatories could be well served to establish their own metrics early in the project life cycle to track to quickly assess the impact of any subsystem on other subsystems or the overall system itself.

Thermal Desktop↗
NASA NTRS2014

Project Assessment Framework through Design (PAFTD) - A Project Assessment Framework in Support of Strategic Decision Making

Research and development organizations that push the innovation edge of technology frequently encounter challenges when attempting to identify an investment strategy and to accurately forecast the cost and schedule performance of selected projects. Fast moving and complex environments require managers to quickly analyze and diagnose the value of returns on investment versus allocated resources. Our Project Assessment Framework through Design (PAFTD) tool facilitates decision making for NASA senior leadership to enable more strategic and consistent technology development investment analysis, beginning at implementation and continuing through the project life cycle. The framework takes an integrated approach by leveraging design principles of useability, feasibility, and viability and aligns them with methods employed by NASA's Independent Program Assessment Office for project performance assessment. The need exists to periodically revisit the justification and prioritization of technology development investments as changes occur over project life cycles. The framework informs management rapidly and comprehensively about diagnosed internal and external root causes of project performance.

Depenbrock, Brett T.↗
NASA NTRS2006

Mission Scenario Development Workbench

The Mission Scenario Development Workbench (MSDW) is a multidisciplinary performance analysis software tool for planning and optimizing space missions. It provides a number of new capabilities that are particularly useful for planning the surface activities on other planets. MSDW enables rapid planning of a space mission and supports flight system and scientific-instrumentation trades. It also provides an estimate of the ability of flight, ground, and science systems to meet high-level mission goals and provides means of evaluating expected mission performance at an early stage of planning in the project life cycle. In MSDW, activity plans and equipment-list spreadsheets are integrated with validated parameterized simulation models of spacecraft systems. In contrast to traditional approaches involving worst-case estimates with large margins, the approach embodied in MSDW affords more flexibility and more credible results early in the lifecycle through the use of validated, variable- fidelity models of spacecraft systems. MSDW is expected to help maximize the scientific return on investment for space missions by understanding early the performance required to have a successful mission while reducing the risk of costly design changes made at late stages in the project life cycle.

Kordon, Mark↗
NASA NTRS2014

VARED: Verification and Analysis of Requirements and Early Designs

Requirements are a part of every project life cycle; everything going forward in a project depends on them. Good requirements are hard to write, there are few useful tools to test, verify, or check them, and it is difficult to properly marry them to the subsequent design, especially if the requirements are written in natural language. In fact, the inconsistencies and errors in the requirements along with the difficulty in finding these errors contribute greatly to the cost of the testing and verification stage of flight software projects [1]. Large projects tend to have several thousand requirements written at various levels by different groups of people. The design process is distributed and a lack of widely accepted standards for requirements often results in a product that varies widely in style and quality. A simple way to improve this would be to standardize the design process using a set of tools and widely accepted requirements design constraints. The difficulty with this approach is finding the appropriate constraints and tools. Common complaints against the tools available include ease of use, functionality, and available features. Also, although preferable, it is rare that these tools are capable of testing the quality of the requirements.

Badger, Julia↗
NASA NTRS2010

Project Interface Requirements Process Including Shuttle Lessons Learned

Most failures occur at interfaces between organizations and hardware. Processing interface requirements at the start of a project life cycle will reduce the likelihood of costly interface changes/failures later. This can be done by adding Interface Control Documents (ICDs) to the Project top level drawing tree, providing technical direction to the Projects for interface requirements, and by funding the interface requirements function directly from the Project Manager's office. The interface requirements function within the Project Systems Engineering and Integration (SE&I) Office would work in-line with the project element design engineers early in the life cycle to enhance communications and negotiate technical issues between the elements. This function would work as the technical arm of the Project Manager to help ensure that the Project cost, schedule, and risk objectives can be met during the Life Cycle. Some ICD Lessons Learned during the Space Shuttle Program (SSP) Life Cycle will include the use of hardware interface photos in the ICD, progressive life cycle design certification by analysis, test, & operations experience, assigning interface design engineers to Element Interface (EI) and Project technical panels, and linking interface design drawings with project build drawings

Bauch, Garland T.↗
NASA NTRS2004

Developing the JPL Engineering Processes

This paper briefly recounts the recent history of process reengineering at the NASA Jet Propulsion Laboratory, with a focus on the engineering processes. The JPL process structure is described and the process development activities of the past several years outlined. The main focus of the paper is on the current process structure, the emphasis on the flight project life cycle, the governance approach that lead to Flight Project Practices, and the remaining effort to capture process knowledge at the detail level of the work group.

reengineering↗