소프트웨어소프트웨어공학공학개요개요cs.kangwon.ac.kr/~ysmoon/courses/2010_2/se/02.pdf ·...

소프트웨어소프트웨어 공학공학 (Software Engineering(Software Engineering))

소프트웨어소프트웨어 공학공학 개요개요

문양세문양세문양세문양세강원대학교강원대학교 ITIT대학대학 컴퓨터과학전공컴퓨터과학전공

소프트웨어 공학 개요In this chapter …In this chapter …

소프트웨어 공학을 배우기에 앞서서,• 소프트웨어 및 소프트웨어 시스템에 대해서 정의해보고,

• 소프트웨어 위기와 이에 따른 소프트웨어 공학의 필요성을 생각해 본다.

또한또한, • 좋은 소프트웨어란 무엇인지 정의해보고,

• 소프트웨어 공학에서 사용하는 주요 모형들을 살펴본 후,소프트웨어 공학에서 사용하는 주요 모형들을 살펴본 후,

• 소프트웨어 개발에 영향을 미치는 요소들을 생각해 본다.

We will cover …• 소프트웨어와 시스템

소프트웨어 위기와 소프트웨어 공학• 소프트웨어 위기와 소프트웨어 공학

• 좋은 소프트웨어의 조건

• 소프트웨어 개발 프로세스 모형

Software Engineeringby Yang-Sae Moon

• 소프트웨어 개발에 영향을 미치는 요소

소프트웨어 공학 개요In this chapter …In this chapter …

소프트웨어와 시스템

소프트웨어 위기와 소프트웨어 공학

좋은 소프트웨어의 조건좋은 소프트웨어의 조건

소프트웨어 개발 프로세스 모형

소프트웨어 개발에 영향을 미치는 요소


소프트웨어 공학 개요소프트웨어의소프트웨어의 중요성중요성

실생활과 소프트웨어(컴퓨터)• 디아블로?, 리니지? 스타크? Oh, NO!

• 일상사에서… 공과금 고지서, 항공기 예약 및 발권, 병원 기록 관리, 초본/등본 발급, …

• 학교로 보면… 수강 신청, 성적 입력 및 열람, 학사 관리, …

정보 혁명의 토대는 컴퓨터이며, 그 잠재력은? 물론, 소프트웨어이다.

소프트웨어는 과거 “편리” 추구에서 현재는 “생존”에 필수적 요소가 되어가고 있다.• 정치, 경제(1차, 2차 3차 산업 공통), 사회, 교육, 국방, 예술, 의료, 오락, …

• 경쟁에서의 승리 제품의 적기 공급 제품? 소프트웨어 자체 혹은 내재가 기본…

소프트웨어의 결함 생명과 재산에 치명적 결과• 우주왕복선 폭발 지진해일(쓰나미) 예보


우주왕복선 폭발, 지진해일(쓰나미) 예보, …

• Y2K 문제 (밀레니엄 버그)

소프트웨어 공학 개요콜롬비아콜롬비아, , 챌린저호챌린저호 폭발폭발


소프트웨어 공학 개요Y2K?Y2K?


소프트웨어 공학 개요소프트웨어의소프트웨어의 정의정의

소프트웨어 정의• 협의: 프로그램 자체

• 광의: 프로그램 + 프로그램의 개발, 운용, 보수에 필요한 정보 일체(소프트웨어 생산 결과물 일체)

소프트웨어? 프로그램?• 소프트웨어는 프로그램의 동적인 실체

• 프로그램은 형식 언어로 표현된 지적 노동의 결과물

• 제조업 vs. 서비스업(소프트웨어는 제작이 아니라 창조적 노력이 포함된 개발)

닳아 없어지는 것이 아니라 소용없어 못쓰게 됨• 닳아 없어지는 것이 아니라 소용없어 못쓰게 됨

• 논리적인 요소로 구성(유지보수가 어려움)

• 소프트웨어 산업(2007년 현재 국내는 22.7조 규모의 산업 - 정보통신산업통계연보)


소프트웨어 공학 개요소프트웨어소프트웨어 산업산업 (1/7)(1/7)


소프트웨어 공학 개요소프트웨어의소프트웨어의 특성특성

비가시성(Invisibility)

테스트 가능(Testability)테스트 가능(Testability)

복잡성(Complexity) 특히 제3자가 보았을 경우

변형성(Conformity)/변경성(Changeability)

장수(Longevity) 죽지 않는다. 단지 사라질 뿐이다.

복제 가능(Duplicability) 생명공학의 모태?

응용에 의존(Application dependability)응용에 의존( pp p y) 일반적으로, 몇 개 핵심 부품을 만들어 조립해 쓸 수가 없다.


소프트웨어 공학 개요소프트웨어의소프트웨어의 분류분류 (1/2)(1/2)

기능적 분류• 응용 소프트웨어(Application Software): 증권 처리, 학사 관리

• 시스템 소프트웨어(System Software): 운영체제, DBMS, Compiler, …

개발 과정에 따른 분류개발 과정에 따른 분류• Prototype

• Product: 상품화 이전이나 완성된 소프트웨어Product: 상품화 이전이나 완성된 소프트웨어

• Package: 시험을 거쳐서 상품화된 소프트웨어(주문형 소프트웨어: 고객의 목적에 맞도록 패키지된 소프트웨어)

하드웨어 환경에 따른 분류• Mainframe• Mainframe

• Parallel Processing or Distributed Processing

• PC & Workstation


• 모바일 디바이스 스마트폰

소프트웨어 공학 개요소프트웨어의소프트웨어의 분류분류 (2/2)(2/2)

적용 분야에 따른 분류• 통신용, 프로그래밍 언어, 사용자 인터페이스, 데이터베이스, 분산처리, …

• 문서 작성, 거래 처리, 개발 도구, 멀티미디어, …

• 전자 정부, 전자 상거래, 가상 도서관, …


소프트웨어 공학 개요소프트웨어소프트웨어 시스템시스템

유기적으로 상호 작용하는 객체들의 모임• S/W는 독립적으로 존재하는 것이 아니라 컴퓨터를 기반으로 여러 시스템이 유기적인

관계를 맺고 있다.

