McConnell의 Code Complete, 2nd edition에서 추천하는 SW 공학 추천 도서

Software Project Survival Guide, Code Copmlete 등 실용적인 SW서적의 저자인 McConnell이 자신이 대표로 있는 Construx Softwrae사의 직원들에게 추천하는 도서 목록. 최신 도서는 빠져있지만 SW공학 관련 좋은 책들이 많이 포함되어 있습니다.

A Software Developer’s Reading Plan

Introductory Level

n   Adams, James L. Conceptual Blockbusting: A Guide to Better Ideas, 4th ed. Cambridge, Mass.: Perseus Publishing.

n   Bentley, Jon. Programming Pearls, 2d Ed. Reading, Mass.: Addison-Wesley, 2000.

n   Glass, Robert L. Facts and Fallacies of Software Engineering, Boston, Mass. Addison Wesley, 2003.

n   McConnell, Steve. Software Project Survival Guide. Redmond, WA: Microsoft Press, 1998.

n   McConnell, Steve. Code Complete, 2d Ed.. Redmond, WA: Microsoft Press, 2004.

Practitioner Level

n   Berczuk, Stephen P. and Brad Appleton. Software Configuration Management Patterns: Effective Teamwork, Practical Integration, Boston, Mass.: Addison Wesley, 2003.

n   Fowler, Martin. UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3d Ed, Boston, Mass.: Addison Wesley, 2003.

n   Glass, Robert L. Software Creativity, Reading, Mass.: Addison Wesley, 1995.

n   Kaner, Cem, Jack Falk, Hung Q. Nguyen. Testing Computer Software, 2d Ed., New York: John Wiley & Sons, 1999.

n   Larman, Craig. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process, 2d Ed., Englewood Cliffs, N.J. Prentice Hall, 2001.

n   McConnell, Steve. Rapid Development. Redmond, WA: Microsoft Press, 1996.

n   Wiegers, Karl. Software Requirements, 2d Ed. Redmond, WA: Microsoft Press, 2003.

n   “Manager’s Handbook for Software Development”, NASA Goddard Space  Flight Center. Downloadable from sel.gsfc.nasa.gov/website/documents/online244doc.htm.

Professional Level

n   Bass, Len, Paul Clements, and Rick Kazman. Software Architecture in Practice, Third Edition, Boston, Mass.: Addison Wesley, 2012.

n   Fowler, Martin. Refactoring: Improving the Design of Existing Code, Reading, Mass.: Addison Wesley, 1999.

n   Gamma, Erich, et al. Design Patterns, Reading, Mass.: Addison Wesley, 1995.

n   Gilb, Tom. Principles of Software Engineering Management. Wokingham, England: Addison-Wesley.

n   Maguire, Steve. Writing Solid Code. Redmond, WA: Microsoft Press, 1993.

n   Meyer, Bertrand. Object-Oriented Software Construction, 2d Ed. New York, Prentice Hall PTR, 1997.

n   “Software Measurement Guidebook”, NASA Goddard Space Flight Center, Available from sel.gsfc.nasa.gov/website/documents/online-doc.htm.

거세정진 (去勢精進)

밴드에 올라온 글인데 SW 산업에 종사하면서 자주 느꼈던 사항이라 동감하면서 옮깁니다.

♥♥
한자를 그대로 해석하면 "남자의 생식기를 제거하고 어떤일에 힘써 나아간다" 는 뜻이 된다.

옛날 명나라때
무림의 최고수에 등극을 하고자하는 자가 있었는데, 무술을 연마하여 대회만 나가면 늘 준우승만 하기를 수차례 하였다.

아무리 노력해도 지존의 자리에 오르지 못하게되자 유명한 도인을 찾아가 방법을 물었다. 그 도인이 무예에 관한 비서(秘書)를 한권 주었는데, 거기에는 36가지의 무예에 관한 수련법이 적혀있었고,

책의 마지막 장에는
이러한 기술들을 반드시 거세정진(去勢精進) 하여야 최고수의 자리에 오를수 있다고 적혀있었다.

그 자는 고민에 빠졌다.

