day 3. 전통적 S/W 개발방법 - 구현, 검사, 유지보수

• 구현
• = 프로그래밍 단계
• 각 모듈을 원시 코드로 작성 및 문서화
• 사용할 프로그래밍 언어 및 코딩 스타일 등 결정해야함
• 프로그래밍 언어
• 1세대 : 기계어, 어셈블리 등 Low-level language
• 2세대 
• 3세대
• 4세대
• 언어 선정 기준
• 친밀감, 프로그램 구조, 언어의 능력, 프로그램의 길이, 처리의 효율성, 이식성, 개발 실적, 업무 성격, 알고리즘 및 계산 난이도, 소프트웨어 수행환경, 개발담당자의 지식, 컴파일러 이용 가능성 등
• 코딩 스타일
• 코드의 일관성을 유지하고 좋은 코딩을 위해
• 구조적 프로그래밍
• 다익스트라에 의해 제안안
• 기본 제어 구조 : 순차, 선택, 반복
• 분기(goto) 없이 코딩 --> 읽기 쉽고 테스트하기 쉬움.
• 무결한 프로그래밍 규칙 제공
• 규칙
• 제어 흐름을 선형화 (linear)
• 단일 입구 -> 단일 출구
• goto stmt 사용 X
• 순차, 선택, 반복 사용.
  
  
  
• 검사
• 개요
• 품질 보증 활동 중 하나
• 요구사항의 만족도 및 예상 결과와 실제 결과의 차이점을 여러 방법 사용하여 검사,평가
• 오류를 발견하기 위함
• 검사의 목적 달성을 위한 규칙 by Glen Myers
• 오류를 찾기 위해 프로그램을 실행
• 오류 발견 확률 높이기 위해 훌륭한 검사 사례 이용
• 성공적인 검사 --> 발견되지 않은 오류 찾기
• 검사 기법
• 최소한의 시간과 노력으로 오류를 찾기위해 검사 사례를 설계하는 방법
• 설계 고려사항
• 모듈내 독립적 경로가 적어도 한 번씩은 수행되어야 함
• 복잡한 논리는 가능한 한 배제
• 임의의 조건을 만족
• 내부 자료구조 이용
• 화이트박스 테스트
• 개요
• 모듈의 원시코드를 오픈한 상태에서 코드의 논리적 경로를 모두 검사하여 검사 사례 설계
• 모듈 안의 작동을 직접 관찰
• 설계된 절차에 초점을 둠. 테스트 과정의 초기에 적용
• 종류
• 기초 경로 검사 (basic path testing) by Tom McCabe
• *제어 흐름도    
• *순환 복잡도
• 모든 경로가 한 번 이상 수행되었음을 보장하기 위해 행해지는 테스트의 횟수의 상한선
• V(G) = E - N + 2 ( E = edges, N = nodes)
• 제어 구조 검사
• 세부 종류
• 조건 검사 (Condition Testing)
• 루프 검사 (Loop Testing)
• 데이터 흐름 검사 (Data Flow Testing)
• 블랙박스 테스트
• 개요
• 각 기능이 작동하는 것을 입증하기 위함. 테스트 과정의 후반부에 적용
• 입력에 대한 출력의 정확성 점검
• 종류
• 동치 분할 검사 (Equivalence Partitioning Testing)
• = 동등 분할 검사
• 입력에 맞는 결과 출력 확인
• 경계값 분석 (Boundary Value Anaylsis)
• 동치분할이 입력에 초점을 맞추는 것을 보완하기 위해 개발됨
• '입력 조건의 중간값보다 경계값에서 오류 발생 확률이 높다'는 점을 이용하여 경계값 검사
• 원인-효과 그래프 검사 (Cause-Effect Graphing Testing)
• 입력과 그로인한 출력 간의 관계를 그래프로 표현하여 검사
• 오류 예측 검사 (Fault Based Testing)
• = 데이터 확인 검사
• 과거의 경험이나 확인자의 감각으로 검사
• 다른 블랙박스 테스트로 찾을 수 없는 오류를 찾아내는, 보충적 테스트
• 비교 검사 (Comparison Testing)
• 여러 버전의 프로그램에 동일한 검사자료를 이용하여 동일한 출력이 나오는지 검사
  
  
  
