[정보처리기사 필기] 17일차 - 데이터베이스, 소프트웨어공학 내용 정리

♣ 진행사항 및 문제풀이 결과

 

1. 데이터베이스

구분	내용	출제경향	내점수	문제풀이결과			오답번호
1강	데이터베이스 정의	3 %			/
2강	DBMS, 스키마, 데이터언어, DBA	11 %			/
3강	DB설계, 데이터모델, ER모델	15 %			/
4강	논리적데이터모델, 관계형 DB	12 %			/
5강	관계대수, 관계해석, 정규화	8 %			/
6강	SQL, 뷰, 시스템카탈로그	16 %			/
7강	내장SQL, 고급데이터베이스	15 %			/
8강	자료구조(선형/비선형구조)	12 %			/
9강	자료구조(정렬/검색)	5 %			/
10강	자료구조(파일편성)	3 %			/

 

4. 소프트웨어공학
구분	내용	출제경향	내점수	문제풀이결과			오답번호
1강	소프트웨어공학, 생명주기	12 %			/
2강	프로젝트 관리	24 %			/
3강	구조적 개발 방법론	36 %			/
4강	객체지향 개발 방법론	15 %			/
5강	발전적 주제	13 %			/

 

 

♣ 중요 내용 정리

 

9강 - 자료구조( 정렬/ 검색/ 해싱 )

1. 정렬

: 오름차순 또는 내림차순으로 데이터를 나열

1) 내부정렬 : 주기억장치 사용

- 선택정렬(Selection sort), 버블정렬(Bubble sort), 삽입 정렬(Insertion sort), 힙정렬(Heap sort)

- shell sort, quick sort, 2-way merge sort, radix sort

2) 외부정렬 : 보조기억장치 사용

- 밸런스드 병합 정렬, 캐스케이드 병합 정렬

- 폴리파즈 병합 정렬, 오실레이팅 병합 정렬

 

2. 정렬 알고리즘 선택 시 고려사항

- 데이터 양

- 초기 데이터의 배열상태

- 키 값들의 분포상태

- 운영체제의 종류, 액세스 빈도, 증가 데이터의 배열 상태 (X) - 오답으로 자주 출제

 

3. 선택정렬 ( Selection Sort )

: 첫 자리부터 정렬하기 ( 비교, 교환 )

 

 

4. 버블정렬 ( Bubble Sort )

: 수면 위로 올라가는 물방울 (인접 데이터 비교)

 

 

 

 

5. 삽입정렬 ( Insertion Sort )

: 성적순으로 교실 자리 배치하기를 생각해 볼 것

 

6. 2-way 정렬

: 두 개씩 묶어서 정렬

 

 

1. 검색

1) 선형 검색 ( 순차검색 )

2) 이분(이진) 검색

- 자료가 정렬되어 있어야 함. 중간 값을 비교 검색, 많은 레코드 검색 시 효율적

3) 보간 검색

4) 트리검색, 블럭 검색, 피보나치 검색

2. 해싱(hashing) 검색

: 해싱 함수를 이용하여 자료를 검색하는 방법, 데이터를 해시 테이블이라는 배열에 저장하고,

해싱 함수를 이용하여 데이터가 위치한 곳의 주소를 찾는 키-주소 변환 방법

 

1) 특징

- DAM(직접접근, Direct Access Method) 파일을 구성할 때 해싱이 사용

- 삽입, 삭제 작업의 빈도가 많을 때 유리한 방식

- 검색은 가장 빠르지만 기억공간의 낭비가 발생

2) 용어 정리

- 해싱함수 : 해시 테이블의 주소를 생성해 내는 함수

- 해시테이블 : 해싱 함수에 의하여 참조되는 테이블

- 버킷 ( bucket ) : 하나의 주소를 갖는 파일의 한 구역

- 슬롯 ( slot ) : n개의 슬록이 모여 하나의 버킷을 형성

- 충돌 ( Collision ) : 서로 다른 2개 이상의 레코드가 같은 주소를 갖는 현상

- 시노임 ( Synonym ) : 같은 주소를 갖는 레코드의 집합

- 오버플로 : 버킷 내에 기억 공간이 없는 현상

 

 

10강 - 자료구조 (파일편성, 인덱스)

1. 순차파일 (SAM : Sequential Access Method ) : 목차 없는 책

: 파일 내의 각 레코드를 논리적 순서에 따라 물리적으로 연속된 위치에 기록한 파일

- 기억장소의 낭비가 없다.

- 색인 순차파일에 비해 삽입, 삭제, 검색이 어렵다.

 

2. 색인순차파일 ( ISAM : Index Sequential Access Method ) : 목차 있는 책 (정적 인덱스)

