[(구)정처기/컴퓨터일반] (4) 소프트웨어 공학 자주 틀리는 내용 정리

4 분 소요

<p class="notice--warning"><span style="color:red;font-weight:bold;">주의)</span>
해당 내용은 (구)정보처리기사, 컴퓨터일반 내용을 기반으로 문서화하였습니다.
수정이 필요하거나, 부족한 내용이 있을시 답글을 남겨주시면 해당 항목을 수정하겠습니다.</p>

<hr />

<h3 id="소프트웨어-생명주기">소프트웨어 생명주기</h3>
<ul>
  <li>나선형 모델
    <blockquote>
      <p>계획 수립(Planning) → 위험 분석(Risk analysis) → 개발(Engineering) → 고객 평가(Customer evaluation)</p>
    </blockquote>
  </li>
</ul>

<h3 id="소프트웨어-범위-결정-사항">소프트웨어 범위 결정 사항</h3>
<ul>
  <li>기능, 성능, 제약 조건, 개발 인원, 일정 계획</li>
  <li>위험성을 최소화 목적</li>
</ul>

<h3 id="소프트웨어-비용-측정-4가지-원칙">소프트웨어 비용 측정 4가지 원칙</h3>
<ul>
  <li>소프트웨어 비용 측정을 최대한 지연</li>
  <li>분해 기술(단계별, 인월별 분해) 이용</li>
  <li>실험적 비용 측정 모델을 이용</li>
  <li>자동화 도구 이용</li>
</ul>

<h3 id="비용-측정-방법론">비용 측정 방법론</h3>
<ul>
  <li>COCOMO(COnstructive COst MOdel)
    <ul>
      <li>Boehm, 상향식, 수학적 산정 기법</li>
      <li>변화 모형(Basic, Intermediate, Detailed)</li>
      <li>규모 모형(Organic, Semi-detached, Embedded)</li>
    </ul>
  </li>
  <li>Putnam 모형
    <ul>
      <li>시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력분포도 곡선</li>
      <li>기초로 만든 자동화 도구 SLIM</li>
      <li>대형 프로젝트의 노력 분포 산정에 용이</li>
    </ul>
  </li>
</ul>

<h3 id="cpmcritical-path-method">CPM(Critical Path Method)</h3>
<ul>
  <li>병행 작업이 가능하도록 계획</li>
  <li>비용측정은 하지 않음</li>
  <li>이전 작업이 모두 완료되지 않으면 다음 작업으로 진행 불가</li>
  <li>정확한 일정 예측은 불가능</li>
</ul>

<h3 id="소프트웨어-설계-모형">소프트웨어 설계 모형</h3>
<ul>
  <li>문서량 기준 : 데이터(DD, 메타데이터) ⇒ 구조(구조도) ⇒ 관계 ⇒ 절차(PDL 알고리즘)</li>
  <li>노력 기준 : 절차 ⇒ 관계 ⇒ 구조 ⇒ 데이터</li>
</ul>

<h3 id="hipohierarchy-plus-input-process-output">HIPO(Hierarchy plus Input Process Output)</h3>
<ul>
  <li>하향식 설계 기법, IBM에서 개발한 프로그램을 기능 위주로 문서화</li>
  <li>입력/처리/출력 구성, 소규모 프로젝트에 적합</li>
  <li>도식 목차(가시적 도표, Visual Table of Contents) : 전체적인 흐름과 구조</li>
  <li>총괄 도표(총체적 도표, Overview Diagram) : 입력, 처리, 출력 등의 기능 명확히 표현</li>
  <li>상세 도표(세부적 도표, Detail Diagram) : 총괄 도표의 일부 기능을 구체적으로 표현</li>
</ul>

<h3 id="자료-흐름-설계-과정">자료 흐름 설계 과정</h3>
<ul>
  <li>정보 흐름의 유형을 설정</li>
  <li>흐름의 경계를 표시</li>
  <li>자료 흐름도를 프로그램 구조로 사상 ⇒ 변환 사상(Transform Mapping)</li>
  <li>제어 계층을 분해시켜서 정의</li>
  <li>경험적 방법으로 구체화</li>
