추가 적립 안내

개발자가 알아야 할 개발 방법론과 생산성 관리 전략부터 객체지향적 디자인의 요구사항과 시스템 문서화에 이르는 방대한 내용을 알기 쉽게 설명한다. 개발자가 프로젝트 팀원으로서 알아야 할 문서화 작업 방법과 문서 간의 일관성 유지 기법, 소프트웨어 엔지니어링 디자인 문서라고 할 수 있는 UML 요구사항 작성 방법, IEEE 표준안 기반의 소프트웨어 품질 관리 방법을 다양한 예시와 사례로 알기 쉽게 설명한다.

★ 이 책에서 다루는 내용 ★

■ 소프트웨어 장인 정신 모델을 통한 업무 능률 개선의 필요성
■ 문서화 작업에서 문서 간의 일관성을 유지하기 위한 추적 기능 사용 방법
■ 유스 케이스 분석에 따른 UML 요구사항 작성 방법
■ IEEE 문서화 표준안 기반의 소프트웨어 품질 관리 방법


★ 이 책의 대상 독자 ★

C, C++, C#, 스위프트(Swift), 파스칼(Pascal), BASIC, 자바(Java), 어셈블리어 등 하나 이상의 절차적 프로그래밍 언어 또는 객체지향 프로그래밍 언어를 이해할 수 있다고 가정한다. 또한 소프트웨어 솔루션 디자인 및 구현 과정에 발생하는 문제를 구체화할 수 있다고 가정한다. 단과대학(기술 전문대학) 또는 일반 대학에서 컴퓨터 과학을 전공하거나 1학기 이상의 관련 과정을 이수했다면 읽는 데 큰 어려움은 없을 것이다.
독자가 컴퓨터 구조(machine organization)와 데이터 표현 방식(data representation)에 대한 기본적인 이해를 갖추고 있을 것으로 가정한다.


★ 지은이의 말 ★

소프트웨어 엔지니어링 개념이 정착되기 전까지 소프트웨어 개발은 쉽게 설명할 수 없는 역량과 성취물을 가진 소수의 소프트웨어 기술 장인을 통해 은밀하게 전해지는 것으로 생각됐다. 그 당시에는 소프트웨어 프로젝트의 성공 여부가 팀이 아닌 탁월한 수준의 핵심 프로그래머 한두 명에게 달려 있었다. 이후 도입된 소프트웨어 엔지니어링 개념 모델은 개발 팀의 균형 잡힌 역량을 확보해 생산성을 높이고, 탁월한 소수의 개발자에 대한 의존도를 낮췄다.
소프트웨어 엔지니어링 개념 모델은 나름의 성공을 거뒀다. 팀 단위로 구성된 프로그래머는 과거 소규모 조직 단위로는 결코 완수하지 못할 대규모 프로젝트를 성공적으로 해내기도 하지만, 일부 중요한 요소의 품질은 기대에 미치지 못하고 있다. 소프트웨어 엔지니어링은 팀 단위 운영을 통한 생산성 증대를 강조하지만, 동시에 개별 프로그래머의 창의성, 기술력, 성장성이 희생되고 있다. 소프트웨어 엔지니어링이 프로그래머의 역량을 높여주는 측면도 있지만, 한편으로는 위대한 프로그래머가 될 수 있는 기회를 줄이거나 역량을 제한하기도 한다. 우리 모두는 프로그래머가 자신의 잠재력을 최대한으로 발휘하길 원하지만 소프트웨어 엔지니어링의 엄격한 규칙은 잠재력을 발휘하려는 의지와 상충될 수 있다.
‘Great Code’ 시리즈는 소프트웨어 엔지니어링의 시대에 프로그래머의 창의성, 기술력, 성장성을 회복하기 위한 작은 노력의 산물이다. 이 책에서는 이를 ‘퍼스널 소프트웨어 엔지니어링(personal software engineering)’이라는 주제로 다루며, 한 명의 프로그래머가 자신의 코드 품질을 개선해 나갈 수 있는 방법을 제시한다. 특히 ‘위대한 코드(great code, 유지 보수, 기능 강화, 테스트 및 디버깅, 문서화, 배포 및 삭제가 용이한 코드)’를 작성하기 위한 방법을 소개한다. 위대한 코드는 엔지니어 또는 관리 체계의 비합리적인 결정이나 잘못된 계획에서 비롯되는 ‘결함(kludge)’이 없는 코드를 의미하기도 한다. 위대한 코드는 한마디로 코드 작성자 본인이 자랑스러워할 수 있는 코드다.


★ 옮긴이의 말 ★

