Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “documentation requirements tracing”

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 37 records · Page 2

Product Structure, the Heart of Product Definition

This paper describes the LMMSS Product Definition System (PDS) philosophy and approach were the use of each item parts document or software can be traced to a specific end item (EI) serial/tail number of the product. It explains why a part-oriented approach to data organization and configuration management is required. The definition of part-oriented is that all appropriate product definition data products will be collected. Referenced and managed by their linkage/relationship to parts/items, The paper will touch upon how LMMSS store/controls product definition information under each project's top product designator in a two tiered approach. One tier for each product end item and another tier which contain/controls listings of drawings, documents. Specifications and standards that are required for hardware item definition.

DeHoog, C., Jr.↗

Managing computer-controlled operations

A detailed discussion of Launch Processing System Ground Software Production is presented to establish the interrelationships of firing room resource utilization, configuration control, system build operations, and Shuttle data bank management. The production of a test configuration identifier is traced from requirement generation to program development. The challenge of the operational era is to implement fully automated utilities to interface with a resident system build requirements document to eliminate all manual intervention in the system build operations. Automatic update/processing of Shuttle data tapes will enhance operations during multi-flow processing.

Plowden, J. B.↗

A Verification-Driven Approach to Traceability and Documentation for Auto-Generated Mathematical Software

Model-based development and automated code generation are increasingly used for production code in safety-critical applications, but since code generators are typically not qualified, the generated code must still be fully tested, reviewed, and certified. This is particularly arduous for mathematical and control engineering software which requires reviewers to trace subtle details of textbook formulas and algorithms to the code, and to match requirements (e.g., physical units or coordinate frames) not represented explicitly in models or code. Both tasks are complicated by the often opaque nature of auto-generated code. We address these problems by developing a verification-driven approach to traceability and documentation. We apply the AUTOCERT verification system to identify and then verify mathematical concepts in the code, based on a mathematical domain theory, and then use these verified traceability links between concepts, code, and verification conditions to construct a natural language report that provides a high-level structured argument explaining why and how the code uses the assumptions and complies with the requirements. We have applied our approach to generate review documents for several sub-systems of NASA s Project Constellation.

Denney, Ewen W.↗

Command and Data Handling Branch Internship

Modular Integrated Stackable Layers (MISL) is a computer system designed for simple, fast, and cost effective flexible reconfiguration in space environments such as the ISS and Orion projects for various uses. Existing applications include wireless and wired communications, data acquisition and instrumentation, and camera systems, and potential applications include bus protocol converters and subsystem control. MISL is based on Texas Instruments (TI)' MSP430 16-bit ultra-low-power microcontroller device. The purpose of my project was to integrate the MISL system with a liquid crystal display (LCD) touchscreen. The LCD, manufactured by Crystalfontz and part number CFAF320240F-035T-TS, is a 320 by 240 RGB resistive color screen including an optional carrier board. The vast majority of the project was done with Altium Designer, a tool for printed circuit board (PCB) schematic capture, 3D design, and FPGA (Field Programmable Gate Array) development. The new PCB was to allow the LCD to directly stack to the rest of MISL. Research was done with datasheets for the TI microcontroller and touchscreen display in order to meet desired hardware specifications. Documentation on prior MISL projects was also utilized. The initial step was to create a schematic for the LCD, power bus, and data bus connections between components. A layout was then designed with the required physical dimensions, routed traces and vias, power and ground planes, layer stacks, and other specified design rules such as plane clearance and hole size. Multiple consultation sessions were held with Hester Yim, the technical discipline lead for the Command and Data Handling Branch, and Christy Herring, the lead PCB layout designer in the Electronic Design and Manufacturing Branch in order to ensure proper configuration. At the moment, the PCB is awaiting revision by the latter-mentioned branch. Afterwards, the board will begin to undergo the manufacturing and testing process. Throughout the internship at Johnson Space Center, I gained several technical and professional skills. I gained proficiency in Altium Designer and experience using subversion clients, as well as knowledge in PSpice with OrCAD and battery design for spaceflight from on-site. I also gained networking, organization, and communication skills throughout meetings with coworkers and other interns. This internship at Johnson Space Center has impacted my future aspirations by further inspiring me to follow a career path into space rated engineering technology and human spaceflight applications. After graduation, I plan to attend graduate Modular Integrated Stackable Layers (MISL) is a computer system designed for simple, fast, and cost effective flexible reconfiguration in space environments such as the ISS and Orion projects for various uses. Existing applications include wireless and wired communications, data acquisition and instrumentation, and camera systems, and potential applications include bus protocol converters and subsystem control. MISL is based on Texas Instruments’ MSP430 16 bit ultra-low power microcontroller device. The purpose of my project was to integrate the MISL system with a liquid crystal display touchscreen. The LCD, manufactured by Crystalfontz and part number CFAF320240F-035T-TS, is a 320x240 RGB resistive color screen including an optional carrier board.The vast majority of the project was done with Altium Designer, a tool for printed circuit board (PCB) schematic capture, 3D design, and FPGA development. The new PCB was to allow the LCD to directly stack to the rest of MISL. Research was done with datasheets for the TI microcontroller and touchscreen display in order to meet desired hardware specifications. Documentation on prior MISL projects was also utilized. The initial step was to create a schematic for the LCD, power bus, and data bus connections between components. A layout was then designed with the required physical dimensions, routed traces and vias, power and ground planes, layer stacks, and other specified design rules such as plane clearance and hole size. Multiple consultation sessions were held with Hester Yim, the technical discipline lead for the Command and Data Handling Branch, and Christy Herring, the lead PCB layout designer in the Electronic Design and Manufacturing Branch in order to ensure proper configuration. At themoment, the PCB is awaiting revision by the latter-mentioned branch. Afterwards, the board will begin to undergo the manufacturing and testing process.Throughout the internship at Johnson Space Center, I gained several technical and professional skills. I gained proficiency in Altium Designer and experience using subversion clients, as well as knowledge in PSpice with OrCAD and battery design for spaceflight from on-site. I also gained networking, organization, and communication skills throughout meetings with coworkers and other interns. This internship at Johnson Space Center has impacted my future aspirations by further inspiring me to follow a career path into space rated engineering technology and human spaceflight applications. After graduation, I plan to attend graduate school for a master's or doctorate degree in electrical or computer engineering.

