[소프트웨어공학] 단계별 프로젝트 계획 수립 전략과 계획 주도 개발

---

프로젝트 계획 수립

• 프로젝트 계획 수립은 프로젝트 생명 주기의 세 단계에서 일어남
• 소프트웨어 프로젝트 관리자의 가장 중요한 업무 중 하나
  • 작업들을 작은 작업들로 나눔
  • 나눈 작업들을 프로젝트 팀 멤버들에게 할당
  • 발생할 수 있는 문제들에 대해 예측
  • 문제들에 대한 잠정적인 해결책 준비
    
    
• 프로젝트 계획
  • 작업이 진행될 방법을 보이고 프로젝트의 진척사항을 평가하기 위해 사용
  • 프로젝트를 시작하면서 생성하고 프로젝트가 진행되면서 수정
    
    
• 프로젝트 계획 수립은 프로젝트 생명 주기의 세 단계에서 일어남
  • 제안 단계
    • 소프트웨어 시스템을 개발 또는 공급하는 계약을 수주하기 위해 응찰할 때
    • 작업 완수를 위한 자원을 가지고 있는지 판단하는 것을 돕는다
    • 언급해야 하는 가격 측정 계획을 위해 필요
      
      
  • 프로젝트 시작 단계
    • 누가 프로젝트에서 작업? 프로젝트를 어떻게 나눌까? 자원을 어떻게 할당? 등에 계획 수립
    • 준비하였던 초기의 노력 추정치를 개선 가능
      
      
  • 프로젝트 기간 내내
    • 소프트웨어와 그것의 개발에 관한 새로운 정보를 반영하기 위해 계획을 수정
    • 관리자는 구현 중인 시스템과 개발 팀의 능력에 대해 더 많은 것을 알게 됨
    • 소프트웨어 요구사항이 변경됨에 따라 작업 분해 구조는 변경되어야 하고 일정은 연장하게 됨

 

---

제안 단계에서의 프로젝트 계획 수립

• 필연적으로 예측을 근거 → 소프트웨어에 대한 완전한 요구사항이 없기 때문
• 요구되는 소프트웨어 기능에 대한 고수준의 설명을 근거로 제안서 작성
• 계획을 수주하면서 계획을 다시 수립
  • 제안서 작성 이후의 변경들과 시스템, 개발 프로세스, 개발 팀에 대한 새로운 정보들을 고려
    
    
• 응찰할 때, 시스템 개발을 위해 고객에게 제안할 가격을 계산해야 함
• 소프트웨어 프로젝트의 가격 책정에 주요한 매개변수
  • 인건비 → 대부분의 프로젝트에서 가장 큰 비용
  • 하드웨어와 소프트웨어 비용
  • 여비와 교육훈련 비용
• 상업용 시스템일 경우 대체적으로 가격이 싼 하드웨어 제품 사용
• 소프트웨어 비용이 비쌀 수 있음
  ← 미들웨어와 플랫폼 스프트웨어에 대한 사용 권리를 가져야 할 경우
  
  
• 프로젝트가 여러 다른 지역에서 개발될 때는 출장 비용 필요

 

---

시스템 개발 계약 승인 후

• 프로젝트 시동 계획을 세우기 위해 프로젝트 계획 개선
  • 시스템에 대한 요구사항 더 알아야 함
  • 목표 : 프로젝트 인원과 예산 편성에 대한 결정을 도울 수 있도록 충분히 상세히 작성
    
    
• 프로젝트 모니터링 방법 정의
  • 진행상황 추적하고 계획했던 진도와 비용들을 실제와 비교

 

---

프로젝트 시작 계획

• 프로젝트 계획은 항상 진화 ← 요구사항 변경, 기술 이슈, 개발 문제들 때문
  • 프로젝트 계획은 계속 유용한 문서로 남아있어야 함
    
    
• 애자일 방법이 사용돼도 프로젝트 시작 계획 필요
  • 기업은 자원들을 프로젝트에 할당하는 방법에 대한 계획이 필요하기 때문
  • 작업 분할과 프로젝트 일정에 대한 필수적인 정보만 포함 → 상세한 계획 X
  • 소프트웨어 각각의 릴리스에 대해 비공식적인 프로젝트 계획과
    노력 추정치를 계획 수집 프로세스에 연관된 팀 전체가 같이 만듦

 

 

