3) 소프트웨어의 품질이란 무엇인가?

 이 글은 KMOOC에서 말하는 ‘소프트웨어 공학’을 듣고 강의를 요약해서 정리한 겁니다.

강의에서 배운 내용 중에 중요하다고 생각하는 부분과 꼭 알아야 할 개념을 중심으로 정리했습니다.

ㅇTL;DR = 소프트웨어 품질 :: 사용자 요구 사항 스펙 디자인 얼마나 잘 포함되는지, 실장이 얼마나 적합한지.그 밖에도 트랜센던탈 뷰 등이 있음 = 품질비용(CoQ) : : 페일리아를 requirement 단계에서 발견하면 1달러이지만, 출시 상태에서 발견하면 1000달러가 든다.

200 ~ 1000x . 디펙트를 발견하고 수정하는 비용=품질은 비기능 요구사항에서 나온다.

논펑셔널 리콰이어먼트 퀄리티·아트리뷰트·리콰이어먼트라고 한다.

=퀄리티 노력 일정을 단속할 수 없다.

품질 우선 순위를 정해서 최고 가치로 추진=세이프티::정상/이상 상황인 인간이 예측한 대로 소프트웨어는 작동해야 한다는 성질=리스크 관리;서프라이즈 요인을 줄이는 것. 위험부담이 커지기 전에 주의하라. 리스크=>플래블럼(현실화)=리스크 리덕션 레버리지(RRL) 값을 계산해 어느 것이 중요한지를 결정하는 방법.=위험은 원 타임 액티비티가 아니라 반복적으로 이뤄져야 한다

7-1 소프트웨어 퀄리티, 소프트웨어 품질

소프트웨어의 품질을 바라본 두 가지 관점이 있다.

1. 디자인 퀄리티 :: 사용자의 요구사항, 스펙, 시스템 디자인을 얼마나 잘 포함하고 있는지 2. 적합도 퀄리티 :: 구현이 얼마나 스펙, 시스템 디자인에 적합한지

이 밖에도 퀄리티를 보는 다양한 관점이 있다.

그중에서도 트렌센덴터 르뷰:정말 좋은데 뭐라고 표현할 수 없구나, 이런 요소들

구분하는 유니버설한 정의는 없다.

교수 왈 {{Error가 다른 페이스, 즉 동일한 페이스로 Verification 활동을 통해 필터링 되지 않고 다른 페이스로 발견됨을 Defect라고 합니다.

그래서 Requirement에서 삽입된 Eror가 Design 페이스에서 발견되었을 때 Defect라고 합니다.

그리고 코딩페이스에서 발견이 되었을 때도 역시 Defect라고 이야기를 합니다.

Error는 보통 하나의 페이스로 발생하는데 같은 페이스로 Filter 된 문제점들을 Error라고 하고, 다른 페이스로 Escape 되었을 때 발견된 것을 Defect라고 합니다.

Bug 는 일반적으로 Defect와 같은 의미로 많이 쓰입니다.

그런데 Fault는 Error와 Defect를 모두 합쳐서 Fault라고 하고, Failure는 시스템을 하드웨어에 업로드하여 운영하는 동안 시스템이 운영되는 동안 다른 단계로 이전할 수 없는 상태, 이러한 문제를 일으키는 것을 Software Failure라고 합니다.

}}

ㅇ품질비용(Cost of Quality; CoQ) :: 페일리아를 리콰이어먼트 단계에서 발견하면 수정하는데 1달러 밖에 들지 않지만, 소프트웨어가 출시된 상태에서 발견하면 1000달러가 소요된다.

일반적으로 200배에서 1,000배 정도 더 든다.

Defect를 발견하고 수정하려면 비용이 많이 든다.

이러한 Quality에 대한 비용을 Cost of Quality 또는 품질비용이라고 한다.

결함 수리는 반복적인 품질향 위를 통해서 가능하다 .ㅇ식스시그마에서 보는 품질비용 ::식스시그마는 CoQ를 분류하였다 식스시그마 전략이라고도 한다.

교육을 통해, 혹은 피어 리뷰 등을 통해 미리 고치면 품질 비용이 줄어든다.

한편, 발매 후, 문제를 고치는 비용은 많이 든다.

CMM 레벨이 높은 곳에서도 품질 비용이 저렴함 적은 비용으로 품질 좋은 소프트웨어를 만들 수 있다는 뜻이다.

프로세스가 최적화됐기 때문이다.

7-2 품질이란 비기능 요구사항에서 나온다.

이를 논 펑셔널 리콰이어먼트라는 단어로 표현했다.

지금은 퀄리티 어트리뷰트 리콰이어먼트라는 말을 쓴다.

품질요소에는 이런 것이 있다 라고 한다.

아이폰이 나온 이후 추가된 칼리티아 트리뷰트, 와우빌리티 와우!
!

<>

평가 요소로 메트릭스라는 말을 많이 쓰는데, 보이지 않는 것을 보여주는 것을 메조먼트&매트릭스라고 한다.