</ul>

<h3 id="결합도약--강">결합도(약 → 강)</h3>
<ul>
  <li>데이터 결합도(Data Coupling)</li>
  <li>구조 결합도(Stamp Coupling) : 두 모듈이 매개 변수로 자료를 전달할 때, 자료 구조 형태</li>
  <li>제어 결합도(Control Coupling)</li>
  <li>외부 결합도(Extern Coupling)</li>
  <li>공통 결합도(Common Coupling) : 두 모듈이 동일한 전역 데이터를 접근</li>
  <li>내용 결합도(Content Coupling) : 하나의 모듈이 직접적으로 다른 모듈의 내용 참조</li>
</ul>

<h3 id="응집도약--강">응집도(약 → 강)</h3>
<ul>
  <li>우연적 응집도(Coincidental Cohesion)</li>
  <li>논리적 응집도(Logical Cohesion)</li>
  <li>시기적 응집도(Temporal Cohesion)</li>
  <li>절차적 응집도(Procedural Cohesion)</li>
  <li>통신적 응집도(Communication Cohesion)</li>
  <li>순차적 응집도(Sequential Cohesion)</li>
  <li>기능적 응집도(Functional Cohesion)</li>
</ul>

<h3 id="객체-분석">객체 분석</h3>
<ul>
  <li>형식적인 전략으로 기술</li>
  <li>모델링 구성 요소인 클래스, 객체, 속성, 연산들을 표현해서 문제를 모형화</li>
  <li>E-R 다이어그램 적합, 개념적으로 파악</li>
</ul>

<h3 id="객체-설계">객체 설계</h3>
<ul>
  <li>구체적인 절차, 객체의 속성과 자료 구조를 표현</li>
  <li>서브 클래스와 메시지 특성을 세분화하여 세부사항을 정제화</li>
  <li>사용자 중심, 대화식 프로그램의 개발에 적합<br />
cf) 객체 구현 : 객체의 정의</li>
</ul>

<h3 id="객체지향-기법-vs-구조적-프로그래밍-기법">객체지향 기법 vs 구조적 프로그래밍 기법</h3>
<ul>
  <li>추상적 자료형  vs 절대적 자료형</li>
  <li>객체 사용 vs 함수 사용</li>
  <li>메시지를 통해 객체 호출 vs 매개 변수를 통해 함수 호출</li>
  <li>전역 변수에 영향 없음 vs 전역 변수에 영향 받음</li>
</ul>

<h3 id="화이트-박스-검사-방법">화이트 박스 검사 방법</h3>
<ul>
  <li>기초 경로 검사(Basic Path Testing)
    <ul>
      <li>가능한 경로를 어느 정도 통과하는지의 적용 범위성 측정</li>
      <li>복잡도(Cyclomatic Complexity)</li>
      <li>V - E + R = 2 (V : 노드의 수, E : 간선의 수, R : 영역의 수)</li>
      <li>화살표로 둘러싸인 면의 수 + 1</li>
    </ul>
  </li>
</ul>

<h3 id="블랙-박스-검사-방법">블랙 박스 검사 방법</h3>
<ul>
  <li>균등 분할(Equivalence Partitioning) : 정상 데이터 / 비정상 데이터</li>
  <li>한계값 분석(Boundary Value Analysis) : 범위 한계 위주</li>
  <li>원인-결과 그래프(Cause-Effect Graphing) : 임의의 자료 입력 ⇒ 정상 출력 확인</li>
  <li>오류 예측(Error Guessing) : 데이터 확인 방법, 위 3가지 이외 오류 검사</li>
  <li>비교 검사 : 하나의 프로그램을 여러 컴퓨터에서 테스트</li>
</ul>

<h3 id="소프트웨어-검사-단계">소프트웨어 검사 단계</h3>
<ul>
  <li>단위 검사(Class) ⇒ 통합 검사 ⇒ 검증 검사 ⇒ 시스템 검사</li>
  <li>cf) 개발 순서 : 시스템 공학 ⇒ 요구 분석 ⇒ 설계 ⇒ 코딩(구현)</li>
