Earticle

소프트웨어 산업은 아직도 뿌리깊은 문제에 시달리고 있다. 어떻게 보면, 제조업과 같은 보다 성숙한 산업의 모범사례로부터 뭔가를 배워야 할 지 모른다. 제조업에서의 ‘린’ 원칙을 소프트웨어 개발에 적용하는 것도 한방안일 수 있다. 소프트웨어공학 문헌에서 이런 ‘린’ 원칙은 시도해 볼만한 것으로 언급되었다. 그러나 이들 원칙을 실제 어떻게 적용할 수 있을 가에 대한 구체적 방안을 제시한 연구는 별로 없었다. 본 연구는 ‘린’ 원칙을 소프트웨어 개발에 적용하는 방안을 제시하고자 한다. 이 방안의 핵심은 낭비제거라는 린의 관점을 구체화하기 위하여 프로젝트에서의 리드 타임과 결함을 누적 흐름도(Cumulative Flow Diagram)을 통해 관리하는 방법이다. 또한 이 방안을 실제 프로 젝트 사례에 적용함 으로써 타당성을 검증하고 적용 방법에 대한 이해를 돕고자 하였다.

Software industry still has many deep-seated problems. As a natural consequence, it may have to learn from best practices in more mature industry like manufacturing. An example is ‘lean’ software development which is defined as translation of ‘lean manufacturing’ principles to the software development domain. The principles include ‘eliminate waste’ and ‘amplify learning.’ It was much asserted that these principles are worth applying. Not much study, however, was done on how to practically implement these principles into software development practice. In this study we attempt to present a method in which project lead time and software defects are regarded as major targets of management and are visualized using Cumulative Flow Diagram. We further applied this method on actual projects. The result confirms that agile is positively effective on reducing wastes.

Software defects prediction research is converging on the use of function point elements for software defect predictions. Studies on the nature and behavior of the function point elements are expanding. Previous studies have analyzed the correlation between the function point elements. This paper presents correlation analysis between function point elements and the software defects. It is observed that external input count and external inquiry count function point elements show some correlation with software defects. Different data subsets were analyzed, where 4GL projects shows strong correlation with defects over 3GL and ApG/other projects, while enhancement software projects show more correlation with defects over new software projects.

Software defects are the major risks of system stable operation. Its error localization technology of automation is one of the key research content for trust computing and software assurance. In this paper, we have proposed a new model, which integrates the current methods by analyzing the program structure. We put forward a new automated fault localization method, this method without the degree loss of automation, at the same time, particle size down to basic positioning code statements, makes the position more accurately. We have designed an experiment to examine the effectiveness of CPD base on SIR. And we proved that the CPD is more effective.

신뢰성 있는 소프트웨어를 생산하기 위해 결함을 식별하고 연관성을 분석하게 된다. 또한 결함간의 원인을 분석하고 예측을 하며. 결함간의 연관성을 기반으로 결함관리를 위한 Opportunity Tree 프레임웍크을 설계한다. Opportunity Tree 프레임웍크을 적용한 가시적인 효과는 다음과 같다. 먼저, 제품의 품질 보증을 통한 고객 만족과 제품의 유연성 제고 및 생산성 향상에 있고, 품질과 인도시간을 조정하여 시장 확장과 재무성과의 최대화할 수 있다.

This paper identifies defects to produce a reliable software and analyzes the relationship between defects. Also, this paper is intended to develop the relationship between defects and their causes to introduce. For the doing, first, to meet to customer satisfaction and make flexibility and productivity and second. to maximize market extension and financial outcome by controlling of quality and delivery.

국방 무기체계에서의 소프트웨어 비중이 증가하고 있으며 구조도 점차 복잡해지고 있어, 이에 따른 신뢰성 검증이 매우 중요하다. 특히 무기체계 시스템을 구성하는 소프트웨어 구성 요소 들의 상호 작용에 따라 발생하는 결함은 정적 시험 및 코드 실행률 점검 수준의 동적 시험만으로는 예방하기가 어렵다. 본 논문에서는 소프트웨어의 동적 결함 유형을 분류 개발한다. 미 국방부 무기체계에 사용하는 오픈 소스 소프트웨어(OSS)에서 보고된 이슈 분석을 통하여 본 논문에서 분류한 동적 결함이 실제로 발생하며, 이들은 대체로 통합 이후 발생하는 결함이며, 재현이 어렵고, 결함 원인 파악이 어려웠음을 보인다. 이 분석 결과를 기반으로 무기체계 신뢰성 검증을 위하여 소프트웨어 통합 시험 개선의 중요성을 도출한다.

