3장 전통적 S/W 개발 방법론

정보처리기사 필기 - 4과목 소프트웨어 공학

3장 전통적 S/W 개발 방법론

128 요구사항 분석

① 전통적 소프트웨어 개발 방법의 개요

· 전통적(고전적) 소프트웨어개발 방법은 과거의 많은 소프트웨어 개발 경험을 토대로 하여 성공적으로 평가되는 소프트웨어 분석 및 설계 방법들을 집대성하여 하나의 개발 방법으로 정형화한 것

· 전통적(고전적) 소프트웨어 개발 방법을 구조적 소프트웨어 개발 방법이라고도 함

② 요구사항 분석의 개요

요구사항 분석은 소프트웨어 개발의 실제적인 첫 단계로 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화(명세화)하는 활동 의미

· 사용자 요구의 타당성을 조사하고 비용과 일정에 대한 제약 설정

· 사용자의 요구 정확하게 추출하여 목표 정하고, 어떤 방식으로 해결할 것인지를 결정

· 요구사항 분석을 통한 결과는 소프트웨어 설계 단계에서 필요한 기본적인 자료가 되므로 사용자의 요구사항을 정확하고 일관성 있게 분석하여 문서화해야 함

· 소프트웨어 분석가에 의해 요구사항 분석이 수행되며, 이 작업 단계를 요구사항 분석 단계라고 함

③ 요구사항 분석 작업

요구사항 분석은 다음과 같은 작업으로 세분화되어 수해오딤

· 문제 인식 : 사용자와의 면담, 설문조사 및 협조, 각종 문서 검토 등을 통하여 사용자의 요구사항 찾아냄

· 모델 제작 : 평가와 종합을 바탕으로 자료와 제어의 흐름, 기능 처리, 동작 행위, 정보 내용 등을 이해하기 쉽도록 모델로 작성

개발할 소프트웨어에 대한 추상적인 모형을 만드는 것

· 문서화와 검토 : 요구사항 분석 명세서를 작성 → 소프트웨어의 기능, 성능, 제약 조건 등에 대하여 기술 하고 검토

④ 요구사항 분석의 어려움

대화 장벽

· 사용자와 개발자의 지식 배경의 다양화, 용어 불일치 등으로 의사 소통 곤란

· 해결책 : 다이어그램 및 프로토타입 이용

시스템의 복잡도

· 소프트웨어 체계화를 위해 새로운 개념이 필요해지고, 시스템 규모와 대상이 광범위해짐에 따라 난이도 증가에 의한 소프트웨어의 복잡화

· 해결책 : 구조적 분석이나 객체지향 분석 이용

요구의 변경

· 사용자 생각의 부정확성, 생각의 반복된 변경

· 해결책 : 수정 요구와 상반된 요구들의 수용 기술 필요

요구 명세화의 어려움

· 중복 현상, 애매모호함, 시험의 어려움, 과거와 다른 현재 상황 등의 내포에 따라 요구 명세서 작성이 어려움

· 해결책 : 제도적인 요구 분석 기술 필요

⑤ 요구사항 분석가의 자질

요구사항 분석가는 요구사항의 효율적인 분석과 정확한 명세화를 위해 다음과 같은 자질을 갖추어야 함

· 소프트웨어 개발에 많은 경험을 가지고 있어야 함

· 사용자의 요구를 정확히 수용하고, 여러 환경을 이해해야 함

· 설계에 필요한 자료를 충분히 제공할 수 있어야 함

· 다방면에 대한 해박한 지식을 가지고 있어야 함

· 시간 배정과 계획 등을 빠른 시간 내에 파악할 수 있어야 함

· 하드웨어, 소프트웨어를 포함함 컴퓨터에 대한 기술을 이해하고 있어야 함

· 고객이 사용할 시스템을 만들어야 하므로 상대의 관점(고객 관점)에서 문제를 파악할 수 있어야 함

⑥ 구조적 분석 기법

구조적 분석 기법은 자료의 흐름과 처리를 중심으로 하는 요구사항 분석 방법으로, 다음과 같은 특징이 있음

· 도형 중심의 분석용 도구와 분석 절차를 이용하여 사용자의 요구사항을 파악하고 문서화함

· 도형 중심의 도구를 사용하므로 분석가와 사용자 간의 대화가 용이

· 하향식 방법을 사용하여 시스템을 세분화할 수 있고, 분석의 중복을 배제할 수 있음

· 사용자의 요구사항을 논리적으로 표현하여 전체 시스템을 일관성 있게 이해할 수 있음

· 시스템 분석의 질이 향상되고, 시스템 개발의 모든 단계에서 필요한 명세서 작성이 가능

· 구조적 분석 기법에는 자료흐름도, 자료 사전, 소단위 명세서, 개체 관계도, 상태 전이도, 제어 명세서 등의 도구를 이용하여 모델링 함

129 구조적 분석 도구

① 자료 흐름도(DFD)의 개요

자료 흐름도(DFD, Data Flow Diagram)는 요구사항 분석에서 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법으로 자료 흐름 그래프, 버블 차트라고도 함

· 시스템 안의 프로세스와 자료 저장소 사이에 자료의 흐름을 나타내는 그래프로 자료 흐름과 처리를 중심으로 하는 구조적 분석 기법에 이용됨

· 자료 흐름도는 자료 흐름과 기능을 자세히 표현하기 위해 단계적으로 세분화됨

· 자료는 처리를 거쳐 변환될 때마다 새로운 이름이 부여되며, 처리는 입력 자료가 발생하면 기능을 수행한 후 출력 자료를 산출함

② 자료 흐름도 구성 요소 표기법

기호	의미	표기법
		Yourdon/DeMacro	Gane/Sarson
프로세스(Process)	· 자료를 변환시키는 시스템의 한 부분(처리과정)을 나타내며 처리, 기능, 변환, 버블이라고도 함  · 원이나 둥근 사각형으로 표시하고 그 안에 프로세스 이름을 기입	○
자료 흐름(Data Flow)	· 자료의 이동(흐름)이나 연관관계를 나타냄  · 화살표 위에 자료의 이름을 기입	→
자료 저장소(Data Store)	· 시스템에서의 자료 저장소(파일, 데이터베이스)를 나타냄  · 도형 안에 자료 저장소 이름을 기입
단말(Terminator)	· 시스템과 교신하는 외부 개체로, 입력 데이터가 만드러지고 출력 데이터를 받음(정보의 생산자와 소비자)  · 도형 안에 이름을 기입

③ 자료 흐름도의 세분화(상세화)

자료 흐름도의 세분화는 요구사항 분석이 진행됨에 따라 하나의 자료 흐름도를 보다 자세히 표현하기 위해 또 다른 자료 흐름도를 생성하는 것

· 단계(Level) 0의 자료 흐름도는 기본 시스템 모델 또는 배경도라고 하며, 전체 소프트웨어 요소를 표시하는 하나의 프로세스(원)과 입·출력을 나타내는 화살표로 표현

· 각각의 프로세스에 대하여 개별적인 상세화 및 계층화가 가능

· 세분화 단계가 많아질수록 소프트웨어 설계와 구현 작업이 용이해짐

④ 자료 사전(DD)

자료 사전(DD, Data Dictionary)은 자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것이며, 이처럼 데이터를 설명하는 데이터를 데이터의 데이터 또는 메타 데이터라고 함

· 자료 흐름도에 시각적으로 표시된 자료에 대한 정보를 체계적이고 조직적으로 모아 개발자나 사용자가 편리하게 사용 가능

