객체지향 소프트웨어 공학(8판)

8판의 구성



본 교재는 두 개의 주요 부분으로 구성되었다. 제2부는 학생들에게 어떻게 소프트웨어 프로덕트를 개발하는지를 가르쳐주며, 제1부는 제2부를 위해 필요한 이론적인 배경을 제공한다. 18개의 장은 다음과 같이 구성된다.



1장 소프트웨어 공학에 대한 소개

2장 ~ 9장(제1부) 소프트웨어 공학 개념들

10장 ~ 17장(제2부) 소프트웨어 공학 기법들

18장 미래 신기술



10장이 새로 추가되어 제 1부의 핵심 내용에 요약이 있다. 2단계 교육과정을 따를 때, 교습자는 우선 제 1부를 가르치고 그 다음 제 2부를 가르쳐야 한다(10장의 핵심 내용은 제 1부에서 깊게 다루기 때문에 10장은 제외). 병렬 교육과정의 경우 교습자는 제 2부를 먼저 가르치고(학생들이 되도록 빨리 그들의 프로젝트들을 시작할 수 있도록) 그 후에 제 1부를 가르친다. 10장의 내용은 학생들이 제 1부를 우선 다루지 않고 제 2부를 이해할 수 있게 구성되었다.



8판의 특징



- 두 개의 새로운 장이 추가되어, 10장에서는 제 1부의 핵심 포인트 요약했으며, 18장에서는 10개의 미래 신기술의 개요를 제시했다.

- 새로운 미니 사례연구를 포함시켜 8장에 설계 패턴들의 내용이 다양해졌다.

- 5장에서 두 개의 이론적인 툴인 분할과 정복 그리고 관심의 분리가 추가되었다.

- 13장의 엘리베이터 문제에 대한 객체-지향 분석은 현대적인 분산과 집중을 배제한 아키텍처를 반영하였다.

- 참고문헌은 최근 연구에 역점을 두어 광범위하게 갱신되었다.

- 100개 이상의 새로운 연습문제들이 추가되었다.

- 새로운 '알고 싶은 사항'이 추가되었다.



머리말



거의 모든 컴퓨터 과학과 컴퓨터 공학 교육과정은 이제 요구되는 팀-기반 소프트웨어 개발 프로젝트를 포함하고 있다. 경우에 따라서 프로젝트는 한 학기나 1/4학기로 수행되나, 1년-장기 팀-기반 소프트웨어 개발 프로젝트는 빠르게 일반화 되고 있다.



이상적으로 모든 학생은 그들에 팀-기반 프로젝트를 시작하기 전에 소프트웨어 공학에 대한 과정을 학습해야 한다(2단계 교육과정). 하지만 실제로 많은 학생들은 그들의 소프트웨어 공학 과정 도중에, 심지어 과정의 초반에 그들의 프로젝트들을 시작한다(병렬 교육과정).



다음 절의 설명처럼 이 교재는 두 학기 교육과정 모두에서 사용될 수 있는 방법으로 구성되었다.



8판은 어떻게 구성되는가?



이 교재는 두 개의 주요 부분으로 구성되었다. 제 2부는 학생들에게 어떻게 소프트웨어 프로덕트를 개발하는지를 가르쳐준다. 그리고 제 1부는 제 2부를 위해 필요한 이론적인 배경을 제공한다. 18개의 장은 다음과 같이 구성된다.



1장 소프트웨어 공학에 대한 소개

2 ~ 9장(제1부) 소프트웨어 공학 개념들

10 ~ 17장(제2부) 소프트웨어 공학 기법들

18장 미래 신기술



10장이 새로 추가되었다. 10장은 제 1부의 핵심 내용에 요약이 있다. 2단계 교육과정을 따를 때, 교습자는 우선 제 1부를 가르치고 그 다음 제 2부를 가르쳐야 한다(10장의 핵심 내용은 제 1부에서 깊게 다루기 때문에 10장은 제외). 병렬 교육과정의 경우 교습자는 제 2부를 먼저 가르치고(학생들이 되도록 빨리 그들의 프로젝트들을 시작할 수 있도록) 그 후에 제 1부를 가르친다. 10장의 내용은 학생들이 제 1부를 우선 다루지 않고 제 2부를 이해할 수 있게 구성되었다.



이 병렬 접근법은 직관에 어긋나 보인다. 확실히 이론은 항상 실습 전에 가르쳐져야 한다. 사실 교육과정 이슈들은 이 교재의 7판을 이용한 대부분의 교습자들이 제 2부의 내용을 제 1부 전에 가르치도록 강요했다. 놀랍게도 이렇게 하는 것이 결과가 가장 만족스러웠다. 그들은 그들의 학생들이 그들의 프로젝트 작업에 결과로 제 1부의 이론적인 내용의 더 나은 공감을 얻을 수 있다고 보고했다. 즉 팀-기반 프로젝트 작업은 학생들에게 좀 더 수용하기 좋고, 기저가 되는 소프트웨어 공학에 이론적인 개념들에 대한 이해를 도와준다.



8판의 새로운 특징



- 본 교재는 전반적으로 갱신되었다.

