[소프트웨어 프로젝트 관리] 프로젝트 단계

• 소프트웨어 프로젝트의 개념적 단계 : 발견 - 발명 - 구현
  • 단계를 분명하게 긋는 계획은 좋은 것이 아니므로, 어느정도 겹치게 두는 것이 좋음
  • 발견, 발명 : 불확실한것을 확실한 것으로 바꾸는 과정
  • 구현 : 확실한 가능성을 실현하는 과정

 

• 단계별 납품 계획
  
  • 각 단계에서 적극적으로 리스크 관리하여 리스크 요인 제거
  • 다음 단계를 위한 상세 계획 수립

소프트웨어 단계별 납품 계획

 

• 소프트웨어 프로젝트 단계
  • 사전 계획
    • 프로젝트 비전 및 목표 수립
      • 프로젝트를 하는 이유 제시
    • 계획 및 진척도 공개
    • 리스크 관리
      
      • 소프트웨어 프로젝트는 Complexity 특성을 가지므로, 복잡하고 위험하여 예산, 일정 초과 등의 가능성이 높아 리스크 관리가 필요
      • 전체 5% 정도의 노력을 리스크 관리에 투자하면 프로젝트를 성공할 확률이 50 ~ 75% 정도 높아짐
      • 리스크 산정 기준 : 발생 가능성 + 영향도
      • 10대 리스크 목록을 작성하여 관리하면 좋음
    • 인력 관리
      • 프로젝트 진행은 인적 자원의 능력 향상을 포함하고 있어야 함
    •  위의 내용을 포함한 소프트웨어 개발 계획서를 작성해야 함
  • 요구사항 개발
    • 과정
      1. 요구사항 수집
         • 고객 인터뷰
         • 경쟁제품 검토
         • 프로토타입 구축
           • 최대한 간결하게, 시각적인 UI 것만 구현 
           • 프로토타입을 실제 SW 개발에 사용하면 안됨. 사용할 경우, refactoring 필요
           • 요구사항을 가시화하는 것이기에 Requirement Creeping을 예방할 수 있음
      2. 요구사항 명세화
         • 문서화
         • 스토리보드 작성
         • UI 프로토타입 반영
      3. 요구사항 분석
         • 요구사항들 간의 공통점과 차이점을 찾아내고 특성별로 구분 (설계활동에 해당)
  • 아키텍처
    • 시스템을 서브 시스템으로 분할하여 상세하게 계획
    • 약 80% 요구사항 정의가 완료되었을 때 아키텍처 단계 진행
    • 아키텍처는 향후 설계와 개발 작업을 통제하는 표준
  • 최종 준비
    • 단계별 납품에 돌입하기 전에 릴리즈 계획을 세우는 단계
    • 요구사항 개발이 완료된 후 추정을 진행
    • 과거 완료된 프로젝트들의 데이터에 기초하여 추정 및 계획을 세워야 함
    • 앞서 진행된 단계에 대한 feedback 필요
  • 단계별 납품 - 계획 수립
    • 각 단계 시작 시, 해당 단계 작업을 준비하는 계획 수립
    • 진척도를 추적하기 위해 상세 마일스톤 (binary milestone) 을 작성
      • binary milestone : 정해진 일정을 했는지 안했는지 True/False 로 관리하는 기법
    • Short-term 마일스톤을 통해 문제를 빠르게 찾아냄
    • 개발이 얼마나 걸릴지 주기적으로 재추정하여 목표 수립
  • 단계별 납품 - 상세 설계
    • 앞선 아키텍처 설계를 확장하는 것
    • 개발자 숙련도가 낮을수록, 프로젝트 난이도가 높을수록 상세하게 설계해야 함
    • 컴포넌트 설계 + 각 클래스의 모듈 다이어그램 + pesudo code
    • 테크니컬 리뷰 진행
      • 기능적 결함 발견
      • 요구사항 결함 발견
      • 검토 요소
        • 정확성(Correctness) : 설계가 의도대로 동작할 것인가?
        • 완전성(Completeness) : 설계가 의도한 목적에 부합하는가?
        • 이해성(Understandability) : 이해 쉽게 설계되었는가?
      • 리뷰 한시간에 약 유지보수 시간 33시간 줄이고, 테스트보다 20배 효율적
      • TDD와 Refactoring을 통한 상세설계 보완
        1. Add a Test
           • 미구현 기능에 대해 테스트를 먼저 추가
           • 구현하지 않았으므로 Test Fail 상태
        2. Make it work 
           • 테스트 통과할 수 있도록 구현
        3. Make it clean
           • Refactoring을 통해 체계적으로 설계하여 적용
  • 단계별 납품 - 구현(구축)
    • 주요 활동
      1. 기능 추가 (소스 코드)
      2. 일별 빌드
         • 빠르고 잦은 통합으로 통해 결함을 너무 늦게 발견하지 않도록 함
         • 결함은 발견된 즉시 처리
      3. 스모크 테스트
         • 프로그램 주요 기능이 작동하는지 확인하는 테스트
         • 정상적으로 돌아가는지 체크 정도이며, 너무 많은 시간을 쏟지 않음
    • 주요활동을 지속적으로 반복하며 핵심지표(상세 마일스톤, 결함, 리스크 목록, 시스템)를 통해 진척도를 추적 및 변경 통제해야 함
    • 통합 절차
      1. 변경된 코드 병합
      2. 로컬에서 단위 테스트 (신규 기능)
      3. 스모크 테스트 (기존 기능 + 신규 기능)
      4. 마스터 소스에 체크인
      5. 일별 빌드 생성
      6. 스모트 테스트 (팀 단위)
      7. 결함 수정
    • 너무 Infra-structure 부분을 다 개발하고, UI 를 개발하려고 하지 말 것
      • 사용자 입장에서 오랫동안 output이 없어 불안
      • 오히려 UI 부분을 미리 만들면 추상적으로 구상한 것 대비 Infra-structure 의 문제를 줄일 수 있음
  • 테스트
    • 목적 : 결함을 많이 잡기 위함
    • 구축과 병행하거나 절반을 남겨 놓고 실시
    • 다음 새로운 코드를 통합할 수 있을 만큼 시스템 품질이 높다는 것을 보증하는 과정
    • 프로젝트 수행의 하류 단계에서 핵심적인 방법
    • 시스템 테스트
      • 시스템의 기능을 처음부터 끝까지 검증
      • 요구사항 기반의 테스트 케이스
      • 일반적으로 시스템 에러의 약 80%는 20%의 루틴에서 집중적으로 발견됨
      • 일반적으로 여러 사람이 변경한 부분 혹은 자주 변경한 부분이 에러가 자주 발생
      • 에러가 많이 발생하는 루틴을 찾아 집중적으로 테스트
  • 릴리즈 (Release)
    • 자주 릴리즈 할 수 있는 상태가 되도록 지원해야 함
    • 소프트웨어는 릴리즈 되었을 때 의미가 있음
    • 릴리즈 체크리스트를 통해 릴리즈 준비 상태가 되었는지 파악

