소프트웨어 개발 방법론 테일러링

교과서에 나오는 폭포수·애자일 같은 개발 방법론을 실제 프로젝트에 그대로 적용하는 경우는 드물다. 팀 규모, 일정, 고객 요구사항이 프로젝트마다 다르기 때문에 방법론의 틀은 유지하되 세부 절차·산출물을 프로젝트 상황에 맞게 잘라내고 조정하는 작업이 필요한데, 이것이 테일러링(Tailoring)이다.

테일러링 개요

• 기존 소프트웨어 개발 모델의 최적화
• 가공, 적용, 정제 과정을 포함
• 개발 모델 선정 시 내부적 요건과 외부적 요건의 충돌 해결을 위해 사용

테일러링 프로세스

1. 프로젝트 자원 현황 반영
2. 현실을 반영한 절차 수립
3. 메뉴얼 작성

소프트웨어 개발 프로젝트

기본 특성

• 목표 달성 지향
• 정해진 시간 내 단계적 진행
• 인적자원 및 일정(process) 관리

5대 관리요소

1. 일정
2. 비용
3. 투입 자원
4. 위험
5. 품질

계획 및 예측

프로젝트 비용 결정 요소

1. 프로젝트 요소

• 규모
• 신뢰도
• 복잡도

2. 자원 요소

• 인적자원
• 하드웨어
• 소프트웨어 라이선스

3. 생산성 요소

• 개발 기간
• 개발자의 능력

프로젝트 일정 관리

관리 원칙

• 분할
• 상호 관계 네트워크
• 시간 할당
• 참여 인원은 시작 전에 결정
• Brooks의 법칙: 진행 중 새로운 인원 추가 시 일정 지연 발생

일정계획 방법론

PERT (Program Evaluation and Review Technique)

• 작업 개발 기간이 불확실한 경우 사용
• 예측치 = (낙관치 + (4 × 기대치) + 비관치) / 6
• 예시: 낙관치 1일, 기대치 2일, 비관치 3일이면 예측치 = (1 + 4×2 + 3) / 6 = 2일. 세 가지 추정값 중 “기대치”에 4배 가중치를 줘서, 극단적인 낙관/비관 추정에 덜 흔들리는 값을 얻는 것이 이 공식의 요점이다.

CPM (Critical Path Method)

• 작업 개발 기간이 확실한 경우 사용
• 주공정경로(임계경로): 작업 소요시간이 가장 긴 경로
• 더 긴 경로를 선택하여 합산
• 박스노드(이정표): 모든 작업 완료 후 다음 단계 진행

간트 차트

• 막대그래프 형태의 일정 표현
• 한계점:
  • 상세 정보 표현의 어려움
  • 의존성, 문제요인 등 표현 제한
• 소규모 프로젝트 활동에 적합

프로젝트 비용 산정

소프트웨어 사업비 종류

1. 계획 수립비
2. 개발비
3. 유지보수비
4. 데이터베이스 구축비
5. 환경구축비

비용 산정 특징

• 사전 비용 산정의 중요성
• 저비용 책정의 문제점:
  • 개발자 부담 증가
  • 품질 저하 위험
• 합리적 산출법 필요
• 접근 방식:
  • 하향식
  • 상향식

하향식 비용 산정 기법

• 과거 경험 기반 (비과학적)
• 전체 비용 선 산정 후 기능별 세분화

전문가 측정 기법

• 신속한 비용 산정 가능
• 개인적, 주관적 성향

델파이 측정 기법

• 중재자 의견 조합 방식

상향식 비용 산정 기법

• 세부 작업 단위 비용 선 산정
• 전체 비용 후 산정

LOC (Line Of Code)

• 예측치 = (낙관치 + (4 × 기대치) + 비관치) / 6
• 주요 공식:
  • 노력 = 개발 기간 × 투입 인원 = LOC/인당 월평균 생산 코드 라인
  • 개발 비용 = 노력 × 월평균 인건비
  • 개발 기간 = LOC/인당 월평균 생산 코드 라인/투입 인원

단계별 노력 기법

• LOC 보완 목적
• 노력에 가중치 별도 반영

수학적 산정 기법

COCOMO

• LOC 기반 비용 산정
• 유형 구분:
  • Organic 조직형: 5만 라인(50KDSI)
  • Semi-Detached 반분리형: 30만 라인 이하(300KDSI)
  • Embedded 내장형: 30만 라인 이상(300KDSI)

Putnam

• Rayleigh-Norden 곡선 기반
• 전체 개발 과정의 노력 분포 예측
• 대형 프로젝트 노력 분포 산정에 적합
• 특징:
  • 기간 증가 시 적용 인원 노력 감소
  • 자동화 측정 도구: SLIM

기능 점수 기법

