소프트웨어 감사(inspections)

소프트웨어 감사(inspections)

- 모순(anmalies)과 결함을 발견할 목적으로 소스 표현을 검사

- 시스템 실행 필요 X, 구현 전에 사용 가능

- 시스템의 어떠한 표현(requirments, design, test data 등)에도 적용 가능

- 오류 발견에 매우 효과적

 

inspection and testing

- 서로 대립하는게 아닌 보완적인 관계

- 양쪽 다 V&V프로세스 중에 사용됨

- 감사는 명세서와 일치하는지 알아볼 수 있으나, 고객의 실제 요구사항에 일치하는지, 성능과 사용성과 같은 비기능적 요구사항을 검사하는 등은 할 수 없음

 

Program inspection

- 문서 검토를 위한 정형화된 접근법

- 결함 수정이 아닌 검출에 중점을 둠

- 결함들은 논리적 오류, 잘못된 상황, 표준에 맞지 않는 것을 나타내는 코드 내의 모순 일 수 있음

 

inspection 선제조건

- 정확한 명세서

- 팀원이 조직의 표준에 익숙해야함

- 문법적으로 옳은 코드

- 오류 검사 항목 준비

- 관리자들은 감사가 비용 증가를 초래한다는 것을 수용

- 감사 결과를 직원 평가에 사용하지 않아야함

 

inspection 과정

시스템 개요 감사팀에 제출 -> 코드 문서 배포 -> 진행/오류 기록-> 수정안 제작 -> 재감사 필요 여부 판단

 

inspection 팀구성

- 최소 4명

- 감사받는 코드의 작성자(Author)

- 오류, 생략, 불일치 등을 찾아내는 감사자(Inspector)

- 코드를 팀에게 읽어주는 낭독자(Reader)

- 회의 진행 및 오류를 기록하는 조정자(Moderator)

 

Automated static analysis

- 정적 분석기는 소스 문서 처리를 위한 소프트웨어

- 프로그램 문서 파싱, 오류가 발생할 가능성이 있는 부분들을 찾아 V&V팀의 주의를 위해 전달

- 감사 보조 도구로 매우 효과적. 단, 그것을 대치할 수는 없음.

 

분석 단계

- Control flow 분석 : 여러 개의 exit 또는 entry지점을 갖는 loop들에 대한 조사, 도달하지 않는 코드를 찾음 등

- Data use 분석 : 초기화되지 않은 변수, 새 값을 할당 받지 않고 두 번 쓰이는 변수, 선언됐지만 사용 안하는 변수 등

- Interface 분석 : 프로시저 선언 및 사용 일관성 검사

- Information flow 분석 : 출력 변수의 종속성 식별. 모순 자체를 찾아내는 것이 아닌 감사or검토를 위해 정보를 알려줌

- Path 분석 : 프로그램에서의 경로를 식별하고 그 경로들에 있는 문장들을 찾아냄. 검토 프로세스에서 유용하게 사용됨

- 위의 두 단계는 막대한 양의 정보를 사용하므로 신중하게 사용하여야 함

 

weak typing - C같이 옛 언어들이 컴파일러로 오류를 검출하지 못하는 것을 의미

 

Cleanroom

- 상태 천이 모델을 사용한 Formal specification

- 점진적 개발(Incremental development)

- 제한된 언어 및 추상화 구조 사용

- Static verification

- 시스템에 대한 Statistical testing

- 다른 접근법보다 경비가 많이 소요되지 않음

- 전통적인 개발 프로세스보다 적은 오류 발생

 

 

Formal specification - 정형화된, 수학적인