자료 사전 표기법 및 작성 시 유의사항

· 자료 사전의 한 항목은 자료에 대한 정의 부분과 설명 부분으로 구성되며, 정의 부분에는 자료의 이름을, 설명 부분에는 자료에 대한 자세한 내용을 표현

· 이름으로 정의를 쉽게 찾을 수 있어야 하며, 이름이 중복되어서는 안됨

· 갱신하기 쉬워야 하며, 정의하는 방식이 명확해야 함

· 자료 사전에서 사용되는 표시 기호는 다음과 같음

기호	의미
=	자료의 정의 : ~로 구성되어 있다(is composed of)
+	자료의 연결 : 그리고(and)
(  )	자료의 생략 : 생략 가능한 자료(Optional)
[ | ]	자료의 선택 : 또는(or)
{  }	자료의 반복 : Iteration of  ① {}n : n번 이상 반복   ② {}n : 최대로 n 번 반복   ③ {}nm : m이상 n이하로 반복
* *	자료의 설명 : 주석(Comment)

⑤ 소단위 명세서(Mini-Spec.)

소단위 명세서는 세분화된 자료 흐름도에서 최하위 단계 버블(프로세스)의 처리 절차를 기술한 것으로 프로세스 명세서라고도 함

· 소단위 명세서는 분석가의 문서이며, 자료 흐름도(DFD)를 지원하기 위하여 작성

· 소단위 명세서는 서술문장, 구조적 언어, 의사결정나무, 의사 결정표(판단표), 그래프 등을 이용하여 기술

※ 최하위 단계 버블(프로세스)

더 이상 세분화할 수 없는 단계의 프로세스로, 원시 버블 또는 프리미티브 버블(Primitive Bubble)이라고도 함

※ 구조적 언어, 의사결정나무, 의사 결정표

· 구조적 언어 : 자연어의 일부분으로 한정된 단어와 문형, 제한된 구조를 사용하여 명세서를 작성하는 데 이용하는 명세 언어

· 의사결정나무 : 현재 상황과 목표와의 상호 관련성을 나무의 가지를 이용해 표현한 것으로 불확실한 상황에서의 의사결정을 위한 분석 방법

· 의사 결정표(Decision Table) : 복잡한 의사 결정 논리를 기술하는 데 사용하며, 주로 자료 처리 분야에서 이용됨

⑥ 개체 관계도(ERD)

개체 관계도(ERD, Entity Relationship Diagram)는 시스템에서 처리되는 개체(자료)와 개체의 구성과 속성, 개체 간의 관계를 표현하여 자료를 모델화하는데 사용

· 개체 관계도의 구성

개체(Entity)	소프트웨어에 의해 인식되는 여러 종류의 자료
속성(Attribute)	개체에 관련된 특성
관계(Relationship)	개체 간에 존재하는 상호 작용

· 개체는 사각형, 속성은 타원, 관계는 다이아몬드로 표시

· 개체 관계의도 작성 순서

① 주요키를 포함하여 개체의 속성을 모두 찾아냄

② 기본적인 개체와 주요키를 정의하며, 개체 사이의 관계 정의

③ 1:M 관계를 단순화하기 위해 속성 개체를 추가하며, 연관 관계를 정의하여 M:N 관계를 표현함

④ 각 개체를 정규화, 누락된 개체 점검 및 클라스 구조가 필요한지 결정

⑦ 상태 전이도(STD)

상태 전이도(STD, State Transition Diagram)는 시스템에 어떤 일이 발생할 경우 시스템의 상태와 상태 간의 전이를 모델화한 것으로, 상태 전이도를 통해 개발자는 시스템의 행위 정의 가능

· 상태 전이도에서 사각형은 시스템의 상태를, 화살표는 상태 전이를 나타냄

· 화살표의 시작 부분은 상태 전이를 일으키는 사건을 의미하며, 화살표의 끝은 사건의 결과로 발생하는 동작

130 요구사항 분석 CASE와 HIPO

① 요구사항 분석을 위한 CASE(자동화 도구)

· 요구사항 분석을 위한 자동화 도구는 요구사항을 자동으로 분석하고, 요구사항 분석 명세서를 기술하도록 개발된 도구

· 요구사항 분석을 위한 자동화 도구 사용의 이점

- 표준화와 보고를 통한 문서화 품질 개선

- 데이터베이스가 모두에게 이용 가능하다는 점에서 분석자들 간의 적절한 조정

- 교차 참조도와 보고서를 통한 결함, 생략 불일치 등의 발견 용이성

- 변경이 주는 영향 추적의 용이성

- 명세에 대한 유지보수 비용의 축소

종류

요구사항 분석을 위한 자동화 도구에는 SADT, STEA, PSL/PSA, TAGS, EPOS 등이 있음

· SADT(Structed Analysis and Design Technique)

- SoftTech 사에서 개발한 것으로 시스템 정의, 소프트웨어 요구사항 분석, 시스템/소프트웨어 설계를 위해 널리 이용되어 온 구조적 분석 및 설계 도구

- 구조적 요구 분석을 하기 위해 블록 다이어그램을 채택한 자동화 도구

· SREM(Software Requirements Engineering Methodology) = RSL/REVS

- TRW 사가 우주 국방 시스템 그룹에 의해 실시간 처리 소프트웨어 시스템에서 요구사항을 명확히 기술하도록 할 목적으로 개발한 것으로, RSL과 REVS를 사용하는 자동화 도구

- RSL(Requirement Statement Language) : 요소, 속성, 관계, 구조들을 기술하는 요구사항 기술 언어

요소	요구사항 명세를 개발하기 위해 사용되는 개체와 개념
속성	요구를 수정하거나 수식하기 위한 것
관계	개체들 간의 관계
구조	정보 흐름을 묘사하기 위한 것

- REVS(Requirement Engineering and Validation System) : RSL로 기술된 요구사항들을 자동으로 분석하여 요구사항 분석 명세서를 출력하는 요구사항 분석기

· PSL/PSA

-미시간 대학에서 개발한 것으로 PSL과 PSA를 사용하는 자동화 도구

- PSL(Problem Statement Language) : 문제(요구사항) 기술 언어

- PSA(Problem Statement Analyzer) : PSL로 기술한 요구사항을 자동으로 분석하여 다양한 보고서를 출력하는 문제 분석기

· TAGS(Technology for Automated Generation of System)

- 시스템 공학 방법 응용에 대한 자동 접급 방법으로, 개발 주기의 전 과정에 이용할 수 있는 통합 자동화 도구

- 구성 : IORL, 요구사항 분석과 IORL 처리를 위한 도구, 기초적인 TAGS 방법론

- IORL :  요구사항 명세 언어

② HIPO

HIPO(Hierarchy Input Process Output)는 시스템의 분석 및 설계나 문서화할 때 사용되는 기법으로, 시스템 실행 과정인 입력, 처리, 출력의 기능을 나타냄

· 기본 시스템 모델은 입력, 처리, 출력으로 구성되며, 하향식 소프트웨어 개발을 위한 문서화 도구

· 체계적인 문서 관리 가능

· 기호, 도표등을 사용하므로 보기 쉽고 이해하기도 쉬움

· 기능과 자료의 의존 관계를 동시에 표현 가능

· 변경, 유지보수가 용이

· 시스템의 기능을 여러 개의 고유 모듈들로 분할하여 이들 간의 인터페이스를 계층 구조로 표현한 것을 HIPO Chart라고 함

HIPO Chart의 종류

