정보처리기사 필기요약(4)

4과목 소프트웨어공학

 

1. 소프트웨어 위기

 

 소프트웨어의 특성에 대한 이해 부족, 소프트웨어의 관리 부재, 프로그래밍에만 치중, 소프트웨어 개발 기술에 대한 교육 부족 등 여러가지 원인에 의해 개발 속도를 따라가지 못해 소프트웨어에 대한 사용자들의 요구사항을 처리할 수 없는 문제가 발생한 것을 의미함.

 

개발 인력의 부족과 그로인한 인건비 상승, 성능 및 신뢰성의 부족, 개발 기간의 지연 및 개발 비용의 증가, 유지보수가 어렵고, 이에 따른 비용 증가, 소프트웨어의 생산성 저하, 소프트웨어의 품질 저하 등이 일어남.

 

2. 좋은 소프트웨어의 조건

 

ㆍ신뢰성이 높고 효율적임
ㆍ사용자의 의도대로 동작
ㆍ잠재적 에러의 최소화
ㆍ편리성 제공
ㆍ유지보수 용이

 

3. 폭포수 모형(Waterfall Model)

 

 - 소프트웨어 개발각  단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행하며 이전 단계로 되돌아갈 수 없는 방식이다.

 

- 소프트웨어 개발 과정의 앞 단계가 끝나야만 다음 단계로 넘어갈 수 있는 선형 순차적 모형이다.

 

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

 

장점:

• 모형의 적용 경험과 성공 사례가 많음
• 단계별 정의가 분명하고, 전체 공조의 이해가 용이함
• 단계별 산출물이 정확하여 개발 공정의 기준점을 잘 제시함

  

단점 :

• 개발 과정중에 발생하는 새로운 요구나 경험을 반영하기 어려우므로 처음부터 사용자들이 모든 요구사항들을 명확하게 제시해야 함
• 단계별로 오류 없이 다음 단계로 진행해야 하는데 현실적으로 오류 없이 다음 단계로 진행하기는 어려움
• 개발된 프로그램을 업무에 운용할 때 검출되지 않은 오류로 인하여 사용자들이 큰 인내심을 가져야 함

 

 

4. 프로토타입 모형(Prototype Model)

 

- 사용자의 요구사항을 정확히 파악하기 위해 실제 개발될 소프트웨어에 대한 견본(시제)품(Prototype)을 만들어 최종 결과물을 예측하는 모형이다.

 

 - 요구 분석 단계에서 사용하게 되며, 프로토타입의 평가가 끝나고 개발이 승인되면 다른 모형을 이용하여 본격적인 개발이 이루어진다.

 

- 소프트웨어 생명주기에서 유지보수 단계가 없어지고 개발 단계 안에서 유지보수가 이루어진다.

 

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

 

장점 :

• 요구사항을 충실히 반영하며, 요구사항의 변경이 용이함
• 최종 결과물이 만들어지기 전에 의뢰자가 최종 결과물의 일부 또는 모형을 볼 수 있음
• 프로토타입은 의뢰자나 개발자 모두에게 공동의 참조 모델을 제공함

 

 

단점 :

• 미리 제작된 소프트웨어를 사용할 경우 실제 소프트웨어와 차이가 발생할 수 있어 사용자에게 혼란을 줄 수 있음
• 단기간에 제작해야 하기 때문에 비효율적인 언어나 알고리즘을 사용할 수 있음

 

 

5. 나선형 모형(Spiral Model)

 

- 보헴 (Boehm)이 제안한 것으로, 폭포수 모형과 프로토타입모형의 장점에 위험 분석 기능을 추가한 모형이다.

 

- 나선을 따라 돌 듯이 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로(프로토타입을 지속적으로 발전시켜) 완벽한 최종 소프트웨어를 개발하는 것이다.

 

 

- 소프트웨어를 개발하면서 발생할 수 있는 위험을 관리하고 최소화하는 것을 목적으로 한다.

 

- 개발 순서 : 계획 및 정의(Planning) → 위험 분석(Risk Analysis) → 공학적 개발(Engineering) →고객 평가(Customer Evaluation)

 

장점 :

