1.. 프로로덕덕트트((Prroodduucctt)) Pmaeum.ipdisk.co.kr/publist/VOL1/maeumnet/data/Adobe... · 제11 장장..프프로로덕트트-- 11 -- 작성자: 이 진영 E-Mail : [email protected]

제제 11 장장 .. 프프로로덕덕트트 -- 11 --

작성자 : 이 진영 E-Mail : [email protected]

11.. 프프로로덕덕트트 ((PPrroodduucctt))

1.1 소프트웨어의 발전

소소프프트트웨웨어어의의 역역할할

역할 내용

제품의 역할 컴퓨터 하드웨어가 가지고 있는 잠재적인 능력을 최대한 발휘할 수 있도록 해주는 역할

제품을 전달해주는 매체의 역할

소프트웨어는 정보 변형자(information transformer)이다 . 즉 , 매체가 제품을 전달하는데 사용될 때 , 멀티미디어 시뮬레이션처럼 복잡해질 수 있고 또는 단일 비트처럼 단순해질 수 있는 정보를 생성하고 , 관리하고 , 수정하고 , 또 전송할 수 있는 정보 변형자

소소프프트트웨웨어어의의 발발전전 과과정정

P. 6 참조

세대 초창기 2세대 3세대 4세대 시기 50’ ~ 60’ 중반 60’ 중반 ~ 70’ 후반 70’ 중반 ~ 80’ 중반 80’ 중반 ~

처리 기법 Batch Process Real-time System Distributed System

시스템 Multiprogramming Multi-user Interactive System

Multiple Computer 분산 클라이언트/서버 환경

응용 분야 DBMS Network 출현 객체지향 기술 출현

특징 한정된 곳에만 분포 주문 소프트웨어

Software House 출현 소프트웨어 위기 조짐

마이크로프로세스 출현 강력한 데스크탑과 워크스테이션 출현 폭넓은 사용

전문가 시스템 인공 신경망 소프트웨어 가상 현실 프로그래밍 병렬 컴퓨터

1.1.1 산업 전망

? 초기: 하드웨어 중심 , 하드웨어 공학 중심

오늘날 : 소프트웨어 중심

⇒ 소프트웨어 개발 비용이 하드웨어 개발 비용을 앞서기 때문

1.1.2 오래된 소프트웨어 플랜트

? 오래된 소프트웨어는 유지보수할 수 없다 .

? 적은 수정조차도 전체 시스템을 쓸모없게 만들 수 있기 때문

? 복잡한 소프트웨어(공학용 어플리케이션 )은 오래되면 상태가 나빠진다 .

? 시간이 지나면 프로그램의 내부구조에 관한 세부 지식을 얻기 어려워짐

? 내장 시스템 (embedded system)은 변경이 어렵다 .



1.1.3 소프트웨어 경쟁력

? 비용 , 스케쥴, 그리고 품질은 앞으로 수십 년간 소프트웨어 연구에 치열한 경쟁을 이끄는 중 요한 원

동력이다 .

1.2 소프트웨어

소소프프트트웨웨어어의의 정정의의

? 실행할 때 원하는 기능과 성능을 제공해 주는 명령어들(컴퓨터 프로그램)

? 프로그램이 정보를 적합하게 조작하도록 해주는 자료구조.

? 프로그램의 운영과 사용을 설명해 주는 문서 .

1.2.1 소프트웨어의 특성

? 소프트웨어는 다음과 같은 특성을 가진다 .

- 소프트웨어는 제조되는 것이 아니라 개발되거나 공학화되는 것이다.

- 소프트웨어는 “닳아 없어지는 것”이 아니라 질이 나빠지는 것이다 .

- 소프트웨어는 기존의 구성 요소를 조립하기 보다는 주문하여 만드는 것이다 .

- 소프트웨어는 물리적인 시스템 요소라기 보다는 논리적 요소이다 .

- 소프트웨어 유지 보수는 Hardware 유지 보수보다 상당히 복잡하다.

? P.13의 참조

? P.14의 , 참조

1.2.2 소프트웨어 컴포넌트

? 고품질 소프트웨어 컴포넌트의 특징 - 재사용성(reusability)

시기 재사용 범위 예 단점

60 년대 잘 정의된 알고리즘의 재사용

과학용 서브루틴 라이브러리(scientific subroutine library)

한정된 어플리케이션 영역에서만 사용 가능

오늘날 알고리즘뿐만 아니라 데이터 구조에까지 확장

풀-다운 메뉴등

1.2.3 소프트웨어 어플리케이션

소소프프트트웨웨어어의의 성성격격을을 결결정정하하는는 중중요요한한 인인자자

인자 의미 예

내용(content) 오고 가는 정보의 의미와 형태 Data 또는 Information 의 형태

비지니스 프로그램과 자동화 기계를 제어하는 소프트웨어

정보 결정도 (information determinacy)

정보의 순서와 시간에 대한 예측 능력 Data 또는 Information 을 처리(process)하는 방법(환경과 시간의 개념을 포함)

공학 분석 프로그램과 멀티유저 운영체제



소소프프트트웨웨어어의의 사사용용 분분야야에에 따따른른 분분류류

소프트웨어 내용 기타/예

시스템 소프트웨어 (System Software)

다른 프로그램들의 동작을 도와주기 위해 작성된 프로그램들의 집합으로 운영체제를 의미한다 .

실시간 소프트웨어 (Real-Time Software)

실시간에 발생되는 사건(events)들을 측정하고 분석 제어하는 소프트웨어

실시간 소프트웨어의 구성요소 ? 외부 환경에서 자료를 수집하는

요소 (데이터 수집 컴포넌트) ? 필요에 따라 정보를 변형하는 분

석 요소 (분석 컴포넌트) ? 외부 환경에 응답하는 출력 제어

요소 (출력 컴포넌트) ? 실시간 응답이 유지되도록 모든

요소를 조정하는 제어 요소 (제어 컴포넌트) ? 모니터링(monitoring) 구성 요소 (모니터링 컴포넌트)

업무용 소프트웨어 (Business Software)

기업 정보 처리를 위한 소프트웨어로 급여 관리, 사원 관리들과 같은 기업 전반에 필요한 처리를 위해 대용량의 데이터베이스가 요구되는 소프트웨어

경영 정보 시스템 (MIS: Management Information System) 대화형 또는 클라이언트/서버 컴퓨팅을 포함

공학과 과학 소프트웨어 (Engineering & Scientific

Software)

공학이나 과학 분야에서 사용되는 소프트웨어로 천문학에서 부터 원자 물리학, 우주선 궤도 , 분자 생물학등에서 사용되는 소프트웨어를 의미하며 수치 알고리즘의 범위를 벗어난 컴퓨터 보조 설계(CAD), 시스템 시뮬레이션 등 그 범위가 점차 넓어지고 있다.

컴퓨터 보조 설계(CAD) 시스템 시뮬레이션

내장 소프트웨어 (Embedded Software)

ROM(Read Only Memory)에 기억시킨 소프트웨어로 일반적으로 소비자와 산업 시장의 제품이나 시스템을 제어하는 한정된 분야에서 사용되는 소프트웨어로 특정한 기능과 제어 능력(자동차의 연료 제어, 계기판, 브레이크 시스템등의 디지털 기능들과 같은)등을 제공한다.

마이크로웨이브 오븐의 키판 제어 자동차의 연료 제어 , 계기판, 브레이크 시스템

개인용 소프트웨어 (PC Software)

소프트웨어 중 가장 폭넓은 범위를 가진 소프트웨어로 개인용 컴퓨터 시장에서 운용되는 소프트웨어 소프트웨어 중 가장 혁신적인 휴먼-인터페이스 설계를 도입하려고 노력하고 있다 .

문서 작성기, 스프레드 쉬트, 데이터베이스 관리등과 수많은 응용 분야에서 사용

인공지능 소프트웨어 (AI Software)

계산이나 즉각적인 분석이 쉽지않은 복잡한 문제를 풀기위해 비수치적인 알고리즘 사용하는 소프트웨어

전문가 시스템(expert system)의 지식 기반 시스템(knowledge0based system) 패턴 인식, 이론 증명, 게임등 응용 분야가 넓어짐



1.3 소프트웨어 : 위기의 조짐

소소프프트트웨웨어어 개개발발의의 기기본본적적인인 문문제제점점

① 일정과 가격 예측은 거의 부정확하다 .

② 소프트웨어 개발자들의 생산성은 그들의 서비스에 대한 요구를 충족시키지 못한다 .

③ 소프트웨어의 품질이 어떤 경우에는 적정선 이하가 된다 .

< 원 인 > ① 우리의 경험은 겨우 40 년 밖에 되지 않는다 .

② 소프트웨어는 물리적이기 보다는 논리적인 요소이다.

③ 소프트웨어 유지 보수 중에 “결함이 있는 부분”은 대치되지만 , 예비 부품들이 별로 많지 않다 .

④ 개발자간의 의견 교환의 부족

⑤ 하드웨어의 빠른 변화에 비해 소프트웨어 개발의 신기술의 부족

⑥ 소프트웨어 개발의 신기술에 대한 정식 기술 훈련을 받지 않으며 , 과거 경험에 의한 소프트웨어 개발

소소프프트트웨웨어어 위위기기 ((SS oofftt wwaarree CCrriiss ii ss ))

? 1970’s Boehm에 의해 제안 - “하드웨어 /소프트웨어 가격 추세도표”

? 컴퓨터 하드웨어 기술은 현저한 속도로 발전되어 하드웨어 비용은 감소 추세인 반면 , 소프트웨어

수용 증가율은 연간 12%에 이르고 있으나, 4%에 머무르고 있는 프로그래머의 증가율을 3 배나 앞지

르고 있다 .

⇒ 프로그래머의 작업량이 상대적으로 증가하는데 반해 소프트웨어 개발 방법은 기존의 방법에 의존하

기 때문에 시스템 개발에 엄청난 인력과 비용이 요구된다는 것이다 .

소프트웨어 비용 곡선 상승하는 소프트웨어 비용

