• 한국소프트웨어감정평가학회 논문지
• /
• 제17권1호
• /
• pp.1-9
• /
• 2021

도급의 대상이 된 일의 완성 여부는 도급계약에 관한 분쟁에서 어떠한 쟁점을 다루던지 가장 중요한 전제에 해당한다. 일반적으로 도급계약의 형태로 이루어지는 소프트웨어 개발 용역의 경우에도 이는 동일하게 나타난다. 일이 완성된 정도를 완성도라 한다. 소프트웨어 도급계약이 원인이 된 소송에서는 대상 소프트웨어의 완성도를 산출하기 위하여 감정을 주로 활용한다. 다만 그 과정에서 다양한 전문가들이 재량을 가지고 참여하다 보니 객관성 확보에 어려움을 겪는 문제가 있다. 이에 본 논문에서는 그간 소프트웨어 완성도 산출에 관한 여러 사례를 살펴보고 각기 어떠한 산출 방식을 적용하였는지 검토해보았다. 이를 통하여 현재 소송 과정에서 이루어지는 완성도 산출의 객관성을 확보하기 위하여 어떠한 개선점이 필요한지 생각해보았다. 그 결과 부족한 자료에 기반하여 이루어진다는 점, 하자와 미완성을 엄격히 구별하지 않고 감정이 이루어지고 있다는 점, 가중치 적용에 대한 재량이 지나치게 광범위하다는 점 등의 문제가 있어 개선이 필요할 것으로 판단하였다.

• 한국소프트웨어감정평가학회 논문지
• /
• 제15권2호
• /
• pp.9-16
• /
• 2019

한국저작권위원회에 의뢰된 소프트웨어 저작물 감정 대상 중 25% 이상은 소프트웨어 완성도-하자 감정이다. 기존 소프트웨어 완성도-하자 감정 사례의 대부분은 해당 소프트웨어의 기능성에 국한하여 계약서에 포함된 또는 고객이 원하는 요구사항들이 구현되어 작동되는지 확인하는 방식으로 이루어졌다. 본 논문은 소프트웨어 완성도 정의에 부합할 수 있도록, 보다 체계적이고 합리적인 완성도-하자 감정 기법을 제안한다. ISO/IEC 9241.10 표준은 소프트웨어 품질 제고를 위한 설계표준이라 할 수 있다. ISO/IEC 9241.10 표준은 준수되어야 하는 7개 항목을 규정하고 있으며, 작업을 위한 기능상의 완전성과 작업 능률 효율화를 위한 사용상의 완전성을 요구하고 있다. 본 논문에서 제시된 소프트웨어 완성도-하자 감정 방법론은 소프트웨어의 질적 품질에 대한 완성도 감정으로 기존 기능구현-작동 여부 감정 방법론은 보완하고 있다.

• 한국소프트웨어감정평가학회 논문지
• /
• 제17권2호
• /
• pp.11-17
• /
• 2021

본 연구에서는 감정사례 및 판례를 분석하여, 기존 소프트웨어 완성도 감정으로 분류되어 수행된 완성도감정, 기성고감정, 하자감정 및 비용감정의 문제점을 적시하고, 그 해결 방안을 제시한다. 판례와 법률적 관점에서 완성도와 기성고율은 큰 차이를 가지고 있다. 완성도는 개발프로세스가 종료된 소프트웨어를 대상으로 전제하는 반면, 기성고율 감정은 미완성된 소프트웨어의 개발진척도를 평가하기 때문이다. 종종 소프트웨어 기성고와 관련된 판례에서는 소프트웨어 공학 개발 절차에 따른 단계별 가중치를 인정하여 전체 기성고 또는 완성도를 산정하는 것을 볼 수 있는데, 감정에서는 대부분 기능의 구현-작동여부 만을 완성도 비율 산정의 척도로 삼고 있는 문제도 존재한다. 또한 기존 소프트웨어 완성도 감정사례에서 다루지 않았던 문제 중 하나는 소프트웨어 하자에 대한 책임 소재 분석 및 감정이 언급되지 않고 있는데 반하여, 판례에서는 분쟁이 발생한 원인을 찾아 책임소재를 다투고 있다. 본 논문에서는 위 제기된 문제를 체계적으로 분류하여 소프트웨어 완성도감정과 소프트웨어 기성고감정을 분리할 것을 제안하고 감정 방안을 제시한다.

• 한국IT서비스학회:학술대회논문집
• /
• 한국IT서비스학회 2010년도 춘계학술대회
• /
• pp.436-438
• /
• 2010

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

• 한국소프트웨어감정평가학회 논문지
• /
• 제15권2호
• /
• pp.35-42
• /
• 2019