Billings, Rachel Mae↗

Developing Concepts of Operations Using Multi-Step Tool Techniques With Large Language Models

The National Aeronautics and Space Administration (NASA) Air Mobility Pathfinders (AMP) project is developing and evaluating concepts of operations (ConOps) for safe, secure, and scalable Urban Air Mobility (UAM) operations. The AMP project’s Operational Concepts, Architecture, and Requirements Integration (OCARI) Team is using a Model Based System Engineering (MBSE) approach for integration, interoperability, and traceability of Advanced Air Mobility (AAM) ecosystems centered around urban air taxi services. The team’s goal is to define structures and behaviors needed for system feasibility, readiness, and interoperability, establish a UAM knowledge base, and trace and validate assumptions and requirements relevant to AAM. NASA Langley Research Center (LaRC) is spearheading an innovative digital engineering approach to integrate, communicate, and facilitate the research of multi-modal transportation systems. The Knowledge-based Digital Platform (KbDP) is a concept being developed that ties the workflows of Project Managers (PM), Principal Investigators (PI), and System Engineers together across organizational boundaries. It does so through the management of an information database defined by mathematical, data science, and system engineering principles. Machine Learning (ML) algorithms play a key role in this concept by extracting meaningful knowledge from relational and graph databases, document repositories, and system artifacts, which the human user leverages to greatly improve the efficiency and effectiveness of their research. Recent advancements in the field of Large Language Models (LLMs), specifically models trained for tool use, such as Command-R , now allow for the reliable implementation of single-step and multi-step tool-centric systems. These techniques provide the LLM with a set of tools, in our case Python functions, that can be called on to answer a much wider range of questions compared to LLMs implemented using a traditional single-source or Retrieval Augmented Generation (RAG) approach. Through this method, the LLM can pull information from multiple data sources, such as relational or graph databases, document repositories, application programming interfaces (APIs), and SysML artifacts depending on the user’s question. The LLM can also output the information in a variety of different formats, using output generation tools, such as CSV, UML, or SysML artifacts. Additionally, tools can be assigned roles and can work together to provide answers to queries in an “agent” like approach, similar to that implemented by Microsoft’s AutoGen framework where different agents can converse with each other to accomplish tasks. Previously, our team developed a chatbot system with “agent like” functionality in the form of different “modes” the user could select from a user interface (UI), this architecture can be seen on the left in figure 1. Three different modes were implemented, the first mode allowed the LLM to utilize the structures and algorithms within a graph database to trace UAM requirements. The second mode gave the LLM access to a vector search capable of providing relevant information from thousands of document pages related to UAM ConOps and requirements. The third mode served as a general assistant where users could enter open-ended questions and custom prompts to utilize the LLM for different use-cases. This system improved the process surrounding generating and analyzing information related to UAM requirements, however, the implementation provided a clunky user experience. Users were required to know what mode to select within the UI in advance before entering their question to the selected tool. Moreover, the different tools were isolated from each other, they lacked bidirectional links that would allow for tools to collaborate to generate better responses. Our team is working on a new architecture, seen on the right in the below figure, with the goal to address many of the UX shortcomings of our original system while improving the accuracy and depth of responses from the LLM. This new system will automatically select the appropriate tool to use based off the user’s question. Each tool will be capable of calling on any of the other tools available to the LLM, resulting in a collaborative pipeline where tools can pass data between other tools until enough data is received to generate an answer to the user’s question. Using a locally deployed, open-source, LLM, the NASA OCARI team, in collaboration with Collins Aerospace, will implement a prototype application that will bridge knowledge across multiple sources to assist System Engineers (SEs) with requirements discovery and tracing, research question and use case identification, and assumption validation. Such a system will also allow SEs to more easily, and intuitively, explore the AAM ecosystem, ultimately improving the efficiency and effectiveness of the SE's research and decision-making processes surrounding ConOps development and validation. In this session, our team will provide a video demonstration of our new prototype architecture in action. We will also present an overview of our prototype system architecture and talk about its advantages over traditional LLM deployments along with how those advantages can provide additional value to the field of System Engineering.