소프트웨어 위기에 대한 인식은 새로운 소프트웨어를 개발할 때 다음과 같은 문제점들을 인식하게 한다 .

? 현존하는 소프트웨어의 유지 보수에 따른 부피 성장과 복잡도 증가를 어떻게 효율적을 유지할 것인

가?

? 오류를 감소시키기 위해 소프트웨어를 어떻게 개발할 것인가?

? 증가하는 소프트웨어 수요를 어떻게 충족시킬 것인가?

100

80

60

40

20

0 1955 1980 1995

총비용 %

하드웨어 비용 소프트웨어 개발 비용

소프트웨어 유지보수 비용

350

300

150

100

50

1976 1984 1992

하드웨어 비용

200

250

1980 1988

억달러

소프트웨어 비용



? 기존 소프트웨어를 어떻게 적응시키고 수정하며 고도화할 것인가?

? 소프트웨어의 문제로 인한 사회적 문제를 어떻게 대처할 것인가?

1.4 소프트웨어 신화

관관리리자자 신신화화

신화 : 소프트웨어 구축에 관한 표준들과 절차들을 서술한 책은 많다 .

현실 : 표준들에 관한 책들은 존재하지만 실무에 반영되지 않으며 완전하지 않다 . 소프트웨어 공학에 대

한 능력은 정규 교육과 실무 경험을 통하여 가장 확실하게 획득할 수 있다 .

신화 : 최고의 소프트웨어 개발 도구 (tool)들을 가지고 있고 최고의 컴퓨터를 가지고 있다 .

현실 : 대다수의 소프트웨어 개발자들은 개발 도구를 사용하지 않는다 .

신화 : 일정에 뒤지면 더 많은 프로그래머를 투입하면 된다 .

현실 : 소프트웨어 개발은 제품 조립처럼 조립되는 것이 아니다 . Brooks 의 법칙에 의하면 늦어진 소프트

웨어 개발 프로젝트에 인력을 충원하면 보다 더 늦어진다 . 새로운 인원의 투입에는 그들의 교육

에 필요한 시간이 투여된다.

고고객객 신신화화

신화 : 목적을 기술해 놓은 일반적인 문장만 있으면 프로그램을 작성할 수 있다 .

현실 : 애매한 정의는 소프트웨어 개발 실패의 요인이다.

신화 : 프로젝트 요구 사항이 계속 변경되지만 소프트웨어가 매우 신축성이 있으므로 변경은 쉽게 수용

될 수 있다 .

현실 : 변경은 더 많은 자원과 더 많은 투자를 요구하는 대변동을 일으킬 수 있다 .

실실무무자자 신신화화

신화 : 우리는 프로그램을 작성하고, 이 프로그램을 작동하게 되면 , 거기서 우리의 일이 끝나는 것이다.

현실 : 소프트웨어는 유지되어야 하며 이러한 유지 보수에 50~70 %의 예산이 필요하다 .

신화 : 프로그램을 “Running” 시키기 전까지는 그 품질을 알아낼 방법이 없다 .

현실 : 품질 보증 기법 중 프로젝트 초기에 적용 가능한 정형 기술 검토(formal technical review) 기법이 있

다 .

신화 : 성공적인 프로젝트에서 나오는 것은 단지 수행 가능한 프로그램 뿐이다.

현실 : 프로그램은 프로젝트의 한가지 부분일 뿐이다 . 문서화는 성공적인 개발을 위한 기본적인 사항이

며 유지 보수를 위한 유지 보수 태스크 지침의 제공은 매우 중요하다.

제제 22 장장 .. 프프로로세세스스 -- 66 --


22.. 프프로로세세스스 ((PPrroocceessss))

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

? 1968 년 서독에서 개최된 NOTO 주최의 회의에서 처음 사용

? 1975 년 후반에 들어 소프트웨어 공학이라는 용어가 정착

? 정의

? 소프트웨어 공학은 소프트웨어 위기를 극복하기 위해 소프트웨어 요구 정의에서부터 유지 보

수에 이르기까지 소프트웨어 수명 주기(Life Cycle) 전단계에 걸친 연구가 요구되어 개발된 일

련의 소프트웨어 개발 방법론

? 주어진 기간 내에 project를 효율적으로 관리하는 기법

? project 에 투여 되는 비용을 예측하는 일과 사람들을 관리하는 일

? 사용자의 요구 사항 등을 정확히 분석하여 그 요구 사항대로 소프트웨어를 개발하는 일

? 각 과정의 일들을 체계적으로 문서화하는 등의 일련의 공학적이며 체계적인 방법으로 소프트

웨어를 개발하고 관리하는 기법

? Fritz Bauer의 정의

- 신뢰성 있고 효과적으로 작동하는 경제적인 소프트웨어를 얻기 위해서 올바른 공학적 원칙

들을 체계화시키고 사용하는 것

? Boehm의 정의

- 과학적인 지식을 컴퓨터 프로그램 설계와 제작에 실제 응용하는 것이며 이를 개발하고 운영

하고 유지 보수하는데 필요한 문서화 작성 과정

? IEEE(Institute of Electrical & Electronics Engineers)의 정의

- 소프트웨어 개발 , 운영 , 유지 보수하는데 관련된 기술적이면서 관리적인 종합적 원리

2.1.1 프로세스, 방법, 도구

? 소프트웨어 공학은 계층화된 기술(layered technology) 이다 .

? P.29 의 참조

? 소프트웨어 공학의 기반은 프로세스 계층(process layer)이다 .

소소프프트트웨웨어어 공공학학의의 구구성성 요요소소

? 소프트웨어 공학은 하드웨어와 시스템 공학의 부산물이다.

? 도구(tools) : 프로세스와 방법을 자동화나 반자동화시켜 지원하는 기능 제공 . 예> CASE

? 방법(methods) : 소프트웨어를 구축하기 위한 전반적인 기술 즉 , 요구 사항 분석 , 설계 , 프로그램

구축 , 테스팅 그리고 유지 보수 태스크들로 구성

? 절차(procedures) : 방법과 도구를 결합하여 소프트웨어를 합리적으로 개발할 수 있도록 도와주

는 일련의 순서들의 모임으로 각 방법론들은 절차들을 가지고 있다 . = process



소소프프트트웨웨어어 공공학학의의 목목표표

소프트웨어의 공학의 목표은 다음과 같다 .

① 소프트웨어 공학자의 생산성을 증대시키기 위한 도구와 방법론 제공

② 경제적인 개발에 의한 개발 비용 감소

③ 신뢰성을 갖춘 소프트웨어의 개발

④ 소프트웨어 품질 향상

⑤ 개발자의 직무 만족도를 고려하여 효율적인 소프트웨어 개발

소소프프트트웨웨어어 공공학학의의 효효과과

① 단순한 프로그래밍에서 탈피

② 오류의 사후 처리에서 사전 예방으로의 전환

③ 소프트웨어의 재활용도 제공

④ 수작업에서 자동화 작업으로의 전환

소소프프트트웨웨어어 공공학학의의 기기본본 원원칙칙

? 구조화 기법의 기본 원칙

- 추상화(Abstraction)

- 형식화(Formality)

- 분할과 통치(Divide & Conquer)

- 계층적인 순서(Hierarchical Ordering)

? 정보 은닉(Information Hiding)

? 지역성 (Localization)

? 무결성 (Conceptual Integrity)

? 완벽성 (Completeness)

? 논리적인 독립성(Local Independence)

잘잘 작작성성된된 소소프프트트웨웨어어

① 사용자가 원하는대로 동작해야 한다 .

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

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

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

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

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

수정 용의성 (modifiability)

신뢰성 (reliability)

효율성 (efficiency)

이해성 (understandability)

생산성 (productivity)

이식성 (portability)



2.1.2 소프트웨어 공학에 관한 일반적 견해

소소프프트트웨웨어어 공공학학과과 연연관관된된 과과정정

(1) 정의 과정(definition phase)

무엇(what)에 초점

3 가지 주요 태스크 - 시스템 또는 정보 공학(10 장)

소프트웨어 프로젝트 계획수립(3 장에서 7 장까지)

요구사항 분석(11, 12, 그리고 20 장).

(2) 개발 과정(development phase)

어떻게(How)에 초점

3 가지 주요 태스크 – 소프트웨어 설계(14, 15, 그리고 21 장)

코드 생성 소프트웨어

테스팅 (16, 17, 그리고 22 장)

(3) 유지보수 과정(maintenance phase)

오류 수정 , 소프트웨어 환경의 전개에 따라 요구되는 적응 , 그리고 고객이 요구사항 변경시켜 발생한

기능 향상 때문에 일어나 변경(Change)에 초점

유지보수 과정에는 4 가지 유형의 변경

? 수정적 유지보수(corrective maintenance) 결함수정

? 적응적 유지보수(adaptive maintenance) 시스템환경 변화에 따른 변경으로 인한 수정

? 완전한 유지보수(perfective maintenance) 기능 향상

? 예방적 유지보수(preventive maintenance) 변경에 대해 잘 대체할 수 있도록 수정

보보호호활활동동 ((uummbbrreell llaa aacc ttii vvii ttiieess )) :: 소프트웨어 개발의 각 단계에서 보완적인 활동들

? 소프트웨어 프로젝트 추적과 관리(software project tracking and control)

? 정형 기술 검토(formal technical reviews)

? 소프트웨어 품질 보증(software quality assurance)

? 소프트웨어 형상 관리(software configuration management)

? 문서 준비와 생산(document preparation and production)

? 재사용성 관리( reusability management)

? 측정(measurement)

? 위험 관리(risk management)



2.2 소프트웨어 프로세스

소소프프트트웨웨어어 프프로로세세스스의의 특특성성화화 -- 참참조조

? 공통 프로세스 프레임워크(common process framework) : 소프트웨어 프로젝트의 크기나 복잡도

와 관계없이 모든 소프트웨어 프로젝트에 적용할 프레임워크 활동(framework activities)들을 집

합

? 프레임워크 활동(framework activities) : 관리 기법에서의 segment

? 태스크 집합(task sets) :

