소프트웨어공학 기말 정리 2

Lecture 11 : 구현

1. 구현 작업

• 본격적으로 시스템을 구축하는 단계
• 프로그램 (코드 모듈)을 구축하는 과정

2. 도구와 표준

• 도구 : 프로그래밍 생산성을 높이기 위한 도구
• 모델링 도구 : UML 설계를 그릴 수 있고 이를 여러 프로그래밍 언어로 변환할 수 있는 도구
• 구현 도구 : 컴파일러, 인터프리터, 디버거, 비주얼 편집기와 IDE, 형상관리
• 코드 표준
  • 명명 규칙 : 클래스, 속성, 오퍼레이션, 시스템의 다른 요소의 이름을 붙일 때 규칙에 따라 이름 붙이기
  • ex) 클래스 이름은 대문자

3. 정적 모델의 구현 - 뭐가 중요한지 잘 몰겠음

• 설계 프로그램으로 매핑
• 추상 수준에 따라 구현에 도움이 되는 정도가 다름
  • 개념 수준 : 도메인 개념
  • 명세 수준 : 인터페이스와 타입
  • 구현 수준 : 구현에 종속적인 사항
• 클래스의 구현
  • 클래스 코드의 구현
    • 속성 : 클래스 안의 인스턴스 변수
    • 오퍼레이션 : 클래스 안의 메소드
  • 상속
    • UML 표현이 언어 문법에 1대1 매칭

4. 연관의 구현

• 연관 : 두 클래스에 속한 객체들이 정보를 추적할 수 있게 하려는 것
• 양방향 연관
  • 두 클래스가 같은 패키지 안
  • 두 클래스가 상대편 객체를 알기 위해 public 메소드와 private 변수 가지기
• 연관의 역할
  • 역할의 추가
• 다중도의 구현
  • 크기를 아는 경우 배열의 사이즈를 적어주기
• 집합 관계의 구현
  • vector를 사용하는 경우 사이즈를 모르기 때문에 * 로 표현
• 합성 관계 - 먼소리?
  • 객체의 존폐에 대한 제어가 있는 집합 관계
  • 집합 개념의 클래스가 요소 개념의 객체의 생성과 소멸 제어

5. 추상 클래스의 구현

• 객체가 생성되는 클래스가 아니라 상속된 클래스가 구체적으로 구현하도록 메소드와 변수의 선언만 있는 템플릿

6. 패키지의 구현

• 패키지 다이어그램
  • 클래스의 모임인 패키지의 구성과 의존 관계 표시
  • import, include 사용
• 패키지 선언

7. 동적 모델링의 구현

• 순서 다이어그램
  • 협력하는 객체들 사이의 메세지 교환을 나타냄
  • 메세지를 받는 객체는 제 3의 객체에게 하나 이상의 메세지를 호출할 수 있음
  • 코딩하는 법 - 안나오길..
• 상태 다이어그램
  • Inactive 객체의 상태 다이어그램을 구현하는 방법
  • 상태 다이어그램을 클래스로 매핑
  • 상태정보를 저장하기 위한 속성 추가
  • 상태 변화는 클래스의 메소드
  • switch case 문과 if문 많이 사용
• 액티비티 다이어그램
  • 액티비티나 프로시저 안에서 수행되어야 할 액션들의 순서를 나타냄
  • 제어 객체나 서브 시스템의 알고리즘이나 제어 흐름 나타냄
  • 프로그램의 위치, 프로그램의 제어문, 반복문으로 제어 흐름 구현

8. 배치 다이어그램

9. 데이터 변환과 시스템 전환 정책

• 데이터 변환
• 일정 : 변경이 많지 않은 것부터 변환
• 데이터 변환 작업 순서
  • 새 파일, 테이블, 데이터베이스의 생성과 검증
  • 포맷 오류 체크 및 수정
  • 변환을 위한 데이터 준비
  • 자료 변환 및 입력
  • 변환 입력된 후 검증
• 시스템 전환 방법
  • 즉시 변환
  • 병행 운영
  • 파일로드 운영
  • 단계적 운영

10. 사용자 교육

• 사용자
• 관리자
• IT 스텝

Lecture 12 : 코드 검사

1. 코드 검사 (Insepction)

• Intro
  • 검사는 개인에 의지하지 않고 조직적으로 해결하려는 노력
  • 프로그래밍에 소요되는 비용 중 가장 핵심적인 부분의 오류를 찾아 수정
  • 오류를 발견 후 제거하여 높은 품질의 소프트웨어를 얻기 위함
  • 공식 기술 검토의 하나이며, 이를 위한 검사팀이 만들어져서 조사함