---

소프트웨어 가격 책정

• 고객을 위해 개발되는 소프트웨어 시스템의 가격
  = (개발 비용) + (개발자를 위한 이윤)
  • 실제론 이렇게 안단순함
• 가격 책정할 때 조직적, 경제적, 정치적, 비즈니스 관련 사항들을 폭넓게 고려해야 함
• 가격 책정에 영향 미치는 요인
  • 계약 조건
    • 어떤 고객은 개발자들이 소스코드에 대한 소유권을 보유하고
      그것을 다른 프로젝트에 재사용하는 것을 허영 하고 싶을 수 있음
      → 개발자에 대한 소스 코드의 가치를 반영하여 책정되는 가격이 낮아짐
      
      
  • 비용 추정의 불확실성
    • 어떤 조직이 자신의 비용 추정에 대해 확신하지 못한다면,
      비상 상황에 대비하여 정상적인 이윤보다 많게 책정할 수도 있음
      
      
  • 재정 건전성
    • 재정적 문제를 가진 기업들은 계약을 수주하기 위해 가격을 낮게 책정할 수 있다.
      
      
  • 시장 기회
    • 개발 조직은 소프트웨어 시장의 새로운 영역에 진입하여 위해 가격을 낮게 책정할 수 있다.
      
      
  • 요구사항 변동성
    • 요구사항이 변경될 거 같으면, 조직은 계약을 수주하기 위해 가격을 낮출 것이다.
      계약을 수주한 이후에는, 요구사항 변경에 대해 높은 가격을 부과할 수 있다.

 

---

가격 책정 전략

• 낮은 가격으로 책정
  • 회사가 미래의 기회를 위해서 직원을 유지하고자 할 때,
    직원들을 유지하기 위한 계약을 얻기 위해 시스템 가격을 낮게 책정
  • 새로운 시장에 진입하기 위해
    
    
• 높은 가격으로 책정
  • 구매자가 고정 가격 계약을 체결하기를 원할 경우,
    예상치 못한 리스크에 대비하여 높게 책정
    
    
• 합의에 의한 가격 결정(Pricing to win)
  • 고객이 지불할 것으로 예상되는 가격에 대해 기업이 어떤 아이디어를 가지고 있고,
    고객의 기대 가격을 근거로 하여 계약에 입찰하는 것을 의미
  • 비윤리적이고 비능률적으로 보일 수 있지만, 고객과 시스템 공급자 모두에게 이득

 

---

프로젝트 비용 산정

• 제안서를 근거로 합의
• 이후, 상세한 프로젝트 명세서를 확정하기 위해 고객과 공급자 사이에 협상이 진행
  • 명세서는 합의된 비용에 의해 제약
  • 구매자와 판매자는 반드시 시스템 기능으로 수용 가능한 것에 대해 합의해야 함
    
    
• 프로젝트에서 고정된 인자는 프로젝트 요구사항이 아닌 비용

 

 

---

계획 주도 개발(계획 기반 개발)

• 개발 프로세스가 상세하게 계획된 소프트웨어 공학 접근법
  • 소프트웨어 공학 관리 기법을 기반으로 하고 대형 소프트웨어 개발 프로젝트들의 전통적인 방식
    
    
• 관리자들은 프로젝트 의사 결정을 지원하고 진척사항을 측정하는 수단으로 활용
• 각각의 시스템에 알맞은 접근법
  • 대규모의 보안성 중심 시스템과 안전성 중심 시스템
    • 계획 주도적 접근법이 적합
    • 광범위한 선행 분석을 요구하고, 사용되기 전에 반드시 인증받아야 함
      
      
  • 급격하게 변화하는 경쟁 환경에서 사용되는 소형에서 중형 규모의 정보 시스템
    • 애자일 방법이 적합

 

---

계획 주도 개발의 장단점

• 장점
  • 초기의 계획 수립이 조직의 이슈들을 고려할 수 있게 함
  • 잠재적인 문제들과 종속성들이 프로젝트가 진행 중일 때가 아닌 프로젝트가 시작하기 전에 발견
    
    