- 두 개의 새로운 장이 추가되었음. 이전의 설명처럼 제 1부의 핵심 포인트 요약인 10장은 학생들이 그들의 소프트웨어 공학 과정과 병행적으로 팀-기반 학기 프로젝트를 시작할 때 이 책이 사용할 수 있게 추가시켰다. 다른 새로운 장인 18장은 다음과 같은 10개의 미래 신기술의 개요를 제시했다.

+ 관점-지향 기술

+ 모델-기반 기술

+ 컴포넌트-기반 기술

+ 서비스-지향 기술

+ 소셜 컴퓨팅

+ 웹 공학

+ 클라우드 기술

+ 웹 3.0

+ 컴퓨터 보안

+ 모델 체킹

- 새로운 미니 사례연구를 포함시켜 8장에 설계 패턴들의 내용도 상당히 다양해졌다.

- 5장에 두 개의 이론적인 툴들이 추가되었다. 분할과 정복 그리고 관심의 분리이다.

- 이제 13장의 엘리베이터 문제에 대한 객체-지향 분석은 현대적인 분산과 집중을 배제한 아키텍처를 반영하였다.

- 참고문헌들은 최근 연구에 역점을 두어 광범위하게 갱신되었다.

- 100개 이상의 새로운 연습문제들이 추가되었다.

- 새로운 알고 싶은 사항들이 추가되었다.



7판에서 유지된 특징



- Unified Process는 객체-지향 소프트웨어 개발을 위해 계속 선호되는 방법론이다. 그러므로 이 교재 전체에서 학습자는 Unified Process의 이론과 실습들을 접하게 될 것이다.

- 1장에서 객체-지향 패러다임의 강점이 심도 있게 분석되었다.

- 반복적-점진적 생명 주기 모델은 가능한 일찍 2장에서 소개된다. 더욱이 이전에 모든 버전처럼 많은 다른 생명주기 모델들이 제시되고, 비교되며, 대조될 것이다. 애자일 프로세스에 특별히 주의를 기울일 것이다.

- 3장(소프트웨어 프로세스)에서 Unified Process의 워크플로(액티비티)와 프로세스가 소개되고 2차원 생명 주기 모델의 필요성이 설명된다.

- 소프트웨어 팀을 조직하는 다양한 방법들은 애자일 프로세스와 오픈-소스 소프트웨어 개발을 위한 팀을 포함해 4장(팀)에서 제시된다.

- 5장(툴의 선택)은 CASE 툴들의 중요한 부류에 대한 정보를 포함한다.

- 테스팅의 중요성은 6장(테스팅)에서 강조된다.

- 객체는 7장(모듈에서 객체까지)에서 지속적으로 관심을 기울인다.

- 설계 패턴은 8장(신뢰성과 이식성)의 중심 초점으로 남아있다.

- 소프트웨어 프로젝트 관리 계획을 위한 IEEE 표준은 9장(계획수립과 추정)에서 다시 제시된다.

- 11장(요구사항), 13장(객체-지향 분석), 14장(설계)은 주로 Unified Process의 워크플로(액티비티)로서 제시된다. 명확한 이유로 인해 12장(고전적 분석)은 크게 변경하지 않았다.

- 15장(구현)에 내용들은 구현과 통합 사이를 명백하게 구별하였다.

- 인도 후 유지보수의 중요성은 16장에서 강조된다.

- 17장은 학습자들이 소프트웨어 산업에서 이용하기 위해 철저하게 준비시킬 수 있도록 UML에 대한 추가 내용을 제공한다. 이 장은 특히 2학기 소프트웨어 공학 과정 순서를 위해 이 책을 활용하는 교습자들이 이용할 수 있다. 두 번째 학기에 팀-기반 기간 프로젝트나 창의적 프로젝트를 개발하기 위해, 학습자가 UML에 대한 추가 지식을 얻을 수 있게 추가시켰다.

- 이전처럼 두 개의 사례 연구가 있다. MSG Foundation 사례 연구와 엘리베이터 문제 사례 연구는 Unified Process를 이용하여 개발된다. 통상 Java와 C++ 구현은 온라인에서 이용할 수 있다.

- 완전한 생명 주기를 보이기 위해 사용되는 두 개의 사례 연구에 추가에서 8개의 미니 사례 연구는 이동 대상 문제, 점진적 정제, 설계 패턴, 인도 후 유지보수와 같은 특정 주제에서 강조된다.

- 이전에 모든 판에서 문서화, 유지보수, 재사용, 이식성, 테스팅, CASE 툴을 강조했었다. 이번 판에서는 이 모든 개념들은 동일하게 크게 강조된다. 소프트웨어 공학의 기초의 중요성을 인지하지 않는 학습자들에게 최신 견해를 학습시키는 것은 소용없다.

- 7판에서처럼 객체-지향 생명 주기 모델, 객체-지향 분석, 객체-지향 설계, 객체-지향 패러다임의 관리 영향, 객체-지향 소프트웨어의 테스팅과 유지보수에 특별히 관심을 기울인다. 또한 객체-지향 패러다임을 위한 내용이 추가되었다. 추가적으로 많은 간단한 인용문이 객체, 절 또는 심지어 단지 문장에 반영시켰다. 이유는 객체-지향 패러다임이 여러 가지 단계가 수행되는 방법에 관계되는 것이 아니라 오히려 소프트웨어 공학에 대해 생각하는 방법에 스며드는 것이 좋기 때문이다.

