소프트웨어공학 #5 - 프로젝트 관리

juyeong-s·2021년 10월 24일
소프트웨어공학

소프트웨어공학

목록 보기
3/3

관리의 정의

개인이 그룹으로 함께 작업하여 그룹 목표 달성을 위해 효율적이고 효과적으로 수행할 수 있는 기업 내부 환경의 생성 및 유지

관리의 일반적인 기능

planning(계획): 목적, 자본, 정보의 흐름, 사람들, 산출물
organizing(구성): 권한과 그룹에 대한 책임
staffing(인사): 직원 고용
directing(지도): 부하를 이끄는 것
controlling(제어): 활동들을 측정하고 교정하는 것
관리 단계

Step1. planning(계획)
목표를 이해하고 문서화
스케쥴, 예산, 다른 자원 요구사항을 개발한다.
Step2. Acquisition of resources(자원의 습득)
공간, 컴퓨팅 자원, 재료, 인적 자원
Step3. Execution(실행)
실행으로 옮긴다.
Step4. Monitoring(모니터링)
프로젝트의 진척을 체크한다.
계획과의 편차를 다루기 위한 중요한 행동을 한다.

SW 생산성 측정

프로젝트 계획에서
작업의 어려운 정도를 측정해야한다.
각 엔지니어가 얼마만큼의 작업을 해결할 수 있을지 측정해야한다.

생산성 측정 항목

몇 개의 기능이 있는지
LOC(Lines Of Code): 이상적인 생산성 측정 항목은 아님(코드가 길다고 좋은 것은 아님)

어떻게 기능의 컨셉을 정량화할 수 있을까?
FP(기능 점수)
Code size(LOC, Lines Of Code)
생산성을 측정하기 위한 가장 흔하게 사용된 측정 항목

두 개의 가장 흔한 코드 사이즈

  • DSI(전달된 소스 지침, Delivered Source Instructions)
    고객에게 전달된 코드의 라인만 포함.
  • NCSS(주석 처리되지 않은 소스 설명, Non-Commented Source Statements)
    주석은 포함되지 않음.

SW 생산성 측정 항목으로써 해결해야 할 문제가 많지만 측정하기 쉽다.
최근데 유용하게 사용하지는 않지만 참조된다.

Function Points(FP)

  • SW 시스템의 기능을 수량화하기 위한 시도
  • 시스템의 복잡성을 특성화한다.
  • 예측하는데 사용될 수 있다.
  • SW를 생산하는데 얼마나 걸릴 것인가
  • 개발하기 위해 얼마나 많은 사람들이 필요할 것인가
  • 정보 처리 응용 프로그램에 적합하다.
  • 생산성, 금액, 에러 등 측정할 수 있다.
  • 미래 계획을 위한 기반으로써 사용될 수 있다.
  • 다른 언어들의 상대적인 힘을 측정하는데 사용될 수 있다.
  • SW 생산성 측정 항목으로써 발생하는 많은 문제가 해결되지만 적합하지는 않다.

일반적인 SW 시스템의 기능

Data 기능: Internal Logical File, External Interface File
Transaction 기능: External Query, External Output, External Input

FP 분석 방법

값 조정 요소(Value Adjust Factors) 고려, AFP = UFP X VAF

  1. 프로젝트의 타입을 결정해라.
  • New project / Maintenance project / Enhancement project
  1. 타겟 시스템의 범위를 결정해라.
  • Whole or Part / In-house 개발, 아웃소싱, Package acquisition...

  1. data 기능과 그들의 복잡도를 식별해라.

  2. transaction 기능과 그들의 복잡도를 식별해라.
    ex) 외부 입력(사용자가 입력하는 화면의 개수), 데이터의 개수에 대한 복잡도 매트릭스

  3. 조정되지 않은 FP를 도출해라.

  • UFP = Sum of weights for all functions
  1. VAF를 결정해라.
  • VAF = (TDI * 0.01) + 0.65, Total Degree of Influence
  1. adjusted FP, AFP를 도출해라.
  • AFP = UFP X VAF

생산성에 영향을 미치는 다른 요소

개인(개발자)의 능력
제품의 복잡도
요구된 신뢰성(고장이 적은)
시간 제약(실시간 시스템->응답 시간)
스케쥴 제약
언어 경험
직원 교체, 이직
다른 시스템을 재구조화(다른 시스템의 산출물에서 문서를 뽑아냄)
SW 비용 평가의 기술

알고리즘적인 비용 모델링

COCOMO, COCOMO 2
전문가 판단
유추에 의한 평가 -> 유사한 프로젝트와 비교
파킨슨의 법칙
시간, 인력으로 결정된다.
Top-down 평가(위에서 아래로, 전반적인 기능 훑음) -> 리프노드를 합산한다.
Bottop-up 평가(밑에서 위로)
COCOMO

