[소프트웨어 공학] 01. Software Project Management

소프트웨어 프로젝트 관리(Software project management)

프로젝트 관리(Project Management)

Software project management

• 소프트웨어 프로젝트에서는 소프트웨어를 개발하고 구매하는 조직의 요구와 정해진 기한을 염두해야 함
• 프로젝트 관리(Project management)는 소프트웨어 개발이 항상 소프트웨어를 개발하는 조직에 의해 설정된 예산과 일정 제약을 받기 때문에 필요하다.

Success criteria

• customer에게 합의된 시간에 소프트웨어를 인도
• 전체 비용이 예산을 넘지 않아야 함
• customer의 기대에 부응하는 소프트웨어를 제공
• 일관되고 잘 작동하는(well-fuctioning) 개발 팀을 유지

소프트웨어 관리 특징(Software management distinctions)

• SW는 intangible함
  • 보거나 만질 수 없다
  • 소프트웨어 프로젝트 관리자는 단순히 제작 중인 아티팩트를 보면서 진행 상황을 볼 수 없다
• 많은 SW 프로젝트는 'one-off'(일회성) projects이고, 고유한 특징을 가지고 있다
  • 대규모 프로젝트일수록 이전 프로젝트와의 차이점이 존재할 가능성이 높다
  • 경험이 풍부한 관리자라도 새로운 문제를 예상하기 어려울 수 있다
• 소프트웨어 개발 프로세스는 가변적이고 조직마다 다름
  • 특정 프로세스가 문제를 일으킬 가능성을 정확히 예측하기 어려움

보편적인 관리 활동(Universal management activities)

• People management(인적 관리)
  • 적합한 팀 구성원을 선발하고 효율적인 팀워크를 이끌어내는 작업 방식을 마련합니다.
• Risk management(위험 관리)
  • 프로젝트에 영향을 줄 수 있는 위험을 평가하고, 이를 모니터링하며 필요한 경우 적절한 조치를 취합니다.
• Project planning(프로젝트 계획)
  • 프로젝트의 전체적인 계획을 수립
  • 개발 작업을 추정 및 스케줄링하며, 팀원들을 각각의 작업에 배정

People Management

Managing people

• 조직에서 사람들은 가장 중요한 자산이다
• 관리자의 역할은 본질적으로 사람 중심적이며(people-oriented), 사람들에 대한 이해가 없다면 관리는 실패할 것이다
• 프로젝트에서 일하는 사람들을 동기부여하는 것이 관리자의 중요한 역할 중 하나이다
• 부족한 인적 관리는 프로젝트 실패의 중요한 원인이다

Teamwork

• 대부분의 SE는 그룹 활동이다
  • 대부분의 비단순 소프트웨어(non-trivial software) 프로젝트는 혼자서 완료할 수 없을 정도로 개발 일정이 있습니다.
• 좋은 그룹은 결속력이 있고 팀 정신을 가지고 있다
  • 참여하는 사람들은 그룹의 성공과 개인적인 목표 모두에 의해 동기부여된다
• group interaction은 group performance의 중요한 요소이다
• 그룹 구성의 유연성은 제한적임
  • 관리자는 사용 가능한 사람들을 가지고 최선을 다해야 한다

Group cohesivenesss(그룹 결속력)

• 그룹 구성원들에 의해 그룹 품질 기준이 개발될 수 있습니다.
• 팀 구성원들은 서로로부터 배우고 서로의 작업을 알게 됩니다.
  • 무지로 인한 억제가 줄어듭니다.
• 지식이 공유됩니다.
  • 그룹 구성원이 떠나더라도 연속성을 유지할 수 있습니다.
• 리팩토링과 지속적인 개선이 장려됩니다.
  • 그룹 구성원들은 원래 디자인이나 프로그램을 만든 개인과 상관없이 함께 고품질의 결과를 내고 문제를 해결하기 위해 협력합니다.

Selecting group members(그룹 구성원 선정)

• 관리자나 팀 리더의 역할은 결속력 있는 그룹을 만들고 이들이 효과적으로 협력할 수 있도록 그룹을 조직하는 것입니다
• 이는 적절한 기술 스킬과 성격의 균형을 갖춘 그룹을 만들고 이 그룹이 효과적으로 협력할 수 있도록 조직하는 것을 포함합니다.

팀 구성 (Assembling a team)

• 이상적인 사람들을 프로젝트에 배정하는 것이 불가능할 수 있습니다.
  • 프로젝트 예산이 높은 급여를 지불할 수 없을 수 있고, 적절한 경험을 가진 스태프가 없을 수 있습니다.
  • 조직 내에서 새로운 기술을 습득하려는 의도 등으로 인해 제한될 수 있습니다
  • 관리자는 훈련된 스태프의 부족, 특히 이러한 제약 사항 내에서 작업해야 합니다.