- 소프트웨어 프로세스는 이 책에 전반에서 여전히 기저가 되는 개념이다. 프로세스를 제어하기 위해 우리는 프로젝트에서 일어나고 있는 것을 측정할 수 있어야 한다. 따라서 척도들은 지속적으로 강조된다. 프로세스 개선에 관해 CMM(capability maturity model), ISO/IEC 15504(SPICE), ISO/IEC 12207이 계속 유지되고 있다.

- 이 교재는 여전히 언어에 독립적이다. 몇몇 코드 예제는 C++과 Java로 제시되지만 언어-의존을 바로 잡기 위해 모든 노력을 했고, 코드 예제는 C++과 Java 사용자들에게 동등하게 알아보기 쉽게 했다. 예를 들어 C++ 출력을 위해 cout을, Java 출력을 위해 system.out.println을 이용하는 대신, 의사코드 print 명령어를 이용한다(하나의 예외는 전과 같이 C++과 Java 모두로 주어진 완전한 구현 세부사항으로 새로운 사례 연구를 보여준다).

- 7판에서처럼 이 책은 600개 이상에 참고문헌을 포함한다. 가능한 고전적 문서보다는 메시지가 신선하고 관련 있는 상태인 최신 연구 논문이나 책들을 선택하였다. 소프트웨어 공학이 빠르게 이동하는 필드라는 것은 아무런 문제가 되지 않으며, 그러므로 학습자들은 그것들을 찾을 수 있는 문헌에서 얻을 수 있는 최신 결과를 알 필요가 있다. 동시에 오늘날 최첨단의 연구는 과거에 진실에 기반하고, 그것의 아이디어가 오늘날 적용가능하다면 오래된 참고문헌을 참조하는 것을 제외할 어떤 이유도 없다.

- 전제조건과 관련하여 독자가 C, C#, C++, Java와 같은 고수준 프로그래밍 언어에 정통하다고 가정된다. 추가로 독자는 데이터 구조들에 과정을 이수했다고 가정했다.



고전적 패러다임을 포함시킨 이유



이제 객체-지향 패러다임이 고전적 패러다임보다 우세하다는 것은 거의 모두가 인정했다. 그래서 7판에 객체-지향과 고전적 소프트웨어 공학을 적용한 많은 교습자들은 이 교재에 객체-지향 자료만을 가르치기를 선택한다. 하지만, 질문했을 때 교습자들은 그들이 고전적 패러다임을 포함하는 내용을 적용하는 것을 선호한다고 표현했다.



그 이유는 교습자가 단지 객체-지향 패러다임만을 가르친다고 해도, 그들이 학급에서 고전적인 패러다임을 아직도 참조하기 때문이다. 많은 객체-지향 기법들은 학생들이 객체-지향 기법이 유래된 고전적 기법의 몇몇 아이디어를 가지지 않고 그것을 이해하기가 어렵다. 예를 들어 엔티티-클래스 모델링을 이해하는 것은 엔티티-관계 모델링을 표면적으로나마 접한 학습자들에게 더 쉽다. 비슷하게 유한 상태 기계에 대한 소개를 알려주는 것은 상태차트들을 가르치는 교습자를 더 쉽게 해준다. 그래서 교습자들이 교육적인 목적으로 이용 가능한 고전적 내용들을 얻을 수 있도록 8판에도 고전적 내용들을 유지시켰다.



연습문제 구성



7판에서처럼 이 교재에는 5가지 형태의 연습문제들을 가지고 있다. 첫 번째는 11, 13, 14장의 후반부에 객체-지향 분석과 설계 프로젝트를 수행한다. 요구사항, 분석, 설계 워크플로를 배우는 유일한 방법이 광범위한 실제의 경험으로부터 왔기 때문에 이것이 포함시켰다.



두 번째는 각 장의 후반부에 핵심 포인트를 강조하는 것을 대상으로 하는 수많은 연습문제를 포함한다. 이 연습문제들은 독립적이다. 모든 연습문제를 위한 기술적인 정보는 이 교재 내에서 찾을 수 있다.



세 번째는 소프트웨어 기간 프로젝트이다. 표준 전화기 상에 상의할 수 없는 가장 작은 수에 팀 멤버들인 세 명에 학습자들이 해결할 수 있게 설계되었다. 기간 프로젝트는 각장에 크게 관련된 15개의 독립된 컴포넌트들로 구성되었다. 예를 들어 설계는 14장에 주제이고 그래서 그 장에서 기간 프로젝트의 컴포넌트는 소프트웨어 설계에 관계된다. 대규모 프로젝트를 아주 작고 잘 정의된 단위로 분할함으로써 교습자는 학급의 진척을 밀접하게 감시할 수 있다. 기간 프로젝트의 구조는 그 또는 그녀가 선택한 다른 어느 프로젝트에도 교습자가 15개의 컴포넌트들을 자유롭게 적용할 수 있도록 하는 것이다.



이 교재가 고학년에 대학생뿐만 아니라 대학원생이 사용하도록 집필되었기 때문에, 네 번째 유형의 문제는 소프트웨어 공학 학문에 대한 연구 논문들을 기반으로 한다. 각 장에서 중요한 논문이 선택되었다. 어디에나 가능하도록 객체-지향 소프트웨어 공학에 관련된 논문이 선택되었다. 학습자는 논문을 읽고 물으며 그것의 콘텐츠와 관련된 질문에 답변한다. 물론 교습자는 어떤 다른 연구 논문을 자유롭게 배정한다. 각 장에 후반부에 관련 자료는 다양한 관련된 논문들을 포함한다.