• 내용
  • 코드 검사는 unit test 이전이나 이후에 진행
    • error가 발생하고 이 error를 해결하면서 더 좋은 결과를 만들기
  • 잘 정의된 순서와 방법에 의해 진행
  • 프로그램 스타일을 표준화, 코드가 개발되는 과정에서 나오는 문서로 인식
  • 개발 라이프 사이클에 포함시켜서 개발 & 품질 보증 활동(SQA)의 일부로 인식
  • 코드 자체에 대한 기술적인 검토만 이루어지게 함
  • 체계적인 틀과 참여하는 사람들에 대한 교육이 필수적임
  • 계획을 수립하고, 그 결과가 자료로 수집되어 관리자에게 보고되어야 한다.

2. 코드 검사 계획

• 새로 만들어지는 코드
• 새로 기능 추가, 많은 변화가 가해진 코드
• 검사팀은 4~7명이 적당
  • 낭독자
  • 사회자
  • 검사자
  • 기록자
  • 프로그램을 만든 저자

3. 코드 검사 진행

• 제품의 개발 과정과 절차를 향상시키는 것이 품질과 생산성을 높이는 가장 효율적인 방법이다.
• 품질 문제의 85%는 개발 과정과 직접적인 연관성이 있음
• 참여자들은 검토회 이전에 코드를 읽고 의문점과 문제점 파악하기
• 코드 검사는 오류를 지적하는 것이지, 해결 방법을 찾으려는 것이 아니므로 최소한의 시간을 써야 한다. (중요)
• 시간을 절약해야 하는 경우 일대일 검사도 가능
• 기술적인 부분에 대해서만 이야기하고 검토가 끝난 후 다시 거론하지 않기
  -> 상호간의 감정적인 부분...

4. 검사팀의 역할 (생략)

5. 코드의 오류 유형 - Ty (중요!!)

• 데이터 오류 (DA: data error)
  • 데이터가 다루어지는데 발생하는 오류
  • 데이터의 유형 정의, 변수 선언, 매개 변수 오류
• 문서 오류 (DC: documentation error)
  • 프로그램 구성요소인 선언 부분
  • 서브 루틴, 모듈에 대한 적합하지 않은 주석, 불필요한 주석 등
• 기능 오류 (FN: function error)
  • 서브루틴이나 블록이 잘못된 것(what)을 수행하는 오류
• 논리 오류 (LO: logic error)
  • 서브루틴이나 블록이 수행하는 방법(how)이 잘못되어 있는 오류
• 성능 오류 (PF: performance error)
  • 프로그램을 수행하며 요구되는 효율성을 만족시키지 못하는 오류
• 표준 오류 (ST: standard error)
  • 과정이나 표현이 표준에 의해 이루어지지 않은 경우
• 기타 (OT: error)
  • 문법적인 오류, 사람의 개성이 포함된 경우, 애매한 오류들

6. 각 오류에 대한 종류 - Cl

• 실종 (M: missing)
  • 구성 요소 안에 있어야 할 것들이 없음으로서 생기는 오류
• 실수 (W: wrong)
  • 구성 요소 안에 있으나 잘못이 발견된 오류
• 불필요 (E: extra)
  • 요구되는 것 이상으로 필요없는 것이 들어간 오류

7. 코드 검사 사후 검토

• 추후에 새로 나타나는 오류를 줄이고 더 이상의 오류가 발생하지 않도록 하는 것이 목적

8. 요약

• 코드 검사는 높은 품질의 소프트웨어를 얻기 위한 품질 보증 활동
• 코드 검사를 통해 오류를 걸러내고 여러 사람들이 다른 사람이 만든 프로그램에 대한 지식을 공유할 수 있고, 함께 좋은 품질의 시스템을 개발한다는 공감대를 형성하는데 기여
• 검사를 위한 틀이 만들어져야 하고, 훈련을 통해 코드 검사를 수행해야 한다.

Lecture 13 : 소프트웨어 테스트

1. 소프트웨어 테스팅

• Inspection VS Testing
  • Inspection : 검사
  • Testing : 수행하면서..
• 소프트웨어 테스팅이란 소프트웨어의 품질을 확보하고 결함을 찾아내기 위해 수행되는 일련의 작업!!
• Testing은 개발된 소프트웨어의 품질에 대한 평가와 품질 향상을 위한 수정 작업을 포함한다.
• 소프트웨어 테스팅은 품질 보증을 위한 마지막 단계

