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

소프트웨어

하드웨어를 동작시켜 작업을 편리하게 수행하도록 하는 프로그램

• 특징
• 상품성, 견고성, 복잡성, 순응성, 비가시성, 비마모성, 비제조성, 비과학성

시스템 구성 요소

입력, 처리, 제어, 피드백으로 이루어짐

소프트웨어 위기

소프트웨어 개발 속도가 하드웨어 개발 속도를 따라가지 못해 사용자의 요구사항을 처리할 수 없는 문제가 발생한 것을 의미

• 원인
• 특성에 대한 이해 부족
• 관리 부재
• 프로그래밍만 치중
• 기술에 대한 교육 부족

• 결과
• 인력 부족과 인건비 상승
• 성능 및 신뢰성 부족
• 유지보수가 어렵고 이에 따른 비용 증가
• 생산성 저하, 소프트웨어의 품질 저하

소프트웨어 공학의 개념

소프트웨어 위기를 극복하기 위한 방안으로 소프트웨어의 품질과 생산성 향상을 목적으로 함

• IEEE 표준 용어사전
• 개발, 운용, 유지보수, 폐기 처분에 대한 체계적인 접근 방안
• Fairley
• 한정된 비용과 기간 내에 소프트웨어를 생산하고 유지보수하는 데 관련된 기술적이고 관리적인 원리
• Boehm
• 과학적 지식을 소프트웨어 설계와 제작이 응용한 것으로 개발, 운용, 유지보수하는 데 필요한 문서 작성 과정

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

• 프로그래밍 기술을 계속적으로 적용해야 한다.
• 품질이 유지되도록 지속적으로 검증해야 한다.
• 개발 관련 사항 및 결과에 대한 명확한 기록을 유지해야 한다.

일반적인 소프트웨어 생명 주기

• 정의 단계
• 무엇을 처리하는 소프트웨어를 개발할 것인지 정의하는 단계
• 타당성 검토 단계, 계발 계획 단계, 요구사항 분석 단계

• 개발 단계
• 어떻게에 초점을 두고 실제적으로 소프트웨어를 개발하는 단계
• 설계 단계, 구현 단계, 테스트 단계

• 유지보수 단계
• 가장 많은 시간과 비용이 투입되는 단계로 여러 환경 변화에 따라 소프트웨어를 적응 및 유지시키는 단계

소프트웨어 생명 주기 모형(폭포수 모형)

• 개발 각 단계를 확실히 매듭짓고 다음 단계로 넘어가는 방식이며 전 단계로 되돌아갈 수 없다.(선형 순차적)
• 공학에서 가장 오래되고 고전적인 생명 주기
• 단계별 정의가 분명하고 전체 공조의 이해가 용이함
• 단계별 산출물이 정확하여 개발 공정의 기준점을 잘 제시함

• 개발 순서
• 타당성 검토    >    계획    >    요구 분석    >    설계    >    구현    >    시험    >    유지보수

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

• 사용자 요구사항을 정확히 파악하기 위해 견본품을 만들어 최종 결과들을 예측하는 모형
• 생명주기에서 유지보수 단계가 없어지고 개발 단계 안에서 유지보수가 이루어짐

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

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

• Boehm이 제안한 것으로 포폭수와 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형
• 나선을 따라 돌 듯이 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발하는 것
• 개발에 발생할 수 있는 위험을 관리하고 최소화하는 것을 목적으로 둔다.

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

프로젝트 관리

주어진 기간 내 최소의 비용으로 사용자를 만족시키는 시스템을 개발하는 전반적인 활동

• 효과적인 프로젝트 관리를 위한 3대 요소
• 사람,    문제,    프로세스

프로젝트 비용 결정 요소

• 프로젝트 요소
• 제품의 복잡도 시스템의 크기 요구되는 신뢰도

• 자원 요소
• 인적 자원, 하드웨어 자원, 소프트웨어 자원

• 생산성 요소
• 개발자의 능력, 경험, 주어진 개발 기간

비용 산정 기법(LOC 기법)

• 소프트웨어 각 기능의 원시 코드 라인 수의 비관치, 낙과니, 기대치를 측정하여 예측칙를 구하고 이를 이용하여 비용을 산정하는 기법
• 예측치 = (a+4m+b)/6        (a=낙관치, b=비관치, m=중간치(기대치))

