정처기 필기_소프트웨어 공학

정처기 필기_소프트웨어 공학

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

- 브룩스(Brooks) 법칙

: 프로젝트 ''진행중에'' 새로운 인력을 투입할 경우 적응 기간과 부작용으로 인해 일정을 더욱 지연시키고, 프로젝트에 혼란을 가져오게 된다는 법칙.

- Pareto의 법칙

: 소프트웨어 테스트에서 오류의 80%는 전체 모듈의 20% 내에서 발견된다는 법칙이다.

- CASE(Computer Aided Software Engineering)

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

: 개발 과정의 속도를 향상 시킨다.

: 소프트웨어 부품의 재사용을 가능하게 한다.

: 요구 분석, 설계, 구현, 검사 및 디버깅 과정 전체 또는 일부를 자동화하는 것이다.

주요 기능: 그래피 지원, 소프트웨어 생명주기 전 단계의 연결, 다양한 소프트웨어 개발 모형 지원.

언어 번역 (X)

- Mini-spec(소단위 명세서)

= 세분화된 자료 흐름도에서 최하위 단계 프로세스의 처리 절차

- 소프트웨어 품질 표준 종류 중 하나 -Reliability(신뢰성)
: 정확하고 일관된 결과를 얻기 위하여 요구된 기능을 오류 없이 수행하는 정도를 나타내는 것

- 소프트웨어 품질 표준 종류 중 하나 -Usability(사용 용이성)

: 사용에 필요한 노력을 최소하하고 쉽게 사용할 수 있는 정도(배우고 사용하기 쉬운 정도)ㅅ

3P = PEOPLE, PROCESS, PROBLEM

PERT 차트

: 작업들 간의 상호 관련성, 결정경로, 경계시간, 자원할당을 제시한다.

: 프로젝트에 필요한 전체 작업의 상호 관계를 표시하는 네트워크이다.

작업 시작/종료 시간을 파악할 수 있다 (X)

GANTT 차트

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

: 시간선(Time-line) 차트라고도 한다.

: 수평 막대의 길이 = 각 작업의 기간을 나타낸다

[프로젝트 이정표, 작업 기간, 작업 일정, 산출물]로 구성되어 있다.

임계 경로 = 최장 경로

객체에게 어떤 행위를 하도록 지시하는 명령은 = MESSAGE

CORBA에서 인터페이스 정의언어는 IDL(interface description language)이다.

---

- 객체 지향 개발 과정

: 구현 단계에서는 클래스를 객체지향 프로그래밍 언어를 사용한다. (절차적 프로그래밍 언어 X)

: 분석 단계에서는 객체의 이름과 상태, 행위들을 개념적으로 파악한다.

: 설계 단계에서는 객체를 속성과 연산으로 정의하고 접근 방법을 구체화한다.

: 테스트 단계에서는 클래스 단위 테스트와 시스템 테스트를 진행한다.

---

유지보수 - 소프트웨어가 사용자에게 인수되고, 설치된 후 발생하는 모든 공학적 작업이다, 소프트웨어 비용 중 유지보수 비용이 가장 많습니다.

- Corrective Maintenance(수정/교정/정정/하자 보수)

: 소프트웨어 테스팅 동안 밝혀지지 않은 모든 잠재적인 오류를 찾아 수정하는 활동에 해당하는 유지보수

- Adaptive Maintenance(환경적응, 적응/조정 보수)

: 소프트웨어 수명기간 중, 운영체제나 컴파일러와 같은 프로그래밍 환경 변화와 주변장치 또는 다른 시스템 요소가 향상되거나 변경될 때 기존의 소프트웨어에 반영하기 위하여 수행하는 활동

- Perfective Maintenance(완전화/기능개선/기능 보수)

: 유지보수 활동 중 가장 큰 업무 및 비용을 차지

: 소프트웨어의 본래 기능에 새로운 기능을 추가 or 성능 개선하기 위해 소프트웨어를 확장시키는 활동

- Preventive Maintenance(예방 보수)

: 장래의 유지보수성 또는 신뢰성을 개선하거나 소프트웨어의 오류 발생에 대비하여 미리 예방 수단을 강구해 두는 활동

외계인 코드

아주 오래되거나 참고 문서 또는 개발자가 없어 유지보수 작업이 어려운 프로그램을 뜻한다.

---

- 결합도 (Coupling)

= 두 모듈간의 상호작용, 또는 의존도 정도를 나타내는 것이다

content coupling 내용 결합도

: 하나의 모듈이 '직접적으로' 다른 모듈의 '내용을 참조'할 때 두 모듈은 내용적으로 결합되어 있다고 한다.

common coupling 공통 결합도

: 두 모듈이 동일한 전역 데이터를 접근한다면 공통 결합되어 있다고 한다.

control coupling

: 어떤 모듈이 다른 모듈의 내부 논리 조직을 '제어'하기 위한 목적으로 제어신호를 이용하여 통신하는 경우이다.

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

