맨먼스 미신

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요

맨먼스 미신은 프레드 브룩스가 1975년에 출판한 소프트웨어 공학 서적으로, 소프트웨어 개발의 어려움을 다룬다. 이 책은 브룩스의 법칙, 즉 늦어진 소프트웨어 프로젝트에 인력을 추가하면 오히려 더 늦어진다는 주장을 핵심으로 한다. 또한, 은탄환은 없다는 주장을 통해 소프트웨어 개발의 본질적인 어려움을 강조하며, 세컨드 시스템 효과, 제거할 수 없는 오류의 경향성, 개념적 무결성 등 다양한 개념을 제시한다. 브룩스는 프로젝트 견적, 의사소통, 코드 동결, 특수 도구 사용 등 소프트웨어 개발의 효율성을 높이기 위한 구체적인 방법론도 제시한다.

더 읽어볼만한 페이지

소프트웨어 개발 책 - 프로그래밍의 도
1975년 책 - 정의론
정의론은 존 롤스가 원초적 입장과 무지의 베일이라는 개념을 통해 공정하고 평등한 사회를 위한 정의의 원칙을 제시하며, 최대 자유 평등 원칙, 차등 원칙 및 기회균등 원칙을 포함하는 사회 정의 이론으로, 자유주의적 평등주의 이념의 핵심으로 평가되어 사회 개혁 논의에 철학적 기반을 제공한다.
1975년 책 - 감시와 처벌
미셸 푸코의 《감시와 처벌》은 18세기 이후 서구 사회에서 권력이 공개적 고문에서 은밀한 감시 체계로 전환되며 개인을 통제하는 방식과 사회 통제의 새로운 메커니즘을 분석한 저서이다.
소프트웨어 프로젝트 관리 - 소프트웨어 개발
소프트웨어 개발은 요구사항 분석, 설계, 코딩, 테스트, 배포, 유지보수를 포함하는 컴퓨터 프로그램 및 관련 데이터를 만드는 과정으로, 다양한 방법론과 도구가 사용되며, 개발자 외에도 다양한 전문가들이 참여한다.
소프트웨어 프로젝트 관리 - 애자일 소프트웨어 개발
애자일 소프트웨어 개발은 1990년대에 등장하여 개인과 상호작용, 작동하는 소프트웨어, 고객과의 협력, 변화에 대한 대응을 핵심 가치로 삼고 적응형 계획과 반복적 실행을 통해 시장 출시 속도와 위험 완화를 추구하는 소프트웨어 개발 방법론이다.

맨먼스 미신 - [서적]에 관한 문서
기본 정보
제목	맨먼스 미신
원제	The Mythical Man-Month: Essays on Software Engineering
저자	프레더릭 브룩스
국가	미국
언어	영어
출판 정보
출판사	애디슨 웨슬리
출판일	1975년
주제
주제	소프트웨어 공학 소프트웨어 프로젝트 관리

2. 판본

The Mythical Man-Month^영어은 1975년에 초판이 발행되었고, 1982년에 수정판이 나왔으며, 1995년에는 저자의 해설과 "은탄환은 없다"(No Silver Bullet) 에세이를 재수록한 4개의 장이 추가된 기념판이 발행되었다.

3. 책에 제시된 아이디어

이 책은 1975년에 처음 출판되었고, 1982년에 수정판이 나왔으며, 1995년에는 저자의 해설과 "은탄환은 없다" 에세이를 재수록한 4개의 챕터가 추가된 기념판으로 재출판되었다.^[1] 브룩스는 IBM에서 OS/360이라는 운영체제 개발에 참여했던 경험을 바탕으로, 일정이 실패하는 몇 가지 원인에 대해 논하며, 그 중 가장 널리 알려진 것은 브룩스의 법칙이다.^[1]

그는 프로젝트 관리자가 소프트웨어 프로젝트 관리에서 반복해서 실수를 저지르는 경향이 있다고 지적하며, 자신의 책에 대해 "모든 사람이 이 책을 읽지만, 아무도 이 책에서 말하는 것을 실천하지 않기 때문이다."라는 역설을 말한다.^[1]

1977년에 출판된 일본어 번역 서적에서는 『소프트웨어 개발의 신화』라는 제목이었고, 1996년, 2002년에 출판된 일본어 번역 서적에서는 『인월의 신화 늑대인간을 쏘는 은탄환은 없다』라는 제목이었다.^[1]

