[소프트웨어공학] 프로젝트 관리를 위한 리스크 프로세스 및 인간 관리

---

프로젝트 관리

• 소프트웨어 공학의 본질적인 부분
  • 전문적인 소프트웨어 공학은 항상 조직의 예사과 일정에 대한 제약조건의 영향을 받음
    
    
• 프로젝트 관리자의 임무
  • 제약조건을 만족하고 극복하면서 고품질의 소프트웨어를 인도하도록 보장
    
    
• 프로젝트 주요 목표
  • 약속된 기한까지 고객에게 소프트웨어 인도
  • 전체 비용을 예산 범위 이내에서 지출
  • 고객의 기대치를 충족하는 소프트웨어 인도
  • 일관적이고 잘 운영되는 개발팀 유지

 

---

소프트웨어 관리가 어려운 점

• 소프트웨어 제품은 형체가 없음
  • 관리자는 개발 중인 제품에 대한 진척사항을 볼 수 없음
    
    
• 대형 소프트웨어 프로젝트는 종종 일회성 프로젝트임
  • 대형 프로젝트는 개발되는 환경이 다른 것들과는 어느 정도 다르기 때문에 고유함
    
    
• 소프트웨어 프로세스는 변동이 심하고 조직마다 다름
  • 소프트웨어 기업들은 완전히 다른 개발 프로세스들을 사용

 

---

프로젝트 관리에 영향을 미치는 요인

• 기업체 규모
  • 기업 규모가 클수록 관리 오버헤드가 커짐
    • 대형 조직에는 반드시 지켜야 하는 것이 존재
      • 관리 계층, 공식적인 보고 방식, 예산 정책, 승인 절차 등
• 소프트웨어 고객
  • 내부 고객일 때
    → 소통 방식은 비공식일 수도 있고 고객의 작업 방식에 맞추는 노력 필요 없음
    
    
  • 외부 고객일 때
    → 맞춤형 소프트웨어를 개발하는 경우 공식적인 소통방식을 통해 합의에 도달해야 함
    
    
• 소프트웨어 규모
  • 소형 시스템
    • 같은 사무실에서 작은 팀에 의해 개발 가능
      
      
  • 대형 시스템
    • 여러 기업체의 다수의 개발팀을 필요로 함
    • 프로젝트 관리자는 이런 팀들의 활동을 조정하고 소통을 정리해야 함
      
      
• 소프트웨어 유형
  • 일반 소비자 중심의 제품
    • 공식적인 기록 필요 X
      
      
  • 안전성 중심 시스템
    • 모든 프로젝트 관리 결정 기록
    • 시스템 안전도에 미치는 영향의 타당성 입증
      
      
• 조직의 문화 직원
  • 개개인의 능력에 의존하는 조직도 있고, 그룹 중심적인 조직도 있음
    
    
• 소프트웨어 개발 프로세스
  • 애자일 프로세스
    • 가벼운 관리로 운영
      
      
  • 정형화된 프로세스
    • 개발팀이 정의된 프로세스를 따르도록 하는 관리 요구

 

---

기본적인 프로젝트 관리 활동

• 프로젝트 계획 수립
  • 관리자는 계획 수립, 예산 추정, 프로젝트 개발 일정 관리, 직원 업무 할당 등을 책임
    
    
• 리스크 관리
  • 관리자는 리스크를 측정하고 조치
    
    
• 인간 관리
  • 팀의 인력을 선택하고 효과적인 성능을 발휘할 수 있도록 작업 방식 설정
    
    
• 보고
  • 기업의 관리자에게 프로젝트 진행사항 보고
    • 상세한 기술정 정보 ~ 관리 요약까지 다양한 수준으로 소통 가능해야 함
      
      
• 제안서 작성
  • 소프트웨어 프로젝트는 첫 번째 단계는 작업을 수행하는 계약을 수주하기 위해 제안서 작성
    
    

 

 

---

리스크 관리

• 프로젝트 관리자의 가장 중요한 임무
• 리스크
  • 발생하지 않았으면 하는 어떤 것
  • 프로젝트 개발 중인 소프트웨어 또는 조직에 위협
    
    
• 리스크 관리
  • 프로젝트/ 개발 중인 소프트웨어에 영향을 줄 수 있는 리스크를 예측하고 조치를 수행하는 것 포함

 