: 인덱스를 통한 랜덤 처리와 데이터이 순차 처리를 병행할 수 있는 파일

- 삽입, 삭제, 갱신, 검색 용이

- 삽입시 기본 영역에 추가 공간이 없을 경우 오버플로 영역에 저장

- 재사용이 안되므로 삽입, 삭제가 빈번할 경우 기억공간 낭비 발생하므로 재구성필요

: 색인영역(Index : 트랙,실린더,마스터 색인), 기본영역(Prime), 오버플로영역으로 구성

 

3. 직접파일 ( DAM : Direct Access Method )

: 해싱함수를 계산해서 물리적 주소를 직접 접근 (대화형 처리 가능)

- 순서에 관계없이 저장

- 레코드 주소의 변환과정의 시간 소요

- 기억공간 효율 저하

 

4. VSAM ( Virtual : 동적 인덱스 )

: 동적 인덱스 방법을 이용한 색인 순차 파일

- 기본 구역과 오버플로우 구역을 구분하지 않음

( 레코드 삭제 시 그 공간을 재사용 할 수 있음 )

- 제어 구간에 가변 길이 레코드를 쉽게 수용할 수 있음

 

5. 역 파일 : 찾아보기 기능

: 특정파일을 여러 개의 색인으로 만들어 항목별 특성에 맞게 작업하도록 구성

- 질의 응답 시간 단축되고 처리가 쉽다.

- 색인의 각 항목의 길이가 가변

 

6. 인덱스

- 데이블의 레코드에 대한 액세스를 빠르게 수행

- 하나 이상의 필드로 만들어도 된다.

- 레코드의 삽입과 삭제가 수시로 일어나는 경우는 인덱스를 최대화한다.

 

 

SE 1강 - 소프트웨어공학, 생명주기

 

* 주요키워드

1. 소프트웨어공학, 소프트웨어 위기

2. 소프트웨어 생명 주기

- 폭포수 모델

- 프로토타입 모형

- 나선형 모델

 

1. 소프트웨어 공학 (Software Engineering ) 이해하기

- 정의 : 가장 경제적으로 신뢰도 높은 S/W를 만들기 위한 방법, 도구와 절차들의 체계화 한 학문

 

- S/W 개발 절차

: 요구 분석 -> 설계 -> 구현(코딩) -> 테스트(시험) -> 유지보수

1) 요구분석 : 무엇을 만들까? -> 분석도구

2) 설계 : 구체적인 기능과 구조를 어떻게 할지 체계화 -> 설계기법

3) 구현 : 프로그램 언어를 선정하고, 설계 명세서를 컴퓨터가 이해할 수 있도록 표현

-> 프로그램 언어 선정 기준, 코딩 표준화

4) 테스트 : 요구 사항에 맞게 작동하는가? -> 테스트 기법

5) 유지보수 : 버전 업데이트 및 새로운 기능 추가 ( S/W 개발 비용 70% 차지 )

-> 유지보수과정(유지보수요구 -> 현시스템 이해 -> 수정, 테스트)

 

2. 소프트웨어 위기

- 정의 : 소프트웨서 개발 속도가 하드웨어 개발 속도를 따라가지 못해 소프트웨어에 대한 사용자들의

요구사항을 처리할 수 없는 문제가 발생함을 의미

-> 소프트웨어 공학이 나타나게 된 배경

 

- 위기의 결과

: 개발인력의 부족 -> 인건비 상승 -> 개발기간 지연 및 개발 비용 증가

: 성능 및 신뢰성 부족 -> 품질 저하

: 유지보수의 어려움

 

- 좋은 소프트웨어의 조건

: 남이 알아보기 쉬워야 한다.

: 경제적, 문서화가 잘 되어 있어야 한다.

: 독창적이면 오히려 더 안좋다

 

- 소프트웨어 공학의 기본 원칙

: 현대적인 프로그래밍 기술 적용

: 지속적인 검증 시행

: 결과에 대한 명확한 기록 유지

: 필요한 적정인력 투입

 

1. 소프트웨어 생명 주기

- 정의 : 소프트웨어를 개발하기 위해 정의, 개발, 유지보수 과정을 각 단계별로 나눈 것

( 폭포수 모형, 프로토타입, 나선형 모형, 4GT )

 

- 소프트웨어 생명 주기 단계

1) 정의단계 : 타당성 검토 단계, 계획 단계, 요구사항분석 단계

2) 개발단계 : 설계 단계, 구현 단계, 테스트 단계

3) 유지보수단계 : 가장 비용이 많이 요구되는 단계

 

- 역할

: 프로젝트 비용산정과 개발 계획수립의 기본 골격