• 은행의 업무 전산화 예제: 현금 자동 인출기, 중앙 컴퓨터, 계좌 DB, 은행 업무 처리 절차,입출금 전표, 은행원, …입출금 전표, 은행원, …

특징• 시너지 효과: 독립적인 의미를 갖지 않고, 통합되었을 때 의미를 가짐

• 역동적으로 발전, 변경

• 상충되는 요구와 이해 관계의 절충 (최적의 모범 답안이 아닌 절충안에 해당) 교통체계• 상충되는 요구와 이해 관계의 절충 (최적의 모범 답안이 아닌 절충안에 해당) 교통체계

소프트웨어 자체도 하나의 시스템임웨어 자체 하나의 시 템임


소프트웨어 공학 개요정보정보 시스템시스템 (Information System)(Information System)

자료의 분류, 저장, 검색에 초점

데이터베이스를 대화식(interactive)으로 접근데이터베이스를 대화식(interactive)으로 접근

조직의 문제 해결을 위한 도구

정보 시스템의 예제정보 시스템의 예제

• 항공권 예약 시스템

• 신용 카드 검색 서비스신용 카드 검색 서비스

• 뱅킹 시스템

정보 시스템의 특징정보 시스템의 특징

• 대규모 자료를 관리하며, (일반적으로) 정적이 아님

• 시스템 분석과 유지보수가 중요함• 시스템 분석과 유지보수가 중요함

MIS (Management Information System, 경영 정보 시스템) [위키]

• 운영, 관리, 의사결정을 위하여 정보를 제공하는 시스템


운영, 관리, 의사결정을 위하여 정보를 제공하는 시스템

• DSS(Decision Support System), KDD(Knowledge Discovery in Database)

소프트웨어 공학 개요제어제어 시스템시스템 (Control System)(Control System)

사건을 감지하여 처리하고 자동적으로 보고

• 센서의 감지 (Ubiquitous Sensors)센서의 감지 ( q )

• 제어 기기의 상태 보고

• 운영자의 입력 처리

• 사용자 및 운영자 인터페이스

제어 시 템 예제제어 시스템 예제

• 교통 제어

• 공정 제어 컨베이어 벨트 제어• 공정 제어 컨베이어 벨트 제어

• 수치 제어

• 의료 시스템 초음파 검사, 메디슨…

• 무기 ( DARPA, FBI, … 테러 방지)

• 항공 제어


• 재난, 방재 산업 산불 감지, 지진 감지

소프트웨어 공학 개요((오리지널오리지널) ) 탑재탑재 시스템시스템 (Embedded System)(Embedded System)

주된 기능이 계산이 아닌 시스템의 구성 요소의 일부(A system that is logically incorporated in a larger system whose y g y p g yprimary function is not computation.)

탑재 시스템 예제• 전자 기계 장치, 공정 제어 시스템

• 비행기 유도 스위칭 시스템(교환기 등)• 비행기 유도, 스위칭 시스템(교환기 등)

• 환자 감시 시스템, 레이다 추적 시스템

탑재 시스템 특징• 대규모, 장기 사용, 테스트하기 어려움

인터페이스가 복잡 비동기 병렬 분산• 인터페이스가 복잡, 비동기, 병렬, 분산

• 대규모 자료를 접근, 변경, 출력

• 실시간 제어 인터페이스


시 제어 터페이

• 엄격한 요구: 실시간 반응, 고장에 대한 안전, 신뢰성

소프트웨어 공학 개요((요즘의요즘의) Embedded System) Embedded System

소형 디바이스에 들어가는 소프트웨어• PDA, 휴대폰용 운영체제, 게임, 영상 재생, …

• 소형 센서에 탑재되는 소프트웨어

• …

Embedded Software를 어떻게 배워~• 프로그램(C, Java, Assembly, …)을 잘하고,프로그램(C, Java, Assembly, …)을 잘하고,

• 운영체제(Windows, UNIX/Linux), DBMS를 잘 이해하는 등의

• 기본에 충실하면 쉽게 적응할 수 있어요…

• 안드로이드를 배워 봅시다.


소프트웨어 공학 개요We are now …We are now …







소프트웨어 공학 개요소프트웨어소프트웨어 위기위기(Software Crisis) (1/2)(Software Crisis) (1/2)

100

총비용 %

100

80

60 하드웨어 비용 소프트웨어

개발 비용

40

소프트웨어20

0

소프트웨어유지보수 비용

01955 1980 1995


소프트웨어 공학 개요소프트웨어소프트웨어 위기위기(Software Crisis) (2/2)(Software Crisis) (2/2)

소프트웨어 공정의 문제점• 비용 초과 (Cost Overruns)

• 기간 지연 (Late Delivery)

• 성능 저하 (Inadequate Performance)

신뢰성 저하 (Unreliability)• 신뢰성 저하 (Unreliability)

• 유지보수 불가능, 엄청난 유지보수 비용 (Prohibitive Maintenance Costs) SMSC 경험

소프트웨어 위기: 소프트웨어의 요구(demand)와 그 공급(supply) 능력간의 차이가 갈수록 심화되고 있음

1965 – 1985 Increase Rate at 1983

Increase in Demand (요구의 증가) 100 times 12%

d i i 생산성Productivity (생산성) 2 times 4%

Manpower Supply (인력 공급) 10 times 4%


소프트웨어 공학 개요소프트웨어소프트웨어 개발의개발의 또또 다른다른 문제점문제점

개발 예산이 초과되고, 일정이 지연되는 경우가 많다.• 개발 일정과 비용 예측이 부정확하다.

• 과거 프로젝트에 대한 경험이 잘 축적되지 않을 뿐 아니라, 과거 데이터가 현재에잘 적용되지 않는 경우가 많다.

프로그래머 개인 역량에 따라 소프트웨어 개발 성패가 좌우된다.• 프로그래머 개인의 능력과 경험이 중요하여, 작업의 정량적인 분석이 어렵다.

• 잘 키운 슈퍼 프로그래머 하나가 열 … 안 부럽다.

소프트웨어 품질을 평가하기가 어렵다.• 체계적인 시험이 없으면, 운영 중에 많은 오류가 발생한다.