• 가장 현실적인 모형으로, 대규모 시스템에 적합함
• 점진적으로 개발 과정이 반복되므로 누락되거나 추가된 요구사항을 첨가할 수 있고, 정밀하며, 유지보수 과정이 필요 없음

 

단점 :

 • 위험성 평가에 크게 의존하기 때문에 이를 발견하지 않으면 반드시 문제가 발생함
• 비교적 최신기법이므로 폭포수 모형이나 프로토타입 모형보다 널리 사용되지 않음

 

 

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

 

사람(People), 문제(Problem), 프로세스(Process)

 

7. 소프트웨어 영역(Software Scope) 결정 요소

 

기능(Function), 성능(Performance), 신뢰도(Reliability)

 

 

8. 비용 산정 기법 - LOC

ㆍ노력(인월) = 개발 기간(월) × 투입 인원(인)
ㆍ개발 비용 = 개발 기간(월) × 투입 인원(인) × 단위 비용(1인당 월평균 인건비)
ㆍ개발 기간 = 예측된 LOC / (투입 인원 × 1인당 월평균 생산 LOC)
ㆍ생산성 = 개발된 LOC / (투입 인원 × 개발 기간)

 

8. 비용 산정 기법 - COCOMO(COnstructive COst MOdel)

ㆍ조직형( Organic Mode ) : 5만 라인 이하의 중소 규모 소프트웨어를 개발하는 유형
ㆍ반분리형(Semi-Detached Mode ): 30만 라인 이하의 소프트웨어를 개발하는 유형
ㆍ내장형( Embedded Mode ): 30만 라인 이상의 소프트웨어를 개발하는 유형

 

 

9. 프로젝트 일정 계획

 

ㆍWBS : 개발 프로젝트를 여러 개의 소작업으로 분할하여 계층적으로 기술한 업무 구조
ㆍPERT/CPM : 프로젝트의 지연을 방지하고 계획대로 진행되게 하기 위한 일정을 계획하는 것
ㆍ간트 차트 : 프로젝트의 각 작업의 시작 및 종료 시점에 대한 작업 일정을 수평 막대를 이용하여 표시
ㆍ브룩스(Brooks)의 법칙 : S/W 프로젝트 일정이 지연된다고 해서 프로젝트 말기에 새로운 인원을 추가 투입하면 프로젝트는 더욱 지연되게 된다고 주장하는 법칙

 

10. 프로젝트 팀 구성

 

분산형팀

 

• 팀원 모두가 의사 결정에 참여하는 비이기적인 구성 방식(민주주의식 팀)
• 의사 결정을 민주주의식으로 하며 팀 구성원의 참여도와 작업 만족도를 높이고 이직률을 낮게 함
• 팀 구성원 각자가 서로의 일을 검토하고 다른 구성원이 일한 결과에 대하여 같은 그룹의 일원으로 책임을 지며, 장기 프로젝트 개발에 적합함
• 다양한 의사 교류로 인해 의사 결정 시간이 늦어지고, 개개인의 생산성 및 책임감이 낮아질 수 있음

 

 

중앙 집중형팀

 

• 한 관리자가 의사결정을 하고, 팀 구성원들은 그 결정을 따르는 구성 방식으로 책임 프로그래머 팀이라고도 함
• 프로젝트 수행에 따른 모든 권한과 책임을 한 관리자에게 위임하고, 기술 및 관리 지원을 위해 인력을 투입하는 형태
• 의사결정이 빠르고, 의사 교환 경로를 줄일 수 있음
• 한 사람에 의하여 통제할 수 있는 비교적 소규모 문제에 적합함
• 책임 프로그래머 역할 : 요구 분석 및 설계, 중요한 기술적 판단, 프로그래머에게 작업 지시 및 배분 등
• 프로그래머 역할 : 책임 프로그래머의 지시에 따른 원시코드 작성, 테스트, 디버깅, 문서 작성 등
• 프로그램 사서 역할 : 프로그램 리스트, 설계 문서, 테스트 계획 등을 관리
• 보조 프로그래머 역할 : 책임 프로그래머의 업무 지원, 여러 가지 기술적인 문제에 대한 자문, 사용자, 품질 보증 담당자 등의 섭외, 책임 프로그래머 감독하에 분석, 설계, 구현 담당

 

 