systems engineering↗

Trace Gas Analyzer (TGA) program

The design, fabrication, and test of a breadboard trace gas analyzer (TGA) is documented. The TGA is a gas chromatograph/mass spectrometer system. The gas chromatograph subsystem employs a recirculating hydrogen carrier gas. The recirculation feature minimizes the requirement for transport and storage of large volumes of carrier gas during a mission. The silver-palladium hydrogen separator which permits the removal of the carrier gas and its reuse also decreases vacuum requirements for the mass spectrometer since the mass spectrometer vacuum system need handle only the very low sample pressure, not sample plus carrier. System performance was evaluated with a representative group of compounds.

Source record↗

Space station WP-04 power system preliminary analysis and design document, volume 3

Rocketdyne plans to generate a system level specification for the Space Station Electric Power System (EPS) in order to facilitate the usage, accountability, and tracking of overall system level requirements. The origins and status of the verification planning effort are traced and an overview of the Space Station program interactions are provided. The work package level interfaces between the EPS and the other Space Station work packages are outlined. A trade study was performed to determine the peaking split between PV and SD, and specifically to compare the inherent total peaking capability with proportionally shared peaking. In order to determine EPS cost drivers for the previous submittal of DRO2, the life cycle cost (LCC) model was run to identify the more significant costs and the factors contributing to them.

Source record↗

Radio frequency performance of DSS 14 64-meter antenna at X-band using an improved subreflector

The performance of the Deep Space Station (DSS) 14 64-meter antenna X-band gain determined using the X- and K-band Radar feedcone is discussed. Tests prior to, and following the installation of an improved subreflector, proved the unit largely (if not totally) restored initial performance levels at that station. The X-band peak gain with the subreflector is +17.8dBi(area efficiency of 47.3 percent); an increase of +0.47 dB due to the unit installation. The test further showed a significant shift in the axial focus required (function of elevation angle) which, if not implemented operationally, will cause a serious degradation. An historical summary of all documented X-band gain measurements at DSS 14 is included and reviewed. The initial performance is traced through various major configuration changes such as the installation of the X-band dual hybrid mode horn within the operational XRO feedcone. Finally, based on the summary and recent data, a peak X-band antenna gain of +72.1 dBi (area efficiency of 50.8 percent) is projected for the operational feedcone.

Freiley, A. J.↗

Crystal Stratigraphy of Two Basalts from Apollo 16: Unique Crystallization of Picritic Basalt 606063,10-16 and Very-Low-Titanium Basalt 65703,9-13