능능력력 성성숙숙 모모형형 ((ccaappaabbii ll ii tt yy mmaatt uurrii ttyy mmooddeell ))

? 소프트웨어 공학 연구소 (SEI: Software Engineering Institute)에서 개발

? 조직들이 프로세스 성숙의 다른 수준에 도달하는 것을 제시해 주는 소프트웨어 공학 능력의 집

합을 예측하는 포괄적인 모형에서 사용

? 5 가지 프로세스 성숙 수준으로 분류

2.3 소프트웨어 프로세스 모형

프프로로세세스스 모모형형 ((PPrroocceess ss mmooddeell )) == 소소프프트트웨웨어어 공공학학 페페러러다다임임 ((ssooffttwwaarree eennggiinneeeerriinngg ppaarraaddiiggmm))

? 산업체의 실제 문제를 해결하기 위해 프로세스 , 방법 , 그리고 도구 계층(tools layers)과 일반 과정

(generic phases)들을 포함하는 개발 전략을 통합한 모형

? 프로젝트와 어플리케이션의 특성 , 사용되는 방법과 도구들 , 그리고 요구되는 제어와 산출물에

근거해서 선택된다 .

? 소프트웨어 개발의 4 가지 단계 p. 35 의 참조

① 현상(status quo) : 사건들의 현재 상태를 나타낸다 .

② 문제 정의(problem definition) : 해결하려는 특정한 문제를 식별한다.

③ 기술 개발(technical development) : 어떤 기술을 적용해서 문제를 해결한다 .

④ 해결 방안 통합(solution integration) : 처음 해결 방안을 요청한 사람에게 결과(예 , 문서들 , 프로그램

들 , 데이터 , 새로운 비지니스 기능 , 새로운 프로덕트)들을 인도한다.

? 문제 해결 루프는 거시적 수준에서 LOC 수준까지 반복적으로 사용된다.

⇒ 실제로 그림 2.3b 가 암시하는 만큼 적절하게 활동들을 구분하기는 어렵다 .

2.4 선형 순차 모형(Sequential Model) P. 37의 참조

? 고전적 생명주기(classic life cycle) 또는 폭포수 모형(waterfall model)이라고도 함

? 소프트웨어 개발을 시스템 수준에서 시작하여 분석 , 설계 , 코딩 , 테스팅 , 그리고 유지보수의 전

과정을 수행하는 체계적이고 순차적인 접근법을 제시한다.

? 소프트웨어 공학에서 가장 오래 되고 가장 폭넓게 사용되는 패러다임

? 선형 순차 모형에 포함된 활동들

제제 22 장장 .. 프프로로세세스스 -- 1100 --


활동 내용

시스템 /정보 공학과 모델링

시스템 요소에 대한 요구사항들 분석 최상의 수준 분석과 설계의 적은 양만 갖는 요구사항 수집 전략적 비지니스 수준과 비지니스 영역 수준에서 요구사항 수집

소프트웨어 요구사항 분석

소프트웨어에 집중된 요구사항 수집 구축될 프로그램의 특성을 이해하기 위해 소프트웨어 엔지니어는 요구되는 기능 , 성능 , 그리고 인터페이스처럼 소프트웨어에 관한 정보 영역을 이해 시스템과 소프트웨어에 대한 요구사항들은 의뢰인과 함께 문서로 만들고 검토된다 .

설계

프로그램의 4 가지 속성(데이터 구조 , 소프트웨어 아키텍쳐, 인터페이스 표현 , 절차(알고리즘))의 세부사항들에 초점을 맞추는 다단계 과정(multistep process) 설계 과정은 코드 생성이 되기 전에 요구사항을 평가할 수 있는 소프트웨어의 표현으로 변환시킨 것이다 . 요구사항처럼 설계도 문서화되어 소프트웨어 형상의 부분이 된다 .

코드 생성 설계에 따른 결과를 기계가 읽을 수 있는 형식으로 변환하는 과정

테스팅 테스팅 과정은 블랙 박스(Black Box)와 화이트 박스(White Box) 테스트로 구성되며 작성된 프로그램 검증한다 .

유지 보수 소프트웨어 변경에 따른 오류를 수정한다 . 소프트웨어 유지보수는 새로운 프로그램보다는 기존의 프로그램에 각 진행 과정을 재적용한다.

? 선형 순차 모형의 문제점

① 실제 프로젝트들은 거의 이 모형이 제시하고 있는 순차 흐름을 따르지 않는다 .

② 고객이 원하는 모든 요구사항을 명확하게 기술하는 것이 대체로 어렵다.

③ 프로그램의 작동 버전(version)은 프로젝트 일정의 후반부가 되어야 사용할 수 있으므로 작동

프로그램을 검토할 때까지 발견되지 않은 큰 실수는 커다란 재앙이 될 수 있다 .

④ 개발자들은 불필요하게 자주 지연시킨다.

⑤ 초기 단계를 지나치게 강조하므로 불필요한 문서들을 작성하는데 많은 시간을 소비한다 .

⑥ 실제 각 단계에서 시스템을 보는 관점이 다르며 , 이를 전환하는데는 많은 노력이 필요하다 .

2.5 프로토타이핑 모형(Prototyping Model) P. 33의

요구 분석

프로토타입

개발/개선

프로토타입

평가

구현

인수/설치

제제 22 장장 .. 프프로로세세스스 -- 1111 --


? 사용자가 완성된 시스템의 모습을 사전에 볼 수 있다 . ? 요구 수정이 초기에 결정

? 사용자와 개발자에게 공동의 참조 모델을 제공한다.

? 원형을 보고 사용자는 소프트웨어 개발이 빨리 끝날 것으로 믿는다 .

? 사용자의 과대한 기대를 유발하여 보다 많은 기능을 기대

? 제품 수정시 의뢰인은 약간의 수정을 통해 프로토타이핑이 작동 제품으로 만들어지기를 요구한다 .

이것은 소프트웨어 개발 관리가 느슨해진다 .

? 개발자는 프로토타입을 빨리 작동시키기 위해 가끔 구현을 위태롭게 만든다 .

? 원형 과정을 관리 , 통제하기 어렵다 . ? 중간 과정을 점검할 수 있는 일정표와 산출물이 없다 .

? 사용자의 참여 시기를 결정하기 어렵다.

? 실험적으로 실현 가능성을 타진하는 방법

2.6 RAD(Rapid Application Development) 모형

? 매우 짧은 개발 주기를 강조하는 선형 순차 소프트웨어 개발 프로세스이다 .

? 컴포넌트를 기저로 하는 구축 접근법을 사용해서 빠른 개발(rapid development)을 하는 선형 순차

모형의 “고속” 적응 모형이다.

? RAD는 재사용이 가능한 프로그램 컴포넌트의 개발을 강조한다 .

? RAD 접근법은 다음과 같은 과정을 포함

과정 내용

비지니스 모델링 (Business modeling)

비지니스 기능들 간의 정보 흐름은 다음의 질문에 대답하는 방법으로 모형화시킨다 : ? 무슨 정보가 비지니스 프로세스를 유도하는가? ? 무슨 정보가 생성되는가? ? 누가 그것을 생성하는가? ? 정보가 어디로 진행되는가? ? 누가 그것을 처리하는가?

데이터 모델링 (Data modeling)

비지니스 모델링 과정의 일부로 정의된 정보 흐름은 비지니스를 지원하는데 필요한 데이터 객체의 집합으로 정제된다 . 각 객체의 특성들이 식별되고 이러한 객체들 간의 관계가 정의된다 .

프로세스 모델링 (Process modeling)

데이터 모델링 과정에서 정의된 데이터 객체들은 비지니스 기능을 구현하는데 필요한 정보 흐름을 달성하기 위해 변환된다 . 데이터 객체를 첨가하고, 수정하고 , 삭제하고 , 검색하기 위해 처리하는 내용에 대한 설명이 있어야 한다 .

어플리케이션 생성 (Application generation)

RAD 는 4 세대 기법의 사용을 가정한다 . 기존의 3 세대 프로그래밍 언어를 사용해 소프트웨어를 생성하는 것보다 RAD 프로세스(가능할 때)는 기존의 프로그램 컴포넌트를 재사용하기 위해 또는 재사용할 수 있는 컴포넌트들을 생성하기 위해서 작업한다 . 모든 사례에서 자동화 도구는 소프트웨어 구조를 촉진시키기 위해 사용된다 .

테스팅과 인수인계 (Testing and turnover)

RAD 프로세스는 재사용을 강조한다. 많은 프로그램 컴포넌트들은 이미 테스팅했었다 . 이것은 총 테스팅 시간을 줄인다. 그러나 새로운 컴포넌트들은 테스트되어야 하고 또 모든 인터페이스도 완전히 검사되어야 한다 .

제제 22 장장 .. 프프로로세세스스 -- 1122 --


? RAD 접근법의 단점

① 대규모이지만 범위가 한정되어 있는 프로젝트에 대해 RAD는 바람직한 RAD 팀 수를 생성하

기 위해 충분한 인적 자원들을 요구한다 .

② RAD는 단축된 기간에 시스템을 완성하기 위해 필요한 긴급(rapid-fire) 활동을 책임지는 개발

자와 의뢰인을 요구한다 . 만약 책임지는 구성원이 없으면 , RAD 프로젝트는 실패할 것이다.

③ 어플리케이션의 모든 타입이 RAD에 적합한 것은 아니다 . 만약 시스템이 적절하게 모듈화될

수 없으면, RAD에 필요한 컴포넌트들의 구축은 문제가 있다 .

④ 고성능이 쟁점이 되고 성능이 시스템 컴포넌트에 인터페이스를 통해 성취된다면 , RAD 접근법

은 작업할 수 없다 .

⑤ RAD는 테크니컬 위험이 높을 때 적합하지 않다 . 이것은 새로운 어플리케이션이 새로운 기술

을 주로 사용할 때 또는 새로운 소프트웨어가 기존의 컴퓨터 프로그램과 상호 운영되는 수준을

크게 요구할 때 사용된다 .

2.7 단계적 소프트웨어 프로세스 모형