책 표지와 제1장 "타르의 늪"에는 타르 늪과 여러 짐승들의 그림이 그려져 있으며, 20주년 기념판에 새롭게 추가된 제16장 "은탄환은 없다"의 표지에는 늑대인간 그림이 그려져 있다.^[1]

3. 1. 맨먼스 미신 (The Mythical Man-Month)

브룩스의 법칙은 이 책의 핵심 내용이다. 브룩스는 "''늦어진 소프트웨어 프로젝트에 인력을 추가하면 더 늦어진다''"라고 말한다. 여기서 맨먼스는 한 사람이 한 달 동안 수행하는 작업량을 나타내는 가상의 단위이다. 브룩스는 맨먼스로 작업량을 측정하는 것은 허구이며, 복잡한 프로그래밍 프로젝트는 작업자 간의 소통 없이는 개별 작업으로 완벽하게 나눌 수 없다고 지적한다.^[1]

따라서 일정보다 늦어진 프로젝트에 더 많은 프로그래머를 투입하면, 새로운 프로그래머가 프로젝트를 배우는 시간과 늘어난 의사소통으로 인해 작업 시간이 줄어들어 오히려 프로젝트가 더 늦어진다. ''n''명의 사람들이 서로 소통해야 할 때, ''n''이 증가함에 따라 산출량은 감소하고, 음수가 되면 사람을 추가할 때마다 프로젝트가 더욱 지연된다.^[1]

그룹 내 상호 통신 공식: ''n''(''n'' − 1)/2^[1]
예시: 50명의 개발자는 50 × (50 – 1)/2 = 1,225개의 통신 채널을 제공한다.^[1]

브룩스는 "시간이 부족해서 실패한 프로그래밍 프로젝트가, 다른 모든 원인으로 실패한 프로그래밍 프로젝트보다 많다"고 지적하며, 그 원인이 "인월"이라는 개념으로 견적을 내기 때문이라고 말한다. 즉, 인월을 사용하여 스케줄을 견적함으로써 견적이 실패하고 스케줄이 늦어지는 것이다. 이러한 상황에서 프로젝트 인원을 늘리는 것은 불에 기름을 붓는 격이라고 브룩스는 주장한다. 그는 이를 "브룩스의 법칙"이라고 정의한다.^[1]

Brooks's Law^영어: 늦어지고 있는 소프트웨어 프로젝트에 인원을 투입해도, 그 프로젝트를 더욱 늦어지게 할 뿐이다.^[1]

브룩스는 소프트웨어 프로젝트에 인원을 추가하면 재배치 자체에 소비되는 노력, 새로운 인원의 교육, 추가적인 상호 연락으로 인해 전체적으로 필요한 노력이 증가한다고 분석한다. 따라서 인원 추가는 늦어지는 프로젝트의 해결책이 될 수 없다. 대신 브룩스는 스케줄을 재정비하거나 작업 규모를 축소할 것을 제안한다. 그는 스케줄의 1/3을 설계, 1/6을 코딩, 1/4을 컴포넌트 테스트, 1/4을 시스템 테스트에 할당하는 방식을 사용한다.^[1]

3. 2. 은탄환은 없다 (No Silver Bullet)

브룩스는 《맨먼스 미신》 기념판에 "No Silver Bullet—소프트웨어 공학의 본질과 우연"이라는 장과 "'No Silver Bullet' 재점화"라는 장을 추가하여 자신의 주장에 대한 추가적인 성찰을 제시했다.

브룩스는 은탄환은 없다고 주장한다. 그는 "생산성, 신뢰성, 단순성 측면에서 10년 안에 10배 향상을 약속하는 단일 기술이나 관리 기법은 없다"고 강조한다.^[1]

이 주장은 암달의 법칙이 "병렬화 가능"과 "엄격한 직렬"을 구분하는 것과 유사하게, 우연적 복잡성과 본질적 복잡성을 구분하는 것에 기반을 두고 있다.

프로그래밍은 프로그램 크기의 거듭제곱으로 증가한다.
발표된 몇몇 연구에 따르면 지수는 약 1.5이다. (뵘의 데이터는 이와 전혀 일치하지 않지만 1.05에서 1.2 사이에서 변화한다.)
적절한 고수준 언어를 사용하면 프로그래밍 생산성이 5배나 증가할 수 있다.