연습문제의 다섯 번째 형태는 사례 연구와 관련되어 있다. 이 문제 형태는 학습자들이 처음부터 새로운 프로덕트를 개발하는 것보다 현존하는 프로덕트를 수정하는 것에서 더 많이 배울 수 있다는 것을 인지한 수많은 교습자들에 대응하기 위해 3판에서 처음 소개되었다. 산업에서 많은 선임 소프트웨어 공학자들은 이런 관점에 동의하였다. 그래서 사례 연구가 제공된 각 장은 학습자들에게 사례 연구를 여러 가지 방법으로 수정하는 것을 요구하는 문제를 갖고 있다. 예를 들어 어떤 장에서 학습자는 사례 연구를 위해 이용되는 어떤 것과는 다른 설계 기법을 이용하는 사례 연구를 재설계하도록 요구받는다. 다른 장에서 학습자는 다른 방식으로 객체-지향 분석의 단계들을 수행함으로써 얻을 수 있는 효과가 무엇인지 요구받는다. 사례 연구의 소스 코드를 수정하기 쉽게 만들기 위해 www.mhhe.com/schach 웹을 이용할 수 있다.



또한 웹사이트는 강의 노트 파워포인트와 모든 연습문제와 기간 프로젝트에 대한 자세한 해결방안을 포함해서 교습자들을 위한 내용들이 있다.



UML에 대한 내용



본 교재는 UML(Unified modeling Language)을 지속적으로 사용하였다. 만약 학습자들이 UML에 대해 이전에 지식을 갖고 있지 않다면 이 내용은 두 가지 방법으로 가르쳐질 수 있다. UML을 적기 공급 기반으로 가르치기를 선호한다. 즉 각 UML 개념은 그것이 필요하기 이전에 소개되어야 한다.





마지막으로 나는 지속적으로 지원과 격려를 보내주는 아내 Sharon을 항상 생각한다. 나의 이전 모든 책들에서 나는 글을 쓰는 것에 앞서 가족들에 약속한 것에 보답하기 위해 최선을 다했다. 하지만 마감일이 닥칠 때 이것이 항상 가능하지는 않았다. 그런 시간들에 Sharon은 항상 이해하고 항상 최선을 다할 수 있도록 격려해 주었다.



나의 15번째 책을 나의 손자들인 Jackson과 Mikaela에게 바칠 수 있게 되어 영광이며, 사랑한다.



Stephen R. Schach





역자 머리말



소프트웨어 공학은 소프트웨어의 성패를 좌우하는 중요한 학문이 되었다. 즉 소프트웨어를 개발하는 개발자, 소프트웨어를 관리하는 관리자, 소프트웨어 프로젝트를 추진하는 CIO 등 관련된 모든 사람들에게 꼭 요구되는 학문 분야가 되었다. 특히 소프트웨어는 기업의 차별화 인자가 되었고, 산업 분야에 중요한 영향을 크게 미치는 주요 산업으로 자리 잡게 되어 경쟁력에 동력이 되고 있는 상태다. 그래서 소프트웨어도 다른 공학 분야처럼 방법론적인 접근이 필요하게 되었다. 즉, 이를 지원하는 소프트웨어 공학의 중요성이 날로 증가하고 있다. 그래서 소프트웨어의 품질은 더욱 차별화의 인자가 되고, 경쟁력의 원천이 되고, 글로벌에서 생존할 수 있는 근원이 된다.



그러나 현실은 그렇지 않다. 소프트웨어 공학이 갖고 있는 의미와 역할을 체계적으로 파악하지 못하는 경우가 많다. 그래서 프로젝트를 어떻게 계획하고, 클라이언트의 니즈를 어떻게 반영하고, 무슨 방법으로 개발하고, 설계하고, 테스트 하는지, 또 품질을 어떻게 보장하는지, 그리고 많은 비용이 소요되는 인도 후 유지보수는 어떻게 하는지를 몰라서 당황하는 사례가 너무 많다. 또 많은 비용을 투자해서 개발된 시스템은 왜 사용자를 충족시키지 못하는지? 또 개발에 투입된 자원은 적합하게 결정된 것인지? 이 모든 것을 관련자들은 어떻게 판정할 수 있는지? 이에 대한 지침들이 바로 소프트웨어 공학이다.



그래서 본 역자는 프로젝트 실무 관리에 대한 경험과 이전의 소프트웨어 공학 역서 등에서 획득한 경험을 바탕으로 최신의 소프트웨어 공학 책을 조사하던 중 본 역서를 선택하여 출간하게 되었다. 이 책의 원서는 2011년도 출간된 OBJECT-ORIENTED & CLASSICAL SOFTWARE ENGINEERING, 8판이다. 저자는 STEPHEN R, SCHACH이다. 저자의 서문을 보면 이 책의 특성과 전반적인 내용을 파악할 수 있다.



