[SOFTWARE DESIGN] Software Quality

12 Nov 2025 • SOFTWARE_DESIGN

소프트웨어 품질

목차

  1. 정의
  2. 관리 사이클 & 측정
    1. 관리 사이클
    2. 측정
  3. 품질 관리(Quality Control)
  4. 알고리즘 관점의 품질
  5. 소프트웨어 품질 모델
    1. McCall (1977)
      1. 목적·배경
      2. 3대 관점과 11개 요인
      3. 계층 구조(측정 프레임)
      4. 장점·한계
    2. Boehm (1978)
      1. 목적·배경
      2. 구조(3계층)
      3. 모델 관계·특징
      4. 장점·한계
    3. FURPS(+)
      1. 목적·배경
      2. 구조
      3. 모델 관계/특징
      4. 장점·한계
    4. Dromey
      1. 목적·배경
      2. 구조
      3. 모델 관계/특징
      4. 장점·한계
    5. ISO 9001 (QMS)
      1. 목적·배경
      2. 구조
      3. 모델 관계/특징
      4. 장점·한계
    6. ISO 9126
      1. 목적·배경
      2. 구조
      3. 모델 관계/특징
      4. 장점·한계
    7. SPICE (ISO/IEC 15504)
      1. 목적·배경
      2. 구조
      3. 모델 관계/특징
      4. 장점·한계
    8. IEEE 표준군
      1. 목적·배경
      2. 구조
      3. 모델 관계/특징
      4. 장점·한계
    9. CMM / CMMI
      1. 목적·배경
      2. 구조
        1. CMM(5단계 성숙도 + KPA)
        2. CMMI(성숙도/연속 표현 + PA)
      3. 모델 관계/특징
      4. 장점·한계
    10. Six Sigma
      1. 목적·배경
      2. 구조
      3. 모델 관계/특징
      4. 장점·한계
    11. 정리
  6. 참고

1. 정의

  • Philip Crosby(1926~2001): 품질=요구사항(명세) 적합성
    • 명확한 정의·측정·관리 강조.
  • W Edwards Deming(1900~1993): 품질=고객 만족
    • 리더십·두려움 제거·부서 장벽 해소 등 14원칙으로 지속개선.
  • Armand V. Feigenbaum(1920~2014): 품질은 고객이 결정
    • 전사적 품질관리(TQC), 목표는 변동.
  • Kaoru Ishikawa(1915~1989): 표준 충족만으론 부족
    • 품질 범위 광범위, 가격=품질 속성 포함.
  • Joseph Moses Juran(1904~2008): 사용 적합성
    • 품질 기획–관리–개선의 구조화된 경영.

  • Walter Shewhart(1891~1967): 객관/주관 두 측면을 모두 다뤄야 함

  • 명세 적합성(Verification): 규격·요구사항 충족 여부.
  • 고객 요구 충족(Validation): 사용 맥락에서의 만족·가치.

2. 관리 사이클 & 측정

2.1. 관리 사이클

Alt Images

PDA Cycle(Walter A. Shewhart)

393x393

PDCA Cycle(Dr. W. Edwards): 계획→실행→점검→개선, 카이젠의 핵심 도구.

2.2. 측정

Measurement is the first step that leads to control and eventually to improvement. If you can’t measure something(to see), you can’t understand it. If you can’t understand it, you can’t control it. If you can’t control it, you can’t improve it. -James Harrington

  • 측정→이해→통제→개선의 출발점
  • 측정: 사물/사건에 숫자 부여하는 것이다.

3. 품질 관리(Quality Control)

Alt Images

품질 관리: 입력(input) → 프로세스(process) → 출력(output)으로 전환되는 동안 품질을 일관되게 확보/통제

470x210

품질 관리 프로세스: 품질 요구 정의 → 측정/점검 → 변동(문제) 식별 → 시정/예방조치 → 모니터링/표준화

Alt Images (a) 전통적 QC ↔ (b) 통계적 QC 대비.

  • 전통적 QC: 사후 검사, 합격/불합격 중심의 통제
  • 통계적 QC: 샘플링과 관리도 등 통계 기법으로 변동을 관리해 예방 중심으로 전환

