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

Project Management - Definition

Creation and maintenance of an internal environment in an enterprise where individuals, working together in groups, can perform efficiently and effectively toward the attainment of group goals.

- 일할때 필요한 환경을 잘 만들고, 잘 유지하는 것이다. 그룹을 지어 함께 일하는 것이기 때문에 목표를 달성하기 위해서는 효과적인 방법이 필요하다.

 

Management Steps

 

1. Planning	Understanding & documenting the goal.  Developing a schedule, budget and other resource req.s.  - 문서와 목표를 정확하게 정의하고, 요구되는 자원과 예산등을 예측한다.  ( 어떻게 예측할 것인지가 화두가 된다.)
2. Acquisition of resources	Space, computing resources, materials and human resources.
3. Execution	Putting the plan into a action.
4. Monitoring	Checking the progress of the project.  Taking necessary actions to handle deviation from the plan.

 

 

Software Productivity

소프트웨어의 생산성은 크게 두가지로 분류한다. ( 프로그램의 코드라인수 vs 프로그램의 기능 관점)

LOC (line of code)

   DSI(delivered source instructions)로 주석과 코드를 함께 라인수로 책정하는 방법.

   NCSS(non-commented source statement) 로 실행되는 코드의 라인수만 책정하는 방법.

  코드의 라인수는 측정하기는 쉽지만 문제가 많아 잘 사용되지 않는다.

Function Points

 요구사항의 기능에 각각 점수를 부여하여 기능이 얼마나 많고 복잡한가를 나타내서 예산을 측정하는 방법이다.

 좀더 깊게 설명하면, 먼저 프로젝트의 분야를 정하고, 그 기능이 쉬운지, 어려운지를 판단하여 가중치를 부여한 후에, 모두 더한

 UFP (unadjusted FP) 를 구한다. 그 다음 14가지의 시스템 특성에 따라 가중치(VAF)를 다시 구하여 Total DI를 구한다.

 그런 후에 AFP(adjusted FP)= UFP X ( TDI * 0.01 + 0.65) 의 식으로 AFP를 구하면 된다.

이 외에도 소프트웨어의 생산성에 영향을 주는 것은 요구사항의 신뢰도, 타이밍 제약, 기한, 언어 경험, 개발자의 이직 등 다양한 점이 영향을 줄 수 있다.

 

Techniques of Software Cost Estimation

소프트웨어의 비용을 평가하는 기술들은 Expert judgement, Parkinson's Law, Top- down, Bottom-up 등 다양하게 존재한다.

대표적으로 COCOMO가 있다.

COCOMO는 LOC를 기반으로 비용을 측정한다.

프로젝트의 개발이 어려운지 정도에 따라 3가지 정도로 분류한 후에 계산식이 존재한다.

예를 들어, 소규모 프로젝트일 경우에는 PM (person- Month) = 2.4(KDSI)^1.05 을 구한 후 Effort Multiplier를 여러가지 항목을 검토하여 정한다. 그런후에 PMdev= PM*Effort multiplier 를 구한 후, TDEV = 2.5*(PMdev)^0.38 로 구할 수 있다.

즉 COCOMO는 LOC를 기반으로 하되 여태까지 프로젝트들의 경험을 토대로 만들어진 식으로 구하게 된다.

FP가 더 각광을 받으면서 LOC뿐만 아니라 FP을 결합한 측정방법 COCOMO2으로 발전한다.

 

Project Control

 

WBS (Work Breakdown Structure)	요구사항들을 잘게 나누어 (가능하다는 확신이 들때까지) 트리구조로 목차를 나누어 각 기한(PERT를 그려 추가적인 여유시간인 slack time도 알 수 있다)을 정한다. 프로젝트를 명확하게 이해해야 할 수 있다.
Gantt chart	활동간의 관계의 초점이 아니라 일정 자체만을 한눈에 볼 수 있도록 표현한 것.
PERT chart	각 기능의 선후 관계를 파악한 후 네트워크로 그린 후에 CPM (Critical Path Method) 을 찾는다. 이 CP에 있는 기능들이 지연될 경우 프로젝트 전체의 지연으로 이어짐을 알 수 있어 특별히 관리해야할 부분을 알 수 있다.  단, CPM을 효율적으로 쓰기 위해서는 작업에 필요한 시간을 정확하게 예측해야 한다.

 

Team Organization

경영은 조직을 구성하는데 개인의 역할을 잘 정의하고 할당하여 프로젝트의 목표를 이루어내는 것이다.

 

Centralization-conrol team	장점: 소규모에 적합. 일이 정확하게 이해됐고, 관리가 정확할때 적합. 매니저의 능력  단점: 의사소통이 어렵다.
Decentralized-control team	장점: 긴 프로젝트에 적합. 일이 이해가 어렵고 복잡할때, 팀원간 의사소통이 활발하다. 단점: 사람이 많으면 어렵다.

*큰 규모는 보통 위 두가지를 믹스해서 사용한다.

 

Contents of SPMP

SPMP(Software Project Managenemnt Plan)의 구성은 다음과 같다.

1. Introduction - Purpose of this document, Project overview, Related docuemnts / terms ...

2. Development Plan - Resource, Schedule

3. Organization - Team structure, Role

4. Technical Management - Configuration management, Technology management

5. Quiality control - Review Method, Review  periodic...

6. Development Environment - Required software and spec, Hardware spec, Space and security ...

7. Deliverables - define the documents , date ...

8. Others - Considerable issues ..

9. References

규모가 커질 경우 목차의 일부분이 따로 문서가 작성된다. 

4번은 SCMP (Software Configuration Management Plan) 

5번은 SQAP (Software Quality Assurance Plan)