가시적 도표(도식 목차)	시스템의 전체적인 기능과 흐름을 보여주는 계층 구조도
총체적 도표(총괄도표, 개요 도표)	프로그램을 구성하는 기능을 기술한 것으로 입력, 처리, 출력에 대한 전반적인 정보를 제공하는 도표
세부적 도표(상세 도표)	총체적 도표에 표시된 기능을 구성하는 기본 요소들을 상세히 기술하는 도표

131 설계

① 구조적 설계 기법

· 구조적 설계 기법은 구조적 분석 기법의 결과물인 자료 흐름도 등으로부터 소프트웨어의 기능(자료 구조)과 프로그램 구조, 모듈을 설계하기 위한 전략, 평가 지침 및 문서화 도구를 제공하는 체계화된 기법

· 자료의 흐름을 중심으로 하는 설계 기법이므로 자료 흐름 중심 설계 기법이라고도 함

· 자료 흐름도, 자료 사전, 개체 관계도, 소단위 명세서 등이 준비된 이후에 설계

② 설계의 개요

설계는 요구사항 분석 단계의 산출물인 요구사항 분석 명세서의 기능이 실현되도록 알고리즘과 그 알고리즘에 의해 처리될 자료 구조를 문서화하는 것

· 좋은 소프트웨어를 개발하기 위한 가장 핵심이 되는 기술로, 소프트웨어의 품질 평가를 위한 지침이 됨

· 소프트웨어 설계 모형의 구성

[그림 1] 소프트웨어 설계 모형

데이터 설계	요구사항 분석 단계에서 생성된 정보를 소프트웨어를 구현하는 데 필요한 자료 구조로 변환하는 것으로, ERD를 이용하여 정의된 개체와 관계, 자료 사전에 정의된 자료의 설명 등이 데이터 설계의 기초가 됨
구조 설계	소프트웨어를 구성하는 모듈간의 관계와 프로그램 구조를 정의하는 것으로 DFD, DD, STD 등과 모듈의 상호 작용이 기초가됨
인터페이스 설계	소프트웨어와 상호 작용하는 시스템, 사용자 등과 어떻게 통신하는지를 기술하는 것으로 DFD 등이 인터페이스 설계에 기초가 됨
절차(프로시저) 설계	모듈이 수행할 기능을 절차적 기술로 바꾸는 것으로 소단위 명세서, 상태 전이도의 정보가 절차 설계의 기초가 됨

③ 설계의 기본 원리

소프트웨어 설계는 다음과 같은 기본 원리를 가지고 있으며 이는 소프트웨어 설계자에게 보다 더 효율적인 설계 방법을 제공함

모듈화(Modularity)

· 모듈화는 소프트웨어를 모듈 단위로 나누는 것

· 모듈은 서브루틴, 부(Sub) 시스템, 소프트웨어 내의 프로그램, 작업 단위 등을 의미함

· 모듈화를 이용하여 설계하면 확장성, 융통성, 경제성 등이 향상됨

추상화(Abstraction, 개념화)

· 문제의 세부 사항을 먼저 설계하기보다는 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하여 구체화시켜 나가는 설계 방법

· 추상화의 유형

기능 추상화	입력 자료를 출력 자료로 변환하는 과정을 추상화하는 방법
제어 추상화	제어의 정확한 메커니즘(절차, 방법)을 정의하지 않고 원하는 효과를 정하는 데 이용하는 방법
자료 추상화	자료와 자료에 적용될 수 있는 기능을 함께 정의함으로써 자료 객체를 구성하는 방법

단계적 정제(Stepwise Refinement)

· Niklaus Wirth에 의해 제안된 하향식 설계 전략으로, 문제를 상위의 중요 개념으로부터 하위의 개념으로 구체화시키는 분할 기법

· 추상화의 반복에 의해 세분화됨

· 소프트웨어 기능에서부터 시작하여 점차적으로 구체화하고, 상세한 내역(알고리즘, 자료 구조)은 가능한 한 뒤로 미루어 가면서 진행

정보 은닉(Information Hiding)

· 한 모듈 내부에 포함된 절차화 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법

· 다른 모듈이 정보 은닉된 모듈과 인터페이스할 때는 소프트웨어 기능을 수행하는 데 반드시 필요한 정보만을 전달함

· 모듈을 독립적으로 수행할 수 있고, 하나의 모듈이 변경되더라도 다른 모듈에 영향을 주지 않으므로 수정, 시험, 유지보수가 용이함

프로그램 구조(Program Structure)

· 소프트웨어의 구성 요소인 모듈의 계층적 구성을 나타내는 것으로, 제어 계층 구조라고도 함

· 프로그램의 순서, 선택, 반복과 같은 소프트웨어의 절차적인 처리 과정을 나타내지 않음

· 프로그램 구조는 일반적으로 트리 구조의 다이어그램으로 표기함(사각형은 모듈을 나타냄)

· 프로그램 구조에서 사용되는 용어

공유도(Fan-In, 팬-입력)	어떤 모듈을 제어(호출)하는 모듈의 수
제어도(Fan-Out, 팬-출력)	어떤 모듈에 의해 제어(호출)되는 모듈의 수
깊이(Depth)	제어의 계층 수
넓이(Width)	제어의 분기된 수
주종적 모듈(Superordinate)	다른 모듈을 제어(호출)하는 모듈
종속적 모듈(Subordinate)	어떤 모듈에 의해 제어되는 모듈

자료 구조

· 자료 구조는 자료 사이의 논리적인 관계를 표현한 것으로 자료의 구성, 결합 정도, 접근 방법 등을 나타냄

· 자료 구조의 종류에는 스칼라 항목, 벡터, 연결 리스트, 계층적 자료 구조 등이 있음

④ 바람직한 설계의 특징

· 설계는 소프트웨어 구조를 나타내야 함

· 설계는 독립적인 기능적 특성을 가진 요소(모듈)로 구성되어야 함

· 설계는 모듈 구조, 즉 특정 기능 또는 부기능을 수행하는 논리적 요소들로 분리되는 구조를 가져야 함

· 소프트웨어 요소(모듈) 간의 효과적인 제어를 위해 설계에서 계층적 자료 조직이 제시되어야 함

· 설계는 자료와 프로시저에 대한 분명하고 분리된 표현을 포함해야 함

· 설계는 모듈 간과 외부 개체 간의 연결 복잡성을 줄이는 인터페이스를 가져야 함

· 설계는 요구사항 분석에서 얻어진 정보를 이용하여 반복적인 방법으로 이루어져야 함

· 요구사항을 모두 구현해야 하고, 유지보수가 용이해야 함

· 모듈의 기능을 예측할 수 있도록 정의

· 적당한 모듈의 크기를 유지하고, 모듈 간의 상관성(결합도)은 낮추고, 응집도는 높임

· 전체적이고 포괄적인 개념을 설계한 후 차례대로 세분화하여 구체화시켜 나감

· 이식성을 고려함

132 모듈과 모듈화

①  모듈과 모듈화 개요

모듈화는 소프트웨어를 각 기능별로 분할하는 것을 의미하며, 각 기능별로 분할한 것을 모듈이라고 함

· 모듈화를 수행하면 소프트웨어의 복잡도가 감소하고, 변경이 쉬우며 프로그램 구현이 용이함

· 모듈의 속성과 구성

모듈의 속성	· 입·출력 요소 : 자료를 받아들이고, 자료를 내보내는 요소  · 기능 요소 : 입력을 출력으로 바꾸는 요소, 즉 모듈의 처리 결과  · 기관 요소 : 기능을 수행하기 위한 절차상의 코드 또는 논리  · 내부 자료 요소 : 모듈 자체의 작업장, 모듈이 스스로 참조하는 자료
모듈의 구성	· 호출 모듈 : 다른 모듈을 호출하는 모듈  · 피호출 모듈 : 다른 모듈에 의해 호출되는 모듈

 

