코드 컴플리트2 - 1부 기초 확립

안녕하세요 낙낙이입니다.

이 포스팅은 코드 컴플리트2 - 더 나은 소프트웨어 구현을 위한 실무 지침서의 요약본입니다.

제가 보면서 중요하다고 생각되는 부분, 메모로 남겼으면하는 하는 부분을 적어놨습니다.

보면서 궁금하신 있으시면 언제든 댓글이나 연락주세요!

1부 기초 확립

1장. 소프트웨어 구현으로의 초대

소프트웨어 구현이란 무엇인가?

소프트웨어 개발 과정

• 문제 정의
• 요구사항 개발
• 구현 계획 수립
• 소프트웨어 아키텍처 또는 고급 수준 설계
• 상세 설계
• 코드 작성 및 디버깅
• 단위 테스트
• 통합 테스트
• 통합
• 시스템 테스트
• 유지보수

절차를 중요시하는 프로젝트에 참여한 경험이 없다면 앞에서 나열한 항목이 불필요한 절차로 보일지 모른다.

독학으로 프로그래밍을 배웠거나 절차에 느슨한 프로젝트에 주로 참여했다면 소프트웨어 제품 제작에 들어가는 여러 활동을 따로 구분하지 않았을 것이다.

아래 이미지는 구현 활동을 회색 원 안에 표시. 구현은 개발 과정 안에서 코드 작성 및 디버깅, 설계, 구현 계획 수립 등 다양한 활동도 포함된다.

구현 외의 중요한 활동으로는 관리, 요구사항 개발, 소프트웨어 아키텍처, 사용자 인터페이스 설계, 시스템 테스트, 유지보수가 있다.

소프트웨어 구현이 중요한 이유는 무엇인가?

• 구현은 소프트웨어 개발에서 큰 비중을 차지한다.
  • 전체 프로젝트 기간의 30% ~ 80%를 차지한다.
• 구현은 소프트웨어 개발 과정에서 중심적인 활동이다.
• 구현에 집중함으로써 프로그래머의 생산성을 크게 향상할 수 있다.
• 구현의 결과물인 소스코드만이 소프트웨어를 정확하게 설명하는 경우가 많다.
  • 요구사항 명세서와 설계문서는 최신 정보를 반영하지 못할 수 있지만, 소스코드는 항상 최신 내용이다.
• 구현은 반드시 해야 하는 유일한 활동이다.

2장. 소프트웨어 개발의 이해를 돕기 위한 비유

소프트웨어 비유 사용법

소프트웨어 비유를 어떻게 사용할 것인가? 그것을 프로그래밍 문제와 프로세스를 이해하는 데 활용해라. 시간이 지나면서 소프트웨어 개발 프로세스를 이해하기 위한 비유를 사용하는 사람은 비유를 사용하지 않는 사람보다 프로그래밍에 대해서 더 잘 이해하고 더 나은 코드를 더 빨리 작헝하는 사람으로 여겨질 것이다..

일반적인 소프트웨어 비유

1. 소프트웨어 글쓰기: 코드 작성
   • 가장 기초적인 비유
   • 펜과 잉크, 종이를 들고 자리에 앉아서 처음부터 끝까지 쓰는 것이다. 정해진 형식 없이 작성하면서 말하고 싶은 것을 생각해 낸다.
   • 개인 작업이나 소규모 프로젝트에 적절
   • 소프트웨어 구현에서는 완전히 독창적인 작품을 만드는 것보다 이전 프로젝트의 설계 아이디어와 코드, 테스트 사례를 재사용하는 데 초점을 맞추는 것이 더 효과적일 때가 많다. 간단히 말해서 글쓰기 비유는 너무 단순하고 제약이 많아 소프트웨어 개발 프로세스에 큰 도움이 되지 않는다.