본 역서의 내용은 최신의 내용으로 구성되어 있으면서도 이론적이고 실무적인 내용이 크게 반영되어 있어 학부 및 대학원생, 실무진과 관심이 많은 관련 있는 분들에게 많은 도움을 줄 것으로 생각된다. 특히 최근 소프트웨어 공학의 추세와 이에 대응하는 내용들을 체계적으로 정리되어 있다. 특히 UML 중심이라 학습자에게 큰 도움을 줄 것으로 생각된다. 또한 학부나 대학원에서 교재로 사용할 때는 한 학기나 두 학기용으로 사용할 수 있으며, 프로젝트 중심으로 수업을 진행할 수 있어 학습자들에게 실무 기반으로 소프트웨어를 개발할 수 있게 해준다.



본 교재를 번역하면서 가능한 한 저자의 의도를 전달하려고 그림이나 표는 원어와 번역 내용에 보다 친숙하게 하기 위해 번역하지 않고 원문 그대로 기재하였다.



이 역서를 출간하는 데 많은 경험과 기회를 주신 나의 많은 지인들에게 진심으로 감사드립니다. 그리고 역서를 내면서 내 자신에 모든 것을 집중할 수 있게 해준 나의 가족에게도 진심으로 감사한 마음을 전합니다. 더욱이 이 책을 출간하는 데 헌신적으로 도움을 준 박해윤 선생과 윤광열 선생께 진심으로 감사를 드린다. 또한 한용만 원생과 이환 학생께도 감사의 마음을 전한다. 그리고 ITC 최규학 사장님 등 관계자 여러분께 진심으로 감사드린다.



유해영 단국대학교 교수

제1부 소프트웨어 공학 개요



제1장 소프트웨어 공학의 영역 001



1.1 역사적인 측면 4

1.2 경제적인 측면 6

1.3 유지보수 측면 7

1.3.1 유지보수의 고전적 그리고 현대적 견해 9

1.3.2 인도 후 유지보수의 중요성 11

1.4 요구사항, 분석, 설계 측면 13

1.5 팀 개발 측면 15

1.6 계획수립 페이즈가 없는 이유 16

1.7 테스팅 페이즈가 없는 이유 17

1.8 문서화 페이즈가 없는 이유 18

1.9 객체-지향 패러다임 19

1.10 객체-지향 패러다임의 전망 23

1.11 용어 24

1.12 윤리 이슈 28



제2장 소프트웨어 생명주기 모델 041



2.1 이론적 측면의 소프트웨어 개발 42

2.2 Winberg Mini Case Study 43

2.3 Winburg 미니 사례연구의 교훈 46

2.4 Teal Tractors Case Study 47

2.5 반복과 점진 48

2.6 Winburg Mini Case Study Revisited 51

2.7 반복과 점진의 위험과 또 다른 측면 53

2.8 반복과 점진 관리하기 56

2.9 다른 생명주기 모델 56

2.9.1 코드-픽스 생명주기 모델 56

2.9.2 폭포수 생명주기 모델 57

2.9.3 래피드 프로토타입핑 생명주기 모델 59

2.9.4 오픈-소스 생명주기 모델 60

2.9.5 Agile 프로세스 63

2.9.6 동기적-안정적 생명주기 모델 66

2.9.7 나선형 생명주기 모델 66

2.10 생명주기 모델들의 비교 70



제3장 소프트웨어 프로세스 079



3.1 Unified Process 82

3.2 객체-지향 패러다임에서 반복과 점진 82

3.3 요구사항 워크플로 84

3.4 분석 워크플로 85

3.5 설계 워크플로 88

3.6 구현 워크플로 89

3.7 테스트 워크플로 90

3.7.1 요구사항 산출물 90

3.7.2 분석 산출물 90

3.7.3 설계 산출물 91

3.7.4 구현 산출물 91

3.8 인도 후 유지보수 93

3.9 폐기 94

3.10 Unified Process의 페이즈 95

3.10.1 도입 페이즈 96

3.10.2 정련 페이즈 98

3.10.3 구축 페이즈 98

3.10.4 전이 페이즈 99

3.11 1차원 대 2차원 생명주기 모델 100

3.12 소프트웨어 프로세스 개선하기 101

3.13 CMM 102

3.14 다른 소프트웨어 프로세스 개선안 105

3.15 소프트웨어 프로세스 개선의 비용과 이익 106



제4장 팀 113



4.1 팀 조직 113

4.2 민주적 팀 접근법 115

4.2.1 민주적 팀 접근법의 분석 116

4.3 고전적 치프 프로그래머 팀 접근법 117

4.3.1 New York Times 프로젝트 119

4.3.2 고전적 치프 프로그래머 팀 접근법의 비실용성 120

4.4 치프 프로그래머와 민주적 팀 120

4.5 동기적-안정적 팀 122

4.6 Extreme Programming 팀 123

4.7 오픈-소스 프로그래밍 팀 125

4.8 P-CMM 126

4.9 적합한 팀 조직 선택하기 127



제5장 툴의 선택 131



5.1 단계적 정제 132

5.1.1 Stepwise Refinement Mini Case Study 132

5.2 비용-이익 분석 137

5.3 분할과 정복 139

5.4 관심의 분리 140

5.5 소프트웨어 척도 141

5.6 CASE 142

5.7 CASE의 전문용어 143

5.8 CASE의 범위 145

5.9 소프트웨어 버전 149

5.9.1 개정 150

5.9.2 변형 150