• 공식
• 노력(인월)
• 개발기간 x 투입 인원
• LOC / 1인당 월평균 생상 코드라인 수

• 개발 비용
• 노력(인월) x 단위 비용(1인당 월평균 인건비)

• 개발 기간
• 노력(인월) / 투입 인원

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

비용 산정 기법(COCOMO)

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

• 개발 유형
• 조작형
• 중 소규모의 소프트웨어로 일괄 자료 처리나 과학 기술 계산용등 5만(50KDSI)라인 이하의 소프트웨어를 개발하는 유형
• 반분리형
• 조직형과 내장형의 중간형으로 트랜잭션 처리시스템이나 운영체제 등 30만(300KDSI)라인 이하의 소프트웨어를 개발하는 유형
• 내장형
• 초대형 규모 트랜잭션 처리 시스템이나 운영체제 등 30만(300KDSI) 라인 이상의 소프트웨어를 개발하는 유형

COCOMO 모형의 종류

• 기본형
• 소프트웨어 크기와 개발 유형만을 이용하여 비용을 산정하는 모형

• 중간형
• 기본 공식을 토대로 사용하나 제품 특성, 컴퓨터 특성, 개발 요원의 특성, 프로젝트 특성에 의해 비용을 산정하는 모형

• 발전형
• 중간형을 보완하여 만들어진 방법으로 개발 공정별로 보다 자세하고 정확하게 노력을 산출하여 비용을 산정하는 모형

브록스의 법칙

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

PERT/CPM

• 프로젝트 지연을 방지하고 일정을 계획하는 것으로 자원의 제약하에 비용을 적게 사용하면서 최단시간 완성을 위한 프로젝트 일정 방법
• 개발 기간을 결정하는 임계 경로(CP)를 제공한다.
• 통계적 모델을 적용해서 개별 작업에 대한 가장 근접한 시간 측정의 기준이 된다.

PERT

• 노드와 간선으로 구성되며 원 노드에는 작업을 간선에는 낙관치, 기대치, 비관치를 표시
• 전체 작업의 상호 관계를 표시하는 네트워크로 단계별 종료 시기를 결정하는 방법

CPM

• 프로젝트 완성에 필요한 작업을 나열하고 작업에 필요한 소유 기간을 예측하는데 사용하는 기법
• 노드와 간선으로 구성된 네트워크로 노드는 작업을 간선은 작업 사이의 전후 의존 관계를 나타냄
• 원형 노드는 각 작업을 의미하며 각 작업의 이름과 소유기간을 표시하고 박스 노드는 이정표를 의미하며 박스 노드 위에는 예상 완료 시간을 표시함

간트차트

프로젝트의 각 자억들이 언제 시작하고 종료되었는지 막대 도표를 이용하여 표시하는 프로젝트 일정표로 시간선 차트라고도 한다.

프로젝트 팀 구성

• 분산형 팀
• 팀원 모두가 의사 결정에 참여한느 비이기적인 구성 방식
• 의사소통 경로의 수 = (n(n-1))/2        n은 팀원의 수

• 중앙 집중형 팀
• 한 관리자가 의사결정 하고 구성원들은 그 결정을 따라는 구성 방식으로 책임 프로그래머 팀이라고도 함

• 계층 적팀
• 분산형 팀 구성과 중앙 집중형 팀 구성을 혼합한 형태
• 5~7명의 초보 프로그래머를 작은 그룹으로 만들어 각 그룹을 고급 프로그래머가 관리하게 함

품질 표준

명확하게 정의된 소프트웨어의 특성을 의미하며 품질을 평가하는 기준 항목

• 종류
• 정확성, 신뢰성, 효율성, 무결성, 사용 용이성, 유지보수성, 유연성, 시험 역량, 이식성, 재사용성, 상호 운용성

위험 관리

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

형상 관리(SCM)

• 개발 과정에서 소프트웨어의 생산물을 확인하고 소프트웨어 통제, 변경 상태를 기록하고 보관하는 일련의 관리 작업
• 소프트웨어 변경의 원인을 알아내고 제어하며 적절히 변경되었는지 확인하여 담당자에게 통보하는 작업
• 개발의 전 단계에 적용되는 활동으로 유지보수 단계에서 수행된다.
• 개발의 전체 비용을 줄이고 개발 과정의 문제점을 해결하여 방해 요인을 최소화하는 것을 목적으로 한다.

