소프트웨어 공학 3장

Hyun·2024년 10월 16일
0

3.1. 계획의 이해

소프트웨어 개발은 일정 지연, 비용 초과, 품질 저하 -> 유지보수 비용도 더욱 증가

=> 그렇게 때문에 계획이 중요

3.2. 문제 정의

  1. 소프퉤어 개발의 첫 번째 작업
  2. 무엇을 개발할 것인지 명확하게 정의
  3. 개발 범위를 결정
    -> 배경 지식, 분석가, 현재 운영중인 시스템 사용, 자료 수집 후 분석이 중요

3.3. 타당성 분석

3.3.1. 경제적 타당성 (economic feasibility)

  • 의사결정을 하는 데 매우 중요
  • 시장 분석을 통해 시장성(marketability) 확인
    -> 경제적 타당성 분석으로 투자 효율성, 시장성 검증 후 개발 여부를 판단

3.3.2. 기술적 타당성 (technical feasibility)

  • 최신 기술이 필요하다면 먼저 검토
  • 요구하는 기술을 회사가 가지고 있는지 확인
    -> 부족하다면, 필요한 기술을 갖고 있는 소프트웨어 개발자를 채용하거나 외주 개발로 해결
  • 오픈소스는 아무렇게나 가져다 사용할 수 있는 게 X
  • 법적인 문제 발생하지 않기 위해서 오픈소스 사용시 어디까지 무료로 사용할 수 있는지 확인해야 함

3.4. 개발 비용 산정

개발 비용 산정이 어려움: 사람(개발자)이 중심이기 때문에 개발 인력의 능력에 따라 품질의 차이가 크다, 개발 프로세스가 다양하기 때문에 표준화, 자동화가 어려움

개발 비용 산정에 영향을 주는 요소: 프로그래머 자질, 소프트웨어 복잡도, 소프트웨어 크기, 가용 시간, 요구되는 신뢰도 수준, 기술 수준 (고급 언어, 저수준 언어 등)

3.5. 비용 산정 기법 1: 하향식 산정 기법

3.5.1. 전문가 판단 기법

: 경험이 많은 여러 전문가가 프로젝트를 수행하는 데 비용이 어느 정도 들어가는지 평가한 금액을 개발 비용으로 산정 -> 짧은 시간에 개발비를 산정하거 입찰에 응해야 하는 경우에 사용

+: 신뢰성이 있고 편리
-: 경험에만 의존시 부정확할 수도 O

3.5.2. 델파이 기법

조정자(coordinatior)를 둔다

  • 그룹 상호작용을 방지하고 객관적 결론 도출을 위해 직접 대면하지 않고 참여하는 회의 방식이다.
  1. 촉진자(조정자) 가 설문지 개발, 참여자를 선정
  2. 설문지를 이용, 참여자(전문가)들의 의견을 확인한다
  3. 설문조사 결과를 분석한다
  4. 참여자들 간에 의견 일치가 되지 않을 시 조사 결과를 통보하고 다시 진행
  5. 의견이 일치될 때까지 4,5를 반복한다

3.6. 비용 산정 기법 2: 상향식 선정 기법

: 프로젝트 세부 작업 단위별로 비용을 산정한 후 전체 비용을 합산하는 방법

3.6.1. 원시 코드 라인 수 기법

: 비관치/ 낙관치/ 기대치 측정 -> 예측치 계산 -> 비용 산정 (노력, 비용, 생산성)

낙관치: 한 모듈의 라인 수를 가장 적게 생각할 때의 예상 라인 수 (가중치 1 부여)
비관치: 한 모듈의 라인 수를 가장 많게 생각할 때 (1 부여)
중간치: 한 모듈의 라인 수를 보통으로 생각할 때 (4 부여)
추정 LOC: (낙관치 + (4 * 중간치) + 비관치) / 6

노력 (인/ 월수) = (참여 인원 / 월) * 개발 기간 = 추정 LOC / 1인당 월평균 생산 코드 라인 수
개발 비용 = (M/M) X 단위 비용
개발 기간 = (M/M) / 참여 인원
생산성 = LOC / (M/M)
E= ATS X S

3.6.2. 개발 단계별 노력 기법

: 각 기능을 구현하는 데 필요한 M/M 을 소프트웨어 개발 생명주기의 각 단계에 적용해 단계별로 산정한다.

3.7. 비용 산정 기법 3: 수학적 산정 기법

3.7.1. COCOMO 기법

: SW 규모(LOC) 예측 후 SW 종류에 따라 각 비용 산정 공식에 대입하여 비용을 산정한다.

LOC 추정 -> 준비된 식에 대입 -> M/M 예측
프로그램에 유형에 따른 가중치, 4가지 특성(제품, 컴퓨터, 개발자, 프로젝트) 에 따른 15가지 분류 고려

  1. 가중치 반영하기
  • 단순형 프로젝트
  • 중간형 프로젝트
  • 내장형(임베디드) 프로젝트

-> 갈수록 M/M이 더 필요

2.보정 계수 반영하기