? 단계적 모형(evolutionary models)들은 반복한다 . 그것들은 소프트웨어 엔지니어가 점차적으로

완벽한 소프트웨어 버전들을 개발할 수 있는 방법으로 특성화된다.

2.7.1 점증적 모형(incremental model) P.46 의

? 프로토타입핑의 반복 개념을 선형 순차 모형(반복적으로 적용된)의 요소들을 결합시킨 것이다.

? 점증적 모형은 월별로 진행되는 것으로 기복이 심한 형태에 선형 순차를 적용한다.

? 각 선형 순차는 소프트웨어의 산출 가능한 “점증(increment)”을 생산해낸다

? 어떤 점증에 대한 프로세스 흐름은 프로토타입핑 패러다임을 통합할 수 있다 .

? 핵심 제품(core product) ? 사용 및 평가 결과 ? 다음 단계의 점증을 위한 계획 수립

? 프로토타입핑과는 다르게 점증적 모형은 각 점증이 갖는 동작 프로덕트의 전달에 초점을 맞춘다.

? 점증 개발은 기술진(staffing)이 프로젝트에 대해 설정된 비지니스 데드라인(business deadline)까

지 완전한 구현을 사용할 수 없을 때 아주 유용하다 .

? 초기 점증은 몇 사람만으로 구현될 수 있다 . 만약 핵심 제품이 좋다고 인정되면 , 그때 필요하다면

추가 기술진이 다음 점증을 구현하는 데 합류할 수 있다 .

2.7.2 나선형 모형(spiral model) P.48~49 의 ,

? Boehm에 의해 제안

? 선형 순차 모형의 제어하고 체계적인 측면에 프로토타입핑의 반복적 특성을 결합시켜 놓은 발전

적인 소프트웨어 프로세스 모형

완전한 프로덕트가 생성될 때까지 반복

제제 22 장장 .. 프프로로세세스스 -- 1133 --


? 소프트웨어의 점증적 버전들 (incremental version)의 빠른 개발(rapid development)을 할 수 있는 가

능성을 제공해준다 .

? 나선형 모형에서 소프트웨어는 점증적인 릴리즈 (incremental releases)의 단계로 개발된다 .

? 초기 반복 시에 점증적인 릴리즈는 페이퍼 모형(paper model) 이나 프로토타입이 되겠지만 , 반복

의 후반부에는 공학화된 시스템이 보다 완벽한 버전으로 될 것이다 .

? 나선형 모형은 태스크 영역(task regions)이라고 부르는 프레임워크 활동(framework activities)들

로 나누어진다 . 전형적으로 여기에는 3 ∼ 6 개 사이의 태스크 영역이 있다 .

태스크 영역 내용

고객과의 의사교환 개발자와 고객간의 효과적인 커뮤니케이션을 설정하는데 요구되는 작 업들

계획수립 자원들 , 시간표, 그리고 정보와 관련된 다른 프로젝트를 정의하는데 요구되는 작업들

위험 분석 기술과 관리 위험 모두를 평가하는 데 요구되는 작업들 공학 어플리케이션의 하나 또는 그 이상의 표현을 구축하는 데 요구되는 작업들

구축와 릴리이즈 사용자 지원(예 , 문서화와 교육 훈련)을 구축하고, 테스트하고 , 설치하고 , 제공하는 데 요구되는 작업들

고객 평가 공학 단계시에 생성되고 설치 단계시에 구현된 소프트웨어 표현들의 평가에 기반을 둔 고객 피드백 (customer feedback)을 얻는 데 요구되는 작업들

? 나선형 모형은 대규모 시스템과 소프트웨어의 개발에 가장 현실적인 접근법이다 .

? 소프트웨어 개발 과정에 위험성 평가를 도입

? 모델이 복잡하여 개발 프로젝트를 복잡하게 만드는 경향이 있다 .

? 대형 프로젝트에 적합

? 선형 순차나 프로토타입핑 패러다임처럼 폭넓게 사용되지는 않는다.

2.7.3 컴포넌트 어셈블리 모형(Component Assembly Model) P.51의

? 컴포넌트 어셈블리 모형은 나선형 모형의 많은 특성들을 포함한다.

? 컴포넌트 어셈블리 모형은 패키지화된 소프트웨어 컴포넌트(때때로 “클래스”라고 부른다 )를 어

플리케이션에 합성한다.

? 컴포넌트 어셈블리 모형은 소프트웨어 재사용을 만들어주고 재사용은 소프트웨어 엔지니어들

에게 수많은 혜택들을 제공해준다.

2.7.4 컨커런트 개발 모형(concurrent development model) P. 53의

? 컨커런트 엔지니어링(concurrent engineering)이라고도 함

? 컨커런트 프로세스 모형은 일련의 주요 테크니컬 활동들 , 태스크들, 그리고 그것에 연관된 상태

들로 도식적으로 표현할 수 있다 .

? 컨커런트 프로세스 모형은 각 소프트웨어 공학 활동들에 대해 한 상태에서 다른 상태로 전이를

시키는 일련의 사건들을 정의한다.

제제 22 장장 .. 프프로로세세스스 -- 1144 --


? 컨커런트 프로세스 모형은 클라이언트 /서버 어플리케이션의 개발용 패러다임으로 자주 사용된

다 .

? 클라이언트/서버 시스템은 기능 컴포넌트의 집합으로 구성된다 .

? 컨커런트 프로세스 모형은 소프트웨어 개발의 모든 유형에 적용할 수 있고 또 프로젝트의 현상

태를 정확한 그림으로 제공해준다.

2.8 정형 방법 모형(formal methods model)

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

? 정형 방법은 소프트웨어 엔지니어가 엄격한 수학적 표기법을 적용해서 컴퓨터-기저(computer-

based) 시스템을 명시하고 , 개발하고 , 그리고 검증하게 해준다 .

? 이 접근법의 변형인 클린룸 소프트웨어 공학(cleanroom software engineering)이라고 부르는 몇 개

의 소프트웨어 개발 조직이 현재 적용되고 있다 .

? 정형 방법을 개발시에 사용하면 , 다른 소프트웨어 공학 패러다임에서 극복하기 어려운 많은 문

제들(애매모호성, 불완전성 , 불일치성 ..)은 제거 시키는 메커니즘을 제공한다 .

? 정형 방법을 설계시에 사용하면 , 프로그램 검정에 대한 기초를 제공해준다 .

? 정형 모형들의 개발은 현재 아주 많은 시간을 소비하고 비용이 많이 든다 .

? 소프트웨어 개발자들은 정형 방법을 적용하는 데 필요한 배경을 거의 가지고 있지 않으므 로 , 광

범위한 교육이 요구된다 .

? 기술적으로 미숙한 고객을 위한 의견교환 매카니즘으로 모형을 사용하기가 어렵다 .

? 정형 방법 접근법은 안전-정밀(safety-critical) 소프트웨어를 구축해야 하는 소프트웨어 개발자

(예 , 항공 운항과 기계장치의 개발자)들과 소프트웨어의 오류 발생 때문에 경제적인 어려움을 겪

고 있는 개발자들 사이에는 지지를 받고 있다 .

2.9 4세대 기법(4GT: fourth generation techniques)

? 데이터베이스 질의에 대한 비절차적 언어 , 보고서 생성 , 자료 조작 , 스크린 인터페이스와 정의 , 코

드 생성 , 고급 수준의 그래픽 처리 능력 , 스프레드쉬트 처리 능력등의 도구들을 개발 환경으로 갖

는 기술

? 특별한 정보 분석과 대형 데이터베이스에 보고되는 정보 보고에 국한

? 수집한 중요한 자료들은 소프트웨어 생산에 요구되어지는 시간이 짧고 , 중간적인 응용 분야에서

매우 감소되고 , 소규모 응용 분야에서 설계와 분석의 양이 많이 감소된다 .

? 소프트웨어 개발시간의 대폭적인 감소와 소프트웨어를 구축하는 사람의 생산성이 크게 향상

? 대규모 소프트웨어 개발 노력에 4GT 사용은 코딩의 제거를 통해 성취할 수 있는 실질적인 시간 절

약을 얻기 위해서 많은 분석 , 설계 , 테스팅 (소프트웨어 공학 활동들)을 요구한다 .

? 반대자 - 현재의 4GT 도구는 프로그래밍 언어보다 사용하기가 많이 쉽지 않고 , 이러한 도구로 만

들어낸 원시코드가 비효율적이고 , 또 4GT 를 사용해서 개발한 대형 소프트웨어 시스템의 유지보

수에 문제가 있다고 주장

제제 22 장장 .. 프프로로세세스스 -- 1155 --


? 지지자 - 4GT 의 사용폭이 지난 십년 동안 상당히 넓어졌고 지금은 많은 다른 어플리케이션 분야

에서 실행 가능한 방법이 되었다 . CASE(computer-aided software engineering) 도구들과 코드 생성

기를 결합시켜 4GT 는 많은 소프트웨어 문제에 대해 신뢰할 수 있는 해결 방안을 제공해 주고 있

다 .

제제 33 장장 .. 프프로로젝젝트트 관관리리 개개념념 -- 1166 --


33.. 프프로로젝젝트트 관관리리 개개념념((pprroojjeecctt mmaannaaggeemmeenntt ccoonncceeppttss))

3.1 관리 스펙트럼

효효과과적적인인 소소프프트트웨웨어어 프프로로젝젝트트 관관리리를를 위위한한 중중요요 요요소소 ((33PP))

? 사람(people) : 프로젝트를 수행하는데 인적 재능과 동기는 성공에 가장 중요한 효과를 가진다 .

인적 관리 능력 완성 모형(PM-CMM: People Management Capability Model) – SEI 개발

? 문제(problem) : 문제 복잡도는 반드시 추정과 스케쥴링되어야 한다 .

프로세스의 목적과 영역 설정 ? 대처 방안 고려 ? 기술과 제약 식별 : 작업 분할

? 프로세스(process) : 소프트웨어 개발에 관한 종합 계획을 수립하는데 필요한 골격을 제공

3.2 사람

3.2.1 플레이어