요구사항 분석의 어려움

• 사용자와 개발자의 지식 배경의 다양화 용어 불일치 등으로 의사소통 곤란
• 난이도 증가에 의한 소프트웨어의 복잡화
• 사용자 생각의 부정확성, 생각의 반복된 변경
• 애매하거나 어렵거나등 요구 명세서 작성이 어려움

자료 흐름도(DFD)

• 요구사항 분석에서 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법으로 버블 차트라고도 함
• 자료 흐름과 처리를 중심으로 하는 구조적 분석 기법에 이용된다.
• 자료 흐름도는 자료 흐름과 기능을 자세히 표현하기 위해 단계적으로 세분화된다.
• 단계 0의 자료 흐름도를 배경도라 하는데 이 배경도를 통해 전체 시스템의 범위를 표현한다.
• 각 프로세스에 대하여 개별적인 상세화 및 계층화가 가능하다.

자료사전(DD)

자료 흐름도 상에 있는 자료를 더 자세히 정의하고 기록한 것이며 데이터를 설명하는 데이터를 데이터 또는 메타데이터라고 한다.

자료 사전 표기 기호

• =      자료의 정의
• +      자료의 연결
• ()      자료의 생략
• |        자료의 선택
• {}       자료의 반복
• **     자료의 설명

HIPO

• 시스템의 분석 및 설계나 문서화할 때 사용되는 기법으로 입력, 처리, 출력의 기능을 나타낸다.
• 하향식 소프트웨어 개발을 위한 무서화 도구이다.
• 체계적 문서 관리가 가능하고, 기호, 도표 등을 사용하므로 보기 쉽고 이해가 쉽다.

HIPO의 종류

• 가시적 도표 (도식 목차)
• 시스템의 전체적인 기능과 흐름을 보여주는 계층 구조도

• 총제적 도표 (총괄 도표)
• 프로그램을 구성하는 기능을 기술한 것으로 입력, 처리, 출력에 대한 전반적인 정보를 제공하는 도표

• 세부적 도표 (상세 도표)
• 총제적 도표에 표시된 기능을 구성하는 기본 요소들을 상세히 기술한 도표

결합도(Coupling)

• 모듈 간에 상호 의존도를 나타낸다.
• 독립적인 모듈이 되기 위해서는 모듈 간의 결합도가 약해야 하며 의존하는 모듈이 적어야 함

결합도의 종류

• 자료 결합도
• 모듈 간의 인터페이스가 자료 요소로만 구성될떄의 결합도

• 스탬프 결합도
• 모듈 간의 인터페이스로 배열이나 레코드 등의 자료 구조가 전달될 떄의 결합도

• 제어 결합도
• 어떤 모듈이 다른 모듈 내부의 논리적인 흐름을 제어하기 위해 제어 신호를 이용하여 통신하거나 제어요소를 전달하는 결합도

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

• 공통 결합도
• 공통 데이터 영역을 여러 모듈이 사요할 때의 결합도

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

응집도(Cohesion)

• 정보 은닉 개념을 확장한 것으로 모듈이 독립적인 기능으로 정의되어 있는 정도를 나타냄
• 내부 요소에는 명령어, 명령어의 모임, 호출문 등이 있음
• 독립적인 모듈이 되기 위해서는 각 모듈의 응집도가 강해야 함

응집도 종류

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

• 순차적 응집도
• 모듈 내의 하나의 활동으로부터 나온 출력데이터를 다음 활동의 입력 데이터로 사용할 경우의 응집도

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

• 절차적 응집도
• 모듈이 다수의 관련 기능을 가질 떄 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우의 응집도

• 시간적 응집도
• 특정 시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 작성할 경우의 응집도

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

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

효과적인 모듈화 설계 방안

• 결합도를 줄이고 응집도는 높여서 모듈의 독립성을 높인다.
• 복잡도와 중복성을 줄이고 일관성을 유지시킨다.
• 유지보수가 용이해야 한다.
• 시스템의 전반적인 기능과 구조를 이해하기 쉬운 크기로 분해한다.
• 하나의 입구와 하나의 출구를 갖도록 한다.

Nassi-Schneiderman Chart