② 모듈의 기능적 독립성의 개요

모듈의 기능적 독립성은 소프트웨어를 구성하는 각 모듈의 기능이 독립됨을 의미하는 것으로 모듈화, 추상화, 정보 은닉의 부산물

· 모듈이 하나의 기능만을 수행하고 다른 모듈과의 과도한 상호작용을 배제함으로써 이루어짐

· 기능적으로 독립된 모듈은 특정 기능을 수행하고, 다른 모듈과는 간단한 인터페이스만을 가지므로 개발이 쉽고 재사용이 가능

· 독립성이 높은 모듈일수록 모듈을 수정하더라도 다른 모듈에게는 거의 영향을 미치지 않으며, 오류가 발생해도 쉽게 발견하고 해결 가능

· 모듈의 독립성은 결합도와 응집도에 의해 측정되며, 독립성을 높이려면 모듈의 결합도를 약하게 하고 응집도를 강하게 하며 모듈의 크기를 작게 만들어야 함

· 결합도와 응집도는 소프트웨어 설계시 평가 지침이 됨

③ 결함도(Coupling)

· 결합도는 모듈 간에 상호 의존하는 정도 또는 두 모듈 사이의 연관 관계를 의미

· 독립적인 모듈이 되기 위해서는 각 모듈 간의 결합도가 약해야 하며 의존하는 모듈이 적어야 함

· 결합도가 강하면 시스템 구현 및 유지보수 작업이 어려움

· 결합도의 종류

 자료 결합도, 스탬프 결합도, 제어 결합도, 외부 결합도, 공통 결합도, 내용 결합도

결합도 약함                                 ↔                                 결합도 강함

자료 결합도  (Data Coupling)	· 자료 결합도는 모듈 간의 인터페이스가 자료 요소로만 구성될 때의 결합도  · 어떤 모듈이 다른 모듈을 호출하면서 매개 변수나 인수로 데이터를 넘겨 주고, 호출받은 모듈은 받은 데이터에 대한 처리 결과를 다시 돌려주는 것  · 자료 결합도는 모듈 간의 내용을 전혀 알 필요가 없는 상태로서 한 모듈의 내용을 변경하더라고 다른 모듈에는 전혀 영향을 미치지 않는 가장 바람직한 결합도
스탬프(검인) 결합도  (Stamp Coupling)	· 스탬프 결합도는 모듈 간의 인터페이스로 배열이나 레코드 등의 자료 구조가 전달될 때의 결함도  · 두 모듈이 동일한 자료 구조를 조회하는 경우의 결합도이며 자료 구조의 어떠한 변화, 즉 포맷이나 구조의 변화는 그것을 조회하는 모든 모듈 및 변화되는 필드를 실제로 조회하지 않는 모듈에까지도 영향을 미치게 됨
제어 결합도  (Control Coupling)	· 어떤 모듈이 다른 모듈 내부의 논리적인 흐름을 제어하기 위해 제어 신호를 이용하여 통신하거나 제어 요소를 전달하는 결합도  · 상위 모듈이 하위 모듈의 상세한 처리 절차를 알고 있어 이를 통제하는 경우나 처리 기능이 두 모듈에 분리되어 설계된 경우에 발생  · 하위 모듈에서 상위 모듈로 제어 신호가 이동하여 상위 모듈에게 처리 명령을 부여하는 권리 전도형상이 발생
외부 결합도  (External Coupling)	· 외부 결합도는 어떤 모듈에서 외부로 선언한 데이터(변수)를 다른 모듈에서 참조할 때의 결합도  · 참조되는 데이터의 범위를 각 모듈에서 제한 가능
공통(공유) 결합도  (Common Coupling)	· 공통 결합도는 공유되는 공통 데이터 영역을 여러 모듈이 사용할 때의 결합도  · 공통 데이터 영역의 내용을 조금만 변경하더라고 이를 사용하는 모든 모듈에 영향을 미치므로 모듈의 독립성을 약하게 만듬
내용 결합도  (Content Coupling)	· 내용 결합도는 한 모듈이 다른 모듈의 내부 기능 및 그 내부 자료를 직접 참조하거나 수정할 떄의 결합도  · 한 모듈에서 다른 모듈의 내부로 제어가 이동하는 경우에도 내용 결합도에 해당됨

④ 응집도(cohesion)

· 응집도는 정보 은닉 개념을 확장한 것으로, 명령어나 호출문 등 모듈의 내부 요소들의 서로 관련되어 있는 정도, 즉 모듈이 독립적인 기능으로 정의되어 있는 정도를 의미

· 독립적인 모듈이 되기 위해서는 각 모듈의 응집도가 강해야 함

· 응집도의 종류

기능적 응집도, 순차적 응집도, 교환(통신)적 응집도, 절차적 응집도, 시간적 응집도, 논리적 응집도, 우연적 응집도

응집도 강함                                                 ↔                                                 응집도 약함

기능적 응집도  (Functional Cohesion)	모듈 내부의 모든 기능 요소들이 단일 문제와 연관되어 수행될 경우의 응집도
순차적 응집도  (Sequential Cohesion)	모듈 내 하나의 활동으로부터 나온 출력 데이터를 그 다음 활동의 입력 데이터로 사용할 경우의 응집도
교환(통신)적 응집도  (Communication Cohesion)	동일한 입력과 출력을 사용하여 서로 다른 기능을 수행하는 구성 요소들이 모였을 경우의 응집도
절차적 응집도  (Procedural Cohesion)	모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우의 응집도
시간적 응집도  (Temporal Cohesion)	특정 시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 작성할 경우의 응집도
논리적 응집도  (Logical Cohesion)	유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들로 하나의 모듈이 형성되는 경우의 응집도
우연적 응집도  (Coincidental Cohesion)	모듈 내부의 각 구성 요소들이 서로 관련 없는 요소로만 구성된 경우의 응집도

⑤ 효과적인 모듈화 설계 방안

· 결합도는 줄이고 응집도는 높여서 모듈의 독립성을 높임

· 모듈의 제어 영역 안에서 그 모듈의 영향 영역을 유지시킴

· 복잡도와 중복성을 줄이고 일관성을 유지시킴

· 모듈의 기능은 예측이 가능해야 하며 지나치게 제한적이어서는 안됨

· 유지보수가 용이해야 함

· 모듈 크기는 시스템의 전반적인 기능과 구조를 이해하기 쉬운 크기로 분해

· 하나의 입구와 하나의 출구를 갖도록 해야 함

· 인덱스 번호나 기능 코드들이 전반적인 처리 논리 구조에 예기치 못한 영향을 끼치지 않도록 모듈 인터페이스를 설계해야 함

133 설계 방법

① 자료 설계

· 자료 설계는 설계의 첫 번째 작업으로, 요구 사항 분석에서 생성된 여러 모델들을 소프트웨어를 구현하는 데 필요한 자료 구조로 변환하는 것

· 자료 구조가 프로그램 구조와 절차적 복잡성에 영향을 주므로 자료 설계는 소프트웨어 품질에 큰 영향을 줌

· 정보 은닉과 자료 추상화의 개념은 자료 설계를 위한 기초를 제공함

② 구조 설계

· 구조 설계는 프로그램의 구조를 개발하고, 소프트웨어 구성 요소들 간의 관계를 정의하는 것