그룹 조직 (Group Organization)

• 소규모의 소프트웨어 개발 팀은 보통 정형화되어있지 않고 뻣뻣하지 않은 구조로 운영된다
• 대규모 프로젝트의 경우, 하위 프로젝트별로 책임을 지는 계층적 구조가 필요할 수 있다
• 애자일 개발과 같은 방법론은 정보 교환을 촉진하기 위해 informal(격식에 얼메이지 않는, 비공식) 그룹을 선호합니다.

Informal groups

• 이러한 그룹은 전체로서 행동하며, 시스템에 영향을 미치는 결정에 대해 합의에 도달합니다
• 그룹 리더는 그룹의 외부 인터페이스 역할을 수행하지만, 특정 작업 항목을 할당하지는 않습니다
• 대신, 작업은 그룹 전체에 의해 논의되며, 작업은 능력과 경험에 따라 할당됩니다
• 이 접근 방식은 모든 구성원이 경험적이고 유능할 때 성공적입니다.

Group communications

• 소프트웨어 공학에서의 효과적인 그룹 작업을 위해 우수한 커뮤니케이션이 필수적입니다
• 작업의 현황, 설계 결정 사항 및 이전 결정의 변경 사항에 대한 정보가 교환되어야 합니다.
• 또한, 우수한 커뮤니케이션은 이해를 증진시키기 때문에 그룹의 결속력을 강화시킨다

Risk management(위험 관리)

• 위험 관리는 위험을 식별하고 이러한 위험의 영향을 최소화하기 위한 계획을 수립하는 데에 초점을 맞추고 있습니다.
• 소프트웨어 위험 관리는 소프트웨어 개발에 내재된 불확실성 때문에 중요하며, 이러한 불확실성은 아래와 같은 것에서 비롯됩니다.
  • 정의가 불분명한 요구사항,
  • 고객 요구 사항 변화로 인한 요구사항 변경,
  • 소프트웨어 개발에 필요한 시간 및 자원 추정의 어려움,
  • 개인의 기술 차이.
• 위험을 예측하고, 이러한 위험이 프로젝트, 제품 및 비즈니스에 미치는 영향을 이해하고, 이러한 위험을 피하기 위한 조치를 취해야 합니다.

Risk Classification(위험 분류)

• 위험 분류에는 두 가지 차원이 있습니다.
  • 위험의 유형(기술적, 조직적 등),
  • 위험에 의해 영향을 받는 것:
• 프로젝트 위험(Project risks)은 일정 또는 자원에 영향을 미칩니다;
• 제품 위험(Product risks)은 개발 중인 소프트웨어의 품질이나 성능에 영향을 미칩니다;
• 비즈니스 위험(Business risks)은 소프트웨어를 개발하거나 구매하는 조직에 영향을 미칩니다.

Examples of project, product, and business risks(프로젝트, 제품, 비즈니스 위험의 예)

위험	영향	설명
직원 이직	프로젝트	경험이 풍부한 직원이 프로젝트가 끝나기 전에 떠날 것입니다.
요구사항 변경	프로젝트 및 제품	예상보다 많은 요구사항 변경이 있을 것입니다.
규모 과소평가	프로젝트 및 제품	시스템의 크기가 과소평가되었습니다.
기술 변경	비즈니스	시스템이 구축된 기본 기술이 새로운 기술로 대체됩니다.
제품 경쟁	비즈니스	시스템이 완성되기 전에 경쟁 제품이 시장에 출시될 것입니다.

 

The risk management process(위험 관리 프로세스)

• 위험 식별(Risk identification)
  • 프로젝트, 제품 및 비즈니스 위험 식별;
• 위험 분석(Risk analysis)
  • 이러한 위험의 가능성과 결과 평가;
• 위험 계획(Risk planning)
  • 위험의 영향을 피하거나 최소화하기 위한 계획 수립;
• 위험 모니터링(Risk monitoring)
  • 프로젝트 전반에 걸쳐 위험을 모니터링;

Risk Identification and Risk Types(위험 식별 및 위험 유형)

• 추정, 조직, 사람, 요구사항, 기술 및 도구와 같은 다양한 유형의 위험이 있습니다.
  • 예) 소프트웨어 개발에 필요한 시간을 과소평가함.
  • 조직 재정 문제로 프로젝트 예산이 삭감됨.
  • 필요한 인력을 모집하는 것이 불가능함.
  • 고객이 요구사항 변경의 영향을 이해하지 못함.
  • 재사용이 가능한 소프트웨어 구성 요소에 결함이 있음.

Risk Analysis(위험 분석)

 

• 식별된 위험을 분석하고 그 확률 및 영향을 평가합니다.
• 위험의 가능성을 낮음에서 높음까지 평가합니다.
• 위험의 영향을 그 중요도에 따라 분류합니다.
  • 치명적, 심각, 용납 가능, 하찮음.