이 책은 무려 40여 년 전에 (원자로 제어용) 소프트웨어 개발자로 일을 시작한 랜달 하이드의 위대한 코드 작성을 위한 세 번째 책이며, 지난 40여 년간 소프트웨어 개발 산업에 존재해온 방법론, 전략, 실무이론, 체계의 집대성이라 할 수 있다. 저자는 Great Code 시리즈 1, 2권을 통해 하드웨어와의 효과적인 소통 방법과 로우레벨로 생각하고 하이레벨로 코딩하는 방법을 소개했고, 3권에서 엔지니어링 대상으로서 소프트웨어를 설명한다.
소프트웨어 개발 업무를 작가주의의 산물이 아닌 엔지니어링 측면에서 접근해 정성적으로 공감에 기대어 설명할 수밖에 없었던 부분을 체계적으로 설명할 수 있도록 소프트웨어 개발 모델부터 테스트, 문서화까지 일관된 예시와 흐름으로 설명한다.
저자 랜달 하이드의 시대에 각광받던 개발 주제(이를 테면 원자로 제어)는 현시점에서 클라우드, 인공지능, 양자 컴퓨팅, 블록체인 등의 주제로 바뀌었고 개발 접근 전략 또는 방법론 또한 좀 더 세분화되거나 맥락이 아예 바뀌게 된 부분도 있다. 하지만 좀 더 좋은 소프트웨어, 위대한 소프트웨어에 대한 갈망은 개발자 모두의 생각일 것이다.
이 책은 소프트웨어 개발이 좋아서 무작정 일을 시작한 사람이 어느 날 문득 소프트웨어라는 산업 전체를 둘러보고, 지난 수십 년간 존재해온 개발 담론을 확인하며 앞으로 수 년간 개발자로서 자신의 경력을 어떤 방식으로 관리할 것인지 계획을 세우고 싶을 때 읽기 좋은 책이 아닐까 생각한다. 이런 독자들에게 저자는 소프트웨어 개발 방법론은 물론, 프로젝트 팀의 효율적인 운영 방안, 프로젝트가 산으로 가는 목표를 벗어나는 이유 그리고 일일 업무 수행 방법까지 꼼꼼히 설명한다.
작년에 수행한 프로젝트보다 좀 더 나은 프로젝트 수행 방법을 고민하는 개발자에게도 추천한다.

1부 퍼스널 소프트웨어 엔지니어링

1장 소프트웨어 개발에 대한 은유법
1.1 소프트웨어란 무엇인가?
1.1.1 소프트웨어는 대량 생산되는 공산품이 아니다
1.1.2 소프트웨어는 아무리 써도 닳지 않는다
1.1.3 대부분의 소프트웨어는 커스텀 제품이다
1.1.4 소프트웨어는 쉽게 업그레이드할 수 있어야 한다
1.1.5 소프트웨어는 독립적으로 존재하지 않는다
1.2 다른 전문 영역과의 비교
1.2.1 예술가의 프로그래머
1.2.2 건축가로서의 프로그래머
1.2.3 엔지니어로서의 프로그래머
1.2.4 기술 장인으로서의 프로그래머
1.2.5 여러분은 예술가, 건축가, 엔지니어, 기술 장인 중 어느 쪽에 가까운가?
1.3 소프트웨어 엔지니어링
1.3.1 소프트웨어 엔지니어링에 대한 공식적 정의
1.3.2 프로젝트의 크기
1.3.3 소프트웨어 엔지니어링은 어떻게 실패하는가?
1.4 소프트웨어 장인 정신
1.4.1 교육
1.4.2 도제식 훈련
1.4.3 소프트웨어 방랑객
1.4.4 고수의 경지에 오른 기술 장인
1.4.5 소프트웨어 장인 정신은 어떻게 실패하는가?
1.5 위대한 코드를 작성하기 위한 방법
1.6 참고 자료

2장생산성
2.1 생산성이란 무엇인가?
2.2 프로그래머의 생산성과 팀의 생산성 비교
2.3 인시와 실제 작업 시간
2.4 프로젝트의 개념적 복잡성과 실질적 복잡성
2.5 생산성 예측
2.6 생산성 측정 지표와 그 필요성
2.6.1 실행 파일 크기 측정 지표
2.6.2 머신 인스트럭션 측정 지표
2.6.3 코드 라인 측정 지표
2.6.4 명령문 수 측정 지표
2.6.5 기능 점수 분석법
2.6.6 McCabe 순환 복잡성 측정 지표
2.6.7 기타 측정 지표
2.6.8 측정 지표가 지닌 문제점
2.7 프로그래머가 하루에 열 줄의 코드를 작성한다는 조사 결과에 대해
2.8 개발 기간 예측
2.8.1 소규모 프로젝트 개발 기간 예측
2.8.2 중규모 및 대규모 프로젝트 개발 기간 예측
2.8.3 개발 기간 예측에 따른 문제점
2.9 위기 상황에서의 프로젝트 관리
2.10 생산성 향상의 비법
2.10.1 소프트웨어 개발 도구의 신중한 선정
2.10.2 오버헤드 관리
2.10.3 명확한 목표와 마일스톤 설정
2.10.4 스스로 동기 부여하기
2.10.5 집중력 유지와 방해 요소 제거
2.10.6 지겨움을 느낄 때는 다른 일을 해보자
2.10.7 스스로 발전할 수 있는 분위기를 조성하라
2.10.8 도움이 필요할 때는 요청하라
2.10.9 느슨해진 팀 분위기 되살리기
2.11 참고 자료

