chap. 2 소프트웨어 공학 -...

Chap. 2 소프트웨어 공학

Prof. Haeng -Kon Kim

SELAB Catholic Univ. of Dae gu

2014 Software Engineering Chapter 2. 소프트웨어 공학

2

목차

1. 소프트웨어 공학의 역사

2. 소프트웨어 공학의 정의

3. 소프트웨어 개발 생명주기 모델

4. 소프트웨어 공학에서의 인간요소


2.1 소프트웨어 공학의 역사(1)

• 소프트웨어공학의 출현배경

– 소프트웨어 비용이 전체 “시스템” 비용의 대부분을 차지함

• 소프트웨어의 비용은 전체 시스템에서 차지하는 비율이 점차 커지고 있음 --> 소프트웨어 위기(software crisis)

3

•하드웨어 : 소프트웨어 기술발전속도

•소프트웨어 시장수요의 급증

•소프트웨어 유지보수의 어려움

•인건비 상승효과

•우수 소프트웨어의 부족

•소프트웨어 생산성 문제 대두



• 소프트웨어산업 및 소프트웨어공학의 중요성 – “소프트웨어산업은 정보기술을 기반으로 하는 21세기 선도산업으로써

제조업, 서비스업, 금융업 등 타 산업을 고도화하고 지능화하기 위한 필수적인 산업인프라로서 지식기반 사회로 가기 위한 견인차 역할을 할 뿐만 아니라 산업성장률이 높고, 부가가치가 크며, 고용창출의 효과가 커서 단독산업으로서 경제성장을 견인할 수 있는 전략산업임”

SW관련정부기관 : 정보통신산업진흥원 http://www.nipa.kr/ 소프트웨어산업협회 http://www.sw.or.kr/

한국소프트웨어산업진흥협회 http://www.kosta.or.kr/

– 소프트웨어는 초기 개발비용 보다는 유지/보수하는데 많은 비용이 필요하므로, 처음에 체계적으로 개발해야만 경제적으로 유지/보수/확장을 할 수 있음

• 소프트웨어의 특징 – Complexity(복잡성)

– Changeability(수정가능) • 하드웨어에 비해, 수정은 용이하지만 저렴하지는 않음

– Longevity(오랜 기간에 걸쳐 유지됨 : 장수) • 소프트웨어 제품은 오랜 시간에 걸쳐 수정/보완/확장되어야만 함

4

http://www.nipa.kr/

http://www.sw.or.kr/

http://www.kosta.or.kr/


5


• 1968년 : 개발 제어가 어려움

– NATO에서 “software engineering” 이라는 용어가 최초로 등장

• 1970년 : Top-down design(large project를 세분화)

– 소프트웨어 품질과 생산성에 관한 관심

• Software의 test기간 중에 발견된 error의 발생 원인이 통계적으로 보고되었으며 ,

coding error < design error 사실 판명

• 결국, 신뢰성 있는 software 개발을 위해서는 코딩 단계보다 설계 단계에서부터

고려하는 것이 중요하다고 인식되기 시작

– software 개발 단계간의 비율 및 비용 분포 등의 실태 조사


6


• 1972~73년 : Gotoless(Dijikstra가 주장) 이해·유지보수가 어려움/

modularity

• 1974~75년 : Reliability QA(Quality Assurance)

• 1976~77년 : Abstraction

• 1978~80년 : Automatic Software Development tool,

– Natural Language description design implementation testing

상품

– 부분적인 sub-tool 등장

• 1980-89년 : CASE(Computer Added Software Engineering)

• 1990~90년 중반 : Expert system, Object-Oriented CASE

• 1990년대 중반~1999 : Object-Oriented…., Component-Oriented ….

• 2000년 초반~현재 : CBD, Product Line…….


7


1960 1970 1980 1990 2000

어셈블리언어 고급언어(COBOL 등)

구조적 언어(C,Pascal,Ada 등) 실시간 언어

객체지향 언어

프로그래밍

언어

개발기법

관리방법

개발도구

표준화 및

방법론

구조적 프로그래밍

구조적 분석,설계

자료구조지향 설계

시험, 유지보수 방법

객체지향 분석,설계

정보공학

진화적 프로토타이핑

사용자인터페이스기술

품질보증, 형상관리

재사용

4세대언어

CASE

통합 CASE

표준화

국가적 방법론

상용화된 방법론


8

2.2 소프트웨어 공학의 정의(1)

1. 개요 및 정의

– 소프트웨어란?

• 프로그램뿐만 아니라 설치, 사용, 개발,

유지보수 하는 데 필요한 모든 문서 포함

• 대규모 시스템에서는 실제로, 프로그램