5.10 형상관리 151

5.10.1 인도 후 유지보수 동안 형상관리 153

5.10.2 기준선 154

5.10.3 개발 동안 형상관리 154

5.11 빌드 툴 155

5.12 CASE 기술로 취득한 생산성 156



제6장 테스팅 163



6.1 품질 이슈 164

6.1.1 소프트웨어 품질 보증 165

6.1.2 관리의 독립성 166

6.2 비실행 기반 테스팅 167

6.2.1 워크스루 167

6.2.2 워크스루 관리 167

6.2.3 인스펙션 169

6.2.4 인스펙션과 워크스루의 비교 171

6.2.5 검토의 강점과 약점 171

6.2.6 인스펙션용 척도 172

6.3 실행-기반 테스팅 172

6.4 테스트 대상은 무엇인가? 173

6.4.1 유용성 174

6.4.2 신뢰성 174

6.4.3 강건성 175

6.4.4 성능 175

6.4.5 정확성 176

6.5 테스팅 대 정확성 증명 177

6.5.1 정확성 증명의 예 178

6.5.2 Correctness Proof Mini Case Study 181

6.5.3 정확성 증명과 소프트웨어 공학 182

6.6 누가 실행-기반 테스팅을 수행하는가? 185

6.7 테스팅 종료 시기 187



제7장 모듈에서 객체까지 195



7.1 모듈이란 무엇인가? 196

7.2 응집도 199

7.2.1 우연적 응집도 200

7.2.2 논리적 응집도 200

7.2.3 시간 응집도 202

7.2.4 절차적 응집도 202

7.2.5 교환적 응집도 202

7.2.6 기능적 응집도 203

7.2.7 정보적 응집도 204

7.2.8 응집도 예제 204

7.3 결합도 205

7.3.1 내용 결합도 205

7.3.2 공통 결합도 206

7.3.3 제어 결합도 208

7.3.4 스템프 결합도 208

7.3.5 데이터 결합도 210

7.3.6 결합도 예제 210

7.3.7 결합도의 중요성 211

7.4 데이터 캡슐화 212

7.4.1 데이터 갭슐화와 프로덕트 개발 215

7.4.2 데이터 갭슐화와 유지보수 216

7.5 추상 데이터 타입 221

7.6 정보 은닉 222

7.7 객체 225

7.8 상속성, 다형성, 동적 바인딩 228

7.9 객체-지향 패러다임 231



제8장 재사용성과 이식성 239



8.1 재사용 개념 240

8.2 재사용에의 제약 242

8.3 재사용 사례연구 243

8.3.1 Raytheon Missile System Division 244

8.3.2 European Space Agency 245

8.4 객체와 재사용 246

8.5 설계와 구현 시 재사용 247

8.5.1 설계 재사용 247

8.5.2 애플리케이션 프레임워크 248

8.5.3 설계 패턴 249

8.5.4 소프트웨어 아키텍처 251

8.5.5 컴포넌트-기반 소프트웨어 공학 252

8.6 구체적인 설계 패턴 252

8.6.1 FLIC Mini Case Study 252

8.6.2 Adapter 설계 패턴 253

8.6.3 Bridge 설계 패턴 254

8.6.4 Iterator 설계 패턴 255

8.6.5 Abstract Factory 설계 패턴 257

8.7 설계 패턴의 부류 260

8.8 설계 패턴의 강점과 약점 261

8.9 재사용과 WWW(World Wide Web) 262

8.10 재사용과 인도 후 유지보수 262

8.11 이식성 264

8.11.1 하드웨어 비호환성 264

8.11.2 운영체제 비호환성 265

8.11.3 수치 소프트웨어 비호환성 266

8.11.4 컴파일러 비호환성 266

8.12 왜 이식성인가? 270

8.13 이식성을 달성하는 기법 271

8.13.1 이식 가능한 시스템 소프트웨어 271

8.13.2 이식가능한 애플리케이션 소프트웨어 271

8.13.3 이식가능한 데이터 273

8.13.4 Model-Driven Architecture 273



제9장 계획 수립과 추정 283



9.1 계획 수립과 소프트웨어 프로세스 284

9.2 기간과 비용 추정 286

9.2.1 프로덕트 사이즈에 대한 척도 287

9.2.2 비용 추정 기법 290

9.2.3 중간급 COCOMO 293

9.2.4 COCOMO II 296

9.2.5 기간과 비용 추정 추적 297

9.3 소프트웨어 프로젝트 관리의 컴포넌트 298

9.4 소프트웨어 프로젝트 관리 계획 프레임워크 300

9.5 IEEE SPMP 300

9.6 테스팅 계획 수립 304

9.7 객체-지향 프로젝트 계획 수립 305

9.8 요구사항 교육 306

9.9 문서화 표준 307

9.10 계획 수립과 추정용 CASE 툴 308

9.11 SPMP 테스팅 308



제2부 소프트웨어 생명주기의 워크플로



제10장 핵심 내용 317



10.1 소프트웨어 개발: 이론 대 실무 317

10.2 반복과 점진 319

10.3 Unified Process 322

10.4 워크플로 개요 323

10.5 팀 324

10.6 비용-이익 분석 325

10.7 척도 325

10.8 CASE 326

10.9 버전과 형상 326

10.10 테스팅 용어 327

