SOFTWARE ENGINEERING

Jo, Heeseung

2

이번 시간에 배우는 것들

8.1 소프트웨어공학 개요

8.2 소프트웨어 생명주기

• 생명 주기, 전통적인 소프트웨어 개발 단계

8.3 소프트웨어공학 방법론

• 폭포수 모델, 점진적 / 반복형 모델, 공개 소스 개발

8.4 소프트웨어 설계도구

• 전통적 도구, UML

8.5 소프트웨어의 품질 보증

8.6 문서

8.7 소프트웨어에 대한 소유권

8.1 소프트웨어공학 개요

4

소프트웨어공학

S/E란?

• (대형) 프로그램을 작성하는 데에 필요한 방법론 & 기법

초보 프로그래머

• 소형 프로그램만 코딩

• 대부분 S/E의 중요성을 무시

• 대형 프로그램에서는 S/E가 가장 중요

5

예: 자동차 공장의 책임자

새로운 model을 생산해야 하는 경우

• 시간 내에 모든 사람이 효율적으로 일해야

cost estimation : 제작에 걸리는 시간, 비용, ...

team 구성 : 어떻게 위임할 것인가?

어떻게 진행 상황을 평가할 것인가?

각 team들 간의 협력은 어떻게?

6

대형 프로그램 개발자

같은 문제가 그대로 발생

• 기존의 경영학 관점을 쓸 수 없나?

소프트웨어만의 특성도 고려

• 내성(tolerance)

- 자동차: 오차 범위 2%

- 프로그램: 오차 범위? 그런 거 없다

• 측도(metric)

- 소프트웨어의 양과 질은 어떻게 평가?

7

S/E의 근본적 문제

소프트웨어 : 노동력 + 상상력의 산물

• 수치적으로 평가하기가 불가능

소프트웨어는 닳아 없어지지 않는다

• 기존의 생산 관점에서는 내구성이 중요

• 소프트웨어는 내구성과 무관

이런 이유로, S/E는 독립적인 학문 분야

8

CASE 도구

CASE(Computer-Aided Software Engineering) 기법

• 소프트웨어 개발에 컴퓨터 기술을 적용

• 이로 인해 소프트웨어 개발 과정이 점점 단순화되어 감

CASE 도구

• 프로젝트 계획 : 비용예측, 프로젝트 일정관리, 인원배치

• 프로젝트 관리 : 개발 프로젝트의 진행상황 모니터

• 문서화 도구 : 문서화 작업

• 프로토타이핑과 시뮬레이션 도구: 프로토타입의 개발

• 인터페이스 설계 도구 : GUI 개발

• 프로그램 개발 도구: 프로그램의 작성 및 디버깅

통합개발환경(IDE; integrated development environment)

• 편집기, 컴파일러, 디버깅 도구 등의 여러 도구들을 하나의 통합패키지로 결합

8.2 소프트웨어 생명주기

10

소프트웨어 생명 주기

일반 생산품의 생명 주기(life cycle)

소프트웨어 생명 주기

development: 개발 use: 소비자가 사용

repair: 닳은 부품을 교체

development: 개발 use: 소비자가 사용

modify: 부품 교체가 아니라, 수정

11

소프트웨어 수정과 폐기

왜 수정(modify) ?

• 개발 시와 환경이 바뀌거나, (DOS -> Win, PC -> Phone)

• 초기 parameter가 바뀌거나, (사용자 수)

• 디버그(Debug)

수정시의 문제

• 프로그래머는 전체 프로그램을 파악해야 함

• 어떻게? program, documentation, comment 등에 의존

소프트웨어의 폐기

• 수정 비용(modification cost) > 개발 비용(development cost)일 때

• 프로그램이 이해 불가능할 때

이제까지의 연구 결과

• 개발 단계(development phase)에 조금의 노력만 하면(manual, comment, guide 등의 문서)

• 효과적인 수정(modification)이 가능

12

S/E의 관점

S/E의 목표

• 소프트웨어의 비용(cost)를 낮춘다

• 그러려면, 수정해서 오래 써야함

• 효과적인 수정방법(modification)이 필요

S/E의 방법론

• 개발 단계에 집중

• "초기에 잘못 개발한 프로그램은 수정 불가능"

13

전통적인 개발 단계

요구사항분석(analysis)

• 사용자의 요구 분석

설계(design)

• 전체 시스템을 구축하기 위한 시스템의 내부 구조 확립

