[소프트웨어공학] #3-1 Project Management

3-1 Software Project Management

: 정해진 시간과 일정, 예산등의 제한조건에 맞게 요구사항이 반영되게 하는 것.

=>개발도 프로젝트이다.

 

프로젝트의 중요한 기준

: 제한시간 안에 고객에게 전달.

: 예산 안에서 개발

: 고객 만족 유도

: 잘 구축되어 운영되는 개발팀(+일관성 있는 운영)

 

SW management 특징(distinction)

-만질 수 없음(intangible)

-대부분의 프로젝트는 one-off(일회성): 유사한 프로젝트더라도 다른 점이 있다.

-다양하고, 조직마다 다르다.

 

프로젝트 management에 영향을 끼치는 요소(factor)

-company size(회사 크기)

-SW customers(고객)

-SW size(소프트웨어 크기)

-SW Type(소프트웨어 종류)

-Organizational culture(조직 문화)

-SW development process(개발 프로세스)

==> 다양한 조직의 프로젝트 매니저는 다양하고 다른 방법으로 일하게된다.

 

Universal management activities

-프로젝트 계획(Project Planning)

-위기관리

-인적 관리(팀원 관리와 구축)

-보고체계(Reporting): 문화마다 다름

-제안서 제출: 이게 첫단계

3-2 Risk Management

: 발생할 수 있는 Risk를 식별하여, 문제가 생길 시의 피해를 최소화

SW 개발 고유의 불확정적요소 때문에 중요함.

-느슨하게 정의된 요구사항

-고객 필요에 의한 요구사항 변경

- 시간과 자원 만족의 어려움

-개별 기술이 다 다름.

risk 예측

-risk의 임펙트 예측

-risk 회피하는 단계를 밟음.

 

Risk 분류(classification)

-type과 영향. 두개의 차원

Project risk: 시간과 자원에 영향

Product risk: 질과 성능에 영향

Business risk: 비즈니스 관련

*당연하지만 명확하게 하나로 보기는 어려움.

 

Risk management process

1) Risk identification(리스크 식별): 팀 활동이나 개인적 경험에 기반

-일반적인 risk에 대한 checklist(기술/조직/사람/요구사항/예측)

2) Risk analysis(리스크 분석): 우선순위화-가능성과 심각도를 분류.

-very low/low/moderate/high/very high

-catastrophic/serious/tolerable/insignificant

3) Risk planning(리스크 계획): 리스크를 피하거나 영향을 최소화하는 방법. 유지보수

-회피전략: 리스크가 발생할 가능성을 감소시킴

-최소화전략: 리스크의 피해를 감소시킴

-우연성 전략: 리스크가 발생하면 비상 계획이 계획됨.

-what if questions

4) Risk monitoring(리스크 모니터링)

-리스크에 정기적으로 접근하여 가능성의 변화를 결정.

-리스크의 피해가 변화했는지도 확인

3-3 Managing People

: 사람은 조직의 가장 중요한 자원

: 사람 관련한 것이 가장 중요함.

: 좋은 관리->프로젝트의 성공

 

요소(factor)

-consistency(일관성): 특히 보상

-Respect(존중): 서로 다른 멤버와 서로 다른 능력

-Inclusion(포함): 서로의 일과 관점을 인지하고 참여

-Honesty(정직): 사고치면 빠르게 보고하라

 

동기부여(Motivating)

-각자 다른 사람들에게 동기를 부여한다.

1) 기본 필요(식, 수면 등등)

2) 개인적 필요(존중, 자아존중)

3) 사회적 필요(그룹의 일원으로 인정 등)

 

인간 필요 계층

 

필요 만족

-생리적/안전 욕구는 주제가 아님(이건 안지켜지기가 어려움)

-Social(사회적): 정보적 소통, 연애

-Esteem(명예): 인정과 보상

-Self-realization(자아실현): 배움, 책임감.

 

사람의 타입

-일에서 동기부여

-관계에서 동기부여: 동료와의 상호작용

-개인에서 동기부여: 개인의 목표 성취

 

균형(balance)

각 클래스의 것들로 개인의 동기부여가 만들어짐

개인의 환경과 외부적 이벤트로 균형은 변동될 수 있음

단순히 개인적인 요소뿐 아니라 그룹이나 문화적 부분에서도 동기부여됨.

동료에서 동기부여되기도

3-4 Teamwork

: 소프트웨어 공학은 그룹 활동.

: 좋은 그룹은 응집력이 있고(cohesive), 팀스피릿을 가진다.

: 그룹 상호작용은 그룹의 성능에 결정적이다.

 

그룹의 단결

-개인보다 그룹을 더 중요하게.

-퀼리티의 상승

-서로에게 배움(지식공유로 인한 커뮤니케이션)

-지속적인 발전

 

공동체정신은 문화권마다 상이하다.

 

팀의 효과

-팀의 사람에 대해

-그룹 조직

-기술적/관리적 소통

 

팀원 선택: 잘하는 사람은 어디서든 원함. 기술 밸런스, 개개인 특성을 맞추기.

경험자가 없다면 잠재력을 보고. 예산도 중요.

 

그룹자체/정보교환 방식/개발팀과 외부의 소통*상호작용

 

Informal groups

-전체로 행동(덩어리)=>팀원의견이 팀의견

-리더가 소통하나 일을 부여하진 않음.

-모든 멤버가 전문적이면 잘잘 돌아감.

 

소통

-핵심요소

-정보는 필수적으로 교환

-좋은 소통이 그룹 단결에 도움.

 

크기/구조/요소/물리적 작업환경

 

3-5 Organization of Project Team

직능별 조직(Functional team): 각기 역할 직렬대로 나열한다.

프로젝트별 조직(Proejct): 맡은 프로젝트별로 나열한다.

매트릭스 조직(matrix): 순서에 따른 업무, 복수개 프로젝트 참여 가능.

애자일 조직: 5-9인, 결과와 주제의 소유권 공유