: 프로젝트 진행방향을 명백히 한다.

: 용어, 기술의 표준화 가능 -> 일관성 유지

: 문서화가 충실한 프로젝트 관리 용이

: 단계별 종료 시점은 변동될 수 있음 (불명확)

 

2. 폭포수 모형 : 순차적(고정) -> 요구분석 불만족

1) 개발단계

: 타당성검토 - 계획 - 요구분석 - 설계 - 구현 - 시험 - 운용 - 유지보수

 

2) 특징

- 가장 오래되고 폭넓게 사용된 전통적인 소프트웨어 생명주기

- 물이 위에서 아래로 떨어지듯이 단계가 순차적으로 진행되고 단계별 정의가 분명

- 두 개 이상의 과정이 병행수행되거나 이전 단계로 넘어가는 경우가 없음

- 개발 과정 중에 발생하는 새로운 요구나 경험을 설계에 반영하기 어려움 ( 요구사항 변경 X )

- 제품의 일부가 될 메뉴얼 작성 필요

- 각 단계가 끝난 후 결과물이 명확히 나옴

 

* 사용자의 요구사항 분석 작업이 어려운 이유

- 개발자와 사용자간의 지식이나 표현의 차이가 커서 상호 이해가 쉽지 않다.

- 사용자의 요구사항이 모호하고 부정확하며, 불완전하다.

- 개발하고자 하는 시스템 자체가 복잡하다.

 

3. 프로토타입 모형 : 모형(가변) -> 요구분석 만족

* 개념 : 모델하우스를 고객에세 보여주고 요구에 맞도록 건물을 시공한다.

 

1) 정의 : 시스템의 일부 혹은 시스템의 모형을 만드는 과정으로서 요구된 소프트웨어의 일부를 구현하며,

추후 구현단계에 사용될 골격코드가 되는 모형

 

2) 개발 단계

: 요구수집 - 빠른 설계 - 프로토타입 구축 - 고객평가 - 프로토타입 조정 - 구현

 

3) 특징

- 실제 상황이 나오기 전에 가상으로 시뮬레이션을 통해 최종 결과물에 대한 예측을 할 수 있음

- 개발 단계에서 오류 수정을 할 수 있음

- 요구사항을 충실히 반영

- 실제 개발된 시스템 견본을 미리 만들어 최종 결과물을 예측하는 모형 -> 비용 증가

 

4. 나선형 모형 : 폭포수 장점 + 프로토타입 장점

1) 개발 단계

: Planning - Risk Analysis - Engineering - Customer Evaluation 의 과정을 반복

 

2) 특징

- 점증적 생명주기 모델

- 위험분석 단계에 초점

- Boehm(보헴) 제안

- 비용이 많이 들고 시간이 많이 소요되지만 완성도 높으므로 대규모 프로젝트에 유리

- 개발 단계에서 유지보수 (X)

 

5. 4GT ( 4th Generation Techniques ) : 4세대 기법

1) 개발 단계

: 요구사항 분석 - 설계, 구현 - 제품화

 

2) 특징

- 4세대 언어(비주얼베이직) 이용 -> 원시 코드를 자동으로 생성

- 설계 단계 단축 - 개발 시간 감소(소규모 개발 시 효율적)

 

SE 2강 - 프로젝트 관리

 

1. 프로젝트 관리 : 계획대로 완료될 수 있도록 관리

- 목적 : 주어진 기간 내에 최소의 비용으로 사용자를 만족시키는 시스템 개발

 

- 관리 대상 : 계획, 개발팀 관리, 비용 관리, 일정 관리, 위험 관리, 형상 관리, 품질 관리

 

- 효과적인 프로젝트 관리를 위한 3대 요소 ( 3P )

1) 사람 ( People ) : 인적자원

2) 문제 ( Problem ) : 문제 인식

3) 프로세스 ( Process ) : 작업 계획

 

1.1 프로젝트 계획 : 수행 전 예측하는 작업

- 프로젝트가 수행되기 전에 소프트웨어 개발영역(범위) 결정, 필요한 자원, 비용, 일정 등을 예측

 

1) 프로젝트 계획 수립 시 예측 대상

- 범위, 비용, 일정, 성능

 

2) 프로젝트 계획 수립 시 소프트웨어 영역 결정 사항

- 기능, 성능, 제한조건, 신뢰도

 

1.2 개발팀 관리

 

1) 중앙 집중형 ( 책임프로그래머 팀 ) : 한 사람에 의하여 통제 -> 소규모 프로젝트 적합

- 책임프로그래머 : 분석, 설계, 작업 지시 등 모든 기술적 판단