2. 소프트웨어 농사: 시스템 키우기
   • 어떤 소프트개발자는 소프트웨어 구축을 씨를 심고 곡물을 기르는 것에 비유
   • 한 번에 조금씩 하나를 설계 -> 코드 작성 -> 테스트 -> 시스템에 추가 -> 조금씩 단계별로 수행
   • 관련성이 약하고 많은 정보를 제공하지 못하며, 간단한 개념 이상으로 확장하기가 어렵다.
   • 약점: 소프트웨어 개발 방법을 직접 통제하지 못한다는 사실을 암시
3. 소프트웨어 조개 양식: 시스템 증대
   • 소프트웨어 농사: 시스템 키우기 보다 더 강력
   • 점증적으로 설계하고 구축하고 테스트하는 것이 활용 가능한 소프트웨어 개발 개념 중 가장 강력
   • 실행할 시스템을 가장 단단한 버전으로 만든다.
     • 입력x, 데이터 처리x, 출력x
     • 그저 새발될 실제 시스템을 유지할 수 있을 정도로 탄탄한 골격을 갖고 있기만 하면 된다.
     • 그것은 식별된 기본 함수마다 더미 클래스를 호출할 것이다.
     • 이 시작은 굴이 작은 모래 알갱이에서 진주를 키우는 것과 같다.
   • 골격을 만든 후 조금씩 근육과 피부를 붙인다
     • 더미 클래스를 실질적인 클래스로 바꾼다.
     • 실제 입력을 받아들이는 코드 넣는다.
   • 장점:
     • 허황되지 않는다는 점
     • 농사 비유보다 부적절하게 확장하기가 더 어렵다.
4. 소프트웨어 건설: 소프트웨어 구축
   • 대형 프로젝트에 유용
     • 1.2미터 탑을 쌓으려면 멀쩡한 맥주 캔 10개가 있어야한다. 이 100배 크기의 탑을 쌓는 데는 맥주캔만 100배 개 더 있다고 되는것은 아니다.
     • 작은 프로젝트에서는 실수를 했더라도 큰 문제는 아니다. 고치거나 처음부터 다시 만들면 되기 때문이다.
     • 하지만 1000줄짜리 코드에서 잘못된 설계를 사용한다면 리팩터링하거나 완전히 처음부터 시작할 수 있다.
   • 구조가 복잡할수록 더 주의 깊은 계획이 필요하다.
     • 복잡성과 크기가 커질수록 중요성도 커진다.
   • 임금은 비싸다.
     • 주된 지출은 인건비에서 일어난다. 건축을 예로 들면 벽을 뜯어내고 15cm 정도를 옮기는 데 비용이 많이 드는 이유는 못을 많이 써야 해서가 아니라 벽을 옮기는 데 걸리는 추가 시간에 대한 임금을 지급해야 하기 때문이다.
     • 소프트웨어 제품 구축의 경우 재료는 훨씬 더 저렴하지만, 임금은 마찬가리고 비싸다.주요 지출이 사람들의 시간이기때문이다.
   • 잘 계획 포르젝트는 세부 사항에 대한 내용을 나중에 변경할 수 있게 한다.
   • 구조를 변경하는 것이 주변 기능을 추가하거나 삭제하는 것보다 더 큰 비용이 든다.
   • 건설 유추는 매우 큰 소프트웨어 프로젝트를 이해하는 데 도움을 준다.
     • 안전성을 가장 중요하게 생각하며 지어야 한다.
     • 고층 건물이 무너지는 것보다는 튼튼한 자재를 사는 데 10%의 비용을 더 지불하는 것이 낫다.
5. 소프트웨어 기법의 적용: 지적 도구 상자
   • 훌륭한 장인은 일에 맞는 도구를 알고 그것을 제대로 사용하는 방법을 알고 있다.
     • 프로그래밍에 대해 더 많은 것을 배울수록 머릿속의 도구 상자는 더 많은 북석 도구로 가득 차고 그것들을 언제, 어떠헥 사용할지에 대한 지식으로 채워질 것이다. 소프트웨어 개발 실천법을 지적 도구 상자에 있는 도구로 생각한다면 모든 개발자가 많은 도구를 갖고 있고 하나의 도구로 모든 일을 처리할 수 없다는 것을 말해준다. 문제마다 그에 맞는 도구를 선택하는것이 효과적인 개발자가 되는 비결이다.