다른 공산품과 같은 불량품 관리 품질 보증에 대한 확실한 정량적 개념이 없다• 다른 공산품과 같은 불량품 관리, 품질 보증에 대한 확실한 정량적 개념이 없다. 다른 공산품의 경우, “불량률 0에 도전,” “무재해 100만시간 달성 목표”


소프트웨어 공학 개요엔지니어링엔지니어링 원리의원리의 발전발전 단계단계

과 학

대량생산엔지니어링

상업화

장인들의 기술

초창기에는 소수의 재능 있는 장인 개개인에 기술이 머물다가,

대량 생산의 필요에 의해 경험과 노하우를 교환하면서 상업화가 이루어지고,

상업화가 되면 자원 공급, 비용 등의 경제적 고려가 필요하며, 결국 과학


이 동원되어 엔지니어링으로 발전한다.

소프트웨어 공학 개요소프트웨어소프트웨어 공학공학 (1/2)(1/2)

복잡한 대규모 문제 해결을 위해서는 엔지니어링(공학) 접근법이 필요

• 요리를 잘하는 집안 식구가 음식점을 개업한다면• 요리를 잘하는 집안 식구가 음식점을 개업한다면….

집안 식구가 먹기 위하여 만드는 음식과는 다른 접근법이 필요하다.

재료 구입, 조리 시간, 서빙, …

• 개업한 음식점이 잘 되어서, 전국 체인점을 내려 한다면…

음식점 하나를 운영하는 것과는 다른 차원의 접근법이 필요하다.

재료 전달 조리법 체계화/기계화 훈련 재료 전달, 조리법 체계화/기계화, 훈련, …

한 사람이 램을 작성할 때와 한 팀이 작성할 때 한 서가 작성할한 사람이 프로그램을 작성할 때와 한 팀이 작성할 때, 한 부서가 작성할

때는 각기 다른 공학적 접근법이 필요하다.


소프트웨어 공학 개요소프트웨어소프트웨어 공학공학 (2/2)(2/2)

소프트웨어 공학의 정의• 질 좋은 소프트웨어를 경제적으로 생산하기 위하여 공학, 과학 및 수학적 원리와 방법을

적용하는 것 - Watts Humphrey, SEI

• 소프트웨어의 개발, 운용, 유지보수 및 소멸에 대한 체계적인 접근 방법- IEEE Computer SocietyIEEE Computer Society

• 품질, 효율, 비용, 인정에 관한 공학적인 접근 원리 - F. Brooks

소프트웨어 공학의 목표• 품질 좋은 소프트웨어를

• 최소의 비용으로• 최소의 비용으로

• 계획된 일정에 맞추어 개발한다.

품질(Quality), 생산성(Productivity)품질(Q y), 생산성( y)


소프트웨어 공학 개요소프트웨어소프트웨어 공학에서공학에서 다루는다루는 주제주제 (1/2)(1/2)

프로세스 패러다임프로세스 패러다임

소프트웨어 공학 기술

방법 도구

소프트웨어 공학 기술

방법 (method): 어떻게 만들 것인가?

도구 (tool): 무엇을 사용해 만들 것인가?

프로세스 (process): 어떤 과정/단계로 만들 것인가?

패러다임 (paradigm): 어떤 접근법/스타일을 사용할 것인가?


소프트웨어 공학 개요소프트웨어소프트웨어 공학에서공학에서 다루는다루는 주제주제 (2/2)(2/2)

분 야 의 미 사 례 요리 비유

방법(method)

소프트웨어 제작에 사용하는 기법이나 절차

구조적 분석/설계 방법객체지향 분석/설계 방법

익히는 방법(구이 찜 훈제 등)(method) 하는 기법이나 절차 객체지향 분석/설계 방법 (구이, 찜, 훈제 등)

도구(tool)

자동화된 시스템설계 도구

프로그래밍 도구테스트 도구

요리 도구(프라이팬, 압력 솥, 오븐 등)

테 구

프로세스(process)

도구와 기법을 사용하여작업하는 순서

eXtreme Programming 조리 순서

패러다임 구조적 방법론 음식 스타일패러다임(paradigm)

접근 방법, 스타일구조적 방법론

객체지향 방법론음식 스타일

(한식, 일식, 중식, 퓨전 등)

XP(eXtreme Programming)란 단순성, 의사소통, 피드백, 용기 등 네 가지 가치를 매우 중요하게 생각하는 소프트웨어

개발방법론 중 하나로 “고객에게 최고의 가치를 가장 빨리’ 전달하도록 하는 것을 최고의 가치로 삼는다.

특히 요구사항 많거나 잦은 변화가 예상되는 위험부담이 큰 프로젝트를 하는 경우에 개발자가 소규모(10명 내외)이고

같은 공간을 사용하는 경우에 높은 효과를 볼 수 있다고 알려져 있다같은 공간을 사용하는 경우에 높은 효과를 볼 수 있다고 알려져 있다.

이 방법론의 대표적인 방법으로는 팀워크와 고객가치를 중시, 2인조 프로그래밍, 우선순위가 높은 일 지속적으로 처리하기, 자료를 따로 보관하지 않고 지속적으로 통합하기, 테스팅 적극적으로 이용하기, 코드 공동 소유하기,

고객 현장에 참여하기 설계를 단순하게 하기 등이 있다


고객 현장에 참여하기, 설계를 단순하게 하기 등이 있다.

소프트웨어 공학 개요Extreme Extreme ProgrammingProgramming SportsSports


소프트웨어 공학 개요소프트웨어소프트웨어 품질품질 (Software Quality) (1/4)(Software Quality) (1/4)

소프트웨어를 대하는 입장에 따라 품질에 대한 관점이 달라짐

발주자 사용자

최소 비용생산성

기능의 정확성이해 용이성사용 용이성효율성융통성사용 용이성일관된 통합

신뢰성

효율성

이식성재사용성

유지보수성상호 운용성 유지보수자



정확성(Correctness)

• 기능적으로 맞게 동작하는가 표준에 적합한가• 기능적으로 맞게 동작하는가, 표준에 적합한가

• 요구 분석서의 기능과 일치하는지 점검

신뢰성(Reliability)

• 소프트웨어가 주어진 기간 동안 바르게 작동할 확률웨어가 주어진 기간 동안 바 게 작동할 확률

• 오류 발생 확률에 반비례

• 정확성 제공하기 위한 필요조건