3. 3. 세컨드 시스템 효과 (The Second-System Effect)

세컨드 시스템 효과는 건축가가 두 번째 시스템을 설계할 때, 첫 번째 시스템에서 제약 때문에 추가하지 못했던 기능들을 모두 포함시키려는 경향이 있어, 가장 위험한 시스템이 될 수 있다는 개념이다. 따라서 두 번째 시스템을 시작할 때 엔지니어는 과도한 설계를 하기 쉽다는 점을 명심해야 한다.^[1]

> 세컨드 시스템은 인간이 설계한 것 중 가장 위험하다. 왜냐하면 지나치게 만들어 버리는 것이 일반적인 경향이기 때문이다.

한국의 경우, 정부 주도의 대규모 IT 프로젝트에서 이러한 세컨드 시스템 효과가 나타나는 경우가 종종 있다. 초기 시스템의 문제점을 개선하려는 의욕이 과도한 기능 추가와 복잡성 증가로 이어져, 결국 실패하는 사례가 발생한다.^[1]

3. 4. 제거할 수 없는 오류의 경향성

복잡한 시스템에서는 일정량의 오류가 불가피하게 발생하며, 발견된 오류를 수정하려는 시도는 다른 오류를 발생시키는 경향이 있다는 것이 저자의 지적이다. 이러한 경향은 소프트웨어 개발 과정에서 피할 수 없는 문제로 여겨진다.

3. 5. 진행 추적

프레더릭 브룩스는 "대규모 소프트웨어 프로젝트가 1년 늦어지는 이유는 무엇인가? 답: 하루하루 늦어지기 때문이다!"라고 썼다.^[1] 여러 부분에서 발생하는 점진적인 지연이 쌓여 결국 전체적으로 큰 지연을 초래한다. 각 관리 계층에서 개별적인 작은 단계를 달성하기 위해 지속적인 주의가 필요하다. 한국의 IT 프로젝트에서는 상명하달식 의사 결정 구조와 경직된 일정 관리로 인해, 작은 문제들이 초기에 해결되지 않고 누적되어 큰 문제로 이어지는 경우가 많다.

3. 6. 개념적 무결성 (Conceptual Integrity)

사용자 친화적인 시스템을 만들기 위해서는 시스템이 개념적 무결성을 갖춰야 하며, 이는 아키텍처와 구현을 분리해야만 달성할 수 있다. 사용자를 대신하여 한 명의 수석 아키텍트 (또는 소수의 아키텍트)가 시스템에 무엇을 포함하고 무엇을 제외할지 결정한다. 아키텍트 또는 아키텍트 팀은 시스템이 무엇을 해야 하는지에 대한 아이디어를 개발하고, 이 비전이 팀원들에게 제대로 이해되도록 해야 한다. 누군가의 참신한 아이디어가 전체 시스템 설계에 자연스럽게 부합하지 않는다면 포함되지 않을 수 있다. 실제로, 사용자 친화적인 시스템을 보장하기 위해, 시스템은 의도적으로 실제로 제공할 수 있는 기능보다 "더 적은" 기능을 제공할 수 있다. 요점은, 시스템이 사용하기 너무 복잡하면, 아무도 시간을 내어 배우지 않기 때문에 많은 기능이 사용되지 않을 것이라는 점이다.^[1]

브룩스는 시스템 개발에서 개념 통합의 중요성을 지적한다.^[1]

:: 개념이 통합된 시스템은 더 빠르게 구축되고, 더 빠르게 테스트할 수 있다.^[1]

:: 기본 설계와 구현을 분리하는 것은 매우 큰 프로젝트에서 개념을 통합하는 데 매우 강력한 방법이다(이는 작은 프로젝트에도 해당된다).^[1]

:: 개념을 통합하려면 설계는 한 명의 인간에서 합의된 소규모 그룹으로 진행되어야 한다.^[1]

즉, 시스템의 기본 설계는 한 명 또는 소수의 아키텍트가 수행한다. 따라서 누군가 "매우 기발한" 아이디어를 생각해 내더라도, 그 아이디어가 시스템 전체의 설계에 잘 맞지 않으면 기각된다.^[1]