4. 알고리즘 관점의 품질

  • Correctness(정확성)
  • Efficiency(효율성)
    • Alt Images
    • 시간 (O(f(n)))
    • 공간 (memory)
  • Maintainability(유지보수성)
    • Extendability(확장성)
  • Understandability(가독성)
    • Structure(구조)

5. 소프트웨어 품질 모델

Alt Images

5.1. McCall (1977)

5.1.1. 목적·배경

  • 1977년 미 공군/DoD 맥락에서 제안된 초기 제품 품질 모델로, 사용자 관점과 개발자 관점의 간극을 줄이기 위해 요인·기준·메트릭을 체계화.

5.1.2. 3대 관점과 11개 요인

  • Product Revision(변경 용이성): Maintainability, Flexibility, Testability.
  • Product Transition(환경 전이 적응): Portability, Reusability, Interoperability.
  • Product Operations(운용 특성): Correctness, Reliability, Efficiency(실행/저장), Integrity, Usability.

5.1.3. 계층 구조(측정 프레임)

  • 11 Factors(사용자 관점) → 23 Criteria(개발자 관점) → Metrics(측정)의 계층형 모델.
  • 메트릭은 예/아니오 질문으로 각 기준을 정량화하고, 기준→요인→제품 수준으로 합성 가능(단, 응답자 주관성 한계 지적).

5.1.4. 장점·한계

  • 장점: 제품 품질을 구체 항목(요인/기준) 으로 쪼개 사전 점검 체크리스트를 만들기 쉬움.
  • 한계: 일부 기준/질문이 주관적이고, 최신 표준(예: ISO 9126/25010)의 세부 분류 대비 표현력이 제한될 수 있음.

5.2. Boehm (1978)

5.2.1. 목적·배경

  • 1978년 Barry W. Boehm이 제안. 자동·정량 평가의 한계를 보완하기 위해 속성 집합과 메트릭으로 품질을 정성적으로 정의하는 계층형 모델(상위→중간→원시 특성).

5.2.2. 구조(3계층)

  1. 상위 특성(High-level): 사용자가 실제로 묻는 3가지 질문
    • As-is Utility: 지금 당장 신뢰성·효율성·사용성 측면에서 잘 쓸 수 있는가?
    • Maintainability: 이해·수정·재테스트가 쉬운가?
    • Portability: 환경이 바뀌어도 쓸 수 있는가?
  2. 중간 요인(7 Factors): 시스템에 기대되는 품질, 각 요인의 정의와 귀속(As-is, Maintainability, General Utility)까지 제시
    • Portability
    • Reliability
    • Efficiency
    • Usability(인간공학)
    • Testability
    • Understandability
    • Flexibility(=Modifiability).
  3. 원시 특성(Primitive) & 메트릭 계층: 측정 기반을 제공(특성별 하나 이상 메트릭 연결).

5.2.3. 모델 관계·특징

  • McCall과 유사한 계층형이지만, 유지보수성(maintainability) 강조가 더 강하고 특성 범위가 넓다는 점이 차별점.
  • 상위 3특성(As-is, Maintainability, Portability)은 General Utility의 필요조건(충분조건은 아님).
  • 품질 역량 향상이 가져올 유지보수 비용 효율(maintenance cost-effectiveness) 을 주요 보상으로 본다.

5.2.4. 장점·한계

  • 장점:
    • 사용자 관점 질문→중간 요인→측정 가능한 원시 특성으로 추적 가능;
    • 유지보수성 중심의 실무 친화적 프레임.
  • 한계: 현대 표준(ISO/IEC 25010)에 비해 보안·호환성 등 최신 축은 상대적으로 약함(역사적 모델).

5.3. FURPS(+)

5.3.1. 목적/배경

  • 요구사항을 구조화하기 위한 모델: 기능(F)과 비기능(URPS)을 체계로 나눠 요구 수집·평가에 모두 쓰도록 설계됨.
  • 기원/확장: Robert Grady가 제안, 이후 Rational이 FURPS+ 로 확장.
  • 맥락: McCall/Boehm과 유사한 구조의 후속 모델(덜 유명하지만 언급 가치).