강인성(Robustness)

• 요구 명세에 표시하지 않은 상황(오류 입력)에서도 제대로 작동하는 성질



성능(Performance)

• 수행 속도 데이터/트랜잭션 처리량• 수행 속도, 데이터/트랜잭션 처리량

• 알고리즘의 시간 복잡도

• 시뮬레이션, 스트레스 테스트시 레이 레 테

사용 용이성(Usability)사용 용이성( y)

• 시스템을 친근하게 느낄 수 있는 성질

• 사용 대상에 따라 달라질 수 있음

• 사용자 인터페이스, Human factor

유지보수성(Maintainability)

• 보수성: 정해진 기간에 소프트웨어 결함을 해결할 수 있는 성질


• 진화성: 잠재적 발전 가능성 (추가 요구사항에 따라 기능이 진화할 수 있어야 함)


재사용성(Reusability)

• 소프트웨어 부품(라이브러리 클래스 등)의 성질• 소프트웨어 부품(라이브러리, 클래스 등)의 성질

• 확장 가능성 – openness

• 적응성 – adaptability적응성 p y

• 이용 용이성 - closeness


소프트웨어 공학 개요소프트웨어소프트웨어 품질의품질의 구분구분

프로덕트 품질

• 소프트웨어 자체의 품질을 의미한다• 소프트웨어 자체의 품질을 의미한다.

• 수돗물 비교: 수돗물 자체의 품질, 즉, 맛, 색깔, 유해성분, …

일반적으로 생각하는 품질을 의미한다.적 생각하 을 의미한다

프로세스 품질세 품질

• 소프트웨어를 개발하는 과정의 품질을 의미한다.

• 수돗물 비교: 수돗물을 전달하는 파이프의 청결도, 집수장의 위치, …

과정의 품질이 좋지 않으면 궁극적인 프로덕트의 품질이 나쁘다는 인식에서 출발한다.

프로세스의 품질이 높으면 S/W에 내재된 잠재적인 오류를 줄일 수 있다.

과거에는 프로덕트 품질을 중시했으나, 현재는 모든 분야에 있어서 프로


세스의 품질을 중시하고 있다. (ISO 인증).

소프트웨어 공학 개요프로덕트프로덕트 품질품질

소프트웨어 자체의 품질을 의미하나…

소프트웨어를 대하는 사람의 입장에 따라서 품질의 정의가 달라진다.

• 구매자: 외부로 드러나는 품질요소(external characteristics)를 중시한다.

(예를 들어, 오류 횟수, 판매 횟수 등)

• 유지보수 엔지니어: 제조 과정에 내재된 내부 특성(internal characteristics)를 중시한다• 유지보수 엔지니어: 제조 과정에 내재된 내부 특성(internal characteristics)를 중시한다.

(예를 들어, 함수 재사용이 용이한가?)

McCall의 품질 모델 교재 p. 32의 [그림 1.6] 참조


소프트웨어 공학 개요프로세스프로세스 품질품질 (1/2)(1/2)

개발하는 과정이 소프트웨어 품질에 많은 영향을 준다는 주장

개발 및 유지 수하는 세스의 품질이 덕 자체의 품질 못지개발 및 유지 보수하는 프로세스의 품질이 프로덕트 자체의 품질 못지

않게 중요하다는 입장

향상 방안

• 특정 오류가 언제 어디서 발견되는가?

• 어떻게 하면 개발 과정에 오류를 조기에 발견할 수 있는가?

• 어떻게 하면 오류에 대한 내성이 있는 시스템, 즉 오류가 소프트웨어를 정지시키는 확률

이 적은 시스템으로 만들 수 있는가?이 적은 시스템으로 만들 수 있는가?

• 프로세스가 좋은 품질을 보장하는 더 효율적이며 효과적인 다른 방법이 있는가?

(일본의 농산품 관리 방법)(일본의 농산품 관리 방법)


소프트웨어 공학 개요프로세스프로세스 품질품질 (2/2)(2/2)


소프트웨어 공학 개요소프트웨어소프트웨어 생산성생산성 (Productivity)(Productivity)

생산 과정(process)에 크게 영향

Process improvement• Process improvement

개발 경험의 성숙도에 의해 좌우개발 경험의 성숙도에 의해 좌우

• CMM(Capability Maturity Model): Level 1~5

생산성에 영향을 미치는 요소

• 프로그래머의 능력• 프로그래머의 능력

• 팀 의사 전달

• 제품의 복잡도제품의 복잡

• 기술 수준

• 관리 기술


소프트웨어 공학 개요소프트웨어소프트웨어 프로세스프로세스 모형모형

소프트웨어 라이프 사이클

개념화단계

유아 및성장기

성년기(제품으로서)

유아기

개발 단계 개발 후개발 전 개발 단계 개발 후개발 전


소프트웨어 공학 개요건축건축 프로세스프로세스

(요구 분석) 집을 짓기 위해서는 건축설계사가 집주인과 만나 어떤 집을

원하는지 들어본다원하는지 들어본다.

(구조 설계) 건축설계사는 집주인의 요구를 반영하여 층별 배치도와 개

략적인 조감도를 그린다략적인 조감도를 그린다.

(상세 설계) 평면도, 측면도를 필요한 자세한 설계 도면을 준비한다.

(구현) 설계가 끝나면 시공단계에 들어가서 실제로 집을 짓는다.

(테스트) 집을 지은 후에는 전등이 잘 켜지는지, 난방이 잘되는지 등의

각종 점검을 수행한다.

(유지보수) 집이 완성된 후에는 하자에 대한 유지보수를 수행한다.(유지 수) 집이 완성된 후에는 하자에 대한 유지 수를 수행한다


소프트웨어 공학 개요소프트웨어소프트웨어 프로세스프로세스 모형모형

개발 프로세스: 개발 과정을 체계적으로 정리한 과정

실정에 맞는 개발 팀의 고유한 모형의 정립 필요

소프트웨어 개발에 필요한 작업

요구 분석과 정의• 요구 분석과 정의

• 시스템 설계 ( 건축의 구조 설계에 해당)

• 프로그램 설계 ( 건축의 상세 설계에 해당)• 프로그램 설계 ( 건축의 상세 설계에 해당)

