정보처리기사 필기 무료강의 제4과목[SE-04강] 전통적 개발 방법론(분석과 설계)

[SE-04강] 전통적 개발 방법론(분석과 설계)

 

 

[SE-04강]전통적개발방법론(분석과설계).pdf

0.15MB

 

학습내용
☞ 전통적 개발 방법론의 요구사항 분석 및 설계
학습목표
☞ 전통적 개발 방법론에 대한 개념을 이해 할 수 있다
 요구사항 분석과정을 이해 할 수 있다
 설계과정의 전반적인 사항을 정리 할 수 있다
학습내용
1. 전통적 소프트웨어 개발 단계

2. 요구사항 분석
(1) 요구사항 분석의 개념 
1) 프로젝트를 이해할 수 있는 개발의 실질적인 첫 단계
2) 소프트웨어가 가져야 될 기능을 기술하는 단계
3) 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화(명세화)하는 단계
4) 현재의 상태를 파악하고 문제를 정의한 후, 문제 해결과 목표를 명확히 도출하는 단계

 

(2) 요구사항 분석 작업
1) 문제 인식 사용자 면접, 설문조사를 통한 의견 수렴, 현재 사용 중인 각종 문서 검토 등 을 통해 
 사용자의 요구 분석을 함
2) 평가와 종합추출된 요구사항에 대한 정보를 평가하고 여러 가지 해결책을 종합함
3) 모델 제작평가와 종합을 바탕으로 자료와 제어의 흐름, 기능 처리, 동작 행위, 정보 내용 등을 이해
 하기 쉽도록 모델을 작성
4) 문서화 검토요구사항 분석 명세서를 작성하고, 소프트웨어의 기능, 성능, 제약 조건 등 에 대하여 
 기술하고 검토함
(3) 요구사항 분석의 어려움 
1) 사용자의 요구사항이 모호하고, 부정확하며, 불완전함
2) 개발자와 사용자 간의 지식이나 표현의 차이가 커서 상호 이해가 쉽지 않음
3) 개발하고자 하는 시스템 자체가 복잡함
(4) 요구사항 분석가의 자질 
1) 요구사항 분석가(Analyst)요구사항을 효율적으로 분석하고 정확한 명세화 작업을 하는 사람
2) 요구사항 분석가가 갖추어야 할 능력
① 추상적인 개념을 파악하여 논리적인 구성요소로 분해할 수 있는 능력
② 서로 상반되고 모호한 정보로부터 필요한 사항을 수렴할 수 있는 능력
③ 관련된 하드웨어와 소프트웨어에 관한 최신 기술
④ 거시적 관점에서 세부적인 요소를 관찰할 수 있는 능력
(5) 구조적 분석 도구
1) 구조적 분석 기법은 자료의 흐름과 처리를 중심으로 하는 요구사항 분석 방법
2) 구조적 분석 도구 종류 : 자료 흐름도, 자료 사전, 소단위 명세서, 개체 관계도 등
3) 자료 흐름도 (DFD, Data Flow Diagram) 
① 자료 흐름도 : 요구사항 분석에서 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법
② 자료 흐름도의 구성 요소 표기법 : 자료 흐름도의 구성 요소 프로세스(Process), 
 자료 흐름(Data Flow), 자료 저장소(Data Store), 단말(Terminator)
• 표기법

③ 기본 DFD의 특성
 • 시스템 내의 모든 자료 흐름은 4가지의 기본 기호로 표시됨
 • 각각의 변환(처리)에 대하여 개별적인 상세화가 가능함
 • 변환(처리) 과정이 버블로 표현됨
④ 자료 흐름도를 작성하는데 지침이 되는 항목 
 • 어떤 처리(Process)가 출력자료를 산출하기 위해서는 반드시 입력자료가 발생해야 함
 • 자료흐름은 처리(Process)를 거쳐 변환될 때마다 새로운 이름을 부여함
 • 처리(Process)와 하위 자료흐름도의 자료 흐름은 서로 일치해야 함
 ⑤ 자료 흐름도의 예

 

4) 자료 사전 (DD, Data Dictionary)
① 자료 사전
 • 자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것
 • 데이터를 데이터의 데이터 또는 메타 데이터(Meta Data)라고도 함 
③ 기출 문제 풀이 - 다음 내용을 자료 사전의 형태로 표기하시오.

 

고객명세는 고객성명, 고객번호, 고객주소로 구성되어 있으며, 고객성명과 고객번호는 
 둘 중 하나만 선택이 가능함
 고객명세 = [고객성명|고객번호] + 고객주소

 