• 단점
  • 소프트웨어가 개발되고 사용되는 환경에 대한 변화 때문에 초기의 결정들이 갱신되어야 한다는 점

 

---

프로젝트 계획

• 계획 주도 개발 프로젝트에서, 프로젝트 계획은 다음의 내용을 정리
  • 작업을 수행하기 위해 프로젝트에서 이용 가능한 자원, 작업 분할, 일정
    
    
• 계획은 프로젝트와 개발 중인 소프트웨어에 대한 리스크와 리스크 관리를 위해 사용할 접근법으로 식별
• 프로젝트 계획 주요 포함 사항
  • 소개
    • 프로젝트의 목적을 간략하게 기술하고 프로젝트 관리에 영향을 미치는 제한 조건을 정리
      
      
  • 프로젝트 조직
    • 개발 팀의 조직 방식, 참여하는 사람, 팀에서의 역할 기술
      
      
  • 리스크 분석
    • 잠재적인 프로젝트 리스크, 발생 가능성, 제안된 리스크 감소 전략들을 기술
      
      
  • 하드웨어와 소프트웨어 자원 요구사항
    • 개발을 수행하는데 필요한 하드웨어와 지원 소프트웨어 명시
      
      
  • 작업 분할
    • 프로젝트를 분할하여 액티비티들로 나눔
    • 각각의 프로젝트 액티비티에 대한 입력과 출력 식별
      
      
  • 프로젝트 일정
    • 액티비티들 사이의 종속성, 각각의 이정표에 도달하는데 필요한 추정 시간,
      액티비들에 대한 인원 할당 내용
      
      
  • 모니터링과 보고 기법
    • 작성되어야 하는 관리 보고서들, 만드는 시기, 사용될 프로젝트 모니터링 기법들을 정의
      
      

 

---

부가적인 프로젝트 계획

• 형상 관리 계획
  • 사용되는 형상 관리 절차와 구조들을 서술
    
    
• 배치 계획
  • 소프트웨어, 연관된 하드웨어를 고객의 환경에 배치할 방법을 서술
  • 기존 시스템으로부터 데이터를 이전하는 것에 대한 계획을 포함해야 한다.
    
    
• 유지보수 계획
  • 유지보수 요구사항, 비용, 노력을 예측
    
    
• 품질 계획
  • 프로젝트에서 사용될 품질 절차와 표준들을 서술
    
    
• 검증 계획
  • 시스템 검증을 위해 사용될 접근법, 자원, 일정을 서술

 

---

계획 수립 프로세스

• 프로젝트 시동 단계에서 최초의 프로젝트 계획을 만들 때 시작하는 반복적 프로세스
• 계획 변경은 필연적
  • 프로젝트 동안 시스템과 프로젝트팀에 대한 더 많은 정보가 점점 이용 가능해짐
    → 요구사항, 일정, 리스크 변경들을 반영하기 위해 정기적으로 계획 갱신
    
    
  • 비즈니스 목표 변경은 곧 프로젝트 계획 변경으로 이어짐

 

---

계획 가정

• 프로젝트 계획을 정의할 때는 항상 현실적인 가정을 해야 함
• 초기의 가정과 일정은 비관적이어야 하고 예상치 못한 문제들을 고려해야 함
  • 프로젝트 동안 어떤 문제들이 항상 발생하고 이 문제들이 프로젝트를 지연되게 만든다.
    
    
• 계획에 비상 대책을 포함하여 문제가 발생해도 인도 일정이 심하게 지장 받지 않도록 해야 함

 

---

리스크 완화

• 개발 작업에 대한 상당한 지연이 발생하는 심각한 문제 발생 시 수행할 수 있는 행동과 작업
  • 실패 리스크를 줄이기 위한 리스크 완화 행동
  • 프로젝트에 대한 계획도 다시 수립
  • 프로젝트 제한조건들과 산출물들에 대한 고객과의 재협상(선택)
    • 작업이 완결되어야 하는 때에 대한 새로운 일정이 수립되어야 하고 고객과 합의를 해야 함
      
      
• 검토 결과 프로젝트를 취소할 수도 있음
  • 프로젝트 취소 요인
    • 기술적 또는 관리의 실패에 대한 결과
    • 프로젝트에 영향을 주는 외부 환경의 변화가 더 큰 요인일 수도