구현(implement)

• 실제 구현

테스트(testing)

• 문제가 없도록디버깅

14

요구사항 분석

요구사항 분석(Analysis) : 시스템이 무엇을 할 지 결정

1. 시장 조사 개발할 필요가 있나?

2. 사용자 요구 조사 사용자가 원하는 것은?

최종 결과 : 소프트웨어 요구사항 명세(specification)

• 서면 합의서

• 소프트웨어 개발 지침

• 소프트웨어 개발의 방향이 될 확고한 목표를 정의해야 함

15

설계

설계(Design) : 시스템의 구축을 위한 시스템의 내부구조 확립

1. 개발할 시스템의 세부적인 기술 설정

2. 적절한 크기의 모듈(module)로 분할

모듈(module)

• 프로그래머가 관리 가능한 크기의 단위(unit)

• 왜? 사람의 능력에는 한계

• OOP : 객체(object) == 모듈(module)의 개념

최종 결과

• 소프트웨어 시스템 구조에 대한 세부 기술서

• 예) 다이어그램과 모델링 작업 결과

16

구현

구현(Implementation)

• 설계를 바탕으로 시스템 구성

• 실제로 "프로그램" + "데이터(data file, database)" 만들기

• 소프트웨어 분석가(software analyst) vs. 프로그래머의 역할

- 소프트웨어 분석가 : 전체 개발 과정에 관련된 사람

· 주로, 요구사항 분석과 설계 단계 담당

- 프로그래머 : 구현 단계 담당

하지만, 소프트웨어 개발 과정의 단계들이 서로 얽혀 있다

17

테스트

테스트(Testing)

• 테스트가 프로그램만을 대상으로 하지 않음

• 전체 개발 과정의 각 중간 단계의 결과물에 대해 정확한지 테스트해야함

• 실제로, 테스트(test) & 디버그(debug)는 매우 어려운 작업

• 검증 테스트

- 시스템이 명세를 충족하는지 확인

• 결함 테스트

- 오류 발견

8.3 소프트웨어공학 방법론

19

소프트웨어 공학 방법론

폭포수 모델(Waterfall Model)

점진적 모델(Incremental Model)

• 프로토타이핑(Prototyping)

- 진화적 프로토타이핑(Evolutionary Prototyping)

- 폐기형 프로토타이핑(Throwaway Prototyping)

공개소스 개발(Open-source Development)

20

폭포수 모델

초창기 S/E에서 많이 사용

개발 단계의 각 세부 단계를 차례로 완전히 끝내고 다음 단계로

문제점

• 사람이 하는 일이 그렇게 완벽하게 되는가?

• cf. 반복형 모델(Iterative Model), XP(Extreme Programming)

21

점진적 모델

소프트웨어의 기능들을 점증적으로 완성해 가는 모델

• 처음부터 모든 기능들을 정의하지 않고, 중요한 기능들이 우선적으로선별되고 개발함

• 이후 추가할 기능들이 선택되고 개발되는 일들이 반복(확장)

• 경우에 따라서는 현재 진행 중인 기능 개발과 추가될 기능 개발이동시에 진행

예) 환자 레코드 시스템

• 전체 레코드 시스템의 작은 샘플에서 환자 레코드를 볼 수 있는 기능만구현

• 잘 동작하면 레코드의 추가나 갱신이 단계적으로 추가

22

반복형 모델

점진적 모델과 반복형 모델

• 점진적 모델 : 제품의 예비 버전을 확장하여 더 큰 버전을 만들어 나감

• 반복형 모델 : 각 버전을 재 구축한다는 개념이 포함됨

• 현실적으로 점진적 모델은 대개 반복형 과정을 이용하며, 반복형 모델은종종 점진적으로 그 기능을 추가하기도 함

23

프로토타이핑

프로토타이핑(prototyping) :

• 프로토타입이라는 제안 시스템의 미완성 버전을 구축하고 평가

• 구현 이전에 단순화 된 버전(simplified version)을 만들어 보고,문제가 있으면 설계/명세를 변경

• 요구사항 분석, 설계, 프로토타이핑을 계속 반복

• 문제가 없어지면, 실제 구현 착수

진화적 프로토타이핑(evolutionary prototyping)

• 프로토타입이 진화적 프로토타이핑 과정을 통해 최종 시스템으로 발전

폐기형 프로토타이핑(throwaway prototyping)

• 최종 설계를 새로 구현하면서 프로토타입을 버림

