[정보처리기사 필기] 소프트웨어공학 정리

========소프트 웨어 공학=========

 

소프트웨어 공학의 선형 순차 모형 순서

분석 -> 설계 -> 구현 -> 테스트 -> 유지보수

 

· 소프트웨어 위기의 원인**중요

- 소프트웨어의 특징에 대한 이해 부족

- 소프트웨어의 관리 부재

- 프로그래밍에만 치중

- 소프트웨어의 생산성 저조

 

· 소프트웨어 재공학의 주요 활동

- 분석(Analysis) : 재공학의 대상 선정

- 개조/재구조/재구성(Restructuring) : 산대적으로 같은 추상적 수준에서 하나의 표현을 다른 표현 형태로 바꿈, 소프트웨어의 기능과 외적인 동작은 안 바뀜

- 역공학(Reverse Engineering) : 기존 SW를 분석하여 SW 개발 과정과 데이터 처리 과정을 설명하는 분석 및 설계 정보를 재발견하거나 다시 만듬, 대상 SW가 있어야 함, 재문서화

- 이식(Migration) : 다른 운영체제나 하드웨어 환경에서 사용할 수 있도록 변환

 

· 임계경로는 가장 오래 걸린 기일

 

· 자료 흐름도(DFD)의 구성 요소*(중요)

- 프로세스 : 원, 자료변환시키는시스템의 한 부분

- 자료 흐름 : 화살표, 자료의 이동 나타냄

- 자료 저장소 : 평행선, 자료 저장

- 단말 : 사각형, 시스템과 교신하는 외부 개체

 

· 자료 흐름도

- 자료 흐름 그래프 또는 버블차트

- 구조적 분석 기법에 이용

- 시간의 흐름이 아니라 자료의 흐름 , 변환과정

 

· 자료사전에 사용되는 기호***(중요)**(중요)

- “ = ” : 자료의 정의

- “ + ” : 자료의 연결

- “ ( ) ” : 자료의 생략

- “ [ | ] ” : 자료의 선택

- “ { } ” : 자료의 반복*(중요)

- “ * * ” : 자료의 설명

 

· 화이트 박스 테스트 *******(중요)

모듈의 원시코드를 오픈시킨 상태에서 원시코드의 논리적인 모든경로를 검사하여 검사 사례를 설계하는 방법

- 기초 경로 검사 –논리흐름도 -순환복잡도

- 제어 구조 검사 (조건,루프,데이터흐름검사)

· 블랙 박스 검사 : 제품이 수행할 특정 기능을 알기 위해서 각 기능이 완전히 작동되는 것을 입증하는 검사, 기능 검사 ,인터페이스 오류 행위 및 성능 오류 초기화와 종료 등 오류 발견

 

·블랙박스 테스트 기법 (검증시험)*******(중요)

동치분할검사 (equivalence paritioning testing) : 입력 자료에 초점을 맞춰 검사사례 만들고 검사

경계값 분석 (boundary value analysis)

: 동치 분할 기법 보완

원인-효과 그래프 : 입력 데이트 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석하여 효용성 높은 검사 사례를 선정하여 검사

오류 예측 검사 (fault based)

: 과거의 경험이나 확인자의 감각으로 검사

비교 검사 :동일한검사자료 동일한결과 출력확인

 

·프로젝트 관리를 위한 3P*******(중요)

PEOPLE, PROBLEM, PROCESS

 

· 검증검사(Validation Test, 블랙 박스 검사)***(중요)*(중요)

- 형상검사 : 소프트웨어 구성요소, 목록, 유지보수를 지원하기 위해 필요한 사항 표현 검사

- 알파 검사 : 사용자가 개발자 앞에서 시행

- 베타 검사 : 최종사용자가 여러 사용자 앞에서

 

· CASE***(중요)

- 소프트웨어 개발 과정을 전용 소프트웨어 도구를 사용해 자동화

- 생산성 향상, 운용 활동 효과적 관리통제

- 개발기간 단축, 개발 비용 절감

- 품질이 향상, 유지보수 간편

- SW 개발 단계의 표준 확립

- 개발 도구와 개발 방법론이 결합

 

**(중요)

· 클래스 : 객체 지향 기법에서 하나 이상의 유사한 객체들을 묶어서 하나의 공통된 특성 표현

· 함수(Function) : 객체가 수행하는 기능

· 메소드(Method) : 상태 참조 변경 수단, 동작(객체가 메시지를 받아 실행해야 할 객체의 구체적인 연산)