· 프로그램이 처리하는 기능에 초점을 맞추어 모듈로 분해하고, 프로그램 전반에 걸친 자료의 흐름을 위한 인터페이스를 정의

구조적 설계 절차

구조적(자료 흐름 중심) 설계에서는 다음과 같은 설계 절차를 통해 구조를 설계함

① 정보 흐름의 유형을 설정

② 흐름의 경계 표시

③ 자료 흐름도를 프로그램 구조로 사상

④ 제어 계층을 분해시켜서 정의

⑤ 경험적 방법을 구체화시킴

DFD를 프로그램 구조로 사상시키는 방법

요구사항 분석에서 작성한 DFD를 프로그램 구조로 사상시키는 방법

· 변환 분해 접근법 : 요구 분석 단계의 DFD를 입력 흐름, 변환 흐름, 출력 흐름으로 구분하여 프로그램 구조 도표로 변환시키는 방법

· 거래 분해 접근법 : DFD에서 거래에 해당하는 부분을 찾아내어 이 거래 중심 자료 흐름도를 거래 중심 구조 도표로 변환하는 방법

구조 도표(Structure Chart, 설계 구조도)

· 구조 도표는 프로그램 구조를 설계할 대 사용되는 도구로, 소프트웨어 기능을 몇 개의 고유 기능으로 분할하여 블랙 박스로 나타내고 블랙 박스 간의 인터페이스를 계층 구조로 표현하는 것

· 소프트웨어의 기능을 모듈의 호출 관계와 인터페이스로 나타냄

③ 인터페이스 설계

인터페이스 설계는 소프트웨어와 상호 작용하는 시스템, 사용자 등과 어떻게 통신하는지를 기술하는 과정

· 소프트웨어와 모듈 사이, 소프트웨어와 정보 생산자·소비자 사이, 소프트웨어와 사용자 사이의 인터페이스 설계로 나눌 수 있음

· 변화 요인이 다양한 사용자와의 인터페이스에 중점을 두고 설계함

④ 절차(프로시저) 설계

· 절차(프로시저) 설계는 데이터 설계, 아키텍처 설계, 인터페이스 설계가 이루어진 후에 수행되는 설계 작업으로 모듈이 수행할 기능을 절차적 기술로 바꾸는 것

· 데이터 설계, 아키텍쳐 설계, 인터페이스 설계를 바탕으로 실제 운영되는 소프트웨어로 변환하기 위해 코드에 가까운 추상화 수준의 모듈 명세서를 작성하는 것

· 프로시저 설계는 그래픽 설계 표기법이나 프로그램 설계 언어 등을 사용하여 나타냄

그래픽 설계 표기법

그래픽 설계 표기법은 그림으로 프로시저를 상세히 설명하고 처리 절차를 기술하는 것으로 흐름도와 N-S 차트가 있음

· 흐름도(Flowchart)

· N-S 차트(Nassi-Schneiderman Chart)

- N-S차트는 논리의 기술에 중점을 둔 도형을 이용한 표현 방법으로 박스 다이어그램, Chapin Chart라고도 함

- 연속, 선택 및 다중 선택, 반복 등의 제어 논리 구조를 표현

- GOTO나 화살표 사용하지 않음

- 조건이 복합되어 있는 곳의 처리를 시각적으로 명확히 식별하는 데 적합

- 선택과 반복 구조를 시각적으로 표현

- 이해하기 쉽고, 코드 변환이 용이

- 읽기는 쉽지만 작성 어려워, 임의로 제어를 전이하는 것은 불가능

- 총체적인 구조 표현과 인터페이스를 나타내기 어려움

- 단일 입구와 단일 출구로 표현

프로그램 설계 언어(PDL)

프로그램 설계 언어(PDL; Program Design Language)는 영어 단어를 이용하여 구조적 프로그래맹의 제어 구조를 기술하는 것이며 의사 코드 또는 구조적 영어(언어)라고 함

· 모듈의 논리를 설계할 때 사고 과정을 체계화해 가는 방법이며, 하향식 접근 방식으로 논리의 전체 흐름을 표현

· 현재 프로그래밍 언어와 유사한 서술적 표현에 의하여 프로그램, 설계, 시스템의 검토에 사용하고, 문서화 기법으로도 사용됨

· 순서도 대용으로 활용할 수 있으며 사용자와의 의사소통이 용이하게 함

· 모듈 내의 논리를 문법적 제한 없이 자유롭게 표현 가능

134 구현

① 구현 단계의 개요

구현 단계는 설계 단계에서 생성된 설계 명세서를 컴퓨터가 알 수 있는 모습으로 변환하는 과정으로, 프로그래밍 또는 코딩 단계라고도 함

· 각 모듈을 특정 프로그래밍 언어를 이용하여 원시 코드로 작성하고 문서화하는 작업

· 구현은 설계를 철저히 반영시키고, 원시 코드를 간단 명료하게 작성하며, 디버깅 및 변경, 검사가 용이하도록 해야 함

· 구현 단계에서는 사용할 프로그래밍 언어와 코딩 스타일 등을 결정해야 함

② 프로그래밍 언어

프로그래밍 언어의 분류

1세대 언어	기계어, 어셈블리어와 같은 저급 언어
2세대 언어	과학 계산용 / 정보 처리 분야 / 인터프리터 방식
3세대 언어	범용 언어 / 인공지능용 언어 / 객체지향형 언어 / 대화식 그래픽 언어 / 배열과 벡터 처리용 언어 / 보고서 작성용 언어  CAI용 언어 / 마이크로프로세서 프로그램 언어 / 수치 제어 기계용 도구를 위해 설계된 언어
4세대 언어	· 비절차적 언어, 자연 언어, 사용자 중심 언어, 응용 프로그램 생성기 언어  · 프로토타입 언어, 질의어(SQL), 정보 검색어, 보고서 작성기

프로그래밍 언어의 선정 기준

친밀감	언어의 능력	처리의 효율성	과거의 개발 실적	알고리즘과  계산상의 난이도	자료 구조의 난이도	성능 고려 사항들
프로그램 구조	프로그램의 길이	이식성	대상 업무의 성격	소프트웨어의  수행 환경	개발 담당자의  경험과 지식	컴파일러의 이용  가능성

③ 코딩 스타일 = 코딩의 표준화

프로그래머가 코딩하는 방법이 다르므로 이러한 코딩 방법의 일관성을 유지하고 좋은 코딩을 위해 제시된 표준을 코딩 스타일이라고 함

· 프로그램 논리를 명확하게 작성해야 함

· 지나치게 기교를 부리지 않음

· 수식은 간결하고 직접적으로 표현

· 임시 변수의 사용을 금함

· 혼동을 초래하는 변수명은 사용하지 말고, 일관성 있는 변수명 사용

· 블록 구조 사용

· 들여쓰기 사용

· 판단에 맞는 정확한 제어 구조 사용

· If뒤에 바로 If가 오지 않도록 하고, Else뒤에 Null이 되지 ㅇ낳게 함

· 모듈화와 서브루틴 사용

· 매개 변수가 5개 이상인 모듈은 유의

· 하나의 변수를 다목적으로 사용하지 않음

· 너무 깊은 중첩 구조는 피함

④ 구조적 프로그래밍

· 구조적 프로그래밍은 Dijkstra에 의해 제안된 것으로 신뢰성 있는 소프트웨어의 생산과 코딩의 표준화 등을 위해 개발된 방법

· 구조적 프로그래밍의 기본 제어 구조는 순차, 선택 반복