5.3.2. 구조

  • 5범주
    • Functionality: 기능 집합·능력·보안.
    • Usability: 인간공학·미학·UI 일관성·도움말/문서/교육.
    • Reliability: 고장 빈도·복구 가능성·예측 가능성·정확성·MTBF.
    • Performance: 속도·효율·가용성·처리량·응답/복구 시간·자원 사용.
    • Supportability: 테스트성·확장성·적응성·유지보수성·호환성·설치·현지화.
  • F vs URPS: F=기능 요구, URPS=비기능 요구(요구 정의/품질 평가에 모두 사용 가능).
  • “+”의 의미: 설계 제약, 구현 요구, 인터페이스 요구, 물리적 요구 등 부가 항목 포함.

5.3.3. 모델 관계/특징

  • 관계: McCall·Boehm과 같은 계층적 분류 틀을 취하면서, 요구/평가에 직접 적용 가능한 카테고리 제공.
  • 특징: 기능(F)과 비기능(URPS)을 명시적으로 분리해 NFR 누락 방지와 공통 언어를 제공.

5.3.4. 장점/한계

  • 장점
    • 요구 수집용 프레임: 초기에 빠르게 범주화하고, 릴리스 전/후 평가 항목으로 재사용 가능.
    • 포괄성: 보안·가용성·설치·현지화 등 실무적 비기능을 폭넓게 커버.
  • 한계
    • 표준 메트릭 규정 부재: 모델이 지표/치 환값을 규격화해 주진 않으므로, 팀이 프로젝트 맥락에 맞게 정량 기준(AC) 을 별도 정의해야 함(모델은 분류 틀 중심).
    • 역사적 분류 모델: 최신 표준(예: ISO/IEC 25010)처럼 공식 규격·평가지표 세트를 제공하는 형태는 아님(요구 분류·평가의 보조 틀에 강점).

5.4. Dromey

5.4.1. 목적/배경

  • 제품마다 “품질 평가가 다르다”는 현실을 반영하여, 제품 속성(Product properties) 을 품질 속성(Quality attributes) 에 동적으로 연결해 평가하는 제품기반 모델을 제안. McCall·Boehm·FURPS(+)와 유사한 계보에서 발전.

5.4.2. 구조

  • 핵심 3요소:
    • 품질에 영향 주는 제품 속성
    • 고수준 품질 속성
    • 두 집합을 잇는 링킹 메커니즘
  • 5단계 절차:
    1. 평가에 필요한 고수준 품질 속성 선택
    2. 컴포넌트/모듈 목록화
    3. 각 컴포넌트의 품질-보유 속성 식별
    4. 속성이 품질 속성에 미치는 영향 규정
    5. 모델 평가 및 약점 식별.

5.4.3. 모델 관계/특징

  • 관계: McCall·Boehm·FURPS(+)와 같은 계층/속성 기반 품질 모델 계열에 속하며, 차별점은 제품 속성↔품질 속성의 명시적 연결과 평가의 동적 적용성.
  • 출전: Dromey 1995(IEEE TSE), 1996(IEEE Software)로 정리됨.

5.4.4. 장점/한계

  • 장점
    • 맞춤형 평가: 시스템/컴포넌트 수준에서 실제 제품 속성을 품질 속성과 직접 매핑 → 프로젝트별 타당한 품질 체크리스트를 구성 가능.
    • 추적성: “어떤 구현 속성이 어떤 품질에 영향을 주는가”를 근거 기반으로 설명 가능(링킹 메커니즘).
  • 한계
    • 모델 일반 한계 공유: 품질을 정량화 가능한 정적 속성 집합으로 축약하는 경향이 있어, 동적으로 변하는 고객 기대를 모두 포착하기 어렵다.
    • 실행 부담: 컴포넌트 수준 속성 식별·매핑 작업이 요구되어 초기 셋업 비용이 듦(5단계 절차 특성상).