</ul>

<h3 id="통합-검사">통합 검사</h3>
<ul>
  <li>하향식(Top Down) 통합 검사 : 가짜 모듈이 필요(Stub), 회귀 검사, 프로그램 전체 실행</li>
  <li>상향식(Bottom Up) 통합 검사 : Cluster, Driver, 중요한 모듈 우선 검사 가능</li>
  <li>클러스터 결함 ⇒ 드라이버 작성 ⇒ 클러스터 검사 ⇒ 드라이버 제거 후 상위 결합</li>
</ul>

<h3 id="유지보수-작업의-종류">유지보수 작업의 종류</h3>
<ul>
  <li>하자보수(=수리보수, Corrective M) : 잠재적인 오류 수정</li>
  <li>기능 개선(=완전보수, Perfective M) : 기능의 수정, 추가, 전반적인 기능 개선 ⇒ 비용 많음</li>
  <li>환경 적응(=적응보수, Adaptive M) : 환경 변화에 대응하여</li>
  <li>예비 조치(=예방보수, Preventive M) : 미리 예측하여 준비</li>
</ul>

<h3 id="품질-목표-항목">품질 목표 항목</h3>
<ul>
  <li>정확성(Correctness) : 요구사항 충족시키는 정도</li>
  <li>신뢰성(Reliability) : 요구된 기능을 오류없이 수행하는 시스템 능력 정도</li>
  <li>효율성(Efficiency) : 최소한의 처리 시간과 기억 장소를 소유하여 요구된 기능 수행</li>
  <li>유연성(Flexibility) : 새로운 요구사항에 접하여 쉽게 수정될 수 있는 능력</li>
</ul>

<h3 id="omaobject-management-architecture-레퍼런스-모델">OMA(Object Management Architecture) 레퍼런스 모델</h3>
<ul>
  <li>객체 간의 관계를 표현하는 표준 참조 모델</li>
  <li>Object Service, Common Facilities, Domain Interface, Application Interface</li>
</ul>

<h3 id="소프트웨어-재공학reengineering">소프트웨어 재공학(Reengineering)</h3>
<ul>
  <li>개조(Restructuring) : SW 기능을 변경하지 않으면서 SW 형태에 맞게 수정</li>
  <li>같은 추상적인 수준에서 하나의 표현을 다른 형태로 바꾸는 작업</li>
  <li>분석(Analysis) : 기존 SW의 명세서를 확인하여 SW 동작을 이해, 재공학 대상 선정</li>
  <li>재개발(Redevelopment) : 기존의 SW 삭제 ⇒ 새롭게 개발</li>
</ul>

<h3 id="소프트웨어-재사용-단위">소프트웨어 재사용 단위</h3>
<ul>
  <li>명령어, 모듈, 요구분석서, 설계, 코딩 ⇒ 개발 비용은 변하면 안됨</li>
</ul>

주의) 해당 내용은 (구)정보처리기사, 컴퓨터일반 내용을 기반으로 문서화하였습니다. 수정이 필요하거나, 부족한 내용이 있을시 답글을 남겨주시면 해당 항목을 수정하겠습니다.

소프트웨어 생명주기

나선형 모델

계획 수립(Planning) → 위험 분석(Risk analysis) → 개발(Engineering) → 고객 평가(Customer evaluation)

프로젝트 계획 단계의 특징

정의 단계의 시작 단계
개발 비용을 추정
유지보수 비용은 개발이 모두 끝난 뒤 책정
계획 단계에서 프로젝트 관리자의 임무는 매우 중요

소프트웨어 범위 결정 사항

기능, 성능, 제약 조건, 개발 인원, 일정 계획
위험성을 최소화 목적

소프트웨어 비용 측정 4가지 원칙

소프트웨어 비용 측정을 최대한 지연
분해 기술(단계별, 인월별 분해) 이용
실험적 비용 측정 모델을 이용
자동화 도구 이용