? 소프트웨어 프로세스(그리고 모든 소프트웨어 프로젝트)는 5 개의 역할을 수행하는 담당자로 다

음과 같이 분류할 수 있다 .

이용 가능한 휴먼 자원

대표적인

소프트웨어

프로젝트

크기(Size)

구현을 위한 기술

비지니스 이슈

사용자 요구사항

비용

제품 전달 기한

응용 시스템 제약

이용 가능한 개발 환경

문제의 특성을 설명해주는 주요 데이터 , 기능 , 행위들을 식별하고 특히 양적인 방법으로 이들 특성을 한정시켜 준다 .

프로젝트의 전체 목표 식별



담당자 역 할 선임 매니저 (Senior manager) 프로젝트에 크게 영향을 주는 비지니스 쟁점을 정의하는 사람

프로젝트 매니저 (Project(technical) manager)

계획을 수립하고, 동기를 부여하고, 조직을 구성하고 , 소프트웨어 작업을 실행하는 실무자들을 관리하는 사람

실무자 (Practitioner) 제품이나 어플리케이션을 공학화시키는데 필요한 실무기술을 갖고 있는 사람

의뢰인 또는 고객(Customer) 공학화시킬 소프트웨어에 대한 요구사항을 명시해주는 사람 최종 사용자 (End user) 제품이 완성되어 인도된 후 소프트웨어를 직접 사용하는 사람

3.2.2 팀장

팀팀장장을을 갖갖추추어어야야할할 능능력력 ((WWeeiinnbbeerrgg 의의 저저서서 tteecchhnniiccaall lleeaaddeerrss hhii pp))

항 목 내 용 동기부여(Motivation). 기술 인력이 자신의 최대 능력을 발휘하도록 격려해주는 능력

조직화 (Organization). 초기 개념을 최종 제품으로 변환시킬 수 있도록 현재 프로세스(또는 새로운 것을 고안하는)들을 형성화시키는 능력

아이디어나 기술 혁신 (Idea 또는 innovation).

사람이 특별한 소프트웨어 제품이나 어플리케이션에 관해 설정된 한계 내에서 작업을 할때 창조적으로 생산하거나 느끼게 해 주는 능력

프프로로젝젝트트 관관리리자자의의 44 가가지지 주주요요 특특성성

특 성 내 용

문제 해결(Problem solving)

? 해결방안에 가장 연관이 있고 체계적인 구조나 해결방안을 개발하는 다른 실무자에게 적절히 동기를 부여하는 기술

? 조직의 쟁점들을 진단 ? 과거 프로젝트에서 배운 것을 새로운 환경에 적용 ? 초기에 문제 해결방안이 틀렸다면 방향을 바꿀 수 있도록 유연

해야 함 .

관리 식별(Managerial identity) ? 해당 프로젝트에 대한 책임 ? 필요시 통제할 수 있다는 확신을 갖여야 함 ? 우수한 기술자가 그들의 재능을 발휘할 수 있도록 보장

성취(Achievement) ? 프로젝트 팀의 생산성을 최적화시키기 위해 독창적이고 진취적 ? 통제된 위험을 범했을때 처벌하지 않는다는 것을 행동으로 보여

줌

영향과 팀 구축 (Influence and team building)

? 사람을 읽을 수 있는 능력 ? 언어와 비언어적 신호를 이해할 수 있어야 하고 , 또 이들 신호를

보내는 사람의 의도에 대답할 수 있어야 함 . ? 아주 긴장된 상태로 관리해야 한다 .



3.2.3 소프트웨어 팀(Software Teams)

MMaanntteeii 의의 33 가가지지 팀팀 조조직직

팀 조직 내 용

민주적 계층 (DD: Democratic decentralized)

? 소프트웨어 공학 팀은 상임 팀장을 갖고 있지 않음 ? 태스크 조정자는 단기간 임명되며 일정 업무가 처리되면 또 다

른 태스크를 처리하기 위해 새로운 조정자가 임명됨 ? 문제와 접근법에 관한 결정은 구성원의 의견수렴을 통해 이루어

짐 . ? 팀원간의 의견교환은 수평적 ? 난의도가 높은 문제에 적합 ? 낮은 모듈화를 갖는 문제에 적합

통제적 계층 (CD: Controlled decentralized)

? 소프트웨어 공학 팀이 특정한 태스크를 조정할 팀장과 서브 태스크를 책임지는 부 팀장을 갖고 있는 팀

? 문제해결은 그룹의 활동이고 구현은 팀장이 각 소그룹에 분할 ? 소그룹들과 개인들 간의 의견교환은 수평적 ? 제어 계층간에는 수직적 의견교환도 발생한다. ? 간단한 문제에 적합 ? 높은 모듈화를 갖는 문제에 적합

통제적 중앙화 (CC: Controlled Centralized)

? 최상위 수준의 문제해결과 내부팀 조정은 팀장이 관리 ? 팀장과 팀원간의 의견교환은 수직적 ? 간단한 문제에 적합 ? 높은 모듈화를 갖는 문제에 적합

MMaanntteeii 의의 소소프프트트웨웨어어 공공학학 팀팀의의 구구조조를를 계계획획할할 때때 고고려려해해야야 될될 77 가가지지 프프로로젝젝트트 인인자자

? 문제의 난이도

? 코드의 라인이나 기능 점수로 나타낸 결과 프로그램의 크기

? 함께 모여있을 시간(team lifetime)

? 모듈화 될 수 있는 수준

? 시스템에 요구되는 품질과 신뢰성

? 인도 날짜의 엄정(rigidity)

? 프로젝트에 필요한 사교성(의견교환)의 수준