"개념적 통합성은 시스템 설계에서 가장 중요한 고려 사항이다."^[1]
개념적 통합성을 달성하기 위해 설계는 한 명의 사람 또는 합의된 소규모 그룹에서 진행되어야 한다.^[1]
"구현으로부터 아키텍처 노력을 분리하는 것은 매우 큰 프로젝트에서 개념적 통합을 얻는 매우 강력한 방법이다." [작은 프로젝트에서도 마찬가지다.]^[1]
개념적으로 통합된 시스템은 더 빨리 구축하고 테스트할 수 있다.^[1]

한국의 개발 문화에서는 빠른 개발 속도를 중시하는 경향이 있어, 개념적 무결성보다는 기능 추가에 집중하는 경우가 많다. 이는 장기적으로 시스템의 유지보수성을 저하시키고 사용자 경험을 해칠 수 있다.

3. 7. 매뉴얼

주요 설계자는 시스템 명세서 매뉴얼을 작성한다. 이 매뉴얼은 시스템의 외부 명세, 즉 사용자가 보게 될 모든 것을 자세히 설명해야 한다.^[1] 구현 팀과 사용자로부터 피드백이 들어오면 매뉴얼을 수정해야 한다.^[1]

수석 아키텍트가 작성한 아키텍처는 매뉴얼로서 역할을 한다. 따라서 매뉴얼은 시스템의 외부 사양을 상세하게 기술해야 하는데, 여기서 "상세하게 기술한다"는 것은 사용자가 시스템을 사용할 때 보이는 모든 것을 기술한다는 것이다. 그리고 매뉴얼은 구현 담당자나 시스템 이용자로부터 의견이 제시될 때 개정해야 한다.^[1]

3. 8. 파일럿 시스템 (The Pilot System)

새로운 종류의 시스템을 설계할 때, 팀은 (의도했든 아니든) 폐기용 시스템을 설계하게 된다. 이 시스템은 이후 시스템의 전면적인 재설계를 유발하는 기술들을 드러내는 "파일럿 플랜" 역할을 한다. 이 두 번째, 더 "영리한" 시스템이 고객에게 인도되어야 한다. 왜냐하면 파일럿 시스템의 인도는 고객에게 고통만 안겨줄 뿐이며, 시스템의 명성을 해치고 심지어 회사를 망하게 할 수도 있기 때문이다.

브룩스는 파일럿 시스템이라는 개념을 소개한다. 화학 엔지니어는 프로세스를 실험실에서 바로 공장으로 가져가지 않고, 규모를 확대하고 보호되지 않은 환경에서 운영하는 경험을 쌓기 위해 파일럿 플랜트를 만든다. 브룩스는 소프트웨어 프로젝트에서도 이와 같은 방식을 활용해야 한다고 주장한다. 그는 소프트웨어 엔지니어는 실제 제품을 납품하기 전에 규칙적으로 시제품 시스템을 실지 테스트하는 것을 아직 수행하지 않고 있다고 지적한다.

브룩스에 따르면, 처음에 만들어진 시스템은 조악하다. 많은 프로젝트에서 처음 만들어진 시스템은 너무 느리고, 너무 크고, 사용하기 어렵기 때문에 거의 쓸모가 없다. 이러한 세 가지 문제가 모두 갖춰진 경우도 있다.

따라서 사용해도 될 만큼의 품질을 갖추지 못한 첫 번째 시스템을 사용자에게 납품하면 시간 벌이는 될 수 있지만, 결국 사용자를 격렬하게 괴롭히고, 재설계를 하는 동안 시스템을 지원하는 개발자를 짜증나게 하며, 제품의 평판이 돌이킬 수 없을 정도로 나빠지게 된다.

그렇기 때문에 브룩스는 "버릴 계획을 세워야 한다. 어쨌든 그렇게 될 것이다."라고 주장한다.

첫 번째 시스템이 버려진 후에 개발되는 시스템을 두 번째 시스템이라고 한다. 이 두 번째 시스템은 첫 번째 시스템보다 세련되었으며, 제품으로 납품해야 하는 것은 바로 이 두 번째 시스템이다.

3. 9. 공식 문서 (Formal Documents)

모든 프로젝트 관리자는 프로젝트 목표, 목표 달성 방법, 목표 수행 주체, 목표 달성 시점 및 소요 비용을 정의하는 핵심적인 공식 문서를 작성해야 한다.^[1] 이러한 문서는 다른 방법으로는 파악하기 어려운 불일치를 드러낼 수도 있다.^[1]