Constructive Cost Model(구조적인 비용 모델)
KDSI(kilo DSI)에 기반 => LOC에 기반
디테일의 정도와 증가하는 복잡성의 세 가지 다른 모델 집합을 기반
액면가(Nominal effort) 및 일정을 방정식으로 나타냄
민감도 분석 가능
effort multipliers로부터 파라미터를 바꾸면서
COCOMO 2와의 차이점
프로세스 모델에 대한 추정
COCOMO: 순차적인 개발 프로세스(폭포수 모델)
COCOMO2: 반복적인 접근, RAD, Reuse-driven-approach
평가자
COCOMO: 소스 지침(KDSI)
COCOMO2: 소스 지침과 FP

임베디드는 Organic보다 복잡함
PM: Person-Month, 몇 명이 필요한지
TDEV: 소요되는 시간(몇 달)
PMDEV / TDEV = # of required persons
COCOMO 2

  • 프로젝트 진척에 의한 다른 모델 사용 -> COCOMO보다 유용함
  • effort multipliers로부터 파라미터를 바꾸면서

Preliminary Design(기본 설계)
One of Cost Drivers(비용을 유발하는 하나의 요소)
App.point: # of components, # of screens in input / output interface

프로젝트 컨트롤(계획 포함, 중요)

활동의 진척을 감시한다.
계획으로부터 차질이 생기는 것을 감지한다.
프로젝트 컨트롤 기술을 사용해라.

  • WBS(Work Breakdon Structure)
  • Gantt chart
  • PERT chart(Program Evaluation & Review Technique)

WBS(Work Breakdon Structure)

프로젝트의 목표를 여러 중간 목표로 나누는 것을 기반으로 합니다.

WBS 목표

  • 프로젝트가 해야하는 모든 활동을 식별하는 것
  • 프로젝트의 주요 활동에 따라 root에 레이블이 지정된 tree
    더 작은 구성 요소로 분해
  • 트리의 각 리프노드가 관리자가 사이즈, 난이도, 자원 요구사항의 관점에서 추정할 수 있다고 확신하는 작업을 나타낼 때까지 ~로 사용된다.
  • 프로젝트 계획의 요약
  • 일정 프로세스에 입력(시간 배정)

Gantt chart

  • 스케줄링, 예산 편성, 자원 계획에 사용되는 기술
  • 바 차트 형식
  • 각 바는 활동을 나타낸다.
  • 타임라인에 따라 그려진다.(활동에 위해 계획된 시간의 길이에 비례)
  • 자원 할당과 인력 충원 계획에 사용된다.
  • 작업 간 종속성을 강조 표시하지 말 것.

slack time(데드라인): 작업을 완료해야 하는 가장 늦은 시간
-> 시간이 남으면 다른 일 병행 가능

PERT chart(Program Evaluation & Review Technique)

PERT-CPM(Critical Path Method, 임계 경로 방법, 핵심적인 작업의 흐름)

  • 프로젝트에서 수행해야 할 활동들의 의존성을 나타낸다.
  • 박스(활동)와 화살표(활동들의 의존성)들의 네트워크

두드러진 특징

  • 활동에서 가능한 모든 병렬성을 노출(병렬적으로 수행할 수 있는 것을 나타낼 수 있음)
  • 스케줄링 및 대체 스케줄의 시뮬레이션 가능
  • 관리자가 프로젝트를 감시하고 제어할 수 있게 한다.
  • PERT chart로부터 날짜
  • 가장 빠른 시작일과 가장 늦은 시작일(이때부터는 꼭 시작해야 한다.)
  • 가장 빠른 종료일과 가장 늦은 종료일(이때까지는 꼭 끝내야 한다.)

임계 경로(Critical Path) -> 찾는 것 중요

  • 활동의 지연으로 인해 전체 프로젝트의 지연을 초래하는 경로
    매니저는 임계 경로 상에 존재하는 작업들의 진척 여부 모니터링을 계속해야 한다.
  • 가장 긴 경로 선택
  • 왜?
    • 가장 늦게 시작, 가장 늦게 종료 등 언제까지 이 프로젝트를 꼭 끝내고 시작해야 하는지 deadline을 알 수 있기 때문이다.
      따라서 여기서 나온 작업들은 절대 delay가 생겨서는 안된다.