10.11 실행 기반과 비실행 기반 테스팅 327

10.12 모듈성 328

10.13 재사용 328

10.14 소프트웨어 프로젝트 관리 계획 329



제11장 요구사항 331



11.1 클라이언트 니즈가 무엇인지 결정하기 332

11.2 요구사항 워크플로 개요 333

11.3 도메인 이해 334

11.4 비즈니스 모델 335

11.4.1 인터뷰 335

11.4.2 다른 기법 336

11.4.3 유스 케이스 337

11.5 초기 요구사항 338

11.6 도메인의 초기 이해: The MSG Foundation Case Study 339

11.7 초기 비즈니스 모델: The MSG Foundation Case Study 342

11.8 초기 요구사항: The MSG Foundation Case Study 346

11.9 요구사항 워크플로 계속하기: The MSG Fundation Case Study 347

11.10 요구사항 수정: The MSG Foundation Case Study 349

11.11 테스트 워크플로: The MSG Foundation Case Study 358

11.12 고전적 요구사항 페이즈 367

11.13 래피드 프로토타이핑 368

11.14 인적 인자 370

11.15 래피드 프로토타입핑의 재사용 372

11.16 요구사항 워크플로용 CASE 툴 373

11.17 요구사항 워크플로용 척도 374

11.18 요구사항 워크플로의 난제 374



제12장 고전적 분석 381



12.1 명세문서 382

12.2 비정형 명세 383

12.2.1 Correctness Proof Mini Case Study Redux 384

12.3 구조적 시스템 분석 385

12.3.1 Sally's Software Shop Mini Case Study 386

12.4 구조적 시스템 분석: The Osbert Oglesby Case Study 393

12.5 다른 반정형 기법 395

12.6 ERM 396

12.7 FSM 398

12.7.1 FSM: Elevator Problem Case Study 399

12.8 Petri Net 405

12.8.1 Petri Net: Elevator Problem Case Study 408

12.9 Z 410

12.9.1 Z: The Elevator Problem Case Study 411

12.9.2 Z의 분석 413

12.10 다른 정형 기법 415

12.11 고전적 분석 기법들 비교 416

12.12 고전적 분석 동안 테스팅 416

12.13 고전적 분석용 CASE 툴 418

12.14 고전적 분석용 척도 419

12.15 SPMP : Osbert Oglesby Case Study 419

12.16 고전적 분석의 난제 420



제13장 객체-지향 분석 429



13.1 분석 워크플로 430

13.2 엔티티 클래스들 추출법 432

13.3 객체-지향 분석: Elvator Problem Case Study 432

13.4 기능적 모델링: Elvator Problem Case Study 433

13.5 엔티티 클래스 모델링: Elevator Problem Case Study 435

13.5.1 명사 추출법 436

13.5.2 CRC 카드 438

13.6 동적 모델링: Elevator Problem Case Study 440

13.7 테스트 워크플로: Object-Oriented Analysis 443

13.8 경계와 컨트롤 클래스들 추출 450

13.9 초기 기능적 모델: The MSG Foundation Case Study 451

13.10 초기 클래스 다이어그램: The MSG Foundation Case Study 453

13.11 초기 동적 모델: The MSG Foundation Case Study 456

13.12 엔티티 클래스 개정하기: The MSG Foundation Case Study 458

13.13 경계 클래스 추출하기: The MSG Foundation Case Study 460

13.14 컨트롤 클래스 추출하기: The MSG Foundation Case Study 460

13.15 유스-케이스 실현: The MSG Foundation Case Study 461

13.15.1 Estimate Funds Available for Week 유스 케이스 462

13.15.2 Manage an Asset 유스 케이스 467

13.15.3 Update Estimated Annual Operating Expenses 유스 케이스 472

13.15.4 Produce a Report 유스 케이스 474

13.16 클래스 다이어그램 점진시키기: The MSG Foundation Case Study 479

13.17 테스트 워크플로: The MSG Foundation Case Study 481

13.18 Unified Process의 명세문서 481

13.19 액터와 유스 케이스 482

13.20 객체-지향 분석 워크플로용 CASE 툴 484

13.21 객체-지향 분석 워크플로를 위한 척도 484

13.22 객체-지향 분석 워크플로의 난제 485



제14장 설계 491



14.1 설계와 추상화 492

14.2 오퍼레이션-중심 설계 493

14.3 데이터 흐름 분석 493

14.3.1 Mini Case Study Word Counting 494

14.3.2 데이터 흐름 분석 확장안 499

14.4 트랜잭션 분석 500

14.5 데이터-중심 설계 501

14.6 객체-지향 설계 502

14.7 객체-지향 설계: Elvator Problem Case Study 503

14.8 객체-지향 설계: The MSG Foundation Case Study 506

14.9 설계 워크플로 511

14.10 테스트 워크플로: 설계 513

14.11 테스트 워크플로: The MSG Foundation Case Study 514

14.12 상세 설계용 정형 기법 514

14.13 실시간 설계 기법 515

14.14 설계용 CASE 툴 516

14.15 설계용 척도 517

14.16 설계 워크플로의 난제 518



제15장 구현 525



15.1 프로그래밍 언어 선택 526

15.2 4세대 언어 528

15.3 올바른 프로그래밍 관습 531

