설계도가 중요한 이유 :
건물을 짓는 도중에 문제가 발생하면
건물을 처음부터 다시 지어야 할 수도 있고, 생각하지 못한 일정이 추가가 됩니다.
이 모든 것은 돈입니다.
Chapter 03는 소프트웨어 구축을 준비하기 위해 수행해야하는 작업을 설명하고 있습니다.
Measure Twice, Cut Once 라는 말은 번역하면 "두 번 측정하고, 한 번 자르세요" 라는 목수들의 용어입니다.
그만큼 실행에 옮기기 전에 잘 준비하라는 겁니다.
왜냐 다시하면 비싸니까
3.1 Importance of Prerequisites(전제 조건의 중요성)
준비의 가장 중요한 목표는 위험을 줄이는 것
가장 일반적인 프로젝트 위험은 부실한 요구 사항과 부실한 프로젝트 계획이므로
준비는 요구 사항 및 프로젝트 계획을 개선하는데 중점을 두는 경향이 있음.
불안전한 준비를 하게 되는 이유
1. 빨리 코딩을 시작하고 싶어서
2. 관리자들이 이를 소프트웨어 개발이라고 생각하지 않아서
상대를 완전히 설득할 수 있는 주장
1. 논리에 호소
2. 비유에 호소
데이터에 대한 이의 제기
결합 발생 시점, 확인 시잠이 늦어질 수록 비용이 높아짐
3.2 작업 중인 소프트웨어의 종류를 결정하라
반복적 접근 방식이 필수 구성 요소에 미치는 영향
반복적인 접근 방식은 부적절한 업스트림 작업의 영향을 줄이는 경향이 있는거 맞으나,
완전히 제거하지는 않음.
필수 구성 요소를 축약하거나 제거하는 반복 프로젝트와 동일한 작업을 수행하는 순차적 프로젝트의 차이 두가지
첫째, 결함이 소프트웨어에 삽입된 시점에 더 가깝게 감지되는 경향이 있기 때문에 평균 결함 수정 비용이 낮아짐.
그러나 결함은 여전히 각 반복에서 나중에 감지되며, 결함을 수정하려면 소프트웨어의 일부를 재설계, 재코딩 및 다시 테스트해야 하므로 결함 수정 비용이 필요한 것보다 높아짐.
둘째, 반복적인 접근 방식을 사용하면 비용이 마지막에 클러스터링되지 않고 프로젝트 전반에 걸쳐 단편적으로 흡수됨.
모든 먼지가 가라앉으면 총 비용은 비슷하지만 가격이 마지막에 한 번에 모두 지불하는 것이 아니라 프로젝트 과정에서 소액으로 지불되기 때문에 높지 않아 보임.
표 3-4를 통해 알 수 있듯이 대부분의 프로젝트는 완전히 순차적이지도 않고 완전히 반복적이지도 않음.
요구 사항이나 설계를 100% 지정하는 것은 실용적이지 않지만 대부분의 프로젝트는 최소한 가장 중요한 요구 사항과 아키텍처 요소를 조기에 식별하는 데 가치가 있음.
1. 요구 사항의 약 80%를 미리 지정하도록 계획하고, 추가 요구 사항이 나중에 지정될 수 있도록 시간을 할당함 그 다음 프로젝트가 진행됨에 따라 가장 중요한 새 요구 사항만 수락하도록 체계적인 변경 제어를 수행
2.요구 사항의 가장 중요한 20%만 미리 지정하고 나머지 소프트웨어는 조금씩 개발하도록 계획하면서 추가 요구 사항과 설계를 지정. 그림 3-2 및 3-3은 이러한 다양한 접근 방식을 반영합니다.
반복적 접근 방식과 순차적 접근 방식 중에서 선택
순차적인(선행) 접근 방식을 선택하는 경우
■ The requirements are fairly stable.
■ The design is straightforward and fairly well understood.
■ The development team is familiar with the applications area.
■ The project contains little risk.
■ Long-term predictability is important.
■ The cost of changing requirements, design, and code downstream is likely to be
high.
You might choose a more iterative (as-you-go) approach when
■ The requirements are not well understood or you expect them to be unstable for
other reasons.
■ The design is complex, challenging, or both.
■ The development team is unfamiliar with the applications area.
■ The project contains a lot of risk.
■ Long-term predictability is not important.
■ The cost of changing requirements, design, and code downstream is likely to be
low.
3.3 문제 정의 전제 조건
이 섹션에서는 문제 정의를 작성하는 방법을 알려주지 않습니다. 그것은 어떤 것이 쓰여졌는지, 그리고 쓰여진 것이 건설을 위한 좋은 기초를 형성할 것인지를 어떻게 인식하는지 알려줍니다.
문제 정의는 가능한 솔루션에 대한 참조 없이 문제가 무엇인지 정의
| 문제 정의의 좋은 예시 | 문제 정의의 안 좋은 예시 |
| “We can’t keep up with orders for the Gigatron” | “We need to optimize our automated data-entry system to keep up with orders for the Gigatron” |
문제 정의 작성 시 주의점
1. 사용자 언어로 작성(컴퓨터 용어 X)
2. 사용자 관점에서 문제를 설명
문제를 정의하지 못했을 때의 불이익 => 잘못된 문제를 해결하는 데 많은 시간을 낭비할 수 있다는 것
3.4 요구 사항 사전 요구 사항 요구 사항은 소프트웨어 시스템이 수행해야 하는 작업을 자세히 설명합니다.
요구 사항 활동 => 솔루션을 향한 첫 번째 단계
공식 요구 사항이 있는 이유?
명시적 요구 사항 집합은 여러 가지 이유로 중요
1. 사용자가 시스템 기능을 구동하도록 하는 데 도움이 됨.
요구 사항이 명시적인 경우 사용자는 이를 검토하고 동의할 수 있음.
2. 논쟁을 피하는 데도 도움이 됨.
프로그램이 수행해야 하는 작업에 대해 다른 프로그래머와 의견 차이가 있는 경우 작성된 요구 사항을 확인하여 해결할 수 있음.
3. 요구 사항에 주의를 기울이면 개발이 시작된 후 시스템 변경을 최소화하는 데 도움이 됨.
코딩 중에 코딩 오류를 발견하면 몇 줄의 코드를 변경하면 작업이 계속됨. 코딩 중에 요구 사항 오류가 발견되면 변경된 요구 사항에 맞게 설계를 변경해야 함.
4. 많은 비용이 발생하는 것을 방지
표 3-1에서 보고된 바와 같이, 수많은 조직의 데이터에 따르면 대규모 프로젝트에서 아키텍처 단계에서 감지된 요구 사항의 오류는 일반적으로 요구 사항 단계에서 감지된 경우보다 수정 비용이 3배 더 많이 듭니다 코딩 중이면 5-10배, 릴리스 후에는 10-100배
안정적인 요구 사항의 신화
안정적인 요구 사항을 통해 프로젝트는 아키텍처에서 설계, 코딩, 테스트에 이르기까지 질서 있고 예측 가능하며 차분한 방식으로 진행할 수 있음.
비용을 예측할 수 있으며, 디버깅을 완료할 때까지 사용자가 생각하지 못했기 때문에 구현하는 데 100배 더 많은 비용이 드는 기능에 대해 걱정할 필요가 없음.
건설 중 요구 사항 변경 처리
1. 섹션 끝에 있는 요구 사항 검사 목록을 사용하여 요구 사항의 품질을 평가,
요구 사항이 충분하지 않은 경우 작업을 중지하고 백업한 다음 계속하기 전에 바로 만들기
시간 낭비로 보일 수 있지만 먼 길을 갔을때는 더 효율적일 수 있음.
2. 요구 사항 변경의 비용을 모든 사람이 알고 있는지 확인하십시오. 고객 또한 알고 있는지
3. 변경 관리 절차 설정
고객이 생각을 바꾸고 더 많은 기능이 필요하다는 것을 깨닫는 것은 괜찮음. 문제는 그들이 너무 자주 변경 사항을 제안하여 따라갈 수 없다는 것임
4. 변경 사항을 수용하는 개발 접근 방식 사용
핵심은 사용자에게 빠르게 응답할 수 있도록 짧은 개발 주기를 사용하는 것
5. 프로젝트 덤프
요구 사항이 특히 나쁘거나 불안정하고 위의 제안 사항 중 어느 것도 실행 가능하지 않은 경우 프로젝트를 취소.
실제로 취소하는 것이 아닌 이를 가정할 것
6.프로젝트의 비즈니스 사례를 주시
자신의 결정이 비즈니스에 미치는 영향을 고려하는 것을 기억할 것.
기능으로서가 아닌, 비즈니스로서의 영향
3.5 아키텍처 필수 구성 요소
소프트웨어 아키텍처 : 소프트웨어 설계의 상위 수준 부분으로, 설계의 보다 세부적인 부분을 담고 있는 프레임
설계 - 아키텍처는 시스템 전체에 적용되는 설계 제약 조건을 나타내는 반면, 상위 수준 설계는 하위 시스템 또는 다중 클래스 수준에서 적용되지만 반드시 시스템 전체에 적용되는 것은 아닌 설계 제약 조건을 나타냅니다.
아키텍처의 품질이 중요한 이유
1. 시스템의 개념적 무결성을 결정하기 때문, 이는 결국 시스템의 궁극적인 품질을 결정하게 됨.
세심하게 계획된 아키텍처는 최상위 수준에서 최하위까지 시스템의 개념적 무결성을 유지하는 데 필요한 구조를 제공함.
프로그래머의 기술과 당면한 작업에 적합한 세부 수준으로 프로그래머에게 지침을 제공함.
여러 개발자 또는 여러 개발 팀이 독립적으로 작업할 수 있도록 작업을 분할함.
2. 아키텍처 변경은 많은 비용이 발생함.
소프트웨어 아키텍처에서 오류를 수정하는 데 필요한 시간은 요구 사항 오류를 수정하는 데 필요한 시간과 동일한 순서로, 즉 코딩 오류를 수정하는 데 필요한 시간보다 더 김.
일반적인 아키텍처 구성 요소
1. 프로그램 구성
- 시스템 아키텍처는 먼저 시스템을 광범위하게 설명하는 개요가 필요.
- 아키텍처에서 최종 조직에 대한 대안이 고려되었다는 증거를 찾고 대안 대신 최종 조직을 선택하는 이유를 찾아야 함.
- 아키텍처는 프로그램의 주요 구성 요소를 정의해야 함.
- 각 빌딩 블록이 담당하는 것은 잘 정의되어야 함.
- 각 빌딩 블록에 대한 통신 규칙은 잘 정의되어야 함.
2. 주요 클레스
- 아키텍처는 사용할 주요 클래스를 지정해야 함.
3. 데이터 디자인
- 아키텍처는 사용할 주요 파일 및 테이블 디자인을 설명해야 함.
4. Business Rules(비즈니스 규칙)
- 아키텍처가 특정 비즈니스 규칙에 의존하는 경우 해당 규칙을 식별하고 규칙이 시스템 설계에 미치는 영향을 설명해야 함.
5. 사용자 인터페이스 디자인
- 사용자 인터페이스는 요구 사항 시간에 지정되는 경우가 많음. 그렇지 않은 경우 소프트웨어 아키텍처에 지정해야 함.
6. 자원 관리
- 아키텍처는 데이터베이스 연결, 스레드 및 핸들과 같은 부족한 리소스를 관리하기 위한 계획을 설명해야 함.
7. 보안
- 아키텍처는 디자인 수준 및 코드 수준 보안에 대한 접근 방식을 설명해야 함.
8. 성능
- 성능이 중요한 경우 요구 사항에 성능 목표를 지정해야 함.
9. 확장성
- 아키텍처는 시스템이 사용자 수, 서버 수, 네트워크 노드 수, 데이터베이스 레코드 수, 데이터베이스 레코드 크기, 트랜잭션 볼륨 등의 증가를 처리하는 방법을 설명해야 함.
10. 상호 운용성
- 시스템이 다른 소프트웨어 또는 하드웨어와 데이터 또는 리소스를 공유할 것으로 예상되는 경우 아키텍처는 이를 수행하는 방법을 설명해야 함.
11. 국제화/지역화
- "국제화"는 여러 로캘을 지원하기 위해 프로그램을 준비하는 기술 활동
- "지역화"(같은 이유로 "L10n"이라고 함)는 특정 현지 언어를 지원하기 위해 프로그램을 번역하는 작업
12. 입력/출력
- 아키텍처는 look-ahead, look-behind 또는 just-in-time 읽기 스키마를 지정해야 함. 또한 I/O 오류가 감지되는 수준(필드, 레코드, 스트림 또는 파일 수준)을 설명해야 함.
13. 처리 중 오류 발생
- 오류 처리는 수정입니까 아니면 단순히 탐정입니까? 수정하는 경우 프로그램은 오류로부터 복구를 시도할 수 있습니다. 단순히 탐지인 경우 프로그램은 아무 일도 없었던 것처럼 처리를 계속하거나 종료할 수 있습니다. 두 경우 모두 오류를 감지했음을 사용자에게 알려야 합니다.
- 오류 감지는 능동적입니까 아니면 수동적입니까? 시스템은 예를 들어 사용자 입력의 유효성을 확인하여 오류를 능동적으로 예측하거나 오류를 피할 수 없는 경우(예: 사용자 입력 조합으로 숫자 오버플로가 발생하는 경우)에만 수동적으로 응답할 수 있습니다. 길을 닦거나 엉망진창을 청소할 수 있습니다. 다시 말하지만, 두 경우 모두 선택은 사용자 인터페이스에 영향을 미칩니다.
- 프로그램은 오류를 어떻게 전파합니까? 오류를 감지하면 오류를 일으킨 데이터를 즉시 삭제하거나, 오류를 오류로 처리하고 오류 처리 상태로 전환하거나, 모든 처리가 완료될 때까지 기다렸다가 사용자에게 오류가 감지되었음을 알릴 수 있습니다(어딘가에서).
- 오류 메시지를 처리하기 위한 규칙은 무엇입니까? 아키텍처가 하나의 일관된 전략을 지정하지 않으면 사용자 인터페이스는 프로그램의 다른 부분에 있는 서로 다른 인터페이스의 혼란스러운 마카로니와 말린 콩 콜라주로 나타납니다. 이러한 모양을 방지하려면 아키텍처에서 오류 메시지에 대한 규칙을 설정해야 합니다.
- 예외는 어떻게 처리되나요? 아키텍처는 코드가 예외를 throw할 수 있는 시기, 예외가 catch되는 위치, 기록되는 방법, 문서화되는 방법 등을 처리해야 합니다.
- 프로그램 내에서 오류는 어떤 수준에서 처리됩니까? 감지 지점에서 처리하거나, 오류 처리 클래스에 전달하거나, 호출 체인을 전달할 수 있습니다.
- 입력 데이터의 유효성을 검사하기 위한 각 클래스의 책임 수준은 어느 정도입니까? 각 클래스가 자체 데이터의 유효성을 검사합니까, 아니면 시스템 데이터의 유효성을 검사하는 클래스 그룹이 있습니까? 모든 수준의 클래스가 수신하는 데이터가 깨끗하다고 가정 할 수 있습니까?
- 환경에 내장된 예외 처리 메커니즘을 사용하시겠습니까, 아니면 직접 빌드하시겠습니까? 환경에 특정 오류 처리 접근 방식이 있다고 해서 요구 사항에 가장 적합한 접근 방식이라는 의미는 아닙니다.
14. 내결함성
- 아키텍처는 예상되는 내결함성의 종류를 나타내야 함.
* 내결함성 : 오류를 감지하고, 가능한 경우 오류를 복구하고, 그렇지 않은 경우 잘못된 영향을 포함하여 시스템의 안정성을 높이는 기술 모음
15. 건축적 타당성
- 아키텍처는 시스템이 기술적으로 실현 가능하다는 것을 입증해야 함.
16. 오버엔지니어링
- 프로그래머가 과도하게 엔지니어링하는 쪽에서 실수를 해야 하는지, 아니면 작동하는 가장 간단한 일을 하는 쪽에서 실수를 해야 하는지 명확하게 나타내야 함.
17. 구매(Buy) 대 구축(Build) 결정
- 기성 구성 요소를 사용하지 않는 경우 사용자 지정 빌드 구성 요소가 미리 만들어진 라이브러리 및 구성 요소를 능가할 것으로 예상하는 방법을 설명해야 함.
18. 재사용 결정
- 계획에서 기존 소프트웨어, 테스트 케이스, 데이터 형식 또는 기타 자료를 사용해야 하는 경우 아키텍처는 재사용된 소프트웨어가 다른 아키텍처 목표를 준수하도록 만드는 방법을 설명해야 함.
19. 변화 전략
- 가능한 변경 사항을 수용할 수 있을 만큼 충분히 유연한 아키텍처를 만들어야 함.
- 변경 사항을 처리하기 위한 전략을 명확하게 설명해야 함.
- 커밋을 지연시키는 데 사용되는 전략을 나타내야 함.
20. 일반 건축 품질
- 임시방편적인 추가가 거의 없는 세련된 개념적 전체여야 함.
- 목표를 명확하게 명시해야 함.
- 모든 주요 결정에 대한 동기를 설명해야 함.
- 시스템을 과소 지정하는 것과 과도하게 지정하는 것 사이의 경계를 따라야 함.
- 여러 보기가 포함되어야 함.
3.6 업스트림 필수 구성 요소에 소요되는 시간
문제 정의, 요구 사항 및 소프트웨어 아키텍처에 소요되는 시간은 프로젝트의 요구 사항에 따라 다름.
일반적으로 잘 운영되는 프로젝트는 노력의 약 10-20%와 일정의 약 20-30%를 요구 사항, 아키텍처 및 사전 계획에 투자함.
요약
- 건설 준비의 가장 중요한 목표는 위험을 줄이는 것입니다. 준비 활동이 위험을 증가시키는 것이 아니라 감소시키고 있는지 확인하십시오.
- 고품질 소프트웨어를 개발하려면 소프트웨어 개발 프로세스의 처음부터 끝까지 품질에 주의를 기울여야 합니다. 처음에 품질에 대한 관심은 마지막에 주의하는 것보다 제품 품질에 더 큰 영향을 미칩니다.
- 프로그래머의 업무 중 하나는 프로그래밍을 시작하기 전에 적절한 준비의 중요성을 포함하여 소프트웨어 개발 프로세스에 대해 상사와 동료를 교육하는 것입니다.
- 진행 중인 프로젝트의 종류는 건설 사전 요구 사항에 큰 영향을 미치며, 많은 프로젝트는 매우 반복적이어야 하고 일부는 더 순차적이어야 합니다.
- 좋은 문제 정의가 지정되지 않은 경우 생성 중에 잘못된 문제를 해결하고 있을 수 있습니다.
- 적절한 요구 사항 작업이 수행되지 않은 경우 문제의 중요한 세부 정보를 놓쳤을 수 있습니다. 요구 사항 변경은 건설 후 단계에서 이전보다 20배에서 100배 더 많은 비용이 들기 때문에 프로그래밍을 시작하기 전에 요구 사항이 올바른지 확인해야 합니다.
- 좋은 건축 설계가 이루어지지 않았다면 시공 중에 올바른 문제를 잘못된 방식으로 해결하고 있을 수 있습니다. 잘못된 아키텍처에 대해 더 많은 코드가 작성될수록 아키텍처 변경 비용이 증가하므로 아키텍처도 올바른지 확인해야 합니다.
- 프로젝트의 건설 전제 조건에 대해 어떤 접근 방식이 취해졌는지 이해하고 그에 따라 시공 접근 방식을 선택합니다.
'CS > Code Complete' 카테고리의 다른 글
| Chapter 10 : General Issue in Using Variables (1) | 2025.02.02 |
|---|---|
| part2-chapter 6, 7 (2) | 2025.01.12 |
