정보처리기사/part02.소프트웨어 개발

2. 통합 구현

kyunge_ev 2024. 6. 13. 22:57

✅ 모듈 구현

1. 단위 모듈 구현

(1) 공통 모듈

  • 전체 시스템 설계를 할 때 각각의 서브시스템에서 공통으로 사용되는 모듈들을 하나로 묶어놓은 소프트웨어 라이브러리를 말한다.
  • 공통 모듈을 만드는 이유는 각각의 서브시스템에서 제각각 모듈을 만들면 개발비가 중복되고 표준화도 되지 않기 때문이다.
  • 공통 모듈을 하나로 만들면 나중에 서브시스템이 추가되더라도 공통 모듈은 재개발 없이 재사용이 가능하다는 장점이 있다.

(2) 단위 모듈

  • 소프트웨어 구현에 필요한 여러가지 동작 중 한 가지 동작을 수행하는 기능을 모듈로 구현한 것
  • 단위 모듈에는 화면 모듈, 화면에서 입력받은 데이터 처리를 위한 서비스 컴포넌트, 비즈니스 트랜잭션 컴포턴트 등이 있다.
  • 공통 모듈을 먼저 구현하고, 이를 단위 모듈 구현 시에 재사용한다.
💡 모듈

- 소프트웨어 구조를 이루며, 다른 것들과 구별될 수 있는 독립적인 기능을 갖는 단위
- 하나 또는 몇개의 논리적인 기능을 수행하기 위한 명령어들의 집합
- 서로 모여 하나의 완전한 프로그램으로 만들어질 수 있다.

(3) 모듈화

  • 하나의 큰 작업을 각 기능에 따라 실제로 개발할 수 있는 작은 단위로 나누는 것
  • 이 때 모듈의 독립성은 결합도가 낮을 수록 좋고, 응집도는 높을 수록 좋다.
  • 모듈의 독립성이 높아야 모듈화가 잘 되었다고 평가될 수 있다.

💡 기능을 작게 분할하여 모듈의 개수가 많아지면 인터페이스가 복잡해지는 단점이 발생할 수 있다.

📌 결합도와 응집도

결합도  모듈들이 서로 관련되거나 연결된 정도를 나타내는 것으로 두 모듈 간의 상호 의존도를 말한다.
응집도 한 모듈 내에 있는 처리 요소들 사이의 기능적인 연관 정도를 나타내며, 응집도가 높아야 좋은 모듈이 된다.

2. 단위 모듈 테스트

(1) 단위 모듈 테스트의 개념

  • 테스트는 결함(Fault)을 찾기 위해 소프트웨어를 작동시키는 일련의 행위와 절차를 말한다.

(2) 단위 모듈 테스트의 분류

1. 테스트 단계에 의한 분류

  • 모듈 테스트 : 독립적인 환경에서 하나의 모듈만을 테스트
  • 통합 테스트 : 시스템 모듈 간의 상호 인터페이스에 관한 테스트이다. 즉 모듈 간의 데이터 이동이 원하는 대로 이루어지고 있는가를 확인하는 작업이다.
  • 시스템 테스트 : 시스템 초기의 목적에 부합하는지에 대한 테스트이다.
  • 인수 테스트 : 사용자의 요구사항을 만족하는지를 확인하는 테스트이다.

2. 테스트 방법에 의한 분류

  • 블랙박스 테스트(Black Box Testing) : 소프트웨어의 외부 명세서를 기준으로 그 기능, 성능을 테스트한다.
    • 입/출력, 데이터 위주
  • 화이트박스 테스트(White Box Testing) : 소프트웨어 내부의 논리적 구조를 테스트한다.
    • =클래스 박스, 내부 명세서를 기준으로

(3) 블랙박스 테스트

  • 프로그램의 논리(알고리즘)을 고려하지 않고, 프로그램의 기능이나 인터페이스에 관한 외부 명세로부터 직접 테스트하여 데이터를 선정하는 방법
  • 기능테스트, 데이터 위주(Data-Driven) 테스트, 입출력 위주(IO-Driven)의 테스트이다.
  • 블랙박스 테스트 방법은 소프트웨어의 기능적 요구 사항에 초점을 맞추고 있다.
  • 프로그램의 논리나 알고리즘과는 상관 없이 기초적 시스템 모델의 관점이다.