A geochemical survey of Apollo 16 regolith fragments found five basaltic samples from among hundreds of 2-4 mm regolith fragments of the Apollo 16 site. These included a high-Ti vitrophyric basalt (60603,10-16) and one very-low-titanium (VLT) crystalline basalt (65703,9-13). Apollo 16 was the only highlands sample return mission distant from the maria (approx. 200 km). Identification of basaltic samples at the site not from the ancient regolith breccia indicates input of material via lateral transport by post-basin impacts. The presence of basaltic rocklets and glass at the site is not unprecedented and is required to satisfy mass-balance constraints of regolith compositions. However, preliminary characterization of olivine and plagioclase crystal size distributions indicated the sample textures were distinct from other known mare basalts, and instead had affinities to impact melt textures. Impact melt textures can appear qualitatively similar to pristine basalts, and quantitative analysis is required to distinguish between the two in thin section. The crystal stratigraphy method is a powerful tool in studying of igneous systems, utilizing geochemical analyses across minerals and textural analyses of phases. In particular, trace element signatures can aid in determining the ultimate origin of these samples and variations document subtle changes occurring during their petrogenesis.

Donohue, P. H.↗

Geomagnetic Cutoff Rigidity Computer Program: Theory, Software Description and Example

The access of charged particles to the earth from space through the geomagnetic field has been of interest since the discovery of the cosmic radiation. The early cosmic ray measurements found that cosmic ray intensity was ordered by the magnetic latitude and the concept of cutoff rigidity was developed. The pioneering work of Stoermer resulted in the theory of particle motion in the geomagnetic field, but the fundamental mathematical equations developed have 'no solution in closed form'. This difficulty has forced researchers to use the 'brute force' technique of numerical integration of individual trajectories to ascertain the behavior of trajectory families or groups. This requires that many of the trajectories must be traced in order to determine what energy (or rigidity) a charged particle must have to penetrate the magnetic field and arrive at a specified position. It turned out the cutoff rigidity was not a simple quantity but had many unanticipated complexities that required many hundreds if not thousands of individual trajectory calculations to solve. The accurate calculation of particle trajectories in the earth's magnetic field is a fundamental problem that limited the efficient utilization of cosmic ray measurements during the early years of cosmic ray research. As the power of computers has improved over the decades, the numerical integration procedure has grown more tractable, and magnetic field models of increasing accuracy and complexity have been utilized. This report is documentation of a general FORTRAN computer program to trace the trajectory of a charged particle of a specified rigidity from a specified position and direction through a model of the geomagnetic field.

Smart, D. F.↗

Science Requirements Document for OMI-EOS

A Dutch-Finnish scientific and industrial consortium is supplying the Ozone Monitoring Instrument (OMI) for Earth Observing System-Aura (EOS-Aura). EOS-Aura is the next NASA mission to study the Earth's atmosphere extensively, and successor to the highly successful UARS (Upper Atmospheric Research Satellite) mission. The 'Science Requirements Document for OMI-EOS' presents an overview of the Aura and OMI mission objectives. It describes how OMI fits into the Aura mission and it reviews the synergy with the other instruments onboard Aura to fulfill the mission. This evolves in the Scientific Requirements for OMI (Chapter 3), stating which trace gases have to be measured with what necessary accuracy, in order for OMI to meet Aura's objectives. The most important data product of OMI, the ozone vertical column, densities shall have a better accuracy and an improved global coverage than the predecessor instruments TOMS (Total Ozone Monitoring Spectrometer) and GOME (Global Ozone Monitoring Experiment), which is a.o. achieved by a better signal to noise ratio, improved calibration and a wide field-of-view. Moreover, in order to meet its role on Aura, OMI shall measure trace gases, such as NO2, OClO, BrO, HCHO and SO2, aerosols, cloud top height and cloud coverage. Improved accuracy, better coverage, and finer ground grid than has been done in the past are goals for OMI. After the scientific requirements are defined, three sets of subordinate requirements are derived. These are: the algorithm requirements, i.e. what do the algorithms need in order to meet the scientific requirements; the instrument and calibration requirements, i.e. what has to be measured and how accurately in order to provide the quality of data necessary for deriving the data products; and the validation requirements, i.e. a strategy of how the OMI program will assure that its data products are valid in the atmosphere, at least to the required accuracy.

Levelt, P. F.↗

Satellite-Based Stratospheric and Tropospheric Measurements: Determination of Global Ozone and other Trace Species

