12장 내용정리를 해볼까.. - 소프트웨어 공학

• 12장 내용은 품질에 대한 것이다. 책에서 도입 부분에서는 품질은 잘 보이지 않는 개념이라고 말하고 있다. 더 나아가서 제품의 기능을 파악하고 구현하는 것은 그 자체로 눈에 보이기 때문에 바로 생각해 낼 수 있는데, 이와 반면에 "품질"이란 것은 눈에 바로 보이지 않아서, 품질 목표를 설정하고 관리하는 일이 어렵다고 한다..
• 책에서는 이런 품질 목표를 설정하고, 관리하는 일을 프로젝트 요구 단계부터 정확히 이해하고 정의해야 한다고 설명을 하고 있다. 왜 그런지는 책을 읽어보아야 겠다.
• 소프트웨어의 품질을 결정하는 요소가 여러가지 있다고 한다. -> 사람마다 제품의 품질 결정이 다르기 때문 아닐까? 모니터를 사더라도, 누구는 화면이 그냥 크기만 하면 좋은 품질이라고 생각하는 반면, 화질까지 신경쓰는 사람이 있는 것처럼 말이다.
• 이런 품질을 높이기 위해서 가장 직관적인 방법이 바로 결함을 모니터링 하는 것일 것이다! 그래서 결함을 모니터링 할 줄 알아야지!

나아가며

제한된 보증과 일반 보증서?

• 제한된 보증의 경우에는 프로그램이 결함 없이 완벽하게 작동을 하지 못하는 경우, 즉 제대로 작동 안할 수도 있다는 말이다.
• 일반 보증서 : 우리나라 공산품(전자레인지, 냉장고 뭐 이런거..) -> 비싼 돈 주고 제대로 작동안하면 개빡치기 때문에 수리 또는 교환 받자나! -> 일반 보증서는 제대로 작동하는 것을 보장해주는 것이래..
• 그래서 소프트웨어 같은 경우는 제한된 보증을 갖고 팔고있고, 결함을 최대한 낮추어서 팔아야 잘 팔리겠지 -> 이 말은 즉 품질을 올려야한다는 말이겠지 -> 그래서 품질 관리를 해주어야 한다!

소프트웨어 개발 단계와 소프트웨어 품질 보증을 동시에 진행시켜라!

• 우리는 지금까지 챕터를 나가면서 소프트웨어 개발 단계에 대해 배웠지, 2장부터 11장까지 미쳤다
• 그 단계를 나열해보면 계획 -> 요구분석 -> 설계 -> 구현 -> 테스트 -> 유지보수 , 분명 6가지 단계라 했는데 왜 이렇게 배운게 많은거 같은거야
• 아무튼 책에서는 제일 먼저 이 소프트웨어 개발 프로세스가 -> 품질에 영향을 준다고 설명이 되어 있어. 당연한거지! 프로세스가 애초에 품질을 올리기 위해서 하는 건데? -> 소프트웨어 공학 개념 자체가 소프트웨어의 품질을 올릴려고 한다고 설명이 되어 있었자나! -> 근데 여기서는 더 웃긴 말을 하네, 그래서 이런 "개발 프로세스" 자체에 관심을 가지라는 거야. -> 왜? : 프로세스 자체를 업그레이드 하면 ? 나중에 개발하는 사람도 이 프로세스를 따를거고 그럼 자연스럽게 내가 만든 소프트웨어의 품질과 같아질거라는거지 ㅇㅇ
• 그래서 결론이 뭐냐면 -> 소프트웨어 개발 프로세스에 따라서 품질에 관한 작업도 같이 해주래. -> 뭐 품질 표준을 정하고, 품질을 보증하는 작업이나 뭐, 품질 표준에 잘 맞게 되고 있나 한마디로 -> 소프트웨어 품질 보증(software quality assurance)를 해주래!
• 검증 방법 : 작업 결과가 요구 사항에 적합한지 확인하는 방법! : 개발 주기 전체에 인스펙션과 기술 검토, 테스팅, 측정 등의 기법을 적용해라!

품질이 영향을 미치는 부분