계층적팀

 

• 분산형 팀 구성과 중앙 집중형 팀 구성을 혼합한 형태(혼합형 팀)
• 5~7명의 초보 프로그래머를 작은 그룹으로 만들어 각 그룹을 고급 프로그래머가 관리하게 함
• 경험자(고급 프로그래머)와 초보자를 구별함
• 프로젝트 리더와 고급 프로그래머에게 지휘 권한을 부여하고, 의사 교환은 초급 프로그래머와 고급 프로그래머로 분산함

 

 

11.소프트웨어 품질 표준(목표)
ㆍ정확성 : 사용자의 요구 기능을 충족시키는 정도
ㆍ신뢰성 : 정확하고 일관된 결과를 얻기 위하여 요구된 기능을 오류 없이 수행하는 정도
ㆍ효율성 : 자원의 낭비 정도
ㆍ무결성 : 허용되지 않는 사용이나 자료의 변경을 제어하는 정도
ㆍ사용 용이성 : 적절한 사용자 인터페이스와 문서를 가지고 있는 정도
ㆍ유지보수성 : 사용자의 기능 변경의 필요성을 만족하기 위하여 소프트웨어를 진화하는 것이 가능한정도
ㆍ이식성 : 다양한 하드웨어 환경에서도 운용 가능하도록 쉽게 수정될 수 있는 정도
ㆍ재사용성 : 이미 만들어진 프로그램을 사용하는 정도
ㆍ상호 운용성 : 다른 소프트웨어와 정보를 교환할 수 있는 정도

 

12. 위험 관리(Risk Analysis)

 

• 프로젝트 추진 과정에서 예상되는 각종 돌발 상황(위험)을 미리 예상하고 이에 대한 적절한 대책을 수립하는 일련의 활동이다.
• 소프트웨어 개발 시 일반적인 위험 요소에는 인력 부족,예산 관리, 일정 관리, 사용자 요구변경 등이 있으며,이 중 가장 대표적인 위험 요소는 사용자 요구 변경이다.
• 위험은 불확실성과 손실을 내재하고 있으며, 위험 관리는 이러한 위험의 불확실성을 감소시키고, 손실에 대비하는 작업이다.

 

 

 

13. 위험 관리의 절차
위험 식별 → 위험 분석 및 평가 → 위험 관리 계획 → 위험 감시 및 조치

 

 

14. 형상 관리

 

ㆍ형상(Configuration) : 소프트웨어 개발 단계의 각 과정에서 만들어지는 프로그램, 프로그램을 설명하는 문서, 데이터 등을 통칭함
ㆍ소프트웨어 형상 관리(S/W Configuration Management) : 소프트웨어 개발 과정의 변화되는 사항을관리하는 활동

 

 

15. 요구사항 분석의 어려움

 

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

 

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

 

-요구의 변경 : 사용자 생각의 부정확성, 생각의 반복된 변경

 

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

 

 

 

16. 자료 흐름도(DFD ; Data Flow Diagram)
ㆍ요구사항 분석에서 처리 공정과 이들 간의 자료 흐름을 그래프 형태로 도형화하여 표현한 것
ㆍ자료 흐름도 구성 요소

 

기호	의미	표기법
프로세스 (Process)	자료를 변환시키는 시스템의 한 부분(처리 과정)을 나타내며, 처리, 기능, 변환, 버블이라고도 함
자료 흐름(Flow)	자료의 이동을 나타냄
자료 저장소 (Data Store)	시스템에서의 자료 저장소(파일, 데이터베이스)를 나타냄
단말 (Terminator)	시스템과 교신하는 외부 개체로, 입력 데이터가 만들어지고, 출력 데이터를 받음(정보의 생산자와 소비자)

 

 

17. 자료 사전(DD)

 

ㆍ자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것
ㆍ데이터를 설명하는 데이터를 메타 데이터(Meta Data)라고 함
ㆍ표기법

 

기호	의미
-	자료의 정의 : ~로 구성되어 있다(is composed of)
+	자료의 연결 : 그리고(and)
( )	자료의 생략 : 생략 가능한 자료(Optional)
[ | ]	자료의 선택 : 또는(or)
{ }	자료의 반복(Iteration of)
* *	자료의 설명 : 주석(Comment)

 