3장. 준비는 철저하게: 선행조건

이 장에서는 소프트웨어 구현을 준비하기 위해서 꼭 수행해야 하는 작업을 설명한다.기초 공사가 잘 되지 않았거나 계획을 잘못 수림했을 때 구현 과정에서 할 수 있는 최선의 행동은 손해를 최소화하는 것이다.

목수들 사이에서 전해지는 “두 번 측정하고 한 번 잘라라”라는 말은 소프트웨어 개발에서 보면 전체 프로젝트 비용의 65% 정도를 차지하는 구현 작업과 상당히 연관성이 있다.

선행 조건의 중요성

준비 작업의 가장 중요한 목표는 위험 축소다.훌륭한 프로젝트 기획자는 프로젝트가 매끄럽게 진행될 수 있도록 가능한 한 초기에 주요 위험 요소를 제거한다.

기술자로서 해야 하는 일 중에는 주위의 비기술자에게 개발 프로세스에 대해서 교육하는 것도 포함되어 있다.

• 상사와의 프로그래밍 프로세스 논의 하기

  • 선행 조건이 필요한 이유 논리적으로 설득하기 : 규모가 큰 프로젝트를 시작하기 전에 당연히 프로젝트를 계획해야 한다. 관리 측면에서 볼 때 계획 수립은 프로젝트에 필요한 시관가 인력, 장비의 수를 결정하는 작업니다. 기술적인 측면에서 보면 계획 수립은 잘못된 작업으로 인해 돈을 낭비하는 일이 없도록 자신이 만들고자 하는 것이 무엇인지 정확하게 이해하는 것이다.

  • 선행 조건이 필요한 이유 데이터에 근거하여 설득하기 : 구현 초기 단계에서 결함을 제거하면 제품을 배포한 후나 시스템 테스트 단계에서 제거하는 것보다 10분의 1에서 100분의 1정도까지 비용이 덜 든다는 사실. 소프트웨어 개발이 진행 될 수록 광범위한 피해를 입힐 가능성이 있다.

문제 - 정의 선행 조건

구현에 들어가기에 앞서 완료해야 하는 첫 번째 선행 조건은 시스템이 해결해야 하는 문제를 명확하게 기술하는 것이다.

한 두 장 분량의 간단한 문서이며 반드시 문제점에 대해 언급해야 한다.

- 생산량을 기가트론의 주문 수향에 맞출 수 없다. o

- 기가트론의 주문 수량에 맞추기 위해서 자동화된 데이터 입력 시스템을 최적화해야 한다. x -> 문제점에 대한 것이라기보다는 해결책에 가깝다.

반드시 사용자의 언어로 작성해야 하며 문제는 사용자 관점에서 기술해야 한다.

컴퓨터 전문 용어로 작성하는 것은 안 된다.

문제 정의를 제대로 하지 않으면 잘못된 문제를 해결하는 데 시간을 낭비할 수도 있다.

예) 연간 수익을 보여주는 보고서가 필요하다.

• 개발자적인 측면에서 생각한다면 연간 이윤을 계산하는 프로그램을 작성하고 디버깅하기 위해 개발자 고용

• 개발자적인 생각을 벗어난다면 비서에게 시켜 1분 만에 계산기로 분기별 이윤 완료

요구사항 선행 조건

요구사항은 소프트웨어 시스템이 무엇을 수행해아 하는지에 대해 상세하게 기술하고 해결책을 구현하기 위한 첫 번째 과정이다.

요구사항이 명시적이면 사용자가 요구사항을 보고 동의할 수 있다. 그렇지 않으면 개발자가 프로그래밍하는 도중에 요구사항을 결정해 버리는 경우가 많다.

