Extracting Acyclic Dependency Models from Quality Standards for COTS Software Evaluation

AIAA Infotech@Aerospace 2007 Conference and Exhibit

2007

Previous research has shown that acyclic dependency models, if they exist, can be extracted from software quality standards and that these models can be used to assess software safety and product quality. In the case of commercial off-the-shelf (COTS) software, the extracted dependency model can be used in a probabilistic Bayesian network context for COTS software evaluation. Furthermore, while experts typically employ Bayesian networks to encode domain knowledge, secondary structures (clique trees) from Bayesian network graphs can be used to determine the probabilistic distribution of any software variable (attribute) using any clique that contains that variable. Secondary structures, therefore, provide insight into the fundamental nature of graphical networks. This paper will apply secondary structure calculations to reveal the clique tree of the acyclic dependency model extracted from the ISO/IEC 9126-1 software quality standard. Suggestions will be provided to describe how the clique tree may be exploited to aid efficient transformation of an evaluation model. Nomenclature

Section: Dependency Model Extraction From Software Quality Standardsmentioning

confidence: 99%

Section: A Cots Software Evaluationsmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Revealing the ISO/IEC 9126-1 Clique Tree for COTS Software Evaluation

AIAA Infotech@Aerospace 2007 Conference and Exhibit

2007

“…Third, the graphical representation could be used to justify the reasoning thereby clearly explaining why a candidate is hired or not in a consistent and unambiguous fashion. Dr. Terry Morris, a NASA researcher with expertise in commercial off-the-shelf (COTS) software evaluations, developed a process by which expert knowledge could be extracted and used formally in a comparative evaluation 25 . This section will be used to describe how Morris's process can be adapted in developing an emotional competence dependency model.…”

Section: Emotional Competence Dependency Modelmentioning

confidence: 99%

The Integrated Hazard Analysis Integrator

AIAA Infotech@Aerospace Conference

Massie²

2009

Hazard analysis addresses hazards that arise in the design, development, manufacturing, construction, facilities, transportation, operations and disposal activities associated with hardware, software, maintenance, operations and environments. An integrated hazard is an event or condition that is caused by or controlled by multiple systems, elements, or subsystems. Integrated hazard analysis (IHA) is especially daunting and ambitious for large, complex systems such as NASA's Constellation program which incorporates program, systems and element components that impact others (International Space Station, public, International Partners, etc.). An appropriate IHA should identify all hazards, causes, controls and verifications used to mitigate the risk of catastrophic loss of crew, vehicle and/or mission. Unfortunately, in the current age of increased technology dependence, there is the tendency to sometimes overlook the necessary and sufficient qualifications of the integrator, that is, the person/team that identifies the parts, analyzes the architectural structure, aligns the analysis with the program plan and then communicates/coordinates with large and small components, each contributing necessary hardware, software and/or information to prevent catastrophic loss. As viewed from both Challenger and Columbia accidents, lack of appropriate communication, management errors and lack of resources dedicated to safety were cited as major contributors to these fatalities. From the accident reports, it would appear that the organizational impact of managers, integrators and safety personnel contributes more significantly to mission success and mission failure than purely technological components. If this is so, then organizations who sincerely desire mission success must put as much effort in selecting managers and integrators as they do when designing the hardware, writing the software code and analyzing competitive proposals. This paper will discuss the necessary and sufficient requirements of one of the significant contributors to mission success, the IHA integrator. Discussions will be provided to describe both the mindset required as well as deleterious assumptions/behaviors to avoid when integrating within a large scale system. Nomenclature CIS= conditional independence statement CPD = conditional probability distribution DAG = directed acyclic graph DRM = design reference mission ESMD = Exploration Systems Mission Directorate FHA = Functional Hazard Analysis G = a graph of topological dependence structure I (.,.|.)

“…Subsequently, there are issues of how to incorporate these attributes to quantify evaluation metrics. Morris and Beling 1 have recently developed a process that extracts attribute dependency models from software quality standards for COTS software evaluation. In their research, the definition and structure of software attributes and their relationships are extracted in the form of a dependency model that can be quantified probabilistically using historical COTS software data in the context of Bayesian causal networks.…”

Section: Introductionmentioning

confidence: 99%

A Probabilistic Software System Attribute Acceptance Paradigm for COTS Software Evaluation

2005

Infotech@Aerospace

Standard software requirement formats are written from top-down perspectives only, that is, from an ideal notion of a client's needs. Despite the exactness of the standard format, software and system errors in designed systems have abounded. Bad and inadequate requirements have resulted in cost overruns, schedule slips and lost profitability. Commercial off-the-shelf (COTS) software components are even more troublesome than designed systems because they are often provided as is and subsequently delivered with unsubstantiated validation of described capabilities. For COTS software, there needs to be a way to express the client's software needs in a consistent and formal manner using software system attributes derived from software quality standards. Additionally, the format needs to be amenable to software evaluation processes that integrate observable evidence garnered from historical data. This paper presents a paradigm that effectively