자연계 밸류 측정을 줄자와 여러 줄자를 합쳐 새로운 형태의 인사이트를 제공하기 위해 만드는 것이 매트릭스 Metrics다.

예) 속도(시간과 거리라는 두 가지 속성을 사용해 측정한 또 다른 값 metrics). 예) 소프트웨어의 Number of Faults 직접 얻어지는 것. 이것은 Measure다.

Fault Density, 단위 유닛 사이에 유닛에 들어있는 Fault의 수. 이러한 경우를 Metrics라고 한다.

소프트웨어 평가에 이용하는 매트릭스의 종류, 그런데 트리레마가 있다.

‘9126’이 가장 많이 쓰인다고 한다.

퀄리티 노력 스케줄(시간) 세 마리 토끼를 다 잡을 수 없다노력도 하고 있으므로 품질의 우선순위를 정해 그것을 최고의 가치로서 추진한다.

7-3소프트웨어 안전·소프트웨어 결함으로 급발진, 도요타(ECU=시피유)ㅇ세이프티::정상적인 것인 비정상적인 상황인 인간이 예측할 수 있는 방향대로 소프트웨어가 작동해야 한다는 성질

“ㅇ기능안전” :: 위험을 방지하고 미리 디텍션 할 수 있는 프로시저나 방법을 갖춘 것을 펑셔널 세이프티라고 한다.

예) 펑셔널 세잎티 인증표준인 IEC 61508라는 것이 있다고 한다.

항공분야에는 감항인증표준이라고 해서 DO178B 또는 DO178C

ㅇ 허저드 아날리시스 :: 이 시스템이 만들어지고 사용 중 어떤 Hazard가 발생할 수 있는지. 그 다음에 그 Hazard의 크기가 어느 정도인지 그 Hazard가 발생한다면 어느 정도의 확률로 발생하는지에 대한 Hazard나 Risk Analysis를 하는 것.

ㅇ씰 :: 주어진 조건하에 있는 안전 관련 시스템이 주어진 시간 내에 요구되는 안전 기능을 만족스럽게 수행할 수 있는 확률 높은 수준의 환율 :: 심박기 등 많이 쓰이는 개념으로 디맨드레이트 :: 에어백 등 잘 사용되지 않는 개념

8-1 리스크란 무엇인가.

ㅇ리스크 관리는 서브라이즈 팩터를 줄이는 것이다.

리스크 크기 == 임팩트 크기 & 발생 확립 리스크 노출 == 확률 * 피해 크기 == 리스크가 위기 전에 주의해야 한다.

ㅇ리스크와 플래블럼 예시교수 왈 {현재 Risk는 프로젝트 팀에서 Top Talent를 가지고 있는 People이 회사를 그만둘 위험이 있는 경우. 그 경우는 아직 떨어져 있지 않지만 앞으로 발생할 가능성이 있는거죠. 그런 경우에는 이러한 것들을 Risk를 해야 하는데 현재 이러한 Technical People이 떨어졌을 때, 그 사람을 대체할 Technical Engineer를 찾지 못하면 Problem이 됩니다.

}}

ㅇ리스크 관리 어떻게 할까?1 Probabillity를 정확히 계산하고 사이즈를 측정하라. Buying More Information.2 다른 Alternative를 찾아 Risk가 발생하는 것을 피하여 3 그 책임을 전가하라 Risk Transfer4 더 많은 시간과 Effort를 들여서 Risk를 회피할 수 있는 정책을 만들어라 = 리스크 리덕션 5 해결할 수 있는 방법에 대해 지식을 얻을 수 있다.

8-2 리스크를 어떻게 공격할지 플래닝

임팩트 확률 타임 프레임이 리스크 측정에서 중요하다.

리스크가 10년 후에 발생한다면 중요한 리스크가 아닐까 내일 발생하면 중요한 리스크

8-3 RRL 이 위험 리덕션 레버리지(RRL) :: Delphi Process는 전문가들이 한 곳에 모여 거기에 각각의 Risk Item에 대해 Value를 결정하고 어떤 것이 중요한지를 결정하는 방법(RRL 값이 클수록 좋은 해결책이다.

)

위험은 한꺼번에 끝나는 것이 아니라 주기마다 수행하는 것이다.

한 타이밍에 도는 거사이클 동안 반복해서 몇 번씩 익숙해지도록 해야 한다는 것이다.

위험 관리는 One Time Deal Activity가 아니라 Software Project 라이프사이클 동안 지속적이고 반복적으로 이루어져야 한다.

“8-4 피마 FMEA Risk”는 아무리 Reduce하고 Elimination 하려고 노력해도 잠재적으로 남아있는 “Risk”일반적으로 Risk Management Is Not Silver Bullet, 즉 Risk Management만으로는 모든 문제를 해결할 수 없다.

○ 골드플레이팅 :: 기술을 과시하는 것, 프로젝트에 필요 없는 펑크셔너리티를 기술을 과시하기 위해 들이는 행위 (리스크가 될 수 있다.

)