형식에 맞는 문서는 다음과 같은 역할을 한다.^[1]

역할
프로젝트 목표를 향한 이정표
프로젝트 목표를 어떻게 달성할지에 대한 이정표
목표 달성을 담당하는 사람을 명확히 함
각 목표에 대해 달성을 예정하고 있는 시기
각 목표에 대해 필요한 비용

형식에 맞는 작은 집합은 또한 프로젝트 수행에 불일치가 있음을 명확히 보여준다.^[1] 이러한 불일치는 형식에 맞는 작은 집합이 없는 경우에는 그 존재를 인식하기 어렵다.^[1]

3. 10. 프로젝트 견적 (Project Estimation)

소프트웨어 프로젝트의 시간 견적을 할 때는 컴파일러(제품으로서의 품질 수준을 갖는 소프트웨어)를 개발하는 것이 애플리케이션 소프트웨어를 개발하는 것보다 3배 어렵다는 것을 기억해야 한다.^[3] 그리고 시스템 프로그램(운영 체제, 제품으로서의 품질 수준을 가지고 시스템으로 통합된 소프트웨어)을 개발하는 것은 컴파일러를 개발하는 것보다 3배 더 어렵다.^[3]

또한 1주일 작업 중 몇 시간을 기술적인 문제에 쏟을지 마음속에 새겨두어야 한다. 이 일은 관리에 소비하는 시간이나 기술적이지 않은 문제(회의나 병가 등)에 소비하는 시간에 대해 생각하는 것보다 중요하다.^[3]

3. 11. 의사소통 (Communication)

프로그래머는 어떤 것도 가정해서는 안 된다. 즉, 프로그래머는 자신이 구현하는 기능에 대해 애매한 점이 있으면 스스로 마음대로 상상하지 말고 아키텍트에게 기능의 의도를 명확히 하기 위해 질문해야 한다.^[1] 설계자는 프로젝트의 전체 그림을 구성하고 이를 다른 사람에게 전달할 책임이 있다.^[2]

설계 팀이 크더라도, 작은 결정들을 일관성 있게 유지하기 위해서는 한두 명이 설계를 담당해야 한다.^[3] 설계자가 구현자들의 질문에 전화로 응답하고 설명하는 것이 중요하며, 그 대화를 기록하여 공개하는 것은 필수 사항이다. (전자 메일은 현재 선택 가능한 수단 중 하나이다.)^[3] 팀은 가능한 한 다양한 방법(정기적인 프로젝트 회의, 기술 브리핑, 공유 공식 프로젝트 워크북, 전자 메일)으로 서로 소통해야 한다.^[3]

3. 12. 외과 수술팀 (The Surgical Team)

수술 팀에서 한 명의 외과 의사가 지휘를 맡고 가장 중요한 작업을 수행하며, 다른 팀원들은 외과 의사를 보조하거나 덜 중요한 부분을 돕는다. 이와 마찬가지로 소프트웨어 프로젝트에서도 "뛰어난" 프로그래머 한 명이 중요한 시스템 구성 요소를 개발하고, 다른 팀원들이 그 프로그래머에게 필요한 것을 제공하는 방식으로 활용할 수 있다.^[1] 브룩스는 "유능한" 프로그래머가 평범한 프로그래머보다 일반적으로 5~10배 더 생산적이라고 보았다.^[1]

색크만, 그랜트, 에릭슨의 연구에 따르면, 같은 훈련을 받고 2년간의 경험을 쌓았더라도 매우 우수한 전문 프로그래머는 서투른 프로그래머보다 10배의 생산성을 낼 수 있다.^[1]

주임 프로그래머와 외과 수술 팀 조직을 채택하면 의사소통이 철저하게 절감되어 소수로 설계함으로써 제품의 통합성을 기대할 수 있다. 또한, 다수의 인원으로 개발함으로써 전체적인 생산성도 기대할 수 있다.^[1]

3. 13. 코드 동결 및 시스템 버전 관리 (Code Freeze and System Versioning)

소프트웨어는 눈에 보이지 않기 때문에, 새로운 시스템이 어느 정도 만들어져 사용자가 직접 사용해 보기 전까지는 많은 것들이 명확하지 않다. 사용자는 시스템을 사용하면서 시스템을 더 깊이 이해하게 되고, 이에 따라 새로운 요구를 할 수도 있다. 이러한 변경 요구는 특정 시점까지는 가능하지만, 어느 시점을 넘어서면 코드가 동결되어야 한다. 그렇지 않으면 시스템은 영원히 완성되지 않기 때문이다. 코드 동결 이후 받아들여지지 않은 변경 요구는 해당 시스템의 '''다음''' 버전까지 연기된다.