CCoonnss ttaattii nnee 의의 소소프프트트웨웨어어 공공학학 팀팀에에 44 가가지지 `̀조조직직 패패러러다다임임 ''

조직 패러다임 내 용

Closed paradigm 권위(authority)의 전통적인 계층(CC 팀과 유사)으로 팀을 구성 과거의 노력과 아주 유사한 소프트웨어를 생성할 때는 적합 기술혁신이 잘 안된다는 단점이 있다 .

Random paradigm 팀을 느슨하게 구성하고 팀원의 개인 기술에 의존 기술혁신이나 기술의 비약적인 발전이 요구될 때 적합 정해진 성능(orderly performance)이 요구될 때는 부적합하다

Open paradigm closed paradigm과 random paradigm의 장점을 취함 복잡한 문제해결에는 바람직하지만 다른 팀들보다 효율적으로 수행하진 못한다 .

Synchronous paradigm 문제의 자연적 구분과 구성원 사이의 많지 않은 대화로 문제의 한 부문을 작업하도록 조직한 구조



책책임임 프프로로그그램램머머 팀팀 ((cchhiieeff pprrooggrr aammmmeerr ttee aamm))

? Baker(1972) 제시

? Brooks(1975)와 Aron(1974)에 의해 보안

? 민주주의 식 팀과 비교해 볼 때 고도로 구조화된 프로젝트 팀 구조이다 .

? 의사 결정이 집중화되고 , 의사 전달 경로가 짧아지는 장점이 있다 .

? 경험이 많고 재능있는 사람을 책임 프로그래머로 이용하는 것을 기본으로 함

? 한명의 고급 프로그래머와 여러 명의 중급 프로그래머가 한 프로젝트에 참여하는 상황에서 효과

적이다 .

역할

책임 프로그래머 ? 경험이 많고 필요한 자격 요건을 갖춘 사람 ? 설계 , 프로그래밍 , testing 그리고 system 설치까지 모든 과정을 책임짐

Backup 프로그래머 ? 책임 프로그래머의 역할을 대신 ? 책임 프로그래머의 작업을 검증하는 것과 test 케이스를 개발하여 도와

주는 역할 라이브러리안

(Librarian) ? Project 와 관련된 모든 사무적인 기능을 담당 ? 자동화된 라이브러리 시스템에 의해 도움을 받음

전문가 ? Project 의 크기가 형태에 따라 임시적 또는 영구적으로 추가되는 사람 ? 프로젝트 행정관, 도구장 , 문서 편집장 , 언어/시스템 전문가, 테스터 , 보

조 프로그래머 등

책임 프로그래머 팀

? 단점 : 큰 조직에서 책임 프로그래머 팀을 조직적인 구조에 알맞게 구성하는 것이 어렵다.

책임 프로그래머에 대한 충분한 대우를 해주기 어렵다 .

현재의 팀 재 구성시 저항이 발생한다 .

적재적소의 책임 프로그래머를 배치하기 어렵다 .

외부 커뮤니케이션

전문가들

책임 프로그래머 백업 프로그래머

라이브러리안



프로그래밍 팀의 구조 장점 단점 기타

민주주의식 팀 (democratic teams)

각 요원들이 의사 결정에 참여하며 , 요원들이 서로 배우고 익히며 , 공개된 작업 환경에서 자신의 작업에 만족감을 갖는다 .

불필요한 의사 교환이 많이 발생 개인적인 책임과 권한이 약화될 수 있다 .

복잡한 프로젝트로서 장기간 동안 조사하고 개발해야 하는 업무에 적합

책임 프로그래머 팀 (chief programmer

teams)

의사 결정이 집중화되고 , 의사 전달 경록 짧아진다 .

위 참조 한명의 고급 프로그래머와 여러 명의 중급 프로그래머가 한 프로젝트에 참여하는 상황에서 효과적이다

계층형 팀 (hierarchical teams)

효과적인 의사 전달 경로만을 허용

가장 우수한 프로그래머가 승진시 유능한 프로그래머를 잃고 , 무능한 관리자로 전락하는 수가 있다 .

가장 기술적으로 뛰어난 프로그래머가 관리자로 승진 ? 유능한 programer 를 잃는다 .

3.3 문제

3.3.1 소프트웨어 영역(software scope)

? 소프트웨어 영역 결정은 소프트웨어 프로젝트 관리의 첫 번째 활동

? 문제의 경계(bound)를 설정 한다 .

? 소프트웨어 영역에 관한 지문은 한정되어 있어야 한다 .

? 소프트웨어 영역을 결정하는 질문

의미 질 문

내용(Context)

소프트웨어를 대형 시스템 , 프로젝트 , 또는 업무 내용에 적합하도록 어떻게 구축할 것인가? 그리고 어떠한 제약을 해당 내용의 결과에 부과할 것인가? System 결정 , 제약사항 결정

정보 목적 (Information objectives)

고객이 볼 수 있는 어떤 데이터 객체가 소프트웨어의 출력물로 생성되는가? 어떤 입력에는 어떤 데이터 객체가 요구되는가? 입출력 Data 결정

기능과 성능 (Function 과 Performance)

소프트웨어가 입력 데이터를 출력 데이터로 변환시킬 때 어떤 기능을 수행해야 하는가? 어떤 특별한 성능 특성을 설명해야 되는가? Process 결정

3.3.2. 문제 분해(problem decomposition)

? 문제 분할(problem partitioning)이라고도 함

? 소프트웨어 요구사항 분석의 핵심 활동



? 분해는 주로 두 개의 영역에 적용된다.

① 전달되어야 하는 기능성 영역 : 기능

② 그것을 전달하는 데 사용되는 프로세스 영역 : 기능에 대한 처리

3.4 프로세스

? 소프트웨어 프로세스의 일반적 단계 - 단계인 정의(definition), 개발(development), 유지 보수

(maintenance)

? 프로젝트 팀은 공학화시킬 소프트웨어에 적합한 프로세스 모델을 선택

? 프로젝트 관리자

- 프로세스 모델 결정 ? 예비계획 수립 ? process 분해 ? 완전한 계획

3.4.1 문제와 프로세스의 합병 P. 82의

? 좌측 열 : 각 주요 문제 기능 기술

? 상단 행 : 전체 구조 활동 기술

? 하단 행 : 소프트웨어 공학 작업 태스크(각 프레임워크 활동에 대한) 기술

? 프로젝트 관리자(그리고 다른 팀원들 )의 작업은 각 매트릭스 셀(matrix cell)에 대한 자원 요구사

항을 추정하고 , 또 각 셀에 연관된 태스크에 대한 시작과 종료 날짜 그리고 각 셀의 결과로 나오

는 제품을 작업한다 .

P. 140의 참조

3.4.2 프로세스 분해

? 소프트웨어 공학 패러다임 선택 ? 프로세스 모형을 일반화시키는 소프트웨어 공학 태스크 선택

(프로세스 분해)

? 작은 프로젝트와 폭넓은 프로젝트 사이에는 프로세스 분해의 개수가 다르게 나타난다 .

? 선형 순차 모형 ? 프로토타이핑 모형 ? RAD 모형 ? 단게적 모형 ? 나선형 모형 ? 컴포넌트 어셈블리 모형 ? 컨커런트 개발 모형 ? 정형 방법 모형 ? 4세대 기법 모형

제제 44 장장 .. 소소프프트트웨웨어어 프프로로세세스스와와 프프로로젝젝트트 매매트트릭릭스스 -- 2222 --


44.. 소소프프트트웨웨어어 프프로로세세스스와와 프프로로젝젝트트 메메트트릭릭스스

? 소프트웨어 메트릭스(software metrics)

- 컴퓨터 소프트웨어에 대한 넓은 영역의 측정

4.1 측정, 척도, 지표

용어 정 의

측정(measures) 프로젝트나 프로세스의 어떤 속성의 정도 , 양 , 차수 , 또는 크기에 관한 수량적인 좌표를 제공

Measurement measures 를 결정하는 활동이다

Metrics 시스템 컴포넌트 또는 프로세스가 주어진 속성을 소유하고 있는 정도에 관한 수량적인 측정 - The IEEE standard Glossary of Software Engineering Terms

지표(indicator) 소프트웨어 프로세스와 소프트웨어 프로젝트 , 프로덕트 그 자체에 통찰력을 제공해 주는 척도나 척도의 조합

4.2 프로세스와 프로젝트 도메인에서 척도

프프로로세세스스 지지표표 ((pprroocceess ss iinnddiiccaattoorr ))

? 소프트웨어 공학 조직이 현재 있는 프로세스의 효율성으로 통찰력을 얻을 수 있게 해준다 .

? 관리자와 실무자에게 해야 할 일과 하지 말아야 할 일을 판단하게 해준다 .

프프로로젝젝트트 지지표표 ((pprroojjeecctt iinn ddiicc aatt oorrss ))가가 소소프프트트웨웨어어 프프로로젝젝트트 관관리리자자에에게게 미미치치는는 영영향향

? 현재 진행중인 프로젝트를 평가할 수 있게 해 주고

? 잠재적인 위험을 추정할 수 있게 해 주고

? 관리자들이 “비평하기” 전에 문제 발생 영역을 발견하게 해 주고

? 작업 흐름이나 태스크를 조정하게 해주고

? 소프트웨어 공학 작업 제품의 품질을 통제하는 프로젝트 팀의 능력을 평가할 수 있게 해 준다 .

○ 동일한 소프트웨어 메트릭스가 프로세스와 프로젝트 지표 모두를 결정할 수 있다 .



4.2.1 프로세스 메트릭스와 소프트웨어 프로세스 개선

소소프프트트웨웨어어 품품질질과과 조조직직의의 성성능능에에 크크게게 영영향향을을 미미치치는는 세세 개개의의 요요소소

? P. 92의 참조

메메트트릭릭스스 가가이이드드라라인인 ((9922’’ GGrr aaddyy))

? 메트릭스 데이터를 해석할 때 상식과 조직적 감각을 사용하라 .

? 측정과 척도(메트릭스)를 수집하기 위해 작업하는 팀과 개인들에게 규칙적인 피드백을 제

공하라 .

? 개인을 평가하는데 메트릭스를 사용하지 마라 .

? 그들이 달성되는데 사용될 분명한 목표와 척도를 설정하기 위해 실무자와 팀이 함께 작업하라

? 개인이나 팀을 위협하기 위해 메트릭스를 절대로 사용하지 마라 .

? 문제 영역을 나타내는 메트릭스 데이터는 “부정적”으로 고려되어서는 안된다 . 이 데이터는 단지

프로세스 개선에 관한 지표이다 .

? 다른 중요한 메트릭스를 배제한 단일 메트릭스에 매달리지 마라 .

통통계계적적 소소프프트트웨웨어어 프프로로세세스스 개개선선 ((SSSS PPII:: ss tt aattii ss ttiiccaall ss ooff tt wwaarree pprr oocceess ss iimmpprr oovvee mmee nntt ))

? 조직은 프로세스 메트릭스의 수집과 사용에 익숙해지기 때문에 간단한 지표의 유도를 보다 엄

격한 접근 방법으로 제공

? 어플리케이션 , 시스템 또는 프로덕트가 개발되고 사용될때 발생되는 모든 오류와 결함에 관한

정보를 수집하기 위해서 소프트웨어 실패 분석(software failure analysis)을 사용

? 결합 분포 개발 ? 피시본 다이어그램(fishbone diagram: Grady) p. 96 의

4.2.2 프로젝트 메트릭스

? 소프트웨어 프로세스 메트릭스는 전략적인 목적으로 사용되는데 반해 소프트웨어 프로젝트 측

정은 전술적인 목적으로 사용된다.

? 프로젝트 메트릭스와 이들로부터 유도한 지표들은 프로젝트 작업흐름과 기술적인 활동들을 채

택하는 프로젝트 관리자와 소프트웨어 팀이 사용한다 .

? 소프트웨어 프로젝트에 프로젝트 메트릭스는 추정(estimation)시에 처음 적용된다

? 과거 프로덕트에서 수집한 메트릭스들은 현재 소프트웨어 작업에 대해 추정할 때 노력과 시간에

대한 기초 자료로 사용된다.

? 프로젝트가 진행되면서 확장된 노력과 카렌더 시간의 측정은 본래의 추정(그리고 프로젝트 일

정)과 비교된다. 프로젝트 관리자는 진행을 조정하고 제어하기 위해 이들 자료를 사용한다 .



?? 프프로로젝젝트트 메메트트릭릭스스의의 목목적적

① 메트릭스는 지연을 없애고 또 잠재적인 문제점과 위험을 완화시키기 위해 필요한 조정을 통해해

서 개발 일정을 최소화하는데 사용된다.

② 프로젝트 메트릭스는 진행 중인 상태의 제품 품질을 평가하고, 필요시에 품질을 개선하기 위해

기술적인 접근법을 수정하기 위해 사용된다 .

? 품질이 개선되면 오류들은 최소화되고 , 오류의 수가 작아지면 프로젝트 시에 요구되는 재작업의 양

도 줄어든다 . 이것은 전체 프로젝트의 비용을 감소시킨다 .

4.3 소프트웨어 측정

직직접접적적인인 측측정정 ((ddiirreecctt mmee aass uurreess )) :: 정정량량적적 측측정정

? 적용된 비용과 노력

? 생산된 LOC(line of code)

? 실행 속도

? 메모리 크기

? 일정 시간 동안에 발견된 결함 등이 포함된다 .

간간접접적적인인 측측정정 ((iinnddiirreecctt mmeeaass uurreess )) :: 정정성성적적 측측정정

? 기능성

? 품질

? 복잡도

? 효율성

? 신뢰성

? 유지 보수성

? 이외 많은 다른 “가능성” 등

소프트웨어 측정 이유

① 제품의 품질을 나타내기 위해

② 제품을 생산해 내는 사람의 생산성을 평가하기 위해

③ 새로운 소프트웨어 공학 방법과 도구를 사용해서 얻은 이점(생산성과 품질면)을 평가하기 위해

④ 추정에 대한 기준선을 만들기 위해

⑤ 새로운 도구들이나 추가 교육에 대한 요청을 정당하게 돕기 위해



4.3.1 크기-중심 메트릭스 p.99 의

? 크기-중심 소프트웨어 메트릭스(size-oriented software metrics)는 생산된 소프트웨어의 “크기”을

고려해서 품질 및/또는 생산성 측정을 정규화시켜 유도된다 .

? 크기 중심 메트릭스의 이용 항목들

? KLOC당 오류

? KLOC당 결함들

? LOC 당 비용($)

? KLOC당 문서 페이지 수

? 오류들 /인-월

? LOC/인-월

? $/문서의 페이지

? 크기-중심 메트릭스는 논란의 여지가 있고 일반적으로 소프트웨어 개발 과정의 측정에 최선의

방법으로 인정되지 않고 있다 . ? 이유 : LOC 의 문제점

LLOO CC 의의 문문제제점점

내 용

지지자

LOC 는 소프트웨어 개발 프로젝트의 “가공물 (artifact)”이다 쉽게 계산될 수 있다 . 현존하는 많은 소프트웨어 추정 모델들이 주요 입력으로 LOC나 KLOC 를 사용한다 대부분의 문헌과 자료에는 LOC 로 이미 존재하고 있다

반대자

프로그래밍 언어-종속적이고 , 잘 설계되지 않는다 . 짧은 프로그램에 적합하다 . 비절차적 언어에서는 쉽게 적용할 수 없다 . 추정에서 LOC의 사용은 성취되기가 불가능할 정도로 세부적인 수준을 요구한다(즉 , 계획자는 분석과 설계가 완성되기 전에 생산될 LOC 를 추정해야 한다).

4.3.2 기능-중심 메트릭스 P.101의

? 정규화된 값으로 어플리케이션이 전달하는 기능성의 측정에 사용

? LOC 보다 프로그램의 “기능성”이나 “유틸리티”애 초점을 맞춤

? “기능성”은 직접 측정될 수 없기 때문에 다른 직접 측정을 사용해서 간접적으로 유도

? Albrecht ~ “기능 점수(function point) 방법”이라는 생산성 측정 방법 제안

? FP = 전체 합계 ×[0.65 + 0.01 × ? Fi]

소프트웨어 정보 영역에서 계산할 수 있는 측정과 소프트웨어 복잡도의 평가에 기초를 둔 경험적인 관계식을 이용하여 유도

복잡도 조정값(1~5)의 합 P. 102 의 를 이용하여 경험적으로 설정



? 크기 중심 메트릭스의 이용 항목들

? FP 당 오류

? FP 당 결점

? FP 당 비용($)

? FP 당 문서 페이지 수

? 인-월 당 FP

4.3.3 확장된 기능 점수 메트릭스

? 기능 점수 메트릭스는 본래 기업의 정보 시스템 어플리케이션에 적용하기 위해 설계

? 어플리케이션을 수용하기 위해 데이터 차원은 기능적이고 행위적(제어) 차원의 배제를 강조

? 기능점수 측정은 많은 공학과 내장 시스템 (기능과 제어를 강조하는 시스템)에 부적당

확장 기능 점수 특 징

특성점수(feature points) 공학 소프트웨어 어플리케이션에 적용할 수 있는 기능점수 측정의 슈퍼셋(superset) 측정은 알고리즘 복잡도가 높은 어플리케이션에 적합

3D 기능 점수 (3D function point)

기능과 제어 능력을 강조하는 어플리케이션에 적합 기능과 제어 크기를 갖는 소프트웨어의 데이터 차원을 통합 ? 데이터 차원(data dimension) ? 기능 차원(function dimension) ? 제어 차원(control dimension)

FFPP 의의 논논란란

내 용

지지자

? FP 가 프로그래밍 언어 독립이므로 , 전통적이고 비절차적 언어를 사용하는 어플리케이션 분야에는 이상적

? FP 가 프로젝트의 전개 초기에 알고 있는 자료에 기초하고 있어 , 추정 기법으로 아주 바람직하다고 주장

반대자

? 계산을 객관적이기 보다는 주관적 자료에 기초하기 때문에 이 방법은 “요술(sleight of hand)”을 요구한다 .

? 정보 도메인 (그리고 다른차원)의 계수를 사후에 수집하기가 어렵다 . ? FP 는 직접적인 물질적 의미를 갖고 있지 않다고 주장 - 단지 수치일 뿐이다 .

4.4 다른 메트릭스 접근법의 조정

소소프프트트웨웨어어 생생산산성성에에 영영향향을을 미미치치는는 55 개개의의 중중요요한한 인인자자 ((7788’’ BBaass ii ll ii 와와 ZZeellkk oowwii ttzz))

인자 내 용 인적 인자(People factors) 개발 조직의 규모와 전문성 문제 인자(Problem factors) 해결해야 할 문제의 복잡도와 설계 제한이나 요구사항에서 변경 수

프로세스 인자 (Process factors)

사용되는 분석과 설계 기법 , 사용 가능한 언어와 CASE 도구 , 그리고 검토 기법

제품 인자(Product factors) 컴퓨터 -기저 시스템의 신뢰성과 성능 자원인자(Resource factors) CASE 도구 , 하드웨어와 소프트웨어 자원들의 가용성



4.5 소프트웨어 품질에 대한 메트릭스

소소프프트트웨웨어어 공공학학의의 가가장장 중중요요한한 목목표표

? 고품질의 시스템과 어플리케이션 또는 제품을 생산해 내는 것

소소프프트트웨웨어어 엔엔지지니니어어는는

? 소프트웨어 프로세스의 전후관계에 현대적 도구들과 연관된 효율적인 방법을 적용해야 한다 .

? 고품질이 실현되었는지를 측정해야 한다 .

? 분석과 설계 모형의 품질 , 원시 코드 , 그리고 소프트웨어가 공학화되어 생성된 테스트 사례 등을

평가하는 측정을 한다

? 실시간 품질 평가를 수정하기 위해 엔지니어는 주관적인 방법보다 객관적인 방법으로 품질을 평

가하는 테크니컬 측정(technical measures: 18 장과 23 장)을 사용해야 한다

프프로로젝젝트트 관관리리자자는는

? 프로젝트가 진행되면 품질을 평가해야 한다 .

? 개별적인 소프트웨어 엔지니어가 수집한 비공개 메트릭스는 프로젝트 수준의 결과들을 제공하

기 위해 통합하고 오류와 결함을 측정

? 측정으로부터 유도된 메트릭스는 개인과 그룹 소프트웨어의 품질 보증과 제어 활동의 효과성에

대한 지표를 제공

? 오류 데이터는 또한 각 프로세스 프레임워크 활동에 대한 결함 제거 효율성 (DRE: defect removal

efficiency)를 계산하는데 사용

4.5.1 품질에 영향을 미치는 인자들의 개요

MMccCCaall ll 과과 CCaavvaannoo 의의 소소프프트트웨웨어어 품품질질 평평가가를를 위위한한 품품질질 인인자자

① 제품 운영(그것을 사용하는),

② 제품 개정(그것을 변경하는)

③ 제품 전이(다른 환경에서 작업하기 위해 수정하는 , 즉 “이식(porting)”).



4.5.2 품질 측정

정의 내 용

정확성 (correctness)

? 정확성은 소프트웨어가 요구되는 기능들을 수행하는 정도 ? 정확성에 관한 가장 일반적인 측정은 KLOC당 결함(defects per KLOC) ? 결함 - 요구사항에 일치하지 않는 것을 의미

유지보수성 (maintainability)

? 프로그램 오류 수정 환경 변화에 대한 적응성 요구사항 변경에 대한 수용 용이성

? 직접적 측정 불가 ? 간접적 측정(변경 평균 시간: MTTC)

무결성 (integrity)

? 시스템의 보안을 위해 공격(우연+고의)에 저항하는 시스템의 능력 ? 공격은 소프트웨어의 프로그램 , 자료 , 문서 모두에서 발생될 수 있다 . ? [정의] 무결성 = ? [1 – 위협 ? (1 – 보안)]

- 위협(threat) : 특정한 유형의 공격이 주어진 시간 내에 발생하는 확률(이것은 경험적 증거로부터 유도되거나 추정될 수 있다)이다 .

- 보안(security) : 특정한 유형의 공격을 물리칠 수 있는 확률(이것은 경험적 증거로부터 유도되거나 추정될 수 있다)이다 .

사용성 (usability)

? 사용자 친숙성의 정도 ① 시스템을 배우는데 요구되는 물질적 및/또는 지적 노력 ② 시스템의 사용이 적합한 효율을 갖는데 요구되는 시간 ③ 일반적인 능력만을 갖고 있는 사람이 시스템을 사용할 때 측정되는 생산성

의 순수 증가 ④ 시스템에 대한 사용자 입장의 주관적 평가

4.5.3 결함 제거 효율성(DRE:: defect removal efficiency)

? 본래 DRE는 품질 보증이나 제어 활동이 모든 프로세스 프레임워크 주요 활동에 적용되어 품질

보증과 제어 활동의 여과 능력의 측정하기 위한 것 .

? 공식 : DRE = E / (E + D)

E = 소프트웨어를 최종 사용자에게 전달하기 전에 발견된 오류의 수

D = 전달된 후 발견된 결함의 수

? 이상적인 값 : 1 ? 소프트웨어 내에 어떠한 오류도 발생하지 않았다는 것을 의미

? 품질 제어와 품질 보증을 위한 여과 능력 지표기를 제공하는 메트릭스로 사용된다면 , DRE는 소

프트웨어 프로젝트 팀에게 전달되기 전에 가능한 많은 오류를 발견하는 기술을 가르쳐 준다 .

? DRE 는 또한 프로젝트 팀이 다음 프레임워크 활동이나 소프트웨어 공학 태스크로 넘어가기 전

에 오류를 발견하는 팀 능력을 평가하기 위해 프로젝트 내에서 사용된다 .



4.6 소프트웨어 프로세스 내에서 메트릭스 통합

소소프프트트웨웨어어 메메트트릭릭스스 수수집집 과과정정 P.113의

항 목 내 용

데이터 수집(data collection) 요구되는 자료를 재구축하기 위해 과거에 수행한 프로젝트에 관한 과거 데이터 조사를 요구하고 측정 수집

메트릭스 계산(metrics computation 수집된 측정의 폭에 따라 메트릭스는 다른 품질과 프로젝트-중심 메트릭스처럼 LOC 나 FP 측정의 넓은 영역으로 확대된다 .

메트릭스 평가(metrics evaluation)

측정은 추정 , 테크니컬 작업 , 프로젝트 제어 , 그리고 프로세스 개선시에 평가되고 적용된다. 프로젝트나 프로세스를 가이드 해주는 지표의 집합을 얻어서 생산해낸 결과에 대한 주요 이유에 초점을 맞추고 있다

.

제제 55 장장 .. 소소프프트트웨웨어어 프프로로젝젝트트 계계획획 수수립립 -- 3300 --


55.. 소소프프트트웨웨어어 프프로로젝젝트트 계계획획수수립립 ((pprroojjeecctt ppllaannnniinngg))

? 특정한 목적을 달성하기위해 개발 계획 프로그램을 수립하고 프로그램의 분석 , 구현 등의 작업

을 수행하는 것을 프로젝트(project) 라 한다 .

? 소프트웨어 프로젝트 관리 프로세스는 공통적으로 프로젝트 계획수립이라고 부르는 일련의 활

동으로 시작한다.

? 이들 활동 중 첫 번째 활동이 추정 (estimation)이다 .

5.1 추정에 대한 관찰

추추정정에에 영영향향을을 미미치치는는 인인자자 ((내내재재된된 위위험험 ))

인 자 설 명

프로젝트 복잡도(project complexity)

계획 수립이 갖고 있는 불확실성에 크게 영향을 미침 과거 노력(프로젝트)에 의해 상대적으로 측정

프로젝트 크기 (project size)

추정의 정확성과 효율성에 영향을 미침 문제 분해(decomposition)

구조의 불확실성(structural uncertainty)

구조는 요구 사항이 일치되는 정도와 구별되는 용이성과 처리되어야 하는 정보의 계층적 성질을 의미

과거 정보의 가용성(availability)

과거 정보에 대한 정보 이용

위험(risk) 설정된 자원 , 비용 그리고 일정에 대해 수량적인 추정이 불확실한 수준을 측정

5.2 프로젝트 계획수립 목적

? 소프트웨어 계획수립의 목적 - 관리자가 자원 , 비용 , 그리고 스케줄을 합리적으로 추정할 수 있

는 프레임워크 제공

? 주 목적 – 제품에 대한 목표 , 필요성 , 제약 조건을 명확히 한다 .

? 추정은 소프트웨어 프로젝트의 초기 단계에서 한정된 시간 내에 만들어야 한다 .

? 프로젝트가 진행되어갈수록 규칙적으로 갱신되어야 한다 .

? 추정은 “최적의 사례”와 “최악의 사례”의 시나리오가 정의되어야 프로젝트 결과를 한정(bound)

시킬 수 있다 .

5.3 소프트웨어 영역(software scope)

? 소프트웨어 프로젝트 계획수립의 첫 번째 활동 ? 소프트웨어 영역 결정

? 소프트웨어의 기능(functions), 성능(performance), 제약(constraint), 인터페이스 , 그리고 신뢰성등

을 기술



■ 개발 비용을 극적으로 줄여 주고, 또 더 빨리 인도시켜 주는 소프트웨어 빌딩 블록

■ 계획 수립 진행시 고려해야 할 4가지 소프트웨어 자원(bennatan(92’)) ? Off-the-shelf component ? Full-experience component ? Partial-experience component ? New component

5.3.1 영역에 필요한 정보 획득

고고객객과과 개개발발자자간간의의 의의견견 교교환환 방방법법

? 예비 모임(meeting)이나 인터뷰(interview)

? 문맥-자유 질문 ? 모임형식(FAST)

문문맥맥 --자자유유 질질문문 ((ccoonntteexxtt --ffrreeee qquueesstt iioonn)) ;; GGaauuss ee 와와 WWeeiinn bbeerrgg((8899’’ss )) PP.. 112233 ~~ 112244 참참조조

? 문제의 기본적인 이해를 유도해주는 질문들의 집합 , 해결방안을 원하는 사람 , 희망하는 해결방

안의 성격 , 그리고 첫 만남 자체의 효율성 등을 제시 .

? 질의-응답(Q&A) 형식 – 첫 만남에서 사용하는 것이 바람직

? Gause와 Weinberg 는 모임의 효율성에 초점을 맞춘 문맥-자유 질문의 마지막 질문을 “메타-질문

(meta-questions)”이라 정의하고 몇가지 항목을 추가하였다. – P.124 참조

FFAASS TT((ff aaccii ll ii ttaattee dd aappppll iiccaattiioonn ss ppeeccii ffiiccaattii oonn tteecchh nnii qquueess ))

? 팀-중심 접근법(team-oriented approach)

? 문제를 식별하고 , 해결요소들을 제안하고, 다른 접근법들을 절충하고 , 그리고 요구사항에 대한

개략적인 집합을 명시해주는 일을 고객과 개발자가 함께 팀이 되어 만들게 해준다.

5.4 자원

? 소프트웨어 계획수립의 두 번째 태스크

? 소프트웨어 개발 노력을 달성하는데 요구되는 자원을 추정

사람 (People)

재사용 가능한 소프트웨어 컴포넌트

(reusable software )component)

하드웨어 /소프트웨어 툴 (development environment)

소프트웨어 프로젝트에 요구되는 인원수는 개발 노력의 추정이 만들어진 후에 결정된다.

소프트웨어 공학 환경(SEE: software engineering environment)이라고 부르는 소프트웨어 프로젝트를 지원하는 이 환경은 하드웨어와 소프트웨어를 합친 것이다.



5.5 소프트웨어 프로젝트 추정

?? 소소프프트트웨웨어어 프프로로젝젝트트 추추정정의의 선선택택 사사항항

① 프로젝트에서 추정을 최후까지 지연시킨다(100% 정확 그러나 비 실용적 )

② 이전에 완료했던 유사한 프로젝트에 근거해서 추정한다 .

③ 프로젝트 비용과 노력을 추정하는데 비교적 간단한 분해 기법을 사용한다 .

④ 소프트웨어 비용과 노력을 추정하기 위해 하나이상의 경험적 모형(empirical model)을 사용한다 .

⑤ 하나 이상의 자동화된 추정 도구를 구입한다.

5.6 분해 기법(Decomposition Techniques)

? 소프트웨어 프로젝트 추정을 “분할과 통합(divide & conqure)”이라는 방법으로 접근

? 한 프로젝트를 주요한 기능과 관련된 소프트웨어 공학 태스크로 분해시키므로 ., 비용과 노력 추

정은 단계적인 형태로 수행한다 .

? 문제 분해와 프로세스 분해의 두가지 관점을 고려

⑴⑴ 소소프프트트웨웨어어 크크기기 ((SS oofftt wwaarree SS iizziinngg))

? 직접 – LOC 측정 , 간접 – FP

? Putnam과 Myers 의 크기 문제에 대한 4 가지 접근법

접근법 내 용

“Fuzzy-logic” sizing

■ 퍼지 논리(fuzzy logic)의 초석인 조사 추론 기법을 사용 ■ 개인의 경험이 사용되더라도 계획자는 추정이 실제 경험에 비교될

수 있도록 프로젝트의 과거 데이터베이스에 접근해야 한다 . ■ Application type 식별 , 질적 규모 식별

Function point sizing ■ 정보 영역(기능 , 성능 , 제약 , 인터페이스, 신뢰성등) 도메인 특징들의

추정을 개발한다.

Standard component sizing

■ 정보 시스템의 표준 컴포넌트들인 서브 시스템, 모듈 , 스크린 , 보고서 , 상호 대화형 프로그램 , 배치 프로그램, 파일들, LOC, 그리고 객체 수준의 명령어들의 발생 수를 추정한 뒤 각 표준 요소들의 산출된 크기를 결정하기 위해 과거의 프로젝트 데이터를 사용

■ 유사한 추정과 계산이 다른 표준 컴포넌트들과 통합된 크기값 (통계적으로 조정된)의 결과에도 만들어진다 .

Change sizing

■ 프로젝트가 프로젝트의 일부분인 기존 소프트웨어를 수정하여 사용할 경우에 사용

■ 계획자는 수행되어야 하는 수정의 개수와 타입(예 , 재사용 , 코드 추가 , 코드 변경 , 코드 삭제 등)을 추정한 후 변경의 각 타입에 대한 “노력 비율”을 사용해서 변경의 크기가 추정된다.

? Putnam과 Myers 는 위에서 언급된 각 크기 접근 방법들의 결과는 3-점 (three-point) 또는 기대값

(expected value) 추정을 생성하기 위해 통계적으로 결합된다고 제안 .

? 크기에 대해 최적(optimistic(low)), 중간(mostlikely), 최악(pessimistic(high))을 개발해서 ,

식(5.1)을 사용해 그들을 결합시켜 달성한다 .



⑵⑵ 문문제제 --기기저저 추추정정 ((PPrroobbllee mm--BB aass eedd EEss ttii mmaattiioonn))

? LOC 와 FP 의 추정

? 과거 데이터나 직관(모든 것이 실패했을 때)을 사용해서 계획자는 각 기능에 대해 최적 , 중간 , 최

악의 LOC나 FP 값을 추정한다 .

? 추정변수(크기) EV에 대한 기대값은 최적 (optimistic(s_opt )); 중간 (most likely(s_m )); 그리고 최악

(pessimistic (s_pess ))의 가중평균으로 계산된다

6

4 pessmopt SSSEV??

? 식 5.1

? LOC 나 FP 의 결과가 최적(optimistic)이나 최악(pessimistic)값 밖으로 떨어질 확률은 매우 적다고

가정 .

? 어떤 추정 기법이 아무리 정교하다 할지라도 다른 접근법과 동시에 크로스-체크(cross-check)해

야 된다 . 더욱이 상식과 경험이 효과가 있다 .

⑶⑶ 프프로로세세스스 --기기저저 추추정정 ((PPrroocceessss --BBaa

Documents

1.. 프로로덕덕트트((Prroodduucctt)) Pmaeum.ipdisk.co.kr/publist/VOL1/maeumnet/data/Adobe... · 제11 장장..프프로로덕트트-- 11 -- 작성자: 이 진영 E-Mail : [email protected]