순차	명령을 순서적으로 나열
선택	특정 논리에 기초하여 명령 선택
반복	순환 제공

· 순차, 선택, 반복을 사용하면 프로그램의 복잡도를 줄여주고, 유지보수 용이

· 분기(GOTO) 없이 프로그래밍하여 읽고, 테스트하기 쉬움

· 오류 없는 프로그램 구성으로 품질 향상시킴

· 완전무결한 프로그래밍 규칙을 제공

· 생산성 증진을 통한 프로그래밍 경비를 감소시킴

· 프로그래밍 규칙

- 프로그램의 제어 흐름을 선형화

- 단일 입구와 단일 출구만을 가지게 함

- GORO문을 사용하지 않음

- 순차, 선택, 반복의 세 가지 기본 제어 구조 사용

135 검사 기법

① 검사의 개요

· 검사(Test)는 소프트웨어 품질 보증 활동의 하나로, 소프트웨어에 대한 요구사항의 만족도 및 예상 결과와 실제 결과의 차이점을 여러 방법으로 사용하여 검사하고 평가하는 일련의 과정을 의미

· 소프트웨어 품질을 평가하는 작업이며 분석이나 설계, 코딩 결과를 최종적으로 점검하는 과정

· 오류를 발견하기 위해 프로그램이나 시스템을 수행하는 과정

· 검사의 목적은 소프트웨어를 구성하는 요소들이 잘 조화를 이루며 정상적으로 동작하고 성능이 요구에 맞다는 것을 보장하기 위해서임

② 검사의 목적을 달성하기 위한 규칙

Glen Myers은 검사의 목적을 달성하기 위해 다음과 같은 규칙 제시

· 오류를 찾기 위해 프로그램을 실행시키는 절차를 검사하 함

· 오류 발견 확률을 높이기 위해 훌륭한 검사 사례를 이용

· 성공적인 검사는 아직 발견되지 않은 오류를 찾아내는 것

※ 검사 자료 : 검사 자료나 실행될 조건을 의미하는 것으로, 소프트웨어 오류를 찾아낼 수 있는 가능성이 가장 높은 테스트를 얻어내는 것

③ 검사 기법

· 검사 기법은 최소한의 시간과 노력으로 대부분의 오류를 찾아내기 위해 검사 사례를 설계하는 방법

· 검사 사례를 설계하는 검사 기법에는 화이트 박스 테스트와 블랙 박스 테스트가 있음

· 검사 사례 설계의 고려사항

- 모듈 내의 모든 독립적인 경로가 적어도 한 번은 수행되어야 함

- 가능한 한 복잡한 논리는 배제시킴

- 임의의 조건을 만족시켜야 함

- 내부 자료 구조를 사용하여 테스트를 수행함

④ 화이트 박스 테스트의 개요

화이트 박스 테스트(White Box Test)는 모듈의 원시 코드를 오픈시킨 상태에서 원시 코드의 논리적인 모든 경로를 검사하여 검사 사례를 설계하는 방법

· 설계된 절차에 초점을 둔 구조적 테스트로, 프로시저(절차) 설계의 제어 구조를 사용하여 검사 사례를 설계하며, 테스트 과정의 초기에 적용됨

· 모듈 안의 작동을 직접 관찰

· 원시 코드(모듈)의 모든 문장을 한 번 이상 수행함으로써 수행됨

· 프로그램의 제어 구조에 따라 선택, 반복 등의 분기접 부분들을 수행함으로써 논리적 경로를 제어함

· 각 조건에서의 참과 거짓의 모든 논리적 결정이 적어도 한 번 이상 실행됨

· 논리 흐름도, 루프 구조, 순환 복잡도에 관한 오류를 찾을 수 있음

· 화이트 박스 테이트 기법에는 기초 경로 검사, 제어 구조 검사(조건 검사, 루프 검사, 데이터 흐름 검사) 등이 있음

⑤ 기초 경로 검사(Basic Path Testing)

· 기초 경로 검사는 Tom McCabe가 제안한 것으로 대표적인 화이트 박스 테스트 기법

· 검사 사례 설계자가 절차적 설계의 논리적 복잡성을 측정할 수 있게 해주고, 이 측정 결과는 실행 경로의 기초를 정의하는 데 지침으로 사용됨

· 기초 경로 검사 절차

① 설계나 원시 코드를 기초로 해서 흐름도를 작성

② 흐름도의 논리적 복잡도를 측정

③ 독립 경로들의 기초 집합을 결정

④ 기초 지합의 각 경로를 실행시키는 검사 사례를 선정

· 제어 흐름도

- 제어 흐름을 표현하기 위해 사용되는 그래프로 프로그램 그래프, 흐름 그래프라고 함

- 제어 흐름도는 각 제어마다 다음과 같은 기호를 사용하여 표시함

▶ 노드(원) : 절차적 명령문을 나타냄

▶ 화살표 : 제어의 흐름을 나타냄

▶ 영역 : 화살표와 노드(원)로 둘러싸인 구역으로, 외부 구역도 하나의 영역으로 포함

· 순환 복잡도

순환 복잡도는 한 프로그램의 논리적인 복잡도를 측정하기 위한 소프트웨어의 척도로, 제어 흐름도 이론에 기초를 둠

- 순환 복잡도를 이용하여 계산된 값은 프로그램의 독립적인 경로의 수를 정의하고, 모든 경로가 한 번 이상 수행되었음을 보장하기 위해 행해지는 테스트 횟수의 상한선을 제공

- 제어 흐름도 G에서 순환 복잡도V(G)는 다음과 같은 방법으로 계산할 수 있음

▶ 순환 복잡도는 제어 흐름도의 영역 수와 일치하므로 영역 수를 계산함

▶ V(G) = E - N + 2 → E는 화살표 수, N은 노드의 수

⑥ 제어 구조 검사

· 조건 검사(Condition Testing)

- 프로그램 모듈 내에 있는 논리적 조건을 검사하는 검사 사례 설계 기법

- 프로그램에 있는 각 조건을 검사하는 데 초점을 맞추는 방법으로 조건 검사 범위 측정이 간단함

· 루프 검사(Loop Testing)

- 프로그램의 반복(Loop) 구조에 초점을 맞춰 실시하는 검사 사례 설계 기법

- 루프 검사는 단순 루프, 중첩 루프, 연결 루프, 비구조적 루프의 네 가지를 사용하여 정의할 수 있음

- 초기화 오류, 인덱싱 및 증가 오류, 경계값 오류 등을 발견할 수 있음

· 데이터 흐름 검사(Data Flow Testing)

- 프로그램에서 변수의 정의와 변수 사용의 위치에 초점을 맞춰 실시하는 검사 사례 설계 기법

⑦ 블랙 박스 테스트 개요

블랙 박스 테스트(Black Box Test)는 소프트웨어가 수행할 특정 기능을 알기 위해서 각 기능이 완전히 작동되는 것을 입증하는 검사로서, 기능 검사

· 소프트웨어 인터페이스에서 실시되는 검사

· 부정확하거나 누락된 기능, 인터페이스 오류, 자료 구조나 외부 데이터베이스 접근에 따른 오류, 행위나 성능 오류, 초기화와 종료 오류 등을 발견하기 위해 사용되며 테스트 과정의 후반부에 적용됨

· 소프트웨어 산물의 각 기능별로 적절한 정보 영역(입·출력)을 정하여 적합한 입력에 대한 출력의 정확성을 점검함