5.5. ISO 9001 (QMS)

5.5.1. 목적/배경

  • 모든 산업·조직에 적용 가능한 프로세스 기반 품질경영시스템(QMS) 표준.
  • 목표: 일관된 품질과 고객 만족 달성(요구 사항 충족 + 지속적 개선).
  • PDCA와 위험 기반 사고(Risk-based thinking) 를 통해 프로세스를 설계·운영·개선.

5.5.2. 구조

  1. 조직 상황(Context): 이해관계자·범위·프로세스 식별
  2. 리더십(Leadership): 품질방침·책임·권한
  3. 기획(Planning): 리스크/기회, 품질목표, 변경 계획
  4. 지원(Support): 자원, 역량, 인식, 커뮤니케이션, 문서화(기록 포함)
  5. 운영(Operation): 운영계획·설계/개발·외부공급자 관리·생산/서비스 제공·비적합 관리
  6. 성과평가(Performance Evaluation): 모니터링/측정, 내부심사, 경영검토
  7. 개선(Improvement): 시정조치(CAPA), 지속적 개선

5.5.3. 모델 관계/특징

  • 제품 품질 모델(맥콜·보헴·FURPS·ISO 9126/25010) 이 “무엇이 좋은 제품인가”를 정의한다면, ISO 9001은 “그 품질을 조직 프로세스로 어떻게 보증할 것인가”를 규정.
  • SPICE(15504)/CMMI와 같이 프로세스 성숙/평가 지향 모델과 상보적.
  • 감사·인증 가능(3rd-party certification) → 대외 신뢰성 확보에 유리.

5.5.4. 장점/한계

장점

  • 업종 불문 재사용 가능한 공통 프레임(프로세스·문서·책임체계 정립).
  • 경영층 관여와 정량적 목표/감사로 실행력 확보.
  • 지속적 개선(PDCA, CAPA) 내재화 → 장기적 품질 안정.

한계

  • 제품 자체의 기술 품질(성능·보안 등) 지표를 직접 제시하지 않음(별도 모델/지표 필요).
  • 문서·감사 중심으로 흐를 위험(형식주의) + 소규모 팀엔 초기 도입 부담.
  • 인증이 실제 고객가치 보장을 자동으로 의미하진 않음(운영 성숙도에 좌우).

5.6. ISO 9126

5.6.1. 목적/배경

  • 소프트웨어 제품 품질 평가를 위한 국제 표준(ISO/IEC 9126).
  • McCall·Boehm 계열을 표준화해 공통 용어와 평가 틀을 제공(내부/외부/사용중 품질까지 포괄).

5.6.2. 구조

  • 6대 특성:
    • 기능성(Functionality)
    • 신뢰성(Reliability)
    • 사용성(Usability)
    • 효율성(Efficiency)
    • 유지보수성(Maintainability)
    • 이식성(Portability).
  • 하위 특성(예시)
    • 기능성: 적합성, 정확성, 보안, 상호운용성, 규정준수
    • 신뢰성: 성숙도, 결함허용, 복구가능성
    • 사용성: 이해·학습·운용 용이성, 매력성
    • 효율성: 시간행태(응답/처리량), 자원행태(CPU/메모리)
    • 유지보수성: 분석·변경·안정·테스트 용이성
    • 이식성: 적응성, 설치용이성, 대체가능성
  • 품질 관점 3층
    1. 내부 품질: 코드/설계 산출물 기준 지표
    2. 외부 품질: 실행 중 시스템 관찰 지표(테스트 결과 등)
    3. 사용 중 품질: 실제 사용 맥락에서의 효과성·생산성·안전성·만족도

5.6.3. 모델 관계/특징

  • McCall·Boehm의 계층 아이디어 계승 + 기능성(특히 보안/상호운용성)을 명시적으로 포함.
  • 이후 ISO/IEC 25010(SQuaRE) 로 발전(특성 체계가 확장·개편됨).
  • 제품 품질 중심(조직/프로세스는 ISO 9001, SPICE, CMMI가 담당) — 상호보완적 사용 권장.