3. 14. 특수 도구 (Specialized Tools)

각 프로그래머는 각자 특별한 도구를 갖는 대신, 각 팀은 해당 팀이 수행하는 작업에 맞춰 고도로 맞춤화된 도구(예: 명세에 따라 코드를 생성하는 코드 생성기 도구)를 만들 수 있는 지정된 도구 제작자를 두어야 한다. 또한, 시스템 전체의 도구는 프로젝트 매니저가 감독하는 공통 도구 팀에서 구축해야 한다.

3. 15. 소프트웨어 개발 비용 절감

브룩스는 소프트웨어 개발 비용을 줄이는 두 가지 방법을 제시하고 있다.

시스템 아키텍처가 완성된 후에 프로그래머를 프로젝트에 참여시킨다. 시스템의 기본 설계를 완성하는 데 몇 달이 걸리는 경우가 많기 때문에, 프로그래머가 일찍 프로젝트에 참여해 봐야 할 일이 없을 수 있기 때문이다.
소프트웨어를 모두 개발하는 대신 "즉시 구할 수 있는" 기성품 소프트웨어가 이미 있다면 그것을 구입한다.

4. "맨먼스 미신" 이후 20년

브룩스는 초판 출판 20년 후, 초판의 내용 중 여전히 유효한 것, 틀렸다고 생각하는 것, 시대에 뒤떨어진 것, 그리고 소프트웨어 엔지니어링에서 새롭게 등장한 것에 대한 논의를 추가했다.

5. 한국 소프트웨어 산업에 대한 시사점

브룩스는 "맨먼스 미신"에서 한국 소프트웨어 산업에 다음과 같은 시사점을 제시한다.

먼저, 시간이 부족해서 실패하는 프로그래밍 프로젝트가 많다는 점을 지적한다.^[1] 그 원인으로 '인월'이라는 개념을 사용해 견적을 내기 때문이라고 말한다. 브룩스는 인월의 문제점에 대해 다음과 같이 지적한다.^[2]

Brooks|브룩스^영어는 비용 계산 중심으로 만들어진 견적 방법이 노동력과 진척을 혼동하게 만든다고 설명한다. 인월은 사람과 달(月)이 대체 가능하다는 것을 암시하기 때문에 사람을 현혹시키는 위험한 신화라고 한다.^[2]

즉, 인월을 사용해 스케줄을 견적하면 실패하고 늦어지게 된다. 이런 상황에서 프로젝트 인원을 늘리는 대책이 흔히 사용되지만, 이는 불에 기름을 붓는 격이라고 브룩스는 주장한다. 그는 이를 "브룩스의 법칙"이라고 부르며 다음과 같이 정의한다.^[3]

Brooks|브룩스^영어의 법칙에 따르면, 늦어지고 있는 소프트웨어 프로젝트에 인원을 투입하면 오히려 프로젝트가 더욱 늦어진다.^[3]

브룩스는 그 이유를 다음과 같이 분석한다.

소프트웨어 프로젝트에 인원을 추가하면, 재배치 자체에 소비되는 노력과 작업 중단, 새로운 인원 교육, 추가적인 상호 연락 등으로 인해 전체적으로 필요한 노력이 증가한다.

따라서 인원을 추가하는 것으로는 늦어지는 프로젝트에 대처할 수 없다. 그래서 브룩스는 스케줄이 늦어질 때 다음과 같은 방법을 제안한다.

# 스케줄을 재정비한다.

# 작업 규모를 축소한다.

브룩스는 스케줄을 운용하는 기준으로, 설계에 1/3, 코딩에 1/6, 컴포넌트 테스트에 1/4, 시스템 테스트에 1/4를 할당하는 방법을 제시했다.

참조

_[1] 뉴스 Quoted Often, Followed Rarely https://money.cnn.co[...] CNN 2005-12-12
_[2] 서적 The Mythical Man-month: Essays on Software Engineering https://web.eecs.umi[...] Addison-Wesley Publishing Company 1975
_[3] 서적 The Mythical Man-Month https://www.amazon.c[...]

본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com