Software Inspection
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Software Inspection

on

  • 2,152 views

소프트웨어 인스펙션

소프트웨어 인스펙션

Statistics

Views

Total Views
2,152
Views on SlideShare
2,146
Embed Views
6

Actions

Likes
0
Downloads
49
Comments
0

1 Embed 6

http://www.persona.or.kr 6

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Presentation Title Walk-in HP logo

Software Inspection Presentation Transcript

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