📌 블랙박스 테스트 기법

구분내용동등(동치) 분할
(Equivalence Partitioning,
균등분할)
경계값 분석
(Boundary Value Analysis)
원인-결과 그래프 기법오류 추측 기법(Error-Guessing)비교 테스트 기법(Comparsion Testing)조합 테스트(Combinatorial Test)

구분 내용
동등(동치) 분할
(Equivalence Partitioning, 균등분할)		 - 프로그램의 입력 도메인을 테스트 사례가 산출될 수 있는 데이터의 클래스로 분류해서 테스트 사례를 만들어 검사하는 방법
- 프로그램의 입력 조건을 중심으로 입력 조건에 타당한 값과 그렇지 못한 값을 설정하여 각 동등 클래스 내의 임의의 값을 테스트 사례로 선정한다.
* 유효 동등 클래스 집합 : 프로그램에 유효한 입력을 가진 테스트 사례
* 무효 동등 클래스 집합 : 프로그램에 타당치 못한 입력을 가진 테스트 사례
- 각 클래스에 최소화 테스트 사례를 만드는 것이 중요하다.
경계값 분석
(Boundary Value Analysis)		 - 입력 조건의 중간값보다는 경계값에서 오류가 발생될 확률이 높다는 점을 이용해서 입력 조건의 경계값에서 테스트 사례를 선정한다.
- 입력 자료에만 치중한 동등 분할 기법을 보완하기 위한 기법이다.
- 입력 조건과 출력 조건을 테스트 사례로 선정한다.
- 입력 조건이 [a,b]와 같이 값의 범위를 명시할 때, a,b 값 뿐만 아니라 [a,b]의 범위를 약간씩 벗어나는 값들을 테스트 사례로 선정한다.
- 즉, 입력 조건이 특정한 수를 나타낼 경우, 최대값, 최소값, 최대값보다 약간 큰 값, 최소값보다 약간 작은 값들을 선정한다.
원인-결과 그래프 기법 - 입력 데이터 간의 관계가 출력에 미치는 상황을 체계적으로 분석하여 효용성 높은 테스트 사례를 추출하여 테스트하는 기법
- 프로그램의 외부 명세에 의한 입력 조건(원인)과 그 입력으로 발생되는 출력(결과)을 논리적으로 연결시킨 그래프로 표현하여 테스트 사례를 유도해 낸다.
오류 추측 기법
(Error-Guessing)		 - 다른 블랙박스 테스트 기법들이 놓칠 수 있을 법한 오류를 감각과 경험으로 찾아내는 일련의 보충적 테스트 기법이다.
- 세부화된 알고리즘이 존재하지 않는다.
비교 테스트 기법
(Comparsion Testing)		 - 블랙박스 테스트 기법의 최초로 Back-to-Back 테스트라고 한다.
- 소프트웨어의 신뢰성이 절대적으로 중요한 경우, 똑같은 기능의 소프트웨어를 개발하여 비교한다.
- 테스트는 일관성을 보장하기 위해 두 시스템의 결과를 동시에 실시간 비교하면서 진행한다.
조합 테스트
(Combinatorial Test)		 * each choice 조합 테스트
: 각 입력 인자의 분할된 클래스로부터 최소한 하나의 입력값이 테스트 케이스에 포함되도록 하는 조합이고

* all combinations 조합 테스트
: 모든 가능한 클래스이 조합이 테스트 케이스에 포함되도록하는 것

* 페어와이즈 테스트(Pairwise Test)
: 입력들의 모든 가능한 조합들을 테스트하는 대신 각 인자의 값을 다른 인자의 값과 최소한 한 번은 짝을지어 테스트를 하는 방법,
페어와이즈 테스트가 all cominations 조합 테스트에 비해 테스트 케이스의 수는 획기적으로 줄이면서 오류를 검출하는 능력면에서는 거의 같은 결과를 내는 것으로 밝혀졌다.

