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

컴퓨터공학/정보처리기사

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

메시에 2019. 4. 22. 15:53

* 소프트웨어의 특성

- 상품성: 판매할 수 있는 상품임

- 복잡성: 개발과정이 복잡하고 관리가 어려움

- 변경 가능성: 프로그램을 수정하여 업그레이드와 오류수정 등이 가능

- 복제성: 쉽게 복사하여 유통이 가능

* (컴퓨터) 시스템

- 특정한 목적을 위해 다양한 컴퓨터로 처리 가능한 요소가 유기적으로 결합된 정보 체계

- 입력, 처리, 출력, 제어, 피드백으로 구성

* 소프트웨어 위기 (Crisis)

하드웨어는 빠르게 발전하는데 소프트웨어 개발속도는 그것을 따라가지 못하고 고객의 요구사항을 감당하지 못하게 됨

- 개발 기간 지연, 개발 비용 증가, 인력 부족, SW 퀄리티 저하, 유지보수의 어려움...

* 소프트웨어 공학

가장 경제적으로 / 퀄리티 높은 소프트웨어를 만들기 위한 / 방법, 도구, 절차 등의 체계

- SE의 목표

주어진 비용 (돈과 시간) 내에서 사용자의 요구사항을 만족하는 퀄리티 높은 소프트웨어를 만들어내는 것.

- SE의 계층 구조

> 도구

> 방법론

> 프로세스

* 소프트웨어 Lifecycle

- 일반적인 SW 생명 주기

> 타당성 검토 -> 개발 계획 -> (요구사항 분석 -> 설계 -> 구현 -> 테스팅) -> 운영 및 유지보수

- 폭포수 모델 (Waterfall Model)

소프트웨어 개발과정의 각 단계가 순차적으로 진행되는 가장 기본적인 모델 (위의 과정과 같다)

> 장점: 쌓인 성공사례가 많음, 단계별 정의가 명확해 이해가 쉬움, 단계별 산출물이 명확

> 단점: 새로운 요구사항의 반영이 어려움, 이전 단계로 돌아가서 오류 수정하기가 어려움

- 프로토타입 모델 (Prototype Model)

프로토타입을 미리 만들어 최종 결과물을 예측. 다 만들어져야 문제점을 확인할 수 있는 폭포수 모델의 단점 보완

요구 수집 -> (빠르게) 설계 -> 프로토타입 구축 -> 고객 평가 -> 프로토타입 재조정 -> 구현

> 장점: 고객과 개발자 모두에게 참조 모델을 제공, 고객이 결과를 미리 볼 수 있어 더 많은 요구사항 반영 가능

> 단점: 프로토타입과 실제 구현된 SW의 차이 때문에 혼란 발생, 프로토타입 개발에 소요되는 비용

- 나선형 모델 (Spiral Model)

반복적인 작업을 점진적으로 수행함. Risk Analysis에 특화되어 있다.

계획 수립 -> 위험 분석 -> 개발 -> 고객 평가

> 장점: Risk Analysis 단계로 인해 위험요소를 제거, 대규모 프로젝트에 적합

> 단점: 미처 발견 못한 위험요소가 있을 수도 있다. 성공사례가 많이 쌓여있지 않음.

+ WINWIN Spiral Model이라는 것도 있음. 고객과의 협상과정을 통해 Win-Win 컨디션을 찾아내는데 더 비중을 둔다.

* SW 프로젝트 관리

- 3P: People, Problem, Process

- 프로젝트 관리의 대상

1) 일정 관리: 제시된 기간 내에 프로젝트를 완료할 수 있도록

> 활동의 정의, 활동 순서, 활동 기간 예측, 일정 계획 수립, 일정 통제

2) 비용 관리: 제한된 예산으로 프로젝트를 완료할 수 있도록

> 자원 계획, 비용 예측, 비용 예산, 비용 통제

3) 품질 관리: 요구사항을 정확히 적용가능한지 보증하기 위한 절차 기술

> 품질 계획, 품질 보증, 품질 통제

4) 위험 관리: 프로젝트에 내재된 위험요소를 예측, 분석, 대비

> 위험 인식, 위험 계량화, 위험 대응 계획, 위험 대응 통제

* 품질 관리

소프트웨어 개발 결과가 요구사항에 적합한지? - 설계 품질, 적합 품질

- IEEE 품질 표준

> 정확성 (Correctness): 요구사항을 얼마나 충족하는가?

> 신뢰성 (Reliability): 정확하고 일관된 결과를 얻을 수 있는가?

> 효율성 (Efficiency): 기능 수행에 얼마나 자원을 소모하는가?

> 무결성 (Integrity): 허가되지 않은 자료 변경을 잘 통제하는가?

> 사용 용이성 (Usability): 적절한 UI와 문서를 제공하는가?

