Engineering topics

Stark, Michael

Publications and source records attributed to Stark, Michael.

5 records

NASA NTRS2002

Integrating Theory and Practice: Applying the Quality Improvement Paradigm to Product Line Engineering

My assertion is that not only are product lines a relevant research topic, but that the tools used by empirical software engineering researchers can address observed practical problems. Our experience at NASA has been there are often externally proposed solutions available, but that we have had difficulties applying them in our particular context. We have also focused on return on investment issues when evaluating product lines, and while these are important, one can not attain objective data on success or failure until several applications from a product family have been deployed. The use of the Quality Improvement Paradigm (QIP) can address these issues: (1) Planning an adoption path from an organization's current state to a product line approach; (2) Constructing a development process to fit the organization's adoption path; (3) Evaluation of product line development processes as the project is being developed. The QIP consists of the following six steps: (1) Characterize the project and its environment; (2) Set quantifiable goals for successful project performance; (3) Choose the appropriate process models, supporting methods, and tools for the project; (4) Execute the process, analyze interim results, and provide real-time feedback for corrective action; (5) Analyze the results of completed projects and recommend improvements; and (6) Package the lessons learned as updated and refined process models. A figure shows the QIP in detail. The iterative nature of the QIP supports an incremental development approach to product lines, and the project learning and feedback provide the necessary early evaluations.

Stark, Michael↗

NASA NTRS2000

Supporting Development of Satellite's Guidance Navigation and Control Software: A Product Line Approach

The NASA Goddard Space Flight Center Flight Software Branch (FSB) is developing a Guidance, Navigation, and Control (GNC) Flight Software (FSW) product line. The demand for increasingly more complex flight software in less time while maintaining the same level of quality has motivated us to look for better FSW development strategies. The GNC FSW product line has been planned to address the core GNC FSW functionality very similar on many recent low/near Earth missions in the last ten years. Unfortunately these missions have not accomplished significant drops in development cost since a systematic approach towards reuse has not been adopted. In addition, new demands are continually being placed upon the FSW which means the FSB must become more adept at providing GNC FSW functionality's core so it can accommodate additional requirements. These domain features together with engineering concepts are influencing the specification, description and evaluation of FSW product line. Domain engineering is the foundation for emerging product line software development approaches. A product line is 'A family of products designed to take advantage of their common aspects and predicted variabilities'. In our product line approach, domain engineering includes the engineering activities needed to produce reusable artifacts for a domain. Application engineering refers to developing an application in the domain starting from reusable artifacts. The focus of this paper is regarding the software process, lessons learned and on how the GNC FSW product line manages variability. Existing domain engineering approaches do not enforce any specific notation for domain analysis or commonality and variability analysis. Usually, natural language text is the preferred tool. The advantage is the flexibility and adapt ability of natural language. However, one has to be ready to accept also its well-known drawbacks, such as ambiguity, inconsistency, and contradictions. While most domain analysis approaches are functionally oriented, the idea of applying the object-oriented approach in domain analysis is not new. Some authors propose to use UML as the notation underlying domain analysis. Our work is based on the same idea of merging UML and domain analysis. Further, we propose a few extensions to UML in order to express variability, and we define precisely their semantics so that a tool can support them. The extensions are designed to be implemented on the API of a popular industrial CASE tool, with obvious advantages in cost and availability of tool support. The paper outlines the product line processes and identifies where variability must be addressed. Then it describes the product line products with respect to how they accommodate variability. The Celestial Body subdomain is used as a working example. Our results to date are summarized and plans for the future are described.

McComas, David↗

NASA NTRS1996

South Atlantic Anomaly Entry and Exit as Measured by the X-Ray Timing Explorer

The Rossi X-ray Timing Explorer (RXTE) carries instruments that must switch off high voltages (HV) when passing through the South Atlantic Anomaly (SAA). The High Energy X-ray Timing Experiment (HEXTE) contains a particle monitor that detects the increased particle flux associated with the SAA and autonomously reduces its voltage. The Proportional Counter Array (PCA) relies on uplinked predictions of SAA entry/exit times based on ephemeris data provided by the Flight Dynamics Facility. A third instrument, the All-Sky Monitor (ASM) also uses a predicted SAA model to reduce voltage when passing through the SAA. Data collected from the HEXTE particle monitor, as well as other instrument readings near the times of SAA entry/exit offer the potential for refining models of the boundaries of the SAA. The SAA has an increased particle flux which causes high rates of detection in the RXTE instruments designed to observe x-rays. The high counting rates could degrade the PCA if HV is not reduced during SAA passages. On the other hand, PCA downtime can be minimized and the science return can be optimized by having the best possible model of the SAA boundary. Thus, the PCA team planned an extensive effort during in-orbit checkout to utilize both the HEXTE particle monitor data and instrument counting rates to refine the model of the SAA boundary. The times of SAA entry and exit are compared with the definitive epemeris to determine the precise location (latitude and longitude) of the SAA boundary. Over time, the SAA and its perimeter were mapped. The RXTE Science Operations Center is continuously working to feed back the results of this effort into the science scheduling process, improving the SAA model as it affects the RXTE instruments, thus obtaining more accurate estimates of the SAA entry/exit times.

Smith, Evan↗

NASA NTRS1992

Impacts of object-oriented technologies: Seven years of SEL studies

The premise that object-oriented technology (OOT) is the most significant technology ever examined by the Software Engineering Laboratory is examined. The evolution of the use of OOT in the Software Engineering Laboratory (SEL) 'experience factory' is described in terms of the SEL's original expectations, focusing on how successive generations of projects have used OOT. General conclusions are drawn on how the usage of the technology has evolved in this environment.

Stark, Michael↗

NASA NTRS1987

Ada training evaluation and recommendation

This paper documents the Ada training experiences and recommendations of the Gamma Ray Observatory dynamics simulator Ada development team. A two month Ada training program for software developers is recommended which stresses the importance of teaching design methodologies early, as well as the use of certain training aids such as videotaped lectures and computer-aided instruction. Furthermore, a separate training program for managers is recommended, so that they may gain a better understanding of modified review products and resource allocation associated with Ada projects.

Murphy, Robert↗