* 직교 배열(Orthogonal Array) 테스트
: 모든 원소의 서로소 집합인 직교 배열의 원리를 소프트웨어 테스트 설계에 적용하여 조합의 수를 줄이면서도 결함 검출 비율이 동일한 테스트 기법이다. 행뿐만 아니라 열까지 Pariwise하게 테스트 케이스를 구성하여 수행하는 테스트 기법
💡 테스트 오라클(Test Oracle)

- 테스트의 결과가 참인지 거짓인지를 판단하기 위해 사전에 정의된 참값(5+3=8이라면 여기서 8)을 입력하여 비교하는 기법 및 활동을 말한다.
- 종류 : 참, 샘플링, 휴리스틱, 일관성 검사

(4) 화이트박스 테스트

  • 프로그램 내의 모든 논리적 구조를 파악하거나, 경로들의 복잡도를 계산하여 테스트 사례를 만든다.
  • 절차, 즉 순서에 대한 제어 구조를 이용하여 테스트 사례들을 유도하는 테스트 사례 설계 방법이다.
  • 테스트 사례들을 만들기 위해 소프트웨어 형상(SW Configuration)의 구조를 이용한다.
  • 프로그램 내의 허용되는 모든 논리적 경로 기본경로를 파악하거나, 경로들의 복잡도를 계산하여 테스트 사례를 만든다.

📌 화이트 박스 테스트의 기법

기초 경로 테스트 (구조 테스트,
복잡도 테스트)		 - McCabe에 의해 제안된 가장 대표적인 화이트박스 기법으로 테스트 영역을 현실적으로 최대화시켜준다.
- 상세 설계 및 원시 코드를 기초로 논리 흐름도를 작성하며, 프로그램의 논리적 복잡도를 측정한다.
- 테스트 사례 설계자가 절차적 설계의 논리적 복잡도를 측정하고, 이 측정을 실행 경로의 기초를 정의하는 데 사용할 수 있게 한다.
- 제어 흐름을 표현하기 위해 논리 흐름도를 이용한다.
루프 테스트
(Loop Testing)		 - 프로그램 반복(Loop) 구조에 국한해서 실시하는 화이트박스 테스트 기법
- 구조 테스트와 병행 사용이 가능하다
- 발견 가능 오류 : 초기화 결함, 인덱싱(Indexing) 및 증가 결함, 루프의 경계선에서 나타나는 경계 결함 등
조건 테스트 - 모듈 내에 포함된 논리적 조건을 검사하여 테스트 사례를 설계하는 방법
- 프로그램에 있는 각 조건을 테스트하는 데 초점을 맞춘다.
데이터 흐름 테스트 (Data Flow Testing) - 변수 정의의 위치와 변수들의 사용에 따라 검사 경로를 선택하는 조건 구조 검사 방법

📌 논리 흐름도와 복잡도

논리 흐름도
(흐름 그래프: Flow Graph)		 - 원(Node(N)): 프로그램의 한 Line(명령문) 또는 순서적으로 수행되는 여러 라인의 집합(일련의 절차적 명령문)
- 화살표(Edge(E)): 실행 순서, 제어의 흐름(=간선)
- 영역: 노드와 간선의 의해 한정된 부분
복잡도 - 프로그램의 논리적 복잡도를 수량(Quentative)적으로 측정하는 소프트웨어 측정법(SW Metrics)
- V(G) = E - N + 2 (E: 간선의 수, N: 노드의 수)
- V(G) = P + 1 (P: 분기의 Node 수)
복잡도의 품질 - 5 이하 : 매우 간단한 프로그램
- 5~10 : 매우 구조적이고 안정된 프로그램
- 20 이상 : 문제 자체가 매우 복잡하거나 구조가 필요 이상으로 복잡한 프로그램
- 50 이상 : 매우 비구조적이며 불안정한 프로그램

✅ 통합 구현 관리

1. IDE 도구