본 논문에서는 SW감정에서 많이 사용되는 완성도와 기성고의 용어의 정의를 재조명하고, 최근 SW분쟁에서 요구하는 완성도와 기성고의 의미와 산출 방법을 제시한다. 일반적으로 SW감정에서의 완성도는 최종 구축/구현된 SW의 기능상의 완성된 정도를 의미하고 있으며, 기성고는 개발비를 정산하기 위하여 현재까지 완료된 산출물 또는 기능을 기반으로 비용을 산출하는 것을 의미한다. 따라서 완성도는 최종적으로 개발 완료된 제품/산출물의 기능이나 인터페이스를 기준으로 판단하며, 기성고는 SW개발 단계별로 산출물 및 투입된 비용으로 산출된다. 최근에는 SW감정이 복잡해지고 완성도와 기성고에 대한 요구사항이 구체적으로 변화되고 있으므로, 본 논문에서는 각 용어의 의미와 목적을 다시 살펴보고 그 산출 방법을 제시한다.

• 한국소프트웨어감정평가학회 논문지
• /
• 제16권1호
• /
• pp.27-36
• /
• 2020

소프트웨어 개발비 감정은 프로그램 완성도 감정과 함께 소프트웨어 공학 방법론을 적용하고 있다. 특히 소프트웨어 비용산정 기법을 적극적으로 준용해왔다. 다수의 감정 사례에서 소프트웨어 개발비 감정을 위해 소프트웨어 비용산정에 기반을 두는 "SW사업 대가산정 가이드"를 참조하여 감정이 이루어져 왔으나, 이러한 방법은 본질적인 한계를 가진다. 개발비 감정을 위한 "SW사업 대가산정 가이드" 자체의 문제점과 함께 소프트웨어 규모 산정의 기본이 되는 기능점수가 가지는 단점으로 인해 감정의 정확성과 일관성이 유지되기 어렵다. 본 연구에서는 규모추정의 정확성과 일관성 유지를 위한 방안으로 유스케이스 기반의 규모 추정 방안을 제시한다. 평가 대상 프로젝트는 개발비 감정 사례들과 유사한 유형의 소프트웨어공학 교과목의 프로젝트로 진행하였으며, 공수 추정 시에 감정 사례들의 상황과 유사하도록 제공되는 문서와 정보를 최소화하였다. 기능 점수 기반의 기존 소프트웨어 개발비 산정 방식과 유스케이스 기반으로 제안한 방안의 성능 평가를 실시한 결과, 기존 방식보다 정확도가 향상되었고 통계적으로 유의함이 입증되었다.

• 한국정보처리학회:학술대회논문집
• /
• 한국정보처리학회 2007년도 춘계학술발표대회
• /
• pp.560-563
• /
• 2007

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

• 한국산업정보학회:학술대회논문집
• /
• 한국산업정보학회 2003년도 추계공동학술대회
• /
• pp.489-503
• /
• 2003

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

• 전자통신동향분석
• /
• 제23권1호통권109호
• /
• pp.21-32
• /
• 2008

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

• 정보처리학회논문지D
• /
• 제13D권1호
• /
• pp.61-66
• /
• 2006

소프트웨어 개발 프로젝트는 성공률이 30% 밖에 되지 않는 어려운 과제이다. 소프트웨어 개발 프로젝트가 실패하는 이유는 여러 가지가 있을 수 있으나, 체계적인 관리 소홀이 큰 비중을 차지하고 있다. 특히, 완성도가 떨어지는 산출물을 다음 단계로 진행시키는 것은 많은 시간과 노력을 허비하여 프로젝트를 실패로 이끌 수 있다. 이를 방지하기 위해 채택되고 있는 방식은 동료 검토(Peer Review) 또는 인스펙션(Inspection) 등과 같은 산출물들에 대한 검토활동이다. 문제가 발견된 산출물들은 다시 개발자에게 돌아가서 수정하게 되는데, 이 과정을 재작업 (Rework)이라고 한다. 프로젝트 관리자가 완성도가 떨어지는 산출물들을 다음 단계로 넘겨서 오류에 대한 막대한 비용을 지출하고 기간을 지연시키는 등의 사고를 막기 위하여, 본 연구에서는 재작업의 충실도를 높일 수 있는 방법을 연구하였다. 즉 프로젝트의 재작업 시에 작업분석을 시행함으로써 재작업된 결과의 검토 수준을 달리하는 재작업지표를 개발하였고, 이에 대한 검증을 위해 4개의 프로젝트를 선택하여 개발된 지표의 적용 여부를 관찰하고 그 효율성을 입증하였다.