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

4 과목 소프트웨어 공학

시스템의 주요 구성 요소

처리 : 입력 데이터를 처리 방법과 조건에 따라 처리하는 것

제어 : 자료 입출력 과정 감독

피드백 : 목표 달성때까지 반복 처리

소프트웨어 위기의 원인

- sw 특성 이해 부족

- sw 관리 부재

- 프로그래밍에만 치중

- sw 개발 기술에 대한 교육 부족

소프트웨어 위기의 결과

- 개발 인력의 부족과 인건비 상승

- 성능 및 신뢰성의 부족

- 개발기간 지연, 개발 비용 증가

- 유지보수 어려워 이에 대한 비용 증가

- sw 생산성 저하, sw 품질 저하

소프트웨어 공학의 개념

- 소프트웨어 공학 (SE, Software Engineering) 은 sw 위기 극복 위해 연구된 학문

sw의 품질과 생산성 향상을 목적으로 함

가장 경제적인 방법으로 양질의 제품을 생산

안정적, 효율적으로 작동하는 sw생산, 유지보수 활동을 체계적으로 하기위함

좋은 품질의 SW

- 사용자 요구대로 동작, 인터페이스 사용편리, 유지보수 용이, 에러가 적어야하고, 실행속도가 빠르고 용량을 적게 차지해야함

SW 생명주기 모형 

- 폭포수 모형

sw 개발 각 단계를 확실히 매듭짓고 철저히 검토, 승인 거친 후 다음단계 진행, 이전 단계로 못돌아감

개발 과정중에 새로운 요구 반영 어려워 처음부터 모든 사용자 요구사항 명확히 제시

개발 순서 : 타당성 검토 - 계획 - 요구 분석 - 설계 - 구현(코딩) - 시험(검사) - 유지보수

- 프로토타입 모형

사용자 요구사항 파악 위해 프로토타입 만들어 최종 결과물 예측하는 모형

sw일부 구현

프로토타입이 골격이되고 개발 단계 안에서 유지보수가 이루어져 생명주기에서 유지보수 단계 X

- 나선형 모형

나선을 따라 돌듯이 여러번의 개발 과정을 거쳐 점진적으로 최종 sw개발

개발 순서 : 계획 및 정의 - 위험분석 - 공학적 개발 - 고객평가

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

사람

문제 : 사용자 입장에서 문제 분석

프로세스 : sw 개발에 필요한 전체적인 작업 계획 및 구조

SW 개발 영역 결정

프로젝트 계획 수립이 첫 번째 업무로, 개발될 sw의 영역을 결정

sw 개발 영역을 결정하는 주요 요소 : 처리될 데이터와 sw에 대한 기능, 성능, 제약조건, 인터페이스 및 신뢰도 등

프로젝트 비용 결정 요소

- 프로젝트 요소 : 복잡도, 시스템 크기, 요구되는 신뢰도

- 자원 요소 : 인적자원, hw 자원, sw 자원

- 생산성 요소 : 개발자 능력, 경험, 개발 기간

비용 산정 기법

- LOC기법(원시 코드 라인 수)

[ 산정 공식 ]

노력 : 개발기간 * 투입인원

   LOC / 1인당 월평균 생산 코드라인 수

생산성 : LOC / 노력(인월)

- COCOMO

Boehm이 제안한 것으로 원시 프로그램의 규모에 의한 비용 산정 기법

개발할 sw 의 규모를 예측한 후 sw 종류에 따라 다르게 책정되는 비용 산정 방식

sw 개발 유형 : 조직형(Organic Mode) / 반분리형(Semi-distached) / 내장형

조직형 : 기관 내부에서 개발된 중.소규모의  sw, 비즈니스 자료 처리용으로 5만(50KDSI)라인 이하의 sw 개발

내장형 : 초대형 규모의 트랜잭션 처리 시스탬이나 운영체제 등의 30만(300KDSI)라인 이상의 sw 개발 유형  

*KDSI : 천 라인 당 명령어 라인 수 

브룩스 법칙 (Brooks)

프로젝트 진행 중에 새로운 인력 투입할 경우 작업 적응 기간과 부작용으로 인해 일정을 더욱 지연시키고 

프로젝트에 혼란을 가져온다는 법칙

프로젝트 일정 계획 - CPM 

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

CPM은 노드와 간선으로 구성된 넽워크. 노드는 작업을, 간선은 작업 사이의 전후 의존 관계를 나타낸다.

경영층의 과학적인 의사결정을 지원, 효과적은 프로젝트 통제 가능

간트 차트(Gantt Chart) (= 시간선(Time Line) 차트)

프로젝트의 각 작업들이 언제 시작하고 종료되는지에 대한 작업 일정을 막대 도표를 이용하여 표시하는 프로젝트 일정표

이정표 / 작업 일정 / 작업 기간 /산출물로 구성

 