· 메시지(Message) : 객체들 간의 상호작용, 객체의 메서드를 일으키는 외부의 요구사항

· 캡슐화의 특징(*중요*)

- 세부내용이 외부에 은폐되어 변경할 때 오류의 파급효과가 적다

- 재사용 용이

- 인터페이스 단순, 결합도 낮아짐(*중요*)

 

· 객체지향 분석의 방법론

- 부치 방법 : 미시적 개발 프로세스와 거시적 개발 프로세스를 모두 사용하는 분석방법

- jacobson : use case 강조하여 사용

- coad와 yourdon : E-R다이어그램 사용하여

개체들의 활동들을 데이터 모델링하는데초점

- Wirfs-Brock : 분석과 설계간의 구분이 없고,

고객명세서를평가해서 설계 작업까지연속적수행

 

· 럼바우 분석 기법(*중요*)

(객체 모델링, 동적 모델링, 기능 모델링)**(중요)

- 객체 모델링(Object M) : 정보 모델링이라고도 하며 시스템에서 요구되는 객체를 찾아내어 속성과 연산 식별 및 객체들 간의 관계를 규정하여 객체 다이어그램으로 표시 (object modeling)

- 동적 모델링(Dynamic M) : 시간의 흐름에 따른 객체들 사이의 제어 흐름, 상호작용, 동작순서등의 시스템 동적인 행위를 표현

- 기능 모델링(Functional M) : 다수의 프로세스들 간의 자료 흐름을 중심으로 처리 과정을 표현한 모델링 (상태도, 자료흐름도)**(중요)

 

· 소프트웨어에 대한 인터페이스**(중요)

- 소프트웨어에 의해 간접적으로 제어되는 장치와 소프트웨어를 실행하는 하드웨어

- 기존의 소프트웨어와 새로운 소프트웨어를 연결하는 소프트웨어

- 일련의 절차적 운영상 소프트웨어를 앞서거나 뒤서게 하는 절차들

 

· 컴포넌트(component)**(중요)

: 소프트웨어 재사용과 관련하여 객체들의 모임, 대규모 사용 단위로 정의

 

· 컴포넌트 재사용을 위한 컴포넌트 기반 개발 활동**(중요)

-후보 컨포넌트가 요구되는 기능을 수행하는지를 조사

-컴포넌트 라이브러리가 컴포넌트 확장 언어를 제공하면 그레이-박스 랩핑을 적용

-어플리케이션 구현을 위해 검증, 개작, 개발된 컴포넌트들을 조립하는 컴포넌트 합성을 수행

 

· 시스템의 구성요소

입력 : 조건을 시스템에 투입

처리 : 처리 방법과 조건에 따라 처리(process)

출력 : 결과를 산출

제어 : 올바르게 진행되는지 감독

피드백 : 목표 달성을 위해 반복 처리

 

· CPM(Critical path method 임계경로기법)

- 작업나열하고 필요한 소요 기간 예측

- 노드는 작업을 간선은 전후의존관계 나타냄

- 작업순서의존관계,동시수행 한눈에 볼수있음

 

· 품질표준(목표)**(중요)

품질표준	의미
정확성**(중요) (Correctness)	사용자의 요구 기능 충족시키는 정도
신뢰성 (Reliability)	요구된 기능 오류없이 수행
효율성 (Efficiency)	자원 쓸데없이낭비하지않음
무결성 (Integrity)	허용되지 않는 사용이나 자료 변경 제어
사용 용이성 (Usability)	필요한 노력을 최소화
유지보수성 (Maintainability)	변경, 오류 사항의 교정에 대한 노력 최소화
유연성(*중요*) (Flexibility)	얼만큼 쉽게 수정
시험역량 (Testability)	의도된 기능 수행되도록 보장하기 위해 프로그램을 시험 할 수 있는 정도
이식성**(중요) (Portability)	다양한하드웨어 환경에서도 운용가능하도록 쉽게 수정
재사용성 (Reuseability)	전체나 일부 소프트웨어를 다른 목적으로 사용 할 수 있는가 하는 정도
상호 운용성 (Interoperability)	다른 소프트웨어와 정보를 교환 할 수 있는 정도

 

· 정형기술검토의 검토 지침 사항**(중요)

- 제품의 검토에만 집중

- 문제 영역을 명확히 표현

- 해결책이나 개선책에 대해 논하지 말라

- 참가자의 수를 제한하고 사전 준비 강요