5.6.4. 장점/한계

  • 장점
    • 널리 통용되는 표준 용어·카탈로그로 팀 간 커뮤니케이션 원활.
    • 6특성/하위특성 기반으로 체크리스트·평가표를 만들기 쉬움.
    • 내부→외부→사용중으로 이어지는 평가 연계 구조 제공.
  • 한계
    • 메트릭 자체를 규정하지 않음(프로젝트 맥락에 맞는 정량 기준을 별도 정의 필요).
    • 최신 요구(예: 개인정보보호, 클라우드 네이티브 특성 등)에 대해선 후속 표준(ISO 25010) 대비 표현력이 제한.
    • 제품 품질만 다루므로 프로세스 성숙도나 조직 역량은 다른 모델과 결합해야 함.

5.7. SPICE (ISO/IEC 15504)

5.7.1. 목적/배경

  • 목적: 소프트웨어 조직의 프로세스 평가(assessment) 와 개선(improvement), 공급자 프로세스 역량 결정(capability determination) 을 체계화.
  • 범위: 획득·개발·운영·공급·유지보수·지원 등 소프트웨어 생애주기 전 과정을 포괄.
  • 약어: SPICE = Software Process Improvement and Capability dEtermination.

5.7.2. 구조

  • 9개 Part(구성)
    1. 개념/입문
    2. 프로세스·프로세스 역량 참조모형
    3. 평가 수행
    4. 평가 수행 가이드
    5. 평가 모형·지표 가이드
    6. 평가자 역량 가이드
    7. 프로세스 개선 활용 가이드
    8. 공급자 프로세스 역량 결정 가이드
    9. 용어

5.7.3. 모델 관계/특징

  • 성격: 제품 품질 모델(맥콜·보헴·ISO 9126)보다, ISO 9000(품질경영), ISO/IEC 12207(생명주기 프로세스), CMM(성숙도) 에 더 가깝고 프로세스 중심.
  • 12207과의 정렬: 12207이 정의하는 Primary/Supporting/Organization 프로세스 구조와의 정합성이 강조됨(획득·공급·개발·운영·유지보수 등).
  • 평가→개선의 연결:
  • 참조모형(2번), 기반 평가 (3~5번), 결과를 개선 (7번), 공급자 역량 판단 (8번) 으로 이어지는 운영 체계.

5.7.4. 장점/한계

  • 장점
    • 표준화된 프로세스 평가 체계로 조직 내부/외부 비교 가능, 공급자 역량 판단에 직접 사용 8).
    • 참조모형+평가모형+개선 가이드가 일관된 루프를 형성하여 지속적 개선에 적합.
  • 한계
    • 제품 품질 특성(성능·보안 등)을 직접 규정하지 않음 → ISO 9126/25010 같은 제품 품질 모델과 병행 필요(프로세스 중심 한계).
    • 평가·문서화 비용과 평가자 역량 요건이 있어 소규모 팀에는 초기 도입 부담.

5.8. IEEE 표준군

5.8.1. 목적/배경

  • 소프트웨어 전 생애주기에서 요구·설계·검토·테스트·QA·형상·프로젝트관리·메트릭·사용자문서 등을 일관된 문서/절차로 정의하기 위한 실무 표준 집합.
  • 대표적으로 SQA(730), SCM(828), 테스트 문서(829), SRS(830), V&V 계획(1012), 설계 설명(1016), 리뷰(1028), 프로젝트 관리 계획(1058), 품질 메트릭 방법론(1061), 사용자 문서(1063), 생애주기 프로세스(1074), 시스템 엔지니어링(1220), 그리고 ISO/IEC 12207 구현 규격(IEEE/EIA 12207) 등이 포함된다.