The importance of software in military weapon systems is increasing, and the software structure is becoming more complicated. We therefore must thoroughly verify its reliability. In particular, the defects from the interaction of the software components that make up the weapon system are difficult to prevent only with static testing and code coverage level dynamic testing. In this paper, we classify dynamic software defect types and analyze the issues reported in the Open Source Software (OSS) used in the US department of defense weapon systems. The dynamic defects classified in this paper usually occur after integration, and it is difficult to reproduce and identify the cause. Based on this analysis, we come to the point that the software integration test must be enhanced in order to verify the reliability of the weapon system.

본 논문은 소프트웨어 공정 시 발생하는 결함을 찾아내고 원인을 분석하여 제거하는 동시에 제품 개발의 진척도를 관리하여 결함을 미리 예측하고 재 발생을 예방한다. 이를 통해 소프트웨어 생산성을 높이며 개발주기를 줄이는 동시에 높은 수준의 제품출하를 이루어 타 회사보다. 앞선 경쟁력과 Speed 경영을 이룰 수 있는 방법을 제시한다. 이를 위해 MBASE 기반의 소프트웨어 프로젝트 관리 모형과 함께 OT를 설계하고 구현하여 제품의 결함을 줄이고 공정의 진행사항을 쉽게 파악할 수 있게 구현하였다.

본 논문에서는 운전 단계중의 상용소프트웨어 성장활용을 설명한 수 있고 또 현장 고장 데이타로부터 활용성장을 예측하는데 관계되는 인자를 결합할 수 있는 새로운 모델을 개발한다. 이 모델은 상용 소프트웨어의 실제 황용이 시간의 멱수 함수로 나타난다는 가정으로부터 생기는 웨이블 분포에 근거한다. 선형신뢰도모델은 잔여결함의 평균크기와 작업량이 일정하고 겉보기 결함밀도가 실제 결함밀도와 동일하다는 가정 하에 유도된다. 기하학적모델은 결함을 수정함에 따라 평균결합크기가 기하학적으로 감소한다는 가정에 있어서 파이가 있다. 한편, Rayleigh모델은 잔여 결함의 평균크기가 시간에 따라 선형적으로 감소한다는 가정에 있어서 차이가 있다. 본 논문에서는 소프트웨어의 신뢰도 요인의 거동을 가정하여 이러한 다양성을 수용하기 위한 모델링을 하였다.

독일 현행 제조물 책임법은 ‘소프트웨어(Software)’를 제조물의 정의 규정에 명시하고 있지 않다. 따라서 소프트웨어의 결함 사례에 대한 제조물 책임법의 적용 여부는 학설과 판례의 해석론에 맡겨져 있다. 1. 비록 소프트웨어가 제2조 제조물의 정의에 언급되어있지 않으나 해석상 제조물로 다루어질 수 있고, 따라서 제조물 책임법이 적용될 수 있다. 다만 소프트웨어의 공급자와 그 소프트웨어와 결합된 제품의 제조자 간에 손해에 대한 책임귀속관계가 명확한 경우에는 그에 따라야 할 것이다. 2. 제조물 책임법이 적용되기 위해서는 소프트웨어에 결함(Fehler)이 존재해야 한다. 결함은 설계 결함과 제조 결함으로 나뉠 수 있고, 제조자의 설명의무와 그 내용도 소프트웨어의 결함을 판단함에 있어서 중요한 고려요소이다. 해석상 소프트웨어의 결함이 인정되는 경우에는 제조물 책임법이 적용될 수 있다. 3. 제조물 책임법상 책임의 주체는 제조자이다. 다만 사정에 따라서 책임 소재가 명백한 경우에는 완성제품의 제조자가 아닌 소프트웨어의 개발·판매자인 제3자에게 책임이 귀속되거나, 제조자의 책임이 제한 혹은 면책될 수 있다. 면책사유(제1조 제2항 제1호 내지 제5호)에 대한 증명책임은 제조자가 부담한다. 피해자는 소프트웨어의 결함으로 인해 권리가 침해된 자이다.

Germany's current product liability law does not specify 'software' in the definition of product. Therefore, the application of the Product Liability Act to software defect cases depends on the interpretation of theories and precedents. 1. Although the software is not mentioned in Article 2’s definition of the product, it can be treated as a product on the basis of interpretation, and thus the Product Liability Act can be applied. However, if the supplier’s fault for the software’s flaws is obvious, the responsibility belongs to the supplier. 2. In order for the product liability law to be applied, a defect (Fehler) must exist in the software. Defects can be divided into design defects and manufacturing defects, and the manufacturer's duty to explain and its contents are also important factors to consider in determining software defects. If software defects are recognized based on interpretation, the Product Liability Act may be applied. 3. Under the Product Liability Act, the subject of responsibility is the manufacturer. However, if the responsibility is clear depending on the circumstances, the responsibility may be attributed to a third party who develops or sells the software, not the manufacturer of the finished product, or the manufacturer’s responsibility may be restricted or exempted. The responsibility for proving the grounds for indemnification (Article 1 (2) 1 to 5) belongs to the manufacturer. The victim is a person whose rights have been violated due to software defects.