Software Inspection and Case Studies 김종선
<ul><li>Agenda </li></ul><ul><ul><li>Understading Software Inspection </li></ul></ul><ul><ul><ul><li>Inspection 개요 및 필요성 <...
Did you know?  <ul><li>소프트웨어 개발 종료후에 오류를 수정하는 것은 요구분석단계나   설계 단계에서의 노력과 비용보다 수십 배에서 수백 배까지 소용될 수 있다 . </li></ul><ul><li>->...
07/11/10 <ul><li>조기에 작업 산출물의 결함 (Defect) 을 효율적으로 제거 . </li></ul><ul><li>작업 산출물과 예방 가능한 결함을 보다 잘 이해할 수 있게 하여    같은 실수의 반복을 ...
INSPECTION 은 ? 07/11/10 작업산출물을 검토하는 것이다 . 작업산출물은 규정된 입력기준 (Entiry Criteria) 을 만족해야 한다 .  Author 가 아닌  Moderator 가 검토과정을 주도...
결함 (Defect) 발생 원인 <ul><li>Communication   10 명의 사람이 있으면  45 개의  Path 가 생김 . </li></ul><ul><li>Short term memory 사람이 관리할 수 ...
TEST 와  INSPECTION 의 결함제거비용효과 07/11/10
INSPECTION 을 통한 기대효과 <ul><li>주목적은 가능한 개발초기에 결함을 제거하는 것으로 코드와 산출물 모두가 대상이다 . </li></ul>07/11/10 <ul><li>필드 서비스 비용 절감 </li><...
07/11/10 INSPECTION 프로세스를 살펴보자
INSPECTION RPOCESS 07/11/10 인스펙션준비 개인준비 인스펙션 회의 수정 후속조치 management RE-INSPECTION
INSPECTION RPOCESS 07/11/10 인스펙션준비 개인준비 인스펙션 회의 수정 후속조치 참가자들의 역할과 책임 주재자 Moderator Inspection 을 전체적으로 기획 ,  중재 ,  관리하는 역할 ...
INSPECTION RPOCESS <ul><li>주재자는 인스펙션이 실시되기 전에 작업 결과물이 검사할 만한 것인지를 확인한다 . </li></ul><ul><li>완성도 </li></ul><ul><ul><li>작업물의 ...
INSPECTION RPOCESS <ul><li>시작기준 </li></ul><ul><ul><li>인스펙션 팀의 멤버로 회의참석을 통보받았을 시기부터 </li></ul></ul><ul><li>자료배포 </li></ul><...
INSPECTION RPOCESS <ul><li>발견한 잘못된 점을 팀 구성원이 모여 논의하는 것이다 . </li></ul><ul><li>인스펙션 주재자 </li></ul><ul><ul><li>회의를 원활하게 진행 </...
INSPECTION RPOCESS <ul><li>개발자는 발견된 오류를 면밀히 살펴보고 오류수정 </li></ul>07/11/10 인스펙션준비 개인준비 인스펙션 회의 수정 후속조치
INSPECTION RPOCESS <ul><li>인스펙션에서 발견된 오류가 수정되었는지를 확인한다 . </li></ul><ul><li>오류 수정의 확인 전까지 인스펙션은 미종료된 상태이다 . </li></ul><ul><...
INSPECTION 준수원칙 <ul><li>검토가 일관성있게 진행될수 있도록 질문과 체크리스트를 제공한다 . </li></ul><ul><li>회의는  2 시간은 절대 넘지 마라 .   피곤하고 막 그러거든요 ~ </li...
07/11/10 CASE STUDY
INSPECTION  체크리스트 <ul><li>기능명세 체크리스트 예제 </li></ul><ul><ul><li>프로젝트와 제품의 목적은 명확한가 ?( ) </li></ul></ul><ul><ul><li>요구사항과 기능명...
07/11/10
07/11/10
INSPECTION 필수 수집 데이터 및 측정항목 07/11/10
다같이 함께 예제를 ~ 07/11/10
INSPECTION 이 효율적이면서 비용이 적게 소요됨에도  찬사 를 받지 못하는 이유는 ? 1. Inspection 으로 돈을 버는 메이저 벤더가 거의 없다 2. Inspection 에는 새로운 것도 없고 따라서 시장...
Conclusion <ul><li>Inspection  자체적인 방법의 어려움보다 프로세스의 내재화가 힘들 것으로 판단된다 . </li></ul><ul><li>Inspection  프로세스의 중요성과 효과성에 대한 모두...
http://creativecommons.org/licenses/by-sa/2.0/kr/
Upcoming SlideShare
Loading in …5
×

Software Inspection

2,170 views

Published on

소프트웨어 인스펙션

