소프트웨어 공학의 목표 재검토

• 사용자의 요구를 만족시키는, 예산 내에서 제시간에 고품질 소프트웨어를 생산하는 것
• 소프트웨어의 품질과 생산성 향상
• 시스템, 제품의 품질과 생산성 향상
• 비즈니스 성과 개선

소프트웨어 품질 정의

• DoD, 1985: “소프트웨어 속성이 의도된 최종 사용을 수행할 수 있는 정도”

• ISO, 1986: “제품 또는 서비스의 특정하거나 암시된 요구를 만족시킬 수 있는 특성과 특징의 총체”

• Kitchenham, 1986: “필요에 적합함”

  • 명세 준수: 이 소프트웨어가 좋은 해결책인가?
  • 의도된 목적에 적합함: 올바른 문제를 해결하고 있는가?

  소프트웨어 제품이 사용자 요구를 충족할 수 있는 능력

소프트웨어 품질에 대한 통찰

• 품질은 절대적인 것이 아님
• 품질은 다차원적임
• 품질은 사람, 자금, 시간, 도구 등 제약을 받음
• 품질은 수용 가능한 타협에 관한 것임
• 품질 기준은 독립적이지 않음

소프트웨어 품질이 다른 품질과 다른 이유

• 소프트웨어는 물리적 실체가 없음
• 초기에는 고객 요구에 대한 지식이 부족함
• 시간이 지나면서 고객 요구가 변화함
• 하드웨어와 소프트웨어 모두에서 변화 속도가 매우 빠름
• 고객의 기대가 매우 높음

품질 요소

• 후원자
• 유지보수 관리자
• 사용자

품질 분류

• 외부 품질: 시스템의 사용자가 볼 수 있는 품질
• 내부 품질: 시스템 개발자와 관련된 품질
• 제품 품질과 프로세스 품질의 구분은 명확하지 않음

제품 품질과 프로세스 품질

• 서로 밀접한 관련이 있음
• 프로세스를 사용하여 소프트웨어 제품을 만듦
  • 제품 품질:
    • 기능성
    • 사용성
    • 효율성
    • 신뢰성 등
  • 프로세스 품질:
    • 방법, 도구의 효과성
    • 표준의 사용 (표준 준수)
    • 관리 등

대표적인 품질 특성

• 정확성, 신뢰성, 견고성
• 성능
• 사용자 친화성
• 검증 가능성
• 유지보수성
• 재사용성
• 이식성
• 이해성
• 상호운용성
• 생산성
• 적시성
• 가시성

정확성, 신뢰성, 견고성

• 서로 상호 교환적으로 사용되며, 애플리케이션이 예상대로 기능을 수행하는 정도를 의미함

• 정확성: 프로그램이 기능 명세에 따라 동작하면 정확하다고 할 수 있음

  • 가정:
    • 시스템의 명세가 제공되어야 함
    • 프로그램이 명세를 충족하는지 명확하게 판단할 수 있어야 함

신뢰성

• 신뢰성 = 의존성: 사용자가 시스템에 의존할 수 있는 경우
• 제품 실패 빈도 및 심각성의 측정
• 실패: 허용 가능한 작동 조건에서 발생하는 허용 불가능한 효과나 행동

견고성

• 요구 사항 명세에서 예상하지 못한 상황에서도 합리적으로 동작할 수 있으면 견고하다고 함
• 다양한 요인에 의해 결정됨:
  • 작동 조건의 범위
  • 유효한 입력에서 발생할 수 있는 허용 불가능한 결과의 가능성
  • 잘못된 입력이 주어졌을 때 결과의 수용성

성능

• 성능은 효율성(공간, 시간)과 동일시됨
• 시스템의 사용성에 영향을 미침
  • 평가:
    • 측정(모니터링)
    • 분석
    • 시뮬레이션

사용자 친화성

• 사용의 용이성
• 시스템이 개인화된 환경에 맞게 쉽게 구성되고 적응할 수 있는 정도

검증 가능성

• 소프트웨어의 속성이 안전하게 검증될 수 있으면 검증 가능함
• 공식 분석 방법 또는 철저한 테스트를 통해 수행됨

Maintainability(유지가능성)

• 유지:
  • 오류 수정 (Corrective)
    • 오류 fixing
  • 적응 (Adaptive)
    • flatform change
  • 완전성 (Perfective)
    • code restructuring
  • 예방적 유지보수 (Preventive)
    • 유지보수 -> 적응 / 진화