개발보다 문서 작성이 더욱 중요



• 소프트웨어공학에 관한 여러 정의들

– “신뢰성 있고 실제 기계에 효과적으로 작동하는 소프트웨어를

경제적으로 얻기 위해서 올바른 공학적 원리들을 체계화 시키고

이동하는 것” - Fritz Bauer

– “과학적 지식을 컴퓨터 프로그램의 설계와 제작에 실제로 응용하는

것이며, 이를 개발, 운영 그리고 유지보수하는데 필요한 문서화

과정” - Boehm

– “소프트웨어의 개발, 운영, 유지보수 그리고 폐기에 대한 체계적인

접근” - IEEE Computer Society

=> 일련의 공학적이며 체계적인 방법으로 소프트웨어를 개발하고

관리하려는 것

9



• Engineering

– 문제를 해결하는데 있어서 도구(tools)와 방법론(methodologies)을 이용

• Software 기준

– Quality (품질) : testing, debugging

– Productivity (생산성) : Man Power(인력) -> Cost(비용)

• Software Engineering 이란? – Quality와 Productivity를 높이기 위한 Tool과 methodologies

10



• 소프트웨어공학에 관한 여러 정의들의 공통사항

– 혼자서 만드는 소프트웨어보다 더 큰, 적어도 2~3인이 한달 이상 걸려서

만드는 소프트웨어 시스템을 대상으로 함 --> 개개의 프로그래머가 아닌

팀에 의해 소프트웨어 시스템을 공학적인 원리로 개발

– 그들 시스템을 개발하는데 있어 공학적 원리를 사용

– 기술적인 측면만이 아니라 비기술적, 관리적인 측면도 가질 것

• 소프트웨어 공학의 주된 목표

– 소프트웨어 제품의 품질 향상

– 소프트웨어 엔지니어의 생산성 향상

11


12


2. 공학적으로 잘 작성된 소프트웨어

– 소프트웨어 공학은 제품을 단지 생산만하는 것이 아니라 가장

경제적인 방법으로 양질의 제품을 생산하는 것을 의미

– 특징

① 소프트웨어는 사용자가 원하는 대로 동작해야 한다.

② 소프트웨어에 잠재적인 error가 가능한 적어야 한다.

③ 소프트웨어는 유지보수가 용이해야 한다.

• 프로그램 개발자와 유지보수하는 사람이 다를 경우, 유지보수에 어려움이 큼

• 따라서, command를 많이 씀으로 인해서 유지보수가 쉬워짐

④ 소프트웨어는 신뢰성이 높아야 한다.

• 하나의 error가 발생하고 나서 다음 error가 발생하는데 걸리는 시간

⑤ 소프트웨어는 효율적이어야 한다.

⑥ 소프트웨어는 사용하기 쉬워야 한다.


13

– 이러한 특성들은 상호 배타적

• 사용하기 쉽도록 사용자

인터페이스를 향상시키면 시스템의

효율이 떨어짐

• 효율성을 향상시키기 위하여

하드웨어에 밀착된 부분들을

포함하게 되면 유지보수성이

줄어듦

– 최근, 효율성보다는 사용 편리성,

유지보수성에 더 큰 비중을 두는

경향



14

2.4 소프트웨어 개발 생명주기 모델(1)

• 소프트웨어 프로세스

– 소프트웨어 제품을 생산하기 위한 행위들과 이들의 결과물들의 집합

• 수행자 : 소프트웨어 공학자

• 수행 도구 : CASE(Computer-Aided Software Engineering) -> 분석한

것을 주면 설계, 코딩까지 해줌


15

• 소프트웨어 프로세스의 공통적인 4개의 행위

사용자의

요구사항의

변화를

만족하게

SW 변경

사용자가

원하는

SW 인지

확인

명세를

만족하는

SW를 개발

SW 기능과

SW의 운영상의

제약 조건을

정의

SW 명세 SW 개발 SW 검증 SW 진화



16

SW

프로세스

특징 설명

이해성 프로세스를 명확하게 정의하고, 프로세스 정의를 쉽게 이해할 수 있는 정도는 어떠한가?

가시성 프로세스의 각 행위가 프로세스의 진행 상황을 명확하게 표현할 수 있는 정도는 어떠한가?

지원성 CASE 도구 등과 같은 도구들이 프로세스 행위에 대한 지원은 어느 정도인가?

수용성 소프트웨어 제품 생산을 책임지고 있는 개발자가 정의한 프로세스 모델을 수용하거나 사용하는가?

신뢰성 제품 결함이 나타나기 전에 프로세스 에러를 피하는 방법으로 프로세스가 정의되었는가?

