• Journal of Software Assessment and Valuation
• /
• v.17 no.1
• /
• pp.1-9
• /
• 2021

In disputes involving contracts for work, most issues boil down a single, most crucial, underlying question: whether the agreed work was completed. The same applies to software development services, which are usually usually provided under contracts for work. In disputes arising from software development contracts, appraisal is commonly used to determine the completeness of the software in question. However, it is often difficult to ensure the objectivity of the appraisal. This study examines past cases involving the determination of software completeness to identify the method used in each case. Then, based on the findings, this study identifies issues requiring improvements to ensure objective determination of completeness.

• Journal of Software Assessment and Valuation
• /
• v.15 no.2
• /
• pp.9-16
• /
• 2019

More than 25% of software copyright evaluations commissioned to the Korea Copyright Commission are software completeness-defective evaluations. Most of the existing software completeness-defective evaluation cases were made to ensure that the requirements contained in the contract or customer's desired requirements were implemented and able to run, limited to the functionality of the software. This paper proposes a more systematic and reasonable maturity-correction technique to meet software completeness definitions. The ISO / IEC 9241.10 standard is a design standard for improving software quality. The ISO / IEC 9241.10 standard specifies seven items that must be complied with and requires functional integrity for work and operational integrity for work efficiency. The software completeness-defective methodology presented in this paper complements the existing function's implementation-functioning methodology with completeness evaluation on the quality of software.

• Journal of Software Assessment and Valuation
• /
• v.17 no.2
• /
• pp.11-17
• /
• 2021

In this study, problems of software completeness appraisal are pointed out and their solutions are presented by analyzing appraisal cases and judicial precedents. Completeness appraisal, ready-made appraisal, defect appraisal, and cost appraisal have been classified as and have been evaluated with extant software completeness appraisals. From a legal point of view, and in judicial precedents, however, there is a big difference between the definition of completeness and the completion rate. This is because the degree of completeness is evaluated under the premise that the software's development is complete, whereas the ready-made appraisal inspects the development progress of unfinished software. Often, in cases involving software completion rate, the total completion level is calculated by weighting each step of the software development process. However, completeness evaluations use the software's realization-operation as its sole criterion. In addition, another issue not addressed in existing software completeness appraisal cases is that there is no mention of who is responsible for software defects, whereas in case law, the responsible party is determined by finding who caused the dispute. In this paper, we systematically classify these problems, and present a novel evaluation method that separates software completeness evaluations from software completion evaluations.

• 한국IT서비스학회:학술대회논문집
• /
• 2010.05a
• /
• pp.436-438
• /
• 2010

소프트웨어 감정은 분쟁이 발생했을 때 감정신청인의 감정 요청 사항에 대하여 전문가의 입장에서 소프트웨어 내용을 분석하고 감정하여 의견을 제출하게 된다. 특히 분쟁의 내용이 소프트웨어의 완성도 또는 공정율에 관한 경우에는 감정의 대상물인 목표 시스템 및 관련 산출물의 법적인 유효성 검토로 시작하여, 기완성 산출물 및 미완성 산출물에 개발공정의 진척도를 평가한다. 본 연구는 소프트웨어 개발과정에서 발주자와 개발자 사이에서 발생하는 공정율 감정에 대하여 추진 단계 및 세부적인 활동 그리고 현안에 대한 해결의 접근방법을 제시한다.

• Journal of Software Assessment and Valuation
• /
• v.15 no.2
• /
• pp.35-42
• /
• 2019

In this study, we reviewed the definition of completeness and payment in SW appraisal along to being complicated requirements of the appraisal, and we also presented their meaning and computation method. The completeness in SW appraisals means the degree of functional completion of the final product, and the payment refers cost spent to develop the product. Therefore, the completeness is evaluated based on the functions or interfaces of the final product, while the payment is calculated on the outputs or expenses of development steps. Recently, SW appraisal is complicated and the requirements for completeness and payment are changing. In this paper, we review the meanings and objectives of completeness and payment and present the evaluation methods for those.

• Journal of Software Assessment and Valuation
• /
• v.16 no.1
• /
• pp.27-36
• /
• 2020

The software development cost appraisal is treated as a part of the program completion appraisal, and the software engineering methodology is applied. In particular, software cost estimation techniques have been actively applied. For more information about the software development costs calculation, we can refer to the "SW cost estimation guide". Although successful appraisal of a number of development costs based on the guide has been processed, but a number of cases requiring discussion of appraisal results have been discovered. In this study, we propose a use case-based size estimation method to maintain the accuracy and consistency of size estimation. As a result of performing performance evaluation of the proposed method in an environment similar to the development cost appraisal case, it was proved that the accuracy was improved over the existing function points method.