---

리스크 분류

• 프로젝트 리스크
  • 프로젝트 일정 또는 자원에 영향
    • 경험 많은 시스템 아키텍트의 손실
      
      
  • 예 : 직원 교체, 관리 변화, 하드웨어 사용 불가능성, 요구사항 변경, 명세화 지연, 규모 과소추정
    
    
• 제품 리스크
  • 개발하고 있는 소프트웨어 품질이나 성능에 영향
    • 구입한 컴포넌트가 기대했던 성능에 미치지 못함
      
      
  • 예 : 요구사항 변경, 명세화 지연, 규모 과소 추정, 소프트웨어 도구의 성능 부족
    
    
• 비즈니스 리스크
  • 소프트웨어를 개발하고 있는 또는 구입한 조직에 영향
    • 새로운 제품을 시장에 내놓은 경쟁회사
      
      
  • 예 : 기술의 변화, 제품의 경쟁

 

---

리스크 분류 특징

• 위험 분류들은 겹칠 수 있음
• 효과적인 리스크 관리
  • 문제 발생에 대한 대처를 쉽게 하는 것
  • 리스크가 예산 또는 일정에 감당할 수 없는 영향을 미치지 않도록 하는 것

 

---

리스크 관리 프로세스

리스크 관리 프로세스 표

 

---

1.  리스크 식별

• 리스크 관리 프로세스의 첫 번째 단계
• 위협을 가져올 수 있는 리스크를 찾아내는 것
  • 위협 → 소프트웨어 공학 프로세스, 개발 중인 소프트웨어, 개발 조직에 위협
    
    
• 리스크 식별 작업
  • 리스크 체크리스크 사용 가능
    
    
    • 추정 리스크
      • 소프트웨어 개발에 필요한 시간을 과소평가
      • 오류 수정 비율 낮게 추정
      • 소프트웨어 규모를 작게 추정
        
        
    • 조직 리스크
      • 조직에 구조변화가 와서 여러 관리 조직이 프로젝트에 관여
      • 조직의 재정적 문제로 인해 프로젝트 예산 축소
        
        
    • 인력 리스크
      • 요구되는 기능을 직원 채용 불가
      • 중요한 직원이 아픔
        
        
    • 요구사항 리스크
      • 주요한 설계 작업에 대한 재작업을 필요로 하는 요구사항에 대한 변경이 제안
      • 고객들이 요구사항 변경에 대한 영향을 이해 못 함
        
        
    • 기술 리스크
      • 시스템에 사용되는 데이터베이스가 초당 처리하는 트랜잭션을 기대했던 것만큼 못함
      • 재사용할 소프트웨어 컴포넌트가 결함 포함
        
        
    • 도구 리스크
      • 소프트웨어 코드 생성 도구에 의해 생성되는 코드가 비효율적
      • 소프트웨어 도구들이 통합된 방식으로는 함께 동작하지 않음

 

---

2.  리스크 분석

• 식별한 리스크 각각에 대해 리스크의 발생가능성과 심각성을 측정
  • 쉬운 수행방법은 없으며, 판단과 경험에 의존
  • 발생가능성과 심각성을 간단한 수치로 평가하는 것은 불가능, 아래처럼 분류
    • 리스크 발생 가능성 → 의미 없음 / 낮음 / 보통 / 높음 / 매우 높음
    • 리스크가 미치는 영향 → 재앙 / 심각함 / 견딜만함 / 중요하지 않음
      
      
• 평가 기준은 임의적 → 프로젝트, 프로세스, 개발팀, 조직에 대한 상세 정보 필요
• 관리 프로세스 매 반복 주기마다 리스크 분석표 수정해야 함
• 가장 중요한 리스크가 무엇인지 평가해야 함

 

---

3.  리스크 계획 수립

• 프로젝트에 위협을 주는 주요한 리스크들을 관리하기 위한 전략 개발
  • 리스크 발생 시 손실 최소화 할 수 있는 행동 생각
    
    
• 리스크 관리 전략은 세 가지로 분류
  • 회피 전략
    • 위험이 발생할 가능성을 줄이는 것
    • 예 - 결함을 포함하고 있는 컴포넌트에 대한 리스크를 처리하기 위한 전략
      
      
  • 최소화 전략
    • 리스크의 영향을 줄이는 것
    • 예 - 직원들의 질병에 대한 전략
      
      
  • 비상 전략
    • 최악의 경우를 대비해 준비하고 그것을 다루기 위한 전략을 세워놓는 것
    • 예 - 조직의 재정적 문제에 대한 전략

 