- 보조프로그래머 : 책임 프로그래머 업무 지원

- 프로그래머 : 코딩, 검사, 디버깅, 문서작성 등

- 프로그램 사서 : 프로그램 리스트, 설계 문서, 검사 계획 등

 

2) 분산형 ( 민주주의식 ) : 링 모양 구조

- 모든 팀 구성원이 동등한 위치에서 의사 결정 -> 장기 프로젝트 적합

- 서로의 일을 검토하고 결과에 대해 같은 그룹의 일원으로 책임짐

- 의사 교류를 활성화 -> 구성원의 작업 만족도 증대

 

1.3 비용 관리

 

1) 비용 결정 요소

- 개발자의 능력, 요구되는 신뢰도, 개발 제품의 복잡도

- 하드웨어 성능은 결정 대상이 아니다

 

2) 비용을 정확하게 예측하기 위한 방법

- 예측을 가능한 한 뒤로 미룸 ( 현실성 X )

- 이미 수행된 유사 프로젝트 참고

- 프로젝트를 상대적으로 잘게 분리하여 항목별로 예측

- 경험적 예측 모델을 활용 : 실험에 의한 결과 활용

 

3) 개발 비용과 개발기간 상관 관계

- 반비례 관계 : 개발완료기간을 앞당기면 비용은 더 증가

 

1.3.1 비용 예측 기법 > LOC ( Line Of Code ) 기법

 

1) 용어 정리

- LOC : Line Of Code ( 원시코드 라인 수 )

- 인월 (=PM, =MM) : 개발에 소요되는 기간을 1개월로 고정할 경우 필요한 총 인원수

 

1.3.2 비용 예측 모형 > COCOMO 모형

 

1) 특징

- Bohehm이 제안한 원시 프로그램의 규모에 의한 비용 예측 모형

- 소프트웨어의 종류에 따라 다르게 책정되는 비용신장 방정식을 이용

- 같은 규모의 프로그램이라도 그 성격에 따라 비용이 다르게 생성

- 비용 견적의 강도 분석 및 비용견적의 유연성이 높아 소프트웨어 개발비 견적에 널리 통용

 

2) COCOMO 모형

- 기본형 ( Basic COCOMO )

- 중간형 ( Intermediate COCOMO )

- 진보형 ( Detailed COCOMO )

 

3) COCOMO 유형(모드) : 기본 모형은 단순히 소프트웨어의 크기와 개발 모드에 의해서 구해진다

- 유기형 ( Organic 프로젝트 ) : 5만 라인 이하 규모 ( 일괄처리, 과학 기술 계산용 등 )

- 반분리형 ( Semi-Detached 프로젝트 ) : 30만 라인 이하 규모 ( 운영체제 등 )

- 내장형 ( Embedded 프로젝트 ) : 30만 라인 이상의 최대형 규모 ( 운영체제 등 )

 

4) 기타 비용 예측(추정) 모형

- Putnam 모형, Fuction-Point 모형

 

1.4 일정 관리

 

1) 프로젝트 일정 계획 기법 : WBS(작업분해), PERT/CPM, Gantt Chart

 

2) 브룩스(Brooks) 법칙

- 새로운 개발 인력이 진행 중인 프로젝트에 투입될 경우 작업 적응 기간과 부작용으로 인해

빠른시간 내에 프로젝트는 완료될 수 없다.

 

3) 일정 계획의 순서

: 프로젝트 규모 추정 - 소단위 작업 분해 - CPM 네트워크 표현 - Gantt Chart 표현

 

1.4.1 작업 분해

: 프로젝트를 여러 개의 작은 소단위로 분해하여 계층 구조로 표현

 

1.4.2 PERT/ CPM 특징

- CPM ( Critical Path Method, 임계 경로 기법 )

: 임계경로 - 가장 오래 걸리는 경로

- 프로젝트의 지연을 방지하고 계획대로 진행되게 하기 위한 일정 계획 방법

- 대단위 계획의 조직적인 추진을 위해 자원의 제약 하에 비용을 적게 사용하면서 초단기간 내 계획 완성을

위한 프로젝트 일정 방법

- 병행작업이 가능하도록 계획할 수 있음

- 노드에서 작업을 표시하고 간선은 작업 사이의 전후 의존 관계를 나타냄

- 프로젝트 완성에 필요한 작업을 나열하고 작업에 필요한 소요기간을 예측하는 데 사용

- 박스 노드는 프로젝트 중간 점검을 뜻하는 이정표로 이 노드 위에는 예상 완료 시간을 표시

- 프로젝트 작업 사이의 관계를 나타내며 최장경로(임계경로)를 파악할 수 있음

 

1.4.3 Gantt Chart

 