• 소프트웨어 진화 (유지 대신)
• 수리 가능성과 진화가능성

Repairability(수정 가능성)

• 소프트웨어 시스템이 결함을 한정된 작업량으로 수정가능한가
• 올바른 모듈화 => 수정 가능성 향상 Why? 이게 뭐냐
• Repairability에서 SW와 HW의 차이점**
  • 소프트웨어는 고치면 되지만 하드웨어는 갈아끼워야 함.
  • 더 야무진말 없나
  • 소프트웨어는 교체가 용이하지만 하드웨어는 장비를 교체해야하기 때문에 쉽지않음?
• HL(High Level), PL(Programing Languege), CASE(Computer-Aided Software Engineering) = Tool
• 신뢰성과 관련

진화성(Evolvability)

• 소프트웨어는 시간이 지남에 따라 새로운 기능을 제공하거나 기존 기능을 변경
• 규모가 크고 복잡한 소프트웨어에서 중요함
• 모듈화를 통해 달성
• 새로운 버전이 릴리스될 때마다 진화성이 감소 => 규모가 더 커지기 때문에
  • 따라서 문서/spec, Tool이 필요함.
• 진화성 강화 방법
  • product family
    • 공통 기술과 핵심 기능을 공유하면서 다양한 고객 요구에 맞춰 변형된 제품 그룹
    • product line(제품군)과 유사
  • software architecture

재사용성(Reusability)

• 기존 구성 요소를 사용하여 새 제품을 구축하는 능력
• ex
  • 과학 라이브러리
  • MFC
  • Eclipse
  • 플러그인
  • ...
• 재사용 단계
  • People
    • 사람의 지식, 경험
  • Requirements
  • Design
    • Design Pattern
  • Code
• 다른 재사용 단계
  1. Module
  2. Function
  3. program
  4. software
  5. service