- 자원과 시간 일정을 할당

- 모든 검토자들을 위해 의미 있는 훈련 행하라

- 검토자들은 사전에 작성한 메모를 공유

- 검토 과정과 결과를 재검토

 

· 소프트웨어 범위 결정 주요 요소(*중요*)

: 성능, 신뢰도, 제약 조건

 

· 토큰 = 채널 사용권(*중요*)

· 프레임 = 전송데이터 + 제어정보

· 응집도***(중요) : 한 모듈 내부의 처리 요소들 간의 기능적 연관도를 나타내며 , 모든 내부 요소는 명령어, 명령어의 모임, 호출문, 특정 작업수행 코드 등

기능적 응집도	응집도 강함, 모듈 내부의 모든 기능 요소들이 단일 문제와 연관되어 수행
순차적 응집도	모듈의 구성 요소가 하나의 활동으로부터 나온 출력자료를 그 다음 활동의 입력 자료로 사용하는 같은 모듈 내에서의 응집의 정도
교환(통신)적 응집도	동일한 입력과 출력을 사용하는 소작업들이 모인 모듈
절차적 응집도	기능을 순차적으로 수행
시간적 응집도	특정 시간에 처리되는 몇 개의 기능 모아 하나의 모듈작성할 경우 응집도
논리적 응집도	유사한 성격 갖거나 특정형태로 분류되는 처리요소들로 하나의 모듈이 형성되는 경우
우연적 응집도	서로 관련 없는 요소

 

· 소프트웨어 재사용이 이점(*중요*)

- 개발 시간과 비용을 단축

- 품질을 향상

- 개발의 생산성 향상

- 실패의 위험을 감소

- 시스템 구축 방법에 대한 지식을 공유(*중요*)

 

· 유지보수의 유형*******(중요)

- 수정(Corrective) 보수 = 수리, 교정, 정정, 하자 보수 : 시스템을 운영하면서 검사 단계에서 발견하지 못한 오류를 찾아 수정

- 적응(Adaptive) 보수 = 환경 적응, 조정 보수 : 소프트웨어 수명 기간 중에 발생하는 환경의 변화를 기존의 소프트웨어에 반영

- 완전화(Perfective) 보수 = 기능 개선, 기능 보수 : 본래 기능에 새로운 기능을 추가하거나 성능을 개선하기 위해 확장(제일 많은 비용)**(중요)

- 예방(Preventive) 보수 : 미래에 유지보수를 용이하게 하거나 기능을 향상시키기 위해

 

· 소프트웨어의 생명 주기 모형

- 폭포수 모형(Waterfall) : 각 단계를 확실히 매듭 짓고 결과를 승인 후 다음 단계, 이전단계로 넘어가지 못함

- 프로토타입 모형(Prototype = 원형) **(중요)

: 개발 될 소프트 웨어에 대한 견본품을 만들어 결과물 예측

- 나선형 모형 : 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형

- RAD 모형 : 매우 빠르게 선형 순차적 모델을 적용, 빠른 개발 주기

 

· 객체 지향 분석

- 요구사항을 분석하여 요구된 문제와 관련 된 모든 클래스(객체), 이와 연관 된 속성과 연산, 그들 간의 관계들을 정의

- 클래스, 객체, 속성, 연산들을 표현해서 문제를 모형화

- 객체는 클래스로부터 인스턴스화 되고, 이 클래스를 식별하는 것이 객체지향 분석의 목적

- 소프트웨어를 개발하기 위한 업무를 객체와 속성, 클래스와 멤버, 전체와 부분으로 나누어 분석

· COCOMO 모형*******(중요)

- 보헴이 제안, LOC(원시 코드라인 수)에 의한 비용 산정 기법

- 같은 규모의 소프트웨어라도 그 유형에 따라 비용이 다르게 산정

- 소프트웨어 프로젝트 유형에 따라 다르게 책정되는 비용 산정 수식을 이용

-

- 계산 법 : 총 비용 = 노력(인월)*단위비용(1인당 월평균 인건비)

 

· 객체지향 기법에서 사용되는 용어*******(중요)

- 캡슐화(Encapsulation) : 데이터와 데이터를 처리하는 함수를 하나로 묶은 것

- 정보 은닉(Information Hiding) : 다른 객체에게 자신의 정보를 숨기고 자신의 연산만을 통하여 접근을 허용하는 것