프로젝트 팀 구성 

- 분산형 팀 : 팀원 모두 의사결정 참여(민주주의식), 개개인의 생산성 및 책임감 낮아질 수 있음

- 중앙 집중형 팀(책임 프로그래머 팀) : 관리자 의사결정 , 의사교환 경로를 줄일 수 있다.

주요 품질 표준

- 정확성(Correctness) : 사용자 요구기능 충족

- 신뢰성(Reliability) : 오류 없이 수행하는 정도

- 효율성(Efficiency) : 필요한 자원 소요 정도

- 사용 용이성(Usability) : 배우고 사용하기 쉬운 정도

- 유연성(Flexibility) : 새로운 요구사항에 맞게 얼만큼 쉽게 수정할 수 있는 정도 

- 이식성(Portability) : 다양한 hw 환경에서 운용가능하게끔 수정할 수 있는 정도

정형 기술 검토(FTR)에 대한 지침 사항 

- 제품 검토, 의제 제한 진행, 농쟁괍 나박 제한, 문제 영역 명확히 표현 

 참가자수 제한, 사전 준비 강요, 각제품에 대한 체크리스트 개발, 자원과 시간 일정 할당, 메모 공유 .....(?)

위험 관리 (Risk Analysis)

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

인력부족, 예산 관리, 일정 관리, 사용자 요구 변경

위험 감시 (Risk Monitoring) : 위험 요소 징후에 대하여 계속 적으로 인지

형상 관리(SCM)

sw 개발 과정에사 sw의 생산물을 확인하고 sw 통제, 변경 상태를 기록하고 보관하는 일련의 관리 작업

sw 변경의 원인을 알아내고 제어하며 적절히 변경되고 있는지 확인하여 담당자에게 통보하는 작업

sw 개발 모든 단계에 적용되는 활동, 유지보수 단계에서 수행

개발 전체 비용을 줄이고 개발과정에서 발생하는 여러 문제점 최소화가 목적

SW 형상 항목 : 정의 단계의 문서, 개발 단계의 문서와 프로그램, 프로그램 내의 자료구조, 유지보수 단계의 변경사항

요구 사항 분석의 어려움

- 대화 장벽 / 시스테의 복잡도 / 요구 변경 / 요구 명세화의 어려움

자료 흐름도 (DFD, Data Flow Diagram = 버블 차트)

요구사항 분석에서 자료 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법

시스템 안의 프로세스, 자료 저아소, 단말 간 자료의 흐름을 나타내는 그래프. 

자료 흐름과 처리를 중심으로 하는 구조적 분석 기법

자료는 처리를 거쳐 변환될 때마다 새로운 이름 부여된다.

처리는 입력자료 발생하면 기능을 수행한 후 출력 자료 산출

자료 흐름도 구성 요소

프로세스 : 자료 변환 시키는 시스템의 한 부부분, 처리과정 나타내며 처리, 기능, 변환, 버블 이라고함

자료 흐름 

자료 저장소(Data Store) :  파일, DB

단말 (Terminator) :  시스템과 교신하는 외부 개체, 입력데이터가 만들어지고 출력 데이터를 받음

자료 사전 표기 기호 : 

= : 자료의 정의 ( is composed of)

+ : 자료의 연결, and

() : 자료의 생략, 생략 가능 자료 (Optional)

{} : 자료의 반복 (Iteration of)

HIPO

:소프트웨어와 프로그램의 기능을 설계하고 개발·문서화할 경우의 도형 방식의 기법이며, 입력(input)/처리(process)/출력(output)을 단위로 한 도형 계층 구조로 정리된다.

하향식 sw 개발을 위한 문서화 도구

기본 시스템 모델은 입력 처리 출력으로 구성

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

종류 : 가시적 도표 (도식 목차 ), 총체적 도표(개요 도표), 세부적 도표(상세 도표)

바람직한 설계의 특징

sw 구조

요구사항 모두 구현, 유지보수 용이해야

모듈간 효과적 제어를 위해 계층적 자료 조직이 제시돼야한다.

모듈간, 외부개체간 연결 복잡성을 줄이는 인터페이스를 가져야한다.

적당한 모듈 크기 유지,모듈간 상호의존도(결합도)는 약하게, 응집도는 강하게 설계

결합도 (Coupling)

모듈 간에 상호 의존하는 정도

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

자료 결합도 : 모듈 호출시 매개변수, 인수로 데이터 넘겨주고, 호출된 모듈은 리턴값 돌려줌

제어 결합도 : 다른 모듈을 제어하기 위해 제어 요소 (Function Code, Switch, Tag, Flag) 를 전달

 하위 모듈에서 상위 모듈로 제어신호가 이동하여 상위 모듈에게 처리 명령을 부여하는 권리 전도현상 발생

공통 결합도 : 공유자원 여러모듈이 사용

