Large Area Crop Inventory Experiment (LACIE). Baseline documentation; LACIE project plan
There are no author-identified significant results in this report.
Source record↗
SEARCH · Search NASA
Results for “project documentation”
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.
Project analysis and integration area
The objective of the Project Analysis and Integration Area (PA&I) is to support the planning, analysis, integration, and decision making activities of the Flat-plate Solar Array FSA) Project. Accordingly, PA&I supports the Project by developing and documenting Project plans based, in part, on the technical and economic assessments performed by PA&I of the various technical options. Goals for module technical performance and costs, derived from National Photovoltaics Program goals, are established by PA&I for each of the major technical activities in the Project. Assessments of progress toward achievement of goals are made to guide decision making within the Project.
Source record↗
Digital imaging technology assessment: Digital document storage project
An ongoing technical assessment and requirements definition project is examining the potential role of digital imaging technology at NASA's STI facility. The focus is on the basic components of imaging technology in today's marketplace as well as the components anticipated in the near future. Presented is a requirement specification for a prototype project, an initial examination of current image processing at the STI facility, and an initial summary of image processing projects at other sites. Operational imaging systems incorporate scanners, optical storage, high resolution monitors, processing nodes, magnetic storage, jukeboxes, specialized boards, optical character recognition gear, pixel addressable printers, communications, and complex software processes.
Source record↗
NASA's Advanced Multimission Operations System: A Case Study in Formalizing Software Architecture Evolution
All software systems of significant size and longevity eventually undergo changes to their basic architectural structure. Such changes may be prompted by evolving requirements, changing technology, or other reasons. Whatever the cause, software architecture evolution is commonplace in real world software projects. Recently, software architecture researchers have begun to study this phenomenon in depth. However, this work has suffered from problems of validation; research in this area has tended to make heavy use of toy examples and hypothetical scenarios and has not been well supported by real world examples. To help address this problem, I describe an ongoing effort at the Jet Propulsion Laboratory to re-architect the Advanced Multimission Operations System (AMMOS), which is used to operate NASA's deep-space and astrophysics missions. Based on examination of project documents and interviews with project personnel, I describe the goals and approach of this evolution effort and then present models that capture some of the key architectural changes. Finally, I demonstrate how approaches and formal methods from my previous research in architecture evolution may be applied to this evolution, while using languages and tools already in place at the Jet Propulsion Laboratory.
software architecture evolution↗
Explanation of Change Cost and Schedule Growth Study Interim Status Briefing
This slide presentation reviews the study to understand the changes in cost and schedule growth for NASA projects. A second goal was to determine the percentage of growth that was outside the control of the project. The study examined project documentation, conducted interviews with key project personnel, and allocated growth events to an Explanation of Change (EoC) tree to quantify the reasons for growth in the scheduled time. This briefing reviews the results of the study of the first 20 missions.
Croonce, Thomas↗
Analysis of Lidar Remote Sensing Concepts
An orbiting coherent Doppler lidar for measuring winds is required to provide two basic pieces of data to the user community. The first is the line of sight wind velocity and the second is knowledge of the position at which the measurement was made. In order to obtain this data for targets of interest to the atmospheric community the instrument must also have a level of backscatter sensitivity sufficient to achieve the goal. Sensitivity analyses for the line of sight velocity and position requirements for two lidar instruments, one with a nadir angle of 30 deg. in a 300 km altitude, 58 deg. inclination orbit and the second for a 45 deg. nadir angle instrument in a 833 km altitude , 89 deg. inclination orbit are performed. The issues relating to the backscatter sensitivity of a coherent lidar have been well documented previously and are not discussed here other than to identify a space-specific issue that does not typically need to be considered for ground and aircraft based coherent lidars. Section 2 and appendices A1 and A2 document these sensitivity analyses. This contract was intended to develop requirements for a space shuttle (STS) based coherent lidar however, shortly after the award of this contract NASA MSFC won the SPARCLE program to put a coherent Doppler lidar on STS. Consequently much of the work conducted under this contract has been documented within the development of the SPARCLE project documentation. The relevant portions of the SPARCLE documentation are identified in section 3.0 and included in appendices A3 and A4. Section 4.0 briefly outlines miscellaneous other activities that occurred under this contract.
Spiers, Gray D.↗
NASA software documentation standard software engineering program
The NASA Software Documentation Standard (hereinafter referred to as Standard) can be applied to the documentation of all NASA software. This Standard is limited to documentation format and content requirements. It does not mandate specific management, engineering, or assurance standards or techniques. This Standard defines the format and content of documentation for software acquisition, development, and sustaining engineering. Format requirements address where information shall be recorded and content requirements address what information shall be recorded. This Standard provides a framework to allow consistency of documentation across NASA and visibility into the completeness of project documentation. This basic framework consists of four major sections (or volumes). The Management Plan contains all planning and business aspects of a software project, including engineering and assurance planning. The Product Specification contains all technical engineering information, including software requirements and design. The Assurance and Test Procedures contains all technical assurance information, including Test, Quality Assurance (QA), and Verification and Validation (V&V). The Management, Engineering, and Assurance Reports is the library and/or listing of all project reports.
Source record↗
NASA Software Documentation Standard
The NASA Software Documentation Standard (hereinafter referred to as "Standard") is designed to support the documentation of all software developed for NASA; its goal is to provide a framework and model for recording the essential information needed throughout the development life cycle and maintenance of a software system. The NASA Software Documentation Standard can be applied to the documentation of all NASA software. The Standard is limited to documentation format and content requirements. It does not mandate specific management, engineering, or assurance standards or techniques. This Standard defines the format and content of documentation for software acquisition, development, and sustaining engineering. Format requirements address where information shall be recorded and content requirements address what information shall be recorded. This Standard provides a framework to allow consistency of documentation across NASA and visibility into the completeness of project documentation. The basic framework consists of four major sections (or volumes). The Management Plan contains all planning and business aspects of a software project, including engineering and assurance planning. The Product Specification contains all technical engineering information, including software requirements and design. The Assurance and Test Procedures contains all technical assurance information, including Test, Quality Assurance (QA), and Verification and Validation (V&V). The Management, Engineering, and Assurance Reports is the library and/or listing of all project reports.
Source record↗
Microgravity Experiments Safety and Integration Requirements Document Tree
This report is a document tree of the safety and integration documents required to develop a space experiment. Pertinent document information for each of the top level (tier one) safety and integration documents, and their applicable and reference (tier two) documents has been identified. This information includes: document title, revision level, configuration management, electronic availability, listed applicable and reference documents, source for obtaining the document, and document owner. One of the main conclusions of this report is that no single document tree exists for all safety and integration documents, regardless of the Shuttle carrier. This document also identifies the need for a single point of contact for customers wishing to access documents. The data in this report serves as a valuable information source for the NASA Lewis Research Center Project Documentation Center, as well as for all developers of space experiments.
Hogan, Jean M.↗
Electronic availability of microgravity experiments safety and integration requirements documents
This follow-on to NASA Contractor Report 195447, Microgravity Experiments Safety and Integration Requirements Document Tree, provides the details for accessing the systems that contain the official, electronic versions of the documents initially researched in NASA Contractor Report 195447. The data in this report serves as a valuable information source for the NASA Lewis Research Center Project Documentation Center (PDC), as well as for all developers of space experiments. The PDC has acquired the hardware, software, ID's, and passwords necessary to access most of these systems and is now able to provide customers with current document information as well as immediate delivery of available documents in either electronic or hard copy format.
Hogan, Jean M.↗
Software Project Management and Measurement on the World-Wide-Web (WWW)
We briefly describe a system for forms-based, work-flow management that helps members of a software development team overcome geographical barriers to collaboration. Our system, called the Web Integrated Software Environment (WISE), is implemented as a World-Wide-Web service that allows for management and measurement of software development projects based on dynamic analysis of change activity in the workflow. WISE tracks issues in a software development process, provides informal communication between the users with different roles, supports to-do lists, and helps in software process improvement. WISE minimizes the time devoted to metrics collection and analysis by providing implicit delivery of messages between users based on the content of project documents. The use of a database in WISE is hidden from the users who view WISE as maintaining a personal 'to-do list' of tasks related to the many projects on which they may play different roles.
Callahan, John↗
A Model-Based Systems Engineering Journey to Developing a Concept of Operations
Starting in 2017, NASA’s Human Research Program (HRP) Exploration Medical Capability (ExMC) element began a systems engineering transition from traditional, document-centric development to model-centric development when defining its foundation medical systems. These foundation medical systems define a Concept of Operations (ConOps) and identify the generic requirements for a medical system based on assumptions about a generic crew and mission environments and guidance from NASA standards (e.g., Medical “Levels of Care”). By making the transition, ExMC intends to improve communication among stakeholders about foundation medical system requirements and content. In addition, this transition will enable ExMC to lower both development and crew treatment risks for future, mission-specific medical systems. ExMC followed a Model Based Systems Engineering (MBSE) paradigm when developing the foundation medical systems. A model-based approach provides several advantages over a traditional, document-centric approach. First, when Systems Engineers (SE) develop diagrams in a model using a standard modeling language, they produce information dense pictures that facilitate understanding much more efficiently with less room for misinterpretation than text. Second, due to the evolving nature of projects, documentation becomes out of date the minute it is published. This can result in people making decisions based on information that is no longer current, especially if they are referencing a locally-stored copy of a document. A model, on the other hand, is always up to date with the latest approved changes and information. It serves as a single point of truth. Third, a model-centric approach centralizes all important information in one place. Rather than having to flip through separate ConOps documents, design specifications, requirements specifications, and the like to coordinate information, a model captures the content in one, integrated spot. This integration makes tracing information from end-to-end easier with greater reliability. The ExMC Systems Engineering Lifecycle follows a well-defined process. ExMC Systems Engineers perform all major steps of the process, regardless of the development methodology. One of the first steps in the process is developing the ConOps that describes the operation of the system from the point of view of the users. It includes a list of the users and their needs, the goals of the medical system, key assumptions about the system, and definitions of the medical system’s operational environments. For this development effort, ExMC chose to replace the traditional text-based ConOps document with a model. While the decision to change the development workflow was not difficult, implementing the structural and organizational workflows were. It required showing ExMC’s users, most of whom are not Systems Engineers, how the information they require would be presented in the model and to gain their acceptance of this approach. This paper documents key lessons learned during the ConOps transformation by focusing on how the model represents information, the agile workflow used by SEs when developing the model and how it integrates into a project plan, how leadership influenced key users to accept the transformation, and how the users interact with the model information.
Jeffrey Robert Cohen↗
Telescience Resource Kit Software Lifecycle
The challenge of a global operations capability led to the Telescience Resource Kit (TReK) project, an in-house software development project of the Mission Operations Laboratory (MOL) at NASA's Marshall Space Flight Center (MSFC). The TReK system is being developed as an inexpensive comprehensive personal computer- (PC-) based ground support system that can be used by payload users from their home sites to interact with their payloads on board the International Space Station (ISS). The TReK project is currently using a combination of the spiral lifecycle model and the incremental lifecycle model. As with any software development project, there are four activities that can be very time consuming: Software design and development, project documentation, testing, and umbrella activities, such as quality assurance and configuration management. In order to produce a quality product, it is critical that each of these activities receive the appropriate amount of attention. For TReK, the challenge was to lay out a lifecycle and project plan that provides full support for these activities, is flexible, provides a way to deal with changing risks, can accommodate unknowns, and can respond to changes in the environment quickly. This paper will provide an overview of the TReK lifecycle, a description of the project's environment, and a general overview of project activities.
Griner, Carolyn S.↗
A Frank Discussion on Lessons Learned From Adopting and Applying NASA-STD-6030 for Spaceflight Systems
With the advancement and adoption of Additive Manufacturing (AM) for spaceflight systems, numerous lessons have been learned during the qualification and certification of AM components. The lessons learned covered in this presentation will provide an overview of the challenges faced by NASA centers and commercial partners working to design AM hardware that complies with NASA-STD-6030 Additive Manufacturing Requirements (AMR). Topics of interest include tailoring of requirements for specific projects, documentation requirements, and addressing conservative approaches towards mechanical property development and analysis. In addition to that, this presentation aims to impress that these lessons learned will influence the future revisions of the NASA technical standard to facilitate and advance AM technology adoption on NASA projects.
Additive Manufacturing↗
Intelligent search and retrieval of a large multimedia knowledgebase for the Hubble Space Telescope
A document-retrieval assistant (DRA) in a microcomputer format is described which incorporates hypertext and natural language capabilities. Hypertext is used to introduce an intelligent search capability, and the natural-language interface permits access to specific data without the use of keywords. The DRA can be used to access and 'browse' the large multimedia database that is composed of project documentation from the HST.
Clapis, Paul J.↗
Phased Project Planning Guidelines
NHB 7121.2 is the initial publication of the guidelines for implementation of the Phased Project Planning (PPP) concept prescribed by NPD 7121,1A. These guidelines are applicable to the planning and approval activities which lead to the implementation of major new research and development projects as defined in NPD 7121.1A as well as to major modifications or extensions of approved projects. They should, therefore, be reflected in the Project Approval Documents which serve as the basic documentation for project definition, guidance and control throughout NASA. The purpose of PPP is to provide, through defined phases, an adequate basis for management decisions on the extent to which project activities can be properly undertaken and commitments made. However, these guidelines do not prescribe detailed format and content of plans and other documents and reports used to apply the PPP concept. Similarly, the work content of phases and the information requirements described herein are not checklists. They are included to assist in understanding the intent of the PPP concept and should not be viewed as rigid or inflexible. PPP, as a concept for orderly planning and definition of new major R&D undertakings, must be adapted to the peculiarities of each individual case. However, the flexibility permitted for adaptation should not be considered as a license for major variation which would compromise the objectives that underlie the concept. Cognizant NASA officials are expected to pursue their project planning and definition activities in reasonable conformance with these guidelines and to request only those exceptions or deviations which are clearly necessary and justified. These guidelines will be modified as determined necessary on the basis of experience. Comments or suggestions for changes should be directed to the Office of Organization and Management.
Source record↗
Scanning NASTRAN output data for maximum and minimum values
A computer program called NASCAN (NASTRAN scan) is described. NASCAN enables users to scan lengthy NASTRAN output files for maximum and minimum values in easy user oriented categories. Areas of high stress or deflections in any of the NASTRAN rigid formats are quickly detected and listed out for project documentations. The NASTRAN model is then revised if necessary by updating an input file tape which is processed through the NASTRAN program.
Walker, D. C.↗
A postprocessor system for the data reduction and post analysis of NASTRAN results
NASTRAN analysis results are scanned to determine maximum and minimum displacements, forces and stresses. Allowables and margins of safety are computed, and in the case of multiple loading conditions, envelopes for displacements, forces, stresses and margins of safety are also produced for specified element sets. Graphical plots of the reduced or the regular NASTRAN results may be obtained superimposed either of a developed fuselage strip or on a projection of any specified part of the finite element model. The use of the data reduction, post analysis and graphical plotting capabilities provide the analyst with a fast and convenient tool for the study of NASTRAN analysis results and their presentation for project documentation.
Raibstein, A. I.↗