계획으로부터 편차를 다루기

  • 매니저는 일정으로부터 편차를 어떻게 다룰지 결정해야 한다.
  • 엔지니어를 추가하지 않지만 올바른 엔지니어를 고용
  • 일시적으로 재할당할 시니어 엔지니어 혹은 트러블슈팅 컨설팅 전문가를 고용
    요구사항을 긁어낸다(불필요한 요구사항을 없앤다.)
  • 원래 계획과 일정의 부정확성을 인정한다.
  • 지연을 올바른 조치로 받아들인다.

팀 구성

목표: 공동의 목표를 위한 협력을 촉진하기 위해
조직 구조의 유형
수직구조(centralized-control team)
수평구조(decentralized-control team)

cf) 역할, 기능에 따라, 어떤 프로젝트 유형인지, Matrix structure(팀원들이 빠지고 다른 프로젝트에 참여하고)

조직 구조의 선택에 미치는 고려 사항

  • 프로젝트의 길이
  • 얼마나 많은 소통 그리고 작업의 성격
  • 팀을 위한 적절한 사이즈
  • 팀은 적당히 크지만 너무 크지는 않으며 적당히 작지만 너무 작으면 안된다.

수직구조(centralized-control team)

Chief programmer team(수석 프로그래머 팀)
수석 프로그래머는 프로젝트의 모든 기술적인 디테일과 설계에 대한 책임이 있다.
작업이 잘 이해됐을 때 잘 작동된다.
수석 프로그래머는 업무적인 과부하가 걸릴 것이다.(해야 할 작업이 많다.)

수평구조(decentralized-control team)

민주적인 팀
의사결정은 합의를 통해 이루어진다.
다른 사람의 작업을 리뷰한다.
높은 사기와 적은 직원교체로 이어진다.
long-term 프로젝트에 적잡하다.(팀원들이 합의해야 하기 때문에 더 오래걸린다.)
덜 이해돼고 더 복잡한 문제에 대해 적합하다.
큰 팀들에게는 부적합하다.
Mixed-control team(하이브리드)

계층적인 팀 구조

수직적, 수평적 팀의 조합
모두 이점을 갖기 위한 시도

팀 구조의 평가

  • 모든 작업에 대해 적절한 팀 구조는 없다.(정답은 없다.)
  • 수평적 제어는 엔지니어들 간 소통이 필수적일 때 가장 좋다.
  • 수직적 제어는 개발의 속도가 가장 중요한 목표이고 문제가 모호함이 없으며 잘 이해됐을 때 가장 좋다.
  • 필요한 만큼의 소통만 해야한다.

개발 속도보다 다음과 같은 목표를 고려해라

  • 개발 비용 줄이기(하지만 개발 비용이 줄이려면 수직적 구조가 적합하며 이에 따라 이직하는 경우가 생긴다.)
  • 직원 교체 줄이기
  • 주니어 엔지니어들이 시니어 엔지니어로 승진
  • 전문화된 지식과 경험의 폭넓은 전파

Governance Model

Chief Officer: 프로젝트 우선순위, 프로그램 리뷰, 프로그램 제어
고객과 Biz.Liaison Group은 요구사항을 주고 받으며 가능한지 아닌지 따짐.
PMO: 전체 프로젝트가 어떻게 수행되는지 모니터링
프로젝트 진척도, 데이터 수집, 상태 보고, 관리하는데 필요한 툴 사용
SQA: 품질 보증
IT TWG(Technical Working Group) : 프로젝트 팀에서 필요한 사람을 여기서 차출한다.
ex) 아키텍트는 아키텍쳐 구성이 끝나면 다시 그룹으로 돌아간다.(효과적으로 프로젝트 운영)

위험요소 관리

  • SW 엔지니어링에서의 전형적인 관리 위험요소
  • 요구사항이 계속 변경된다.
  • 프로젝트에서 일하는 적절한 사람이 없다.(팀원의 역량이 부족하다.)

어떻게 위험요소를 줄일까?

  • 프로토타이핑(prototyping)
  • 점진적인 전달(incremental delivery)
  • Modular design(변경이 될 만한 것을 모듈로 분리, 쉽게 변경사항을 수용하기 위해)

위험요소 핸들링 양식

  • Occur: 발생가능성, Mitigation Plan(risk를 완화하기 위한 계획), Respon(책임자)

SW 엔지니어링 영역에서 공통적인 위험요소

SPMP

효과적인 프로젝트 관리가 SW 품질을 향상시킬 수 있을까?

당연하다. 일정, 생산성이 떨어지면 deadline을 지키기 위해 급해지는 경향이 있기 때문에 품질이 좋지 않을 가능성이 크다. 또한, WBS에 맞게 일정이 진행되면 품질이 좋아질 수 있으므로 WBS를 자세하고 체계적으로 구성해야한다.

profile
juyeong-s
frontend developer
이전 포스트

소프트웨어공학#4-ProcessModels

0개의 댓글