• 프로세스 재사용 어플리케이션
  • 소프트웨어 방법론(Software methodology)
  • [Life cycle model](ProcessModel#소프트웨어 생명주기 모델 (Software Life Cycle Model))

Portability(이식성)

• 소프트웨어가 다양한 환경에서 이식(실행)될 수 있는 능력
  • 하드웨어 플랫폼
  • 소프트웨어 플랫폼
• 모듈화로 달성
  • 모듈화는 어떻게 해야할까?

UnderStandability(이해성)

• 내부(개발자 관점) 생산 품질
• 객체지향 구조를 이해하면 편함
• 추상화와 모듈방식에 따라 강화
• Maintainability과의 관계는
  • 비례관계

Interoperability(상호 운용성)

• 시스템이 다른 시스템과 공존하고 협력할 수 있는 능력
• 인터페이스 표준화를 통해 달성
• 개방형 시스템 개념
• **IOT, Military(국방)**에서 가장 중요

Productivity(생산성)

• 소프트웨어 생산 프로세스의 효율성과 성능의 품질

• 측정하기 어려움:

  • 간단한 측정 기준: SLOC (Source Lines Of Code)(코드 라인 수)
  • 기능 기반 측정 기준: FP (Function Point)(기능 점수)

Timeliness(적시성)

• 제품을 제시간에 전달할 수 있는 능력
• Time-to-Market
  • 제품 개발부터 실제로 판매되기까지 걸리는 시간
• 요구사항
  • 철저한 스케줄링
  • 정확한 작업 추정
  • 명확한 마일스톤 설정

철저하고 정확한 계획을 세워도 변경을 발생할 수 밖에 없음

• incremental delivery로 달성
  • incremental model과 관련 있어보임

계획을 완수하지 못할 것 같으면 일부분 포기하고 마켓에 내놓는게 나을 수 있음

Visibility(가시성)

• 모든 단계와 현재 상태가 잘 문서화
• 행동의 영향을 주고 의사결정을 가이드
• 요구사항&설계 명세서

투명성

• 프로젝트의 단계와 상태가 외부 검토를 위해 이용 가능하고 접근 가능

제품이 visible하다(프로젝트 진행 관점)

• 모듈이 명확하게 구조화
• 기능이 명확하게 이해가능
• 문서화가 정확하고 이용 가능

Q: 왜 가시성이 중요한가?

• 개발 진도의 차이
• 팀원의 이탈

Security(보안성)

• 소프트웨어를 악의적인 공격 및 해커의 위험으로부터 보호하기 위해 아이디어가 구현됐는지

• 소프트웨어는 이러한 잠재적 위험 속에서도 정상적으로 기능을 수행

• 보안은 무결성, 인증, 가용성을 제공하기 위해 필수적

• Security Vulnerability(보안 취약점): 공격자가 실제로 악용할 수 있는 약점 또는 결함

  • accessible(접근 가능): 공격자가 그 결함에 접근할 수 있음
  • exploitable(악용 가능): 공격자가 그 결함을 통해 피해 일으킬 수 있음

• 보안 평가를 위한 주요 지표

  • 보안 위험
  • 보안 취약점
  • 사고 통계
  • 연간 기대 손실(Annualized Loss Expectancy)
  • 등

Safety(안전성)

소프트웨어 안전성 (Software Safety)

• 소프트웨어 위협부터 자유로운 상태 (IEEE Std-1228, 1994)
• 위험한 상황을 피하고, 상황이 안전하지 않으면 올바른 시스템에 경고를 보내는 것에 중점

소프트웨어 위협 (Software Hazard)

• 사건의 전제 조건이 되는 소프트웨어(운영) 상태

사고 (Accident)

• 사망, 부상, 질병, 환경 피해 또는 재산 손실을 초래하는 의도하지 않은 사건

소프트웨어 자체로는 발생하지 않고 소프트웨어가 하드웨어에게 영향을 끼치면서 발생

소프트웨어 안전성을 측정하는 방법

• Requirement Safety(안전에 대한 요구사항)
• Safety Guard(안전 가드)

특정 응용 분야에서의 품질 요구사항

정보 시스템 (Information Systems):

• 데이터 저장 및 검색
• 예시: 은행 시스템, 도서관 카탈로그 시스템 등
• 주요 품질 특성:
  • Data integrity(데이터 무결성)
  • Security(보안성)
  • Data availability(데이터 가용성)
  • Transaction performance(트랜잭션 성능)
  • User friendliness(사용자 친화성)

실시간 시스템 (Real-time Systems):

• 엄격하게 정의된 시간 내에 응답해야 함
• 예시: 공장 모니터링 시스템, 미사일 유도 시스템, 마우스 처리 소프트웨어
• 제어 지향 시스템
• 운영 체제 레벨에서 스케줄링
  • 마감 시간
  • 우선순위
• 주요 품질 특성:
  • 응답 시간 요구사항 (정확성 기준)
  • 안전성

분산 시스템 (Distributed Systems):

• 병렬 처리 및 통신
  • 작업 할당, 분할
• 분산의 정도:
  • 데이터
  • 제어
    • cell handover
  • 하드웨어
    • 중복관리
• 예시: 클라이언트/서버 시스템의 미들웨어, 그룹웨어 등
• 주요 품질 특성:
  • 시스템 가용성
  • 코드 이동성

임베디드 시스템 (Embedded Systems):

• 소프트웨어는 여러 구성 요소 중 하나임
• 최종 사용자에게는 인터페이스가 없거나 매우 제한됨
  • 버튼, 스위치정도의 인터페이스 밖에 없음
• 예시: 항공기, 로봇, 전자레인지, 식기세척기, 자동차 등
• 주요 품질 특성:
  • 신뢰성
    • 고장나면 안됨
  • 적응성
    • 여러곳에 적용가능
  • 메모리 및 성능 효율성 => 성능

AI/ML 시스템의 품질 요소

• 전통적인 소프트웨어와 근본적으로 다름:
  • 모델의 입력과 결과 간의 관계는 데이터의 일부 집합에 대해서만 정의되며, 이로 인해 이전에 보지 못한 데이터에 대해 모델 결과에 대한 불확실성이 존재함
    • 알고리즘의 문제는 없고 어떤 데이터가 필요한가 문제
  • 소프트웨어 공학의 캡슐화 및 모듈화와 같은 일반적인 개발 원칙은 다시 생각되어야 함. 예를 들어, 신경망은 단순히 더 작은 서브넷으로 나누어 모듈로 재사용할 수 없음
  • ML 구성 요소의 개발 및 통합은 다학문적 접근 방식을 요구함: 응용 도메인에 대한 지식, ML 모델을 구축하는 방법에 대한 지식, 소프트웨어 공학에 대한 지식이 필요함
  • 알고리즘보다는 학습 및 테스트에 사용된 데이터가 더 중요한 역할을 함

• AI/ML 시스템의 품질 요소:
  

  • 데이터 관점:

    • 대표성 (Representativeness)
    • 정확성 (Correctness)
      • 오류, 데이터 오류 얼마나
    • 완전성 (Completeness)
      • 누락데이터
    • 학습-테스트 독립성 (Train-test Independence)

  • 모델 관점:

    • 적합성 (Appropriateness)
      • 모델 선정 적합성
    • 적합도 (Goodness of Fit)
      • 데이터 처리 모델 적합성
    • 견고성 (Robustness)
    • 공정성 (Fairness)

  • 시스템 관점(형상):

    • 효과성(Effectiveness)
    • 효율성 (Efficiency)
      • 효율적으로 동작하는가

  • 인프라 관점(자원리소스):

    • 적합성 (Suitability)
    • 효율성 (Efficiency)

  • 환경적 관점(유저의 공간):

    • 환경적 영향 (Env. Impact)
    • 사회적 영향 (Social Impact)

소프트웨어 품질에 대한 표준

• 수많은 품질 요소가 존재
  • 이 요소들은 서로 독립적이지 않음
  • 일부 품질 요소들은 너무 밀접하게 관련되어 있음
    • 조사 및 평가하기 어려움
    • 시스템에 적용하기 어려움
• 소프트웨어 품질에 대한 표준:
  • ISO 9126: 소프트웨어 공학 — 제품 품질
  • ISO 25010: 시스템 및 소프트웨어 품질 요구사항 및 평가 (SQuaRE) — 시스템 및 소프트웨어 품질 모델
  • 그 외 다수…

ISO 9126: 여섯 가지 품질 특성

• ISO/IEC 9126: 소프트웨어의 여섯 가지 품질 특성
  • 기능성: 소프트웨어가 요구된 기능을 제공하는가?
  • 신뢰성: 소프트웨어가 얼마나 신뢰할 수 있는가?
  • 사용성: 소프트웨어를 사용하는 것이 얼마나 쉬운가?
  • 효율성: 소프트웨어가 얼마나 효율적인가?
  • 유지보수성: 소프트웨어를 수정하는 것이 얼마나 쉬운가?
  • 이식성: 소프트웨어를 다른 환경으로 옮기는 것이 얼마나 쉬운가?

ISO 9126의 여섯 가지 품질 특성과 하위 특성

• 특성 & 하위 특성:
  • 기능성: 적합성, 정확성, 상호운용성, 준수성, 보안성
  • 신뢰성: 성숙도, 장애 허용성, 복구 가능성
  • 사용성: 이해성, 학습 용이성, 운영성
  • 효율성: 시간 행동성, 자원 행동성
  • 유지보수성: 분석 가능성, 변경 용이성, 안정성, 테스트 가능성
  • 이식성: 적응성, 설치 가능성, 준수성, 교체 가능성

ISO 25010: 여덟 가지 품질 특성

• ISO/IEC 25010(2011), 시스템 및 소프트웨어 품질 요구사항 및 평가 (SQuaRE) — 시스템 및 소프트웨어 품질 모델
  • 현재는 ISO 9126 표준을 대체
  • 제품 품질 모델과 사용 품질 모델로 구분됨
  • 외부 품질과 내부 품질은 ISO/IEC 25010 프레임워크에서 특정한 의미를 가짐:
    • 외부 품질: 블랙박스 측정을 통해 제품 품질 모델의 특성을 평가함
    • 내부 품질: 화이트박스 측정을 통해 제품 품질 모델의 특성을 평가함, 즉 소프트웨어 내부 구조에 대한 지식을 바탕으로 시스템 특성을 측정함

ISO/IEC 25010 품질 특성과 사용 품질 모델

• ISO/IEC 25010(2011), 품질 특성 (제품 품질 모델):
  • ISO/IEC 9126 구조와의 관계: 기존의 여섯 가지 품질 특성을 기반으로 새롭게 추가된 특성들이 존재함
• 사용 품질 모델:
  • 실제 시스템 환경에서만 달성될 수 있음 (실제 운영 중에)

요약 및 토론

• 소프트웨어 품질의 정의:
  • 요구에 맞는 소프트웨어
• 대표적인 품질 요소:
  • 정확성, 신뢰성, 성능, 사용자 친화성, 유지보수성, 재사용성, 이해성, 가시성 등
  • AI/ML 시스템의 품질 요소
• 왜 소프트웨어 품질이 중요한가?
• 소프트웨어 품질을 어떻게 측정할 수 있는가? 예를 들어, 유지보수성을 측정하는 방법은?