견고성 예상되지 않는 문제점이 발견됨에도 불구하고 프로세스가 계속 진행될 수 있는가?

유지보수성 프로세스가 요구 사양서의 변경과 프로세스의 개선을 잘 반영할 수 있는가?

신속성 프로세스가 주어진 사양서로부터 시스템을 얼마나 빨리 만들 수 있는가?




• 소프트웨어 개발 생명주기(Software Development Life-Cycle:

SDLC)

– 요구에 의해서 소프트웨어 시스템이 탄생하고,

– 가동, 운용되는 가운데에 유지보수가 반복되고,

– 최종적으로 수명이 다하여 파기할 때까지의 전 공정을 체계화한

개념

• 소프트웨어 프로세스 모델

– 시스템이 어떠한 순서를 밟아서 개발되며, 운용, 보수되어 생애를

마칠 때까지의 작업 프로세스를 모델화(modeling)한 것

17



• 소프트웨어 프로세스 모델이 필요한 이유

– 개발조직이 해야 하는 일의 종류, 순서 및 각 단계에서 생성되어야

하는 결과물을 정리해 놓은 것

• 소프트웨어의 개발이 체계적이고 반복적으로 되기 위해 꼭 필요함

• 각 단계의 작업을 완료하고 그 다음 단계로 가기 위해서 필요한 조건을

명시함 (exit criteria)

• 개발되는 소프트웨어의 종류, 요구되는 신뢰도, 난이도, 조직의 규모

또는 문화 등에 따라 적합한 프로세스 모델이 다름

– Waterfall model, prototyping model, spiral model은 가장 많이

알려진 프로세스 모델

– 우수한 프로세스 모델은 소프트웨어의 개발이 좀 더 짧은 시간에,

좀 더 높은 품질의 소프트웨어를, 좀 더 적은 비용으로 개발할 수

있도록 도와줌

18


19

2.4.1 폭포수 모델

폭포수(Waterfall) 모델



• 각 단계별 결과물

20

문제정의

개발계획

수립

요구분석

기본설계

상세설계

프로그래밍

모듈시험

통합시험

시스템시험

인수시험

운용,유지보수

계획단계 분석단계 설계단계 구현단계 테스팅단계 운용,유지보수단계

시스템정의서

프로젝트계획서

요구사양서

임시사용자지침서

기본설계사양서

상세설계사양서

사용자지침서,시험계획서

모듈별코드

인수시험계획서

통합소프트웨어

확인된소프트웨어

검증된소프트웨어



• 폭포수 모델의 주된 특징

– Sequential: 각 단계별로 요구되는 결과물이 만족스러운 수준으로

준비되었을 때, 다음 단계의 작업이 시작됨

– Document-driven: 각 단계별로 요구되는 결과물의 대부분은

문서화되어야 하며, 검토 및 승인을 받아야만 다음 단계로 진행될

수 있음

– 특정 단계에서 필요하다면(이전 단계의 작업결과에 문제가 있는

경우) 이전의 단계로 “loop back” 할 수 있음

21


22


① 타당성 조사 단계

– 경영자가 소프트웨어의 필요성을 깨달아 이를 개발하기 위한 타당성을 검토하는 단계

– 작동 타당성

• 개발될 소프트웨어의 실사용에 대한 문제 검토

• 사용시에 발생할 수 있는 문제점 검토

– 경제적 타당성

• 소요되는 비용의 타당성 검토

• 소비자 부담 가격의 타당성 검토

– 시장 타당성

• 흥미, 판매, 설치, 서비스, 교육 등에 대한 검토

② 계획과 요구사항 단계

– 개발에 필요한 기본적인 인원과 기계를 할당하고 제품에 대한 조작 개념을 확정, 승인

– 중간검토, 필요한 자원, 책임의 한계, 스케줄, 비용, 주요 회의 등에 대한 상세한 계획

– 시스템이 제공할 서비스, 제약조건 및 목적 등을 설정

– 애매모호함 없이 정확하고 일관성 있게 기술


23

③ 기본설계 단계

– 개발될 소프트웨어에 대한 전체적인 하드웨어 및 소프트웨어 구조, 제어구조,

자료구조의 개략적인 설계를 작성, 사용자 지침서와 테스트 계획 수립 단계

– 상세계발 계획 : 예산, 조직, 책임, 스케줄, 활동범위, 기술 등의 계획

– 상세사용 계획 : 개발과 병행되어야 할 교육, 설치, 지원 등에 대한 계획

– 생산관리 계획 : 경영구조계획, 품질 보증계획, 전체적인 확인계획

– 소프트웨어 요구 명세의 승인 : 기능, 수행, 인터페이스 등에 대한 완전성