• 프로그램의 작성(구현)

• 테스트(단위 테스트, 통합 테스트, 시스템 테스트)테 (단위 테 , 통합 테 , 시 템 테 )

• 시스템 설치

• 유지보수


소프트웨어 공학 개요대표적인대표적인 소프트웨어소프트웨어 프로세스프로세스 모형모형

폭포수 모형 (Waterfall Model)

타이핑 형 (P i M d l)프로토타이핑 모형 (Prototyping Model)

점증적 모형 (Incremental Model)

나선형 모형 (Spiral Model)

V 모형 (V Model)


소프트웨어 공학 개요폭포수폭포수 모형모형 (Waterfall Model) ((Waterfall Model) (1/3)1/3)



계 획

요구 분석

설 계

구 분석

구 현

시 험

인수설치


소프트웨어 공학 개요폭포수폭포수 모형모형 (Waterfall Model) (Waterfall Model) (3/3)(3/3)

1970년대 소개항공 방위 소프트웨어 개발 경험으로 습득항공 방위 소프트웨어 개발 경험으로 습득

각 단계가 다음 단계 시작 전에 끝나야 함각 단계가 다음 단계 시작 전에 끝나야 함

• 순서적 - 각 단계 사이에 중복이나 상호작용이 없음

• 각 단계의 결과는 다음 단계가 시작 되기 전에 점검각 단계의 결과는 다음 단계가 시작 되기 전에 점검

• 바로 이전 단계로의 피드백만이 가능함

단순하거나 응용 분야를 잘 알고 있는 경우 적합

• 한 번의 과정, 비전문가가 사용할 시스템 개발에 적합

결과물(deliverable) 정의가 중요


소프트웨어 공학 개요폭포수폭포수 모형의모형의 프로세스프로세스 및및 결과물결과물 요약요약

계획 요구 분석 설계

•문제정의•타당성 분석 계획서

•DFD•자료사전 요구

•시스템구조설계•프로그램설계

구조설계서상세설계서

P R D

•타당성 분석•비용, 일정예측

계획서 •자료사전•소단위명세서

구분석서

•프로그램설계•UI 설계

상세설계서

구현 시험 인수/설치

통합시험

I T A

•프로그래밍•단위테스트

프로그램•통합시험•기능시험•성능시험

통합된프로그램

•설치•인수 시험

설치된소프트웨어

활동 결과물(활동) (결과물)


소프트웨어 공학 개요폭포수폭포수 모형모형 –– 계획계획 (Planning)(Planning)

문제의 실현 가능성을 타진한다. (feasibility study)

영구 기관(엔진)을 만들 수는 없다? 물로 가는 자동차는? 영구 기관(엔진)을 만들 수는 없다?, 물로 가는 자동차는?

열역학 법칙을 깬열역학 법칙을 깬세계 최초 L4 영구기관?

개발하고자 하는 시스템의 성격을 파악하여 비용과 기간을 예측한다.

예측을 잘못하면 소위 “열심히 하고 욕먹는 결과”를 초래한다.

개발 방법과 각 단계에 필요한 자원을 결정한다.

좋은 도구를 사용할 경우, 인력을 크게 줄일 수도 있다.


좋은 도구를 사용할 경우, 인력을 게 줄일 수도 있다.

소프트웨어 공학 개요폭포수폭포수 모형모형 –– 요구요구 분석분석 (Requirement Analysis)(Requirement Analysis)

개발을 의뢰한 사용자(일반인, 운영자, …) 요구나 주어진 문제를 정확히

분석하고 이해하는 과정이다분석하고 이해하는 과정이다.

발주자와 개발자가 요구 분석 사항에 동의하여야 다음 단계 진행이 가능발주자와 개발자가 요구 분석 사항에 동의하여야 다음 단계 진행이 가능

하다.

소프트웨어가 어떤 품질을 만족해야 하는지 결정한다• 소프트웨어가 어떤 품질을 만족해야 하는지 결정한다.

• 소프트웨어가 어떤 기능을 제공해야 하는지 결정한다.

( 세부적으로 어떻게 구현할 지는 추후 설계 단계에서 생각한다.)( 세부적 어떻게 구현할 지는 추후 설계 단계에서 생각한다 )

요구분석서는 사용자와 개발자의 의사 소통 수단으로서 정확하고 간결요구분석서는 사용자와 개발자의 의사 소통 수단으로서, 정확하고 간결

하고 완벽하며 이해하기 쉽고 일관성을 유지하도록 작성해야 한다.


소프트웨어 공학 개요폭포수폭포수 모형모형 –– 설계설계 (Design)(Design)

시스템 구조 설계

소프트웨어 구조를 어떻게 가져갈 것인가?• 소프트웨어 구조를 어떻게 가져갈 것인가?

• 일반적으로, 소프트웨어 모듈을 정의하고, 각 모듈간의 관계를 정의한다.

프로그램 설계

• 각 모듈내의 알고리즘을 설계한다• 각 모듈내의 알고리즘을 설계한다.

• 모듈간의 인터페이스 방법을 설계한다.

사용자 인터페이스 설계

• 입력 형식(메뉴 음성입력 등)을 결정하고 설계한다• 입력 형식(메뉴, 음성입력 등)을 결정하고 설계한다.

• 출력 형식(화면, 소리 등)을 결정하고 설계한다.


소프트웨어 공학 개요폭포수폭포수 모형모형 –– 설계설계 ((시스템시스템 구조구조 설계설계 예제예제))

PDSN/IWFGGSN LME SMSC IPLS AAA JUICE WISE INBH NMS WINGS

SANTA

MS LME SMSC IPLS AAA JUICE WISE INBH NMS WINGS

LME SMSC IPLS AAA JUICE WISE INBH NMS WINGS

메시지 송수신 페이징 처리

단말 정보 처리

SANTA 과금 처리 기타 연동

IXPC(I t / Xt P C i ti )

데이터베이스

정보 관리 및 공유

(Inter/eXter Process Communication) 메시지 파일

운용자 정합운용 및 유지보수메시지 정보 관리 제어 및 호처리

통계/장애/상태 관리 Graphical UI

Textual UI

운용자 정합

운용/형상/구성 관리

운용 및 유지보수

데이터베이스 관리

파일(메시지) 관리