- 추상화(Abstraction) : 불필요한 부분을 생략하고 객체의 속성 중 가장 중요한 것에만 중점을 두어 개략화 하는 것

- 상속성(Inheritance) : 상위 속성과 연산을 하위 클래스가 물려 받는 것

- 다형성(Polymorphism) : 각 객체가 가지고 있는 고유한 방법으로 응답

· OMA 레퍼런스 모델의 구성 요소 : 객체 요구 매개자(ORB), 객체 서비스, 공통 기능, 도메인 인터페이스, 응용 인터페이스

 

· HIPO : 시스템의 기능을 여러 개의 고유 모듈로 분할하여 이들간의 인터페이스를 계층구조로 표현한 도형 또는 도면(가시적 도표, 총체적 도표, 세부적 도표)

 

ALIEN CODE**(중요)

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

 

· 결합도(낮음에서 높음 순)**(중요)

- 자료 결합도 : 모듈 간의 내용을 전혀 알 필요가 없는 상태로서 한 모듈의 내용을 변경하더라도 다른 모듈에는 전혀 영향을 미치지 않음

- 스탬프(검인) 결합도 : 모듈 간의 인터페이스로 배열이나 레코드 등의 자료구조가 전달 될 때

- 제어 결합도 : 한 모듈에서 다른 모듈로 논리적 흐름을 제어하는데 사용한 제어요소가 전달될 때

- 외부 결합도 : 어떤 모듈에서 외부로 선언한 데이터를 다른 모듈에서 참조할때의 결합도

- 공통(공유) 결합도 : 공유되는 공통 데이터 영역을 여러 모듈이 사용할 때(가장 강한 결합도)

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

 

· CASE의 종류

- 상위(Upper) CASE***(중요) : 소프트웨어 생명 주기의 전반부에 사용, 문제를 기술하고 계획, 요구분석과 설계단계 지원

- 하위(Lower) CASE : 소프트웨어 생명 주기의 하반부에 사용, 코드의 작성과 테스트, 문서화 하는 과정을 지원

- 통합(Integrate) CASE : 소프트웨어 생명 주기에 포함되는 전체 과정을 지원, 공통의 정보 저장 장소와 통일 된 사용자 인터페이스 사용 도구들을 통합

 

· Method : 객체가 메시지를 받아 실행해야 할 객체의 구체적인 연산

개체(Entity) : 소프트웨어에 의해 인식되는 여러 종류의 자료

실체(Instance) : 하나의 클래스에 속하는 각각의 객체**(중요)

클래스(Class) : 공통된 속성과 연산을 갖는 객체의 집합, 객체의 일반적인 타입을 의미

· N-S 차트 : 연속(Sequence), 선택 및 다중 선택(If ~ then ~ Else, Case), 반복(Repeat ~ Until, While)

 

· 소프트웨어 형상관리 기능(*중요*)

- 형상 식별 : 형상 관리 대상에 이름과 관리번호를 부여하고 계층구조로 구분하여 수정 및 추적에 용이하도록 하는 작업

- 변경 제어 : 식별된 형상 항목의 변경 요구를 검토하여 현재의 기준선이 잘 반영 될 수 있도록 조정하는 작업

- 형상 감사 : 기준선의 무결성을 평가하기 위해 확인, 검증, 검열 과정을 통해 공식적으로 승인

- 형상 상태 보고 : 형상의 식별, 통제, 감사 작업의 결과를 기록 관리하고 보고서 작성

- 버전 제어 : 소프트웨어 처리 시 생성된 다른 버전의 형상 항목을 관리하고 이를 위해 특정 절차와 도구를 결합시키는 작업

 

현상관리 대상

 

· 자료 흐름도의 구성 요소**(중요)**(중요)

(프로세스, 자료흐름, 단말, 자료저장소)

- ◯(프로세스) -자료를 변환시키는 시스템의 한 부분

-처리 공정

- → (자료 흐름) : 자료의 이동

- □ (단말) : 시스템과 교신하는 외부 개체

- 〓 (자료 저장소)

 

· 브룩스 법칙 : 새로운 인원을 투입하면 일정은 더욱 지연**(중요)

 

· 순환 복잡도 계산 : 화살표 수 - 노드 수 + 2

 

· 생산성 = 원시 코드 라인수/노력

 

PERT차트**(중요)

-작업들 간의 상호 관령성, 결정 경로, 경계시간, 자원할당을 제시

 

소프트웨어 품질 측정(개발자 관점)*(중요)

- 정확성

- 무결성

- 일관성