및 타당성 검토

– 개발계약의 승인 : 상기 내용에 대해 문서로 승인

④ 상세설계 단계

– 제어구조, 자료구조, 인터페이스 구조, 크기, 주요 알고리즘, 각 프로그램

요소에 대하여 완전한 규격을 작성하는 단계

– 가장 위험부담이 따르는 개발 내용에 대한 확인 및 해결 방안 모색



24

⑤ 코딩단계

– 실제 프로그램 작성

⑥ 통합테스트 단계

– 모듈별 코딩을 통합

– 모듈간 인터페이스 테스트에 중점

⑦ 실행단계

– 완전한 기능을 갖춘 시스템이 작동하는 단계

– 제품에 따르는 보고서, 지침서, 제원표, 데이터베이스 등을 완전히 갖춤

⑧ 사용자 및 유지보수 단계

– 시스템 인수 시험의 만족도 검토

– 인도 또는 판매 시스템 제품의 완벽성 여부

– 설치의 완벽성



25


• 검증(Verification)과 확인(Validation)

– 생명주기 초기단계에서 고려되어야 하며 그 결과는 이전단계로

feedback

• 검증 : Are we building the product right?

– 제품을 만든 과정은 올바른가?

– 제품이 요구사항을 만족하여 개발되었는가를 검사하는 것

• 확인 : Are building the right product?

– 올바른 제품을 만들고 있는가?

– 제품의 기능이 고객이 진정으로 원하는 대로 수행 되는지를 검사하는 것



• 특징 – 단계가 이미 정해져 있으며, 어떤 단계에서 문제가 생겨도 앞의

단계 또는 앞에 앞의 단계 등에 되돌아가는 것이 곤란

• 장점 – 소프트웨어의 개발과정을 개념적으로 자연스럽게 표현하고 있음

– 단계별 작업진행으로 해당 단계의 진척 관리가 쉬움

– 반드시 각 단계마다 눈에 보이는 성과물이 출력됨

– 사양이 분명해서 유사한 시스템의 개발 경험이 있는 경우 효율, 품질 면에서 우수

• 단점 – 앞 단계로 되돌아가서 다시 반복하는 등 많은 시스템 개발(사양이

애매모호한 시스템, 신규개발 시스템)에서는 작업단계의 변경이 곤란한 경우가 많음

– 처음 단계에서 지나치게 강조하다 보면 코딩이나 테스트 작업 지연

– 사용자의 요구를 만족하는지는 최종적인 성과물이 완성되어야만 판명

26


27


• 폭포수 모델의 문제점

– 프로젝트를 융통성 없이 명확한 개발단계로 나눔

– Customer 입장에서는 소프트웨어 개발 전 라이프 사이클 동안 초기

분석단계를 제외하고는 모두 블랙박스화 됨

• 출하한 시스템이 사용자의 요구사항을 만족하지 않아 사용되지 않는

경우가 종종 생김

– 프로젝트 초기 단계에서 사용자의 요구사항을 명확하게 한다는 것이

현실적으로 매우 어려움

• 프로젝트 진행 도중 새로운 요구사항의 발생시 이의 반영이 불가

• 개발완료 단계에서 치명적인 오류가 발생할 경우 문제해결에 소요되는

비용부담이 획기적으로 증가


28

• 개발 초기부터 Prototype(시제품)을 만들어 고객과의 의사 소통이 완료 시점까지 진행됨

• 폭포수 모델의 단점을 보완하기 위해 점진적으로 시스템을 개발해 나가는 접근 방법

프로토타이핑(prototyping) 모델

2.4.2 프로토타이핑 모델



– 개발팀은 고객 및 사용자와의 대화를 통하여 전반적인 기능을 파악하고, 우선 간단히 설계를 한 후 시제품을 만들어 사용자에게 보여주게 됨

– 사용자는 시제품을 보고 만들어질 완제품의 모습 파악

– 사용자는 시제품에 대하여 평가하고 그 결과는 시제품을 향상시키거나 완제품을 만들어가는 데 반영

29

시작

끝

요구사항 분석

시제품 설계

시제품 개발

고객의시제품 평가

시제품정제

완제품 생산



① 요구사항 분석 단계 – 고객으로부터 받은 일부의 요구 사항만 정의하고, 완전치 않은

요구사항에 대하여 윤곽을 잡아 놓음

– 추가적인 정의가 필요한 부분은 시제품이 개발된 후 계속 정제해나감

② 시제품 설계 단계 – 시제품에 대한 설계

– 사용자들이 볼 수 있는 면에 초점을 맞춤

– 시제품 개발의 목표가 확립되고 시제품에 포함될 시스템의 기능들이 선택됨