요구사항을 명시적으로 정의함으로써 사용자가 원하는 것이 무엇인지를 알 수 있다.

명시적 요구사항은 논쟁을 피하게 해준다.

요구사항에 집중하면 개발을 시작하고 난 후 변경 사항을 최소화하는 데 도움을 준다.코드를 작성하다가 코드 오류를 발견하면 코드를 약간 수정한 후 계속 작업할 수 있다. 그러나 코드를 작성하다가 요구사항에서 오류를 발견하면 바뀐 요구사항을 충족시키기 위해 설계를 변경해야 한다.새로 설계할 때 처음보다 시간이 더 오래 걸릴 것이다.

요구사항을 제대로 병시하는 것은 프로젝트 성공에 있어 효과적인 구현 기술보다 더 중요하다.코드를

요구사항이 견고하면 아키텍처부터 설계, 코드 작성, 테스트까지 순서에 따라 예상한대로 차분하게 프로젝트를 진행할 수 있다.

일단 고객이 요구사항 문서를 받아드링고 나면 더 이상 변경할 필요가 없다고 기대해도 좋다. 하지만 일반적으로 고객은 코드가 작성되기 전까지 자기에게 필요한 사항을 확실하게 설명하지 못한다. 프로젝트를 진행할수록 프로젝트에 대해서 더 많이 이해하듯이, 고객도 프로젝트가 진행될수록 더 잘 이해하게 된다. 개발 과정에서 고객은 자연스럽게 자신에게 필요한 요구사항을 더 잘 이해하게 되며 이러한 과정이 요구사항 변경의 주요한 원인이다.

일반적으로 요구사항이 얼마나 변경될까? 일반 프로젝트는 개발 시에 25% 정도의 요구사항 변경을 경험한다. 그것이 일반적인 프로젝트에서 재작업하는 이유의 70 ~ 85%를 차지한다.

다음은 구현 중에 발생하는 요구사항의 변경을 잘 다루기 위한 몇가지 방법이다.

• 요구사항 체크리스트로 요구사항의 품질을 평가한다.

**체크리스트: 요구사항**

구체적인 기능 요구사항

- 출처와 정확도, 값의 범위, 빈도를 포함해 시스템에 들어가는 모든 입력을 명시했는가?
- 목적과 정확도, 값의 범위, 빈도, 형식을 포함해 시스템에서 나오는 모든 출력을 명시했는가?
- 웹 페이지와 보고서 등을 위한 모든 출력 형식을 명시했는가?
- 모든 외장 하드웨어와 소프트웨어 인터페이스를 명시했는가?
- 데이터 교환과 오류 검사, 통신 프로트콜을 포함한 모든 외부 통신 인터페이스를 명시했는가?
- 사용자가 수행하고자 하는 모든 작업을 명시했는가?
- 각 작업에 사용되는 데이터와 작업의 결과로 얻은 데이터를 명시했는가?

비기능적(품질) 요구사항

- 모든 필수 연산에 대해서 예상 응답 시간을 사용자 관점에서 명시했는가?
- 처리 시간이나 데이터 전송률, 시스템 처리량과 같이 시간을 고려해야 하는 사항을 명시했는가?
- 보안 수준을 명시했는가?
- 소프트웨어 실패로 인한 결과와 실패 시 보호해야 하는 중요한 정보, 오류 검출과 복구를 위한 방법을 포함한 안정성에 대한 대책을 명시했는가?
- 최소 메모리와 디스크 공산을 명시했는가?
- 특정한 기능의 변경과 운영 환견의 변경, 다른 소프트웨어와의 인터페이스의 변경을 수용할 수 있는 능력을 포함한 시스템의 유지보수성을 명시했는가?
- 프로젝트의 성공이나 실패에 대해서 정의했는가?

요구사항의 품질