• Proceedings of the Korea Information Processing Society Conference
• /
• 2007.05a
• /
• pp.560-563
• /
• 2007

본 논문은 소프트웨어의 완성도와 관련하여 발주사와 개발사간의 분쟁이 있을 시에 필요한 분쟁조정을 위한 평가방법을 연구하였다. 먼저 소프트웨어 개발 과정에서 발생할 수 있는 분쟁의 유형을 분류하였고, 객관적인 평가를 위한 감정 절차를 분류하였다. 본 연구에서는 분쟁조정의 객관성 확보를 위한 가중치 설정, 각 기능들에 대한 중요도를 설정하여 어느 정도의 완성도를 보였는지를 정량적으로 평가하였다. 또한, 프로그램의 복제 문제를 판단하기 위하여 필요한 감정 항목 설정 및 도용 여부를 판단하기 위한 기본 자료로 활용될 수 있을 것으로 기대한다.

• Proceedings of the Korea Society for Industrial Systems Conference
• /
• 2003.11a
• /
• pp.489-503
• /
• 2003

잘못되거나 불확실한 결과가 예상되는 프로젝트를 계속 지속하는 행위는 어떠한 분야의 프로젝트에서도 발견 할 수 있는 보편적인 현상이다. 그러나 소프트웨어 개발 분야는 그러한 어떠한 분야보다도 이 문제에 더 민감하며 그 파급효과 또한 크다. 그 이유는 소프트웨어 그 자체가 형태를 가지고 있지 않아 프로젝트 진행 도중에는 그 완성도를 예측하기가 무척 어렵기 때문이다. 또한 소프트웨어는 프로젝트범위가 자주 변동되기 때문에 통제와 관리에 어려움이 많다. 이런 이유로 소프트웨어 개발 생명주기의 각 단계에서 발생하는 위험 요소들을 찾아 그 위험 요소들이 발생했을 때 프로젝트에 미치는 영향정도 파악하여 그 해당위험 요소에 대응하는 방안들을 모색하는 것이 피해를 줄이기 위해 가장 최선의 방법이다. 본 논문에서는 위에서 거론된 소프트웨어 위험 관리에 대한 관련 문헌을 조사, 검토하고 설문을 통해 조사한 실무자들의 경험을 바탕으로 위험에 대한 인식과 대응 반응을 파악하고 연구하고자 한다. 소프트웨어 프로젝트 계획 단계에서 위험 요소가 추후 발생할 것을 예측하여 실제로 위험 요소가 발현했을 때, 적극적으로 대처 할 수 있는 방법을 찾아 해당 위험이 주는 영향을 최소화 할 수 있는 방법을 찾고자 한다.

• Electronics and Telecommunications Trends
• /
• v.23 no.1 s.109
• /
• pp.21-32
• /
• 2008

임베디드 시스템을 위한 응용 프로그램 개발 도구로서 통합개발환경을 이용하는 것은 소프트웨어 개발의 생산성과 코드의 완성도를 향상시킬 수 있다는 점에서 매우 중요하게 인식되고 있다. 최근에 USN에 대한 관심이 높아지면서 이를 위한 여러 가지 응용소프트웨어들이 개발되고 있으나, 통합개발환경의 부재로 명령어 라인 기반의 개발 방식이 사용되고 있는 실정이다. 이와 같은 방식은 불편함을 야기할 뿐만 아니라 개발 시간을 증가시킬 수 있으며, 궁극적으로 USN 응용 소프트웨어의 개발을 어렵게 만드는 요인이 된다. 본 고에서는 이와 같은 문제점을 해결하기 위하여 USN 응용 소프트웨어를 빠르고 편리하게 개발할 수 있는 통합개발환경의 동향을 살펴보고 ETRI의 본 연구팀에서 개발한 USN 소프트웨어 통합개발 도구인 “NanoEsto”를 기술하고 상용 제품과의 비교를 수행하였다.

• The KIPS Transactions:PartD
• /
• v.13D no.1 s.104
• /
• pp.61-66
• /
• 2006

It is reported that the success ratio of software development projects has been only 30%. Many causes lower project's chance of success, particularly lack of systematic project management. Especially, moving on the next phase of project with unsatisfactory outputs can be very problematic because it can cause much waste of resource, time and even lead to the failure of the whole project. Peer review and inspection are some of the practices designed to prevent such waste and possible failure. When defects are identified through such progress, each developer has to work on the product component again and fix the problem. This process is called rework. In this paper, we propose a method for improving quality of reworked product component to prevent excessive cost and time consumed caused by moving on the next phase of a project with a problematic product component. More specifically, this paper suggests a rework indicator that measures the level of rework based on its complexity and severity and is used to choose appropriate checking method on reworked product component. The research also confirmed the method's usefulness and effectiveness by applying the suggested method on four projects.