– 시제품에 포함되는 것과 시제품에서 배제되어야 하는 것이 무엇인지 규명하는 것은 중요

30



③ 시제품 개발 단계 – 일반적으로 성능, 다른 시스템과의 인터페이스 등에 대한 것은

판단하기 어려워 중요하게 다루어지지 않음

– 오류를 관리하고 다루는 면은 무시되거나 기초 수준 정도로 구현

– 시제품의 신뢰도와 프로그램 품질 수준은 떨어짐

– 이 단계의 목표는 '어떻게 하면 시제품을 빨리 만들 수 있겠는가’

④ 고객의 시제품 평가 단계 – 가장 중요한 단계라 할 수 있음

– 시제품은 고객에 의해 평가되고, 개발될 소프트웨어의 요구사항을 구체적으로 정제하기 위해 사용

– 이를 통해 요구사항의 오류을 발견하고 규명할 수 있게 되며, 추가되어야 하는 요구사항을 찾아 낼 수 있음

31



⑤ 시제품 정제 단계

– 사용자가 원하는 것을 만족시키기 위해 시제품에 대한 필요

– 시제품이 어떻게 고쳐져야 하는지 결정하고 다음 단계의 시제품이 빠르게 만들어 질 수 있도록 함

– 이 시제품은 다시 고객에게 평가되는 순환을 하게 되며 고객이 요구사항에 대하여 만족할 때까지 계속됨

⑥ 완제품 생산 단계

– 이 단계의 목표는 원하는 시스템을 개발하는 것

– 원형을 버리고 최종 시스템이 새로 만들어질 것인지, 또는 원형을 확장하여 완제품을 만들 것인지의 결정에 딸라 완제품 개발 게획이 달라질 수 있음

32



• 프로토타이핑 모델의 활용

– 시스템의 유용한 일부를 초기에 개발하여 사용자에게 배달함으로써 사용자로부터 피드백을 시스템 초기에 얻어낼 수 있음 ==> 시제품을 통해 이전에 밝혀지지 않았던 사용자의 요구사항을 구체적으로 규명할 수 있음

– 프로젝트 초기에 요구사항이 확실치 않거나 모든 요구사항을 미리 뽑아낼 수 없는 불안정한 상황일 때 프로젝트를 쉽게 제어 관리할 수 있게 해줌

– 시제품은 사용자와 시스템 간의 인터페이스에 초점을 맞추어 개발

– 피드백을 얻어낸 후 시제품을 버리는 경우도 있고, 원하는 시스템의 기능 중 중요한 부분만 구현하여 피드백을 얻은 후 계속 발전시켜 완제품을 만들어낼 수 도 있음

33



• 장점

– 시스템의 기능이 사용자에게 보여짐으로써 개발자와 사용자의 오해가 규명됨

– 생각지 못했던 기능과 서비스가 발견됨

– 사용하기 어렵거나 혼돈을 일으키는 기능들이 규명되어 명료화됨

– 분석가나 개발자는 불완전하거나 일치하지 않는 요구사항을 시제품을 통해 발견할 수 있음

• 한계점

– 만들어질 완제품이 어떨 것이라는 것에 대한 오해를 불러일으킬 수 있음

– 시제품에서 완제품으로 옮겨가는 데 많은 변화가 예상될 수 있음

– 시스템의 극한 상황 등에 대한 성능 평가가 어려움

– 다른 시스템들과의 교류 및 통합 등에 대한 결과가 쉽게 얻어지지 않음

34


2.4.3 나선형 모델

• 폭포수 모델과 프로토타이핑 모델의 장점에 새로운 요소인 위험

분석을 추가하여 만든 것 ==> 기술적 개발과 위험 관리를 하나의 모델로 통합함

– 각 cycle에서 평가 가능한 prototype을 생성함

• 산출물이 사용 가능한 시스템(release)일 필요는 없음

– 모든 prototype은 다음과 같은 위험을 관리하기 위해 사용됨

• 사용자 요구사항을 제대로 이해하지 못하는 경우의 위험

• 새로운 도구나 기술의 사용에서부터 오는 위험

• 실현 불가능한 설계부터의 위험

– 각 cycle에서 위험을 평가하고 계속 진행할 것인지의 여부를 판단

• 목적 : 시스템을 개발하면서 생기는 위험을 관리하고 최소화하려는 것

• 나선을 돌면서 점진적으로 완벽한 시스템 개발

35

나선형(Spiral) 모델



36

계획및 정의 위험 분석

고객 평가

요구사항 분석과계획 수립

고객 평가

계속추진할 것인지에 대한 결정