---

4. 리스크 감시

• 제품, 프로세스, 비즈니스 리스크에 변동사항이 있는지 검사하는 프로세스
  • 식별한 각각의 리스크들을 정기적으로 평가
    ← 해당 리스크의 발생 가능성 증감 여부를 판단하기 위해
    
    
  • 리스크의 영향 정도가 변화했는지에 대해서도 고려
  • 리스크는 프로젝트의 모든 단계에서 정기적으로 감시되어야 함
    • 모든 관리 검토 회의에서 주요한 리스크들을 독립적으로 평가하고 토의해야 함
      
      
• 리스크 요인
  • 추정 - 합의된 일정에 맞추는 것의 실패; 보고된 결함 제거 실패
  • 조직 - 조직 내의 소문; 상급 관리자의 행동 결여
  • 인력 - 직원의 낮은 도덕성; 팀 멤버 간의 낮은 공조체제, 직원 잦은 교체
  • 요구사항 - 많은 요구사항 변경 요청; 고객의 불평
  • 기술 - 하드웨어 또는 지원 소프트웨어의 공급 지연; 보고된 많은 기술적인 문제점들
  • 도구 - 팀 멤버들이 도구 사용을 싫어함; 소프트웨어 도구들에 대한 불평

 

 

---

인간 관리

• 조직의 가장 큰 자산 → 소프트웨어 조직 내에서 일하는 사람
• 소프트웨어 관리자의 목표
  • 프로젝트에서 일하는 엔지니어가 가능한 최대의 생산성을 올리도록 하는 것
    
    
• 소프트웨어 관리자가 소프트웨어 개발 작업에 영향을 미치는 기술적인 이슈들을 이해하는 것은 중요

 

---

인간 관리의 네 가지 주요 인자

• 일관성
  • 프로젝트 팀의 모든 구성원은 비슷한 대우를 받아야 함
    
    
• 존중
  • 사람들은 서로 다른 능력을 가지고 있으며, 관리자는 이런 차이를 존중
    
    
• 참여
  • 모든 의견을 고려하는 작업 환경을 개발하는 것이 중요
    
    
• 정직
  • 관리자는 팀에서 제대로 진행되는 것과 그렇지 않은 것에 대해 항상 정직해야 함

 

---

동기 부여하기

• 프로젝트 관리자는 일하는 사람들의 최상의 능력을 발휘할 수 있도록 동기를 부여해야 함
• 사람들은 자신의 욕구를 만족시키는 것에 동기부여를 받음
  
  
  • 사회적인 욕구
    • 사람들에게 동료들과 만날 수 있는 기회를 제공
    • 소셜 네트워크 시스템과 원격화상회의 사용
      
      
  • 명예 욕구
    • 성취한 것에 대한 공개적인 인정
    • 사람들은 제대로 보상받고 있다는 것도 느껴야 함
      
      
  • 자아실현 욕구
    • 더 배우고 싶은 사람들에게는 교육훈련은 중요한 동기부여
    • 작업에 대한 책임감 부여, 부담되는 작업 할당(불가능하진 않아야 함)

 

---

사람의 심리적 유형

• 인간 욕구의 계층은 실제 동기부여에 대비하여 과하게 축약되어 있음
• 작업-지향인 : 그들이 하고 있는 일에 의해 동기부여받는 사람들
• 자기-지향인 : 개인적인 성공과 자신에 대한 인정에 의해 동기 부여받는 사람들
• 교류-지향인 : 동료와의 존재와 행동에 의해 동기를 부여받는 사람들

 

 

---

팀워크

 

---

단결된 그룹의 장점

• 그룹은 자신의 고유한 품질 표준을 설정할 수 있다.
  • 구성원들이 공감하여 표준을 설정하므로, 그룹에 부과된 외부 표준보다 더 잘 지키게 됨
    
    
• 구성원이 서로로부터 배우고 도움을 준다.
• 지식이 공유된다.
• 리팩토링과 지속적 개선이 장려된다.

 

---

