Software Inspection andCase Studies

김종선

Agenda

- Understading Software Inspection- Inspection 개요 및 필요성- Inspection Process- Case Studies

Did you know?

소프트웨어 개발 종료후에 오류를 수정하는 것은 요구분석단계나 설계 단계에서의 노력과 비용보다 수십 배에서 수백 배까지 소용될 수 있다 . -> 그럼 빨리 제거하면 되나 ?

파레토 분포 (Pareto Distribution) 에 따라 전체 오류의 80% 는 소프트웨어의 20% 에서 야기된 것이다 . -> 문제가 될 만한 부분을 집중 관리하면 효과적일까 ?

Inspection!!

23年 4月 10日 4

조기에 작업 산출물의 결함 (Defect) 을 효율적으로 제거 . 작업 산출물과 예방 가능한 결함을 보다 잘 이해할 수 있게 하여 같은 실수의 반복을 예방 .

INSPECTION 의 목적 ?

23年 4月 10日 5

작업산출물을 검토하는 것이다 .작업산출물을 검토하는 것이다 .

작업산출물은 규정된 입력기준 (Entiry Criteria) 을 만족해야 한다 .

작업산출물은 규정된 입력기준 (Entiry Criteria) 을 만족해야 한다 .

Author 가 아닌 Moderator 가 검토과정을 주도한다 .

작업 산출물의 결함 (Defect) 를 찾고 기록한다 .

각 산출물에 대한 체크리스트를 사용한다 .

시나리오 등의 효과적인 판독 기법을 사용한다 .

필요하다면 재 작업을 시작하고 모니터한다 .

INSPECTION 은 ?

규정된 기준에 근거하여 Re-Inspection 을 시작한다 .

도출된 결함 데이터를 기존의 결함 데이터에 추가한다 .

23年 4月 10日 6

결함 (Defect) 발생 원인

• Communication 10 명의 사람이 있으면 45 개의 Path 가 생김 .

• Short term memory사람이 관리할 수 있는 범위 (7 digit). 여러가지 Interruption 이 발생하는 것 .

• Cognitive Dissonance자신의 산출물에서 결함 (Defect) 을 찾기가 힘듬 .

• Complexity of work설계문서의 복잡성으로 Code 작성이 어려운 경우 .

아무리 능숙한 프로그래머라도 평균적으로 35Defs /KLOC 가 발생함 .

23年 4月 10日 7

TEST 와 INSPECTION 의 결함제거비용효과

23年 4月 10日 8

INSPECTION 을 통한 기대효과

• 주목적은 가능한 개발초기에 결함을 제거하는 것으로 코드와 산출물 모두가 대상이다 .

• 필드 서비스 비용 절감• 연속적인 작업이 아니라 재작업시간

감소문제결정시간재통합 비용재테스트 비용

• 전체 테스트 시간을 감소

• 개발자에게 기술적인 가능성 , 투명성 ,

타당성이 검증• 테스트엔지니어에게 테스트 가능성• 사용자가 시스템 용이성을 확인• 전문가들의 풍부한 경험으로 품질 ,

구조 , 개발자들간의 코드작성규칙을 점검

• 요구사항과 설계와 적합한지 여부를 확인

23年 4月 10日 9

INSPECTION 프로세스를 살펴보자

23年 4月 10日 10

INSPECTION RPOCESS

인스펙션준비

개인준비

인스펙션 회의

수정

후속조치

man

ag

em

en

t

RE-I

NS

PEC

TIO

N

23年 4月 10日 11

INSPECTION RPOCESS

인스펙션준비

개인준비

인스펙션 회의

수정

후속조치

참가자들의 역할과 책임

주재자Moderator

Inspection 을 전체적으로 기획 , 중재 , 관리하는 역할 . 직접 개입은 가능한 적게한다 .

개발자Author

Inspection 할 프로그램 또는 문서를 만든 사람으로 회의시 상세 내역을 적극적으로 경청해야 할 사람 .

제출자Reader

개발자를 위해서 추가적으로 필요한 정확한 자료를 만들어줄 참가자 .

기록자Recoder

후속 작업을 하기 위하여 기록을 하는 사람 .

검토자Inspector

전달받은 자료를 충분하게 검토할 수 있는 모든 참가자 . 결함을 찾을 뿐 해결방안을 제시할 필요는 없다 . 또한 최대한 객관적인 입장에서 의견을 제시할 수 있어야 한다 .

23年 4月 10日 12

INSPECTION RPOCESS

인스펙션준비

개인준비

인스펙션 회의

수정

후속조치

• 주재자는 인스펙션이 실시되기 전에 작업 결과물이 검사할 만한 것인지를 확인한다 .

• 완성도− 작업물의 90% 이상이 검사가능해야 한다 .

• 가독성− 도식화된 것이 좋다 .

• 인스펙션 회의를 할만한 복잡도가 있어야 한다 .• 대상 산출물이 선정기준은 강화되어야 한다 .

− 신규기술 , 기법 , 그리고 툴을 적용하는 영역− 다수의 예외사항 처리− 재사용목적을 가진 영역− 복잡한 사용자 인터페이스를 가진 영역− 많은 결함 및 변경 이력을 가지고 있는 모듈

• 사이즈− 한 두시간 안에 검토되도록 하라 .− 기능적 명세는 3~5 페이지 .− 200 라인 이내의 코드만을 검토하라 .

23年 4月 10日 13

INSPECTION RPOCESS

인스펙션준비

개인준비

인스펙션 회의

수정

후속조치

• 시작기준− 인스펙션 팀의 멤버로 회의참석을 통보받았을