5) 소단위 명세서 (Mini-Specification) 
① 소단위 명세서
 • 세분화된 자료 흐름도에서 최하위 단계 버블(프로세스)의 처리 절차를 기술한 것
 • 프로세스 명세서라고도 함
② 특징
 • 반 페이지나 한 페이지 정도의 크기로 세분된 모듈을 작성할 때 사용
 • DFD에서는 한 개의 처리 공정이 그 대상이 되지만, 한 공정의 기능이 두 가지 이상

 

이거나 세분화함으로써 소단위 명세서를 이해하기가 쉬워진다면 더욱 세분화될 수 도 있음
• 소단위 명세서는 구조적 언어를 사용하고, 작성하는 도구에는 서술 문장, 의사 결정 나무, 
 의사 결정표, 표, 그래프 등이 있음
6) 개체 관계도 (ERD, Entity Relationship Diagram)
① 개체 관계도(ERD) 데이터 구조들과 그들 간의 관계들을 표현하기 위해 사용됨
② 개체 관계도의 작성 순서 
 • 주요키를 포함하여 개체(Entity)의 속성을 모두 찾아냄
 • 기본적인 개체(Entity)와 주요키를 정의하며, 개체(Entity) 사이의 관계를 정의함
 • 1:M 관계를 단순화하기 위해 속성 개체(Entity)를 추가하며, 연관 관계를 정의하여 M:N 관계를 표현함
 • 각 개체(Entity)를 정규화, 누락된 개체(Entity) 점검 및 클래스 구조가 필요한지 결정함
(6) 자동화 분석 도구
1) 자동화 분석 도구요구사항을 자동으로 분석하고, 요구사항 분석 명세서를 기술하도록 개발된 도구
2) 자동화 분석 도구 종류 
① SREM : TRW사가 우주 국방 시스템 그룹에 의해 실시간 처리 소프트웨어 시스템에서 요구
 사항을 명확히 기술하도록 할 목적으로 개발
② PSL/PSA : 미시간 대학에서 개발한 것으로 PSL과 PSA를 사용하는 자동화 도구
③ EPOS
(7) HIPO
1) HIPO (Hierarchy Input Process Output) 
① HIPO 다이어그램은 분석 및 설계 도구로서 사용됨
② 시스템의 분석 및 설계나 문서화할 때 사용되는 기법이며, 기본 시스템 모델은 입력, 처리, 
 출력으로 구성됨
③ 기능과 자료의 의존 관계를 동시에 표현할 수 있음
④ 구조도, 개요 도표 집합, 상세 도표 집합으로 구성됨
⑤ 보기 쉽고 이해하기 쉬움
2) HIPO의 종류
① 가시적 도표 (Visual Table of Contents, 도식 목차) 
 시스템의 전체적인 기능과 흐름을 보여주는 계층(Tree) 구조도
② 총체적 다이어그램 (Overview Diagram, 총괄도표ㆍ개요 도표) 
 프로그램을 구성하는 기능을 기술한 것으로 입력, 처리, 출력을 기술
③ 세부적 다이어그램 (Detail Diagram, 상세 도표)
 총체적 도표에 표시된 기능을 구성하는 기본 요소들을 상세히 기술하는 도표
3. 설계
(1) 설계 (Design)
1) 요구사항 분석 단계의 산출물인 요구사항 분석 명세서의 기능이 실현되도록 알고리즘과 그 알고리즘
 에 의해 처리될 자료 구조를 문서화 하는 것
2) 소프트웨어 설계 모형
① 구성: 데이터 설계 - 아키텍처 설계 - 인터페이스 설계 - 절차 설계 
• 데이터 설계 : 요구사항 분석 단계에서 생성된 정보를 소프트웨어로 구현하는 데 
 필요한 자료 구조로 변환

 

아키텍처 설계 : 소프트웨어를 구성하는 모듈 간의 관계와 프로그램 구조를 정의
• 인터페이스 설계: 소프트웨어와 상호 작용하는 시스템, 사용자 등과 어떻게 통신하는지 기술
• 절차 설계: 모듈이 수행할 기능을 절차적 기술로 바꾸는 것
② 설계 모형의 구조도

3) 소프트웨어 설계에 사용되는 대표적인 3가지 추상화 기법 
① 제어추상화 : 제어의 정확한 메커니즘을 정의하지 않고 원하는 효과를 정하는 데 이용하는 방법
② 기능추상화 : 입력 자료를 출력자료로 변환하는 과정을 추상화하는 방법
③ 자료추상화 : 자료와 자료에 적용될 수 있는 기능을 함께 정의함으로써 자료 객체를 구성하는 방법
4) 프로그램 구조 (Program Structure)
① 소프트웨어의 구성 요소인 모듈의 계층적 구성을 나타내는 것으로, 제어 계층 구조라고도 함
② 프로그램의 순서, 선택, 반복과 같은 소프트웨어의 절차적인 처리 과정을 나타내지 않음
③ 프로그램 구조는 일반적으로 트리 구조의 다이어그램으로 표기(사각형은 모듈을 나타냄)

 

 