메시지 정보 관리

메시지 상태 관리

호처리 제어

제어 및 호처리


소프트웨어 공학 개요폭포수폭포수 모형모형 –– 설계설계 ((사용자사용자 인터페이스인터페이스 설계설계 예제예제))

GUI(Graphical User Interface): Java 기반으로 이식성 높고 편리한 환경 제공

TUI(Textual User Interface): 원격지에서 MML을 사용한 운영 기능 제공

MMC Category 선택 Combo Box

명령어 입출력

환경

MMC Command List MMC Command Result Output Window

MMC Command Parameter Table

MMC Command Input Text Field

Command실행

Command

Output Window 결과삭제

Window


MMC Command Input Text Field도움말 닫기

소프트웨어 공학 개요폭포수폭포수 모형모형 –– 구현구현 (Implementation)(Implementation)

미리 정해진 모듈 설계에 따라 프로그램, 즉 코딩을 수행한다.

코딩된 각 모듈은 테스트의 기본 단위이다.

모듈 테스트는 테스트 단계가 아닌 구현 단계로 보기도 한다 모듈 테스트는 테스트 단계가 아닌 구현 단계로 보기도 한다.

코딩 작업 자체도 개발회사 전체적인 표준이 있어야 한다.

• 헤더 주석, 변수 작명 규칙, 모듈의 최소 및 최대 크기 등

• 모듈 테스트도 회사 전체의 표준이 있어야 한다.

테스트 계획서, Code Inspection, …


소프트웨어 공학 개요폭포수폭포수 모형모형 –– 구현구현 ((모듈모듈 테스트의테스트의 예제예제))


소프트웨어 공학 개요폭포수폭포수 모형모형 –– 시험시험 (Test)(Test)

각 모듈들이 정의된 인터페이스에 따라 잘 동작하는지 통합 시험

(integration test)을 수행한다(integration test)을 수행한다.

여러 모듈을 조금씩 결합하면서 단계적으로 시험하는 방법을 취한다여러 모듈을 조금씩 결합하면서 단계적으로 시험하는 방법을 취한다.

테 개발 기관 내 에서 실제 사용해 테스트: 개발 기관 내부에서 실제 사용해보는

시험이다. i 허스키 익스프레스를 넥슨 직원들을 대상으로 version: 허스키 익스프레스를 넥슨 직원들을 대상으로

open한다.

테스트: 선택된 고객을 대상으로 실제 테스트: 선택된 고객을 대상으로 실제

사용해보는 시험이다. version: 허스키 익스프레스를 프로게이머들을


허 키 익 레 를 게이머들을

대상으로 open한다.

소프트웨어 공학 개요폭포수폭포수 모형모형 –– 인수인수 (Acceptance)(Acceptance)

패키지 소프트웨어인 경우,

사용자가 소프트웨어를 설치할 수 있도록 설치 안내서를 제공한다사용자가 소프트웨어를 설치할 수 있도록 설치 안내서를 제공한다.

주문형 소프트웨어인 경우주문형 소프트웨어인 경우,

사용자 앞에서 직접 설치하며, 필요한 경우 인수 시험(acceptance test)

을 실시한다을 실시한다.

설치 단계가 끝나면 웨어 생명 기에 있어서 운용 및 유지설치 단계가 끝나면 소프트웨어 생명 주기에 있어서 운용 및 유지보수

단계로 넘어간다.


소프트웨어 공학 개요폭포수폭포수 모형의모형의 결과물결과물(Deliverable)(Deliverable)

Activity Output documentsRequirements analysis Feasibility study Outline requirementsRequirements analysis Feasibility study, Outline requirementsRequirements definition Requirements documentSystem specification Functional specification, Acceptance test plan

D ft lDraft user manualArchitectural design Architectural specification, System test planInterface design Interface specification, Integration test planD il d d i D i ifi i U i lDetailed design Design specification, Unit test planCoding Program codeUnit testing Unit test reportModule testing Module test reportIntegration testing Integration test report, Final user manualSystem testing System test reportAcceptance testing Final system plus documentation

단 프로젝트의 규모 및 성격에 따라서 크게 달라질 수 있다


단, 프로젝트의 규모 및 성격에 따라서 크게 달라질 수 있다.

소프트웨어 공학 개요폭포수폭포수 모형의모형의 장단점장단점

장점

개발자가 어떤 작업을 수행하고 있는지 그 단계가 명확하다• 개발자가 어떤 작업을 수행하고 있는지 그 단계가 명확하다.

• 프로세스가 간단하여 일반인도 쉽게 이해할 수 있다.

• 중간 산출물이 명확하게 지정되어 있다.중간 산출물이 명확하게 지정되어 있다.

단점단점

• 처음 단계를 지나치게 강조하면 코딩, 테스트가 지연된다.

• 각 단계의 전환에 많은 노력을 기울여야 한다 (뒤로 돌아가기 어렵다 )• 각 단계의 전환에 많은 노력을 기울여야 한다. (뒤로 돌아가기 어렵다.)

• 소용없는 다종의 문서를 생산할 가능성 있음


소프트웨어 공학 개요프로토타이핑프로토타이핑 모형모형 ((1/3)1/3)

프로토타이핑이란 시스템의 일부 혹은 모형를 만드는 과정이다.

시뮬레이션을 수행하거나 데 시스템을 만 는 방법 등이 있다시뮬레이션을 수행하거나, 데모 시스템을 만드는 방법 등이 있다.

Rapid Prototyping Model ( 컬러링 예제)

요구분석

프로토타입개발/개선

프로토타입평가

google phoneprototype

구현

인수/설치


인수/설치

소프트웨어 공학 개요프로토타이핑프로토타이핑 모형모형 ((2/3)2/3)

시범 시스템의 적용

• 사용자의 요구를 더 정확하게 추출한다.

• 알고리즘의 타당성, 운영체제와의 조화, 인터페이스의 시험 제작을 통

해 요구사항을 명확히 하고 위험을 줄일 수 있다.

프로토타이핑 도구프로토타이핑 도구

• 화면 생성기

비주얼 프로그래밍 4세대 언어 등• 비주얼 프로그래밍, 4세대 언어 등

공동의 참조 모델 제공

개발 단계에서 유지보수가 이루어짐