스탬프 결합도

: 두 모듈이 매개변수로 자료를 전달할 때 자료 구조 형태로 전달되어 이용할 때 데이터가 결합되어 있다고 한다.

약-> 강 정도

[data<stamp<control<external<common<content]

---

- 럼바우(Rumbaugh)의 분석 기법

= 모든 소프트웨어 구성 요소를 그래픽 표기법을 이용하여 모델링 하는 기법이다.

객체지향 분석 절차 = [객체 모형 -> 동적 모형 -> 기능 모형]

1. 객체 모델링 (=정보 모델링)

시스템에서 요구되는 객체를 찾아내어, 속성과 연산 식별 및 객체들 간의 관계를 규정하여 객체 다이어그램으로 표현한 것

2. 동적 모델링

상태도을 이용하여 시간의 흐름에 따른 객체들 사이의 제어 흐름, 상호 작용, 동작 순서 등의 동적인 행위를 표현한 것

3. 기능 모델링

자료 흐름도(DFD)를 이용하여 다수의 프로세스들간의 자료 흐름을 중심으로 처리 과정을 표현한 것

[설계 순서: 입/출력 결정 -> 자료 흐름도 작성 -> 기능 상세히 기술 -> 제약 사항 결정 및 최소화]

자료 흐름도 구성 요소

: process, data flow, data store, terminator

---

객체지향 기법- 오퍼레이션

: 클래스 내의 객체에 의한 함수이거나 변형이다.

: 한 클래스내의 모든 객체들은 같은 오퍼레이션을 공유하며 개개한 오퍼레이션은 묵시적 아규먼트로써 목적 개체를 가지며 행위를 서술한다.

: 메소드는 한 클래스에 대한 오퍼레이션의 구현이며 일반적으로 객체지향 설계에서는 동일시하며 함수지향 설계에서는 함수로 대응된다.

: 객체지향 기법에서는 메소드(Method)와 오퍼레이션(연산)을 동일시 한다.

---

- 블랙박스 기법

: 소프트웨어 인터페이스에서 실시되는 검사로 설계된 모든 기능들이 정상적으로 수행되는지 확인한다.

: 인터페이스 오류, 행위 및 성능 오류, 초기화와 종료 오류 등을 발견하기 위하여 사용된다.

: 소프트웨어의 기능이 의도대로 작동하고 있는지, 입력은 적절하게 받아들였는지, 출력은 정확하게 생성되는지를 보여주는 데 사용된다.

-> 찾는 오류: 자료 구조

- 화이트박스 기법

: 설계 절차에 초점을 둔 구조적 테스트이다.

: '원시 코드'의 모든 문장을 한 번 이상 실행함으로써 수행된다.

-> 찾는 오류: 논리 흐름도, 루프 구조, 순환 복잡도

화이트박스 기법	블랙박스 기법
기초 경로 검사: tom mccabe가 제안, 실행 경로의 기초를 정의하는 데 지침으로 사용_됨 조건 검사: 모듈 내에 있는 논리적 조건을 검사하는 사례 설계 기법 루프 검사 데이터 흐름 검사: 변수정의와 변수 사용의 위치에 초점을 맞춰 실시	동치분할 검사: 입력 자료에만 치중한, 입력 조건에 중점을 두고, 어느 하나의 입력 조건에 대하여 타당한 값과 그렇지 못한 값을 설정하는 기법 경계값 분석: 동치분할 기법 보완하는 기법, 입력값의 중간값보다 경계값에서 오류가 발생할 확률이 높다 원인-효과 그래프 검사 오류 예측 검사: 과거의 경험이나 확인자의 감각으로 검사하는 기법 비교 검사: 여러 버전의 프로그램에 동일한 검사자료를 제공하여 동일한 결과가 출력되는지 검사하는 기법이다.

---

품질 표준 종류

정확성 (Correctness)

: 사용자의 요구 기능을 충족시키는 정도

유연성 (Flexibility)

: 새로운 요구사항에 맞게 얼마만큼 쉽게 수정할 수 있는가 하는 정도

---

- 소프트웨어 생명 주기 모형 -나선형 모형

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

: 프로토타입 모델에 위험/분석 기능을 추가한 생명주기 모형이다.

장점: 가장 현실적인 모형, 대규모 시스템에 적합

​ : 점진적으로 개발 과정이 반복되므로 누락되거나 추가된 요구사항을 첨가할 수 있고, 정밀하며, 유지보수 과정이 필요 없음

단점: 위험성 평가에 크게 의존하기 때문에 이를 발견하지 않으면 반드시 문제가 발생

​ : 비교적 최신기법이므로 폭포수 모형이나 프로토타입 모형보다 널리 사용되지 않음

---

- 소프트웨어 생명 주기 모형 -프로토타입 모형

= 실제 상황이 나오기 전에 가상으로 시뮬레이션을 통해 최종 결과물에 대한 예측을 할 수 있는 소프트웨어 생명 주기이다.