- 요구사항을 사용자의 언어로 작성했는가? 사용자도 동의 하는가?
- 각 요구사항이 다른 요구사항들과 충돌하지 않는가?
- 견고하면서 변경이 쉬워야 하는 것처럼 서로 충돌하는 특성들 사이의 트레이드오프를 명시했는가?
- 요구사항에서 설계에 대한 명세를 피하고 있는가?
- 요구사항이 일관된 수준으로 기술되어 있는가? 더 구체적으로 기술해야 할 요구사항은 없는가? 덜 구체적으로 기술해야 할 요구사항은 없는가?
- 따로 구현할 수 있으면서 여전히 이해할 수 있을 정도로 요구사항이 명확한가? 개발자도 그렇게 생각하는가?
- 각 항목이 문제점과 해결책에 관련되어 있는가? 각 항목을 문제 환경에서 그 근원까지 추적할 수 있는가?
- 각 요구사항이 테스트 가능한가? 각 요구사항이 만족스러운지를 결정하기 위한 개별적인 테스트가 가능한가?
- 요구사항에 대한 가능한 모든 변경 사항을 명시했는가?

요구사항의 완성도

- 개발을 시작하기 전에 정보를 사용할 수 없다면 그 부분을 명시했는가?
- 제품이 모든 요구사항을 충족한다는 점에서 요구사항이 완비되었다고 생각하는가?
- 모든 요구사항에 만족하는가? 구현이 불가능한 요구사항과 고객과 상사에게 보여주기 위해 넣은 요구사항을 제거했는가?

• 모든 사람이 요구사항 변경 비용에 대해서 알게 한다.

  • “오, 정말 괜찮은 생각이군요. 그런데 그 기능이 요구사항 문서에 없기 때문에 그 기능을 지금 추가할 것인지 아니면 나중에 추가할 것인지를 결정하기 위해서 일정을 변경하고 비용 추정을 다시 해야 할 것 같습니다.”

  • 요구사항 단계에서 변경하는 것이 나중에 변경하는 것보다 훨씬 비용이 적게든다는 점을 강조한다.

• 요구사항 변경 절차를 구축한다.

  • 고객이 마음을 바꿔 더 많은 기능이 필요하다는 것을 깨닫는 것 가체는 아무런 문제가 없다. 문제는 그러한 요구를 받아들일 수 없을 정도로 너무 자주 변경 사항을 제안한다는 점이다. 변경 사항을 관리하기 위한 절차를 구축하면 모든 사람이 행복해힌다.

• 변경 사항들을 수용하는 개발 접근 방법을 사용한다.

  • 진화적 프로토타이핑 접근 방법을 사용하면 기능을 구현할 인력을 투입하기 전에 시트템의 요구사항을 살펴볼 수 있다. 작게 구축하여 사용자로부터 약간의 피드백을 받고 설계를 약간만 수정한 다음, 약간의 변경을 거친 후에 조금더 만들어 나간다. 핵심은 사용자에게 빠르게 응답할 수 있도록 개발 주기를 짧게 가져가는 것이다.

• 프로젝트를 취소한다.

  • 요구사항이 매우 형편없거나 변하기 쉽고 앞에서 제안한 어떤 사항도 사용할 수 없다면 그 프로젝트는 취소해야 한다.

• 프로젝트의 사업성을 주시한다.

  • 요구사항 문제의 상당수는 프로젝트를 수행하는 사업상 목정을 고려하면 무의미해진다. 좋은 생각처럼 보였던 요구사항도 “기능”으로서 “점진적인 사업 가치”를 평가해 보면 터무니없는 아이디어로 보일 수 있다.

아키텍처 선행 조건

소프트웨어 아키텍처는 소프트웨어 설계의 상위 부분에 속하며 설계 중에서 더 상세한 부분을 담은 틀이다.

왜 아키텍처가 선행 조건에 포함될까? 그것은 아키텍처의 품질이 시스템의 궁극적임 품질을 결정하기 때문이다.