• 제품을 차별화할 수 있다! -> 품질에 따라 고객이 제품을 선택하기 때문,..
• 가격 책정의 원천이 될 수 있다! -> 애플을 생각해 보자..
• 이건 다른 이야기지만 특히 "생명"을 다루거나, "의료"쪽, "항공", "운송" 이런 부분에서 품질이 진~짜 중요하겠지? 이유는 말안해도 알겠지

품질을 소개합니다!

• 소프트웨어의 품질을 높이고자 하는 조직은 프로세스 성숙도가 커질 수록 -> "테스트", "리뷰", "품질보증", "품질관리", "결함방지" 이런 일들을 해서 품질을 "향상" 시킨다고 하네. 그래서 저 5가지가 뭔지 설명을 해줘.

  • 테스트

    • 테스트는 10장 내용이였는데, 또 나오네? -> 이게 품질을 보장하는 가장 일반적인 방법이래.. 왜? -> 결함 관리를 하니깐 -> 결함을 찾으려고 프로그램을 실행시킨다고 했자나? 그래서 품질을 보장하는 거지.
    • 근데 이런 테스트만으로 결함을 "획기적으로" 줄이고 방지하는게 제한적이래 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 뭐야 갑자기 이유를 보자 어휴
      1. 제품주기에서 테스트가 너무 늦게 수행된대
         • 맞는 말이네.. 소프트웨어 개발 주기에서 거의 맨 마지막에 존재해서 결함을 다 찾는게 무리네. 심지어 찾아도 수정하는데 비용이 어마어마 할거 아니야?
      2. 테스트는 좁은 차원만 다룬다.
         • 테스트로 신뢰성 ( 시스템이 정의된 조건 아래 계속 작동할 수 있는 능력! )을 향상시킬수는 있는데, 유지보수성(변경에 대해 얼마나 잘 수용하는지.. ) 와 확장성 ( 새로운 기능 확장이 가능? ) 등은 안된데 그냥 안돼. 그래서 신뢰성을 제외한 다른 속성을 처음부터 고려해서 설계해야 한답니다.
      3. 테스트는 코드 품질만 향상시킨답니다!
         • 원시코드만 테스트 하는거 맞네 지금와서 보니깐.. 문서에 대한 테스트가 없어! -> 그래서 기업에서는 리뷰 (비공식적)나 인스펙션(공식적)을 통해서 문서 검토를 한다고 그러네.

  • 리뷰 (그래서 리뷰를 하게 된거야 테스트로는 품질을 올리는게 한계가 있다고 판단을 한거거든)

    • 제품이 변경되거나 예상치 못한 조건에서 작동하는 데 필요한 품질을 갖추고 있는지 확인하는 그런거!
      • 요구 사항 측면에서 "테스트"는 -> 기능 요구 사항을 검증하는 데 좋고
      • 요구 사항 측면에서 "리뷰"는 -> 유지보수성, 신뢰성, 재사용성 등과 같은 비기능적 품질 요구사항을 검증하는 데 더 적합하대.

  • 품질 보증 (테스트랑 리뷰 두개로 만족을 못해 -> 그러면 품질 보증을 해준대)

    • 테스트의 동의어 또는 독립적인 테스트 구룹에 대한 명칭이래.
      • 올바른 의미 : 소프트웨어 제품이 계획된 품질 수준을 가지고 있음을 "경영진" 및 "기타 프로젝트 이해 관계자"에게 보장하는 활동이래.
      • 품질 보증 활동!
        1. 개발자와 협력을 해서 -> 소프트웨어 개발의 적절한 표준과 절차를 정의를 하래.
        2. 검토(리뷰) 및 감사(검증)을 통해서 업무를 모니터링하여 표준 및 절차를 준수하고 있는지 확인하래.
        3. 품질 목표를 향한 진행 상황에 대해 상급 관리자 및 기타 이해 관계자에게 피드백을 제공하래.

  • 품질 관리! ( 갑자기 왜 나온거야 이놈은 ) , 품질 계획, 제어, 보증, 검증 및 여러 가지 품질 관련 프로세스를 포함하는 용어라는데?

    • 품질 관리는 프로젝트 품질 목표 달성을 위해서. 엔지니어링 및 관리 기술을 적용하는 것이래..
      • 리뷰와 측정, 프로세스 개선 부분을 자세히 살펴볼거래, 테스트 부분은 (코드 실행) 10장 테스트에서 다뤘으니깐..

    품질 개념?

    • 품질은 너무 애매해 그래서 책에서는 다양한 관점에 대해서 품질을 정의를 하고 있네.
    1. 고객 만족 관점
    • 사용자 만족도는 제품의 전반적 요소를 기반으로 하고, 품질은 그 중 하나래. 그렇다면 사용자 만족도가 높다고 해서 좋은 품질이냐? -> 아니다!
    2. 요구 적합성 관점 (ISO 9000 품질 표준)에 사용된 정의!
    • 요구사항에 대해 "적합성"을 품질로 정의하는거래!
    • 지정된 요구사항이랑, 디자인을 준수하는 제품이 높은 품질의 제품이래.
    • 만약에 품질을 고객 만족 관점에서 생각을 해봐 -> 개발 주기 전체 프로세스를 진행하면서 이걸 어떻게 평가하고 만족시킬거야? 이와 반면에 요구 적합성 관점은 그냥 요구사항에만 맞으면 되거든. 그래서 쉬워.
    3. 제품 품질
    • 제품 자체로 품질을 평가하는거지.
    • 제품의 품질은 여러 속성의 집합이고, -> 이런 속성들이 품질을 결정하는 거야 ex) 카메라의 해상도 속성, 광 감도 속성, 프레임 속도 속성 이런거..소프트웨어 품질

  • 제품 속성 측면에서 -> 소프트웨어 품질을 정의해보자!

  • 소프트웨어 품질은 -> 프로젝트의 시간, 비용, 기능과 함께 고려되는 것이래 그니까 품질도 그냥 프로젝트의 한 "요소"일 뿐이니깐. 너무 품질을 추구해버리면, 시간과 비용이 많이 들 수 있겠지? 이런걸 주의하라는 거같애.

  • 뭐 비용하고 시간은 서로 간의 해당 단어가 의미하는 바를 바로 알 수 있지만, 품질은 아니자나 위에서 관점에 따라 다르니까 !

  • 그래서 프로젝트 시작할 때 품질의 정의를 정해놓고 가는거야! IEEE는 품질에 대한 정의를 "시스템, 구성요소, 프로세스가 지정된 요구사항을 충족시키는 정도, 또는 시스템, 구성요소, 프로세스가 고객 또는 사용자 요구나 기대를 충족시키는 정도" 라고 하고 있대.