2. 테스팅의 개요와 목적 (중요)

• 테스팅의 개요
  • 개발자가 자신의 불완전함과 실수를 가정
  • 불완전성을 극복하고 높은 품질의 제품을 만들기 위한 노력!
  • 순서 : Inspection -> Testing
  • 높은 확률로 오류를 찾아낼 수 있도록 좋은 시험사례를 만들기!
• 테스팅의 목적
  • 일반적인 소프트웨어 테스트 목적
    • 오류 발견, 요구사항 충족, 명세에 충족, 출시 이후 결함 예방
  • 소프트웨어 테스트의 부가적 목적
    • 자신감 획득과 정보 확인, 개발 프로세스 점검, 적절히 동작하는지 확인
  • 오류를 발견하려고 프로그램을 실행
  • 기존에 발견하지 못한 오류를 많이 발견하는 것이 좋은 사례

3. 소프트웨어 개발 프로세스와 테스트 -V형 모델

• 여러개의 시험을 통해 진행하는 구조

4. 단위 테스트 (중요)

• Intro
  • 프로그램의 기본 단위인 모듈에 대한 테스트
  • 설계 지침을 기반으로 모듈의 중요한 경로와 경계값을 테스트
  • v모델 방식의 소프트웨어 개발에서 단위 테스트는 테스트 프로세스의 첫 단계
  • 코드가 효율적으로 작성되었는지, 프로젝트 내에 합의된 코딩 표준을 준수하고 있는지 검증
• 단위 테스트의 인터페이스 점검 사항
  • 입력 변수의 개수, 입력 변수의 타입, 입력 변수의 순서가 정확한지 확인
  • 변수의 단위가 정확하고 호출 모듈과 호출되는 모듈에서 일치하는지 확인
  • 읽기 전용 변수가 변경되었는지 확인
  • 라이브러리 호출 입력 변수확인
  • 파일 사용 정확한지 확인
• 단위 테스트 자료구조 점검 사항
  • 타입 / 초기화(디폴트값) / 이름(타이핑) / 불일치 데이터 / 언더,오버플로우
• 단위 테스트 오류처리 점검 사항
  • 오류 메세지가 이해하기 쉬운지 확인
  • 오류 처리가 오류 클래스와 일치하지 않는지 확인
  • 예외 처리 확인
  • 오류에 대한 서술이 오류 위치를 찾는데 필요한 정보를 주는지 확인
    -> 오류 클래스 만들어서 사용하기!!

5. 통합 테스트

• 각각의 모듈을 통합하여 통합된 컴포넌트 간의 인터페이스와 상호 작용상의 오류를 발견하는 작업 수행
• 블랙박스 테스트
• 통합 테스트는 점진적으로 실시
  • 하향식 통합
    • 드라이버 모듈을 주 모듈로 사용
    • 깊이우선 or 넓이 우선 방법을 이용하여 하나의 하위 모듈을 선택하여 통합하고 테스트
    • 통합될 때 까지 두번째 단계 반복
  • 상향식 통합
    • 드라이버 모듈 설계하여 하위 모듈들과 결합시켜 테스트 모듈들의 묶음을 클러스터 라고 부름
    • 드라이버 모듈을 실제 모듈로 대체, 한층 더 높은 드라이버 모듈 설계 -> 더 큰 클러스터로 통합
    • 통합될 때 까지 두번째 단계 반복

  6. 시스템 테스트

• Intro
  • 다른 작업을 모두 마치고 마지막으로 소프트웨어와 다른 시스템 요소들과 통합해야 함 -> 모든 요소들이 적절히 조화를 이루어 시스템의 기능을 만족하는지 확인하기
  • 실제로 구현된 시스템과 계획된 사양을 비교하기
  • 모든 모듈이 통합된 후에 시스템 레벨의 오류를 테스트 단계에서 확인할 수 있다.
  • 비기능적 요구도 확인하기
• 시스템 테스트의 테스트 종류 (중요!)
  • 복구 테스트
  • 보안 테스트
  • 스트레스 테스트 -> 시스템에 부하를 걸때
  • 성능 테스트

7. 인수 테스트

• 확인 테스트
  • 개발된 소프트웨어가 고객의 요구사항을 만족하는지 조사하는 시험
  • 개발자, 독립적인 테스터 및 사용자가 수행