5.8.2. 구조

  • 생애주기 흐름별 핵심 표준: 이 표준군은 문서 형식·필수 항목·절차를 규정해 산출물의 형식과 최소 기준을 통일한다.
    • 요구: 830(SRS)
    • 설계/검토: 1016(설계 설명), 1028(리뷰)
    • 검증/시험: 1012(V&V 계획), 829(테스트 문서)
    • 품질/형상/프로젝트: 730(SQA 계획), 828(SCM 계획), 1058(프로젝트 관리 계획)
    • 측정/문서: 1061(품질 메트릭 방법론), 1063(사용자 문서)
    • 프로세스/시스템: 1074(소프트웨어 생애주기 프로세스), 1220(시스템 엔지니어링 프로세스), IEEE/EIA 12207(ISO/IEC 12207의 산업 적용 표준)

5.8.3. 모델 관계/특징

  • IEEE/EIA 12207은 ISO/IEC 12207을 구현하며 Primary(획득·공급·개발·운영·유지보수), Supporting(문서·형상·QA·검증·검증·합동검토·감사·문제해결), Organization(관리·인프라·개선·교육) 프로세스를 명시한다. 제품 품질 모델(McCall·Boehm·ISO 9126)보다는 프로세스/문서 체계에 가깝다.
  • ISO 9000과의 정렬성이 높아, 소프트웨어 조직에서 ISO 대체 가능성까지 언급될 정도로 유사성이 크다.

5.8.4. 장점/한계

  • 장점
    • 표준 템플릿/체크리스트로 산출물 일관성·감사 가능성 제고(예: 829 테스트 문서, 830 SRS, 1058 SPMP).
    • 메트릭 체계화: 1061이 품질 요구 수립–지표 식별–분석–검증 방법론을 제공 → 측정 기반 품질 관리에 유리.
  • 한계
    • 제품 품질 특성 그 자체(성능·사용성·보안 등)를 정의·분류하는 품질 모델은 아님 → ISO 9126/25010 등과 병행 적용 필요.
    • 문서·절차 중심으로 과도하게 흐르면 형식주의 위험과 도입/유지 비용이 증가할 수 있음(특히 소규모 팀).

5.9. CMM / CMMI

5.9.1. 목적/배경

  • CMM(SW-CMM): 소프트웨어 품질을 프로세스 관점에서 다루기 위해 SEI가 제안한 성숙도 모델(DoD 후원). 프로세스 준수/역량 수준으로 품질을 관리.
  • CMMI: SW-CMM을 확장·통합(시스템+소프트웨어 등)한 프레임워크. Process/Project/Engineering/Support 4개 영역으로 구성.

5.9.2. 구조

5.9.2.1. CMM(5단계 성숙도 + KPA)
  1. Initial: 무정형, KPA 없음
  2. Repeatable: 요구·계획·추적·SQA/SCM 등
  3. Defined: 조직 프로세스 정의·교육·동료검토·통합관리 등
  4. Managed: 정량적 관리, 품질관리
  5. Optimizing: 결함 예방·변경관리
5.9.2.2. CMMI(성숙도/연속 표현 + PA)
  • 성숙도 레벨:
    • 0 - Incomplete
    • 1 - Initial
    • 2 - Managed
    • 3 - Defined
    • 4 - Quantitatively Managed
    • 5 - Optimizing.
  • 주요 Process Areas(예):
    • L2: REQM, PP, PMC, SAM, MA, PPQA, CM
    • L3: REQD, TS, PI, VER, VAL, OPF, OPD, OT, IPM, RSKM, DAR
    • L4: OPP, QPM, L5: OID, CAR
      (모델은 Staged/Continuous 두 표현 제공)

5.9.3. 모델 관계/특징

  • SPICE/ISO 9000/ISO 12207와 더 가까운 프로세스 중심 계열(제품 특성 모델인 McCall/Boehm/ISO 9126과 대비).
  • CMMI는 SW-CMM을 대체하며, 시스템·소프트웨어 통합 프레임으로 경영·프로젝트·엔지니어링·지원 전반을 포괄.

5.9.4. 장점/한계

  • 장점:
    • 조직 프로세스 성숙도를 단계적으로 제시 → 개선 로드맵/비교 가능성 확보(KPA로 실행 항목 명확).
  • 한계:
    • 품질을 프로세스/역량 수준으로 측정하는 성격상, 제품 자체의 세부 속성(성능·사용성 등)은 직접 규정하지 않음(제품 품질 모델과 병행 필요).
    • 모델 일반 한계: 정형화된 속성/수준에 의존해 동적 고객 기대를 충분히 포착하지 못할 수 있음.