노력 조정 수치 (EAF) = 필요한 각 항목별 승수 값을 모두 곱한 값

  1. 총 개발 기간 산정하기
    TDEV(Total DEvelopment Time) : 개발할 소프트웨어 유형과 크게 상관없다. 개발한 소프트웨어 유형에 상관없이 모두 동일한 상수(2.5)를 곱한다.

3.7.2. COCOMO 2 방법

: 원시 코드의 라인 수를 정확히 예측하기 어렵다. 그렇기 때문에 소프트웨어 개발 프로젝트가 진행된 정도에 따라 3가지 다른 모델.

단계별로 값을 예측 -> 인건비 예측

  1. 애플리케이션 합성 모델(application composition model): 사용자 인터페이스의 개수 등을 계산해 다음의 객체 점수(object point)를 산출
  2. 초기 설계 모델(early design model) : 초기 설계 단계에서 예측값을 구한다, 더욱 정확한 예측
  3. 구조 설계 이후 모델 (post-architecture model) : 이미 기능 점수가 나왔기 때문에 LOC 를 추정

3.7.3. 기능 점수 산정 방법

공수 (MM=PM=노력=E)

기능 점수 (FP)

  • 데이터 기능
    1. 내부 논리 파일 (Internal Logical File, ILF)
    2. 외부 연계 파일 (External Interface File, ELF)
  • 트랜잭션 기능
    1. 외부 입력 (External Input, EI)
    2. 외부 출력 (External Output, EO)
    3. 외부 조회(External inQuiry, EQ)

+: 사용자의 요구사항만으로 기술을 추출해 측정, 객관적인 요구사항만으로 측정, 모든 개발 단계에서 사용
-: 높은 분석 능력 필요, 기능 점수 전문가 필요, 내부 로직 위주의 소프트웨어에는 다소 부적합, 개발 공수보다 개발 규모 측정에 적합

3.7.4. 간이 기능 점수법을 이용한 기능 점수 산정 방법

평균 복잡도 가중치

과거에 수행한 소프트웨어의 기능 점수 산정 결과를 분석해 5가지 유형에 적용된 복잡도를 계산한 가중치의 평균값

내부 논리 파일: 7.5
외부 연계 파일: 5.4
외부 인력: 4
외부 출력: 5.2
외부 조회: 3.9

  1. 측정 유형 결정
  • 개발 프로젝트 기능 점수 (개발 규모 측정)
  • 개선 프로젝트 기능 점수 (변경 규모 측정)
  • 애플리케이션 기능 점수 (응용 규모 측정)
  1. 측정 범위와 애플리케이션 경계 설정
  • 측정 범위에 포함될 요소 (서브 시스템) 의 선별
  • 애플리케이션 경계: 기능 점수를 계산하는 대상을 제외한 다른 애플리케이션이나 외부 사용자를 구분한 경계, 사용자 관점에서 구분해야 함
  1. 데이터 기능 점수 계산
  • 내부 논리 파일: 애플리케이션에 존재하는 데이터를 논리적으로 모아놓음
  • 외부 연계 파일: 측정 대상 애플리케이션에서는 참조만 하고 다른 애플리케이션에서 유지되는 파일

데이터 기능 점수 = (ILF 개수 X 7.5) + (EIF 개수 X 5.4)

  1. 트랜잭션 기능 점수 계산

복잡도는 입력, 출력, 조회의 개수로 계산된다.

  • 외부 입력: 사용자나 다른 애플리케이션으로부터 들어오는 데이터나 정보를 처리
  • 외부 출력: 계산하는 로직을 거쳐 데이터나 제어 정보를 사용자에게 보여주는 기능
  • 외부 조회: 로직이 필요없고 존재하는 데이터를 찾아 그대로 표시만

트랜잭션 기능 점수 = {(EI 개수 X 4.0) + (EO 개수 X 5.2) + (EQ 개수 X 3.9)}

  1. 미조정 기능 점수 계산

미조정 기능 점수 (Unadjusted Function Point, UFP) : 데이터 기능 점수 + 트랜잭션 기능 점수

  1. 보정 전 개발 원가 계산

보정 전 개발 원가 = 미조정 기능 점수 X 기능 점수당 단가

  1. 보정 계수
  • 규모 보정 계수 (생산정이 증가하지만 일정 규모 이상 되면 생산성은 감소) : 500FP 미만이면 1.28, 3000FP 초과시 1.153 적용
  • 애플리케이션 복잡도 보정 계수
    1. 연계 복잡성 수준: 연계 기관 수에 따른 보정 계수 적용
    2. 성능요구 수준: 사용자가 빠른 응답 시간 또는 높은 처리율을 요구
    3. 운영 환경 호환성: 개발 완료되어 설치할 때 운영 환경이 단순하지 않고 다영할 때
    4. 보안성 수준: 시큐어 코딩, 웹 취약점, 암호화 점검, 개인정보 보호
  1. 보정 후 개발 원가 계산

보정 후 개발 원가 = 보정 전 개발 원가 X (규모 보정 계수 X 연계 복잡성 수준 보정 계수 X 성능 요구 수준 보정 계수 X 운영 환경 보환성 보정 계수 X 보안성 수준 보정 계수)

0개의 댓글

관련 채용 정보