- 포함되는 내용 : 이정표, 작업 일정, 작업 기간, 산출물

 

1.5 품질 관리

 

1) 품질 보증 : 어떤 항목이나 제품이 설정된 기술적 요구사항과 일치하는가를 적절하게 확인하는데 필요한

체계적이고도 계획적인 유형의 활동

 

2) 품질 목표의 항목

- 정확성 : 사용자 요구 기능 충족 정도

- 신뢰성 : 옳고 일관된 결과를 얻기 위해 요구되는 기능

- 이식성 : 다른 하드웨어 환경에서 운용 가능

- 상호 운용성 : 다른 소프트웨어와 정보를 교환할 수 있는 기능

- 유지보수성 : 변경 시 수정에 대한 노력의 최소화 정도

- 효율성 : 기능 수행 시 필요한 자원의 소요 정도

- 무결성 : 허용되지 않는 사용이나 자료의 변경을 제어

- 사용 용이성 : 사용하기 쉬운 정도

- 유연성 : 쉽게 수정할 수 있는 정도

- 시험 용이성 : 평가를 쉽게 해주는 정도

- 재사용성 : 전체나 일부 소프트웨어가 다른 응용 목적으로 사용 가능

- 종속성, 중복성, 복잡성, 최적화 등은 목표 항목이 아님!

 

1.5.1 품질관리 위원회

: 소프트웨어 품질 향상을 목적으로 구성

 

1) 정형 기술 검토 ( FTR : Formal Technical Review )

- 가장 일반적인 검토방법으로 소프트웨어 품질 보증 활동

- 목적 : 기능과 로직의 오류 발견, 사용자 요구사항의 확인, 프로젝트 관리의 편리성 등

- 지침 사항 : 의제 제한성, 논쟁과 반박의 제한성, 제품 검토의 집중성, 참가 인원의 제한성

 

2) 워크스루 ( Walkthrough )

- 각 단계가 끝나면 검토 회의

- 오류 검출에 초점을 두고 해결책은 나중으로 미룬다.

- 발견된 오류는 문서화

- 검토를 위한 자료를 사전에 배포하여 검토

 

1.5.2 신뢰성(가용성) 측정

 

1.6 위험 관리

- 프로젝트 추진 과정에서 예상되는 각종 돌발 상황을 미리 예상하고 이에 대한 적절한 대책을 수립하는 행동

 

1) 위험 관리 절차

: 위험식별 - 위험 분석 및 평가 (위험표 작성) - 위험 관리 계획 - 위험 감시 및 조치

 

2) 위험표에 포함될 사항

- 위험내용, 위험 종류, 위험 발생 확률, 위험에 따른 영향력, 위험 감시 및 조치

 

3) 위험 요소 : 사용자 요구 사항 변경 ( 가장 대표적 ), 인력 부족, 예산 부족

 

4) 위험 모니터링 ( monitoring ) : 위험 요소 징후들에 대하여 계속적으로 인지하는 것

 

1.7 형상 관리

 

1) 형상 정의 : 소프트웨어 개발 단계의 각 과정에서 만들어지는 프로그램, 문서, 데이터 등을 통칭

 

2) 형상 관리 : 소프트웨어 생산물을 확인하고 소프트웨어 통제, 변경 상태를 기록하고 보관하는 일련의 작업

: 유지보수단계에서 실행

 

3) 형상 관리 항목 : 정의단계의 문서, 개발 단계의 문서와 프로그램, 유지보수 단계의 변경 사항

 

SE 3강 - 구조적 개발 방법론

소프트웨어 개발 방법론

: 과거 경험을 토대로 성공적으로 평가되는 소프트웨어를 분석 및 설계방법들을 모아 하나의 개발 방법으로

정형화 한 것

: 구조적 개발 방법론, 객체 지향 개발 방법론

 

1. 구조적 개발 방법론

- 개발 순서 : 요구사항 분석 - 설계 - 구현 - 검사 - 디버깅 - 유지보수

 

1.1 요구사항 분석

 

1) 요구사항 분석 기법 : 사용자 면접, 현재 사용 중인 문서 검토, 설문 조사를 통한 의견 수렴

 

2) 분석가가 갖추어야 할 가장 중요한 능력

: 거시적 관점에서 세부적인 요소를 관찰할 수 있는 능력 ( 가장 중요 )

 

3) 구조적 분석 기법 ( 도구 )

- 자료의 흐름과 처리를 중심으로 하는 요구사항 분석 방법

- 종류 : 자료 흐름도, 자료 사전, 소단위 명세서, 개체 관계도, 상태 전이도

 

1,1,1 자료흐름도 ( DFD : Data Flow Diagram )

 