• 기능 난이도에 따른 차등 비용
• 기능 증대 요인:
  1. 입력
  2. 출력
  3. 사용자 질의
  4. 데이터 파일
  5. 인터페이스
• 자동화 측정 도구: ESTIMACS

투입 인력 자원 구성

책임 프로그래머 팀 유형

• 특징:
  • 1인 책임 프로그래머, 다수 보조
  • 소규모 프로젝트, 단기적 적합
• 단점:
  • 낮은 만족도
  • 높은 이직률

민주주의식 팀 유형

• 개인별 독립적 담당 영역 존재
• 책임 프로그래머 팀 유형과 대비되는 특성

소프트웨어 품질 관리

ISO/IEC 12207

• 국제 표준화 기구 제정 표준 수명 주기 프로세스
• 분류:
  • 기본
  • 지원
  • 조직

ISO/IEC 12119

• 소프트웨어 품질 요구사항과 테스트 국제표준

ISO/IEC 25010

• 품질 특성 및 평가 표준
• 6대 외부 품질 특성:
  1. 기능성
  2. 신뢰성
  3. 사용성
  4. 효율성
  5. 유지보수성
  6. 이식성
• 21개 세부 항목으로 확장

CMM (Capability Maturity Model)

• 업무 능력 평가 기준 성숙도 모델
• 특징:
  • 제품 자체 품질과 무관
  • 소규모 업체 적용 어려움

CMM 단계별 프로세스 성숙도

1. 초기
2. 반복
3. 정의
4. 관리
5. 최적화

CMM 관리 품질 평가 기준

• 레벨 1: 혼돈적 관리
• 레벨 2: 경험적 관리
• 레벨 3: 정성적 관리
• 레벨 4: 정량적 관리
• 레벨 5: 최적화 관리

CMMI

• CMM 발전 모델
• 통합 요소:
  • SW-CMM
  • SE-CMM
  • IDP-CMM

CMMI 단계별 프로세스 성숙도

1. 초기
2. 관리
3. 정의
4. 정량적 관리
5. 최적화

SPICE (ISO/IEC 15504)

• ISO/IEC 12207 파생
• CMM 단점 개선 목적
• 목적: 자체 평가 및 프로세스 평가

SPICE 단계별 프로세스 성숙도

• 레벨 0: 불완전
• 레벨 1: 수행
• 레벨 2: 관리
• 레벨 3: 확립
• 레벨 4: 예측 가능
• 레벨 5: 최적

CASE 도구

특징

• 개발 프로세스 전 과정 자동화 지원
• 장점:
  • 재활용성
  • 점진적 개발
  • 유지보수
  • 생산성 향상
  • 신뢰성 향상
• 단점:
  • 높은 비용
  • 명령어, 문법 숙지 필요
  • CASE 도구 간 호환성 부족

주요 CASE 도구

SADT

• SoftTech사 개발
• 블록다이어그램 채택 자동화 도구

SREM

• TRW사 개발
• RSL과 REVS 사용
• REVS: RSL 기술 요구사항 분석 명세서 출력 시스템

TAGS

• 시스템 공학 방법 응용 자동 접근 방법
• 통합 자동화 도구

PSL/PSA

• PSL: 요구사항 기술언어
• PSA: 분석 명세서 출력 분석 시스템

프로젝트 형상 관리

개요

• 산출물의 종합 및 변경 과정(버전) 체계적 관리
• 목적: 정상적, 절차적 변경사항 반영

특징

• 다중 개발자 협업 시 문제 최소화
• 불필요한 수정 제한
• 변경사항 관리 용이

주요 활동

형상 식별

• 관리 대상 식별 및 관리번호 부여
• 기준선(Baseline) 설정으로 수정/추적 가능화

형상 통제

• 베이스라인 적용 소프트웨어 수정사항 최종 반영 결정
• 별도 조직의 승인 필요

형상 상태 보고

• 작업 결과 기록 및 관리

형상 감사

• 베이스라인 무결성 승인을 위한 공식 검증

핵심 정리

• 테일러링은 방법론을 “덜어내는” 작업이지 새로 만드는 게 아니다 — 프로젝트 규모·기간·팀 숙련도에 맞춰 산출물과 절차의 양을 조절한다.
• 비용 산정은 하향식(경험 기반, 빠르지만 주관적)과 상향식(세부 작업 단위 합산, 정확하지만 시간이 걸림)이 대비되고, COCOMO·기능점수 같은 수학적 기법은 이 둘의 주관성을 줄이려는 시도다.
• 형상 관리(Configuration Management)는 “누가 언제 무엇을 왜 바꿨는지”를 추적 가능하게 만드는 절차이며, Git 같은 도구가 실무에서 이 개념을 구현한 사례에 해당한다.