Every day is Bright sunny day!

Auditing?

The independent examination of records and other information in order to form an opinion on the integrity of a system of controls and recommend control improvement to limit risks.

흠.. 해석하면..
통제 시스템의 통합에 대한 의견을 제시하고
위기를 제한 하는 통제 개선을 권고하기 위해
독립적으로 기록이나 다른 정보를 시험하는 것.

정의에 사용된 단어를 살펴보면..

independent
 - report to a separate line of management
 - be free to state the facts of a situation
 - freethinking

examination
 - gathering and assessment of factual information from various sources
 
records and other
 - need to refer to information regarding the business processes & system under review
 - use data analysis tools to examine computer records

opinion
 - provide both objective facts & subjective opinions
 
integrity
 - same meaning with  completeness, accuracy and trustworthiness
 -
system of controls
recommend
control improvements
limit
risk

1부 아키텍처 개요 1

1장 아키텍처 비즈니스 사이클 3
1.1 아키텍처에 영향을 주는 요인 6
1.2 소프트웨어 프로세스와 아키텍처 비즈니스 사이클 12
1.3 좋은 아키텍처의 요건 15
1.4 요약 17
1.5 생각해볼 문제 17

2장 소프트웨어 아키텍처 정의 19
2.1 소프트웨어 아키텍처 요건 19
2.2 소프트웨어 아키텍처에 대한 기타 관점 23
2.3 아키텍처 패턴, 참조 모델, 참조 아키텍처 24
2.4 소프트웨어 아키텍처의 중요성 26
2.5 아키텍처 구조와 뷰 35
2.6 요약 42
2.7 더 읽을 거리 42
2.8 생각해볼 문제 45

3장 A-7E 항공 전자 시스템 47
3.1 아키텍처 비즈니스 사이클과의 관계 48
3.2 요구사항과 품질 48
3.3 A-7E 항공 전자 시스템의 소프트웨어 아키텍처 53

2부 아키텍처 수립 69

4장 품질속성 이해 71
4.1 기능성과 아키텍처 72
4.2 품질속성 아키텍처 72
4.3 시스템 품질속성 74
4.4 실전에서의 품질속성 시나리오 78
4.5 기타 시스템 품질속성 94
4.6 업무 품질 94
4.7 아키텍처 자체의 품질 96
4.8 요약 97
4.9 더 읽을 거리 97
4.10 생각해볼 문제 98

5장 품질 목표 달성 99
5.1 설계전술 100
5.2 가용성 설계전술 101
5.3 변경용이성 설계전술 106
5.4 성능 설계전술 112
5.5 보안 설계전술 117
5.6 시험용이성 설계전술 119
5.7 사용편의성 설계전술 122
5.8 설계전술과 아키텍처 패턴 관계 124
5.9 아키텍처 패턴과 스타일 125
5.10 요약 126
5.11 생각해볼 문제 127
5.12 더 읽을 거리 127

6장 항공관제 시스템 129
6.1 아키텍처 비즈니스 사이클과의 관계 132
6.2 요구사항과 품질 132
6.3 아키텍처 관점에서의 해결방안 135
6.4 요약 150
6.5 더 읽을 거리 151
6.6 생각해볼 문제 151

7장 아키텍처 설계 153
7.1 생명주기상에서의 아키텍처 153
7.2 아키텍처 설계 155
7.3 팀 구조 형성과 아키텍처의 관계 167
7.4 골격 시스템 구축 170
7.5 요약 171
7.6 더 읽을 거리 173
7.7 생각해볼 문제 173

8장 비행 모의실험 175
8.1 아키텍처 비즈니스 사이클과의 관계 176
8.2 요구사항과 품질 177
8.3 아키텍처 관점에서의 해결방안 182
8.4 요약 197
8.5 더 읽을 거리 199
8.6 생각해볼 문제 199

9장 소프트웨어 아키텍처 문서화 201
9.1 아키텍처 문서의 용도 201
9.2 뷰 204
9.3 관련 뷰 선택 205
9.4 뷰 문서화 207
9.5 여러 뷰를 고려한 문서화 215
9.6 UML 218
9.7 요약 229
9.8 더 읽을 거리 230
9.9 생각해볼 문제

10장 아키텍처 재건 231
10.1 개요 231
10.2 정보 추출 234
10.3 데이터베이스 구축 237
10.4 뷰 융합 239
10.5 재건 241
10.6 사례 연구 248
10.7 요약 257
10.8 더 읽을 거리 258
10.9 생각해볼 문제 259

3부 아키텍처 분석 261

11장 ATAM 271
11.1 ATAM 참여자 272
11.2 ATAM의 결과물 274
11.3 ATAM의 과정 275
11.4 나이팅게일 시스템: ATAM을 적용한 사례 연구 288
11.5 요약 303
11.6 더 읽을 거리 304
11.7 생각해볼 문제 305

12장 CBAM 307
12.1 의사결정의 배경 308
12.2 CBAM의 기초 310
12.3 CBAM의 구현 314
12.4 사례 연구: 미국항공우주국 ECS 프로젝트 317
12.5 CBAM 작업 결과 324
12.6 요약 324
12.7 더 읽을 거리 325
12.8 생각해볼 문제 325