This report summarizes research done under NASA Grant NAG5-3461 from November 1, 1996 through December 31, 2000. The research performed during this reporting period includes development and maintenance of scientific software for the GOME retrieval algorithms, consultation on operational software development for GOME, sensitivity and instrument studies to help finalize the definition of the SCIAMACHY instrument, leading the development of the SCIAMACHY Scientific Requirements Document for Data and Algorithm Development, consultation and development for SCIAMACHY near-real-time (NRT) and off-line (OL) data products, radiative transfer model development for utilization in GOME, SCIAMACHY and other programs, development of infrared line-by-line atmospheric modeling and retrieval capability for SCIAMACHY, and participation in GOME and SCIAMACHY validation studies. The Global Ozone Monitoring Experiment was successfully launched on the ERS-2 satellite on April 20, 1995, and remains working in normal fashion. SCIAMACHY is currently planned for launch in late 2001 on the ESA Envisat satellite. Three GOME-2 instruments are now scheduled to fly on the Metop series of operational meteorological satellites (Eumetsat). K. Chance is a member of the reconstituted GOME Scientific Advisory Group, which will guide the GOME-2 program as well as the continuing ERS-2 GOME program.

Chance, K. V.↗

EVA Hand Tool Design Considerations, Development, and General Requirements Interpretation: A Junior Engineer’s Guide

This paper serves as a guide to developing hand tools for use by crewmembers during extravehicular activity (EVA) in outer space. It outlines the fundamentals of EVAs and related provisions, providing a starting point and perspective for engineers unfamiliar with designing equipment to be used during manned spaceflight. Common EVA hardware constraints, which are often unclear, are interpreted and traced back to a source or justification because, as in any design field, fully understanding the basis and intent of a design requirement is needed to properly satisfy it. Lastly, miscellaneous design considerations and lessons learned in tool development are discussed. The information found within is drawn from commonly cited NASA and EVA related documents as well as from professional experiences.

EVA↗

A Survey of NASA Standard Nondestructive Evaluation (NDE)

This document provides a comprehensive review to trace the evolution of NASA’s Standard nondestructive evaluation (NDE) flaw sizes provided in NASA-STD-5009B for fracture-critical metallic spaceflight hardware. A NASA Standard NDE flaw size is considered to be conservative such that most inspectors, trained and certified in the specific method, are expected to provide the required 90/95 probability of detection (POD) for that flaw size. As such, individual certified inspectors are not required to perform POD demonstration testing to be allowed to inspect fracture-critical hardware for that specific method.

Probability of Detection↗

Certifying Auto-Generated Flight Code

Model-based design and automated code generation are being used increasingly at NASA. Many NASA projects now use MathWorks Simulink and Real-Time Workshop for at least some of their modeling and code development. However, there are substantial obstacles to more widespread adoption of code generators in safety-critical domains. Since code generators are typically not qualified, there is no guarantee that their output is correct, and consequently the generated code still needs to be fully tested and certified. Moreover, the regeneration of code can require complete recertification, which offsets many of the advantages of using a generator. Indeed, manual review of autocode can be more challenging than for hand-written code. Since the direct V&V of code generators is too laborious and complicated due to their complex (and often proprietary) nature, we have developed a generator plug-in to support the certification of the auto-generated code. Specifically, the AutoCert tool supports certification by formally verifying that the generated code is free of different safety violations, by constructing an independently verifiable certificate, and by explaining its analysis in a textual form suitable for code reviews. The generated documentation also contains substantial tracing information, allowing users to trace between model, code, documentation, and V&V artifacts. This enables missions to obtain assurance about the safety and reliability of the code without excessive manual V&V effort and, as a consequence, eases the acceptance of code generators in safety-critical contexts. The generation of explicit certificates and textual reports is particularly well-suited to supporting independent V&V. The primary contribution of this approach is the combination of human-friendly documentation with formal analysis. The key technical idea is to exploit the idiomatic nature of auto-generated code in order to automatically infer logical annotations. The annotation inference algorithm itself is generic, and parametrized with respect to a library of coding patterns that depend on the safety policies and the code generator. The patterns characterize the notions of definitions and uses that are specific to the given safety property. For example, for initialization safety, definitions correspond to variable initializations while uses are statements which read a variable, whereas for array bounds safety, definitions are the array declarations, while uses are statements which access an array variable. The inferred annotations are thus highly dependent on the actual program and the properties being proven. The annotations, themselves, need not be trusted, but are crucial to obtain the automatic formal verification of the safety properties without requiring access to the internals of the code generator. The approach has been applied to both in-house and commercial code generators, but is independent of the particular generator used. It is currently being adapted to flight code generated using MathWorks Real-Time Workshop, an automatic code generator that translates from Simulink/Stateflow models into embedded C code.