3장 소프트웨어 개발 모델
3.1 소프트웨어 개발 수명주기
3.2 소프트웨어 개발 모델
3.2.1 약식 모델
3.2.2 워터폴 모델
3.2.3 V 모델
3.2.4 반복형 모델
3.2.5 나선형 모델
3.2.6 신속 애플리케이션 개발 모델
3.2.7 점증형 모델
3.3 소프트웨어 개발 방법론
3.3.1 전통적 (예측적) 방법론
3.3.2 적응형 방법론
3.3.3 애자일 방법론
3.3.4 익스트림 프로그래밍
간소한 디자인을 위한 가이드
3.3.5 스크럼
3.3.6 목표 기능 주도형 개발
3.4 위대한 프로그래머를 위한 소프트웨어 개발 모델 및 방법론
3.5 참고 자료

2부 UML

4장 UML의 개요와 유스 케이스
4.1 UML 표준
4.2 UML 유스 케이스 모델
4.2.1 유스 케이스 다이어그램 요소
4.2.2 유스 케이스 패키지
4.2.3 유스 케이스 인클루전
4.2.4 유스 케이스 일반화
4.2.5 유스 케이스 익스텐션
4.2.6 유스 케이스 내러티브
4.2.7 유스 케이스 시나리오
4.3 UML 시스템 경계 다이어그램
4.4 유스 케이스 이외의 영역
4.5 참고 자료

5장 UML 액티비티 다이어그램
5.1 UML 액티비티 상태 기호
5.1.1 시작 상태와 종료 상태
5.1.2 액티비티
5.1.3 상태
5.1.4 전환
5.1.5 조건식
5.1.6 합병 지점
5.1.7 이벤트와 트리거
5.1.8 포크 및 조인 동기화
5.1.9 호출 기호
5.1.10 파티션
5.1.11 주석과 주해
5.1.12 커넥터
5.1.13 기타 액티비티 다이어그램 기호
5.2 UML 액티비티 다이어그램의 확장
5.3 참고 자료

6장 UML 클래스 다이어그램
6.1 UML에서의 객체지향 분석 및 디자인
6.2 클래스 다이어그램에서의 가시성
6.2.1 퍼블릭 클래스의 가시성
6.2.2 프라이빗 클래스의 가시성
6.2.3 프로텍티드 클래스의 가시성
6.2.4 패키지 클래스의 가시성
6.2.5 가시성 타입 추가하기
6.3 클래스 속성 요소
6.3.1 속성의 가시성
6.3.2 속성에서 파생된 값
6.3.3 속성 이름
6.3.4 속성의 데이터 타입
6.3.5 연산 데이터 타입(반환값)
6.3.6 속성의 다수성 표현
6.3.7 기본 속성값
6.3.8 프로퍼티 문자열
6.3.9 속성 문법
6.4 클래스 연산 요소
6.5 UML 클래스의 관련성
6.5.1 클래스 의존 관계
6.5.2 클래스 연관 관계
6.5.3 클래스 집합 관계
6.5.4 클래스 구성 관계
6.5.5 클래스 관련성의 특징
6.5.6 클래스 상속 관계
6.6 객체
6.7 참고 자료

7장 UML 인터랙션 다이어그램
7.1 시퀀스 다이어그램
7.1.1 라이프라인
7.1.2 메시지 타입
7.1.3 메시지 라벨
7.1.4 메시지 번호
7.1.5 보호 조건
7.1.6 반복 시행
7.1.7 롱 딜레이 및 시간 제약 조건
7.1.8 외부 객체
7.1.9 액티베이션 바
7.1.10 브랜칭
7.1.11 대체 흐름
7.1.12 객체 생성 및 제거
7.1.13 시퀀스 프래그먼트
7.2 커뮤니케이션 다이어그램
7.3 참고 자료

8장 그 외 다양한 UML 다이어그램
8.1 컴포넌트 다이어그램
8.2 패키지 다이어그램
8.3 배포 다이어그램
8.4 결합 구조 다이어그램
8.5 스테이트차트 다이어그램
8.6 UML에 대한 관심의 확장
8.7 참고 자료

3부 문서화

