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

The completeness appraisal of software is performed in various forms, such as assessing the completion level in the development process, calculating the defect rate, estimating the development cost, and calculating the redevelopment cost. Along with this, the problem that is often dealt with is estimation of the development time. Even in a dispute over completeness due to delays in software development, issues of calculating an appropriate development time required to develop a delivery software or a development time required for change requests are often included in the appraisal request. In this paper, we introduce the procedure and method for estimating the appropriate project time of software development so that the appraiser can be applied to the appraisal work for determining the completeness. The method is based on the manual for calculating the appropriate project period of software development project.

• 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.

• 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.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 the Korea Academia-Industrial cooperation Society
• /
• v.21 no.6
• /
• pp.18-27
• /
• 2020

This study compared and analyzed the results of proficiency testing between testers based on the international standard ISO/IEC 17043 proficiency testing requirements using ISO/IEC 25023 software quality characteristics evaluation. Application of the test was submitted to the KASTO as a software test in the electric test field defined by KOLAS. Among ISO/IEC 25023, the evaluation items for proficiency testing between testers were selected as functional completeness and time behavior. The comparison test between testers was carried out on May 28, 2019 at the accredited LG Electronics SW Laboratory in Seoul and attended by KOLAS assessors. The test evaluation method was measured once per tester with functional completeness, and measurement was repeated 10 times per tester according to time behavior. As a result, in the case of functional completeness, all 12 test steps were passed, and the satisfaction was evaluated. Time behavior was repeated 10 times, and the mean was 9.45 ± 0.01 seconds for testers 1 and 3 and 9.52 ± 0.0 seconds for tester 2, but there was no statistically significant difference. In conclusion, the proficiency of the testers was equal, and the reliability of the test results of the test institute was confirmed.

• Journal of Korea Game Society
• /
• v.18 no.2
• /
• pp.121-130
• /
• 2018

Most of those studies use frequency, the number of times a pattern appears in a transaction database, as the key measure for pattern interestingness. It prerequisites that any interesting pattern should occupy a maximum portion of the transactions it appears. But in our real world scenarios the completeness of any pattern is more likely to become various in transactions. Hence, we should also consider the problem of finding the qualified patterns with the significant values of the weighted support by completeness in order to reduce the loss of information within any pattern in transaction. In these pattern recommendation applications, patterns with higher completeness may lead to higher recall while patterns with higher completeness may lead to higher recall while patterns with higher frequency lead to higher precision. In this paper, we propose a measure of weighted support and completeness and an algorithm WSCFPM(weigted support and completeness frequent pattern mining). Our algorithm handles the invalidation of the monotone or anti-monotone property which does not hold on completeness. Extensive performance analysis show that our algorithm is very efficient and scalable for word pattern mining.

• The KIPS Transactions:PartD
• /
• v.16D no.2
• /
• pp.201-212
• /
• 2009

There are various methods to trace output in software development to verify the consistency and completeness of requirements. Existing studies do present the trace meta-model or automated tools, but fail to list specifically traced output or traced items. Also, in regards to trace tables, which contain traced items, existing studies don‘t consider the whole software development process but merely its sub-process. Given this, the present study suggests an extended requirements tracetable that tracks output from the inception of the project through the architectural design phase to the application delivery, following up on the researcher’s previous study on a tracetable that considered only a sub-process of the whole development process. In addition, in order to address the problem of the tracking process becoming complicated with increased tracefields due to an extended trace table, the researcher suggests a method for normalizing a requirements tracetable that can integrate and separate by development process phase. Apply it to theH system development project of a D company, and this study caseverified application possibility of study, confirmed an effect of a chase to easily find out an error of requirements. Improve precision of a traceto verify consistency of requirements and completeness through this study, and will minimize failure of a software development.

• The Transactions of the Korea Information Processing Society
• /
• v.4 no.10
• /
• pp.2453-2460
• /
• 1997

Among the method of developing software there are many object-oriented analysis(OOA) techniques, and the new ones are being introduced continuously. The present OOA techniques, however, have difficulty in the identification and the verification of the objects and tend to ignore high-level control aspects of the problem due to the initial partitioning of them on the basis of the data. As a result, it brings inaccurate understanding and faults in the software which is required by users. Therefore the purpose of this paper is to design the TOVERC to verify completeness and consistency through cross-reference between the state transition diagram and the methods of object model in order to reflect the requirements of users in the analysis of software considering this problem.

• Journal of Digital Convergence
• /
• v.14 no.5
• /
• pp.293-300
• /
• 2016

DRM software should conform completeness, correctness and appropriateness for the related function to protect digital right properly. Therefore, the systematization of functionality evaluation method based on the related standard is essentially required. In this paper, based on the software quality standard, I intended to construct a model to measure the quality about functionality including suitability, accuracy and interoperability of DRM software. To this, we developed functional suitability evaluation model by analyzing infra-technology of DRM software and quality requirements about functional suitability. I think that through this study, functionality criteria to enhance the quality level of DRM software. Through the accumulation of future evaluation practices, it is necessary to improve the suitability and validity of the DRM software functional suitability evaluation model.