> 유지보수성 (Maintainability): 요구사항이 변경되거나 오류가 발생했을 때 고치기 쉬운가?

> 이식성 (Portability): 다양한 HW 환경으로 쉽게 이식될 수 있는가?

> 재사용성 (Reusability): SW의 전체 또는 일부가 다른 목적으로 재사용될 수 있는가?

> 상호운용성 (Interoperability): 다른 SW와 정보를 교환하며 같이 동작할 수 있는가?

- 정형 기술 검토 (Formal Technical Review)

소프트웨어 품질 보증 활동의 하나.

- SW 신뢰도 (가용성) 메트릭

> MTTF (Mean Time To Failure): 총 가동시간 / n (n: 연속으로 가동중이었던 블록의 수)

> MTTR (Mean Time to Repair): 고장나있던 시간 / n (n: 고장났던 블록의 수)

> MTBF (Mean Time Between Failure): MTTF + MTTR

가용도 = MTTF / MTBF

- 위험 관리 (Risk Analysis)

프로젝트 추진과정에서 예상되는 위험상황을 미리 예상하고 적절한 대책을 수립하는 활동

> 위험의 종류: 인력 부족, 예산 관리, 일정 관리, 사용자 요구사항의 변경

> 위험 관리 절차

1) 위험 식별

2) 위험 분석 및 평가

3) 위험표 (Risk Table): 위험 내용과 종류, 발생확률, 영향력

4) 위험 관리 계획

5) 위험 감시 및 조치

- 형상 관리 (Configuration Management)

개발 과정에서 변경되는 사항을 관리하는 활동. 적절히 변경이 되었는지 확인하고 담당자에게 통보한다.

형상 관리의 대상들:

> 정의 단계의 문서

> 개발 단계의 문서 및 프로그램

> 설계 명세서

> 실행 프로그램

> 유지보수 단계의 변경 사항

* 요구사항 분석

프로젝트의 실질적인 첫 단계로 소프트웨어가 가져야할 기능을 기술

- 요구사항 분석 단계

> 문제 인식 / 수집: 인터뷰나 설문조사 등을 이용해 요구사항을 파악 및 수집

> 전개: 수집한 요구사항들에 대해 자세히 조사

> 평가와 종합: 요구사항을 다이어그램이나 CASE 도구 등을 통해 종합

> 검토: 위의 내용을 검토 및 재정리

> 문서화: 요구사항 분석 내용을 문서화

- 요구사항 분석의 어려움

* 구조적 분석

프로세스 사이의 데이터 흐름에 맞춰서 시스템 모형을 만드는 것.

- 자료 흐름도 (DFD)

> Process: 동그라미

> Data Flow: 화살표 (위에 자료 이름)

> Data Store: 위아래 선 두개

> Terminator: 직사각형 (자료의 출처나 도착지를 나타냄)

- 자료 사전 (Data Dictionary)

DFD에 나타나는 자료를 좀 더 상세하게 정의, 기록한 것

> 정의: =

> 연결: +

> 생략: ( )

> 선택: [ | ]

> 반복: { }

> 설명: * *

ex) 고객명세는 고객성명, 고객번호, 고객주소로 이루어져있고 고객성명과 고객번호는 둘 중 하나만 선택가능함

고객명세 = [고객성명|고객번호] + 고객주소

- 개체 관계도 (E-R Diagram)

> 개체: 데이터를 의미

> 속성: 개체에 포함되어 있는 특성값을 의미

> 관계: 개체, 속성간의 관계

- 상태 전이도 (State Diagram)

시스템 이벤트 발생시 시스템의 상태 변화를 모델링하는 것. 상태는 직사각형으로 표현.

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

DFD의 처리 공정 절차를 기술한 것. 구조적 언어, 의사결정표, 의사결정도, N-S Chart 등을 이용한다.

* 설계 (Design)

- 설계 방법과 계층

1) 자료 설계: 요구사항 명세서의 정보를 SW로 구현하기 위해 필요한 자료구조로 변환

2) 구조 설계: 프로그램의 큰 틀, 모듈간의 관계 등을 정의

3) 인터페이스 설계: SW와 사용자 또는 다른 시스템간의 통신 방법을 기술

4) 절차 설계: 모듈이 수행할 기능을 절차적 기술로 변환

- N-S Chart

위의 4) 절차 설계에서 쓰이는 것 중 하나로 박스 다이어그램이라고도 한다.

절차적 프로그래밍 언어처럼 '순차', '선택', '반복' 3가지 제어구조를 도형으로 표현

- 추상화 (Abstraction)

실세계의 객체를 프로그램으로 갖고오는 것

소프트웨어 개발에 대한 전체적 개념을 설계하고 구체화하는 것

> 기능 추상화, 제어 추상화, 자료 추상화

* 프로그램 구조

모듈들간의 계층적 구성을 나타내는 것