소프트웨어 공학 개요프로토타이핑프로토타이핑 모형모형 (3/3)(3/3)

프로토타이핑의 단점

• 오해 (프로토타입을 보고, 전부 다 개발한 것 아니냐고 할 수 있음)

• 기대심리 유발 (프로토타입이 이 정도이니, 최종 결과물은 …)

• 관리가 어려움(중간 산출물 정의가 난해)


소프트웨어 공학 개요점증적점증적 모형모형 (1/2)(1/2)

개발 싸이클이 짧은 환경

빠른 시간 안에 시장에 출시하여야 이윤에 직결된다 빨리 만들어 일단 반응을 보자• 빠른 시간 안에 시장에 출시하여야 이윤에 직결된다. 빨리 만들어 일단 반응을 보자.

• 개발 시간을 단축하는 법 시스템을 나누어 릴리스한다.

개발

개발 시스템

릴리스 1 구축 릴리스 2 구축 릴리스 3 구축발자

릴리스 1 사용 릴리스 2 사용 릴리스 3 사용사용자

완성 시스템


소프트웨어 공학 개요점증적점증적 모형모형 (2/2)(2/2)

릴리스 구성 방법

점증적(incremental) 방법 기능별로 릴리스• 점증적(incremental) 방법 – 기능별로 릴리스

• 반복적(iterative) 방법 – 릴리스할 때마다 기능의 완성도를 높임

단계적 개발

• 기능이 부족하더라도 초기에(빠른 시점에) 사용 교육이 가능• 기능이 부족하더라도 초기에(빠른 시점에) 사용 교육이 가능

• 처음 시장에 내놓는 소프트웨어는 시장을 빨리 형성시킬 수 있음

• 자주 릴리스하면 가동 중인 시스템에서 일어나는 예상하지 못했던 문제를 신속 꾸준히

고쳐나갈 수 있음

• 개발 팀이 릴리스마다 다른 전문 영역에 초점 둘 수 있음

이번 Release에서는 성능 짱

이번엔 GUI 짱

…


…

소프트웨어 공학 개요나선형나선형 모형모형 (1/3)(1/3)

Determine objectives

Riskanalysis

Riskanalysis

Evaluate alternativesidentify, resolve risks

Determine objectivesalternatives and

constraints

analysis

Riskanalysis

Riskanalysis Proto-

Prototype 2

Prototype 3Opera-tionalprotoype

analysis Proto-type 1

Concept ofOperation

Simulations, models, benchmarks

S/Wrequirements Product

Requirements planLife-cycle plan

REVIEW

requirements

Requirementvalidation

DesignV&V

Productdesign Detailed

design

CodeUnit test

IntegrationIntegration

Developmentplan

V&V IntegrationtestAcceptance

testService Develop, verifynext-level product

Plan next phase

Integrationand test plan



소프트웨어의 기능을 나누어 점증적으로 개발

실패의 위험을 줄임 위험 분석에 초점을 맞춘 개발 모형• 실패의 위험을 줄임 위험 분석에 초점을 맞춘 개발 모형

• 테스트 용이

• 피드백이 용이피드백이 용이

여러 번의 점증적인 릴리즈(incremental releases)여러 번의 점증적인 릴리즈(incremental releases)

진화 단계진화 단계

• 계획 수립(planning): 목표, 기능 선택, 제약 조건의 결정

• 위험 분석(risk analysis): 기능 선택의 우선순위 위험요소의 분석• 위험 분석(risk analysis): 기능 선택의 우선순위, 위험요소의 분석

• 개발(engineering): 선택된 기능의 개발

• 평가(evaluation): 개발 결과의 평가


평가(evaluation): 개발 결과의 평가


대규모 시스템 개발에 적합

Risk reduction mechanism• Risk reduction mechanism

반복적인 개발 및 테스트

강인성 향상• 강인성 향상

단점

관리가 중요 (상당히 복잡하고 긴 과정 )• 관리가 중요 (상당히 복잡하고, 긴 과정 …)

• 위험 분석이 중요

• 상대적으로 새로운 모형 ( 적용이 쉽지 않음)• 상대적으로 새로운 모형 ( 적용이 쉽지 않음)


소프트웨어 공학 개요V V 모형모형

폭포수 모형에 시스템 검증과 테스트 작업을 강조함

폭 수 형에서 감춰진 반복과 재작업을 러내 놓은 형임폭포수 모형에서 감춰진 반복과 재작업을 드러내 놓은 모형임

인수/설치

요구 분석 시스템 테스트요구분석 검증

시스템 설계 통합 테스트인터페이스 검증

상세 설계 단위 테스트

모듈 검증

구현(코딩)


소프트웨어 공학 개요소프트웨어소프트웨어 프로젝트프로젝트 성패에성패에 영향을영향을 미치는미치는 요소요소

의사소통(Communication skill)

젝 의 성격프로젝트의 성격

프로그래머의 역량(Maturity)

관리(Management)

팀의 프로젝트 경험(Experience)


소프트웨어 공학 개요Communication SkillCommunication Skill

발주자와 개발자의 의사 소통

발주자는 컴퓨터 및 소프트웨어에 대한 지식이 부족하고 개발자는 발주자의 전문 분야• 발주자는 컴퓨터 및 소프트웨어에 대한 지식이 부족하고, 개발자는 발주자의 전문 분야

에 대한 지식이 부족함

• 인터뷰 기술터뷰 기

• 프로토타입

• 요구 취합 방법(설문지, 유저 그룹, 워크샵, ...)

• 정형적 방법

개발자들 사이의 의사 소통

• Mythical man-month (개발자가 많이 투입된다고 해서 생산성이 높아지지는 않는다.

개발 인원이 많아질 수록 의사소통이 많아지기 때문)

• 문서화 궁극적으로 글로 표현을 해야 명확한 경우가 많다. (뒤탈도 없고)

기술회의 (BUT 잦은 회의는 오히려 생산성을 떨어뜨릴 수 있다 )


• 기술회의 (BUT, 잦은 회의는 오히려 생산성을 떨어뜨릴 수 있다.)

소프트웨어 공학 개요프로젝트프로젝트 성격성격

응용분야에 따라 성격이 달라짐

