HOME > Detail View

Detail View

Great code. 3, 개발자는 어떻게 소프트웨어를 완성하는가

Material type
단행본
Personal Author
Hyde, Randall 동준상, 역
Title Statement
Great code. 3, 개발자는 어떻게 소프트웨어를 완성하는가 / 랜달 하이드 지음 ; 동준상 옮김
Publication, Distribution, etc
서울 :   에이콘,   2021  
Physical Medium
471 p. : 삽화 ; 24 cm
Series Statement
에이콘 소프트 아키텍처 시리즈
Varied Title
Write great code. 3, Engineering software
ISBN
9791161755434
Bibliography, Etc. Note
참고문헌과 색인수록
Subject Added Entry-Topical Term
Software engineering Computer programming Coding theory
000 00000nam c2200205 c 4500
001 000046088960
005 20210810092705
007 ta
008 210810s2021 ulka b 001c kor
020 ▼a 9791161755434 ▼g 93000
040 ▼a 211009 ▼c 211009 ▼d 211009
041 1 ▼a kor ▼h eng
082 0 4 ▼a 005.1 ▼2 23
085 ▼a 005.1 ▼2 DDCK
090 ▼a 005.1 ▼b 2005k ▼c 3
100 1 ▼a Hyde, Randall
245 1 0 ▼a Great code. ▼n 3, ▼p 개발자는 어떻게 소프트웨어를 완성하는가 / ▼d 랜달 하이드 지음 ; ▼e 동준상 옮김
246 1 9 ▼a Write great code. ▼n 3, ▼p Engineering software
260 ▼a 서울 : ▼b 에이콘, ▼c 2021
300 ▼a 471 p. : ▼b 삽화 ; ▼c 24 cm
490 1 0 ▼a 에이콘 소프트 아키텍처 시리즈
504 ▼a 참고문헌과 색인수록
650 0 ▼a Software engineering
650 0 ▼a Computer programming
650 0 ▼a Coding theory
700 1 ▼a 동준상, ▼e
830 0 ▼a 에이콘 소프트 아키텍처 시리즈
900 1 0 ▼a 하이드, 랜달, ▼e
945 ▼a KLPA

Holdings Information

No. Location Call Number Accession No. Availability Due Date Make a Reservation Service
No. 1 Location Science & Engineering Library/Sci-Info(Stacks1)/ Call Number 005.1 2005k 3 Accession No. 121257895 Availability Available Due Date Make a Reservation Service B M

Contents information

Book Introduction

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

★ 이 책에서 다루는 내용 ★

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

★ 이 책의 대상 독자 ★

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

독자가 컴퓨터 구조(machine organization)와 데이터 표현 방식(data representation)에 대한 기본적인 이해를 갖추고 있을 것으로 가정한다.


Information Provided By: : Aladin

Table of Contents

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 참고 자료

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

New Arrivals Books in Related Fields

Ramamurthy, Bina (2021)