무림의 고수에 등극하는 것이 평생의 소원이지만,  거세까지 해가면서 정진한다는 것은 받아들이기가 어려웠다. 그러나 워낙 지존에 대한 열망이 강했던지라 스스로 거세를 하고 무예를 연마하였다.

이듬 해
그 자는 드디어 연마한 무예로 무림의 최고수에 등극하였다.

그러나,
시간이 지나면서 지존의 자리가 덧없고, 거세에 대한 후회가 밀려와 견딜 수가 없었다. 그리하여, 그 비서를 준 도인을 다시 찾아가 물었다.

"왜 그런 기술들은 꼭 거세정진하여야만 무림의 지존이 될수있었나요?"

그 도인이 말하기를, "사실 나는 그 책의 저자가 아니고 번역만 했다. 원저자는 조선이라는 나라에 있으니 꼭 알고 싶으면 그 사람에게 물어보시오"라고 하였다

물어물어 조선의 태백산 중에 수련중이던 원저자를 찾아갔다.

자초지종을 이야기하니, 자기도 젊었을 때 쓴 책이라 기억이 아삼삼하다며 다락에서 먼지묻은 원서를 찾아 들고왔다. 그 책은 한글로 쓰였을 뿐, 자신이 연마한 바로 그 책이었다.

책의 마지막에는 이렇게 적혀있었다. "이러한 기술들을 반드시 불알이 빠질 정도로 연마해야만 최고수의 자리에 오를수 있다"고 적혀있었다.

거세정진(去勢精進)의 원서 표현은 "뭐 빠지게 노력하라" 였다.
* *
이 글이 주는 교훈이 두 가지다.

첫째, 공부는 돈이 좀 들더라도 반드시 원서를 사서 하라는 것이다.
    
둘째, 책을 번역할 때 그나라 말에 적절한 표현이 없을 때는 함부로 의역(意譯)하지 말고, 혹시라도 의역(意譯)을 했을 경우는 각주(脚註)-footnote 반드시 달아 원서의 표현을 그대로 적어야 한다는 것이다.

●○●

프로젝트에서 Software Architect의 역할

KOSTA Software Architecture Conference에서 발표한 자료입니다.
software architectur란? software architecture process, software architecture 요구사항, software architect의 역할과 역량 4개 영역으로 구성되어 있습니다. PDF 파일은 아래 shareslide URL에 있습니다.


http://www.slideshare.net/yokim31/sw-20140717?qid=03ccdc69-4db9-4a9c-bbce-9a1c2e8f2bca&v=qf1&b=&from_search=5

What is Software architecture?

What is Software architecture?

•일반적으로 SW 아키텍처는

üSW 시스템의 성공을 위해서 매우 중요하다

üSW 아키텍처에 대한 충분한 일반화된 지식 체계가 있다.

•SW 아키텍처 정의

ü시스템의 SW아키텍처는 SW요소와 요소간의 관계 그리고 각각의 속성으로 구성된 시스템에 필요한 구조의 집합이다.

ü아키텍처는 SW 구조의 집합이다. SW시스템은 많은 구조로 이루어지고, 단일 구조는 아키텍처가 아니다.

–Module view

–Component and connector view

–Allocation view

ü아키텍처는 추상화이다.

ü모든 SW 시스템은 SW아키텍처를 가지고 있다.

ü아키텍처는 행위를 포함한다.

ü모든 아키텍처가 좋은 아키텍처는 아니다.

SW 아키텍처 수립의 주요 활동

1.시스템 타당성 수립
(Making a business case for the system)

2.중요한 아키텍처 요구사항 이해
(Understanding the architecturally significant requirements)

3.아키텍처 생성 또는 선택
(Creating or selecting the architecture)

4.아키텍처 문서화와 의사소통
(Documenting and communicating the architecture)

5.아키텍처 분석 또는 평가
(Analyzing or evaluating the architecture)

6.아키텍처 기반 시스템 구축과 테스트
(Implementing and testing the system based on the architecture)

7.아키텍처에 따라 구축되었는지 확인
(Ensuring that the implementation conforms to the architecture)

Enterprise Architecture Method and EA architecture category 

Enterprise Architecture와 SW 아키텍처의 관계

Software Architecture Framework (SW architecture in practice, 3rd edition)

Architecture Influence Cycle

Quality attributes

 

Tradeoffs among quality attributes