18. HIPO

 

• 시스템의 분석 및 설계나 문서화할 때 사용되는 기법으로 시스템 실행 과정인 입력, 처리, 출력의 기능을 나타낸다.

 

HIPO의 구성
ㆍ가시적 도표(Visual Table of Contents, 구조도) : 시스템의 전체적인 기능과 흐름을 보여주는 계층
(Tree) 구조도
ㆍ총체적 다이어그램(Overview Diagram, 개요 도표) : 프로그램을 구성하는 기능을 기술한 것으로 입력, 처리, 출력을 기술
ㆍ세부적 다이어그램(Detail Diagram, 상세 도표) : 총체적 도표에 표시된 기능을 구성하는 기본 요소들을 상세히 기술하는 도표

 

19. 결합도(Coupling)
ㆍ한 모듈과 다른 모듈 간의 상호 의존도 또는 두 모듈 사이의 연관 관계를 의미함
ㆍ독립적인 모듈이 되기 위해서는 각 모듈 간의 결합도가 약해야 하며, 의존하는 모듈이 적어야 함
ㆍ결합도의 종류

 

자료  결합도

스탬프 결합도

제어 결합도

외부 결합도

공통(공유)결합도

내용 결합도

결합도 약합 <-----                                   -----> 결합도 강함

 

20. 응집도(Cohesion)
ㆍ모듈 안의 요소들이 서로 관련되어 있는 정도를 의미함
ㆍ모듈을 이루고 있는 각 요소들이 공통의 목적을 달성하기 위하여 얼마나 관련이 있는지의 기능적 연관의 정도를 나타냄
ㆍ응집도의 종류

 

우연적 응집도

논리적 응집도

시간적 응집도

절차적 응집도

교환적 응집도

순차적 응집도

기능적 응집도

응집도 약합 <-----                                   -----> 응집도 강함

 

 

21. 효과적인 모듈화 설계 방안

 

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

• 모듈의 제어 영역 안에서 그 모듈의 영향 영역을 유지시킨다.
•복잡도와 중복성을 줄이고 일관성을 유지시킨다.
• 모듈의 기능은 예측이 가능해야 하며 지나치게 제한적이어서는 안 된다.
• 유지보수가 용이해야 한다.
• 모듈 크기는 시스템의 전반적인 기능과 구조를 이해하기 쉬운 크기로 분해한다.
• 하나의 입구와 하나의 출구를 갖도록 해야 한다.
• 인덱스 번호나 기능 코드들이 전반적인 처리 논리 구조에 예기치 못한 영향을 끼치지 않도록 모듈 인터페이스를 설계해야 한다.

 

 

22. 화이트박스 테스트(White Box Test)

 

ㆍ모듈 안의 작동을 자세히 관찰할 수 있으며, 프로그램 원시 코드의 논리적인 구조를 커버하도록 검사 사례(Test Case)를 설계하는 프로그램 테스트 방법
ㆍ논리 구조상의 오류, 세부적 오류, 반복문 오류, 수행경로 오류 등을 발견할 수 있으며, 자료 구조의 오류는 발견하지 못함

ㆍ종류 : 기초 경로 검사(Basic Path Test), 조건 검사(Condition Coverage), 데이터 흐름 검사(Data
Flow Test), 루프 검사(Loop Test)

 

 

23. 블랙박스 테스트(Black Box Test)

ㆍ소프트웨어 인터페이스에서 실시되는 검사로 설계된 모든 기능들이 정상적으로 수행되는지 확인함
ㆍ인터페이스 오류, 성능 오류, 부정확한 기능 등을 발견할 수 있으며, 논리 구조상의 오류는 발견하지 못함
ㆍ종류 : 동치(동등) 분할 검사(Equivalence Partitioning Testing), 경계값 분석(Boundary Value Analysis), 원인-효과 그래프(Cause and Effect Graphing Testing), 비교 검사(Comparison Testing)

 

24. 유지보수

 