2) 특징

- 시스템내의 모든 자료 흐름은 4가지의 기본 기호로 표시된다.

- 각 각의 변환(처리)에 대하여 개별적인 상세화가 가능하다.

- 자료는 처리를 거쳐 변환될 때마다 새로운 명칭을 부여해야 한다.

- 자료흐름도의 최하위 처리는 소단위명세서를 갖는다.

- 어떤 처리가 출력자료를 산출하기 위해서는 필요한 자료가 반드시 입력되어야 한다.

- 상위단계의 처리와 하위 자료흐름도의 자료 흐름은 서로 일치돼야 한다.

- Bubble Chart 라고도 부른다

 

1.1.2 자료사전 ( DD : Data Dictionary )

 

1) 특징

- DFD에 있는 자료를 더 자세히 정의하고 기록한 것

- 데이터를 설명하는 데이터 (메타 데이터)

 

 

 

1.1.3 HIPO ( Hirarchy Input Process Output )

 

1) 특징

- 분석, 설계, 문서화에 사용되는 도구이며, 기본 시스템 모델은 입력, 처리, 출력으로 구성됨

- 하향식 소프트웨어 개발을 위한 문서화 도구로서 이해하기 쉬움

- 변경, 유지보수 용이

 

2) HIPO 종류

- 가시적 도표 (Visual Table of Contents) = 구조도

: 시스템 전체적인 기능과 흐름을 보여주는 계층 구조도

- 총체적 다이어그램 (Overview Diagram) = 개요도표집합

: 입력, 처리, 출력에 대한 전반적인 정보를 제공하는 도표

- 세부적 다이어그램 (Detail Diagram) = 상세 도표 집합

: 총체적 다이어그램을 상세 기술하는 도표

 

1.2 구조적 설계

 

 

3) 설계의 기본 원리

- 모듈화 : 소프트웨어를 모듈 단위로 나누는 것 (작업 단위, 소프트웨어 내의 프로그램, 부시스템)

- 추상화 : 전체적이고 포괄적인 개념을 설계한 후 세분화 구체화 시켜나가는 방법

: 종류 - 기능추상화, 제어추상화, 자료추상화

- 정보은닉 : 모듈 내부에 포함된 절차와 자료들의 정보를 숨겨 다른 모듈의 접근 및 변경을 막는 기법

- 구조화

: 공유도 ( Fan-In ) : 어떤 모듈을 제어(호출)하는 상위 모듈의 개수

: 제어도( Fan-Out ) : 어떤 모듈에 의해 제어(호출)되는 하위 모듈의 개수

 

4) 좋은 설계 기준

- 설계는 모듈적이어야 함

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

- 소프트웨어는 논리적으로 특별한 기능과 부기능을 수행하는 요소들로 나누어져야 한다.

- 소프트웨어 요소들간의 효과적인 제어를 위해 설계에서 계층적 조직이 제시되어야 함

 

5) 자료 흐름 중심 설계

- 정보흐름의 유형 설정 ( 데이터 설계 )

- 흐름의 경계를 표시

- 자료흐름도를 프로그램 구조로 사상 ( 구조 설계 )

- 제어 계층을 분해시켜서 정의 ( 절차 설계 )

- 경험적 방법으로 구체화

 

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

- 절차 설계 기법

- 논리의 기술에 중점을 둔 도형을 이용한 표현방법으로 박스 다이어그램이라고 함

- 순차(Sequence), 선택 및 다중 선택(If~then~else, Case), 반복(Repeat ~ until, While, for)등의 제어논리구조를 표현

 

1.2.2 모듈화

 

1) 모듈화 목적

- 소프트웨어 복잡도가 감소하고, 변경이 쉬우며 프로그램 구현이 용이

 

2) 결합도 ( Coupling ) : 모듈 간에 상호 의존도

- 독립적인 모듈이 되기 위해서는 결합도가 약해야 함

- 종류 : 데이터 < 스탬프 < 제어 < 외부 < 공통 < 내용

(1) 데이터결합도 (Data) : 데이터 요소(파라미터,인수,매개변수)로만 구성된 경우

(2) 스탬프결합도 (Stamp) : 배열이나 레코드 등의 자료구조가 전달될 경우

(3) 제어결합도 (Control) : 제어 요소가 전달된 경우

(4) 외부결합도 (External) : 외부로 선언한 데이터(변수)를 참조할 경우

(5) 공동결합도 (Common) : 공통 데이터 영역을 사용할 경우

(6) 내용결합도 (Content) : 내부 기능 및 내부 자료를 참조할 경우

 

3) 응집도 ( Cohesion ) : 모듈 안의 요소들이 서로 관련되어 있는 정도