좋은 아키텍처는 구현을 쉽게 만든다. 나쁜 아키텍처는 구현을 거의 불가능하게 만든다.

고려해야 하는 아키텍처 구성 요소

• 프로그램 구조

  • 시스템 아키텍처는 시스템을 일반적인 말로 기술한 개요가 필요하다.

  • 아키텍처는 프로그램 내의 중요한 빌딩 블록을 정의해야 한다. 프로그램의 크기에 따라 각 빌딩 블록은 하나의 독립된 클래스일 수도 있고 많은 클래스로 구성된 서브시스템일 수도 있다. 빌딩 블록에 적어도 요구사항에서 명시한 기능이 하나는 들어가야 한다. 두 개 이상의 빌딩 블곡에서 처리되는 기능이 있다면 그것을 이용할 때 서로 충돌하지 않고 협력해야 한다.

  • 각 빌딩 블록이 책임져야 하는 내용은 반드시 명확하게 정의해야 한다. 하나의 빌딩 블록은 반드시 한 분야를 책임져야 하며 다른 빌딩 블록에 대해서는 가능한 한 조금 알아야 한다. 한 빌딩 블록이 다른 빌딩 블록에 대해 아는 내용을 최소화함으로써 설계에 관한 정보를 단일 빌딩 블록으로 제한할 수 있다.

• 주요 클래스

  • 아키텍처는 주요 클래스를 명시해야 한다.

  • 각각의 중요한 클래스가 맡은 역할과 클래스 사이의 상호작용을 어떻게 할 것인지를 규명해야 한다.

• 데이터 설계

  • 아키텍처는 중요한 파일과 테이블 설계를 기술해야 한다.

  • 리스트를 사용하여 id목록을 표현하는 방법을 선택했다면 왜 리스트가 비순차 접근 리스트나, 스택, 해시 테이블 보다 더 나은 선택인지를 설명해야 한다.

  • 데이터는 일반적으로 하나의 서브시스템이나 클래스에서만 직접 접근해야 한다.

  • 아키텍처는 왜 단일 db가 다중 db보다 좋은지 설명해야 하고, db가 일반 파일보다 좋은지 설명해야 하며 동일한 데이터에 접근하는 다른 프로그램과의 상호 연동이 가능한지 규명하고 데이터에 대해서 생성항 뷰를 설명해야 한다.

• 비지니스 규칙
  • 고객의 정보가 30초 이상 남아있으면 안 되는 비즈니스 규칙을 따라야 하는 시스템이 있다면 고객의 정보를 최신 정보로 유지하고 동기화 하기 위한 아키텍처 접근 방법에 그 규칙이 미치는 영향을 기술해야 한다.
• 사용자 인터페이스 설계
  • 웹 페이지 형식, GUI, 명령줄 인터페이스 등 주요 요소를 명시해야 한다.
• 자원 관리
  • db 연결과 스래드, 핸들과 같이 부족한 자원을 관리하기 위한 계획을 기술해야 한다. 메모리 관리는 드라이버 개발이나 임베디드 시스템과 같이 메모리가 한정된 애플리케이션을 다룰 때 중요한 분야다.
• 보안

  • 설계 단계와 코드 단계의 보안에 대한 접근 방법을 기술해야 한다.

  • 버퍼 처리 방법, 신뢰할 수 없는 데이터 처리 규칙, 암호화, 오류 메시지에 포함될 내용의 상세함 정도, 메모리에 있는 중요 데이터 보호와 같은 보안 관련 사항을 염두에 두고 작성해야 한다.

• 성능

  • 속도나 메모리, 비용 같은 자원 사이의 우선순위를 성능 목표에 명시해야 하는 경우라면 자원 사용도 그 내용에 포함해야 한다.

  • 추정치를 제공해야 하며 설계자가 그러한 목표에 도달할 수 있다고 믿는 이유를 설명해야 한다.