• 검사 전략
• 설계된 검사 사례 (Test Case) 수행
• 검사 순서
• 단위(코드) 검사 : 코드(모듈) 단위
• 화이트박스 테스트 이용
• 통합(설계) 검사 : 모듈을 결합하여 전체 시스템 검사
• 비점진적 통합 방식
• 단계적 통합 없이 프로그램 전체 검사  ==>> 오류발견, 수정이 어려움
• 점진적 통합 방식
• 모듈 단위로 단계적 통합하여 검사. (상향식, 하향식, 혼합식 통합 방식)
• 하향식 (Top-down)
• 상위 모듈에서 하위 모듈 방향으로 통합. 
• 깊이 우선 통합법. 넓이 우선 통합법
• 통합 절차 : 주요 제어 모듈을 드라이버로 사용하며, 제어 모듈의 종속 모듈은 Stub로 대체(상위 기능 먼저 검사하므로, 하위모듈을 임의의 가짜로 대체하여 검사).
• 상향식 (Bottom-Up)
• 가장 하위단계부터 통합 및 검사.
• 하위 모듈을 클러스터로 결합하여, 클러스터를 검사
• 혼합식 (Sandwich)
• 하위 수준에서는 상향식으로, 상위 수준에서는 하향식으로 통합하여 검사
• 검증(요구사항) 검사 : 사용자의 요구사항 충족 여부 검사
• 통합검사 후, 하나의 소프트웨어로 통합되어 요구사항을 토대로 진행. 블랙박스 테스트
• 종류
• 형상 검사 (구성 검토, 감사)
• 필요한 사항이 제대로 표현되었는지 확인
• 알파 검사
• 개발자 장소에서 사용자가 개발자 앞에서 행함
• 통제된 환경. 오류와 사용상의 문제점을 사용자와 개발자가 함께 확인
• 베타 검사
• 선정된 최종 사용자가 여러명의 사용자 앞에서 수행
• 실업무를 가지고 사용자가 직접시 시험.
• 개발자의 제어 없이 검사 수행.
• 발견된 오류와 사용상의 문제점을 개발자에게 보고
• 시스템 검사 : 개발된 소프트웨어가 컴퓨터 시스템에서 완벽히 수행하는지 검사
• 복구 검사
• 보안 검사
• 강도 검사 : 비정상 적인 상황에서 소프트웨어 실행
• 성능 검사
  
  
• 디버깅
• 테스트 케이스를 이용하여 오류 찾은 후, 그 오류를 수정
• 디버깅 접근법
• 맹목적 강요
• 모든 방법 동원하여도 실패하는 경우에 사용. 비효율적
• 역추적 (backtracing)
• 오류가 발견된 위치에서 원인이 발견될때까지의 코드 부분으로 거슬러 올라가서 수정하는 방법
• 원인 제거 (cause elimination)
• 오류 가능성이 있는 원인을 제거하여 버그 분리
  
  
  
• 유지 보수 (Maintanence)
• 개요
• 목표 : 개발된 소프트웨어 품질을 최상의 상태로 유지
• 가장 많은 노력과 비용이 투입되는 단계
• 사용자에게 인수 되어 설치된 후 발생하는 모든 공학적 작업
  
  
• 활동
• 수정 보수 (= 수리,교정,정정,하자 보수)
• 검사단계에서 발견하지 못한 잠재적 오류를 찾아 수정/진단
• 적응 보수 (= 환경 적응, 조정 보수)
• 소프트웨어 수명 도중 환경의 변화 (OS, 하드웨어 등의 변경)를 기존 소프트웨어에 반영
• 완전화 보수 (= 기능 개선, 기능 보수)
• 본래의 기능에 새로운 기능을 추가하거나 성능 개선 위함
• 유지보수 활동 중 가장 큰 업무 및 비용
• 예방 보수
• = 소프트웨어 재공학
• 미래에 유지보수를 용이하기 위해 소프트웨어를 변경
  
  
• 유지보수 과정
• 유지보수 요구 -> 현 시스템에 대해 이해 -> 수정 및 시험
  
  
• 유지보수 비용
• 소프트웨어 개발 비용 중 70%  차지
• 비용 산정 방법 by BL(Belady와 Lehman이 제안)
• M = P + Ke(c-d)
• M : 노력(인원/월), P : 생산적 활동 비용, K : 통계값에서 구한 상수 
• e = exp, c = 복잡도, d = 소프트웨어에 대한 지식 정도
• 유지보수 문제점
• 다른 사람이 개발한 소프트웨어는 이해하기 어려움.
• 변경이 자주 발생하므로, 문서화를 통해 추적해야 함
• 대부분의 소프트웨어는 변경가능하도록 설계되지 않음
  
  
• 유지보수 부작용
• 코딩 부작용, 자료부작용, 문서화 부작용
  
  
• 외계인 코드 (alien code)
• 너무 오래(15년 이상) 전에 개발되어 유지보수가 어려운 프로그램
• 문서화를 통해 외계인 코드 방지할 수 있음