팀 작업에 영향을 미치는 세 가지 요인

• 그룹의 구성원
  • 프로젝트 그룹을 여러 유형의 사람들을 섞어서 구성
    
    
• 그룹의 조직 방식
• 기술적 그리고 관리적 소통
  • 그룹 멤버들 사이, 소프트웨어 공학팀, 프로젝트 이해당사자 사이의 좋은 소통 필수

 

---

그룹 멤버의 선택

• 관리자 또는 팀 리더의 임무
  • 단결된 그룹을 만들고 그룹이 작업을 효과적으로 함께 할 수 있도록 조직
  • 기술적인 능력과 개인의 특성 사이의 올바른 균형을 가진 그룹을 만드는 것과 관련
    
    
• 일반적으로, 다른 프로젝트에서 경험을 가진 현재의 직원들을 모아 구성됨
  • 관리자들이 팀 선택에 대해 완전한 자율권을 가지는 경우는 거의 없음
  • 업무에 꼭 맞는 사람이 아니어도 기업에서 가용한 인력을 사용하는 경우가 더러 있음

 

---

그룹 구성

• 같은 동기부여 유형을 가지는 사람들로 구성할 경우 문제 발생
• 효과적인 그룹은 모든 유형의 사람들이 균형을 이루는 그룹

 

---

그룹의 조직

• 그룹 조직되는 방식은 그룹의 결정, 정보가 교환되는 방식, 그리고 개발 그룹, 정보가 교환되는 방식,
  개발 그룹과 외부의 프로젝트 이해당사자와의 상호 작용에 영향을 미침
• 프로젝트 관리자에게 중요한 조직에 대한 질문
  • 프로젝트 관리자가 그룹의 기술적 리더여야 하는가?
  • 중요한 기술적 결정을 내리는데 누가 관여? 그리고 이런 결정은 어떻게 내려야 하는가?
  • 외부의 이해당사자 그리고 기업체의 상급 관리자와의 관계는 어떻게 처리할 것인가?
  • 같은 지역에서 근무하지 않는 구성원을 통합하는 방법은?
  • 그룹 내에서 지식을 공유하는 방법은?
    
    
• 작은 프로그래밍 그룹들은 대체로 비정형적인 방식으로 조직됨
• 큰 프로젝트에서는 계층적 구조로 그룹을 조직할 수 있음
• 에자일 그룹은 항상 비정형적 그룹

 

---

비정형적 그룹

• 그룹 전체가 하나로 활동, 시스템에 영향을 미치는 결정을 내릴 때 합의에 의해 결정
• 그룹 리더가 그룹 외부에 대한 인터페이스 역할 수행, 특정 작업들을 팀원들에게 할당하진 않음
  • 그룹 전체가 수행할 작업에 대해 토의하고 능력과 경험에 따라 업무 할당

 

---

계층적 그룹

• 그룹의 리더가 계층의 꼭대기에 있음
  • 리더가 많은 권한을 갖고, 멤버들의 작업을 지휘
    
    
• 조직의 구조가 명백하고, 의사 결정은 계층의 위로부터 내려짐
• 장점 : 신속한 의사결정
• 단점 : 소프트웨어 개발은 모든 단계에서 효과적인 팀 소통이 필수적이어서 잘 동작하지 않음

 

---

그룹 소통

• 작업 상황, 설계에 대한 결정 사항, 이전의 설계 결정에서의 변경 내용 정보는 반드시 교환해야 함
• 좋은 소통은 그룹의 단결력 강화
• 소통의 효과성과 효율성은 다음의 영향을 받음
  • 그룹의 크기
    • 그룹의 규모가 커질수록 멤버들이 효과적으로 소통하는 것 어려워짐
      
      
  • 그룹의 구조
    • 비정형적으로 조직된 그룹이 정형적이고 계층적인 그룹보다 더 효과적으로 소통
      
      
  • 그룹의 구성
    • 동일한 성격 유형의 사람들은 충돌할 수 있고, 결과적으로 소통 억제될 수 있음
      
      
  • 물리적 작업환경
    • 작업장의 구조가 소통을 활발하게 하거나 저해하게 만드는 주요한 요인
      
      
  • 이용할 수 있는 대화수단
    • 프로젝트 팀의 분산화를 위한 원격 화상 회의 기술 등등이 존재