5.10. Six Sigma

5.10.1. 목적/배경

  • 경영 철학: 고객 중심의 측정과 목표 설정을 통해 수익(바텀라인) 개선을 지향. 고객의 소리를 듣고(VOC), 이를 측정 가능한 요구로 변환한다.

5.10.2. 구조

  • 핵심 흐름: VOC 수집 → 요구의 정량화(측정 지표 정의) → 목표값 설정 → 데이터 기반 개선 사이클 수행(예: 프로젝트 단위).

5.10.3. 모델 관계/특징

  • 품질 모델 ↔ 경영 철학:
    • 맥콜/보헴/ISO 9126 같은 제품/측정 모델은 단순·정적 속성으로 품질을 계량화하기 쉽다.
    • Six Sigma 같은 경영 철학은 고객 기대가 계속 변하는 동적 관점을 반영해 품질의 본질을 더 잘 포착한다는 논지. 두 접근은 상호보완적이다.
  • 조직 역량 문맥: 강의 슬라이드도 CMMI와 함께 6 Sigma를 조직 능력 프레임으로 병기.

5.10.4. 장점/한계

  • 장점
    • 고객 가치 정렬: VOC→측정 요구 전환으로 고객 중심 성과를 직접 겨냥.
    • 정량 목표: 명확한 목표 설정과 데이터 기반 실행으로 결과 지향(바텀라인).
  • 한계
    • 문헌 범위상 개념 소개: 본 자료는 프레임(철학)만 제시하며, 세부 기법·지표 체계(DMAIC/CTQ 등)는 별도 설계 필요.
    • 제품 품질 분류 부재: 성능/보안/사용성 등 제품 특성의 표준 분류·메트릭은 ISO 9126/25010 같은 제품 품질 모델과 병행해야 함.

5.11. 정리

모델 분류 핵심 초점 대표 특성/키워드 주 사용 맥락 · 산출물
McCall (1977) 제품 3축: 운용·수정·전이 11 요인·23 기준·메트릭 출시 전 품질 체크리스트, 내부/외부 품질 점검표
Boehm (1978) 제품 상위 3(As-is·Maintain·Port) + 중간 7 유지보수성·이해가능성 강조 품질트리 기반 갭 분석, 유지보수 비용 추정 근거
FURPS(+) 요구/제품 F(기능) / URPS(비기능) 분류 Usability, Reliability, Performance, Supportability(+확장성 등) 요구사항 구조화, 수용 기준(AC) 정의
Dromey 제품 제품속성 ↔ 품질속성 링크 컴포넌트별 속성 매핑, 동적 평가 프로젝트 맞춤 품질모델, 영향 매트릭스
ISO 9001(QMS) 프로세스/조직 프로세스 지향 품질경영 설계–운영–모니터–개선, 내부감사 QMS 매뉴얼·절차서, 인증 준비/유지
ISO 9126 제품 6특성: 기능성·신뢰성·사용성·효율성·유지보수성·이식성 내부/외부/사용중 품질 공통 평가지표 체계, 품질 리포트
SPICE(15504) 프로세스 프로세스 역량 평가 획득·개발·운영·지원 전반 프로세스 성숙도(능력수준) 평가보고서
IEEE 표준군 실무 표준 SRS/SQA/SCM/테스트/V&V 문서화 730, 828, 829, 830, 1012… 표준 양식·체크리스트·산출물 일관화
CMM/CMMI 프로세스/조직 성숙도 0~5 단계 정량관리·최적화, KPA/PA 성숙도 진단 및 개선 로드맵
Six Sigma 경영/개선 VOC→CTQ, DMAIC, 3.4 DPMO 데이터 기반 결함/변동 감소 개선 프로젝트 차터·지표 대시보드

참고

 SOFTWARE_DESIGN

Comments

Newest Posts