• 논리의 기술에 중점을 둔 도형을 이용한 표현 방법
• 순차 구조, 반복 구조, 선택 구조, 다중 선택 구종 등으로 표현
• GOTO나 화살표를 사용하지 않으며, 선택과 반복 구조를 시각적으로 표현한다.
• 이해하기 쉽고 코드 변환이 용이하다
• 읽기는 쉽지만 작성하기 어려우며 임의로 제어를 전이하는 것이 불가능하다.

구조적 프로그래밍

Dijkstara에 의해 제안된 것으로 소프트웨어의 생산과 코딩의 표준화 등을 위해 개발된 방법이다.

• 제어 구조
• 순차        명령을 순서적으로 나열함
• 선택        특정 논리에 기초하여 명령을 선택함
• 반복        순환을 제공함

화이트 박스 테스트

• 모듈의 원시 코드를 오픈시킨 상태에서 원시 코드의 논리적인 모든 경로를 검사하여 검사 사례를 설계하는 방법
• 모듈 안의 작동을 직접 관찰할 수 있으며 원시 코드의 모든 문장을 한번 이상 수행함으로써 수행된다.

화이트 박스 테스트 종류

• 기초 경로 검사
• Tom McCabe게 제안한 것으로 대표적인 화이트 박스 테스트 기법
• 검사 사례 설계자가 절차적 설계의 논리적 복잡성을 측정할 수 있게 해주고 측정 결과는 실행 경로의 기초를 정의하는 데 지침으로 사용됨

• 조건 검사
• 모듈 내에 있는 논리적 조건을 검사하는 검사 사례 설계 기법

• 루프 검사
• 반복 구조에 초점을 맞춰 실시하는 검사 사례 설계 기법

• 데이터 흐름 검사
• 프로그램에서 변수의 정의와 변수 사용의 위치에 초점을 맞춰 실시하는 검사 사례 설계 기법

제어 흐름도

제어 흐름을 표현하기 위해 사용되는 그래프

순한 복잡도

한 프로그램의 논리적인 복잡도를 측정하기 위한 소프트웨어의 척도로 제어 흐름도 이론에 기초를 둠

• 순환 복잡도 계산
• 활살표 - 노드 수 + 2 = 순한 복잡도

블랙 박스 테스트

소프트웨어의 각 기능이 완전히 작동되는 것을 입증하는 검사로 기능검사라고도 한다.

블랙 박스 테스트의 종류

• 동치 분활 검사
• 입력 자로에 초점을 맞춰 검사 사례를 만들고 검사하는 방법

• 경계값 분석
• 동치 분할 기법을 보완하기 위한 기법으로 입력 조건의 중간값보다 경계값에서 오류가 발생될 확률이 높다는 점을 이용하여 입력 조건의 경계값을 검사 사례로 선정하여 검사

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

• 오류 예측 검사
• 과거의 경험이나 확인자의 감각으로 검사하는 기법

• 비교 검사
• 여러 버전의 프로그램에 동일한 검사 자료를 제공하여 동일한 결과가 출력되는지 검사하는 기법

단위 검사

코딩이 이루어진 후 최소 단위인 모듈에 초점을 맞추어 검사하는 것

하향식 통합 검사

상위 모듈에서 하위 모듈 방향으로 통합하면서 검사하는 기법

상향식 통합 검사

하위 모듈에서 상위 모듈 방향으로 통합하면서 검사하는 기법

검증 검사

소프트웨어가 사용자의 요구사항을 충족시키는가에 중점을 두고 검사하는 기법

검증 검사의 종류

• 형상 검사
• 소프트웨어 구성 요소, 목록, 유지보수를 지원하기 위해 필요한 모든 사항들이 제데로 표현되었는지를 검사하는 기법

• 알파 검사
• 개발자의 장소에서 사용자가 개발자 앞에서 행하는 검사 기법

• 베타 검사
• 선정된 최종 사용자가 여러 명의 사용자 앞에서 수행하는 검사 기법

시스템 검사

개발된 소프트웨어가 시스템에서 완벽하게 수행되는가를 검사하는 것

• 종류
• 복구 검사, 보안 검사, 강도 검사, 성능 검사

디버깅

검사 단계에서 검사 사례에 의해 오류를 찾은 후 그 오류를 수정하는 과정

객체지향 기법

• 현실의 기계 부품처럼 하나의 객체로 만들어 부품으로 기계를 조립하는 것처럼 객체를 조립해서 작성할 수 있도록 하는 기법
• 유지 보수가 쉬우며 재사용 및 확장이 용이해 소프트웨어를 빠르게 개발할 수 있다.