• 개발된 소프트웨어의 품질을 항상 최상의 상태로 유지하기 위한 것으로 소프트웨어 개발 단계 중 가장 많은 노력과 비용이 투입되는 단계이다.
• 소프트웨어가 사용자에게 인수되고, 설치된 후 발생하는 모든 공학적 작업이다.
• 소프트웨어 유지보수를 용이하게 하려면 시험 용이성, 이해성, 수정 용이성, 이식성 등이 고려되어야 한다.
• 유지보수의 유형

 

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

 

25. 객체지향 기법

 

ㆍ객체(Object) : 필요한 자료 구조와 이에 수행되는 함수들을 가진 하나의 소프트웨어 모듈로, 애트리 뷰트와 메소드로 구성됨
ㆍ애트리뷰트(Attribute) : 객체의 상태를 나타냄
ㆍ메소드(Method) : 객체가 메시지를 받아 실행해야 할 객체의 구체적인 연산의 정의한 것
ㆍ클래스(Class) : 하나 이상의 유사한 객체들을 묶어 공통된 특성을 표현한 데이터 추상화를 의미함
ㆍ메시지(Message) : 객체들 간의 상호 작용은 메시지를 통해 이루어짐

 

26. 객체지향 기법의 기본 원칙
ㆍ캡슐화(Encapsulation) : 데이터와 데이터를 조작하는 연산을 하나로 묶는 것을 의미함
ㆍ정보 은닉(Information Hiding) : 객체가 다른 객체로부터 자신의 자료를 숨기고 자신의 연산만을 통하여 접근을 허용하는 것을 의미함
ㆍ추상화(Abstraction) : 주어진 문제나 시스템 중에서 중요하고 관계있는 부분만을 분리하여 간결하고 이해하기 쉽게 만드는 작업을 의미함
ㆍ상속성(Inheritance) : 상위 클래스의 속성과 메소드를 하위 클래스가 물려받는 것을 의미함
ㆍ다형성(Polymorphism) : 많은 상이한 클래스들이 동일한 메소드명을 이용하는 능력을 의미함

 

 

26.럼바우(Rumbaugh)의 분석 기법

 

• 모든 소프트웨어 구성 요소를 그래픽 표기법을 이용하여 모델링하는 기법이다.
• 분석 활동은 객체 모델링, 동적 모델링, 기능 모델링순으로 이루어진다.

 

27. 소프트웨어의 재사용

 

ㆍ기존의 기능 및 품질을 인정받은 소프트웨어의 전체 혹은 일부분을 다른 소프트웨어 개발이나 유지에 사용하는 것
ㆍ특징

 

장점: 개발 시간과 비용 단축, 소프트웨어 품질 및 생산성 향상, 프로젝트 실패 위험 감
소, 시스템 구축 방법에 대한 지식 공유, 시스템 명세, 설계, 코드 등 문서 공유

 

단점 :

-어떤 것을 재사용할 것인지 선정해야 한다.
- 시스템에 공통적으로 사용되는 요소들을 발견해야 한다.
- 프로그램의 표준화가 부족하다.
- 새로운 개발 방법론을 도입하기 어렵다.
- 재사용을 위한 관리 및 지원이 부족하다.
- 기존 소프트웨어에 재사용 소프트웨어를 추가하기 어렵다.

 

 

 

28. 소프트웨어 재공학(Software Reengineering)
ㆍ소프트웨어의 위기를 해결하기 위해 개발의 생산성이 아닌 유지보수의 생산성으로 해결하려는 방법
ㆍ목표 : 유지보수성/생산성/품질 향상, 복잡한 시스템을 다루는 방법 구현, 다른 뷰의 생성, 잃어버린 정보의 복구 및 제거
ㆍ소프트웨어 재공학의 주요 활동 : 분석, 개조, 역공학, 이식

29. CASE(Computer Aided Software Engineering)
ㆍ소프트웨어 생명주기의 전체 단계를 연결시켜주고 자동화시켜주는 통합된 도구를 제공해주는 기술
ㆍCASE 사용의 이점 : 소프트웨어의 생산성 문제 해결, 개발 비용 절감, 개발 속도가 빠르고, 재사용성 향상, 소프트웨어 품질 향상, 유지보수 용이
ㆍCASE의 분류 : 통합 CASE, 상위 CASE, 하위 CASE