(1) IDE 개요

  • 효율적으로 소프트웨어를 개발하기 위한 통합 개발 환경(IDE : Integrated Development Environment)
  • 기존의 소프트웨어 개발에서 코드 편집기, 디버거, 컴파일러, 인터프리터 등이 분리어 있던 도구들을 개별로 사용하던 작업들을 하나로 통합하여 개발자에게 제공

(2) IDE 종류

  • 이클립스(Eclipse)
  • 라자루스(Lazarus)
  • 엑스코드(X code)
  • 비주얼 스튜디오(Visual Studio)
  • J 빌더(J Builder)
  • C++ 빌더(C++ Builder)
💡 IDE 도구의 각 기능

- Coding : 프로그래밍 언어를 가지고 컴퓨터 프로그램을 작성할 수 있는 환경을 제공(구현)
- Compile : 고급언어의 프로그램을 저급언어 프로그램으로 변환하는 기능
- Debugging : 프로그램에서 발견되는 버그를 찾아 수정할 수 있는 기능
- Deployment : 소프트웨어를 최종 사용자에게 전달하기 위한 기능
컴파일 고급언어 vs 저급언어( 어셈블리어 / 기계어 )
기준 : 인간 공학

2. 협업도구

(1) 협업도구의 개요

  • 소프트웨어 개발 프로젝트 임무를 수행하기 위해 각기 다른 장소에 있는 많은 개발자가 참여할 때, 팀 단위의 활동을 가능하게 하기 위해 협업도구가 필요함

(2) 협업도구의 기능

  • 업무 효율성 향상
  • 정보 접근성 향상
  • 전체 이슈 진행 과정을 쉽게 파악
  • 직원관리(전자 결재, 근태 관리, 주소록)

3. 소프트웨어 형상 관리

(1) 형상 관리의 개요

1. 소프트웨어 형상 관리(SCM : Software Configuration Management)

  • 소프트웨어에 대한 변경을 철저히 관리하기 위해 개발된 일련의 활동
  • 소프트웨어를 이루는 부품의 Baseline(변경 통제 시점)을 정하고 변경을 철저히 통제하는 것
  • 전체 소프트웨어 프로세스에 적용되는 ‘보호 활동’이다.

2. 소프트웨어 형상 관리 항목(SCI : Software Configuration Item)

  • 프로젝트 요구 분석서
  • 설계서
  • 프로그램(소스 코드, 목적 코드, 명령어 파일, 자료 파일, 테스트 파일)
  • 사용자 지침서
  • 운영 및 설치 지침서

3. 베이스라인(Baseline)

  • 정식으로 검토되고 합의된 명세서나 제품으로서, 이것으로부터 앞으로의 개발을 위한 바탕 역할을 하며, 정식 변경 통제 절차들을 통해서만 변경될 수 있는 것(IEEE)
  • 정당화될 수 있는 변경에 심하게 저항하지 않으면서 변경을 통제하게 도와주는 하나의 소프트웨어 형상 관리 개념
💡 형상 관리는 개발 전 단계에서 관여한다.

4. 형상 관리의 기능(식 통 감 보(기))

(1) 형상 식별

  • 형상 관리 계획을 근거로 형상 관리의 대상이 무엇인지 식별하는 과정
  • 형상 식별은 소프트웨어 형상의 모든 항목에 대해 의미 있고 항구적인 명명을 보증하는 소프트웨어 형상 관리 활동이다.
  • 형상 관리 항목(SCI : Software Configuration Item)에 대해 관리 목록 번호를 부여하고 나무 구조를 표현하여 저장한다. 이는 관련 문서에 대한 추적을 용이하게 한다.
  • 통제가 쉽도록 ‘누가, 언제, 무엇을, 왜 정의하였는가?’하는 정보를 생성하며, 기준선(Baseline)을 설정한다.

(2) 형상 통제

  • 식별된 SCI의 변경 요구를 검토하고 승인하여 현재의 베이스라인에 적절히 반영될 수 있도록 통제하기 위한 형상 관리 활동이다.

