'소프트웨어공학의 진실과 오류' 中에서 #4

소프트웨어 생명 주기 (개발)

 폭포수 - 요구사항 분석 -> 설계 -> 코딩 -> 오류 제거 -> 테스트 -> 검토(review)와 검사(inspection) -> 유지보수

 -> Step은 반드시 필요. 하지만 폭포수라고 해서 한 과정에서 그 내용을 한번에 처리 할 수 없음. : 요구사항의 시간에 따른 변경. 구현시 설계상의 오류 발견등
 
 -> Spiral 모형 도입 - 반복을 통해서 개발 되었지만 완성된 후 고객이 봤을 때 다시 요구사항 추가 변경이 생김

 => Prototype 모형으로 진행
 => 이 부분 만으로도 고객을 만족시킬 수는 없음 -> JAD(Joint Application Development) 방법론

 공동으로 요구사항 결정 방법론 = JARR(Joint Application Requirements Resolution)

 => XP 경량 개발방법론에서는 사용자의 대표자가 개발 기간동안 상주 요구사항을 바로바로 Feedback.

설계

 27. 소프트웨어 문제에 대해 최상의 솔류션이 하나인 경우는 거의 없다.
 -> 최고의 설계자들이 모인 방에서 두 명의 설계자가 동의한다면 그게 다수 의견이다.

 28. 설계는 복자하고 반복적인 프로세스다. 초기 설계 솔류션은 잘못됐을 가능성이 크고 최적의 상태도 아님.

 29. 설계자는 숙지한 기본 단위 수준으로 문제를 분해됐을 때 설계에서 코딩으로 전환한다.
 설계자와 코더가 동일한 사람이 아니라면, 설계자와 코더의 기본단위가 같지 않을 수 있고, 이는 문제를 초래할 수 있다.

 52. 효율은 훌륭한 코딩보다는 훌륭한 설계에 더 많은 영향을 받는다.

테스트

 32. 프로그래머가 완전히 테스트했다고 믿는 소프트웨어도 보통은 로직 경우의 55-60%만 테스트된 경우가 많음. 커버리지 분석기와 같은 자동화 도구를 사용하면 이 비율을 대략 85-90% 높일 수 있다.

 33. 100%의 테스트 커버리지가 가능하다 하더라도, 이는 충분한 테스트 기준이 아니다. 대략 소프트웨어 결함은 35%는 누락된 로직 경로에서, 40%는 로직 경로의 특정 조합을 실행할 때 나타남. 100% 커버리지로도 잡히지 않음.

 테스트 -> 로직 조각(모듈,컴포넌트)/ 로직 테스트 경로 필요/ 로직 경로의 조합 필요
 1) 누락에 의한 오류
 2) 조합에 의한 오류

 35. 특정 테스트 프로세스는 자동화할 수 있고, 또 자동화해야 한다. 그러나 자동화할 수 없는 테스트 작업도 많다.

 자동화된 작업의 예
 1) 테스트 동작을 기록/재생하는 도구는 테스트의 입력을 기록해두었다가 필요할 때 다시 실행시킬 수 있어
 2) 테스트 관리자는 반복적으로 일련의 테스트 케이스를 실행하고 그 결과를 테스트 오라클(테스트 오라클은 이미 알고 있는 정확한 답의 집합으로 컴퓨터 과학 용어)과 비교할 때 상당히 편리함.
 3) 회귀 테스트를 생성하고 조작하는 것은 코드에 새로운 변경을 가했을 때 예전에 잘 동작하던 코드에서 오류가 생기는지 확인하는 휼륭한 방법이다.

 자동화 되지 않은 작업
 1) 어떤 것을 어떻게 테스트해야 하는지 선택하는 작업
 2) 각 테스트가 나타내는 동치류수가 최대가 되도록 하는 테스트 케이스 생성 (동치류 : 테스트 입력값의 부분 집합으로 각 클래스 내 임의의 값이 그 클래스를 대표할 수 있어야 한다는 걸 뜻함)
 3) 테스트 오라클을 만들기 위해 예상되는 테스트 결과를 수집하는 작업
 4) 테스트 프로세스를 위한 기반구조 계획 작업
 5) 테스트의 수행 순서
 6) 소프트웨어 제품 고객, 사용자와 함께 테스트를 구축, 실행, 결과를 확인하는 것에 대한 조율 작업
 7) 테스트 기법 선정과 테스트 수행 효과의 최대화에 대한 절충안 결정.

 37. 엄격한 검사(inspection)은 첫 번째 테스트 케이스를 실행시키기도 전에 소프트웨어 제품에 포함된 오류의 90%까지 제거할 수 있다.

 46. 품질은 속성의 집합이다.
 - 이식성, 신뢰성, 효율성, 사용 편의성, 테스트 용이성, 이해 용이성, 수정 용이성

 47. 품질은 사용자 만족, 요구사항 충족, 비용과 일정 목표 달성, 또는 신뢰성 - 이러한 것이 아니다. 사용자 만족의 직관적 기준 = 요구사항 충족 + 납기일 준수 + 적절한 비용 + 좋은 품질의 제품