⑤ 기출문제 풀이 다음은 프로그램 구조를 나타낸다. 모듈 F에서의 Fan-In과 Fan-Out의 수는 얼마인가?

5) 바람직한 설계의 특징(=좋은 설계에 대한 기준) 
① 설계는 모듈적이어야 함 (독립적인 기능적 특성을 가진 요소(모듈)로 구성되어야 함)
② 설계는 자료와 프로시저에 대한 분명하고 분리된 표현을 포함해야 함
③ 소프트웨어 요소(모듈)들 간의 효과적인 제어를 위해 설계에서 계층적 조직이 제시되어야 함
④ 소프트웨어는 논리적으로 특별한 기능과 부기능을 수행하는 요소들로 나누어져야 함
(2) 모듈화 (Modularity)
1) 모듈과 모듈화
① 모듈(Module) 
• 소프트웨어를 각 기능별로 분할한 것
• 소프트웨어 구조를 이루는 기본 단위
② 모듈화 (Modularity)
• 소프트웨어를 각 기능별로 분할하는 것
2) 모듈화 장점 : 융통성, 경제성, 확장성
3) 모듈의 기능적 독립성
① 소프트웨어를 구성하는 각 모듈의 기능이 독립됨을 의미
② 기능적으로 독립된 모듈은 특정 기능을 수행하고, 다른 모듈과는 간단한 인터페이스만을 
 가지므로 개발이 쉽고 재사용이 가능함
③ 독립성이 높은 모듈일수록 모듈을 수정하더라도 다른 모듈들에게는 거의 영향을 미치지 
 않으며, 오류가 발생해도 쉽게 발견할 수 있고 해결할 수 있음 
④ 모듈의 독립성은 결합도(Coupling)와 응집도(Cohesion)에 의해 측정되며, 독립성을 높이려면
 모듈의 결합도를 약하게 하고 응집도를 강하게 하며 모듈의 크기를 작게 만들어야 함
⑤ 결합도와 응집도는 소프트웨어 설계 시 평가 지침이 됨
4) 결합도 
① 결합도 (Coupling)
 • 두 모듈 간의 상호 의존도를 나타낸 것
 • 한 모듈과 다른 모듈 간의 상호 의존도 또는 두 모듈 사이의 연관 관계 
 • 독립적인 모듈이 되기 위해서는 각 모듈간의 결합도가 약해야 하며, 의존하는 모듈이 적어야 함

 

② 결합도의 종류 
 • 결합 정도에 따른 순서 

 

 데이터 결합도(Data Coupling) - 모듈간의 인터페이스가 자료 요소로만 구성된 경우
- 모듈이 파라미터나 인수로 다른 모듈에게 데이터를 넘겨주고, 호출받은 모듈은 받은 
 데이터에 대한 처리 결과를 다시 돌려주는 유형의 모듈 결합도
 • 스탬프 결합도(Stamp Coupling) - 두 모듈이 동일한 자료 구조를 조회하는 경우의 결합도
- 모듈 간의 인터페이스로 자료 구조(배열이나 레코드 등)가 전달된 경우
- 자료 구조의 어떠한 변화(포맷이나 구조의 변화)는 그것을 조회하는 모든 모듈 및 
 변화되는 필드를 실제로 조회하지 않는 모듈에까지 영향을 미치게 되는 결합도
 • 제어 결합도(Control Coupling)
 - 한 모듈에서 다른 모듈로 논리적인 흐름을 제어하는 데 사용되는 제어 요소가 전달될 때의 결합도
 • 외부 결합도(External Coupling)
 - 어떤 모듈에서 외부로 선언한 데이터(변수)를 다른 모듈에서 참조할 때의 결합도
 • 공통(공유) 결합도(Common Coupling) 
 - 한 모듈이 다른 모듈에게 제어 요소를 전달하고, 여러 모듈이 공통 자료 영역을 사용하는 경우
 • 내용 결합도(Content Coupling) 
 - 한 모듈이 다른 모듈의 내용(내부 기능 및 그 내부 자료)을 참조하는 경우 내용 결합이라고 함
 - 한 모듈이 다른 모듈의 일부분을 참조 또는 수정하는 경우