자료처리 중심? 제어 중심? 시스템 소프트웨어? 인공지능?• 자료처리 중심?, 제어 중심?, 시스템 소프트웨어?, 인공지능?

크기, 복잡도소프트웨어 규모

분류 참여 프로그래머 기간소프트웨어 규모(원시코드 줄)

단순 규모소규모

11

1~4주1~6개월

5001K~2K소규모

중규모대규모

초대규모

12~55~20

100~1000

1 6개월1~2년2~3년4~5년

1K 2K5K~50K

50K~100K1M

• 소규모: 단순한 데이터 처리 과학 계산용 프로그램

초대규모극초대규모

100 10002000~5000

4 5년5~10년

1M1M~10M

• 소규모: 단순한 데이터 처리, 과학 계산용 프로그램

• 중규모: 어셈블러, 컴파일러, 소규모 경영 정보 시스템, 재고 관리

• 대규모: 컴파일러, 실시간 처리 시스템, DBMS


• 초대규모, 극초대규모: 군사 명령 제어 체계, 통신 시스템, 은행 전산망 관리

소프트웨어 공학 개요프로그래머프로그래머 역량역량

소프트웨어 개발 – 노동집약적 산업

래머의 능력프로그래머의 능력

• 프로그래밍 능력

커뮤니케이션 능력• 커뮤니케이션 능력

• 응용 분야에 대한 이해

• 프로세스 도구에 대한 이해와 경험• 프로세스, 도구에 대한 이해와 경험

Sackman의 실험

• 프로그래밍 생산성 차이 최대 1:25 (평균 1:16)• 프로그래밍 생산성 차이 최대 1:25 (평균 1:16)

• 디버깅 능력 1:28

(미숙한 프로그래머가 작성한 모듈은) 전체 품질이나 일정에 영향(미숙한 프로그래머가 작성한 모듈은) 전체 품질이나 일정에 영향

소프트웨어 공학의 체계적이고 조직적인 접근법을 통하여 일정 부분 상

쇄가 가능하다 BUT 개인의 차이는 어디서나 나타나기 마련


쇄가 가능하다. BUT, 개인의 차이는 어디서나 나타나기 마련…

소프트웨어 공학 개요프로젝트프로젝트 관리관리 기술기술

소프트웨어 개발 관리

프로그래밍 경험• 프로그래밍 경험

• 관리 능력

소프트웨어 프로세스 관리소프트웨어 프로세스 관리

• 일정 관리

• 예산 인력 관리• 예산, 인력 관리

• 형상 관리

• 품질 관리

CMM(Capability Maturity Model) 모델

소프트웨어 품질 관리(Quality Assurance)소프트웨어 품질 관리(Quality Assurance)


소프트웨어 공학 개요CMM (Capability Maturity Model)? (1/2)CMM (Capability Maturity Model)? (1/2)

개요 (“09. 품질보증”에서 좀더 자세히 다룸)

CMM(능력 성숙도 모델 Capability Maturity Model)은 Carnegie Mellon 대학의 소프트• CMM(능력 성숙도 모델, Capability Maturity Model)은 Carnegie Mellon 대학의 소프트

웨어공학연구소(SEI, Software Engineering Institute, www.sei.cmu.edu)에서 Mark Paulk

교수가 중심이 되어 만든 소프트웨어 개발 Process에 대한 평가 모델이다.

• CMM은 1986년에 연구가 시작되어 1993년에 규격화된 CMM v1.1이 만들어졌으며, 현

재 미국의 여러 정부 조직 등에서 소프트웨어 구매 시 해당 소프트웨어를 개발한 회사

에 대한 평가 모델로서 채택하고 있다.

• CMM에서는 다섯 가지 단계의 비교적 추상적인 개념의 성숙도를 제시한다. 그리고, 소

프트웨어 개발 조직은 그 조직에서 사용하는 개발 과정과 방법론에 따라 성숙도를 부여

받는다.


소프트웨어 공학 개요CMM (Capability Maturity Model)? (2/2)CMM (Capability Maturity Model)? (2/2)

CMM 레벨• 단계 1 (Initial Level): 초기 단계로서 개발 및 관리를 위한 환경을 제공하지 못하는 단계단계 ( ) 기 단계 서 개발 및 관리를 위한 환경을 제공하지 못하는 단계

이다. 계획이 수시로 변하여 미래를 예측할 수 없으며, 프로젝트의 성공은 개인의 능력에 크게 좌우된다.

• 단계 2 (Repeatable Level): 프로젝트에 대한 계획과 관리가 어느 정도 체계화되어 있다• 단계 2 (Repeatable Level): 프로젝트에 대한 계획과 관리가 어느 정도 체계화되어 있다. 신규 프로젝트에 대해서는 과거 성공한 프로젝트에 기반하여 개발이 이루어지며, 어느정도의 문서화, 훈련 등을 수행한다.

단계 3 (D fi d L l) 개발 과정에 대한 표준 공정이 어느 정도 정착된 상태이며 품질• 단계 3 (Defined Level): 개발 과정에 대한 표준 공정이 어느 정도 정착된 상태이며, 품질향상을 위한 일정, 방법론 등이 정착된 상태이다. 정의된 프로세스에 대해서 조직 전체가 어느 정도 인식하고 있으나, 그 성숙도는 높지 않은 상태이다.

• 단계 4 (Managed Level): 조직적인 개발이 이루어지며, 소프트웨어에 대한 전반적인 테스트가 수행되고 그 결과가 피드백된다. 각 개발 단계에 대한 세분화를 통하여 생산 가능한 양적(quantitative) 측정이 가능해진다.

• 단계 5 (Optimizing Level): 품질 향상을 위한 지속적인 연구개발이 진행되며, 이를 위한데이타 및 분석 자료 축적이 가능한 상태이다. 이러한 기반을 바탕으로 소프트웨어 개발을 위한 신기술의 비용 및 이윤 분석이 가능하다.


을 위한 신기술의 비용 및 이윤 분석이 가능하다

소프트웨어 공학 개요CMM CMM 인증인증 관련관련 기사기사


소프트웨어 공학 개요Homework #1Homework #1


소프트웨어소프트웨어공학공학개요개요cs.kangwon.ac.kr/~ysmoon/courses/2010_2/se/02.pdf ·...

Documents