13장 월드와이드웹 327
13.1 아키텍처 비즈니스 사이클과의 관계 328
13.2 요구사항과 품질 329
13.3 아키텍처 관점에서의 해결방안 334
13.4 제2차 ABC 사이클: 웹 기반 전자상거래 아키텍처로의 진화 340
13.5 품질 목표 달성 346
13.6 오늘날의 월드와이드웹 아키텍처 비즈니스 사이클 346
13.7 요약 348
13.8 더 읽을 거리 349
13.9 생각해볼 문제 349

4부 아키텍처 확산 351

14장 소프트웨어 프로덕트 라인 353
14.1 개요 353
14.2 소프트웨어 프로덕트 라인의 작동원리 355
14.3 범위 설정 357
14.4 프로덕트 라인 아키텍처 360
14.5 소프트웨어 프로덕트 라인의 방해 요소 364
14.6 요약 367
14.7 더 읽을 거리 368
14.8 생각해볼 문제 368

15장 셀시우스테크 369
15.1 아키텍처 비즈니스 사이클과의 관계 370
15.2 요구사항과 품질 387
15.3 아키텍처 관점에서의 해결방안 390
15.4 요약 398
15.5 더 읽을 거리 399
15.6 생각해볼 문제 399

16장 J2EE/EJB 401
16.1 아키텍처 비즈니스 사이클과의 관계 402
16.2 요구사항과 품질 403
16.3 아키텍처 관점에서의 해결방안 406
16.4 시스템 배치 의사결정 419
16.5 요약 425
16.6 더 읽을 거리 425
16.7 생각해볼 문제 425

17장 루더 아키텍처 427
17.1 아키텍처 비즈니스 사이클과의 관계 428
17.2 요구사항과 품질 431
17.3 아키텍처 관점에서의 해결방안 435
17.4 품질 목표 달성 451
17.5 요약 452
17.6 더 읽을 거리 452
17.7 생각해볼 문제 452

18장 기성품 컴포넌트를 활용한 시스템 구축 453
18.1 컴포넌트가 아키텍처에 미치는 영향 455
18.2 아키텍처 불일치 456
18.3 검색을 통한 컴포넌트 기반 설계 462
18.4 ASEILM 사례 466
18.5 요약 476
18.6 더 읽을 거리 476

19장 미래의 소프트웨어 아키텍처 477
19.1 다시 살펴보는 아키텍처 비즈니스 사이클 479
19.2 아키텍처 수립 479
19.3 생명주기 내에서의 아키텍처 481
19.4 상용 컴포넌트의 영향 482
19.5 요약 484

from IEE/ISO 730

1.     목적

2.     참고 문서

3.     관리

A.     소프트웨어 생명 주기 관련

4.     문서화

A.     소프트웨어 요구사항 명세서SRS (기능,성능,설계 제한조건,태도)

B.      소프트웨어 설계 정의서SDD

C.      소프트웨어 검증 및 확인 계획SVVP (Verification and Validation)

D.     소프트웨어 검증 및 확인 리포트 SVVR

E.      사용자 매뉴얼 – 가이드, 모든 에러 메시지가 설정되어야 한다.

F.      소프트웨어 형상관리 계획 SCMP

5.     표준, 메트릭

A.     표준

                         i.         문서화 표준

                        ii.         로직 구조 표준

                       iii.         코딩 표준

                       iv.         주석 표준

                        v.         테스트 표준 및 실천

B.      메트릭

                         i.         Branch metric

                        ii.         Decision point metric

                       iii.         Domain metric

                       iv.         Error message metric

                        v.         Requirements demonstration metric

 

6.     Review and audit

A.     소프트웨어 요구사항 review

B.      예비 설계 review

C.      Critical 설계 review

D.     소프트웨어 검증 및 확인 계획SVVP review

E.      Functional audit – verify all requirements specified in SRS have been met

F.      Physical audit – verify s/w and its doc are ready for delivery

G.     In process audit

H.     Managerial review

I.       s/w 형상관리 계획 review

J.       사후 관리 review

 

7.     Test

8.     문제 보고 및 수정

9.     도구, 기술, 방법론

10.   코드 제어

11.   미디어 제어

12.   공급자 제어

13.   운영

14.   교육

15.   위기 관리

from IEE/ISO 829

1.     Test 계획 identifier

A.     Identifier

2.     Introduction

A.     프로젝트 권한

B.      프로젝트 계획

C.      품질 보증 계획

D.     형상관리 계획

E.      관련 정책

F.      관련 표준

 

3.     Test 품목

A.     요구사항 명세서

B.      디자인 명세서

C.      사용자 가이드

D.     운영 가이드

E.      설치 가이드

 

4.     Test 할 Features

5.     Test 안 할 Features

6.     접근법 ??

A.     Major activities, techniques, tools

B.       

7.     Item pass/fail criteria

8.     Suspension criteria and resumption requirements

9.     Test 결과물

A.     Test plan

B.      Test 설계 명세서

C.      Testcase 명세서

D.     Test 절차 명세서

E.      Test item transmittal reports

F.      Test 로직

G.     Test incident report

H.     Test summary reprort

10.   Test 할 tasks

11.   환경적 필요조건

12.   책임

A.     관리, 설계, 준비, 실행 등 그룹이 책임을 명시한다.

13.   인력 및 교육 요구

14.   스케줄

A.     마일스톤

B.       

15.   위기 및 우연

16.   승인절차

A.     Name and title