· 블랙 박스 테스트의 종류에는 동치 분할 검사, 경계값 분석, 원인-효과 그래프 검사, 오류 예측 검사, 비교 검사 등이 있음

⑧ 동치 분할 검사(Equivalence Partitioning Testing)

· 동치 분할 검사는 입력 자료에 초점을 맞춰 검사 사례를 만들고 검사하는 방법으로 동등 분할 기법이라고도 함

· 프로그램의 입력 조건에 타당한 입력 자료와 타당하지 않은 입력 자료의 개수를 균등하게 하여 검사 사례를 정하고, 해당 입력 자료에 맞는 결과가 출력되는지 확인하는 방법

⑨ 경계값 분석(Boundary Value Analysis)

· 경계값 분석은 입력 자료에만 치중한 동치 분할 기법을 보완하기 위한 기법

· 입력 조건의 중간값보다 경계값에서 오류가 발생될 확률이 높다는 점을 이용하여 입력 조건의 경계값을 검사 사례로 선정하여 검사

⑩ 원인-효과 그래프 검사(cause-effect graphing testing)

· 원인-효과 그래프 검사는 입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석하여 효용성 높은 검사 사례를 선정하여 검사하는 기법

· 프로그램의 외부 명세에 의한 입력 조건과 입력으로부터 발생되는 출력을 논리적으로 연결시킨 그래프로 표현하여 검사함

⑪ 오류 예측 검사(fault based testing) = Mutation Testing

· 오류 예측 검사는 과거의 경험이나 확인자의 감각으로 검사하는 기법

· 다른 블랙 박스 테스트 기법으로는 찾아낼 수 없는 오류를 찾아내는 일련의 보충적 검사 기법이며, 데이터 확인 검사

⑫ 비교 검사(Comparison Testing)

여러 버전의 프로그램에 동일한 검사 자료를 제공하여 동일한 결과가 출력되는지 검사하는 기법

136 검사 전략

① 검사 전략의 개요

검사 전략은 설계된 검사 사례를 수행하는 것으로, 다음과 같은 순서에 의해 진행됨

① 단위(코드) 검사 : 검사는 프로그램의 기본 단위인 모듈(코드) 수준에서 시작

② 통합(설계) 검사 : 단위 검사 후 모듈을 겹합하여 저체 시스템에 대해 검사

③ 검증(요구사항) 검사 : 사용자의 요구사항을 충족시키는가를 검사

④ 시스템 검사 : 개발된 소프트웨어가 컴퓨터 시스템에서 오나벽하게 수행되는지를 검사 

② 단위 검사

· 단위 검사(Unit Test)는 코딩이 이루어진 후 소프트웨어 설계의 최소 단위인 모듈에 초점을 맞추어 검사하는 것

· 단위 검사는 화이트 박스 테스트 기법을 사용

· 단위 검사에서는 이터페이스, 외부적 I/O, 자료 구조, 독립적 기초 경로, 오류 처리 경로, 경계 조건 등을 검사

③ 통합 검사의 개요

· 통합 검사(Integration Test)는 단위 검사가 완료된 모듈들을 결합하여 하나의 시스템으로 완성시키는 과정에서의 검사를 의미

· 통합 검사는 모듈 간의 인터페이스와 연관된 오류를 밝히기 위한 검사 기법

· 통합 검사 방법에는 다음과 같이 비점진적 통합 방식과 점진적 통합 방식

비점진적 통합 방식	· 단계적으로 통합하는 절차 없이 모든 모듈이 미리 결합되어 프로그램 전체를 검사하는 방법으로, 빅뱅 통합 검사 있음  · 전체 프로그램을 대상으로 하므로 오류 발견이 힘들고, 수정이 어려움
점진적 통합 방식	· 모듈 단위로 단계적으로 통합하면서 검사하는 방법이며 하향식, 상향식 혼합식 통합 검사가 있음  · 오류 수정이 용이하고, 인터페이스와 연관된 오류를 완전히 검사할 가능성이 높음

④ 하향식 통합 검사(Top Down Integration Test)

하향식 통합 검사는 프로그램의 상위 모듈에서 하위 모듈 방향으로 통합하면서 검사하는 기법

· 주요 제어 모듈(주요 프로그램)을 기준으로 하여 아래 단계로 이동하면서 통합되는데, 이때 깊이 우선 통합법이나 넓이 우선 통합법을 사용할 수 있음

· 하향식 통합 방법 수행 절차

① 주요 제어 모듈을 드라이버로 사용하고, 주요 제어 모듈의 종속 모듈들은 스터브(Stub)로 대체함

② 깊이 우선 또는 넓이 우선 등의 통합 방식에 따라 종속 스터브들이 실제 모듈로 교체됨

③ 모듈이 통합될 때마다 검사를 실시함

④ 새로운 오류가 발생하지 않음을 보증하기 위해 회귀 검사(전에 수행된 검사의 일부나 전체를 다시 검사하는 것)를 실시함

※ 하향식 통합 방법

· 깊이 우선 통합법 : 주요 제어 모듈을 중심으로 이 모듈에 종속된 모든 모듈을 통합하는 것

· 넓이 우선 통합법 : 구조의 수평을 중심으로 해당하는 모듈을 통합하는 것

· 드라이버(Driver) : 검사 사례 자료를 입력 받고, 검사를 위해 받은 자료를 모듈로 넘기며, 관련된 결과를 출력하는 제어 프로그램

· 스터브(Stub) : 일시적으로 필요한 조건만을 가지고 임시로 제공되는 가짜 모듈, 즉 시험용 모듈

· 스터브(Stub) 사용 이유 : 하향식 통합 방식에서는 먼저 상위의 주요 제어 모듈을 검사하게 되는데, 이 때 주요 제어 모듈은 이에 종속된 모듈이 모두 결합되어야 정상적으로 검사될 수 있음. 그러므로 주요 제어 모듈이 정상적으로 운용되도록 스터브를 사용하는 것

⑤ 상향식 통합 검사(Bottom up integration Test)

상향식 통합 검사는 프로그램의 하위 모듈에서 상위 모듈 방향으로 통합하면서 검사하는 기법

· 가장 하위 단계의 모듈부터 통합 및 검사가 수행되므로 스터브는 필요하지 않지만, 하나의 주요 제어 모듈과 관련된 종속 모듈의 그룹인 클러스터가 필요함

· 상향식 통합 방법 수행 절차

① 하위 모듈들을 클러스터로 결합

② 검사 사례 입·출력을 조정하기 위해 드라이버 작성

(드라이버 작성 : 주요 제어 모듈이 있어야 프로그램이 동작하게 되는데, 상향식 통합 검사에서는 하위 모듈에서 상위 모듈로 통합·검사되므로 클러스터를 시험하기 위한 제어 프로그램이 필요)

③ 클러스터 검사

④ 드라이버 제거하고, 클러스터는 프로그램 구조의 상위로 이동하여 결합

⑥ 혼합식 통합 검사

혼합식 통합 검사는 하위 수준에서 상향식 통합, 상위 수준에서 하향식 통합을 사용하여 최적의 검사를 지원하는 방식으로 샌드위치식 통합 검사 방법

⑦ 검증 검사(확인 검사, 인수 검사)

· 검증 검사(Validation Test)는 소프트웨어가 사용자의 요구사항을 충족시키는가에 중점을 두고 검사하는 방법

· 통합 검사가 끝난 후 전체가 하나의 소프트웨어로 통합되어 요구사항 명세서를 토대로 진행하며, 블랙 박스 테스트를 이용하여 진행

· 검증 검사 기법