S/W 공학 변천사

COCOMO 모델을 개발한 Barry Boehm이 ICSE 2006 in Shanghai에서 Keynote Speech에서 발표한 "A View of 20th and 21st Century Software Engineering" 논문과 PPT자료의 URL입니다.

저자의 1950년대부터 경험을 토대로 SW공학 변천사를 10년단위로 정리한 본 자료는 SW공학에 대한 이해에 매우 유용한 자료입니다. 개인적으로 많은 것을 느끼고 배우게 해주었던 자료입니다. 영문 원본 일독을 강추합니다. 번역본은 NIPA SW공학센터 "SW공학백서 2013"에서 부분적으로 이용 가능합니다.

KOSTA 교육 과정 "프로젝트에서 배우는 SW 공학 베스트 프랙티스"에서 상세한 내용은 제가 강의를 통하여 설명합니다.

논문은
   http://csse.usc.edu/csse/TECHRPTS/2006/usccsse2006-626/usccsse2006-626.pdf

Powerpoint 파일은
    http://isr.uci.edu/icse-06/program/keynotes/boehm.html

S/W 프로젝트 현황은?

짧은 납기, 적은 인원, 많고/변하고/불분명한 요구사항

그런데 프로젝트 현황은?

§프로젝트 성공 여부

ü성공 39%, 도전 43%, 실패 18% (Standish Group 2012)

ü성공 41% (NIPA 2012)

§품질 비용

ü피할 수 있는 재작업 비용  40 ~ 50% (Barry Boehm)

ü재작업 비용 46.3%  (NIPA 2012)

–내부 실패 27.2%, 외부 실패 19.1%

§문제 프로젝트 현황 (Standish Group 2012)

ü계획 기능 제공 비율 69%

ü기간 초과율 74%

ü비용 초과율 59%

§기능 사용 현황

üStandish Group

–자주 사용 20%, 거의 사용 안함 30%, 사용 안함 50%

ü2e 컨설팅

–화면 자주 사용 35.8%, 19.7% 거의 사용 안함, 사용 안함 44.5%

S/W 프로젝트에 대해 경구

§과거를 기억하지 못하는 사람은 그 것을 되풀이 한다. – George Santayana

§처음부터 제대로 하지 않으면 결함을 찾고, 고치는데 더 많은 시간을 보내야 한다. – Philip B. Crosby

§일을 처음부터 제대로 할 충분한 시간은 없으나, 나중에 다시 작업할 시간은 항상 충분히 있다. – Ed. Deming

§개발한 기능의 50%는 사용하지 않으며, 30%는 거의 사용하지 않는다. - Standish Group, 2010

§도전적인 SW 개발 프로젝트에서 제안 기능의 제공 비율은 64% ~ 70% 수준이다. – Standish Group

§피할 수 있는 결함을 고치기 위한 재작업에 프로젝트 공수의 40% ~ 50%를 사용한다. – Barry Boehm

§동일한 사람이 프로젝트를 수행해서 항상 같은 시스템을 성공적으로 만드는 작은 회사가 있으나, 매번 다른 사람이 프로젝트를 수행해서 매번 같은 시스템을 제대로 만들지 못하는 큰 회사가도 있다. – NASA 퇴직 PM

§소프트웨어 연구에서 소프트웨어공학은 14%, 컴퓨터공학은 11%, 정보시스템은 67%를 실제로 평가하고, 나머지는 옹호한다. 옹호된 개념은 옹호자가 믿는 것보다 대부분 가치가 낮다. – Robert L. Glass

ü벤더와 실무자에 국한되는 것이 아니고, 학문적인 연구도 마찬가지다.

§100% 소프트웨어 결함을 제거할 수 있는 방법은 없다. _ Capers Jones

ü미국 산업 평균 결함 제거 효율은 85%이며 기능점수 당 0.75개의 결함이 운영에 이관된다.

ü결함 제거 효율을 95%까지 높이면 운영이관 결함을 기능점수 당 0.08개로 줄일 수 있다.

§완벽한 테스팅은 불가능하다. – ISTQB

ü사소한 경우를 제외하고는 모든 입력 변수와 선행 조건의 조합 값을 고려한 전수 테스트는 불가능하다. 완벽한 테스팅 대신, 위험과 우선순위를 고려하여 테스팅 노력을 집중한다.