Risk planning(위험 계획)

• 각 위험을 고려하고 그 위험을 관리하기 위한 전략을 개발합니다.
• 회피 전략(Avodance strategies)
  • 위험이 발생할 확률을 줄입니다.
    • ex) 하드웨어 고장을 방지하기 위해 정기적인 유지보수를 실행
• 최소화 전략(Minimization strategies)
  • 프로젝트 또는 제품에 대한 위험의 영향을 줄입니다.
    • change impact를 줄이기 위해서 정보을 최대한 숨기기
• 비상 계획(Contigency plans)
  • 위험이 발생하면 그 위험에 대처하기 위한 계획이 있습니다.
    • 화재가 발생하면 트랙픅을 다른 데이터 센터로 전환

 

Risk monitoring(위험 모니터링)

• 식별된 위험을 정기적으로 평가하여 그 위험이 더 이상 혹은 더 많이 발생할 가능성이 있는지를 결정합니다.
• 위험의 영향이 변했는지도 평가합니다.
• 각 주요 위험은 관리 진행 회의에서 논의되어야 합니다.

 

Project planning(프로젝트 계획)

• 프로젝트 계획은 업무를 여러 부분으로 나누고 이들을 프로젝트 팀 구성원에게 할당하는 것을 포함합니다.
  • 발생할 수 있는 문제를 예상하고 잠정적인 해결책을 준비합니다.
• 프로젝트의 시작 단계에서 생성된 프로젝트 계획은
  • 프로젝트 팀 및 고객에게 작업 방식을 전달하고,
  • 프로젝트 진행 상황을 평가하는 데 사용됩니다.

Planning stages(계획 단계)

• 제안 단계(proposal stage)에서, 소프트웨어 시스템을 개발하거나 제공하기 위한 계약에 입찰할 때.
• 프로젝트 시작 단계(project startup phase)에서, 누가 프로젝트에서 일할지 계획할 때,
  • 프로젝트가 어떻게 단계별로 나누어 질지, 자원이 회사 전체에 어떻게 배정될지 등.
• 프로젝트 전반에 걸쳐 주기적으로(개발 계획 중에), 경험을 바탕으로 계획을 수정하고 작업 진행 상황을 모니터링한 정보에서.

 

Project scheduling(프로젝트 스케줄링)

• 프로젝트 스케줄링은 프로젝트 내 업무를 별도의 작업으로 구성하고, 이러한 작업이 언제, 어떻게 수행될지 결정하는 과정입니다.
• 각 작업을 완료하는 데 필요한 달력 시간을 추정하고, 필요한 노력과 해당 작업을 수행할 사람을 예상합니다.
• 서버에 필요한 디스크 공간, 시뮬레이터와 같은 특수 하드웨어에서 필요한 시간, 여행 예산 등 각 작업을 완료하는 데 필요한 자원을 추정해야 합니다.

 

The project scheduling process(프로젝트 스케줄링 프로세스)

 

Scheduling problems(스케줄링 문제)

• 문제의 어려움과 따라서 해결책을 개발하는 비용을 추정하는 것은 어렵습니다.
• 생산성은 작업에 참여하는 사람 수에 비례하지 않습니다.
• 늦은 프로젝트에 사람을 추가하는 것은 의사소통 오버헤드로 인해 더 지연됩니다.
• 예상치 못한 상황은 항상 발생합니다. 계획에 여유를 두세요.

Project activities(프로젝트 활동)

• 프로젝트 활동(작업)은 기본적인 계획 요소입니다. 각 활동에는:
  • 일정 기간(duration)(달력 일 또는 월),
  • 노력 추정치(effor estimate), 작업을 완료하는 데 필요한 인력-일 또는 인력-월을 나타냅니다,
  • 활동이 완료되어야 하는 마감일(deadline),
  • 검토 회의, 모든 테스트의 성공적인 수행 등이 될 수 있는 정의된 종료 지점(Defined end-point)이 있습니다.

Milestones and deliverables(이정표 및 납품물)

• 이정표는 진행 상황을 평가할 수 있는 스케줄 상의 지점입니다.
  • 예) 시스템을 테스트하기 위한 인계.
• 납품물은 고객에게 전달되는 작업 제품입니다.
  • 예) 시스템에 대한 요구사항 문서.

 

 

 

 

 

요약

소프트웨어 개발에서 위험을 어떻게 관리할까요?
일관성 있는 팀을 어떻게 구성하고 좋은 팀워크를 유지할 수 있을까요?
소프트웨어 개발 프로젝트를 어떻게 계획할까요?
그리고 그것에 대한 노력과 비용을 어떻게 추정할 수 있을까요?