[소프트웨어 공학] Chapter 4. 프로젝트 관리 개념(2) - 프로젝트 측정

* 교수님께서 소프트웨어 공학은 크게 엔지니어링 / 매니지먼트 (관리) 부분으로 나뉜다고 한다! 이러한 관점에서 이 과목을 잘 살펴보도록 해보자 ~~ 

 

프로젝트 측정 (Measure) 

 

1. 프로젝트 측정이 필요한 이유

 

1. To charactive : 측정하여 대상을 특징화하고 분류하는 것 

2. To evaluate : 측정하여 대상을 평가하고 판단 

3. To predict : 측정하여 대상의 미래 상황을 예측하는 것 

4. To improve : 측정하여 대상을 개선하는 것 

 

* (세분화된) 측정 이유 

- access the status of an ongoing project 

진행중인 프로젝트의 상황 평가 → 프로젝트가 계획대로 진행되고 있는지에 대한 여부 확인을 포함

- track potential risks

잠재적인 위험을 추적하고 그것에 대비하기 위한 계획을 수립하는 것 → 위험을 최소화하고 프로젝트를 안전하게 진행

- uncover problem areas before they go 'critical'

문제가 발생하기 전에 문제를 파악하고 대응하는 것 → 뭄제를 조기에 발견하고 적절한 조치를 취하여 문제를 심각한 상황으로 끌고가지 않음 

- adjust work flow or tasks

작업 흐름이나 작업을 조정하는 것 → 프로젝트가 예산 내에서 완료되도록 하거나 작업이 지연되는 문제를 해결하는 등의 목적으로 수행

- evaluate the project team's ability to control quality of software work products

프로젝트 팀이 소프트웨어 작업 제품의 품질을 효과적으로 제어할 수 있는 능력을 평가하는 것을 의미 → 프로젝트 관리자는 팀의 역량을 평가하고 개선점을 파악하여 프로젝트의 품질 향상 쌉가능

 

 

2. 무엇을 측정하는가 

 

 

무엇을 기준으로 ? - 평가기준 ! 

1. LOC (Line Of Code, 코드의 size) : 직접적인 측정 방식

2. FP(Function Point) : 기능적으로 얼마나 만들기 힘든 문제인가를 수치화 

 

소프트웨어 측정에서 자세히 다루어보겠다 ! 

 

 

3. 소프트웨어 측정 

• 직접 측정
  LOC(Line Of Code), speed, memory size, # of defect, etc 
  직접적으로 평가할 수 있는 척도 하지만 이것들만을 통해서는 부족하다 ! → 간접 측정을 통해 보완하자 

 

• 간접 측정 
  functionality, quality, complexity, efficiency, realiability, maintainability, etc 

 

✅ 크기 중심 측정 지표(Size - Oriented Metrics) 

→ Line of Code (LOC) 

* KLOC(thousand lines of code) : LOC가 커서 나온 단위 

→ errors per KLOC 

→ Defect per KLOC (개발 뒤 고객이 사용하다 발견된 결함) 

→ $ per KLOC

→ Page of documentation per KLOC

→ Errors per person-month

→ KLOC per person-month

→ $per page of documentation 

 

 

Size- Oriented Metrics : Example 

 

 

✅ 기능 중심 측정 지표 (Function-Oriented Metrics) 

→ errors per FP (Function Point)

→ defects per FP

→ $ per FP

→ pages of documentation per FP

→ FP per persin-month

기능점수 측정 평가

* 기능점수 측정 평가(Function Point Metrics) 

기능점수 측정에 사용되는 다섯가지 요소 

 

1. Number if external inputs(EIs) : 소프트웨어 시스템이 받아 들이는 외부 입력의 수, 일반적으로 사용자나 다른 시스템에서 제공

2. Number of external outputs(EOs) : 소프트웨어 시스템에서 생성되는 외부 출력의 수, 일반적으로 사용자나 다른 시스템에서 사용

3. Number of external inquiries (EQs) : 소프트웨어 시스템에서 처리하는 외부 조회의 수, 이 조회는 일반적으로 사용자나 다른 시스템에서 요청된다.

4. Number of internal logical files(ILFs) : 소프트웨어 시스템 내부에서 유지 관리되는 데이터 파일의 수, 소프트웨서 시스템에서 생성되거나 사용될 수 있음

5. Number of external interface files(EIFs) : 다른 시스템과의 인터페이스를 위해 사용되는 파일의 수, 이파일은 다른 시스템에서 생성되거나 사용될 수 있음 

 

→ 이 다섯가지 요소는 소프트웨어 시스템의 크기와 복잡도를 고려하여 기능 점수를 계산하는데 사용된다 ! 이를 통해 개발 프로젝트의 규모를 파악하고 비용 및 일정을 산정하는 데 도움이 된다 ~ 

 

 

---

Safe Home 예제 

 

Safe Home은 소프트웨어 공학에서 자주 사용되는 예제 중 하나 ! 

주택 안전 시스템을 개발하는 프로젝트이다. 이 시스템은 다양한 센서와 카메라, 경보기, 자동화된 잠금장치 등을 사용하여 집 안의 안전을 유지하는 것을 목적으로 함 

 

* Safe Home 예제는 요구사항 수집, 분석, 설계, 구현, 테스트 등의 단계에서 다양한 소프트웨어 공학적인 기법들을 적용할 수 있는 예제로 활용된다. 이를 통해 소프트웨어 공학 학습자들은 실제 프로젝트에서 발생할 수 있는 다양한 문제 상황에 대처하는 데 필요한 지식과 기술을 습득할 수 있다. 또한 Safe Home 예제를 활용하여 소프트웨어 개발에 대한 이해를 높이고, 팀 프로젝트 수행 능력을 강화하는 데도 도움이 됨 

 

---

Function- Oriented Metrics : Example 

 

---

 

품질 측정 

Correctness (정확성) - 프로그램이 명세에 따라 올바르게 작동하는 정도를 측정하는 지표 

→ #_ defects / KLOC 

 

Maintainability (유지보수성) - 프로그램이 변경에 대해 유연하게 대처할 수 있는 정도를 측정하는 지표

→ MTTC ( mean-time-to-change ) 

 

Integrity (무결성) - 프로그램이 외부 공격으로부터 안전하게 보호되는 정도를 측정하는 지표 

→ Integrity = ∑( 1 -(threat x (1 - security)))

 

Usability (사용성) - 프로그램이 사용하기 쉬운 정도를 측정하는 지표 

→ quantify easy of use 

 

 

 

 

DRE (Defact Remove Efficiency)

소프트웨어 품질을 평가하고 개선하기 위한 중요한 지표 중 하나

 

DRE= E / (E+D) 

 

1. 'E'는 소프트웨어를 최종 사용자에게 제공하기 전에 발견된 오류 수를 나타낸다. 

→ 즉, 이는 소프트웨어가 출시되기 전에 발견되어 수정된 오류 수를 의미

2. 'D'는 소프트웨어를 최종 사용자에게 제공한 후 발견된 결함 수를 나타낸다. 

→ 즉, 이는 소프트웨어가 이미 출시된 이후 발견된 결함 수를 의미한다. 

 

* Defect Removal Efficiency은 소프트웨어에서 발견된 결함 중에서 사전에 발견된 오류의 비율을 측정한다.

따라서 DRE이 높을수록 소프트웨어 개발 프로세스에서 결함을 발견하여 수정하는 능력이 높다는 것을 의미 ! 

 

 

[출처 및 참고]

 

한국항공대학교 「 소프트웨어공학 」 강의자료