[소프트웨어공학] Chapter 4. 프로젝트 관리 개념(1) - 4P

소프트웨어 공학에서 프로젝트 관리는 소프트웨어 제품을 개발하고 유지, 보수하는 프로세스를 계획, 조정, 실행, 감시 및 제어하는 활동이다. 프로젝트 관리는 프로젝트를 성공적으로 완료하기 위해 프로젝트 팀원 간의 협력과 의사소통, 일정관리, 예산 관리 등의 다양한 요소를 조율해야한다 ! 

 

4P는 프로젝트 관리에서 중요한 개념 중 하나로 Project(프로젝트), Product(제품), Process(프로세스), People(인력) 의 네가지 요소를 의미한다. 4P 개념은 프로젝트의 성공을 위해 모두 고려되어야하는 중요한 영역임 ~ ! 

People(사람) - 성공적인 프로젝트를 위한 핵심 자원
Product(산출물) - 만들어야 할 소프트웨어 결과물
Process(프로세스) - 작업완수에 필요한 일련의 프레임워크 활동들과 태스크들
Project(프로젝트) - 소프트웨어 구현을 위해 필요한 모든 작업들 

---

네 개의 P(4P)

 

1. People 

 이해당사자들 

Senior managers(고위급 관리자) : 비즈니스 이슈를 정의하는 역할을 담당하며 프로젝트에 큰 영향을 미침 
Project(technical) managers (프로젝트 관리자) : 소프트웨어 개발을 위해 실무자들을 계획, 조직, 지도하고 프로젝트를 통제
Practitioners (실무자) : 제품 또는 응용 프로그램을 엔지니어링하기 위해 필요한 기술적 역량을 제공 
Customers(고객) : 엔지니어링할 소프트웨어의 요구 사항을 명시하는 역할 → 소프트웨어 개발 결과물에 대한 주변적인 이해를 가지고 있음 
End-user(사용자) : product가 만들어졌을 때 구체적으로 상호작용하는 주체 →소프트웨어의 품질과 사용성을 평가하며 제품 또는 응용 프로그램의 최종 사용자 

이러한 이해관계자들은 소프트웨어 프로젝트의 성공을 위해 모두 중요한 역할을 수행함 ! 

 

소프트웨어 팀 

* 팀 리더 역할 (MOI 모델) 

• Motivation(동기부여)
  : 팀원들이 최상의 능력을 이끌어낼 수 있도록 동기부여를 해줄 수 있어야함 
• Organization(조직) 
  : 처음에 막연했던 요구사항을 다듬고 solution을 찾는 과정까지 framwork를 잘 적용시켜 완성할 수 있는 조직력이 필요해 ! 
• Ideas or Innovation(혁신)
  : creative 한 가치를 극대화 시킬 수 있는 것이 리더의 역할 

* 소프트웨어 팀 구성 시 고려사항 

• 문제의 난이도 
• 예상되는 프로그램 사이즈
  (ex. 가장 기본적인 평가 척도 : 코드라인 수) 
• 팀 구성 허용시간
  (팀 수명시간, 인적자원들에 대해 어떻게 스케쥴링 해야함 ? )
• 문제의 모듈화 가능 수준 
  (문제 난이도와 관련, 얼마나 작은 문제(모듈)로 쪼개질 수 있는가?, )
• 요구된 품질 및 신뢰도 
  (높은 신뢰성을 요구한다 ? - 수학적 완벽성을 추구)
• 인도 날짜에 대한 허용정도
  (시장의 적시성, deadline)
• 프로젝트에 요하는 사회성(대화) 수준 
  (ex. 학술적인 project , 예를 들어 생물학과 관련된 프로젝트라면 생물과 관련된 전문가 팀원이 필요함) 

 

* 팀 조직 패러다임 

• Closed paradigm(폐쇄적 패러다임)
  : 전형적인 계층적 팀 조직 (ex. 리더 - 팀원) 
• random paradigm(임의적 패러다임)
  : 리더가 없음 ! 위 아래 관계가 애매함, 팀원이 서로 동등한 입장을 가지고 주도적으로 운용(ex. 연구소) 
• open paradigm(개방적 패러다임) closed - random을 상충시켜보자 ! 
  : 폐쇄적인 방식으로 프로젝트를 관리하면서도 무작위한 패러다임에서 발생하는 혁신적인 아이디어를 수용
• synchronous paradigm(동기적 패러다임) 내 할일만 한다 ! 
  : 다른 팀원과의 소통이 거의 없이 독립적으로 문제를 해결 

 

협조 및 대화 

현재 소프트웨어의 특성 : 대규모 →  상호 운용성 , 불확실성

 

