프로그래밍[Univ]/소프트웨어 공학론

[소프트웨어공학론] Project Planning part2

Cloud Travel 2012. 4. 2. 10:47

* Milestones and deliverables

 - Milestones : 프로젝트 수행간 기억할 만한 날

 - Deliverables : Milestones의 결과물로 고객에게 전달되는 결과물

   


* Project scheduling (프로젝트 일정)

 - 프로젝트 일정은 Task단위로 분할하여 계획한다.)

  > Task는 1~2주 안에 끝낼수 있어야 할 분량이어야 한다.

  > Task간의 의존관계는 적어야한다.(Minimize task dependencies)

  > Concurrently하게 일이 진행(동시 실행)하게 해야 한다.

 - Task단위로 언제 어떻게 할 것인지를 정한다.

  > 각 Task의 종료일, 작업량, 인력 할당 및 수행에 필요한 자원을 식별한다.

 - Project scheduling을 하는 것은 PM의 능력과 경험에 의존한다.

 - Project scheduling process

  ⓐ Task 분할

  ⓑ Task간의 의존관계 파악

  ⓒ 필요 자원 산출(추정)

  ⓓ 인력 할당

  ⓔ 일정표를 생성 

  ⓕ 모든 Task에 해당하는 것이 끝날때까지 ⓒ ~ ⓔ반복후 종료

 - Project scheduling Problems

  > 추정하기가 힘들다.

  > 생산성은 투여된 인력과 비례하지 않는다.

  > 프로젝트 후반에 사람을 투여하면, 그 사람을 이해 시키기 위해 필요한 시간으로 프로젝트가 더 느려 질수 있다.

 - Schedule representation(스케쥴 표현) 

  > 그래픽적 요소로 나타내는 것이 좋다.

  ex) 간트차트, 바 차트

  

  > Staff allocation chart에는 경험, 난이도, 참여도, 특별함 등이 포함되있다.

  


-----> Plan-driven End <----

* Agile Planning

 - Agile Method는 반복적으로 increment(plan-driven의 task)를 수행하는 방식이다.

 - 고객의 원순위 및 요구사항 변화가 있을 수 있기 때문에 유연한 계획(flexible plan)을 작성해야한다.

 - Agile planning stages

  ⓐ Release planning : 전체 일정 중 몇개의 Increment를 둘 것인가를 정하는 것으로 프로젝트의 큰그림을 그림

  ⓑ Iteration planning : Increment의 세부 진행 계획을 새운다. 2-4주 단위로 Increment를 나눈다.

 - Planning in XP : 유저의 스토리에 기반을 두어 Increment를 나눔

  > 어떤 것이 중요한 가를 파악하고 중요한 것부터 실행을 한다.

  > 각각의 스토리를 2-3주 분량의 Increment로 나눠서 개발을 한다.


----> Agile Planning End <----


* Estimation techniques(기술 측정)

 - 노력과 가격을 측정하는 단계이다.

 ⓐ Experience-based techniques : manager, 전문가에게 물어본다.

 ⓑ Algorithmic cost modeling : 계산을 해낸다.


* Experience-based techniques

 - 전문과 또는 관리자에게 물어보는 방식으로, 과거 경험으로 예측을 하는 방식

 - 산출물을 예상하고, 다른 소프트웨어 컴포넌트나 시스템을 보고 계획을 생성

 - 개인 보단 많은 사람의 토의로 결정


* Algorithmic cost modelling

 ⓐ COCOMO 1

  - Effort = A * Size^B * M

   > A : 조직의 성격을 반영하는 상수

   > B : Size에 비례하여 effort가 늘어 나지 않는 것을 보정해주는 수

   > M : 생산품의 요구사항, 프로세스, 신뢰성, 사람의 능력등을 고려한 수치

   > Size는 보통 Line수를 가지고 하며, Line수의 단위는 KLOC로 1,000줄 단위이다.

  - Manager의 직관으로 결정하며, 조직마다 정해진 A,B,M이 존재한다.

  - 정확도

   > 어느 상황에도 똑같은 Effort 공식을 사용하므로 정확하지가 않는다.

   > 상황 : 상용화된 컴퍼넌트(COTS)사용, Tool사용, 가져오기, 시스템 분산, 프로그래밍 언어적 측면...

   > 이러한 비 정확성을 줄이기 위해서 생긴 것이 COCOMO2이다.

 ⓑ COCOMO 2

  - COCOMO2 model은 4가지의 부 model로 세분화 된다.

  ① Application composition model

   - 프로토타입핑 프로젝트와 재사용이 많은 프로젝트를 사용할 때 사용

   - PM = (NAP * ( 1-%reuse/100))/PROD

    >> 전체에서 재사용 부분을 뺀후, Application point를 곱한다.

    >> PROD는 기관의 경험으로 기관 마다 다른 수치를 제공한다.

  ② Early design model

   - 요구사항이 밝혀진 이후에서 사용 가능

   - 6개의 M을 곱해줘서 수치를 보정해 준다.

   - PM = A * Size^B * M(1)~M(6)

    > M(1)~M(6)

    > RCPX(신뢰성, 복잡도), RUSE(재사용 정도), PDIF(플랫폼의 난이도), PREX(사람의 경험), 

       PERS(사람의 능력), SCED(요구 일정), FCIL(개발 설비)

  ③ Reuse model

   - Black box의 경우(소스를 보지 못하고 재사용함) 

   > PM = (ASLOC * AT/100)/ATPROD

    >> ASLOC : 새로생성할 코드 

    >> AT : 자동 생성되는 부분

    >> ATPROD : 통합시 필요한 생산성

   - White box의 경우(소스를 분석가능)

   > PM = ASLOC * (1-AT/100) * AAM

    >> AAM : 소스를 조정하는 정도

    >> Black box때와 변수는 그외 변수는 같다.

  ④ Post-architecture model

   - 17개의 M값을 곱한다.

   - PM = A * Size^B * M(1)~M(17)

   - Code의 Size는 새로운 라인수 + 재사용 모델에서 수정할 라인수 + 요구사항 변경에 따른 라인수 이다.

   - B의 값은 다음에 따라서 의존한다.

    a) 이전 경험 : 1점 : 익숙 / 5점 : 경험X

    b) 개발 유연성 : 1점 : 유연함 / 5점 : 고정 되있음

    c) Risk 관리 : 1점 : Risk관리 함 / 5점 : Risk관리 안함

    d) 팀워크 : 1점 : 팀워크가 좋음 / 5점 : 팀워크가 안좋음

    e) 조직의 프로세스 성숙도 : 1점 : 성숙 / 5점 : 비성숙

    >> 계산법은 a)~b)까지의 값을 매긴후, 각각을 더한다. 더한 값을 100으로 나눈후 1.01값을 더한다.

    ex) B = (1+2+3+3+4) / 100 + 1.01 = 1.14 


------------------------------------------------------------------------------------------------

이런게 존재한다는 것만 알고 있자!