Denney, Ewen↗

Assessment of Techniques for Measuring Tropospheric H Sub x O Sub y

In its continuing efforts to direct its applications programs towards relevant national needs, NASA is conducting the Tropospheric Chemistry Program, the long-range objective of which is to apply NASA's space technology to assess and predict human impact on the troposphere, particularly on the regional to global scale. One area of required research is instrumentation development, which is aimed at improving the capability to measure important trace gases and aerosols which are key species in the major atmospheric biogeochemical cycles. To focus on specific needs, the Instrumentation Worksphop for H(x)O(y) Tropospheric Species was conducted in August 1982. The workshop discussed current measurement needs and instrument capabilities for H(x)O(y) species, including OH, HO2, and H2O2. The workshop activities and conclusions are documented.

Hoell, J. M.↗

Task Analytic Models to Guide Analysis and Design: Use of the Operator Function Model to Represent Pilot-Autoflight System Mode Problems

Task-analytic models structure essential information about operator interaction with complex systems, in this case pilot interaction with the autoflight system. Such models serve two purposes: (1) they allow researchers and practitioners to understand pilots' actions; and (2) they provide a compact, computational representation needed to design 'intelligent' aids, e.g., displays, assistants, and training systems. This paper demonstrates the use of the operator function model to trace the process of mode engagements while a pilot is controlling an aircraft via the, autoflight system. The operator function model is a normative and nondeterministic model of how a well-trained, well-motivated operator manages multiple concurrent activities for effective real-time control. For each function, the model links the pilot's actions with the required information. Using the operator function model, this paper describes several mode engagement scenarios. These scenarios were observed and documented during a field study that focused on mode engagements and mode transitions during normal line operations. Data including time, ATC clearances, altitude, system states, and active modes and sub-modes, engagement of modes, were recorded during sixty-six flights. Using these data, seven prototypical mode engagement scenarios were extracted. One scenario details the decision of the crew to disengage a fully automatic mode in favor of a semi-automatic mode, and the consequences of this action. Another describes a mode error involving updating aircraft speed following the engagement of a speed submode. Other scenarios detail mode confusion at various phases of the flight. This analysis uses the operator function model to identify three aspects of mode engagement: (1) the progress of pilot-aircraft-autoflight system interaction; (2) control/display information required to perform mode management activities; and (3) the potential cause(s) of mode confusion. The goal of this paper is twofold: (1) to demonstrate the use of the operator functio model methodology to describe pilot-system interaction while engaging modes And monitoring the system, and (2) to initiate a discussion of how task-analytic models might inform design processes. While the operator function model is only one type of task-analytic representation, the hypothesis of this paper is that some type of task analytic structure is a prerequisite for the design of effective human-automation interaction.

Degani, Asaf↗

Applying Standard Independent Verification and Validation (IVV) Techniques Within an Agile Framework: Is There a Compatibility Issue?

Agile methods have gained wide acceptance over the past several years, to the point that they are now a standard management and execution approach for small-scale software development projects. While conventional Agile methods are not generally applicable to large multi-year and mission-critical systems, Agile hybrids are now being developed (such as SAFe) to exploit the productivity improvements of Agile while retaining the necessary process rigor and coordination needs of these projects. From the perspective of Independent Verification and Validation (IVV), however, the adoption of these hybrid Agile frameworks is becoming somewhat problematic. Hence, we find it prudent to question the compatibility of conventional IVV techniques with (hybrid) Agile practices.This paper documents our investigation of (a) relevant literature, (b) the modification and adoption of Agile frameworks to accommodate the development of large scale, mission critical systems, and (c) the compatibility of standard IVV techniques within hybrid Agile development frameworks. Specific to the latter, we found that the IVV methods employed within a hybrid Agile process can be divided into three groups: (1) early lifecycle IVV techniques that are fully compatible with the hybrid lifecycles, (2) IVV techniques that focus on tracing requirements, test objectives, etc. are somewhat incompatible, but can be tailored with a modest effort, and (3) IVV techniques involving an assessment requiring artifact completeness that are simply not compatible with hybrid Agile processes, e.g., those that assume complete requirement specification early in the development lifecycle.

Agile↗