§100% 테스트 커버리지가 가능하더라도 그것은 충분한 테스팅 기준이 아니다. - Robert L. Glass

ü약 35%의 오류는 누락된 로직 때문에, 40%는 새로운 로직 경로 때문에 발생하는데, 이것은 100% 커버리지에 포함되지 않는다.

품질은 공짜다 (Quality is Free) [Crosby 1980]

품질은 공짜다.

§  의미는?

ü  품질 프로그램은 품질 이행 비용보다 많은 돈을 절감할 수 있다.

ü  수익성은 높은 품질 비용 절감과 결함 예방을 통하여 이루어 진다.

ü  품질비용은 예방, 평가, 실패 비용을 포함한다.

§  처음부터 물건을 제대로 만들어서, 결함 수리 비용을 발생시키지 말고 또는 다시 만들지 않는다. “Do things right in the first place, and you won't have to pay to fix them or do them over.”

품질에 대한 잘못된 가정

§  품질은 멋 부리는 그냥 좋은 것이다.

à 품질은 요구사항을 만족시키는 것이다.

§  품질은 측정할 수 없고, 만질 수 없다.

à 품질은 요구사항을 만족시키지 못해서 발생하는 비용이다.

§  품질은 우리 조직에 적절하지 않다. 우리 조직은 다르다.

à 처음부터 잘 만드는 것이 더 싸다 “Do things right the first time.”.

§  품질문제는 사용자 때문에 발생한다.

à 대부분의 문제는 계획과 개발 단계에서 발생한다.

§  품질은 품질 조직의 일이다.

à 품질은 모든 부서가 같이 참여하여 진행하는 모두의 일이다.

품질관리 성숙도 그리드

크로스비의 품질관리 성숙도 그리드는 조직의 품질 성숙도를 평가하는 기준을 제공하였고, CMM역량 성숙도 모델의 기반이 되었다. 회사 차원의 품질관리 성숙도를 제대로 파악하는 것이 품질 활동의 출발점이다. 인도 시스템 통합 사업자처럼 사업의 핵심역량으로서 품질관리를 자리매김하는 것이 국내 S/W산업의 글로벌화의 출발점이 아닐까?.

표 5: 품질관리 성숙도 그리드 (page 32 ~ 33)

유형	1단계: 불확실	2단계: 인식	3단계: 계몽	4단계: 지혜	5단계: 확실
경영진 이해 및 태도	품질 이해 부족. 품질문제 품질조직 질책	품질이 필요 인식, 투자 실행 말설임	품질관리 이해, 지원하고, 도움됨	참여. 품질관리 제대로 이해, 개인역할 인식	품질관리 회사 시스템 핵심 영역
품질 조직	품질은 프로젝트의 문제. 조직적인 인스펙션 없음. 평가 강조	강력한 품질관리자 임명, 평가와 제품 위주, 프로젝트의 일임	품질부서가 최고경영진에 보고. 모든 평가 취합, 품질리더 경영진 포함	품질관리자가 회사의 대표자. 효과적인 현황 보고 및 예방 활동 수행	품질관리자 이사회 멤버, 예방이 주요 관심사, 품질이 Thought 리더
문제 해결	문제발생 해결. 답 없고, 대처 부적절, 시끄럽고, 책임 전가	주요 문제해결을 위한 팀 구성 장기적인 솔루션 파악 안됨	개선활동 의사소통 체계 구축, 문제 공유, 순차적 해결	문제 개발 초기 파악. 제안과 개선 활성화	아주 예외적인 경우를 제외하고 결함 예방
매출대비 품질 비용	보고: 없음 실제: 20%	보고: 3% 실제: 18%	보고: 8% 실제: 12%	보고: 6.5% 실제: 8%	보고: 2.5% 실제: 2.5%
품질 개선 활동	조직적 활동 없음 활동에 대한 이해 못함	단기적인 품질 활동	정확한 이해와 확정에 의한 다단계 프로세스 이행	지속적인 다단계 프로세스 적용 적극적, 예방적인 품질 활동	일상적이며, 지속적인 품질 활동
회사 품질 현황	품질 문제 이해 못한다.	품질관리가 정말로 필요한가?	경영진 지원 하에 문제 파악,  해결	결함 예방이 일상적인 활동임	품질 문제가 왜 없는지를 안다