형상 통제 절차

  • 변경 요구( Change Request)의 제기 → 변경 요청서(Change Report) 작성(변경 요청서는 CCA에 의해 변경의 상태나 우선순위 등 최종 결정을 내리도록 사용자 또는 프로그래머에 의해 작성) → 공학 변경명령(EOO:Engineering Change Order)
💡 CCA(Change Contrl Authority) : 변경 제어 담당관
  • 형상 통제는 소프트웨어 유지보스를 위한 변경 관리와 일치한다.

(3) 형상 감사(Configuration Audit)

  • 회의를 통해 오류를 발견
  • 변경이 적절하게 시행되었는지 객관적인 검증과 확인(V&V) 과정을 거쳐 새로운 형상의 무결성을 확보하기 위한 활동이다.
  • 정형 검토 회의(FTR : Formal Technical Review)
    • 수정 완료된 형상 객체의 기술적인 정확성에 초점을 둔다.
    • 검토자들은 SCI를 산정하여 다른 SCI와의 일관 혹은 잠재적인 부작용 유무를 검토한다.
    📌 정형 검토 회의 지침
    • 제품의 검토에만 집중하라
    • 의제를 제한하여 진행하라
    • 논쟁과 반박을 제한하라
    • 문제의 영역을 명확히 표현하라
    • 해결책과 개선책에 대해 논하지 마라
    • 참가자의 수를 제한하라
    • 체크리스트를 개발하라
    • 자원과 시간 일정을 할당하라
    • 의미있는 훈련을 행하라
    • 검토자들의 메모를 공유하라
    • 검토 과정과 결과를 재검토하라
  • 소프트웨어 형상 감사
    • 검토 시 일반적으로 고려되지 않은 특성들에 대해 형상 객체를 산정함으로써 FTR을 보완한다.

(4) 형상 보고(=형상 기록)

  • 형상 식별, 변경 통제, 형상 감사 기능의 수행 결과를 기록하고 데이터 베이스에 의해 관리를 하며, 이에 대한 보고서를 작성하는 활동
  • 형태 상태 보고(CSR : Confiugration Status Reporting)이라고도 한다.

5. 형상 관리 도구

(1) 형상 관리 도구의 개요

  • 프로그램 소스를 특정 저장소에 저장해둔 것을 내려받아 수정 후 업로드시키고, 다른 개발자가 개발한 최신 소스를 내려 받아 분석 및 빌드하도록 도와주는 도구이다.
  • 버전 관리 = 소스 관리 = 소스 코드 관리
  • 종류 : CVS, SVN, Git(hub) 등

(3) 형상 관리 도구의 구성 요소

구분 내용
저장소 - 프로젝트의 프로그램 소스를 포함한 형상 항목이 저장되는 장소
- 소스뿐만 아니라 소스의 변경 사항도 모두 정할 수 있다.
- 네트워크를 통해서 여러 사람이 접근 가능하다.
체크아웃 - 저장소에서 소스 및 버전 관리 파일을 받아 온다.
커밋 - 소스를 수정 및 삭제, 새 파일 추가 등의 변경 사항을 저장소에 갱신할 수 있다.
체크인 - 저장소에 해당 파일을 반영한다.
업데이트 - 체크아웃을 통해서 소스를 가져왔다 하더라도 다른 사람이 커밋을 하면 로컬 소스 코드가 달라지는데, 이 때 업데이트 명령어를 통해서 저장소에 있는 최신 버전의 소스를 가져올 수 있다.
- 로컬 소스 코드와 저장소에 있는 소스 코드를 비교해 차이가 발생하는 부분만 바꿔준다.

6. 소프트웨어 재사용

(1) 소프트웨어 재사용의 개념

  • 기존의 기능 및 품질을 인정받은 소프트웨어의 전체 혹은 일부분을 재사용하여 새로 개발되는 소프트웨어의 질을 높이고, 생산성을 향상시켜 개발 시간과 비용을 감소시키는 소프트웨어 위기의 해결책

(3) 소프트웨어 재사용 평가 기준

  • 소프트웨어 부품의 크기, 복잡도, 정규화 정도, 재사용 빈도수에 따라 재사용 가능성의 높고 낮음을 평가한다.