첫 번째 시제품

다음 단계 시제품

개발

고객의평가 반영

초기 위험 분석

다음 단계 위험 분석



① 계획 및 정의 단계

– 요구사항을 모으고 프로젝트 계획을 수립

– 나선형 사이클의 시작은 성능, 기능을 비롯한 시스템의 목표를 규명하는 것에서부터 시작

– 시스템의 목표와 제약조건에 대한 차선책이 평가, 고려될 수 있음

– 이러한 평가과정은 프로젝트 위험의 원인을 규명하는 데 효과적으로 사용

② 위험 분석 단계

– 초기 요구사항에 근거하여 위험(잘못될 가능성)이 규명됨

– 위험에 대한 평가가 이루어져 프로젝트를 ‘계속 진행할 것인지(GO)’, 또는 ‘중단할 것인지(NO-GO)’를 결정하는 작업이 이 단계의 마지막에서 이루어짐

– 위험이 너무 높으면 프로젝트가 중단될 수도 있음

– 계속 진행하기로 결정되면 다음 개발 과정으로 넘어감

37



③ 개발 단계

– 위험에 대한 평가가 있은 다음 이루어짐

– 이 단계에서는‘어떠한 모델이 적용되어 시스템 개발이 이루어질 것인가’ 하는 개발 모델을 결정

• 사용자 인터페이스에 대한 위험이 주로 고려 : 프로토타이핑 모델 적용

• 위험이 시스템 통합에 있다고 판단 : 폭포수 모델 적용

– 이 단계는 시제품을 개발하거나 최종 제품을 만드는 과정이라고 볼 수 있음

④ 고객 평가 단계

– 앞의 개발 과정에서 나온 결과(예 : 초기 소프트웨어 시제품)를 사용자가 평가하는 과정

– 고객에 의해 시스템에 대한 평가가 이루어지게 되고, 고객은 시스템의 수정을 요구하기도 함

– 고객의 평가에 의하여 다음 결과물 계획

38



• 장점

– 비용이 많이 들고 시간이 오래 걸리는 큰 시스템을 구축해 나가는 데 가장 현실적인 접근 방법

• 예) 초고속 정보통신망 개발, 대형사업 등

– 성과를 보면서 조금씩 투자하여 위험 부담을 줄일 수 있는 이상적 방법

• 한계점

– 폭포수 모델과 프로토타이핑 모델 보다 더 복잡하여 프로젝트 관리 자체를 어렵게 만들 가능성이 많음

– 많은 고객을 상대로 하는 상업용 제품의 경우에는 적용하기 힘듦

39


40

• 컴퓨터 소프트웨어의 수학 명세서를 유도하는 활동들의 집합을 포함

• 소프트웨어 공학자가 엄격한 수학적 표기법을 적용해서 컴퓨터 기반

시스템을 명시, 개발, 그리고 확인

• 변형된 방법으로 클린룸 소프트웨어 공학(cleanroom software

engineering)이라고 부르는 몇 개의 소프트웨어 개발 조직이 현재 적용

• 비즈니스 환경에서 애플리케이션 능력에 관한 관심을 표현

– 정형 모형들의 개발은 현재 아주 많은 시간을 소비하고 비용이 많이 듬

– 소프트웨어 개발자들은 정형 방법을 적용하는 데 필요한 지식을 거의 가지고

있지 않으므로 광범위한 교육이 요구

– 기술적으로 미숙한 고객을 위한 의견 교환 메카니즘으로 이 모형을

사용하기가 어려움

정형 방법 모델

2.4.4 클린 룸 모델


41

• 기본적인 생각

– IBM의 Mills [MIL87][DYE92]에 의해 고안된 개발모델

– ‘시스템의 가장 핵심이 되는 부분’을 최초의 인크리먼트(increment, 실행

가능한 프로토타입)로 개발하여 사용자에게 피드백 하여 새로운 요구를

끄집어내거나 개발 계획 자체를 다시 고쳐서 반복해서 증가분 소프트웨어를

개발시스템에 추가하여 가는 생각을 기초로 하고 있음

클린 룸 모델

2.4.4 클린 룸 모델


2.4.4 클린 룸 모델

• 클린 룸 모델에 의한 점진적 개발의 생각

42

핵심부

increment 0

증가분 소프트웨어의 부분 1

increment 1

increment 2

증가분 소프트웨어의 부분 2

다음 increment로

+

+

increment 부분의 개발순서(개발

우선도)는 시스템내에서의 중요성, 이용빈도, 사용자에의 feedback에 의한 평가등으로 결정된다.


2.4.4 클린 룸 모델

• 클린 룸 모델에 의한 개발 프로세스

43