형상 검사(구성 검토, 감사)	소프트웨어 구성 요소, 목록, 유지보수를 지원하기 위해 필요한 사항들이 제대로 표현되었는지를 검사하는 기법
알파 검사	· 개발자의 장소에서 사용자가 개발자 앞에서 행하는 검사 기법  · 통제된 환경에서 행해지며, 오류와 사용상의 문제점을 사용자와 개발자가 함게 확인하면서 기록
베타 검사	· 선정된 최종 사용자가 여러 명의 사용자 앞에서 행해지는 검사 기법  · 실업무를 가지고 사용자가 직접 시험하는 것으로, 개발자에 의해 제어되지 않은 상태에서 검사가 행해지며, 발견된 오류와 사용상의 문제점을 기록하고 개발자에게 주기적으로 보고

⑧ 시스템 검사

· 시스템 검사(System Test)는 개발된 소프트웨어가 해당 컴퓨터 시스템에서 완벽하게 수행되는가를 검사하는 것

· 시스템 검사의 종류

복구 검사	소프트웨어에 여러 가지 결함을 주어 실패하도록 한 후 올바르게 복구되는지를 확인하는 검사
보안 검사	시스템 내에 설치된 보호 도구가 부적당한 침투로부터 시스템을 보호할 수 있는지를 확인하는 검사
강도 검사	비정상적인 상황에서 소프트웨어를 실행시키기 위한 검사로 비정상적인 양, 빈도 등의 자원을 요구하는 환경에서 소프트웨어를 실행시킴
성능 검사	통합된 시스템에서 소프트웨어의 실시간 성능을 검사하기 위한 것으로, 검사 단계의 전 과정에 걸쳐 수행됨

⑨ 디버깅(Debugging)

디버깅은 검사 단계에서 검사 사례에 의해 오류를 찾은 후 그 오류를 수정하는 과정이며 검사 기법은 아님

· 디버깅은 성공적인 검사 결과로 발생함

· 디버깅은 인간의 심리적인 요소가 많이 관여하기 때문에 매우 어려움

디버깅 접근법

· 맹목적 강요 : 디버깅할 수 있는 모든 방법을 동원하여도 실패하게 된 경우에 사용되는 가장 비효율적인 방법

· 역추적(Backtracking) : 오류가 발견된 위치에서 원인이 발견될 때까지의 코딩 부분으로 거슬러 올라가면서 수정하는 가장 닐반적인 방법이며, 작은 프로그램에서 성공적으로 사용할 수 있음

· 원인 제거(Cause Elimination) : 오류 가능성이 있는 원인을 제거하여 버그를 분리하기 위해 사용

137 유지보수

① 유지보수의 개요

유지보수(Maintenance)는 개발된 소프트웨어의 품질을 항상 최상의 상태로 유지하기 위한 것으로, 소프트웨어 개발 단계 중 가장 많은 노력과 비용이 투입되는 단계

· 유지보수는 소프트웨어가 사용자에게 인수되어 설치된 후 발생하는 모든 공학적 작업

· 소프트웨어 유지보수를 용이하게 하려면 시험 용이성, 이해성, 수정 용이성, 이식성 등이 고려되어야 함

· 유지보수는 수리 보수, 적응 보수, 완전화 보수, 예방 보수 활동으로 구분 할 수 있고, 이 활동을 통해 소프트웨어의 수명은 연장시키는 작업

수정(Corrective) 보수  = 수리·교정·정정·하자 보수	시스템을 운영하면서 검사 단계에서 발견하지 못한 잠재적인 오류를 찾아 수정하는 활동으로, 오류의 수정과 진단을 포함
적응(Adaptive)보수  = 환경 적응, 조정 보수	· 소프트웨어의 수명 기간 중에 발생하는 환경의 변화(하드웨어, 운영체제 등)를 기존의 소프트웨어에 반영하기 위하여 수행하는 활동  · 운영체제나 컴파일러와 같은 프로그래밍 환경의 변화와 주변장치 또는 다른 시스템 요소가 향상되거나 변경될 대 대처할 수 있는 유지보수 활동
완전화(Perfective) 보수  = 기능 개선, 기능 보수	· 소프트웨어의 본래 기능에 새로운 기능이 추가하거나 성능을 개선하기 위해 소프트웨어를 확장시키는 활동  · 유지보수 활동 중 가낭 큰 업무 및 비용을 차지하는 활동
예방(Prevention) 보수	· 장래의 유지보수성 또는 신뢰성을 개선하거나 소프트웨어의 오류발생에 대비하여 미리 예방 수단을 강구해 두는 활동  · 예방 유지보수를 소프트웨어 재공학이라고 함

② 유지보수의 과정

① 유지보수 요구 : 유지보수 활동이 필요할 경우 이에 대한 요구를 수행

② 현 시스템에 대한 이해 : 요구된 유지보수 활동을 수행하기 위해서는 먼저 현재 시스템에 대한 이해를 필요로 하며, 현재 시스템에 대해 이해하지 못한 상태에서 유지보수 활동을 수행하면 오류가 발생할 수 있음

③ 수정 및 시험 : 유지보수 활동을 수행하고, 유지보수 활동을 수행한 후에도 정상적으로 기능이 수행되는지를 확인하기 위해 테스트

③ 유지보수의 비용

· 소프트웨어 유지보수 단계에서 사용되는 비용은 소프트웨어 개발에 필요한 비용 중 약 70%를 차지함

· 유지보수 비용은 분석, 평가, 설계 변경, 코딩 등의 생산적인 활동과 프로그램과 자료 구조의 이해, 인터페이스의 특성 파악, 성능 측정 등의 실험 활동에 따라 달라질 수 있음

· 유지보수 비용은 일반적으로 bl 방법에 의해 다음과 같은 산정함

M = P +  Ke(c-d)

M : 유지보수를 위한 노력(인원/월)  P : 생산적인 활동에 드는 비용  K : 통계값에서 구한 상수

c : 복잡도  d :  소프트웨어에 대한 지식의 정도

④ 유지보수의 문제점

· 다른 사람이 개발한 소프트웨어는 이해하기가 어려울 뿐만 아니라 소프트웨어 개발자들의 이직률이 높기 때문에 개발된 소프트웨어에 대한 전문적인 설명을 들을 수가 없음

· 소프트웨어에 대한 변경이 자주 발생하므로 변경된 내용을 문서화하지 않을 경우 추적하기 어려움

· 소프트웨어에 대한 적절한 문서가 없거나 문서의 질이 형편없을 수도 있음

· 대부분의 소프트웨어는 변경 가능하도록 설계되지 않음

· 유지보수는 매혹적인 작업이 아니므로 기피하는 경향이 있음

※ 유지보수의 부작용 / 외계인 코드

유지보수의 부작용 : 유지보수 활동을 통해 예기치 못한 부작용이 발생될 수 있음

· 코딩 부작용 : 코딩 내용의 변경으로 인해 발생하는 부작용

· 자료 부작용 : 자료나 자료 구조의 변경으로 인해 발생하는 부작용

· 문서화 부작용 : 자료 코드에 대한 변경이 설계문서나 사용자가 사용하는 매뉴얼에 적용되지 않을 때에 발생하는 부작용

외계인 코드(Alien Code)

· 외계인 코드는 아주 오래 전에 개발되어 유지보수 작업이 매우 어려운 프로그램을 의미

· 일반적으로 15년 전 또는 그 전에 개발된 프로그램을 의미하며, 문서화를 철저하게 해 두면 외계인 코드 방지 가능

출처 : 2017 시나공 정보처리기사 필기