Engineering Papers⌕ Search

Engineering topics

Hihn, Jairus

Publications and source records attributed to Hihn, Jairus.

At least 55 records · Page 3

Experiences with Text Mining Large Collections of Unstructured Systems Development Artifacts at JPL

Often repositories of systems engineering artifacts at NASA's Jet Propulsion Laboratory (JPL) are so large and poorly structured that they have outgrown our capability to effectively manually process their contents to extract useful information. Sophisticated text mining methods and tools seem a quick, low-effort approach to automating our limited manual efforts. Our experiences of exploring such methods mainly in three areas including historical risk analysis, defect identification based on requirements analysis, and over-time analysis of system anomalies at JPL, have shown that obtaining useful results requires substantial unanticipated efforts - from preprocessing the data to transforming the output for practical applications. We have not observed any quick 'wins' or realized benefit from short-term effort avoidance through automation in this area. Surprisingly we have realized a number of unexpected long-term benefits from the process of applying text mining to our repositories. This paper elaborates some of these benefits and our important lessons learned from the process of preparing and applying text mining to large unstructured system artifacts at JPL aiming to benefit future TM applications in similar problem domains and also in hope for being extended to broader areas of applications.

text mining↗

Bootstrapping Process Improvement Metrics: CMMI Level 4 Process Improvement Metrics in a Level 3 World

The measurement techniques for organizations which have achieved the Software Engineering Institutes CMMI Maturity Levels 4 and 5 are well documented. On the other hand, how to effectively measure when an organization is Maturity Level 3 is less well understood, especially when there is no consistency in tool use and there is extensive tailoring of the organizational software processes. Most organizations fail in their attempts to generate, collect, and analyze standard process improvement metrics under these conditions. But at JPL, NASA's prime center for deep space robotic exploration, we have a long history of proving there is always a solution: It just may not be what you expected. In this paper we describe the wide variety of qualitative and quantitative techniques we have been implementing over the last few years, including the various approaches used to communicate the results to both software technical managers and senior managers.

Hihn, Jairus↗

Risk Identification and Visualization in a Concurrent Engineering Team Environment

Incorporating risk assessment into the dynamic environment of a concurrent engineering team requires rapid response and adaptation. Generating consistent risk lists with inputs from all the relevant subsystems and presenting the results clearly to the stakeholders in a concurrent engineering environment is difficult because of the speed with which decisions are made. In this paper we describe the various approaches and techniques that have been explored for the point designs of JPL's Team X and the Trade Space Studies of the Rapid Mission Architecture Team. The paper will also focus on the issues of the misuse of categorical and ordinal data that keep arising within current engineering risk approaches and also in the applied risk literature.

Risk Scoring↗

How Spreadsheets Get Us to Mars and Beyond

Spreadsheets, spreadsheets everywhere and nary a page of documentation. JPL is NASA's prime center for deep space missions. In all of our missions, spreadsheets have played a major role in managing parts lists, managing requirements, monitoring progress, planning budgets, developing the initial concept designs, and providing the backbone of our infrastructure. In this paper we will share our lessons learned in building various spreadsheet intensive systems and applications. Based on our experience in developing and using these various systems we will propose a number of exploratory ideas as to the dimensions of spreadsheet system complexity. In addition, we will share our approaches to documentation, review, and verification of these types of systems.

testing↗

Spreadsheets in Team X: Preserving Order in an Inherently Chaotic Environment

JPL is NASA's prime center for deep space missions. In response to the need to reduce the cost and time to complete early concept studies and proposals JPL created the first concurrent engineering team in the aerospace industry: Team X. Started in 1995, Team X has carried out over 800 studies, dramatically reducing the time and cost involved, and has been the model for other concurrent engineering teams both within NASA and throughout the larger aerospace community. Since its inception, the software backbone of this highly successful design team - engaged in examining some of NASA's cutting edge concepts - has been the unassuming spreadsheet. Over the years the Team X spreadsheet-based tools have evolved from simple standalone engineering models into a networked spreadsheet intensive system with real time parameter updating. Recent new capabilities include stochastic cost estimation and a graphical drag and drop block diagram that automatically populates the related spreadsheet parameters of cost, mass and power. This paper describes how the spreadsheet functions within Team X: its history, architecture, current capabilities, enabling strengths and persistent weaknesses. In addition, the verification methods and institutional oversight that have evolved as the Team X products became increasingly critical to Laboratory success are also discussed.

concurrent engineering↗

Estimating Software-Development Costs With Greater Accuracy

COCOMOST is a computer program for use in estimating software development costs. The goal in the development of COCOMOST was to increase estimation accuracy in three ways: (1) develop a set of sensitivity software tools that return not only estimates of costs but also the estimation error; (2) using the sensitivity software tools, precisely define the quantities of data needed to adequately tune cost estimation models; and (3) build a repository of software-cost-estimation information that NASA managers can retrieve to improve the estimates of costs of developing software for their project. COCOMOST implements a methodology, called '2cee', in which a unique combination of well-known pre-existing data-mining and software-development- effort-estimation techniques are used to increase the accuracy of estimates. COCOMOST utilizes multiple models to analyze historical data pertaining to software-development projects and performs an exhaustive data-mining search over the space of model parameters to improve the performances of effort-estimation models. Thus, it is possible to both calibrate and generate estimates at the same time. COCOMOST is written in the C language for execution in the UNIX operating system.

Baker, Dan↗

Software Development Cost: How Much? You Sure? Technical Summary

This slide presentation reports on findings from analyzing a NASA COCOMO 81 dataset with 93 records. The current tool is called COSEEKMO, using a methodology can be applied to any set of cost models and data. The effort was part of a research initiative funded by the NASA Office of Safety and Mission and Assurance (OSMA) aimed at improving software reliability.

software effort estimation↗

Studies in Software Cost Model Behavior: Do We Really Understand Cost Model Performance?

While there exists extensive literature on software cost estimation techniques, industry practice continues to rely upon standard regression-based algorithms. These software effort models are typically calibrated or tuned to local conditions using local data. This paper cautions that current approaches to model calibration often produce sub-optimal models because of the large variance problem inherent in cost data and by including far more effort multipliers than the data supports. Building optimal models requires that a wider range of models be considered while correctly calibrating these models requires rejection rules that prune variables and records and use multiple criteria for evaluating model performance. The main contribution of this paper is to document a standard method that integrates formal model identification, estimation, and validation. It also documents what we call the large variance problem that is a leading cause of cost model brittleness or instability.

data mining↗

The impact of organizational structure on flight software cost risk

This paper summarizes the final results of the follow-up study updating the estimated software effort growth for those projects that were still under development and including an evaluation of the roles versus observed cost risk for the missions included in the original study which expands the data set to thirteen missions.

software cost↗