내용 결합도 : 한 모듈이 다른 모듈의 내부 기능이나 자료를 직접 참조하거나 수정

외부 결합도 : 한 모듈이 다른 모듈 내의 요소들을 참조하고 동시에 이런 요소들이 다른 모듈에 개방되어 있는 것

스탬프 결합도 : ?

내용 > 공통 > 외부 > 제어 > 스탬프 > 자료

응집도(Cohesion)

정보 은닉 개념을 확장. 모듈 안의 요소들이 서로 관련되어 있는 정도, 모듈이 독립적인 기능으로 정의되어 있는 정도.

모듈 내부 요소에는 명령어, 명령어의 모임, 호출문 등

우연적 응집도 < 논리적 응집도 < 시간적 응집도 < 절차적 응집도 < 교환적 < 순차적 < 기능적 ( 응집도 높음 )

기능적 응집도 : 모듈 내부의 모든 기능요소들이 단일 문제와 연관되어 수행될 경우의 응집도

교환(통신)적 응집도 : 동일한 입출력을 사용하여 서로 다른 기능을 수행하는 구성요소들이 모여있을 경우

논리적 응집도 : 유사한 성격을 갖거나 특정 형태로 분류되는 처리요소들도 모듈이 형성

우연적 응집도 : 모듈 내부의 각 구성요소들이 서로 관련없는 다른 기능 

효과적인 모듈화 설계 방향

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

복잡도외 중복성(Redundancy) 줄이고 일관성 유지

유지보수(maintenance) 용이해야

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

N-S 차트(Nassi-Schneiderman Chart)

구조화 프로그래밍 언어용으로 개발된 순서도(flow chart)의 일종. 종전의 순서도와는 달리 흐름을 나타내는 것이 없고, 처리는 직사각형을 포개어가는 것으로 나타낸다. 또 제어는 반드시 위에서 아래로 흐르도록 쓰여져 있다. 구조화된 프로그램은 순서도에서 선이 복잡하게 얽히는 일이 없으므로, NS 차트의 경우에는 한결 보기 쉬운 모양으로 나타낼 수 있다

논리의 기술에 중점을 둔 도형을 이용한 표현 방법( 박스 다이어그램, Chapin Chart )

순차, 연속 구조, 반복구조, 선택구조, 다중선택 구조 등을 표현

GOTO나 화살표를 사용하지 않으며, 선택과 반복 구조를 시각적으로 표현

이해쉽고 코드 변환 용이

화이트 박스 검사 / 블랙 박스 검사 기법

화이트 박스 검사 : 기초 경로 검사, 조건 검사, 루프 검사, 데이터 흐름 검사

블랙 박스 검사 : 동치 분할 검사, 경계값 분석, 원인-효과 그래프 검사, 오류 예측 검사, 비교 검사

검사 전략

- 하향식 통합 검사 

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

일시적으로 필요한 조건만 가지는 임시로 제공되는 시험용 모듈 스터브(Stub)가 필요하다

일반적으로 스터브(Stub)는 드라이버(Driver)보다 작성하기 쉽다

검사 초기부터 사용자에게 시스템 구조를 보여줄 수 있다.

상위 모듈에서는 검사 사례를 쓰기가 어렵다. ( Test Case )

순환 복잡도

- 알파 검사

- 베타 검사

유지보수의 유형

-------------------------생략-------------------------------

외계인 코드

객체지향 기법의 구성 요소

- 객체

- 클래스

- 메시지

객체지향 기법의 기본 원칙

- 캡슐화

-------------------------생략-------------------------------

객체지향 분석

객체지향 분석의 주요 방법론

럼바우 (Rumbaugh)의 분석 기법 

소프트웨어의 재사용

소프트웨어 재공학 (Software Reengineering)

Reengineering의 주요 활동

- 분석

- 개조 

- 이식

- 역공학

CASE

① common application service elements 공통 응용 서비스 요소 ② computer-aided software engineering 컴퓨터 지원 소프트웨어 엔지니어링.

SW, HW, DB, test등을 통합하여 소프트웨어를 개발하는 환경을 조성한다.

소프트웨어의 생명주기의 전체 단계를 연결해주고 자동화해주는 통합된 도구를 제공해주는 기술이다.

CASE의 주요 기능 : sw 생명주기 전단계를 연결, 개발 모형 지원, 그래픽 지원 등

CASE 사용의 이점 : sw 개발기간 단축 및 비용 절감, 품질 향상, 개발 주기의 표준화, 개발 기법의 실용화, 문서화 용이 등

Use Case : 시스템 사이에서 교환되는 메시지의 중요도에 의해 클래스나 시스템에 제공되는 고유 기능 단위이며, 상호 행위자 밖의 하나 혹은 그 이상의 것이 시스템에 의해서 실행되는 행위를 함께 함