시기부터• 자료배포− 모든 자료는 적어도 인스펙션 회의 2 일전에

전달한다 .

• 검토자− 설계나 코드에서 이해하기 어려운 부분은

표시하고 메모해둔다 .− 가능한 모든 에러를 발견− 오류는 주재자가 일정한 기록양식에 기록한다 .

• 다음에 대한 리스트를 작성한다 .− 잠재적버그− 제품에 관한 질문들과 논점− 소프트웨어 품질 향상을 위한 제언

23年 4月 10日 14

INSPECTION RPOCESS

인스펙션준비

개인준비

인스펙션 회의

수정

후속조치

• 발견한 잘못된 점을 팀 구성원이 모여 논의하는 것이다 .

• 인스펙션 주재자− 회의를 원활하게 진행− 팀 구성원이 전문성을 가지고 검토하도록 할

책임을 가진다 .− 회의 참가자에게 동등한 기회제공− 인스펙션의 취지는 개발자를 비난하기 위한 것이

아니라 개발자를 도와주기 위한 것 !!− 결함을 발견되면 기록하도록 지시− 인스펙션의 재시행여부를 결정

• 참가자− 발견한 오류를 숨김없이 토론할 의무

23年 4月 10日 15

INSPECTION RPOCESS

인스펙션준비

개인준비

인스펙션 회의

수정

후속조치

• 개발자는 발견된 오류를 면밀히 살펴보고 오류수정

23年 4月 10日 16

INSPECTION RPOCESS

인스펙션준비

개인준비

인스펙션 회의

수정

후속조치

• 인스펙션에서 발견된 오류가 수정되었는지를 확인한다 .

• 오류 수정의 확인 전까지 인스펙션은 미종료된 상태이다 .

• 수정결과는 직접 만나서 검사한다 .• 수정을 확인한 후 오류기록부에 날짜기입 .

• 검사가 모두 끝나면 품질 관리자에게 종합보고를 하고 인스펙션을 종료한다 .

23年 4月 10日 17

INSPECTION 준수원칙

• 검토가 일관성있게 진행될수 있도록 질문과 체크리스트를 제공한다 .• 회의는 2 시간은 절대 넘지 마라 . 피곤하고 막 그러거든요 ~− 코드인스펙션은 시간당 100~200 라인 , 명세검토는 시간당 5~8

페이지• 문제를 잘 해결할 수 있는 전문가와 주재자 , 개발자를 포함하여 4~5

명안으로 해결하라 .• 적어도 48 시간 이전에 자료를 주고 검토한후 참석하게 하라 .• 주재자가 진행방법을 모르거나 회의를 진행할 수 없으면 과감히 바꿔라 .• 주제에 집중하고 개별적인 질문은 하지 말기 .• 결함은 반드시 문서화 !• 인스펙션 회의는 문제를 해결하는게 아니라 결함을 찾는 것이다 .

그자리에서 오류를 수정하려는 시도는 하지말라 .• 회의동안에는 개인적인 친분을 고려하지 말고 의견을 내라 .• 상대방을 존중하라 .• 프로젝트 팀장이라고 인스펙션 대상에서 제외하지 말라 .• 적절히 쉬면서 할것 .• 미팅에 목적 , 협의 사항 , 시간제한을 반드시 두고 하라 .• 미팅이 종료되면 문서를 정리하여 관계자들에게 전달한다 .

23年 4月 10日 18

CASE STUDY

23年 4月 10日 19

INSPECTION 체크리스트

• 기능명세 체크리스트 예제−프로젝트와 제품의 목적은 명확한가 ?( )−요구사항과 기능명세가 정확하게 매칭되고 추적가능한

가 ?( )−전문용어가 적절하게 사용되었는가 ? ( )−요구사항이 장황하거나 불필요한것은 없는가 ? ( )−기능적 요구사항을 만족시킬만한 기준이 있느낙 ? ( )−요구사항은 테스트케이스로 쉽게 전환가능한가 ? ( )−명세는 누가 검토하나 ? ( )−예전 릴리즈에 포함된 기능과 수정된 결함을 통합하는데

문제는 없는가 ? ( )

23年 4月 10日 20

23年 4月 10日 21

23年 4月 10日 22

INSPECTION 필수 수집 데이터 및 측정항목

23年 4月 10日 23

다같이 함께 예제를 ~

INSPECTION 이 효율적이면서 비용이 적게 소요됨에도

찬사를 받지 못하는 이유는 ?

1. Inspection 으로 돈을 버는 메이저 벤더가 거의 없다2. Inspection 에는 새로운 것도 없고 따라서 시장성도 없다3. Inspection 은 소프트웨어 생명주기의 뒤쪽 단계에 있는 보이지 않는 부분으로 간주한다 .

4. Inspection 은 효율적이긴 하지만 , 녹초가 될 정도로 정신을 집중해야 하는 고된 작업이다 .

- 로버트 L 글래스 , “우리가 미처 알지 못한 소프트웨어 공학의 사실과 오해” 중에서 -

23年 4月 10日 25

Conclusion

• Inspection 자체적인 방법의 어려움보다 프로세스의 내재화가 힘들 것으로 판단된다 .

• Inspection 프로세스의 중요성과 효과성에 대한 모두의 공감은 필수 !

• Inspection 을 통해서 얻은 데이터를 반드시 잘 활용할 수 있어야 진정한 Inspection 이다 . 이 데이터는 향후 (1) 개발자별로 결함이 자주 발생하는 곳을 예상하는 예상치로서 사용될 수도 있고 (2) 결함을 제거하는 모델로도 사용될 수 있다 .

http://creativecommons.org/licenses/by-sa/2.0/kr/