- 주요 용어

> Fan-in: 이 모듈을 제어하는 상위 모듈 수

> Fan-out: 이 모듈이 제어하는 하위 모듈 수

> Depth: 최상위 모듈부터 이 모듈까지의 길이

> Width: 같은 레벨의 모듈 수

> Super-ordinate: 다른 모듈을 제어하는 모듈

> Sub-ordinate: 다른 모듈에 의해 제어되는 모듈

- HIPO (Hierachy + Input Process Output) 기법

> Top-down 개발을 위한 문서화 도구

> 구조도 (가시적 도표), 총체적 다이어그램, 세부적 다이어그램으로 구성

* 모듈

하나의 프로그램을 작은 부분으로 분할한 것

모듈의 이름으로 호출하여 다수가 이용할 수 있으며, 시스템 개발 비용을 절감하고 신뢰성을 향상시키는데 도움이 된다.

효과적인 모듈설계 -> High Cohesion, Low Coupling을 지향

- 응집도 (Cohesion): 모듈 안의 요소들이 서로 관련되어 있는 정도

1) 시간적 응집도 (Temporal): 특정 시간에 처리되는 여러 기능을 모아 모듈로 구성

2) 절차적 응집도 (Procedural): 모듈 내부의 기능 요소들이 여러 관련 기능을 순차적으로 수행

3) 교환적 응집도 (Communicational): 동일한 입력, 출력을 사용하는 기능끼리 모아 모듈로 구성

4) 순차적 응집도 (Sequential): 한 모듈 내의 한 기능에 의한 출력이 다음 기능의 입력으로 사용됨

5) 기능적 응집도 (Functional): 모듈 내의 모든 요소들이 하나의 기능을 수행하기 위해 사용됨

- 결합도 (Coupling): 두 모듈간의 상호 의존도.

1) 내용 결합도 (Content): 한 모듈이 다른 모듈의 일부를 마음대로 참조, 수정. 한 모듈에서 다른 모듈로 제어 이동

2) 공통 결합도 (Common): 여러 모듈이 공통 자료 영역을 사용 (전역 변수 등)

3) 외부 결합도 (External): 어떤 모듈에서 선언한 변수를 다른 모듈에서 참조

4) 제어 결합도 (Control): 한 모듈이 다른 모듈에게 제어 요소를 전달 (Flag 등)

5) 스탬프 결합도 (Stamp): 모듈간의 인터페이스로 배열이나 구조체 등의 복합 자료구조가 전달

6) 자료 결합도 (Data): 모듈간의 인터페이스가 자료 요소만으로 구성

* 구현 (Implementation)

프로그래밍 언어를 사용해서 소스코드를 작성하고 문서화하는 작업

설계 단계에서 산출된 설계 명세서를 바탕으로 모듈 단위로 코딩을 한다.

테스트가 용이하도록 코드를 작성할 것.

- 프로그래밍 언어: 업무의 성격, SW의 실행 환경, 개발자의 경험 및 지식 등에 따라 결정

- 구조적 프로그래밍: 순차, 선택, 반복의 3가지 제어구조. goto는 가급적 쓰지 마라

* 테스팅

요구사항 분석 - 설계 - 구현의 결과를 점검하는 단계. 에러를 찾기 위함.

예상 결과 (Expected) 와 실제 결과 (Actual) 가 같은지 검사하고 평가.

- 단위 테스트 (Unit Test)

SW의 최소구성단위인 모듈별로 테스트하는 것. = 모듈 테스트.

여기까지는 전문 테스터가 아니라 구현한 개발자가 수행하는 것이 보통.

- 블랙박스 테스트

코드를 보지 않고 기능이 제대로 수행되는지 검사하는 기법.

성능 오류, 부정확한 기능, 인터페이스 오류를 잡아낼 수 있음

> 동치분할 검사 (Equivalence Partitioning): 입력 조건을 적절한 범위로 자르고 각 범위마다 나와야 하는 값과 실제 나오는 값을 비교

이걸 하기 위해: 경계값 분석 (Boundary Value Analysis), 원인-효과 그래프 (Cause-Effect Graph), 비교 검사

- 화이트박스 테스트

소스코드를 직접 실행해보면서 모듈 내부의 동작을 자세히 관찰하는 것

> Basic Path Test, Data Flow Test, Loop Test

> Statement Coverage, Branch Coverage, Condition Coverage, Branch/Condition Coverage, Multiple Condition Coverage

* 유지보수 (Maintenance)

SW가 인수, 설치된 후에 발생하는 모든 작업으로 SW의 수명을 연장시키며 모든 프로세스 중 가장 비용이 많이 발생함.

유지보수 과정에서 부작용이 발생할 수 있는데 (ex: 스파게티 코드) 문서화를 철저히 하고 가이드라인을 잘 지켜야 이를 방지할 수 있다.