요구분석

기능사양 기술이용 시나리오 기술

Incremental 개발계획 입안

인크리먼트 0

설계 및 검증테스트케이스 생성

설계 및 검증설계 및 검증

설계 및 검증통계적 테스트

원시코드

계획의 수정

테스트 케이스

인크리먼트 1




원시코드

테스트 케이스

인크리먼트 2




원시코드

테스트 케이스

+ 증가부분 1

+ 증가부분 2

+ 증가부분 3

다음 인크리먼트로

인크리먼트는 계획적으로 실시

인크리먼트내로의 피드백

인크리먼트내로의 피드백

인크리먼트내의 피드백

전체계획으로피드백

공정의 흐름

시스템내의 중요성,

이용빈도 등 고려

입력과 출력으로

변환되는 과정에 관심


2.4.4 클린 룸 모델

• 클린 룸 모델에 의한 개발 프로세스(그림 설명)

– 우선 개발하는 시스템에 대한 요구 분석을 하고, 기능적인 명세(사양)와

이용 시나리오를 기술 <-- 종래의 모델과 변함이 없음

– 미리 개발 시스템의 어느 부분부터 가동시키고, 순차적으로 기능을

추가하여 갈 것인가의 점진적(incremental) 계획서를 작성 <-- 종래

모델과 다른점

– 개발은 점진적 계획서에 따라서 증가분한 인크리먼트마다 추가 기능의

설계와 검증, 테스트케이스의 작성을 수행하면서 계획적으로 진행

– 이와 같은 방법으로 하면,

• 각각의 인크리먼트의 테스트가 완료된 시점에 사용자의 확인을 받기

때문에 폭포수모델의 결점이었던 ‘테스트 또는 출하단계에서 처음으로

사용자 확인을 받는다’ 또는 ‘테스트 단계에서 생긴 결함의

수정비용이 증가된다’와 같은 모순은 없어지게 됨

• 각 인크리먼트마다 검증, 테스트를 수행함에 의하여 결함이 개재될

여지가 없어지게 됨

44


2.4.4 클린 룸 모델

• 인크리먼트 명세의 상세화와 검증 방법

① 박스구조분석에 의한 단계적 상세화

• 박스구조분석은 명세를 입력과 출력과의 관계로 관련 지어 수행하는

블랙박스로서 취급하여서 서서히 입력으로부터 출력으로 변환되는

과정에 관심을 두고 상세화하여 나가는 분석방법

② 함수등가성에 기초한 검증

• 함수등가성이란?

– 명세를 입력과 출력과의 대응관계를 정의하는 함수로서 다루어, 명세를

자세하게 한 것이 입출력관계와 기능에 있어서 원래의 명세와 등가(等價)임을

판정하는 기준

• 함수등가성의 대상이 되는 것

– 구조화 프로그래밍(structured programming)에 있어서의 4가지 제어구조, 즉

순차, 분기, 선택, 반복의 제어구조

45


• 나선형모델의 많은 특징들을 결합

• 소프트웨어를 개발하는데 요구되는 반복적 접근방법을 가진

진화적 특성도 가짐

• 컴포넌트 기반 개발은 이미 만들어져 패키지화된

컴포넌트(클래스)를 사용하여 어플리케이션을 구성

• CBD 모델은 소프트웨어의 재사용성을 이끌고 이러한 재사용성은

많은 소프트웨어 공학에 많은 이점을 줌

• QSM(Quality Software Management) 연관의 재사용성에 관한

논문에서,

– 컴포넌트의 사용은 개발 사이클의 70%, 개발비용의 80%의 단축을

가져오며 업계의 표준인 16.9% 보다 큰 26.2% 생산성 지표의 향상을

가져온다고 언급

46