비용 측정 방법론

COCOMO(COnstructive COst MOdel)
- Boehm, 상향식, 수학적 산정 기법
- 변화 모형(Basic, Intermediate, Detailed)
- 규모 모형(Organic, Semi-detached, Embedded)
Putnam 모형
- 시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력분포도 곡선
- 기초로 만든 자동화 도구 SLIM
- 대형 프로젝트의 노력 분포 산정에 용이

CPM(Critical Path Method)

병행 작업이 가능하도록 계획
비용측정은 하지 않음
이전 작업이 모두 완료되지 않으면 다음 작업으로 진행 불가
정확한 일정 예측은 불가능

위험 관리 절차

위험 식별 : 위험 요소가 될 사항
위험 분석 및 평가 : 위험의 비중과 영향력 파악
위험 관리 계획 : 위험 예방, 대안 준비, 문서화
위험 감시 및 조치 : 위험 관찰, 모니터링

위험표 포함 사항

위험 발생 확률
위험의 내용 및 종류
위험에 따르는 영향력
위험 발생 시간 X

자료 흐름도

프로세스 : 원 / 데이터 흐름 : 화살표 / 데이터 저장 : 실선 2줄 / 입출력 : 사각형

소단위 명세서

설계 단계에서 사용하는 구조적인 언어 사용 가능
서술 문장, 의사결정 나무, 의사 결정표, 표, 그래프 등

소프트웨어 설계 모형

문서량 기준 : 데이터(DD, 메타데이터) ⇒ 구조(구조도) ⇒ 관계 ⇒ 절차(PDL 알고리즘)
노력 기준 : 절차 ⇒ 관계 ⇒ 구조 ⇒ 데이터

HIPO(Hierarchy plus Input Process Output)

하향식 설계 기법, IBM에서 개발한 프로그램을 기능 위주로 문서화
입력/처리/출력 구성, 소규모 프로젝트에 적합
도식 목차(가시적 도표, Visual Table of Contents) : 전체적인 흐름과 구조
총괄 도표(총체적 도표, Overview Diagram) : 입력, 처리, 출력 등의 기능 명확히 표현
상세 도표(세부적 도표, Detail Diagram) : 총괄 도표의 일부 기능을 구체적으로 표현

자료 흐름 설계 과정

정보 흐름의 유형을 설정
흐름의 경계를 표시
자료 흐름도를 프로그램 구조로 사상 ⇒ 변환 사상(Transform Mapping)
제어 계층을 분해시켜서 정의
경험적 방법으로 구체화

결합도(약 → 강)

데이터 결합도(Data Coupling)
구조 결합도(Stamp Coupling) : 두 모듈이 매개 변수로 자료를 전달할 때, 자료 구조 형태
제어 결합도(Control Coupling)
외부 결합도(Extern Coupling)
공통 결합도(Common Coupling) : 두 모듈이 동일한 전역 데이터를 접근
내용 결합도(Content Coupling) : 하나의 모듈이 직접적으로 다른 모듈의 내용 참조

응집도(약 → 강)

우연적 응집도(Coincidental Cohesion)
논리적 응집도(Logical Cohesion)
시기적 응집도(Temporal Cohesion)
절차적 응집도(Procedural Cohesion)
통신적 응집도(Communication Cohesion)
순차적 응집도(Sequential Cohesion)
기능적 응집도(Functional Cohesion)

객체지향 분석 순서

객체 모델링 : 객체의 속성, 연산을 식별
동적 모델링 : 객체 모형들의 행위, 상태, 조건을 파악
기능 모델링 :
입출력 결정 ⇒ 자료 흐름도 ⇒ 기능의 내용 상세 기술 ⇒ 제약사항 결정 / 최소화

객체지향 기술

다형성 : 동일한 메소드를 다양한 방법으로 사용할 수 있는 능력

객체 분석

형식적인 전략으로 기술
모델링 구성 요소인 클래스, 객체, 속성, 연산들을 표현해서 문제를 모형화
E-R 다이어그램 적합, 개념적으로 파악