1) Corrective: 오류를 수정하는 것

2) Adaptive: 환경 변화를 기존 SW에 적용하는 것 (이식 등)

3) Perfective: 성능 개선, 새로운 기능 추가. 가장 큰 비중을 차지

4) Preventive: 오류 방지를 위해 정기적으로 수행 (??)

* 객체지향

60년대 후반부터 대두된 개발 패러다임으로 실세계의 현상을 컴퓨터 시스템에서 '객체' 로 표현

- 객체지향의 구성요소

> 객체: Attribute와 Method로 이루어진 하나의 소프트웨어 모듈

> 속성 (Attribute): 객체의 상태, 데이터

> 메소드: 객체가 실행해야할 구체적인 연산, 동작.

> 클래스: 객체들의 공통된 특성을 표현한 데이터 추상화. 객체들이 갖는 속성과 연산을 정의하고 있는 틀.

> 메시지: 객체들간의 상호작용을 위한 수단.

> 오퍼레이션: 클래스 내 객체에 의한 함수나 그 변형. 오퍼레이션의 구현이 메소드라 할 수 있는데 일반적으로 객체지향에서는 동일하게 본다.

- 객체지향의 기본 원칙

> 캡슐화 (Encapsulation)

데이터와 데이터를 조작하는 연산을 하나로 묶고, 이를 외부로 드러내지 않고 필요한 인터페이스만을 드러내는 것

-> High Cohesion / Low Coupling을 실현, 재사용성 증가

> 정보 은닉 (Information Hiding)

객체가 다른 객체로부터 자신의 자료를 숨기고 자신의 연산을 통해서만 접근을 허용하는 것

> 추상화 (Abstraction)

주어진 문제나 시스템 중에 중요한 부분만을 분리해서 간결하고 이해하기 쉽게 만드는 것

> 상속 (Inheritance)

다른 클래스의 속성, 메소드를 물려받아 재사용하는 것

> 다형성 (Polymorphism)

서로 다른 클래스들이 동일한 메소드명을 이용하고, 한 메시지가 객체에 따라 다르게 응답할 수 있는 특성

* 객체지향 분석

- 객체지향 분석 기법의 종류

1) 코드 & 요든 분석 기법: ER Diagram을 이용해서 개체들을 파악하고 모델링하는데 주안점을 둔 기법

2) 럼바우의 분석 기법: 객체 모델, 동적 모델, 기능 모델의 3개 모형을 이용해 모든 SW 구성요소를 Graphical하게 표현

> 객체 모델링: 객체, 속성, 연산 등의 식별 및 객체간의 관계 정의. 객체 다이어그램 작성

> 동적 모델링: 객체들의 제어흐름, 상호반응, 연산순서를 나타냄. 상태 다이어그램 작성

> 기능 모델링: 입출력 결정 -> DFD 작성 -> 기능의 내용 상세 기술 -> 제약사항 결정 및 최소화

* 재공학 & 역공학

- SW 재사용: SW의 전체 또는 일부분을 다시 사용해서 새롭게 개발하는 기법

> 개발 시간 및 비용 감소, 품질 / 생산성 / 신뢰성 향상, 프로젝트 실패 위험 감소, 지식의 공유

- SW 재공학 (Re-engineering)

> 분석 - 구성 - 역공학 - 이식

> 개발이 아니라 유지보수의 생산성으로 소프트웨어 위기를 해결

> 기존 시스템을 이용해 더 나은 시스템을 구축, 새로운 기능을 추가

> 사용자 요구사항 변경 없이 기술적 설계를 변경하여 프로그램을 개선

> 재구조화: 요구사항이나 기술적 설계 변경 없이 프로그램을 개선

- SW 역공학 (Reverse Engineering)

> 소프트웨어를 분석하여 개발 과정과 데이터 처리 과정을 알아내고 다시 만들어내는 작업

> 재문서화, 설계도 추출

* CASE (Computer-Aided Software Engineering)

SW 개발 과정을 컴퓨터 SW를 이용해 자동화하는 것.

문서화, 명세화, 다이어그램 작성 등을 쉽게 할 수 있도록 Graphical Interface를 제공해주는 프로그램들.

- CASE 사용의 이점

> 개발 기간 단축 및 비용 절약 (CASE 도구 도입을 위한 초기 구축비용이 있지만 그 이상으로 개발비 감축)

> 유지보수를 간편화

> 생산성 향상

> 모듈 재사용성, 효율 증가

> 일관된 방식을 적용하여 SW 개발 가능

> 표준화를 지원

- CASE의 분류

> 상위 (Upper) CASE: 요구분석, 설계 단계 지원

> 하위 (Lower) CASE: 코드작성, 테스팅, 문서화 지원

> 통합 (Integrate) CASE: 개발 주기 전체 지원