• 단기 프로토타이핑(rapid prototyping)

- 실제로 동작하는 제품 버전을 만드는 것이 아니라, 소프트웨어 개발 과정에관련된 당사자들 사이의 의사소통을 명확히 하기 위한 시연용 도구를 만듦

24

공개 소스 개발

오늘날 대부분의 무료 소프트웨어의 개발 방식

예. 리눅스 운영체제의 공개 소스

과정

• 소프트웨어의 소스코드와 설명 문서를 개발자가 인터넷에 공개

• 다른 사용자들이 무료로 다운받아 사용

• 자신의 필요에 맞게 소프트웨어를 수정하거나 확장, 오류수정

• 변경에 대해 원 개발자에게 보고하면, 원 개발자는 이러한 변경을반영하여 재공개

8.4 설계도구

26

설계 도구

설계 도구

• 소프트웨어 개발의 분석 및 설계 단계 동안 사용되는 모델링 기법과표기체계

전통적 도구

• 데이터 흐름도(Data Flow Diagram)

• 데이터 사전(Data Dictionary)

UML

• 용례 다이어그램(Use Case Diagram)

• 클래스 다이어그램(Class Diagram)

27

전통적 도구들

데이터 흐름도(Data Flow Diagram)

• 데이터 흐름에 대한 조사를 통해 얻은 정보를 표현하기 위한 수단

- 데이터가 시스템에서 어떻게 움직이는지 조사함으로써 프로시저 식별하는 데도움이 됨

• 타원 : 데이터 처리

• 화살표 : 데이터 경로

• 사각형 : 데이터 소스와 데이터 저장소

<병원의 진료비 청구 시스템>

28

전통적 도구들

데이터 사전(Data Dictionary)

• 소프트웨어 시스템에 나타나는 데이터 항목들에 관한 정보의 중앙저장소

• 시스템 전체에 걸친 데이터 설명

• 이름, 용도, 표현 방법, 연관된 function 등

• 데이터 사전을 구축하는 이유?

- 소프트웨어 시스템의 잠재적 사용자와 사용자의 요구를 요구사항 명세 문서로변환하는 작업을 맡은 소프트웨어 엔지니어 사이의 의사소통 개선

- 시스템 전체에 걸쳐 일관성 확보

- 예) Name

· 인사부서에서의 사원 지칭

· 재고 레코드에서의 부품 지칭

29

UML

UML(Unified Modeling Language)

• 사용자가 현실세계를 빠짐없이 반영할 수 있는 사용하기 쉬운 비주얼모델링 언어

• 객체지향 도구시장의 성장을 촉진

종류

• 용례 다이어그램(Use Case Diagram)

• 클래스 다이어그램(Class Diagram) 등

30

용례 다이어그램

용례 다이어그램(Use Case Diagram)

• 사용자의 관점에서 제안 시스템의 모습을 그림

• 제안된 소프트웨어 시스템을외부 시각에서 바라봄

• 사각형 : 시스템

• 타원(용례, usecase) : 시스템과 사용자 사이의 상호작용

• 막대인물(행위자, actor) : 시스템 사용자

31

클래스 다이어그램

클래스 다이어그램(Class Diagram)

• 클래스들의 구조와 클래스 사이의 관계를 표현하기 위한 표기체계

연관 관계(Association) : 클래스 사이의 관계

• 일대일 관계(one-to-one relationship)

- 각 병실은 1명의 환자에게만 배정

• 일대다 관계(one-to-many relationship)

- 각 환자는 한 명의 주치의, 의사는 여러 명의 환자

• 다대다 관계(many-to-many relationship)

- 의사는 여러 명의 환자, 환자는 여러 명의 진찰전문의

32

연관 관계

x 타입의 개체들과 y 타입의 개체들 사이의 관계

8.5 품질보증

34

소프트웨어 테스트 전략

소프트웨어는 테스트를 통해 "검증"

• 정확하지 않음!

• 모든 경로를 테스트해보는 것은 불가능

유리박스 테스트(Glass-box testing)

• 테스트 대상 소프트웨어의 내부 구성에 대한 지식에 의존

• 소프트웨어를 테스트하는 사람이 소프트웨어 내부 구조를 잘 알고있으며, 이러한 지식을 테스트 설계에 이용

파레토 원리(Pareto principle)