(5) 소프트웨어 재사용의 이점

  • 개발 비용과 기간을 단축시킨다.
  • 소프트웨어 개발의 생산성을 높인다.
  • 프로젝트 실패의 위험을 줄여준다.

7. 소프트웨어 재공학

(1) 소프트웨어 재공학의 개요

  • 소프트웨어 위기의 해결책을 개발의 생산성이 아닌 유지보수의 생산성 재고에서 찾는 새로운 시각이다.

(3) 소프트웨어 재공학의 목적

  • 소프트웨어의 유지보수성을 향상시킨다.
  • 소프트웨어에서 사용하고 있는 기술을 상향 조정한다.
  • 소프트웨어의 수명을 연장시킨다.
  • 소프트웨어 성분들을 추출하여 정보 저장소에 저장한다.
  • 유지보수 생성선을 높인다.

(5) 소프트웨어 역공학(Reverse Engineering)

  • 소프트웨어의 역공학은 소프트웨어 정공학의 반대로 진행되며, 추상도가 더 높아진다.
  • 소프트웨어 역공학은 소스코드보다 상위 수준의 추상화에서 프로그램 표현을 위해 프로그램을 분석하는 프로세스이다.
  • 역공학은 설계 복구의 한 프로세스로 기존 프로그램으로부터 데이터, 구조 및 절차적 설계 정보를 추출해낸다.
  • 역공학의 관심 분야
    • 추상화 수준(Abstraction Level)
    • 완전성(Completeness)
    • 방향성(Directionality)
  • 역공학의 핵심 : ‘추상 추출(Extract Abstractions) 활동’으로써 문서화가 안된 구프로그램을 평가하며, 소스 코드로부터 수행 처리의 명세, 사용자 인터페이스, 프로그램 자료구조와 데이터베이스를 추출한다.
  • 역공학의 2가지 개념
    • 코드의 역공학 : 코드로부터 흐름도, 자료구조도, 자료 흐름도를 재생시키는 것
    • 데이터 역공학 : 코드로부터 자료 사전, ERD 등을 재생시키는 것
  • 역공학 프로세스
    • 처리(Process) 역공학
      • 소스 코드에 의해 표현된 절차적 추상을 이해하고 추출하기 위한 과정으로, 시스템에 대한 높은 상세 수준에서의 기능적 추상을 나타내는 각 컴포넌트에 대한 처리 설명서를 작성한다.
    • 데이터(Data) 역공학
      • 프로그램 수준에서 내부 프로그램 데이터 구조와 새로운 데이터 베이스 스키마를 역공학 해야 한다.
    • 사용자 인터페이스(User Interface) 역공학
      • 기존 사용자 인터페이스를 이해하기 위해 인터페이스 구조와 행위 모델을 코드로부터 추출한다.

8. 리팩토링(Refactorying)

(1) 리팩토링의 정의

  • 소프트웨어를 보다 쉽게 이해하고 적은 비용으로 수정할 수 있도록 겉으로 보이는 동작의 변화 없이 내부 구조를 변경하는 것으로, 프로그램의 가치가 상승할 수 있다.
  • 코드 스멜을 고치고 다듬는 과정이다.

(4) 코드 스멜과 리팩토링 대상

1. 코드 스멜 대상

  • 읽기 어려운 프로그램
  • 중복된 로직을 가진 프로그램
  • 실행 중인 코드를 변경해야 하는 특별 동작을 요구하는 프로그램
  • 복잡한 조건이 포함된 프로그램

2. 리팩토링 대상

  • 중복 코드
  • 긴 메소드명
  • 큰 클래스
  • 긴 파라미터 리스트
  • Switch Parametor
  • 병렬 상속 구조
  • 외계인 코드(Alien Code)
    • 아주 오래되거나 참고문서 또는 개발자가 없어 유지보수 작업이 어려운 프로그램을 의미
    • 프로그램 문서화(Documentation)를 통해 외계인 코드가 생성되는 것을 방지할 수 있다.
저작자표시 비영리 변경금지