•  품질 보증 계획
  • 품질 : 명시적, 암시적 요구사항을 충족하는 정도
  • 품질 보증 계획은 프로젝트 사전 단계부터 이루어져야 함 
  • 리뷰를 통해 이루어짐 (코드, 계획서, 요구사항)
  • 결함 추적
    • 결함이 발견된 때부터 해결될 때까지의 과정(LifeCycle)을 기록하고 추적하는 작업
    • 프로젝트의 추적과 통제에 있어 핵심적인 요소
  • 테크니컬 리뷰
    • 개발자가 자신의 동료들이 완료한 작업을 Review 하는 것
    • 결함 발견에 초점을 두고 Review 진행 (not 학습 및 해결방안 제시)
    • 기법
      • walkthrough 기법 : 프로세스 없이 아무나 Review
      • inspectation 기법 : 프로세스 존재 및 타팀이나 임원이 Review 진행
      • code reading 기법
  • 베타 테스트
    • 공식적으로 Release 하기 전에 정해진 사용자 계층이 써보도록 테스트하는 것
    • 주로 호환성 테스트를 위해 진행

 

 

참고

- 스티브 맥코넬 저, 『소프트웨어 프로젝트 생존전략』

- 논문, 『Quantitative Analysis of Fault Distributions in Complex Software Systems』