Search NASA⌕ Search

SEARCH · Search NASA

Results for “UNIVERSITY PROGRAM”

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 NTRS1998

Continuation of the University of Michigan Sounding Rocket Program

This interim report gives the activity on this grant through 31 October 1998, and the planned activities for the next fiscal year. A Project Initiation Conference (PIC) was held at the Wallops Flight Facility (WFF), with planning for the launch of flight 36.174 in Fall 1998. However, following the PIC, the WFF personnel decided that the experiment telemetry system had to be completely rewired, which required substantial design and wiring changes on the experiment side of the payload. These costs had not been anticipated in the FY98 budget, and used up considerable resources of the experimenters. In addition, the telemetry re-design was not completed until Fall 1998, so that there was no opportunity for a launch in 1998 (the Jupiter window closes in late November 1998 and it will reopen in late summer 1999). A Design Review was held by telecon with WFF personnel on 26 October 1998, with plans for the 36.174 launch now in late August 1999 with a launch window which extends into winter 2000. On a more positive note, we have been developing a vacuum UV calibration chamber in Michigan's Space Physics Research Lab, for future measurements of our experiment components, and this facility is now undergoing initial measurements of various calibration lamps in preparation for testing of the telescope UV reflective efficiency. This facility will greatly increase our ability to optimize our experiment for UV efficiency, which has been lacking in the past, and it will be made available for support of other NASA missions at Michigan and for visitors from other institutions. For the next flight 36.174, the following activities will be accomplished: (1) prepare the experiment, including replacement and upgrading of critical components, at University of Michigan; (2) pre-integrate the payload at the Wallops Flight Facility; (3) perform final far-UV calibration of instrument (4) perform final alignment, integration, and electrical checks at WSMR; (5) launch payload from WSMR and check condition of recovered payload; (6) perform post-flight calibration, if necessary and applicable (7) reduce and analyze flight data. The following pages contain information from the experimenter package for the Design Review for the next flight, 36.174, listing the plans, changes, and schedule for this flight.

Clarke, John↗
NASA NTRS2015

Briefing to University of Porto on NASA Airborne Science Program and Ames UAVs

NASA Ames is exploring a partnership with the University of Portugal to jointly develop and test new autonomous vehicle technologies. As part of the discussions I will be briefing the University of Portugal faculty on the NASA Airborne Science Program (ASP) and associated activities at NASA Ames Research Center. The presentation will communicate the requirements that drive the program, the assets available to NASA researchers, and discuss research projects that have used unmanned aircraft systems including MIZOPEX, Surprise Valley, and Florida Keys Coral Reef assessment. Other topics will include the SIERRA and Dragon Eye UAV projects operated at Ames.

Test Vehicles↗
NASA NTRS2013

NASA Software Engineering Benchmarking Study

To identify best practices for the improvement of software engineering on projects, NASA's Offices of Chief Engineer (OCE) and Safety and Mission Assurance (OSMA) formed a team led by Heather Rarick and Sally Godfrey to conduct this benchmarking study. The primary goals of the study are to identify best practices that: Improve the management and technical development of software intensive systems; Have a track record of successful deployment by aerospace industries, universities [including research and development (R&D) laboratories], and defense services, as well as NASA's own component Centers; and Identify candidate solutions for NASA's software issues. Beginning in the late fall of 2010, focus topics were chosen and interview questions were developed, based on the NASA top software challenges. Between February 2011 and November 2011, the Benchmark Team interviewed a total of 18 organizations, consisting of five NASA Centers, five industry organizations, four defense services organizations, and four university or university R and D laboratory organizations. A software assurance representative also participated in each of the interviews to focus on assurance and software safety best practices. Interviewees provided a wealth of information on each topic area that included: software policy, software acquisition, software assurance, testing, training, maintaining rigor in small projects, metrics, and use of the Capability Maturity Model Integration (CMMI) framework, as well as a number of special topics that came up in the discussions. NASA's software engineering practices compared favorably with the external organizations in most benchmark areas, but in every topic, there were ways in which NASA could improve its practices. Compared to defense services organizations and some of the industry organizations, one of NASA's notable weaknesses involved communication with contractors regarding its policies and requirements for acquired software. One of NASA's strengths was its software assurance practices, which seemed to rate well in comparison to the other organizational groups and also seemed to include a larger scope of activities. An unexpected benefit of the software benchmarking study was the identification of many opportunities for collaboration in areas including metrics, training, sharing of CMMI experiences and resources such as instructors and CMMI Lead Appraisers, and even sharing of assets such as documented processes. A further unexpected benefit of the study was the feedback on NASA practices that was received from some of the organizations interviewed. From that feedback, other potential areas where NASA could improve were highlighted, such as accuracy of software cost estimation and budgetary practices. The detailed report contains discussion of the practices noted in each of the topic areas, as well as a summary of observations and recommendations from each of the topic areas. The resulting 24 recommendations from the topic areas were then consolidated to eliminate duplication and culled into a set of 14 suggested actionable recommendations. This final set of actionable recommendations, listed below, are items that can be implemented to improve NASA's software engineering practices and to help address many of the items that were listed in the NASA top software engineering issues. 1. Develop and implement standard contract language for software procurements. 2. Advance accurate and trusted software cost estimates for both procured and in-house software and improve the capture of actual cost data to facilitate further improvements. 3. Establish a consistent set of objectives and expectations, specifically types of metrics at the Agency level, so key trends and models can be identified and used to continuously improve software processes and each software development effort. 4. Maintain the CMMI Maturity Level requirement for critical NASA projects and use CMMI to measure organizations developing software for NASA. 5.onsolidate, collect and, if needed, develop common processes principles and other assets across the Agency in order to provide more consistency in software development and acquisition practices and to reduce the overall cost of maintaining or increasing current NASA CMMI maturity levels. 6. Provide additional support for small projects that includes: (a) guidance for appropriate tailoring of requirements for small projects, (b) availability of suitable tools, including support tool set-up and training, and (c) training for small project personnel, assurance personnel and technical authorities on the acceptable options for tailoring requirements and performing assurance on small projects. 7. Develop software training classes for the more experienced software engineers using on-line training, videos, or small separate modules of training that can be accommodated as needed throughout a project. 8. Create guidelines to structure non-classroom training opportunities such as mentoring, peer reviews, lessons learned sessions, and on-the-job training. 9. Develop a set of predictive software defect data and a process for assessing software testing metric data against it. 10. Assess Agency-wide licenses for commonly used software tools. 11. Fill the knowledge gap in common software engineering practices for new hires and co-ops.12. Work through the Science, Technology, Engineering and Mathematics (STEM) program with universities in strengthening education in the use of common software engineering practices and standards. 13. Follow up this benchmark study with a deeper look into what both internal and external organizations perceive as the scope of software assurance, the value they expect to obtain from it, and the shortcomings they experience in the current practice. 14. Continue interactions with external software engineering environment through collaborations, knowledge sharing, and benchmarking.

Rarick, Heather L.↗
NASA NTRS1965

Space reseach at Texas A&M University

Space science research at Texas A and M University - heat transfer, molecular structure, impact attenuation, shell structure, muons, and materials science

UNIVERSITY PROGRAM↗
NASA NTRS1966

Status report

University research in materials, plasma, and engineering for direct energy conversion

PLASMA PHYSICS↗