• 확장성
  • 사용자 수와 서버 수, 네트워크 노드의 수, db 레코드 수, db 레코드 크기, 드랜잭션 용량 등의 증가를 시스템이 어떻게 처리할 것인지를 기술해야 한다.
• 상호운용성
  • 다른 소프트웨어나 하드웨어와 함께 데이터나 자원을 공유할 거라고 예상된다면 그러한 기능을 어떻게 구현할 것인기 기술해야 한다.
• 국제화와 지역화

  • 대부분의 대화식 시스템에는 수십에서 수백 개의 안내 메시지와 상태 표시, 도움말 메시지, 요류 메시지가 들어 있다. 문자열을 사용하는 자원들은 미리 예측해야 한다.

  • 필요한 코드에 직접 문자열을 입력할 것인지, 클래스에 보관하고 클래스 인터페이스를 통해서 문자열을 참조할 것인지, 문자열을 리소스 파일에 저장할 것인지 결정 할 수 있다.

• 입력/출력
  • 필드나 레코드, 스트림, 파일 수준에서 어떤 입출려겨 오류가 검출되는지를 명시해야 한다.
• 오류 처리
  • 오류 처리를 위해서 굉장히 많은 코드가 작성되므로 오류를 처리하기 위한 일관된 방법이 아키텍처에 명시되어 있어야 한다.

• 장애 허용

  어떤 수의 제곱근을 구하는 데 있어서의 장애 허용은 다음과 같이 여러 가지 방법으로 구성

  • 오류를 발견했을 때 시스템이 자료를 백업하거나 다시 시도할 수 잇다. 처음 구한 답이 틀렸다면 잘 된 부분까지 백업하고 그 부분부터 계속한다.

  • 시스템은 주 코드에서 오류가 발생되었을 경우 보조 코드를 사용할 수 있다. 이 경우에는 첫 번째 답이 틀리면 시스템이 또 다른 제곱근 공식을 사용한다.

  • 시스템은 잘못된 값을 시스템의 나머지 부분에 악영향을 끼치지 않는 가짜 값으로 대체할 수 있다.

• 구조적인 실행 가능성

  • 아키텍처는 시스템이 기술적으로 실행 가능함을 보여줘야 한다.
• 구입과 구현 결정

  • 소프트웨어를 구현하는 가장 급진적인 해결책은 모든 것을 직접 구현하는 대신 사거나 무료로 제공되는 오픈소스 소프트웨어를 내려받는 것이다.

  • 시장에서 판매하는 컴포넌트를 사용하지 않는다면 맞춤 제작하는 컴포넌트가 판매 중인 라이브러리와 컴포넌트의 기능을 어떤 부분에서 능가할 것인지 설명해야 한다.

• 재사용 결정
  • 재사용된 소프트웨어가 다른 아키텍처 목표에 어떻게 부합할 것인지를 설명해야 한다.
• 변경 전략

  • 소프트웨어 제품을 만드는 일은 개발자와 사용자 모두에게 배우는 과정이기 때문에 제품은 개발 내내 변경될 수 있다.

  • 소프트웨어 설계자가 마주하고 있는 과제는 변경 사항을 수용할 수 있을 정도로 유연한 아키텍처를 만드는 것이다.

  • 한가지 사항을 변경할 때마다 소수의 클래스에만 영향을 미치는 점을 보여줘야한다.

    선행 조건에 소요되는 시간

일반적으로 제대로 진행되는 프로젝트는 요구사항과 아키텍처, 사전 계획 수립을 위해서 전체 노력의 10%에서 20% 정도와 전체 시간의 20% ~ 30% 정도를 투자한다.

요구사항 작업을 마친 다음 프로젝트의 나머지 시간을 추정한다.

고객: 일을 하는 데 드는 비용이 얼마죠?

기술자 : 무슨 일을 해야 하는데요?

요구사항을 파악하고 시간 및 비용 추정이 필요하다.