• 인수 테스트
  • 사용자가 수행하는 확인 테스트!!
  • 개발된 소프트웨어가 사용자의 요구에 만족하는지 검증하는 목적
  • 요구사항 분석 단계에서 도출된 시스템의 사양이나 계약을 만족하는지 확인
  • 시스템 테스트가 완료된 후 시작!
• 인수 테스트의 종류 (중요!)
  • 알파 테스트
    • 사용자가 개발 환경에 와서 테스트하는 것
  • 베타 테스트
    • 개발자 팀이 소프트웨어를 사용자에게 배포하여, 자신의 컴퓨터 환경 또는 실제 상황에서 수행하는 테스트

8. 블랙박스 테스트 (중요)

• Intro
  • 프로그램을 블랙박스로 취급하여 내부 구조를 참조하지 않고 주어진 입력에 요구되는 결과가 나오는가를 시험하기!
  • 프로그램과 외부와의 인터페이스에 대해서 시험이 이루어짐
  • 프로그램의 기능에 대해 초점을 맞추기, 주어진 입력 값들의 조합에 의해 요구되는 결과가 나오는지 확인
  • 설계 명세서나 요구사항 명세서만을 참조함
• 테스트 케이스 도출 기법
  • 동등 분할 : 오류 종류에 따라 프로그램의 입력 데이터 분류
  • 경계값 분석
    • 입력 조건을 분석하여 경계값 주위에서 시험 데이터 선택
    • 경계값에서 약간 큰 값, 작은 값 등 이용
  • 페어와이즈 조합
  • 상태 전이
  • 인과 그래프
  • 결정 테이블

9. 화이트박스 테스트

• Intro
  • 프로그램 내부의 구성을 시험
  • 구조 또는 코드에 기초한 시험
  • 블랙 박스에서 문제 없으면 화이트박스 안해도 괜찮음
• 테스트 검증 검증 기준
  • 모든 실행문 커버리지
    • 코드의 모든 부분이 실행되도록 테스트 케이스 설계
  • 분기/결정 커버리지
    • 결정문의 true, false를 적어도 한 번 씩 수행하도록 설계
  • 조건 커버리지
    • 결정문을 결정하는 조건의 true, false 체크
    • 조건문의 모든 조건식을 만족하는 경우와 만족하지 않는 경우 테스트
  • 변경조건/결정 검증기준
  • 다중조건
  • 기본 경로 테스트
  • 자료 흐름 테스트

10. 테스트 프로세스

• 단계1) 테스트 계획
• 단계2) 테스트 설계
• 단계3) 테스트 실행
• 단계4) 결과분석 및 평가

11. 테스트 계획

• 프로젝트 계획서, 요구사항 명세서를 바탕으로 테스트의 목표 수립, 테스트의 대상 및 범위를 선정
• 효율적인 테스트를 위한 전략, 일정 등을 포함한 테스트 계획서 작성
• 테스트 활동 전체에 대한 최상위 테스트 계획서와 단계별 계획서 모두 작성

12. 테스트 설계

• 테스트 케이스 : 테스트에 사용할 특정한 입력값
• 테스트 (케이스) 설계 : 테스트에 필요한 최적의 입력값을 찾아내는 것!
• 적은 수의 테스트 케이스로 오류를 검출할 확률이 높도록 구성하는 것

13. 테스트 실행

• 테스트 계획 단계에서의 계획서와 테스트 설계 단계에서의 테스트케이스 설계서, 테스트 절차서를 기반으로 구현된 소프트웨어를 구동시켜 테스트를 실시하는 단계

14. 테스트 결과 분석 및 평가

• 테스트 활동의 결과와 얻어진 출력값을 분석하여 테스트 성공 여부에 대해 평가
• 프로젝트에서 정의한 테스트 단계에 대한 테스트 보고서 작성

15. 테스트 종료

• 완벽한 테스트는 없음
• 테스트 완료하는 기준을 만들어 놓고 수행하기
  • 테스트 완료 기준 관점
    • 기간, 작업량, 오류가 감소하는 정도, 테스트케이스 수, 테스트 커버리지

16. 요약

• 테스트는 소프트웨어에 숨겨있는 오류를 발견하는 과정이며, 소프트웨어에 대한 점진적 확인과 검증하는 과정
• 확인(???)이란 소프트웨어가 요구사항 명세서에 지정된 기능 혹은 성능을 정확히 수행하는지 조사하는 것
• 검증이란 소프트웨어의 기능 혹은 성능이 고객의 요구사항을 만족하는지 조사
• 테스팅 기법은 블랙박스와 화이트박스로 나눌 수 있음