프로그램 개발자에 대한 50가지 진리 [출처미상]

인터넷에서 발견한 자료이다. 원 저자가 누구인지는 모르지만, 아마 열악한 프로젝트에서 좌절한 개발자가 정리하지 않았을까 추정한다. PMO, QA, 아키텍처 인력이 확보되지 않거나, 제대로 역할을 못하는 프로젝트에 속한 개발자라면 대부분 공감할 수 있는 내용이다. 누구의 탓이라고 해야 하나 다 같이 곰곰히 생각해 보아야 하지 않을까 생각해서 첨부한다.

1.     "오늘까지"라는 말은 "내일 아침까지"라는 말이다.

2.     프로그램은 내가 원하는 대로 움직이지 않는다. 타이핑한대로 움직인다.

3.     요구 사양은 프로그램을 완성한 후에 추가된다. 기본 사양은 완성품을 고객이 보고 나서 결정된다. 상세 사양은 사용자가 프로그램을 사용해 본 이후에 결정된다.

4.     소프트웨어 설계에는 두 개의 방법이 있다. 하나는 결함이 있을 수 없을 정도로 단순하게 만드는 방법이다. 다른 하나는, 분명한 결함을 눈치채기 어려울 정도로 복잡하게 만드는 방법이다.

5.     코드는 개발 현장에서 사용하는 것이 아니라 납품처에서 사용하는 것이다. 디버그는 납기일까지 하는 것이 아니라, 납품된 이후에 하는 것이다.

6.     프로그래머를 죽이기 위해서는 칼이 필요 없다. 프로그램의 요구조건을 3번만 바꾸면 된다.

7.     다른 사람을 믿으라. 그 사람이 해결해줄지도 모른다. 주의사항 - 먼저 자신을 의심해라.

8.     개발에 마지막은 없다. 출시만이 있을 뿐이다.

9.     클라이언트의 요구사항이 제 아무리 뒤늦게 추가되어도 납기일은 변하지 않는다. 이것을「납기 불변의 법칙」이라고 한다.

10.   우리의 고객들은 물과 기능추가를 공짜라고 생각하고 있다.

11.   주머니가 짠 고객일수록 잔소리가 많다.

12.   개발 스케줄은 산수를 무시하고 짜여진다. 영업은 1＋1 = 2 를 이해하지 못하는 사람의 모임이다.

13.   한 명이 쓰러지면 모두가 쓰러진다.

14.   버그가 너무 심하다? 걱정 마라. 어느 순간 그것은 기본 사양이 될 것이다.

15.   좋은 설계는 한 명의 천재보다 세 명의 범재를 요구한다. 나쁜 설계는 백 명의 범재보다 한 명의 천재를 요구한다.

16.   고객에게 시스템 엔지니어는 부하이며, 프로그래머는 가축이다. 시스템 엔지니어에게 고객은 돈이다. 프로그래머에게 고객은 보이지 않는 악성 바이러스다.

17.   돈과 시간만 있으면, 그 어떤 시스템이라도 만들 수 있다고 생각하는가? 웃어라. 그 기회는 영원히 주어지지 않는다.

18.   품질은 사양 변경의 수와 규모에 의해, 얼마나 악화될지 결정된다.

19.   영업은 공상이 실현된다고 생각하는 몽상가이다. 시스템 엔지니어는 넘을 수 없는 벽이 없다고 믿는 모험가이다. 프로그래머는 몽상가와 모험가에 의해 칠흑의 바다에 내던져진 표류자이다.

20.   유능한 프로그래머가 프로그램 설계개념도를 받아 들고 최초로 하는 일은, 프로그램의 목적을 이해하는 것이다. 그리고 그 다음으로 하는 일은, 지정된 방법과 시간 안에는 도저히 그 목적을 완수할 수 없다는 사실을 시스템 엔지니어에게 이해시키는 일이다.

