Hyeonjeong Kim

Recent Catastrophic Accidents: Investigating How Software was Responsible

Areas crucial to life such as medicine, transportation, nuclear-energy research and industry, aeronautics, and others, all make use of software in one way or another. However, the application of software to such domains means that the software may now become safety-critical such that an error in the software or an error in its use could have devastating consequences. This paper reviews 14 recent accidents, several of which resulted in the loss of life in addition to time and money, and identifies the role(s) that software played as an important causative factor. The useful lessons which can be learned from the accidents are also presented, which can then act as principles and guidelines to avoid the recurrence of similar accidents in the future.

Bridging the Gap between Fault Trees and UML State Machine Diagrams for Safety Analysis

Poorly designed software systems are one of main causes of accidents in safety-critical systems, and thus, the importance of safety analysis for software has greatly increased over the recent years. Software safety can be improved by analyzing both its desired and undesired behaviors, and this in turn requires expressive power such that both can be modeled. However, there is a considerable gap between modeling methods for desired and undesired behaviors. Therefore, we propose a method to bridge the gap between fault trees (for undesired behavior) and UML state machine diagrams (for desired behavior). More specifically, we present rules and algorithms that facilitate the transformation of a hazard (in the context of fault trees) to a UML state machine diagram. We illustrate our proposed approach via an example on a microwave-oven system. Our proposed transformation can help engineers identify how the hazards may occur, thereby allowing them to prevent the hazard from occurring.

An Embedded Software Reliability Model with Consideration of Hardware Related Software Failures

As software in an embedded system has taken charge of controlling both software and hardware components, the importance of estimating more accurate reliability for such software has been increased. To estimate the reliability of target software systems, software reliability models are often utilized with software failure data. Since software and hardware are highly co-related and frequently interact with each other in embedded systems, both of them are contributing factors to software failures. Thus, the influence of software and hardware faults on software failures should be taken account for to estimate software reliability. However, many researchers have developed software reliability models assuming that software failures are caused by only software faults, which might lead to inaccurate reliability estimation. In this paper, we suggest two new reliability models considering software and hardware faults as root causes of software failures for embedded software reliability estimation. The proposed models are compared with existing models for validity, and analysis results of the models with real project data are presented. The experimental results show that a Weibull based model, which takes characteristics of hardware degradation into account, has higher fitting-adequacy and superior accuracy for software reliability estimation. Through these results, the proposed model provides more accurate software reliability estimation and helps setting better testing strategies in the earlier phases of the embedded software testing.

Developing a software process simulation model using SPEM and analytical models

To develop Software Process Simulation Models (SPSMs) more effectively, we need to consider the following issues: reducing the knowledge difference between increasing the reusability of a simulation model, decreasing the complexity of a simulation model, and mitigating the lack of historical data. We propose an approach to develop an SPSM based on SPEM, and widely adopted analytical models. An SPEM-based process model is integrated with the quantitative information and transformed into a DEVS-Hybrid SPSM. Our approach resolves the issues by the transformation algorithms, the hierarchical and modularised modelling properties of SPEM and DEVS, and widely adopted analytical models.

Change Impact Analysis of a Software Process Using Process Slicing

A software process needs to be changed for various reasons during or before its enactment. To accommodate the change in the software process, it is necessary to analyze the impacts of the change. Few researches provide the methods to structurally analyze the impacts of the change for a software process or workflow with limitations. In this paper, we propose an approach to analyzing the impacts of the software process change using process slicing. Process slicing is designed to formally operate on the software process considering multi-perspectives of the software process such as behavioral, informational, and organizational perspectives. Process slicing produces the process slice, which is the part of the software process related to the change. Process slicing can be automatically performed resulting in making a project manager enable to reduce the effort to identify the impacts of the change.

Developing a Simulation Model Using a SPEM-Based Process Model and Analytical Models

It is hard to adopt a simulation technology because of the difficulty in developing a simulation model. In order to resolve the difficulty, we consider the following issues: reducing the cost to develop a simulation model, reducing the simulation model complexity, and resolving the lack of historical data. We propose an approach to deriving a simulation model from a descriptive process model and widely adopted analytical models. We provide a method to develop simulation models and a tool environment to support the method. We applied our approach in developing the simulation model for a government project. Our approach resolves the issues by the transformation algorithms, the hierarchical and modularized modeling properties of UML and (Discrete Event System Specification) DEVS, and widely adopted analytical models.

Identifying properties of UML state machine diagrams that affect data and control dependence

Program slicing is a useful reduction technique in many areas such as debugging and testing, and thus, there has also been some research to try and apply slicing techniques to flat state-based models at the design level, for their maintenance and quality improvement. However, such state-based models have difficulties in specifying large and complex software systems, and so the benefit obtained from slicing such models, is very limited. In contrast, UML state machine diagrams can properly describe the behavior of large software systems; but it is difficult to apply a slicing algorithm to automatically reduce the diagram with respect to a point of interest, because of the unique properties (such as hierarchy and orthogonality) of these diagrams. In this paper, we identify important issues relevant to the slicing of UML state machine diagrams with regards to data and control dependence. We also show why the unique properties of these diagrams are important to consider when retrieving data and control dependence information, by virtue of an illustrative example.

A Hypothetical Scenario-Based Analysis on Software Reliability Evaluation Approaches in the Web Environment

With the spread of the Internet and the development of Web technology, web-based software such as web applications and web services has been in the spotlight and widely used. Accordingly, ensuring web-based software reliability is becoming important, and the efforts to develop highly reliable software in the web environment are required. Compared with traditional software, research on the reliability of web-based software is not enough, and the dynamic execution environment of the web makes the reliability evaluation of web-based software much more complicated. In this paper, we deal with reliability evaluation issues in the web environment and compare with each other in terms of failure data collection methods, reliability evaluation techniques, and validation schemes. We also evaluate them based on hypothetical execution scenarios, analyze the strengths or weaknesses of each technique, and identify the remaining open problems.