기말고사 예상 문제

Lecture 11

1. 구현 작업 단계

• 전체 계획
• 모듈설계/모둘코딩/모듈테스트/모듈문서화
• 통합 테스트
• 시스템 테스트
• 릴리스

2. 추상 수준의 3가지

• 개념 수준, 명세 수준, 구현 수준

3. 구현의 정의

• 작업 이후 본격적으로 시스템을 구축하는 단계

4. 코드 표준

• 명명 규칙 : 클래스, 속성 오퍼레이션 등에 있어서 혼란을 주지 않기
• 클래스 이름 대문자
• 속성의 이름 첫글자 소문자
• 오퍼레이션 소문자로 시작
• 헝가리안 표기법

5. 시스템 전환 방법의 비교

• 즉시 변환
  • 장점
    • 새 시스템의 도입 효과 즉각적
    • 오래된 시스템 고집하여 새 시스템을 약화시킬 기회없음
    • 계획 단순
  • 단점
    • 문제가 발생할 경우 돌이킬 수 없음
    • 만일의 사태에 대한 계획 필요
• 병행 운영
  • 장점
    • 새 시스템에 문제가 있으면 돌이킬 수 있음
    • 과거 시스템과 비교 가능
  • 단점
    • 중첩되는 기간에 고객이 두 시스템의 비용을 이중이로 지출
    • 사용자가 친숙한 시스템 고집하여 새로운 시스템을 안 쓸 수도 있음
• 파일럿 운영
  • 장점
    • 즉시 전환과 병행 운영의 장점 동시에 가져감
    • 리스크 감소, 비용 적음
  • 단점
    • 파일럿의 성과를 파악하지 못하면, 전면적인 적용에 문제
• 단계적 운영
  • 장점
    • 서브시스템에 주의 기울이기
    • 첫 단계를 잘 선택하면, 투자 회수가 빠름
    • 각 단계를 테스트 하여 완벽한 시스템이 될 수 있다.
  • 단점
    • 초기 단계에 문제 발생하면 새 시스템에 안좋은 소문이 남
    • 최종 단계까지 오래 걸림

Lecture 12

1. 코드 오류 유형 및 종류

• 데이터, 문서, 기능, 논리, 성능, 표준 오류와 기타

2. 코드 검사 이유

• 추후에 새로 나타나는 오류 줄이고 더 이상의 오류가 발생하지 않도록 함
• 오류를 발견 후 제거하여 높은 품질의 소프트웨어를 얻기

3. 코드 검사팀의 구조 및 역할

??? 이게 왜 나왔냐

Lecture 13

1. V형 모델

2. 시스템 테스트 종류

• 복구 테스트, 보안 테스트, 스트레스 테스트, 성능 테스트

3. 시험 목적

• 일반적인 소프트웨어 테스트 목적
  오류 발견, 요구사항 충족, 명세에 충족, 출시 이후 결함 예방
• 소프트웨어 테스트의 부가적 목적
  자신감 획득과 정보 확인, 개발 프로세스 점검, 적절히 동작하는지 확인
• 오류를 발견하려고 프로그램을 실행
• 기존에 발견하지 못한 오류를 많이 발견하는 것이 좋은 사례

4. 통합테스트 방식(top-down/borrom-up)

• 하향식 통합
  드라이버 모듈을 주 모듈로 사용
  깊이우선 or 넓이 우선 방법을 이용하여 하나의 하위 모듈을 선택하여 통합하고 테스트
  통합될 때 까지 두번째 단계 반복
• 상향식 통합
  드라이버 모듈 설계하여 하위 모듈들과 결합시켜 테스트 모듈들의 묶음을 클러스터 라고 부름
  드라이버 모듈을 실제 모듈로 대체, 한층 더 높은 드라이버 모듈 설계 -> 더 큰 클러스터로 통합
  통합될 때 까지 두번째 단계 반복

5. Alpha & Beta 테스팅 차이

• 인수테스트의 두 종류
• 알파 테스트
  사용자가 개발 환경에 와서 테스트하는 것
• 베타 테스트
  개발자 팀이 소프트웨어를 사용자에게 배포하여, 자신의 컴퓨터 환경 또는 실제 상황에서 수행하는 테스트

6. ????

• 단위 테스트 -> 통합 테스트 -> 시스템 테스트 -> 인수 테스트
• 블랙박스 테스트와 화이트박스 테스트