Great Code Vol 3 (개발자는 어떻게 소프트웨어를 완성하는가)

Great Code Vol 3 (개발자는 어떻게 소프트웨어를 완성하는가)

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

랜달하이드

RandallHyde
『TheArtofAssemblyLanguage』,『WriteGreatCode』시리즈,『Using6502AssemblyLanguageandP-Source』의저자며,『MicrosoftMacroAssembler6.0Bible』의공저자다.지난40여년간원자력발전기,교통신호시스템,다양한소비자용전자제품을위한임베디드소프트웨어및하드웨어개발도구를만들었고,포모나에위치한캘리포니아폴리테크닉주립대학교(CaliforniaStatePolytechnicUniversity)와리버사이드에위치한캘리포니아대학교(UniversityofCalifornia)에서컴퓨터과학을가르쳤다.프로그래밍과소프트웨어엔지니어링에대한다양한자료를제공하는웹사이트(www.randallhyde.com)를운영한다.

목차

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.6McCabe순환복잡성측정지표
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.3V모델
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.1UML표준
4.2UML유스케이스모델
4.2.1유스케이스다이어그램요소
4.2.2유스케이스패키지
4.2.3유스케이스인클루전
4.2.4유스케이스일반화
4.2.5유스케이스익스텐션
4.2.6유스케이스내러티브
4.2.7유스케이스시나리오
4.3UML시스템경계다이어그램
4.4유스케이스이외의영역
4.5참고자료

5장UML액티비티다이어그램
5.1UML액티비티상태기호
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.2UML액티비티다이어그램의확장
5.3참고자료

6장UML클래스다이어그램
6.1UML에서의객체지향분석및디자인
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.5UML클래스의관련성
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.6UML에대한관심의확장
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.2Ethernet활성화/비활성화
10.6.3RS-232활성화/비활성화
10.6.4테스트모드활성화/비활성화
10.6.5USB활성화/비활성화
10.6.6DIP스위치읽기
10.7유스케이스를DAQ소프트웨어요구사항으로작성하기
10.8SRS에기초한DAQ소프트웨어요구사항작성
10.9요구사항정보를이용한RTM업데이트
10.9.1리뷰에의한요구사항검증
10.9.2테스트에의한요구사항검증
10.10참고자료

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

12장소프트웨어테스트문서화
12.1Std829표준안의소프트웨어테스트문서
12.1.1테스트프로세스지원
12.1.2중요도레벨과위험도평가
12.1.3소프트웨어개발테스트레벨
12.2테스트계획
12.2.1마스터테스트계획
12.2.2레벨테스트계획
12.2.3레벨테스트디자인문서화
12.3소프트웨어리뷰리스트문서화
12.3.1SRL문서개요작성예시
12.3.2SRL작성예시
12.3.3RTM에SRL아이템추가하기
12.4소프트웨어테스트케이스문서화
12.4.1STC문서의서론부
12.4.2세부사항
12.4.3범례
12.4.4소프트웨어테스트케이스작성예시
12.4.5STC정보를이용한RTM업데이트
12.5소프트웨어테스트프로시저문서화
12.5.1IEEEStd829-2009소프트웨어테스트프로시저
12.5.2STP문서개요의확장
12.5.3STP문서의서론부
12.5.4테스트프로시저
12.5.5범례
12.5.6색인
12.5.7STP작성예시
12.5.8STP정보로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참고자료

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

출판사 서평

★이책에서다루는내용★

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


★이책의대상독자★

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


★지은이의말★

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


★옮긴이의말★

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