객체지향 기법의 구성 요소

• 객체
• 데이터와 함수 기능을 가지고있음

• 클래스
• 객체의 집합으로 객체의 일반적인 타입을 의미한다.

• 메시지
• 객체들 간의 상호작용을 하는데 사용되는 수단으로 객체에게 어떤 행위를 하도록 지시하는 명령

객체지향 기법의 주요 기본 원칙

• 캡슐화
• 데이터와 데이터를 처리하는 함수를 하나로 묶는 것
• 객체들의 재사용이 용이함
• 인터페이스가 단순해지고 객체간의 결합도가 낮아짐

• 정보 은닉
• 캡슐화에서 가장 중요한 개념으로 다른 객체에 자신의 정보를 숨기고 연산만을 통하여 접근을 혀용하는 것

• 상속성
• 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받는것

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

• 다형성
• 메시지에 의해 객체가 연산을 수행하게 될때 하나의 메시지에 대해 각 객체가 가지고 있는 고유한 방법으로 응답할 수 있는 능력

객체지향 분석 방법론

• Rumbaugh 방법
• 일반적으로 사용되는 방법으로 분석 활동을 객체 모델, 동적 모델, 기능 모델로 나누어 수행하는 방법

• Booch  방법
• 미시적, 거시적 개발 프로세스를 모두 사용하는 분석 방법으로 클래스와 객체들을 분석 및 식별하고 클래스의 속성과 연산을 정의함

• Jacobson 방법
• Use Case를 강조하여 사용하는 분석 방법

• Coad와 Yourdon 방법
• E-R다이어그램을 사용하여 객체의 행위를 모델링하며 연산과 메시지 연결 정의 등의 과정으로 구성하는 기법

• Wirfs-Brock 방법
• 분석과 설계간의 구분이 없고 고객 명세서를 평가해서 설계 작업까지 연속적으로 수행하는 기법

Rumbaugh 분석 기법

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

객체지향 설계 단계

문제정의    >    요구 명세화    >    객체연산자 정의    >    객체 인터페이스 결정    >    객체 구현

소프트웨어의 재사용

• 이미 개발된 소프트웨어의 전체 혹은 일부분을 다른 소프트웨어에 사용하는 것
• 개발의 품질과 생산성을 높이기 위한 방법

소프트웨어 재공학

• 기존 소프트웨어를 파기하지 않고 새로운 요구에 맞도록 수정 보안하거나 새로운 기능을 추가하여 성능을 향상시키는 것
• 유지보수 비용이 개발 비용의 대부분을 차지하는 문제를 고려하여 개조 및 개선을 통해 유지보수성과 품질을 향상시키려는 기술
• 유지보수 생산성 향상을 통해 소프트웨어 위기를 해결하는 방법

소프트웨어 역공학

기존 소프트웨어를 분석하여 개발 과정과 데이터 처리 과정을 설명하는 분석 및 설계 정보를 재발견하거나 다시 만들어내는 작업

• 목표
• 복잡한 시스템을 다루는 방법 구현
• 다른 뷰의 생성
• 잃어버린 정보의 복구 및 제거
• 부작용의 발견

CASE

• 개발 과정에서 사용되는 요구분석, 설계구현, 검사 및 디버깅 과정 전체 또는 일부를 컴퓨터와 전용 소프트웨어 동구를 사용하여 자동화하는 것
• 소프트웨어 생명 주기의 전체 단계를 연결해 주고 자동화해주는 통합된 도구를 제공해주는 기술

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

• 이점
• 개발 기간 단축 및 비용 절감, 품질 향상, 유지보수 용이, 생산성 향상, 재사용성 향상, 개발주기의 표준화 등

CASE 분류

• Upper CASE
• 생명 주기의 전반부에 사용되는 것으로 문제를 기술하고 계획하며 요구 분석과 설계 단계를 지원하는 CASE

• Lower CASE
• 생명주기 하반부에 사용되는 것으로 코드의 작성과 테스트 문서화하는 과정을 지원하는 CASE

• Intergrate CASE
• 생명주기에 포함되는 전체 과정을 지원하기 위한 CASE

CASE 정보 저장소

소프트웨어를 개발하는 동안에 모아진 정보를 보관하여 관리하는 곳으로 오늘날에는 데이터베이스가 정보 저장소 역할을 담당