9장 시스템 문서화
9.1 시스템 문서화 유형
9.2 변경 이력 추적 기능
9.2.1 개발자 문서에 추적 기능 적용하기
9.2.2 태그 형식
9.2.3 요구 사항 이력 추적 매트릭스
9.3 검증, 검토, 확인
9.4 문서화를 통한 개발 비용 절감
9.4.1 사용자 니즈 검증을 통한 비용 절감
9.4.2 요구 사항 부합 여부 검토를 통한 비용 절감
9.5 참고 자료

10장 요구 사항 문서화
10.1 요구 사항의 근원과 추적 가능성
10.1.1 요구 사항 형식 권장안
10.1.2 우수한 요구 사항의 특징
10.2 디자인 목표
10.3 시스템 요구 사항 명세서
10.4 소프트웨어 요구 사항 명세서
10.4.1 서론
10.4.2 전반적 설명
10.4.3 세부적 요구 사항
10.4.4 각종 지원 정보
10.4.5 소프트웨어 요구 사항 명세서 예시
10.5 요구 사항 작성하기
10.6 유스 케이스
10.6.1 디버그 모드 활성화/비활성화
10.6.2 Ethernet 활성화/비활성화
10.6.3 RS-232 활성화/비활성화
10.6.4 테스트 모드 활성화/비활성화
10.6.5 USB 활성화/비활성화
10.6.6 DIP 스위치 읽기
10.7 유스 케이스를 DAQ 소프트웨어 요구 사항으로 작성하기
10.8 SRS에 기초한 DAQ 소프트웨어 요구 사항 작성
10.9 요구 사항 정보를 이용한 RTM 업데이트
10.9.1 리뷰에 의한 요구 사항 검증
10.9.2 테스트에 의한 요구 사항 검증
10.10 참고 자료

11장 소프트웨어 디자인 명세서 문서화
11.1 IEEE Std 1016-1998 vs IEEE Std 1016-2009
11.2 IEEE 1016-2009 개념 모델
11.2.1 디자인 고려 사항과 디자인 업무 참여자
11.2.2 디자인 뷰포인트와 디자인 요소
11.2.3 디자인 뷰, 디자인 오버레이, 디자인 래셔널
11.2.4 IEEE Std 1016-2009 개념 모델
11.3 SDD 필수 콘텐츠
11.3.1 SDD 식별 정보
11.3.2 디자인 작업 참여자와 디자인 고려 사항
11.3.3 디자인 뷰, 뷰포인트, 오버레이, 래셔널
11.4 SDD 추적 가능성 및 태그
11.5 SDD 개요 제안
11.6 SDD 작성 예시
11.7 디자인 정보를 이용한 RTM 업데이트
11.8 소프트웨어 디자인 문서의 작성
11.9 참고 자료

12장 소프트웨어 테스트 문서화
12.1 Std 829 표준안의 소프트웨어 테스트 문서
12.1.1 테스트 프로세스 지원
12.1.2 중요도 레벨과 위험도 평가
12.1.3 소프트웨어 개발 테스트 레벨
12.2 테스트 계획
12.2.1 마스터 테스트 계획
12.2.2 레벨 테스트 계획
12.2.3 레벨 테스트 디자인 문서화
12.3 소프트웨어 리뷰 리스트 문서화
12.3.1 SRL 문서 개요 작성 예시
12.3.2 SRL 작성 예시
12.3.3 RTM에 SRL 아이템 추가하기
12.4 소프트웨어 테스트 케이스 문서화
12.4.1 STC 문서의 서론부
12.4.2 세부 사항
12.4.3 범례
12.4.4 소프트웨어 테스트 케이스 작성 예시
12.4.5 STC 정보를 이용한 RTM 업데이트
12.5 소프트웨어 테스트 프로시저 문서화
12.5.1 IEEE Std 829-2009 소프트웨어 테스트 프로시저
12.5.2 STP 문서 개요의 확장
12.5.3 STP 문서의 서론부
12.5.4 테스트 프로시저
12.5.5 범례
12.5.6 색인
12.5.7 STP 작성 예시
12.5.8 STP 정보로 RTM 업데이트하기
12.6 레벨 테스트 로그
12.6.1 레벨 테스트 로그 문서의 서론부
12.6.2 세부 사항
12.6.3 용어 설명
12.6.4 테스트 로그에 대한 몇 가지 의견
12.7 문제점 보고서
12.7.1 문제점 보고서의 서론부
12.7.2 세부 사항
12.7.3 문제점 보고서에 대한 몇 가지 의견
12.8 테스트 보고서
12.8.1 마스터 테스트 보고서 개요
12.8.2 레벨 테스트 보고서
12.9 여러분에게 정말로 필요한 개발자 문서는 무엇인가?
12.10 참고 자료

후기: 위대한 코드 설계하기