Software Size Estimation by Integrating Functional Size and Functional Complexity Measures
본 연구는 회귀 분석을 사용하여 기능적 크기 척도(UFP 및 CFP)와 기능적 복잡도 척도(CC 및 YC)를 결합한 소프트웨어 규모 추정 모델을 제안하며, 이러한 지표들을 결합하는 것—특히 UFP와 복잡도 척도를 결합하는 것—이 COCOMO II와 같은 애플리케이션에 대한 추정 오차를 유의미하게 줄이고 예측 정확도를 향상시킨다는 것을 입증한다.
원본 논문은 CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기
소프트웨어를 구축하는 것은 건물을 짓는 것과 매우 유사한 복잡한 작업이지만, 벽돌과 모르타르 대신 코드의 줄과 기능적 요구사항이 재료가 됩니다. 수십 년 동안 프로젝트 매니저들은 프로젝트에 소요될 시간과 비용을 추정하기 위해 이 코드의 줄 수를 세는 방식에 의존해 왔습니다. 그러나 두 프로그램이 동일한 기능을 수행하더라도 프로그래머가 코드를 어떻게 작성하느냐에 따라 필요한 코드의 양이 판이하게 달라질 수 있기 때문에 이 방법은 결함이 있습니다. 이를 해결하기 위해 업계에서는 소프트웨어를 어떻게 작성했느냐가 아니라, 입력, 출력, 데이터 파일 등을 세어 사용자를 위해 실제로 무엇을 '수행'하는지로 측정하는 방법을 개발했습니다. 이것이 바로 기능적 크기(functional size)라고 알려진 것입니다. 하지만 이러한 기능적 계산조차도 사각지대가 있습니다. 이는 기능의 양은 측정하지만, 그것을 구축하는 난이도는 놓치는 경우가 많기 때문입니다. 단순한 기능은 만들기 쉬울 수 있는 반면, 많은 분기점과 조건이 포함된 복잡한 기능은 전통적인 의미에서의 단일 '기능'으로 계산되더라도 구현하기 매우 까다로운 악몽이 될 수 있습니다.
기능의 크기와 이를 구축하는 복잡성 사이의 이 간극은 인도네시아의 한 연구팀이 다루고자 했던 핵심적인 과제였습니다. 그들은 기능적 크기 측정값과 구조적 복잡성 측정값을 결합하면 소프트웨어 프로젝트의 실제 규모를 더 정확하게 예측할 수 있을지 알아내고자 했습니다. 그들의 연구는 소프트웨어를 구축하는 데 필요한 노력을 정교화하는 데 초점을 맞추고 있으며, 이는 프로젝트가 예산 내에 머물 것인지 아니면 통제 불능 상태로 치닫게 될지를 결정하는 중요한 작업입니다. 그들은 소프트웨어의 '무엇(what)'과 '얼마나 어려운가(how hard)'를 모두 살펴봄으로써, 디지털 시스템을 계획하고 관리하는 사람들을 위해 더 명확한 그림을 그려내고자 했습니다.
연구진은 먼저 직원 협동조합을 위해 설계된 프로젝트와 소매점을 위한 프로젝트라는 두 가지 실제 소프트웨어 프로젝트에서 데이터를 수집했습니다. 공공 데이터셋은 분석에 필요한 구체적인 세부 사항이 부족한 경우가 많기 때문에 그들은 공공 데이터셋을 사용하지 않았습니다. 대신, 그들은 이 애플리케이션들의 텍스트 요구사항을 가져와 BPMN 다이어그램이라고 불리는 시각적 흐름도로 변환했습니다. 이 다이어그램은 팀이 시스템의 모든 부분에 대해 두 가지 다른 유형의 측정을 추출할 수 있게 해주는 가교 역할을 했습니다. 첫째, 그들은 입력 및 출력과 같은 표준 카테고리를 기준으로 미조정 기능 점수를 세는 방식과, 데이터가 시스템을 어떻게 드나드는지를 추적하는 방식인 코스믹 기능 점수(cosmic function points)를 사용하는 방식 등 두 가지 확립된 방법을 사용하여 기능적 크기를 계산했습니다.
다음으로, 그들은 동일한 부분들의 구조적 복잡성을 측정했습니다. 이는 흐름도 내의 로직을 분석하여 얼마나 많은 결정 지점, 루프, 그리고 분기 경로가 존재하는지 확인하는 작업을 포함했습니다. 그들은 두 가지 서로 다른 복잡성 지표를 사용했는데, 하나는 코드 내의 독립적인 경로의 수를 세는 것이고, 다른 하나는 다양한 종류의 분기와 루프가 갖는 인지적 난이도에 가중치를 두는 것이었습니다. 마지막으로, 그들은 이 결합된 측정값들을 프로젝트에서 작성된 실제 코드의 줄 수와 비교했습니다. 이 최종 계산은 연구진이 예측하고자 했던 완성된 소프트웨어의 실제 크기, 즉 '그라운드 트루스(ground truth)' 역할을 했습니다.
결과는 사용된 기능적 크기 측정 방법에 따라 뚜렷한 패턴을 보였습니다. 연구진이 첫 번째 기능적 크기 방법을 사용했을 때, 복잡성 측정값을 추가하는 것은 예측의 정확도를 유의미하게 향상시켰습니다. 구체적으로, 추정 오차율이 24%에서 22%로 감소했습니다. 이는 이러한 유형의 기능적 계산의 경우, 로직의 복잡성을 아는 것이 추정치를 교정하여 현실에 더 가깝게 만드는 데 도움이 된다는 것을 시사합니다. 그러나 두 번째 기능적 크기 방법을 사용했을 때는 이야기가 달랐습니다. 코스믹 기능 점수를 사용했을 때 복잡성 측정값을 추가해도 오차율은 15%로 일정하게 유지되어 낮아지지 않았습니다. 이 경우, 기능적 크기 측정치가 이미 매우 정밀했기 때문에 추가적인 복잡성 데이터가 최종 수치를 더 정확하게 만들지 못했습니다.
오차율의 개선이 없었음에도 불구하고, 복잡성 데이터는 여전히 가치가 있었습니다. 연구진이 코스믹 기능 점수에 복잡성 측정치를 더했을 때, 예측의 품질은 다른 방식으로 개선되었습니다. 매우 좁은 오차 범위 내에 들어오는 추정치의 비율이 76%에서 80%로 증가했습니다. 이는 평균 오차는 변하지 않았지만, 팀이 정답에 매우 근접하게 도달하는 데 있어 더 신뢰할 수 있게 되었음을 의미합니다. 본 연구는 복잡성 측정치를 통합하는 것이 모든 상황에 적용되는 만능 해결책은 아니며, 그 가치는 어떤 기능적 크기 측정법을 사용하느냐에 따라 달라진다는 결론을 내립니다. 한 방법에서는 정확도를 날카롭게 다듬고, 다른 방법에서는 일관성을 높여줍니다. 이러한 발견은 기존의 노력 추정 모델에 데이터를 입력하는 더욱 미묘하고 정교한 방법을 제시하며, 잠재적으로 소프트웨어 팀이 프로젝트에 실제로 필요할 시간과 자원에 대해 더 정보에 입각한 결정을 내릴 수 있도록 돕습니다.
연구 분야의 논문에 파묻히고 계신가요?
연구 키워드에 맞는 최신 논문의 일일 다이제스트를 받아보세요 — 기술 요약 포함, 당신의 언어로.