: 구축하고자 하는 시스템의 요구사항이 불명화한 경우 가장 적합한 소프트웨어 개발 모형이다.

: 개발 단계에서 오류 발견 및 수정이 가능하다.

: 시제품은 사용자와 시스템 사이의 인터페이스에 중점을 두어 개발한다.

---

- 소프트웨어 생명 주기 모형 -폭포수 모형(=고전적 생명 주기 모형)

: 가장 오래된 모형으로 많은 적용 사례가 있지만 요구사향 변경이 어려우며, 각 단계의 결과가 확인되어야지만 다음 단계로 넘어간다.

: 선형 순차적 모형

---

- 상향식 통합 검사(bottom-up integration test)

= 하위 모듈에서 상위 모듈 방향으로 통합하면서 검사한다.

: 검사를 위해 드라이버를 생성한다.

: 하위 모듈들을 클러스터로 결합한다.

과정: [낮은 수준의 모듈들을 cluster로 결합 -> driver라는 제어 프로그램의 작성 -> cluster 검사 -> driver를 제거하고 cluster를 상위로 결합]

- 하향식 통합 검사

: 깊이 우선 통합법 또는 넓이 우선 통합법에 따라 스터브(stub)를 실제 모듈로 대치한다.

---

자료 사전(DD)

= is composed of
+ and
* * comment(주석)
{ } iteration of(자료의 반복)
[|] or
( ) optional (생략 가능한 자료)

---

- 소프트웨어 재공학

Software reuse는 재공학 활동이 아님!

: 기존 시스템을 이용하여 보다 나은 시스템을 구축하고 새로운 기능을 추가하여 소프트웨어 성능을 향상시킨다

: 주요 활동으로 분석, 개조, 역공학, 이식 등이 있다.

: 유지보수에 대한 장기적인 전략적 고려와 많은 비용, 시간, 자원을 요구한다.

: 유지보수성, 생산성, 품질의 향상을 목적으로 한다.

: 소프트웨어의 위기를 개발의 생산성이 아닌 유지보수의 생산성으로 해결하려는 방법이다. (재공학의 필요성이 제기된 가장 주된 이유는 유지보수 문제이다)

: 수정 유지보수가 아니라 예방 유지보수 측면에서 소프트웨어 위기를 해결하려는 방법

: 기존에 있던 소프트웨어를 파기하지 않고 변경된 사용자의 요구사항이나 수정된 환경으로 기존 소프트웨어를 수정 보완하여 재구축하자는 개념이다.

주요 활동 -이식

: 기존 소프트웨어를 다른 운영체제나 하드웨어 환경에서 사용할 수 있도록 변환하는 작업을 말한다.

주요 활동 - 역공학

: 원시 코드를 분석하여, 소프트웨어 관계를 파악하고 기존 시스템의 설계 정보를 재발견하고 다시 제작하는 작업을 말한다.

주요 활동 - 분석

: 기본 소프트웨어의 명세서를 확인하여 소프트웨어의 동작을 이해하고 재공학 대상을 선정하는 것을 말한다.

주요 활동 - 개조(재구성, 재구조, Restructuring)

소프트웨어 기능을 변경하지 않으면서 소프트웨어를 형태에 맞게 수정하는 활동으로서, 상대적으로 같은 추상적 수준에서 하나의 표현을 다른 표현 형태로 바꾸는 것을 말한다.

---

- 소프트웨어 생명 주기 모형 -프로토타입 모형

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

---

순환복잡도 계산

[화살표 수 - 노드 수 + 2]

---

cohesion 응집도

= 한 모듈 내의 각 구성 요소들이 공통의 목적을 달성하기 위하여 서로 얼마나 관련이 있는지의 기능적 '연관의 정도'를 나타낸다.

= 모듈이 독립적인 기능으로 잘 정의되어 있는 정도를 의미한다.

기능적 응집도 functional cohesion

: 가장 응집도가 높음

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

순차적 응집도 sequential cohesion

: 한 모듈 내부의 한 기능 요소에 의한 출력 자료가 다음 기능 원소의 입력 자료로서 제공되는 형태이다.

교환/통신적 응집도 communicational cohesion

: 동일한 입/출력을 사용하는 소작업들이 모인 모듈에서 볼 수 있다.

절차적 응집도 procedural cohesion

: 모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우이다.

논리적 응집도 logical cohesion

: 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들로 하나의 모듈이 형성되는 경우이다.

우연적 응집도 coincidental cohesion

: 가장 응집도가 약함

: 서로 다른 상위 모듈에 의해 호출되어 처리상의 연관성이 없는 서로 다른 기능을 수행하는 경우이다.

---

시스템 검사

성능 검사

: 모든 단계에서 수행된다.

: 통합 시스템의 맥락에서 소프트웨어의 실시간 성능을 검사한다.

---

자동화 예츨 도구들 중 Raleigh-Norden곡선 & Putnam의 예측모델에 기반을 둔 것은 SLIM이다.

---