- 모듈이 독립적인 기능으로 잘 정의되어 있는 정도

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

- 종류 : 우연적 < 논리적 < 시간적 < 절차적 < 교환적 < 순차적 < 기능적

(1) 우연적응집도 (Coincidental) : 서로 관련 없는 요소로만 구성

(2) 논리적응집도 (Logical) : 유사한 성격 또는 처리 요소들로 구성

(3) 시간적응집도 (Temporal) : 특정 시간에 처리되는 몇 개의 기능을 모아 구성

(4) 절차적응집도 (Procedural) : 구성 요소들이 그 기능을 순차적으로 수행할 경우

(5) 교환적응집도 (Communication) : 동일한 입력과 출력을 사용하여 서로 다른 기능을 수행하는

구성요소들이 모였을 경우

(6) 순환적, 순차적 응집도(Sequential) : 출력데이터를 그 다음 활동의 입력 데이터로 사용할경우

(7) 기능적응집도 (Functional) : 단일 문제와 연관되어 수행될 경우

 

1.3 구현

 

1) 정의 : 설계단계에서 생성된 내용을 컴퓨터가 알 수 있는 형태로 변환하는 과정 (코딩)

 

2) 프로그램 언어 선택 기준

- 대상 업무 성격, 개발 담당자의 경험과 지식, 과거의 개발 실적 등

 

3) 구조적 프로그래밍 : 컴퓨터 프로그램을 여러 갈래로 분기하여 복잡하게 하지 않고, 순서대로, 선택적으로

반복문장을 사용하는 제어구조만을 사용한 프로그램 ( Dijkstra 제안 )

 

1.4 검사 ( Test )

 

1) 소프트웨어 품질 보증 활동의 하나로써 오류를 발견하기 위하여 프로그램 수행하는 과정

 

2) 검사기법

(1) 화이트 박스 테스트 : 구조 테스트

- 모듈안의 작동을 자세히 관찰할 수 있으며, 프로그램 원시 코드의 논리적인 구조를 커버하도록

테스트 케이스를 설계하는 프로그램 테스트 방법

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

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

- 원시 코드의 모든 문장을 한 번 이상 수행함

- 종류

: 기초 경로 검사 ( Basic Path Testing ) - McCabe 제안

: 조건 검사 ( Condition Testing )

: 루프 검사 ( Loop Testing )

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

 

(2) 블랙 박스 테스트 : 기능 테스트

- 소프트웨어가 수행할 특정기능을 알기 위해서 각 기능이 완전히 작동되는 것을 입증하기 위한 검사

- 발견할 수 있는 오류 : 성능, 부정확한 기능, 인터페이스 오류

- 종류

: 등치분할검사 ( Equivalence Partitioning )

: 경계값 분석 ( Boundary Value Analysis )

: 원인-효과 그래프 검사 ( Cause-Effect Graphing Testing )

: 오류예측검사 ( Fault based Testing )

: 비교검사 ( Comparison Testing )

 

1.4.1 검사전략

 

* 검사 순서 : 단위(코드) - 통합(설계) - 검증(요구사항) - 시스템

 

1) 단위 검사 : 모듈에 대한 검사 ( 화이트 박스 테스트 기법 사용 )

 

2) 통합 검사 : 모듈들을 결합하여 검사

(1) 하향식 : 상위 모듈에서 하위 모듈 방향으로 통합하면서 검사하는 기법

- stub 필요 : 모듈간에 통합시험을 하기 위해 일시적으로 제공되는 시험용 모듈

(2) 상향식 : 하위 모듈에서 상위 모듈방향으로 통합하면서 검사하는 기법

: 절차

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

- 드라이버라는 제어 프로그램 작성

- 클러스터 검사

- 드라이버 제거하고 클러스터를 상위로 결합

3) 검증 검사 : 요구사항을 충족하는지 검사 ( 블랙 박스 테스트 기법 사용 )

(1) 형상 검사

(2) 알파 검사 : 개발자의 장소에서 사용자가 시험하고 개발자는 뒤에서 결과를 지켜보는 검사

(3) 베타 검사 : 실업무를 가지고 사용자가 직접 시험하는 검사

 

 

1.5 디버깅

- 오류 수정 과정 ( 검사 기법 X )

- 성공적인 테스팅의 결과로 발생

- 징후로부터 원인을 찾아 수정하는 과정

- 심리적인 요소가 많이 관여하기 때문에 힘듦

- 접근법 : 맹목적 강요, 역추적, 원인 제거

 

1.6 유지 보수

: 가장 많은 비용이 투입되는 단계로써 인수, 설치된 후 발생하는 모든 공학적 작업

 