객체 설계

구체적인 절차, 객체의 속성과 자료 구조를 표현
서브 클래스와 메시지 특성을 세분화하여 세부사항을 정제화
사용자 중심, 대화식 프로그램의 개발에 적합
cf) 객체 구현 : 객체의 정의

객체지향 기법 vs 구조적 프로그래밍 기법

추상적 자료형 vs 절대적 자료형
객체 사용 vs 함수 사용
메시지를 통해 객체 호출 vs 매개 변수를 통해 함수 호출
전역 변수에 영향 없음 vs 전역 변수에 영향 받음

화이트 박스 검사 방법

기초 경로 검사(Basic Path Testing)
- 가능한 경로를 어느 정도 통과하는지의 적용 범위성 측정
- 복잡도(Cyclomatic Complexity)
- V - E + R = 2 (V : 노드의 수, E : 간선의 수, R : 영역의 수)
- 화살표로 둘러싸인 면의 수 + 1

블랙 박스 검사 방법

균등 분할(Equivalence Partitioning) : 정상 데이터 / 비정상 데이터
한계값 분석(Boundary Value Analysis) : 범위 한계 위주
원인-결과 그래프(Cause-Effect Graphing) : 임의의 자료 입력 ⇒ 정상 출력 확인
오류 예측(Error Guessing) : 데이터 확인 방법, 위 3가지 이외 오류 검사
비교 검사 : 하나의 프로그램을 여러 컴퓨터에서 테스트

소프트웨어 검사 단계

단위 검사(Class) ⇒ 통합 검사 ⇒ 검증 검사 ⇒ 시스템 검사
cf) 개발 순서 : 시스템 공학 ⇒ 요구 분석 ⇒ 설계 ⇒ 코딩(구현)

통합 검사

하향식(Top Down) 통합 검사 : 가짜 모듈이 필요(Stub), 회귀 검사, 프로그램 전체 실행
상향식(Bottom Up) 통합 검사 : Cluster, Driver, 중요한 모듈 우선 검사 가능
클러스터 결함 ⇒ 드라이버 작성 ⇒ 클러스터 검사 ⇒ 드라이버 제거 후 상위 결합

유지보수 비용 측정

BL방법 : M = P + K * e^(c-d) (M:인원/월, P : 비용, K : 상수, c : 복잡도, d : SW지식)

유지보수 작업의 종류

하자보수(=수리보수, Corrective M) : 잠재적인 오류 수정
기능 개선(=완전보수, Perfective M) : 기능의 수정, 추가, 전반적인 기능 개선 ⇒ 비용 많음
환경 적응(=적응보수, Adaptive M) : 환경 변화에 대응하여
예비 조치(=예방보수, Preventive M) : 미리 예측하여 준비

품질 목표 항목

정확성(Correctness) : 요구사항 충족시키는 정도
신뢰성(Reliability) : 요구된 기능을 오류없이 수행하는 시스템 능력 정도
효율성(Efficiency) : 최소한의 처리 시간과 기억 장소를 소유하여 요구된 기능 수행
유연성(Flexibility) : 새로운 요구사항에 접하여 쉽게 수정될 수 있는 능력

OMA(Object Management Architecture) 레퍼런스 모델

객체 간의 관계를 표현하는 표준 참조 모델
Object Service, Common Facilities, Domain Interface, Application Interface

소프트웨어 재공학(Reengineering)

개조(Restructuring) : SW 기능을 변경하지 않으면서 SW 형태에 맞게 수정
같은 추상적인 수준에서 하나의 표현을 다른 형태로 바꾸는 작업
분석(Analysis) : 기존 SW의 명세서를 확인하여 SW 동작을 이해, 재공학 대상 선정
재개발(Redevelopment) : 기존의 SW 삭제 ⇒ 새롭게 개발

소프트웨어 재사용 단위

명령어, 모듈, 요구분석서, 설계, 코딩 ⇒ 개발 비용은 변하면 안됨

Twitter Facebook LinkedIn

SG Yoo.