품질 모델 ( 소프트웨어 작업관점, 소프트웨어 자체의 유형 )

• 소프트웨어 작업 관점에 따라 신경써야 할 품질 속성이 다르다!
• 다음 3가지의 예를 보자!
  • ex1) 프로덕트 개정(업그레이드) -> 유지보수성, 융통성, 테스트 용이성 (품질 요소, <- 사용자 관점)
  • ex2) 프로덕트 전환(이식) -> 이식성, 재사용성, 상호운용성
  • ex3) 프로덕트 운용(사용) -> 정확성, 신뢰성, 효율성, 통합성, 사용성
• 외부 관점 품질 요소 -> 사용자 측면 (사용성, 신뢰성, 효율성, 재사용성, 유지 보수성, 이식성, 테스트 용이성) 이런거..
• 내부 관점 품질 요소 -> 개발자 측면 ( 커뮤니케이션, 정확성, 일관성, 장치 효율성, 접근 가능성, 완전성, 구조적, 간결성, 장치독립성, 자기설명적, 추적성) 이런거.,.
• ISO 소프트웨어가 가질 수 있는 품질 특성

• IEC9126 소프트웨어가 가질 수 있는 품질 특성

• 소프트웨어 유형에 따라 신경써야 할 품질 속성이 다르다!
  • 증권 거래 시스템 VS 임베디드 시스템!
  • 품질 관리!
• 소프트웨어 제품이나 아이템이 "정해진 요구"에 적합하다는 것을 보장하는데 필요한 계획적이고, 체계적인 활동을 말한다!!!!
• 품질 관리 기능은 크게 다음과 같이 나눌 수 있다.
  1. 프로세스와 표준의 정의 : 소프트웨어 개발 조직을 위해 품질 관리 프레임워크를 개발하고 정의.
  2. 품질 보증 : 품질 계회과 품질 제어 활동을 포함한다!
  3. 프로세스 개선 : 개발뿐만 아니라 조직의 품질 보증 프로세스를 개선하는 활동을 수행하는 것!