15.3.1 일관되고 의미 있는 변수 이름들 사용 531

15.3.2 자기 문서화 코드의 이슈 533

15.3.3 파라미터들 사용 534

15.3.4 가독성 증가를 위한 코드 배치 535

15.3.5 중첩 if 문 535

15.4 코딩 표준 537

15.5 코드 재사용 538

15.6 통합 538

15.6.1 하향식 통합 539

15.6.2 상향식 통합 541

15.6.3 샌드위치 구현과 통합 542

15.6.4 객체-지향 프로덕트들 통합 542

15.6.5 통합 관리 543

15.7 구현 워크플로 544

15.8 구현 워크플로: The MSG Foundation Case Study 544

15.9 테스트 워크플로: 구현 545

15.10 테스트 케이스 선택 545

15.10.1 명세 테스팅과 코드 테스팅 545

15.10.2 명세들에 대한 테스팅 타당성 546

15.10.3 코드에 대한 테스팅 타당성 547

15.11 블랙-박스 단위 테스팅 기법 550

15.11.1 동등 테스팅과 경계값 분석 550

15.11.2 기능 테스팅 551

15.12 블랙-박스 테스트 케이스: The MSG Foundation Case Study 552

15.13 글래스-박스 단위 테스팅 기법 555

15.13.1 구조적 테스팅 : 문, 분기, 경로 범위 555

15.13.2 복잡도 척도 556

15.14 코드 워크스루와 인스펙션 557

15.15 단위 테스팅 기법들 비교 558

15.16 Cleanroom 559

15.17 객체들 테스트 시 잠재적인 문제점 560

15.18 단위 테스팅 관리적 측면 562

15.19 코드 산출물을 디버깅하기보다는 재구축할 시기 563

15.20 통합 테스팅 565

15.21 프로덕트 테스팅 565

15.22 승인 테스팅 567

15.23 텍스트 워크플로: The MSG Foundation Case Study 568

15.24 구현용 CASE 툴 568

15.24.1 전체 소프트웨어 프로세스용 CASE 툴 568

15.24.2 통합 개발 environment 569

15.24.3 비즈니스 애플리케이션용 Environment 570

15.24.4 대중적인 툴 기반 구조 570

15.24.5 Environment들이 갖는 잠재적 문제점 571

15.25 구현 워크플로용 CASE 툴들 571

15.26 구현 워크플로용 척도 572

15.27 구현 워크플로 난제 573



제16장 인도 후 유지보수 583



16.1 개발과 유지보수 584

16.2 인도 후 유지보수 필요성 586

16.3 인도 후 유지보수 프로그래머들 요구는 무엇인가? 586

16.4 Postdelivery Maintenance Mini Case Study 589

16.5 인도 후 유지보수 관리 590

16.5.1 결점 보고 590

16.5.2 프로젝트에 대한 변경 권한 591

16.5.3 유지보수성 보장 592

16.5.4 반복되는 유지보수 문제 592

16.6 객체-지향 소프트웨어 유지보수 593

16.7 인도 후 유지보수 스킬 대 개발 스킬 596

16.8 역 공학 596

16.9 인도 후 유지보수 동안 테스팅 597

16.10 인도 후 유지보수용 CASE 툴 598

16.11 인도 후 유지보수용 척도 599

16.12 인도 후 유지보수: The MSG Foundation Case Study 599

16.13 인도 후 유지보수의 난제 600



제17장 UML의 세부 사항 607



17.1 UML은 방법론이 아니다 608

17.2 클래스 다이어그램 609

17.2.1 집합 610

17.2.2 다중성 610

17.2.3 합성 612

17.2.4 일반화 612

17.2.5 연관 613

17.3 노트 614

17.4 유스󰠂케이스 다이어그램 614

17.5 스테레오타입 615

17.6 상호작용 다이어그램 616

17.7 상태 차트 618

17.8 액티비티 다이어그램 621

17.9 패키지 623

17.10 컴포넌트 다이어그램 623

17.11 배치 다이어그램 624

17.12 UML 다이어그램 복습 624

17.13 UML과 반복 625



제18장 미래 신기술 629



18.1 관점-지향 기술 630

18.2 모델-중심 기술 632

18.3 컴포넌트-기반 기술 633

18.4 서비스-지향 기술 634

18.5 서비스-지향과 컴포넌트-기반 기술의 비교 634

18.6 소셜 컴퓨팅 636

18.7 웹 공학 636

18.8 클라우드 기술 638

18.9 웹 3.0 638

18.10 컴퓨터 보안 638

18.11 모델 체킹 639

18.12 현재와 미래 640



Appendix

{A} Term Project: Chocoholics Anonymous 643

{B} 소프트웨어 공학 자원들 647

{C} 요구사항 워크플로: The MSG Foundation Case Study 649

{D} 구조적 시스템 분석: The MSG Foundation Case Study 650

{E} 분석 워크플로: The MSG Foundation Case Study 653

{F} SPMP: The MSG Foundation Case Study 654

{G} 설계 워크플로: The MSG Foundation Case Study 659

{H} 구현 워크플로: The MSG Foundation Case Study(C++ 버전) 664

{I} 구현 워크플로: The MSG Foundation Case Study(Java 버전) 665

{J} 테스트 워크플로: The MSG Foundation Case Study 666

Stephen R. Schach