• 대규모 시스템에서 시스템 내부의 소수의 모듈이 나머지 대부분의모듈보다 더 많은 문제를 갖고 있다는 것에 기초하여 이런 모듈을 찾아더욱 철저히 테스트하자는 테스트 기법

기초 경로 테스트(Basis path testing)

• 소프트웨어 안의 모든 명령이 적어도 한 번씩은 실행되도록 보장하는테스트 데이터 집합 개발

35

소프트웨어 테스트 전략

블랙박스 테스트(Black-box testing)

• 사용자의 관점에서 수행

• 소프트웨어가 어떻게 작업을 수행하는지에 대해서는 관여하지 않으며, 정확성과 시간을 기준으로 소프트웨어가 올바르게 수행되는지를 평가

경계값 분석(boundary value analysis)

• 동치 클래스(소프트웨어가 비슷한 성능을 보이는 데이터 범위)를식별하고 이러한 범위들의 가장자리에 가까운 데이터들에 대해 테스트실행

• 동치클래스를 식별함으로써 테스트 데이터 개수를 최소화하여 동치클래스 안의 데이터 몇 개에 대해서 정확한 동작이 검증되면 전체클래스에 대해 소프트웨어를 검증한 것으로 간주

• 예) 소프트웨어가 특정 범위의 값을 입력받도록 되어 있다면 이 범위의최대값과 최소값에 대해 소프트웨어를 테스트

베타테스트(beta testing)

• 일부 사용자들에게 소프트웨어의 예비버전(beta version) 배포

• 마케팅 효과..

8.6 문서

37

문서

소프트웨어 시스템

• 프로그래머가 차후에 관리할 수 있어야 함

문서

• 소프트웨어 패키지의 중요한 부분

• 유지보수에 필수적

• S/E에서 매우 중요

문서의 분류:

• 사용자 문서(user documentation) : 모든 고객을 위한 인쇄된 책자

• 시스템 문서(system documentation) : 소스코드, 설계문서

• 기술 문서(technical documentation) : 설치, customizing, update 등

38

사용자 문서

사용자 문서

• 소프트웨어의 기능과 사용법을 설명

• 예: user's guide, user's manual

• 프로그래머가 아닌 사람 대상

현재는 중요한 마켓팅 수단

• 예제가 풍부한 매뉴얼을 선호

• 전문 작가(writer)들이 별도로 출판하는 추세

39

시스템 문서

시스템 문서

• 유지보수 단계에 도움이 될 수 있도록 시스템을 관리하는 법, 내부 구조설명

• 예: administrator's guide, 내부 문서

• 프로그램 그 자체도 문서

- 프로그램을 깔끔하게, 잘 짜야 하는 이유

S/E 관점에서는:

• 설계(design) 단계에서부터 작성 시작

• 프로그램의 발달에 따라 계속 작성/수정

• 문제점: 프로그래머가 귀찮아 한다

40

기술 문서

기술 문서

• 시스템 소프트웨어의 설치와 (운영 매개변수의 조정, 커스터마이징, 업데이트 설치, 문제 발생시 소프트웨어 개발자에게 보고하는 일 등의) 사후관리 방법 설명

• 예: 자동차 업계에서 정비사에게 제공되는 매뉴얼

• 사용자들이 소프트웨어패키지들을 추상적 도구로 이용할 수 있도록 모든소프트웨어에 대한 관리를 맡고 있는 시스템 관리자가 사용하는 문서

8.7 소프트웨어에 관한 소유권

42

소프트웨어 소유권

저작권 법(copyright)이나 특허법(patent)

• 상품의 개발자가 소유권을 보호하면서 특정인에게 상품 또는 그 일부를공개할 수 있게 함

• 모든 결과물에 저작권 안내문을 포함시킴으로써 자신의 소유권을주장해야 함

- 명세, 소스코드, 최종제품 등

• 저작권 문구 : 소유권, 작업 결과물의 사용이 허가된 대상자, 기타제한사항들 명시

43

소프트웨어 소유권

소프트웨어 라이센스(Software license)

• 소프트웨어 제품의 소유자와 사용자 사이의 법률적 합의서

• 지적재산에 대한 소유권을 이전하지 않으면서 사용자에게 제품 사용에대한 일정한 허가를 부여함

특허(patent)

• 발명을 통해 영리적 이익을 얻을 수 있게 하자는 취지로 제정된 것

• 특허기간 : 특허 신청일로부터 20년

영업 비밀(trade secret)

• 비밀 준수 서약서는 법률적 효력이 있음