1) 유지보수 활동

- 수정보수 ( Corrective ) : 오류 수정

- 적응보수 ( Adaptive ) : 환경변화 반영

- 완전화 보수, 기능 보수 (Perfective) : 기능개선, 가장 큰 비중 차지

- 예방보수 ( Preventive )

 

2) 유지보수 비용 계산식 ( M= P+Ke^(c-d))

- P : 생산적인 활동에 드는 비용

- K : 통계값에서 구한 상수

- c : 복잡도

- d : 지식의 정도

 

3) 외계인 코드

- 아주 오래되어 유지보수 작업이 어려운 프로그램 ( 방지법 : 문서화 )

 

4) 유지보수 부작용

- 코딩 부작용 : 코딩 내용 변경에 따른 문제

- 자료 부작용 : 자료 구조 변경에 따른 문제

- 문서화 부작용 : 변경에 대한 내용이 문서에 적용되지 않을 경우

 

 

SE 4강 - 객체지향 개발 방법론

 

1. 구조적 개발 VS 객체지향 개발

1) 구조적 개발

- 장점 : 구조 단순 - 이해, 수정하기 쉽고 정확하다

- 단점 : 소프트웨어 재사용, 유지보수 어렵다 -> 소프트웨어 위기 해결 안됨

 

2) 객체지향 개발

- 장점 : 현실 세계를 프로그램에 반영, 소프트웨어 재사용,유지보수 향상

 

2. 객체지향 개발 용어 및 개념 이해하기

1) 객체 ( Object ) : 현실세계의 개체며 객체들 간의 상호작용은 메시지를 통해 이루어짐

2) 클래스 ( Class ) : 데이터 추상화(모델링)을 의미

3) 메시지 ( Message ) : 객체들간의 상호작용을 하는데 사용되는 수단, 메소드 시작

4) 메소드 ( Method ) : 연산, 행동

 

2.1 캡슐화 ( Encapsulation )

- 정보처리에 필요한 기능을 한 테두리로 묶는 것

- 정보 은폐, 외부 접근 차단, 오류 방지(결합도 낮아짐)

-> 재사용 용이, 객체간의 인터페이스 단순화, 응집도 향상

 

2.2 정보 은폐 ( Information Hiding )

- 자신의 자료를 숨기고 자신의 연산만을 통하여 접근을 허용 -> 고려되지 않은 오류 제거

 

2.3 상속 ( Inheritance )

- 상위 클래스의 메소드와 속성을 하위 클래스가 물려받는 것

- 다중 상속은 한 클래스가 여러 상위 클래스로부터 상속 받는 것

 

2.4 다형성 ( Polymorphism )

- 한 메시지가 객체에 따라 다른 방법으로 응답할 수 있는 것

- 많은 상이한 클래스들이 동일한 메소드명을 이용하는 능력

 

3. 객체지향 프로그램 특징

- 재사용율이 높다

- 유지보수성이 향상된다

- 사용자 중심, 대화식 프로그램 등 대형 프로젝트 개발에 적합

- 실행 속도가 느려진다

 

4. 객체지향 개발 단계

: 계획 - 분석 - 설계 - 구현 - 테스트 및 검증

 

4.1 객체지향 분석 ( OOA : Object Oriented Analysis )

- 모델링 구성요소인 클래스, 객체, 속성, 연산들을 표현해서 문제를 모형화 ( ERD )

- 주요 목적 : 객체는 클래스로부터 인스턴스화 되고, 이 클래스를 식별

- 기법 : Rumbaugh (럼바우)

* 럼바우기법 절차

객체모형 - 동적모형 - 기능모형

 

4.2 객체지향 설계

- 시스템을 구성하는 객체와 속성, 연산을 인식

- 계층차트를 그리면 유용

- 순차적 또는 동시적으로 구현될 수 있음

- 객체의 속성과 자료구조를 표현

- 서브클래스와 메시지 특성을 세분화하여 세부사항 정제화

 

4.3 객체지향 구현

- 절차 중심이 아니다

 

4.4 테스트

- 단위(class) 테스팅 - 통합 테스팅 - 검증과 시스템 테스팅

 

 

 

SE 5강 - 발전적 주제

1. 소프트웨어 재사용

1) 특징

- 이미 개발된 소프트웨어 전체 혹은 일부분을 다른 소프트웨어 개발이나 유지에 이용

- 이미 만들어진 프로그램을 사용

 

2) 이점

- 개발시간과 비용의 단축

- 소프트웨어 품질 향상

- 생산성 향상

- 시스템 구축방법에 대한 지식 공유

- 시스템 명세, 설계, 코드 등의 문서 공유