컴포넌트 기반 모델 (CBD : Component-Based Development

2.4.5 컴포넌트 기반 모델


47

2.4.5 컴포넌트 기반 모델


소프트웨어 제작 방법의 공통점

• 소프트웨어 제작 방법의 공통점 3가지

– 소프트웨어의 정의(definition) 단계

– 소프트웨어의 개발(development) 단계

– 소프트웨어의 유지보수(maintenance) 단계


소프트웨어 제작 방법의 공통점

• 소프트웨어 정의 단계

– 요구사항 분석 과정에 해당

– 사용자의 관점에서 시스템이 제공해야 하는 기능, 데이터, 인터페이스 정의

– 사용자에게 무엇(what)을 제공할 것인가에 초점을 맞춤

• 소프트웨어 개발 단계

– 시스템이 제공해야 하는 무엇(what)을 어떻게(how to) 만족시킬 수 있을 것인가

규명

– 소프트웨어 개발 과정은 설계, 구현, 테스팅의 과정

– 개발자는 요구사항을 만족시키기 위해 소프트웨어를 어떻게 설계할지, 어떤

프로그래밍 언어를 사용하는 것이 좋을지, 테스팅은 어떻게 할지 등에 관심을

가짐

• 소프트웨어 유지보수 단계

– 시스템이 개발된 후 오류의 수정, 환경 변화, 기능 향상 요구 등과 연관되어

발생하는 변화(change)에 초점을 맞춤

– 시스템 변경의 경우에 따라 재 요구사항 분석, 재 설계, 재 프로그래밍, 재

테스팅의 과정이 필요하게 되고 이에 따라 관련된 문서의 갱신을 수반함


50

2.5 소프트웨어 공학에서의 인간요소(1)

• (소프트웨어 공학에서) 인간요소 연구의 중요성

① 대형 프로젝트가 주어진 예산 및 시간 내에 완료되기 위해서

효과적인 소프트웨어 관리가 중요

• 소프트웨어 관리자는 개발자를 이해함으로써 실현 불가능한 목표를

설정하지 않도록 하는데 도움

② 컴퓨터 시스템은 사람들에 의해 사용됨

• 시스템 설계 시, 사용할 사용자의 능력과 수준을 고려

③ 프로그래머의 생산성은 소프트웨어 공학에서 중요한 비용요소

• 인간요소를 잘 이해함으로써 적은 비용으로 생산성을 증가시킬 수 있는

방법을 찾을 수 있음


51


• 그룹 업무

– 겉으로 보기에는 개별적으로 행동하는 것 같지만, 소프트웨어

공학은 팀 활동임

– 프로그래머들은 다른 사람들과 함께 일할 필요성을 못 느낌

– 소프트웨어 엔지니어의 시간 분포

• 팀 멤버간의 상호작용(50%) : 그룹의 전반적인 성능에 중요한 역할


52


• 그룹에서의 개성

① 일 중심(Task-oriented) 형태

② 자기 중심(Self-oriented) 형태

③ 상호작용 중심(Interaction-oriented) 형태

– 단순히 프로그래밍 능력만을 기초로 그룹을 형성하는 것보다

개성이라는 측면에서 서로 보완해 주는 사람들로 그룹을 형성하는

것이 더 좋은 그룹

– 그것이 불가능하다면, 엄격한 관리적 통제를 통해 개인의 목적이

그룹의 전체적인 목적을 초월하지 않도록 해야 함


53

• 그룹 내에서 커뮤니케이션(communication)에 영향을 주는 요소

– 그룹의 크기

– 그룹 멤버의 직위, 개성, 성별

• 지위가 높고 낮은 그룹 멤버 사이의 커뮤니케이션은 지위가 높은 사람에

의해 좌우되는 경향이 있음

• 혼성 그룹을 더 선호

– 그룹 멤버 사이의 개인적인 갈등

– 그룹의 물리적 작업 환경



54


• 그룹 커뮤니케이션 형태

– 별 형태

• 모든 커뮤니케이션이 중앙 조정자를 통해 이루어 질 수 있도록 구성

• C가 팀 지도자인 프로젝트에서, A가 B에게 업무 설명을 하려면

– A는 문서를 작성해서 C에게 전달, C는 B에게 전달

– 네트워크 형태

• 그룹 멤버에 의해 만들어진 문서가 모든 다른 그룹 멤버에게 전달됨

• 그룹 멤버에게 불필요한 문서를 읽는 부담 --> 그룹의 크기가 작아야 함


55

그룹을 위한 사무실과 회의

장소


• 인간공학

– Item의 설계방법, 작업 방법, 작업 환경의 설정 등을 인간의

능력이나 한계에 맞도록 정하는 기술

• item : 신뢰성의 대상이 되는 시스템, 서브시스템, 기계, 장치, 구성품,

부품, 소자 등의 총칭 또는 그 하나를 지칭

– 가장 중요한 환경적인 요소 (IBM McCue(1978) 연구)

• 프라이버시

• 밖을 볼 수 있는 환경

• 개별화

– 개인 프라이버시 요구와

그룹의 커뮤니케이션 요구는

상호 배타적


56


– 개발 업무보조를 위해 네트워크화된 개인용 컴퓨터를 제공

• 개인 업무가 다른 사람들의 업무에 의해 방해를 받지 않음

• 효과적인 네트워크 유틸리티는 정규적, 비정규적 그룹 통신을

향상시키기 위해 제공

– 전자게시판, 컴퓨터 회의 시스템, 전자우편 시스템을 포함

chap. 2 소프트웨어 공학 -...

Documents