21.   프로그램이란, 운과 감에 의해서 작성되는 기적이다. 운과 감이 없다면, 그 기간 내에 그러한 목표를 실현될 수 있을 리 없다. 따라서 사양 변경은 기적에 트집을 잡는 건방진 행위이며, 사양 추가는 기적이 두 번 일어날 것으로 믿는 무모한 행위이다.

22.   시스템 엔지니어는 지구력, 프로그래머는 순발력.

23.   정시에 퇴근하면, 일이 늘어난다.

24.   완벽한 프로그램은 무한한 시간과 돈을 필요로 한다. 미국의 국가 예산을 무제한으로 사용하는 NASA마저도, 아직 시간과 돈이 부족하다고 한다.

25.   눈으로 훑어볼 틈이 있다면 움직여라. 뇌세포보다 CPU가 더 해석이 빠르다. 그리고, 그 사이, 쉴 수 있다.

26.   불편함을 버그라고 부를 것인가, 사양 상의 제한 사항이라고 부를 것인가는 남겨진 개발일자와 납기일에 의해 결정된다.

27.   정장 대신 캐쥬얼을 입고 출근하는 "캐쥬얼 데이"를 세간에서는 휴일이나 공휴일이라고 부르는 것 같다.

28.   프로그램은 머리로 기억하지 않는다. 몸으로 기억한다.

29.   내일 쉴 수 있다면 오늘 죽어도 괜찮다.

30.   고객은 거짓말을 한다. 영업은 꿈을 말한다. 시스템 엔지니어는 공상을 이야기한다. 프로그래머는 과묵해진다. (혼잣말이 많아진다)

31.   「네, 할 수 있습니다」라고 말하기 전에 10초만 곰곰이 다시 생각해보라.

32.   프로그래머는 1분 생각하고 1일을 코딩에 소비한다. 1시간 생각하고 1시간 코딩하는 대신에 말이다.

33.   납품 이후의 디버그는 버그를 부른다.

34.   세 개의 디버그는 하나의 버그를 낳는다. 이것을 버그의 끝없는 반복 (endless loop) 라고 한다.

35.   안 좋은 예감은 반드시 적중한다. 그러나 프로그래머는 그 안 좋은 예감에 반응하지 않는다. 그것은 시스템 엔지니어의 일이다.

36.   아수라장을 해결할 수 있는 방법은 오직, 고객이 돈을 지불하는 것 뿐이다.

37.   아마추어는 버그발견의 천재이다.

38.   아, 그건 마이크로소프트에서만 가능한 주문입니다.

39.   프로그래머가 불만이라고 생각하는 부분은 고객도 반드시 불만이라고 생각한다.

40.   건강하기 때문에, 건강을 해친다.

41.   그건, 당신이 말한 요구조건입니다만.

42.   아, 개발실의 창문은 안 열립니다. 그 이유는 옛날에 한 프로그래머가 그 창문에서···

43.   고객은 최악의 사태를 믿지 않으며, 그 사태에 대한 준비를 악질적인 비용청구라고 생각한다. 시스템 엔지니어는 최악의 사태를 대비하고 준비하려 한다. 프로그래머는 최악의 사태를 누구보다 잘 예상하지만, 무시한다.

44.   만약 다른 직업을 갖게 된다면, 정시퇴근을 「도망」이라고 부르지 않는 직업이 좋을 것 같다.

45.   시스템 엔지니어가 프로그래머에게 말하는「상식」은 3시간마다 변한다.

46.   최소한 자기가 쓴 시방서는 읽어주세요.

47.   고객이 시스템 엔지니어에게 사랑받는 방법은, 시스템 개발에는 시간이 곧 돈이라는 사실을 깨닫고 빨리 최종 요구조건을 확정하는 것이다. SE (system engineer)가 고객에게 사랑받는 방법은, 프로그래머에게 미움받는 것이다.

48.   납기일이란, 작업 현장이 우리 회사에서 고객의 회사로 바뀌는 날을 의미한다.

49.   가끔 일어나는 버그는 버그가 아니다. 스펙이다.

50.   개발비의 30%는 프로그램의 요구조건을 확정하는데 사용된다. 개발비의 30%는 프로그램의 요구조건을 변경하는데 사용된다. 개발비의 30%는 프로그램의 버그를 잡는데 사용된다. 개발비의 10%만이 프로그램의 개발에 사용된다.