• 프로세스 관점에서의 품질 관리 : 소프트웨어 개발 프로세스와 방법론을 정의하고, 이들 활동의 실적을 모니터링 한다.
• 프러덕트 관점에서의 품질 관리 : 품질 특성, 메트릭, 지표, 표준을 정의하고 체크리스트를 준비해 소프트웨어 결과물과 시스템의 품질을 검증한다.
• 품질 보증 조직!

• 프로세스와 표준의 정의
  • 프레임워크를 개발하고 정의할 책임이 있다고 하는데..
    1. 소프트웨어 개발, 품질 관리 프로세스 및 방법론의 정의를 해야해
       • 소프트웨어 개발 방법론과 소프트웨어 프로세스를 정의를 해야하는데, 예를 들면 컴포넌트 개발 방법론과 V 개발 프로세스를 선택하는 것을 의미해. 또한 형상관리 기능과 도구(유지보수!)도 파악해서 정의를 해야한대. 그리고 시스템 컴포넌트 변경하려고 할 때 서로 협력하는 메커니즘을 개발 주기 동안 확립해야한대 ( 변경에 대한 요구 자나, 유지보수)
       • 전통적인 프로세스의 품질 보증 활동에 대한 것이래.
    2. 개발 주기 동안 품질 보증 작업을 수행할 표준, 절차, 가이드라인의 정의가 필요해.
       • 프로세스 표준의 경우 : 개발 프로세스와 방법론에 대한 요구를 정의한다. 또한 특정 프로젝트에 대한 프로세스와 방법론뿐만 아니라 개발 주기 동안 프로세스와 방법론의 적용에 관한 표준도 포함한다. 개발 각 단계가 산출하여햐 할 결과물과 그 품질을 보장하는 품질 보증 표준 및 절차도 정한다.
       • 개발 주기 동안 산출해야 할 소프트웨어 결과물에 대한 요구를 정의한다.
    3. 품질 측정과 평가를 위한 품질 메트릭, 지표를 정의해야해.
       • 품질을 평가할 수 있는 측정 방법을 요구한다! 지표가 필요해!
• 품질 보증 활동
  1. 품질 계획
     • 각 프로젝트 초기에 이뤄지고, 품질 프레임워크의 가이드를 따라 프로젝트 고유의 필요성을 고려해 품질 계획을 수립한다.
     • 계획에는 다음과 같은 사항이 들어가야 한다.
       1. 목적
       2. 관리
       3. 표준과 관례
       4. 리뷰와 감사
       5. 형상 관리
       6. 프로세스, 방법론, 도구, 기술
       7. 메트릭, 지표
  2. 품질 제어
     • 계획이 정확하게 실행되고 있는지 확인하는 것!
     • 교육 -> 품질 보증의 중요성과 기관의 품질 보증 표준과 절차, 사용 가능한 품질 보증 도구, 도구 사용법을 개발자에게 가르치려는 것이다.
     • 개발자가 품질 보증 활동을 잘 하도록 도와주는 것 -> 워크스루, 인스펙션, 리뷰 기술을 교육 , 인스펙션과 리뷰를 위한 체크리스트 개발을 돕는다.
• 인스펙션
  • 주로 결과물의 리뷰로 이루어진다.
  • IEEE의 표준에서 제안하는 기본적인 리뷰 작업.
  • Fagan이 제안한 방법으로 품질 개선과 비용 절감을 위한 기법으로 사용하고 있다.
  • 설계와 코드에 대한 인스펙션은 탁월한 효과를 보이고 있다.
  • 프로덕트를 공통되는 오류, 변칙, 표준이나 관례의 부적합을 리스트로 만들어 체크해 보는 작업.
  • 구현 단계의 인스펙션

- 위와 같이 인스펙션은 요구, 명세, 도메인 모델, 유스케이스, 설계 다이어그램, 프로그램 원시코드, 정적 및 동적 페이지, UI 설계, 테스트 계획, 테스트 케이스에도 적용될 수 있다.
- 인스펙션의 단계 
    1. 계획 -> 2. 사전 교육 -> 3. 준비 -> 4. 인스펙션 회의 -> 5. 수정 -> 6. 후속 조치