5) 응집도 
① 응집도(Cohesion) : 모듈 안의 요소들이 서로 관련되어 있는 정도
② 응집도의 종류
 • 응집 정도에 따른 순서 

기능적 응집도(Functional Cohesion) - 모듈 내부의 모든 기능 요소들이 단일 문제와 연관되어 수행될 경우의 응집도
• 순차적 응집도(Sequential Cohesion) - 한 모듈 내부의 한 기능 요소에 의한 출력 자료가 다음 기능 원소의 입력 자료로서 제공되는 형태
• 교환(통신)적 응집도(Communication Cohesion) - 동일한 입력과 출력을 사용하는 소작업들이 모인 모듈에서 볼 수 있음
• 절차적 응집도(Procedural Cohesion) - 모듈 내부의 요소들이 여러 관련 기능이 있을 경우 순차적으로 수행할 경우의 응집도

 

• 시간적 응집도(Temporal Cohesion)
 - 특정 시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 작성 할 경우의 응집도
• 논리적 응집도(Logical Cohesion) 
 - 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들로 하나의 모듈이 형성 되는 경우의 응집도
• 우연적 응집도(Coincidental Cohesion)
 - 모듈 내부의 각 구성 요소들이 서로 관련 없는 요소로만 구성된 경우의 응집도
6) 효과적인 모듈화 설계 방안 
① 응집도는 강하고, 결합도는 약해야 함. ② 복잡도와 중복을 피함
③ 모듈의 기능은 예측이 가능해야 하며 지나치게 제한적이어서는 안 됨
④ 유지보수가 용이해야 함
(3) 설계 방법
1) 데이터(자료) 설계
① 데이터 설계는 설계의 첫 번째 작업으로, 요구사항 분석에서 생성된 여러 모델 들을 소프트
 웨어를 구현하는 데 필요한 자료 구조로 변환하는 것
② 자료 구조가 프로그램 구조와 절차적 복잡성에 영향을 주므로 자료 설계는 소프트웨어 품질에
 큰 영향을 줌
2) 아키텍처(구조) 설계
① 아키텍처 설계는 프로그램의 구조를 개발하고, 소프트웨어 구성 요소들 간의 관계를 정의하는 것
② 구조적(자료 흐름 중심) 설계 절차 
• 정보 흐름의 유형을 설정
• 흐름의 경계를 표시
• 자료 흐름도를 프로그램 구조로 사상
• 제어 계층을 분해(Factoring)시켜서 정의 
• 경험적 방법으로 구체화
3) 인터페이스 설계
① 인터페이스 설계는 소프트웨어와 상호 작용하는 시스템, 사용자 등과 어떻게 통신하는 지를 기술하는 과정임
② 사용자 인터페이스 설계 시 오류 메시지나 경고에 관한 지침
• 메시지는 이해하기 쉬어야 함
• 오류로부터 회복을 위한 구체적인 설명이 제공되어야 함
• 소리나 색 등을 이용하여 듣거나 보기 쉽게 의미 전달을 하도록 해야 함
4) 절차(프로시저) 설계
① 절차(프로시저) 설계는 데이터 설계, 아키텍처 설계, 인터페이스 설계가 이루어진 후에 수
 행되는 설계 작업으로 모듈이 수행할 기능을 절차적 기술로 바꾸는 것
② 데이터 설계, 아키텍처 설계, 인터페이스 설계를 바탕으로 실제 운영되는 소프트웨어로 
 변환하기 위해 코드에 가까운 추상화 수준의 모듈 명세서를 작성하는 것
③ N-S 차트 (Nassi-Schneiderman Chart, 나씨-슈나이더만 도표)
• 구조적 프로그램을 표현하기 위해 고안됨
• 논리의 기술에 중점을 둔 도형식 표현 방법
• 조건이 복합되어 있는 곳의 처리를 시각적으로 명확히 식별하는 데 적합함
• 알고리즘의 제어 구조는 아래의 3가지로 충분히 표현될 수 있음 
 - 반복 (Repeat ~ until, While, for)

 

- 연속(순차) (Sequential) - 선택, 다중선택 (If ~ then ~ else, Case)
요점정리
1. 전통적 개발 방법론에 대한 개념을 정리합니다. 2. 요구사항 분석과정을 정리하고 이해합니다. 3, 설계과정의 전반적인 사항을 정리 합니다.
다음차시예고
수고하셨습니다. 다음 5주차에서는 “[SE-05강] 전통적 개발 방법론(구현, 검사, 유지, 보수)”에 대해서 학습하도
록 하겠습니다.