Published in: Technology, Business
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,170
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
76
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide
  • Presentation Title Walk-in HP logo
  • Software Inspection

    1. 1. Software Inspection and Case Studies 김종선
    2. 2. <ul><li>Agenda </li></ul><ul><ul><li>Understading Software Inspection </li></ul></ul><ul><ul><ul><li>Inspection 개요 및 필요성 </li></ul></ul></ul><ul><ul><ul><li>Inspection Process </li></ul></ul></ul><ul><ul><ul><li>Case Studies </li></ul></ul></ul>
    3. 3. Did you know? <ul><li>소프트웨어 개발 종료후에 오류를 수정하는 것은 요구분석단계나 설계 단계에서의 노력과 비용보다 수십 배에서 수백 배까지 소용될 수 있다 . </li></ul><ul><li>-> 그럼 빨리 제거하면 되나 ? </li></ul><ul><li>파레토 분포 (Pareto Distribution) 에 따라 전체 오류의 80% 는 소프트웨어의 20% 에서 야기된 것이다 . </li></ul><ul><li>-> 문제가 될 만한 부분을 집중 관리하면 효과적일까 ? </li></ul>Inspection!!
    4. 4. 07/11/10 <ul><li>조기에 작업 산출물의 결함 (Defect) 을 효율적으로 제거 . </li></ul><ul><li>작업 산출물과 예방 가능한 결함을 보다 잘 이해할 수 있게 하여 같은 실수의 반복을 예방 . </li></ul>INSPECTION 의 목적 ?
    5. 5. INSPECTION 은 ? 07/11/10 작업산출물을 검토하는 것이다 . 작업산출물은 규정된 입력기준 (Entiry Criteria) 을 만족해야 한다 . Author 가 아닌 Moderator 가 검토과정을 주도한다 . 작업 산출물의 결함 (Defect) 를 찾고 기록한다 . 각 산출물에 대한 체크리스트를 사용한다 . 시나리오 등의 효과적인 판독 기법을 사용한다 . 필요하다면 재 작업을 시작하고 모니터한다 . 규정된 기준에 근거하여 Re-Inspection 을 시작한다 . 도출된 결함 데이터를 기존의 결함 데이터에 추가한다 .
    6. 6. 결함 (Defect) 발생 원인 <ul><li>Communication 10 명의 사람이 있으면 45 개의 Path 가 생김 . </li></ul><ul><li>Short term memory 사람이 관리할 수 있는 범위 (7 digit). 여러가지 Interruption 이 발생하는 것 . </li></ul><ul><li>Cognitive Dissonance 자신의 산출물에서 결함 (Defect) 을 찾기가 힘듬 . </li></ul><ul><li>Complexity of work 설계문서의 복잡성으로 Code 작성이 어려운 경우 . </li></ul>07/11/10 아무리 능숙한 프로그래머라도 평균적으로 35Defs /KLOC 가 발생함 .
    7. 7. TEST 와 INSPECTION 의 결함제거비용효과 07/11/10
    8. 8. INSPECTION 을 통한 기대효과 <ul><li>주목적은 가능한 개발초기에 결함을 제거하는 것으로 코드와 산출물 모두가 대상이다 . </li></ul>07/11/10 <ul><li>필드 서비스 비용 절감 </li></ul><ul><li>연속적인 작업이 아니라 재작업시간 감소 </li></ul><ul><ul><li>문제결정시간 </li></ul></ul><ul><ul><li>재통합 비용 </li></ul></ul><ul><ul><li>재테스트 비용 </li></ul></ul><ul><li>전체 테스트 시간을 감소 </li></ul><ul><li>개발자에게 기술적인 가능성 , 투명성 , 타당성이 검증 </li></ul><ul><li>테스트엔지니어에게 테스트 가능성 </li></ul><ul><li>사용자가 시스템 용이성을 확인 </li></ul><ul><li>전문가들의 풍부한 경험으로 품질 , 구조 , 개발자들간의 코드작성규칙을 점검 </li></ul><ul><li>요구사항과 설계와 적합한지 여부를 확인 </li></ul>
    9. 9. 07/11/10 INSPECTION 프로세스를 살펴보자
    10. 10. INSPECTION RPOCESS 07/11/10 인스펙션준비 개인준비 인스펙션 회의 수정 후속조치 management RE-INSPECTION
    11. 11. INSPECTION RPOCESS 07/11/10 인스펙션준비 개인준비 인스펙션 회의 수정 후속조치 참가자들의 역할과 책임 주재자 Moderator Inspection 을 전체적으로 기획 , 중재 , 관리하는 역할 . 직접 개입은 가능한 적게한다 . 개발자 Author Inspection 할 프로그램 또는 문서를 만든 사람으로 회의시 상세 내역을 적극적으로 경청해야 할 사람 . 제출자 Reader 개발자를 위해서 추가적으로 필요한 정확한 자료를 만들어줄 참가자 . 기록자 Recoder 후속 작업을 하기 위하여 기록을 하는 사람 . 검토자 Inspector 전달받은 자료를 충분하게 검토할 수 있는 모든 참가자 . 결함을 찾을 뿐 해결방안을 제시할 필요는 없다 . 또한 최대한 객관적인 입장에서 의견을 제시할 수 있어야 한다 .
    12. 12. INSPECTION RPOCESS <ul><li>주재자는 인스펙션이 실시되기 전에 작업 결과물이 검사할 만한 것인지를 확인한다 . </li></ul><ul><li>완성도 </li></ul><ul><ul><li>작업물의 90% 이상이 검사가능해야 한다 . </li></ul></ul><ul><li>가독성 </li></ul><ul><ul><li>도식화된 것이 좋다 . </li></ul></ul><ul><li>인스펙션 회의를 할만한 복잡도가 있어야 한다 . </li></ul><ul><li>대상 산출물이 선정기준은 강화되어야 한다 . </li></ul><ul><ul><li>신규기술 , 기법 , 그리고 툴을 적용하는 영역 </li></ul></ul><ul><ul><li>다수의 예외사항 처리 </li></ul></ul><ul><ul><li>재사용목적을 가진 영역 </li></ul></ul><ul><ul><li>복잡한 사용자 인터페이스를 가진 영역 </li></ul></ul><ul><ul><li>많은 결함 및 변경 이력을 가지고 있는 모듈 </li></ul></ul><ul><li>사이즈 </li></ul><ul><ul><li>한 두시간 안에 검토되도록 하라 . </li></ul></ul><ul><ul><li>기능적 명세는 3~5 페이지 . </li></ul></ul><ul><ul><li>200 라인 이내의 코드만을 검토하라 . </li></ul></ul>07/11/10 인스펙션준비 개인준비 인스펙션 회의 수정 후속조치
    13. 13. INSPECTION RPOCESS <ul><li>시작기준 </li></ul><ul><ul><li>인스펙션 팀의 멤버로 회의참석을 통보받았을 시기부터 </li></ul></ul><ul><li>자료배포 </li></ul><ul><ul><li>모든 자료는 적어도 인스펙션 회의 2 일전에 전달한다 . </li></ul></ul><ul><li>검토자 </li></ul><ul><ul><li>설계나 코드에서 이해하기 어려운 부분은 표시하고 메모해둔다 . </li></ul></ul><ul><ul><li>가능한 모든 에러를 발견 </li></ul></ul><ul><ul><li>오류는 주재자가 일정한 기록양식에 기록한다 . </li></ul></ul><ul><li>다음에 대한 리스트를 작성한다 . </li></ul><ul><ul><li>잠재적버그 </li></ul></ul><ul><ul><li>제품에 관한 질문들과 논점 </li></ul></ul><ul><ul><li>소프트웨어 품질 향상을 위한 제언 </li></ul></ul>07/11/10 인스펙션준비 개인준비 인스펙션 회의 수정 후속조치
    14. 14. INSPECTION RPOCESS <ul><li>발견한 잘못된 점을 팀 구성원이 모여 논의하는 것이다 . </li></ul><ul><li>인스펙션 주재자 </li></ul><ul><ul><li>회의를 원활하게 진행 </li></ul></ul><ul><ul><li>팀 구성원이 전문성을 가지고 검토하도록 할 책임을 가진다 . </li></ul></ul><ul><ul><li>회의 참가자에게 동등한 기회제공 </li></ul></ul><ul><ul><li>인스펙션의 취지는 개발자를 비난하기 위한 것이 아니라 개발자를 도와주기 위한 것 !! </li></ul></ul><ul><ul><li>결함을 발견되면 기록하도록 지시 </li></ul></ul><ul><ul><li>인스펙션의 재시행여부를 결정 </li></ul></ul><ul><li>참가자 </li></ul><ul><ul><li>발견한 오류를 숨김없이 토론할 의무 </li></ul></ul>07/11/10 인스펙션준비 개인준비 인스펙션 회의 수정 후속조치
    15. 15. INSPECTION RPOCESS <ul><li>개발자는 발견된 오류를 면밀히 살펴보고 오류수정 </li></ul>07/11/10 인스펙션준비 개인준비 인스펙션 회의 수정 후속조치
    16. 16. INSPECTION RPOCESS <ul><li>인스펙션에서 발견된 오류가 수정되었는지를 확인한다 . </li></ul><ul><li>오류 수정의 확인 전까지 인스펙션은 미종료된 상태이다 . </li></ul><ul><li>수정결과는 직접 만나서 검사한다 . </li></ul><ul><li>수정을 확인한 후 오류기록부에 날짜기입 . </li></ul><ul><li>검사가 모두 끝나면 품질 관리자에게 종합보고를 하고 인스펙션을 종료한다 . </li></ul>07/11/10 인스펙션준비 개인준비 인스펙션 회의 수정 후속조치
    17. 17. INSPECTION 준수원칙 <ul><li>검토가 일관성있게 진행될수 있도록 질문과 체크리스트를 제공한다 . </li></ul><ul><li>회의는 2 시간은 절대 넘지 마라 . 피곤하고 막 그러거든요 ~ </li></ul><ul><ul><li>코드인스펙션은 시간당 100~200 라인 , 명세검토는 시간당 5~8 페이지 </li></ul></ul><ul><li>문제를 잘 해결할 수 있는 전문가와 주재자 , 개발자를 포함하여 4~5 명안으로 해결하라 . </li></ul><ul><li>적어도 48 시간 이전에 자료를 주고 검토한후 참석하게 하라 . </li></ul><ul><li>주재자가 진행방법을 모르거나 회의를 진행할 수 없으면 과감히 바꿔라 . </li></ul><ul><li>주제에 집중하고 개별적인 질문은 하지 말기 . </li></ul><ul><li>결함은 반드시 문서화 ! </li></ul><ul><li>인스펙션 회의는 문제를 해결하는게 아니라 결함을 찾는 것이다 . 그자리에서 오류를 수정하려는 시도는 하지말라 . </li></ul><ul><li>회의동안에는 개인적인 친분을 고려하지 말고 의견을 내라 . </li></ul><ul><li>상대방을 존중하라 . </li></ul><ul><li>프로젝트 팀장이라고 인스펙션 대상에서 제외하지 말라 . </li></ul><ul><li>적절히 쉬면서 할것 . </li></ul><ul><li>미팅에 목적 , 협의 사항 , 시간제한을 반드시 두고 하라 . </li></ul><ul><li>미팅이 종료되면 문서를 정리하여 관계자들에게 전달한다 . </li></ul>07/11/10
    18. 18. 07/11/10 CASE STUDY
    19. 19. INSPECTION 체크리스트 <ul><li>기능명세 체크리스트 예제 </li></ul><ul><ul><li>프로젝트와 제품의 목적은 명확한가 ?( ) </li></ul></ul><ul><ul><li>요구사항과 기능명세가 정확하게 매칭되고 추적가능한가 ?( ) </li></ul></ul><ul><ul><li>전문용어가 적절하게 사용되었는가 ? ( ) </li></ul></ul><ul><ul><li>요구사항이 장황하거나 불필요한것은 없는가 ? ( ) </li></ul></ul><ul><ul><li>기능적 요구사항을 만족시킬만한 기준이 있느낙 ? ( ) </li></ul></ul><ul><ul><li>요구사항은 테스트케이스로 쉽게 전환가능한가 ? ( ) </li></ul></ul><ul><ul><li>명세는 누가 검토하나 ? ( ) </li></ul></ul><ul><ul><li>예전 릴리즈에 포함된 기능과 수정된 결함을 통합하는데 문제는 없는가 ? ( ) </li></ul></ul>07/11/10
    20. 20. 07/11/10
    21. 21. 07/11/10
    22. 22. INSPECTION 필수 수집 데이터 및 측정항목 07/11/10
    23. 23. 다같이 함께 예제를 ~ 07/11/10
    24. 24. INSPECTION 이 효율적이면서 비용이 적게 소요됨에도 찬사 를 받지 못하는 이유는 ? 1. Inspection 으로 돈을 버는 메이저 벤더가 거의 없다 2. Inspection 에는 새로운 것도 없고 따라서 시장성도 없다 3. Inspection 은 소프트웨어 생명주기의 뒤쪽 단계에 있는 보이지 않는 부분으로 간주한다 . 4. Inspection 은 효율적이긴 하지만 , 녹초가 될 정도로 정신을 집중해야 하는 고된 작업이다 . - 로버트 L 글래스 , “ 우리가 미처 알지 못한 소프트웨어 공학의 사실과 오해 ” 중에서 -
    25. 25. Conclusion <ul><li>Inspection 자체적인 방법의 어려움보다 프로세스의 내재화가 힘들 것으로 판단된다 . </li></ul><ul><li>Inspection 프로세스의 중요성과 효과성에 대한 모두의 공감은 필수 ! </li></ul><ul><li>Inspection 을 통해서 얻은 데이터를 반드시 잘 활용할 수 있어야 진정한 Inspection 이다 . 이 데이터는 향후 (1) 개발자별로 결함이 자주 발생하는 곳을 예상하는 예상치 로서 사용될 수도 있고 (2) 결함을 제거하는 모델 로도 사용될 수 있다 . </li></ul>07/11/10
    26. 26. http://creativecommons.org/licenses/by-sa/2.0/kr/

    ×