품질 측정

• 품질을 측정할 때는 정성적(문자) 보단 정량적으로 해야지! -> 수치화를 해서 객관적으로 평가해야 한다는 뜻이다!

• 책에서는 예를 들어서 -> 1) 메모리에 적재에 소모되는 바이트 크기 , 2) 원시코드의 줄 수 3) 원시코드의 문장의 개수를 말하고 있어.

• 복잡도를 측정하는 방법도 알려줬는데, McCabe의 싸이클로매틱 복잡도가 있다고 해 -> 이 싸이클로 매틱 방법이 테스트 화이트 박스 부분에서 봤던건데. -> 논리 그래프에서 복잡도 구하는 거였지. 또 다른 방법으로 알고리즘의 계산 복잡도 라던가, 빅 오 표현 방법이라던가 이런거지 ㅜ머..

• 측정 방법은 표준화된건 아닌데, 많은 문헌들에서 사용되는 측정 방법이 있어서 그걸 표준으로 생각하고 쓰는 거 같애.

• 그래서 메트릭이 크게 "프로세스 메트릭" , "프로젝트 메트릭" , "프로덕트 메트릭"이 있대.

• 품질 측정의 유용성 ?

  • 소프트웨어를 수준별로 평가할 수 있대
  • 예르 들어서 모듈이나 클래스는 천 줄이 넘으면 -> 큰 것이다.
  • 다른 예로 함수가 10개 이상의 분기를 갖으면 -> 너무 복잡한 것으로 간주한대
  • 측정과 메트릭 -> 특정 값을 계산하는 반면 지표 -> 상대적 의미가 있는 값의 범위를 나타낸대.

• 품질 메트릭? 어떻게 구하는데?

  • 이걸로 요구(R), 설계 (D), 코드(C), 시스템(S) 각각 요구 명세, 설계, 코드, 시스템의 품질 측면을 측정한다고 해.

  • 요구 완전성 메트릭

    - 여러 사람이 요구 명세를 검토했을 때 모두 고유한 한 가지 방법으로만 해석하는 요구의 비율로 측정이 된다.

    • 요구 명세서에 기술된 시스템의 상태와 <-> 시스템에 대한 외부자극이 완전하다는 가정에 근거한다.
    • 즉 입력과 출력이 완전히 매핑이 되어야 한다는 것이고 이를 수식으로 나타냈을 때
      • f(state, stimulus) -> (state, response) 되어야 한다는 것을 의미.

  • 요구 정확도 메트릭

    • 요구가 정확한지 알지 못할 것 (가정)
    • 검증할 수 있거나, 아직 검증 할 수 없는 요구 전체에 대한 검증 가능한 정확한 요구의 비율
    • 아직 검증되지 않는 요구를 분모로 사용해서, 이것 대비 정확한 기능의 비율을 계산한다.

  • 요구 일관성 메트릭

    • 서로 상충하는 요구의 숫자를 카운트한다.

• 설계 메트릭

  • 모듈 설계 복잡도
  • 설계 복잡도
  • 통합 복잡도

• 구현 메트릭

  • LOC
  • 싸이클로매틱 복잡도
  • 객체지향에서 복잡도 계산
    -WMC
    -DIT
    -CBO
    -RFC
    -LCOM

    프로세스 개선

• CMMi ? (Capability Maturity Model Integration)

  • 현재의 프로세스 상태를 벤치마킹하고, 어떤 부분을 향상 시킬 것인지 전략을 선택해서 프로세스를 개선하려는 소프트웨어 개발 조직에 도움이 되기 위하여 제정되었대.
  • 이 것을 사용하면 -> 소프트웨어 엔지니어링 및 관리를 조직에 정착시키는데 도움이 된대.
  • 두 가지 방법으로 사용이 되는데
    1. 미래의 고객이 소프트웨어 공급자가 어떤 점이 부족하며, 어떤 점이 강한지 발견하기 위해 평가하는 기준이래.
    2. 소프트웨어 개발자 스스로 프로세스 능력을 평가하고, 개선의 방향을 설정하려는 것이래.

• ISO 9001

  • SPICE (Software Process Improvement and Capability Entertainment)