→ 정형적 대화 : 문서, 조직적 회의, 기타 공적인 채널을 통한 대화

→ 비형식적 대화 : 일상적으로 이루어지는 아이디어 나누기, 도움 요청하기, 기타 사적인 대화 
: 실질적으로는 도움이 된다는 비형식적 대화 ! 

 

2. Product 

소프트웨어 범위(scope)

: 소프트웨어 개발 프로젝트에서 제품이나 서비스의 요구사항을 충족시키는데 필요한 기능, 제약조건 등을 명! 확! 히 ! 정의하는 것 

• 배경 (Context) - 경계 바깥의 larger system 
  : 만드는 것에 대한 뒷배경을 알아야한다 ! → 소프트웨어가 대상 시스템, 제품 또는 비즈니스 환경에 어떻게 적합한지, 이러한 환경으로 인해 제한사항이 어떤 것인지를 고려한다.
• 목적 - 이 시스템은 input을 받아서 ~게 처리하여 output을 내놓는 목적을 가집니다 !
  : 소프트웨어에서 어떤 데이터 객체가 입력으로 필요하고, 어떤 데이터 객체가 출력으로 생성되어 고객에게 제공되어야 하는지를 정의
• 기능 및 성능 
  : 소프트웨어가 입력 데이터를 어떻게 처리하여 출력으로 변환하는지, 그리고 이를 수행하는 데 필요한 기능과 특별한 성능 요구 사항을고려한다. 

소프트웨어 범위는 관리적 측면이나 기술적 측면 모두에서 애매모함이 없고 이해 가능해야만 한다 ! 

 

3. Process

문제 분할

• 구획화(partitioning) / 정교화 (problem elaboration)
• 분할 및 정복(Divide-and-conquer) 전략
• 분할 : 기능(Function)및 프로세스(Process)

문제 하나하나 쪼개서 해결한 다음 합치면 최종적으로 자세한 사항이 나온다 ! 세밀한 상세화 과정(planing)을 거친다 ! 

4. Project 

프로젝트가 trouble을 마주하는 경우 💔

• SW사람들이 고객의 요구사항을 이해하지 못했을 때 (needs분석 실패)
• product scope가 정확히 정의되지 않음 
• 변화를 제대로 관리하지 않음 
• 채택한 기술의 변화
• 비즈니스의 요구가 변함 
• 비현실적인 deadline
• 사용자 저항(customer - end user의 입장이 다르다) 
• 스폰서 lost (너네 하는거 안되겠어 ~ 돈 끊을래 ) 
• 적절한 기술을 가진 인력의 부족, 결함
• 매니저가 배우기를 피해 .. (건성건성 한다 ! )

기본 요령 

• Start on the right foot(첫걸음부터 제대로) 
  : 문제 이해부터 차근차근 ~ 
• Maintain momentum(탄력 유지)
  : 팀에 문제가 생길 경우에도 incentive를 지급하거나 새로운 팀원을 뽑는 등 탄력을 유지한다
  가급적 팀이 하는 것에 간섭하지 않기(사장님이 기웃기웃 ? 😱 팀원들 일 못해요 ~ ) 
• Track progress(진도 확인)
  : 정해진 일정에 정해진 양의 일이 완성되었는지 체크 (예정된 진도에 앞서가거나, 뒤쳐지지 않는가 ?) 
• Make smart decisions (현명한 의사 결정)
  : 때로는 과감하게 . . , 신속하게 판단하여 결정 내리기 
• Conduct a postmortem analysis(사후 분석 실시) 
  : 프로젝트 하나 끝난 뒤 손 털지 말고 내가 이런 부분을 과시했구나, 부족했구나 .. 등 다음 프로젝트에 반영할 수 있도롣 배우기 ~ 

W5HH 원칙 → 기본요령에 대해 

1. Why is the system being developed ? → 왜 개발함 ? 

2. What will be done ? → 언제까지? 데드라인 언제임 ?

3. When will it be accomplished ? → 언제 출시 ?

4. Who is responsible? → 누가 관여? 

5. Where are they organizationally located? : → 조직은 어디서 구해? (인력 사이트 등) 

6. How will the job be done technically and managerially? → 일은 어떻게 기술적으로 다뤄지고 관리됨?

7. How much of each resource(ex.people, software,tools, database) will needed? → 자원투입은 어떻게 얼마나 해야함 ?

 

---

[참고 및 출처]

 

한국항공대학교 「 소프트웨어공학 」 강의자료

---

이번 시간에는 4P에 대해 배웠다 ~ 

다음 시간에는 측정 척도에 대해서 배운다 ! 

숙제도 나왔다 ~ 

슬푸다 ~ 

 

끗 !