slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
소프트웨어 공학 (Software Engineering ) 계획 (Planning) 문양세 강원대학교 IT 대학 컴퓨터과학전공 PowerPoint Presentation
Download Presentation
소프트웨어 공학 (Software Engineering ) 계획 (Planning) 문양세 강원대학교 IT 대학 컴퓨터과학전공

Loading in 2 Seconds...

play fullscreen
1 / 64

소프트웨어 공학 (Software Engineering ) 계획 (Planning) 문양세 강원대학교 IT 대학 컴퓨터과학전공 - PowerPoint PPT Presentation


  • 300 Views
  • Uploaded on

소프트웨어 공학 (Software Engineering ) 계획 (Planning) 문양세 강원대학교 IT 대학 컴퓨터과학전공. In this chapter … (1/2). 계획 (Planning). 소프트웨어 공학의 계획을 논하기에 앞서서 … 만사에 있어서 계획이 없으면 이룰 것이 없다 . 많은 계획들 중에 있어서도 가장 중요한 계획은 자기 자신 인생의 장중단기 계획이다. 사랑하는 학생 여러분 가슴에 손을 올리고 생각해 보세요 . 나는 10 년 후에 무엇이 되고 싶은가 ?  장기 계획

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about '소프트웨어 공학 (Software Engineering ) 계획 (Planning) 문양세 강원대학교 IT 대학 컴퓨터과학전공' - orla-spence


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

소프트웨어 공학 (Software Engineering)

계획 (Planning)

문양세

강원대학교 IT대학 컴퓨터과학전공

slide2

In this chapter … (1/2)

계획 (Planning)

  • 소프트웨어 공학의 계획을 논하기에 앞서서…
    • 만사에 있어서 계획이 없으면 이룰 것이 없다.
    • 많은 계획들 중에 있어서도 가장 중요한 계획은 자기 자신 인생의 장중단기 계획이다.
  • 사랑하는 학생 여러분 가슴에 손을 올리고 생각해 보세요.
    • 나는 10년 후에 무엇이 되고 싶은가?  장기 계획
    • 10년 후를 위해서, 올 한해 나는 무엇을 추구하고 달성할 것인가?  중기 계획
    • 올 한해 목표를 달성하기 위해서, 나는 이달에, 오늘 무엇을 해야 하나?  단기 계획

 그래 고민되니까 오늘까정만 술 한잔?

slide3

In this chapter … (2/2)

계획 (Planning)

  • 소프트웨어 공학에서의 계획이란,
    • 개발하고자 하는 문제에 대한 정확한 이해 및 정의를 하고,
    • 여러 가지 필요한 작업들을 도출하고, 그 작업들의 순서를 결정하며,
    • 어떻게 개발해 나갈 것인지 일정을 계획하며, 이에 따른 비용을 추정하는 것이다.
    • 그리고, 궁극적인 결과(output)로는 계획서를 작성하는 것이다.
  • We will cover …
    • 프로젝트 관리
    • 문제 정의
    • 계획 (예산, 일정, 조직)
    • 노력 추정
    • 위험 분석
    • 계획서 작성
slide4

In this chapter …

계획 (Planning)

프로젝트 관리

문제 정의

계획 (일정, 예산, 조직)

노력 추정

위험 분석

계획서 작성

slide5

프로젝트 관리 (Project Management)

계획 (Planning)

프로젝트 관리란?소프트웨어 프로젝트를1) 조직하고(organizing) – 어떠한 일이 있는지 파악하여, 관련 사람들을 어떻게 끌어 모으고,2) 계획하고(planning) – 어떠한 일정으로 얼마의 비용으로 어떻게 사람을 넣어서 진행하며,3) 일정관리(scheduling)하는 것이다. – 잘 진행되는지 항시 점검하고 피드백하는 것이다.

slide6

프로젝트 관리의 중요성

계획 (Planning)

  • 수입과 지출에 직결되는 경제 관련 작업(economic activity)
    • 기술 외적인 부분(경영, 경제)이 많음
    • 기술력 최고? 이것보다는 적기에, 쓸만한 것을, …  온라인 게임 열풍
  • 관리가 잘된 프로젝트도 실패하는 경우가 있음관리가 잘 안 되는 프로젝트는 실패로 끝날 가능성이 많음
    • 결과적으로, 프로젝트에 있어서 관리는 필수적 개념임
    • 그래서, 아무리 잘난 사람이 많아도 조직에는 과장, 팀장, 부장이 존재하는 것임
  • 관리 작업에 대한 방법을 일부 이론적으로 다룸
    • 관리를 실제 배우는 일은 현장감이 중요
    • 관리에, 특히 인간 관리에 정도는 없음  경험을 바탕으로 융화할 수 있어야
slide7

일반 제품 관리와 소프트웨어 프로젝트 관리의 차이점

계획 (Planning)

프로덕트를 만질 수 없고 눈에 보이지 않음

프로덕트가 매우 Flexible함  변경이 쉽고, 진화하며, 에러를 내재함

기계공학, 건축공학처럼 엔지니어링 기술이 아직 확립되어 있지 않음 수십 년을 연구했음에도 Not Yet?  과연 SE란 것이 존재하나?

소프트웨어 엔지니어링 프로세스가 표준화되어 있지 않음 최근 표준화를 시도하고 있음 (ISO, CMM 등을 확대해석 하면)

대부분의 소프트웨어 프로젝트는 일회성 아파트 건설 (서울에 짓나, 춘천에 짓나, 그게 그거지 뭐~) 온라인 게임 (스타크래프트vs. 리니지vs. 카트라이더vs디아블로…)

slide8

프로젝트 관리 작업

계획 (Planning)

계획서 작성(Proposal writing)

프로젝트 예산 수립(Project costing)

프로젝트 일정 계획(Project planning and scheduling)

프로젝트 모니터링 및 리뷰(Project monitoring and reviews)

조직 구성 및 평가(Personnel selection and evaluation)

보고서 작성 및 발표(Report writing and presentations)

slide9

프로젝트 관리 작업의 공통점

계획 (Planning)

  • 소프트웨어 프로젝트에만 있는 작업이 아님
  • 다른 엔지니어링에서도 충분히 볼 수 있는 관리 작업들임 과거를 돌아보면, 건설사 사장이 전자 사장해도 (대충) 잘하고,전자 사장이 소프트웨어 사장해도 (대충) 잘한다. 소프트웨어 프로젝트 관리가 다른 특징을 많이 가지긴 해도 큰 범주 안에서 보면 결국 관리 공학이다.
  • 다른 엔지니어링도 복잡해진다면, 소프트웨어 프로젝트 관리에서 드러내는 문제점을 가질 수 있음
    • 예산의 초과
    • 자원 예측의 부정확
    • 기간의 지연
    • 계획의 잦은 변경
slide10

계획 (1/2)

계획 (Planning)

  • 계획의 부재
    • 불확실성  중간에 무엇을 하고 있는지, 어디까지 되어가는지 파악할 길이 없음
    • 일정의 차질, 경비의 초과, 저품질, 높은 유지보수 비용
    • 위험 (risk)
    • 결과적으로는… 프로젝트의 실패
  • 소프트웨어 프로젝트 계획 수립“소프트웨어 개발 과정과 일정, 비용, 조직, 생산 제품에 대하여 사전에 계획”
    • 문제를 이해하고 정의
    • 필요한 소작업(activity)을 정의하고 순서를 결정
    • 일정 예측
    • 비용 예측
    • 위험 분석

계획서 작성

slide11

계획 (2/2)

계획 (Planning)

  • 계획 수립의 결과 소프트웨어 개발 계획서
    • 사업관리자, 개발자, 사용자들에게 사업의 범위, 필요 비용, 필요 자원, 개발 일정, 위험 요소 등에 대한 정보를 제공하는 산출문서(deliverable)
  • 주의할 점
    • (계획자는) 시스템에 대한 충분한 이해가 있어야 함, 그러나 변경의 여지도 있음
    • 현실적, 구체적 계획  보여주기 위한 계획이 아닌 실질적인 계획
    • 득실 관계 저울질 기간 vs. 비용
    • 기술적인 측면 고려  제품의 난이도, 투입 엔지니어의 능력
slide12

We are now …

계획 (Planning)

프로젝트 관리

문제 정의

계획 (일정, 예산, 조직)

노력 추정

위험 분석

계획서 작성

slide13

문제의 인식

  • 문제 범위와 원인 파악

기본 요건 분석

  • 문제를 둘러싼 조직, 제도, 시설, 인원, 기술에

관한 현황 파악

시스템 조사 및

정보 수립

  • 현재의 시스템 조사, 업무 흐름 정책 등을 파악
  • 면담과 서류로 심층 분석

(고객 상담, 현업의 분석, 작업의 체험)

현 시스템의 이해

  • 목표 시스템의 정의

신규 시스템의 정의

문제 정의 (1/2)

계획 (Planning)

문제의 이해:대상 업무나 문제를 사용자가 이해하는 용어로 정확히 기술한 것(개발자가 아닌 고객의 관점에서 정확히 기술해야 함)

slide14

문제 정의 (2/2)

계획 (Planning)

  • 문제를 정의한 후에는 해결 방법에 대한 대책을 수립함
    • 신규 시스템의 목표 설정  기능과 우선순위 (투자 효과를 분석)
    • 해결 방안 모색(사용자 요구, 개발 여건, 기술적 능력 고려)
  • 문제(개발 시스템)의 정의 요소
    • 문제의 기술 (교수용 온라인 게임을 만든다.)
    • 시스템의 필요성 (교수들도 가끔 즐길 권리가 있다.)
    • 시스템의 목표 (전국 교수들을 모두 매혹시킨다.)
    • 제약 사항 (근데, 컴퓨터를 다룰 줄 모르는 분은 불행히 제외한다.)
    • 시스템의 제공 기능 (3D와 FullHD는 기본이고, 사운드는 5.1 채널 지원이다.)
    • 사용자의 특징 (애덜이 아니라 대부분 중년이다.)
    • 개발, 운용, 유지보수 환경 (전화 Claim이 비교적 많을 것이니, ARS 응대가 필요하다.)
slide15

타당성 분석 (Feasibility Analysis)

계획 (Planning)

  • 경제적 타당성
    • 투자 효율성 ( 본전은 뽑을 수 있어야 …, 본전은 뽑지 못해도, 고객은 확보해야 …)
    • 시장성 ( 판매가 가능하고, 시장이 열려 있어야…)
    • 비용과 수익의 비교
  • 기술적 타당성 (사용자 요구 기능 및 성능 vs. 제공 가능성)
    • 사례 연구 (case study)
    • 실패 사례 연구 실패는 성공의 어머니, 他山之石 (타산의 아무 쓸모 없는 돌도 다듬으면 옥…)
    • 모의 실험 (simulation)
    • 프로토타이핑
  • 법적 타당성
    • 사용 도구들의 법적 권한  1000억짜리 (불법) 툴을 사용하여 하루에 끝내자.  Oh! No.
    • 시장, 관행들에 대한 조사 아무 메일이나 잡아내는 소프트웨어를 개발하자.  Oh! No.
slide16

We are now …

계획 (Planning)

프로젝트 관리

문제 정의

계획 (일정, 예산, 조직)

노력 추정

위험 분석

계획서 작성

slide17

일정 계획 (Scheduling)

계획 (Planning)

  • 일정 계획:개발 프로세스를 이루는 소작업(activity)를 파악하고, 그 순서와 일정을 정하는 작업
    • 개발 모형 결정 (폭포수, 프로토타이핑, …)
    • 소작업, 산출물, 이정표 설정
  • 작업 순서
    • 작업 분해: WBS(Work Breakdown Structure) 작성 [World Best Software?]
    • CPM(Critical Path Method) 네트워크 작성
    • 최소 소요 기간(best case)을 구함 (위험 분석을 위해, worst case도 작성해 본다.)
    • 소요 MM, 기간 산정하여 CPM 수정
    • 간트 차트로 그려, 일정을 구체화 함
slide18

작업 분해(Decomposition)

계획 (Planning)

  • 작업 분해:프로젝트 완성에 필요한 소작업(activity)를 찾아냄
  • WBS(Work Breakdown Structure)
    • 계층적 구조를 가짐
    • Activity의 규모를 판별할 수 있음
    • 각 노드에 작업 소요일, 책임자 등을표시할 수 있음
  • 작업 분해는 일정 계획에앞서서 필요 작업을 찾는데주된 목적이 있음
slide19

작업순서 결정 및 소요시간 예측

계획 (Planning)

CPM 네트워크 작성을 위해, 우선 각 소작업에 대한 소요 기일을 예측하고, 각 소작업 간의 선후관계를 파악한다.

CPM 소작업 리스트 예제

slide20

CPM 네트워크 (1/2)

계획 (Planning)

  • CPM 네트워크는 방향성 그래프(directed graph)이다. 그리는 예는,
    • 노드(node)는 소작업을 표시한다.
      • 원형 노드: 소작업의 이름과 소요 기간을 기재한다.
      • 박스 노드: 프로젝트 중간 점검(milestone)을 의미하며, 예상 종료일을 기재한다.
    • 에지(edge)는 작업 사이의 선후 관계를 표시한다.
  • CPM 네트워크를 사용하여, 프로젝트 완성에 필요한 작업을 나열하고 작업에 필요한 소요기간을 예측하는데 사용된다.
slide21

CPM 네트워크 (2/2)

계획 (Planning)

CPM 네트워크 예제

slide22

CPM 네트워크에 의한 임계 경로 (1/2)

계획 (Planning)

  • CPM 네트워크를 사용하여 파악할 수 있는 정보
    • 각 작업이 가장 빠르게 시작할 수 있는 시각 (earliest start time)
    • 각 작업이 최대한 빠르게 끝날 수 있는 시각 (earliest finish time)
    • 각 작업을 최대로 늦추어 시작할 수 있는 시각 (latest start time)
    • 각 작업을 최대로 늦추어 끝낼 수 있는 시각 (latest finish time)

작업의 순서는 물론 엔지니어의 적기 투입에 중요한 역할을 한다.

  • 임계 경로 (critical path)
    • 프로젝트를 마치는데 있어서 가장 기간을 많이 차지하는 경로
    • 임계 경로 내의 작업이 늦어지면 프로젝트 전체 일정이 늦어진다.
    • 관리자는 임계 경로의 작업에 많은 신경을 써야 한다.
slide23

CPM 네트워크에 의한 임계 경로 (2/2)

계획 (Planning)

임계 경로 예제

slide24

CPM 네트워크 특징

계획 (Planning)

  • 장점
    • 관리자의 일정 계획 수립에 도움
    • 프로젝트 안에 포함된 작업 사이의 관계를 파악할 수 있음
    • 병행 작업 계획  Parallel Processing 가능
    • 일정 시뮬레이션
    • 일정 점검, 관리
  • 관리에 대한 작업도 포함 가능
  • 작업 시간의 정확한 예측 필요
  • 소프트웨어 도구
    • MS Project 등

Page 24

slide26

프로젝트 일정표 (간트 차트, Gannt Chart)

계획 (Planning)

소작업별로 작업의 시작과 끝을 나타낸 그래프

예비시간(slack time)을 보여줌예비시간: 다음 작업에 영향을 주지 않고 연장 가능한 시간

계획 대비 진척도를 표시할 수 있음  프로젝트 일정 관리에 활용

개인별 일정표 작성 가능 언제 투입하고, 언제 휴가가고…

  • 일반적인 간트 차트의 구성
    • 세로를 일정축으로 하여 작업을 가로의 막대로서 표시함
    • 막대의 흰 부분: 예상 소요 기간
    • 막대의 회색 부분: 예비시간
slide27

간트 차트 예제

계획 (Planning)

slide28

MS Project의 간트 차트 예제

계획 (Planning)

관심있는 학생은 MS Project를 배워보시기 바랍니다. (무료교육 많음) SI 업체 등에 취업할 경우 큰 도움이 될 것입니다.

slide29

We are now …

계획 (Planning)

프로젝트 관리

문제 정의

계획 (일정, 예산, 조직)

노력 추정

위험 분석

계획서 작성

slide30

노력 추정이란?

계획 (Planning)

  • 얼마나 노력이 들어가느냐, 결국 개발 비용을 추정하는 것이다.
  • 소프트웨어 개발 비용 예측
    • 정확한 비용 예측은 매우 어려움
      • 알려지지 않은 요소가 산재  에러 발생, 성능 저하, 엔지니어의 이직, …
      • 원가의 계산이 어려움 (결국, 인건비인데, 이것 자체의 추정이 어려움)
    • 과거의 (경험적) 데이타가 필요
    • 단계적 비용 산정 방법도 사용 (초기 10억원, 프로토타입 이후 11.5억원 등)
  • 예산
    • 인건비: MM(인원/월)를 기초  관리자를 포함한 엔지니어의 인건비를 의미함
    • 경비: 여비, 인쇄비, 재료비, 회의비, 공공요금
    • 간접 경비: 오버헤드(overhead)  회사에는 회계, 기획, 경영 등 많은 파트가 있음
slide31

비용에 영향을 주는 요소

계획 (Planning)

  • 제품의 크기
    • 제품의 크기가 커짐에 따라 비용은 기하급수로 늘어남  분산, 병렬 시스템의 예
  • 제품의 복잡도
    • 응용 : 개발지원 : 시스템 = 1 : 3 : 9
  • 프로그래머의 자질
    • 코딩, 디버깅의 능력차
    • 프로그래밍 언어, 응용 친숙도
  • 요구되는 신뢰도 수준  MTBF(mean time between failure)
  • 기술 수준(개발 장비, 도구, 조직능력, 관리, 방법론 숙달)
  • 남은 시간
    • Putnam “프로젝트의 노력은 남은 개발 기간의 4제곱에 반비례” 2달 남았으면 1/24 = 1/16, 1달 남았으면 1이 필요…
slide32

MTBF 제안 예제

계획 (Planning)

slide33

프로젝트 비용을 예측하는 방법

계획 (Planning)

  • 상향식 (Bottom-up)
    • 소작업에 소요되는 기간을 구하고,여기에 투입되어야 할 인력과 투입 인력의 참여도를 곱하여 최종 인건 비용을 계산
    • 장점: 소작업에 드는 노력을 일일이 계획할 수 있음
    • 단점: 개인의 주관에 의한 추정이 될 가능성이 많음
  • 하향식 (Top-down)
    • 프로그램의 규모를 예측하고 과거 경험을 바탕으로 예측한 규모에 대한 소요 인력과 기간을 추정
    • 프로그램의 규모
      • LOC (Lines of code)
      • 기능 점수 (Function Point)

 총 몇 라인이니까, 혹은 어떤 기능이 있으니까 얼마 정도가 들 것이다라고 예측함

slide34

COCOMO 방법 (1/4)

계획 (Planning)

  • 개요 (위키)
    • B. Boehm이 1981년에 제안한 Constructive Cost Model이다.
    • 주로 2K-32K 라인 규모의 많은 프로젝트의 기록을 통계 분석하여 얻은 결과로서, 중소규모 프로젝트의 추정에 적합하다.
    • 완성될 규모의 LOC(lines of code)를 추정하고, 이를 준비된 식에 대입하여 소요 MM을 예측한다.
    • 소프트웨어 공학 기술의 발전과 더불어 초기 COCOMO 모델은 1995년에 COCOMO II로 확장되었다.
slide35

COCOMO 방법 (2/4)

계획 (Planning)

표준 산정 공식

  • 용어
    • KDSI: Kilo Delivered Source Instruction  입력 값으로 추정치에 해당함(LOC: Lines of code  1 KDSI = 1,000 LOC)
    • PM: Programmer-Month
    • TDEV: Total development time  궁극적으로 파악해야 하는 값
slide36

COCOMO 방법 (3/4)

계획 (Planning)

  • 유형 설명
    • 단순형: 소규모 팀이 개발하는 잘 알려진 응용 시스템으로, 일괄 자료 처리, 과학 기술 계산, 비즈니스 자료 처리 등 5만 라인 이하 규모
    • 중간형: 중규모 팀이 개발하는 소프트웨어 시스템으로, 트랜잭션 처리, 운영체제, DBMS 등 30만 라인 이하 규모
    • 임베디드형: 하드웨어가 포함된 실시간 시스템, 미사일 유도, 신호기 제어 시스템
  • 예제: CAD 시스템
    • 예상 규모: 33,360 LOC  중간형
    • PM = 3.0 x (KDSI)1.12 = 3.0 x (33.36)1.12 = 152MM
    • TDEV = 2.5 x (152)0.35 = 14.5 M
    • N = PM/TDEV = 152/14.5 ≒ 11명
slide37

COCOMO 방법 (4/4)

계획 (Planning)

비용 예측 그래프

  • 단순히 # of lines에 비례하는 것이 아니라,
  • 복잡할수록(시스템이 커질수록) 비례하는 정도가 달라진다.  빨리 증가한다.
slide38

COCOMO 방법의 보정(Scaling) (1/2)

계획 (Planning)

  • 기본 방법에 제품의 성격, 목표 시스템의 특성, 개발 구성원의 특성, 프로젝트 자체의 성격 등에 따라 보정한다.
    • 예를 들어, 프로그램의 경험이 많다면 노력 예측 값은 더 작아져야 하며,
    • 실시간 처리 요구가 있다면 예측 값은 더 커져야 한다.

노력 승수: 여러 조건을 고려하여 기본 방법에 곱하는 상수 값

  • 노력 승수에 영향을 미치는 요소
    • 제품의 특성: 신뢰성에 대한 요구나 문제의 복잡도, 데이터베이스의 크기 등
    • 컴퓨터 실행: 수행 시간의 제약, 주기억 장치의 제약, H/W 및 S/W의 안전성 등
    • 개발자의 특성: 개발자의 응용 분야 경험 유무, 프로그래밍 언어에 대한 익숙도 등
    • 프로젝트: 복잡한 소프트웨어 도구 사용이 필요한가?
slide39

COCOMO 방법의 보정(Scaling) (2/2)

계획 (Planning)

노력 승수 테이블  p. 81의 표 2.4 참조

노력 승수(ki, 1  i n)를 사용하여 보정한 PM 계산 노력 승수를 기본 PM 값에 곱하여 보정된 PM 값을 구한다.

slide40

COCOMO 방법의 사용 예제 (1/2)

계획 (Planning)

128,000 LOC 크기인 임베디드형(Embedded)의 예측

  • 기본 방법
    • PM = 3.6 x (128)1.20 = 1,216 MM(man-months)
    • TDEV = 2.5 x (1,216)0.32 = 24 개월
    • N = 1,216 / 24 = 50.66 ≒ 51명
    • 생산성: 128,000/1,216 = 105 LOC/MM  한 달에 105 라인 작성
slide41

COCOMO 방법의 사용 예제 (2/2)

계획 (Planning)

128,000 LOC 크기인 임베디드형(Embedded)의 예측 (계속)

  • 보정된 방법 (1.15, 1.56, 0.82 적용 시 예제)
    • PMscale = 1.15 x 1.56 x 0.82 x PM = 1,789 MM(man-months)
    • TDEV = 2.5 x (1,789)0.32 = 28 개월
    • N = 1,789 / 28 = 50.66 ≒ 63명
    • 128,000/1,789 = 72 LOC/MM  한 달에 72 라인 작성
slide42

COCOMO 방법의 특징

계획 (Planning)

COCOMO 모델을 보면, “소요 기간과 소요 인원의 관계는 서로 바꿀 수 있는 관계가 아니다”라는 말을 실증하고 있다. 기간이 먼저 계산되고, 이에 따라서 필요 인원을 파악 “기간이 많이 걸리니 인원을 늘리자”는 잘못된 생각

프로젝트의 규모만 예측될 경우, 인원, 개발 기간 등의 비용을 비교적 정확하게 예측할 수 있다.

반면에, 1) 소프트웨어 제품을 하나의 개체로 보고 전체적인 수식을 계산한다. 실제로는 제품이 훨씬 복잡한 구조를 가지고 있다.2) 계획 단계에 프로젝트의 규모를 정확히 예측하기는 거의 불가능하다.

slide43

COCOMO II

계획 (Planning)

  • 1995년에 발표
  • 소프트웨어 개발 프로젝트가 진행된 정도에 따라 세 가지의 다른 모델을 제시  각 단계에 따라 다른 계산법을 적용
  • 제1단계: 프로토타입을 만드는 단계
    • 화면이나 출력 등 사용자 인터페이스, 3 세대 언어 컴포넌트 개수를 세어 응용 점수(application points)를 계산
    • 이를 바탕으로 노력을 추정
  • 제2단계: 초기 설계 단계
    • 자세한 구조와 기능을 탐구
  • 제3단계: 구조 설계 이후 단계
    • 시스템에 대한 자세한 이해
slide44

기능 점수 방법

계획 (Planning)

  • 기능 점수(function points)
    • 정확한 라인수는 예측 불가능  COCOMO 적용이 어려움
    • 입력, 출력, 질의, 화일, 인터페이스의 개수로 소프트웨어의 규모를 나타냄
    • 각 기능에 가중값(표 2.6(p. 86)이 기본이고, 표 2.7(p. 87)은 복잡도에 따라 세분화함) 부여
    • 기능 점수 1을 구현하기 위한 LOC
      • 어셈블리 언어: 324
      • C언어: 150
      • Pascal: 91
      • Ada: 71
      • Smalltalk: 21
  • 총 라인수= FP x 원하는 언어의 1점 당 LOC
  • 개발 노력 = 총 라인수/ 생산성(LOC/MM) 일단 총 라인 수를 구하고, COCOMO 등을 사용해 예측할 수도 있다.

이들 고급 언어는 어디로 갔지?

slide45

가중값(p. 86의 표 2.6) 설명

계획 (Planning)

입력 개수: 사용자가 시스템에 제공하는 입력 자료의 개수예: 웹 페이지 작성에 있어서 입력 화면의 개수

출력 개수: 시스템이 사용자에게 제공하는 출력 자료의 개수예: 웹 페이지 작성에 있어서 출력 화면의 개수

질의 개수: 사용자가 제공하는 대화형 질의의 개수예: 검색 화면에서 검색 조건을 주는 방법의 수

파일 개수: 시스템이 저장 및 관리하는 파일의 개수예: 봉급 파일, 주소 파일

인터페이스 개수: 다른 시스템과의 인터페이스 개수예: 은행 봉급 서버는 주소 서버, 고과 서버와 인터페이스 함

slide46

복합 가중값(p. 87의 표 2.7) 설명

계획 (Planning)

기본 가중값을 바탕으로 복잡도를 고려하여, 단순, 보통, 복잡의 세 가지 단계로 구분함

표 2.7의 예를 보면, “개수 x 복합 가중값”을 더하여최종 기능 점수인 148을 구하였다. 25 LOC/FP인 4세대 언어로 구현한다면, 148 x 25가 되어 3775 LOC를 구할 수 있다. 프로젝트 팀의 생산성이 2000 LOC/MM(한 달에 한 사람이 2000 라인 작성)이라면, 3775/2000 = 1.9MM가 된다.

slide47

기능 점수 추정 사례

계획 (Planning)

 내용을 Skip함 (교재사례 예제가 너무 일관성이 없어 강의에서 제외함)

slide48

조직 계획

계획 (Planning)

  • 조직의 구성
    • 소프트웨어 개발 생산성에 큰 영향
    • 작업의 특성과 팀 구성원 사이의 의사 교류
  • 프로젝트의 구조
    • 프로젝트별 조직: 프로젝트 시작에서 개발 완료까지 전담 팀 구성
    • 기능별 조직
      • 계획수립 분석팀, 설계 구현 팀, 테스트 및 유지보수 팀
      • 파이프라인(pipeline)식 공정
    • 매트릭스 조직 ( 인력 풀 제도)
      • 요원들은 고유 관리 팀과 기능 조직에 동시에 관련
      • 필요에 따라 요원을 차출 팀을 구성하고 끝나면 원래의 소속으로 복귀
slide49

조직 구성의 노하우?

계획 (Planning)

  • 경험이 많은 사람과 적은 사람을 적당히 혼합한다.
    • 경험 많은 사람만 모아놓으면 배가 산으로 갈 것이다.
    • 경험 적은 사람만 모아놓으면 아예 배를 만들지 못할 것이다.
    • 적당히 섞어 놓으면, 경험과 노하우가 자연스럽게 전수되는 이점이 있다.
  • 이직의 최소화가 대규모 프로젝트의 성패를 좌우한다.
    • 프로젝트 후반에 새로운 인원이 투입되면 그만큼 일정이 지연된다.
  • 기간 단축을 위해서 인원을 추가 투입하는 것은 의미가 없다.
  • 프로젝트를 너무 잘게 나누면, 팀(모듈)간 의사 교환 문제가 발생한다. 대개 3명~8명 정도가 적당하다. 8명이 넘으면 중간 관리자를 둔다.
slide50

중앙 집중식 조직 (1/2)

계획 (Planning)

  • 의사 결정권이 리더에게 집중
  • 계층적 팀 구조
  • 책임 프로그래머 팀(Chief Programmer Team)
    • 외과 수술 팀 구성에서 따옴
    • 책임 프로그래머: 제품설계, 주요부분 코딩, 중요한 기술적 결정, 작업의 지시
    • 프로그램 사서: 프로그램 리스트 관리, 설계 문서 및 테스트 계획 관리
    • 보조 프로그래머: 기술적 문제에 대하여 논의, 고객/출판/품질 보증 그룹과 접촉, 부분적 분석/설계/구현을 담당
    • 프로그래머: (책임 프로그래머의 지시에 따라) 각 모듈을 프로그래밍
slide51

책임프로그래머

백업

프로그램 사서

프로그래머

보조 프로그래머

중앙 집중식 조직 (2/2)

계획 (Planning)

  • 특징
    • 의사 결정이 빠름
    • 소규모 프로젝트에 적합
    • 초보 프로그래머를 훈련시키는 기회로 적합
  • 단점
    • 한 사람의 능력과 경험이 프로젝트의 성패 좌우  책임 프로그래머의 선정 문제
    • 책임 프로그래머에게 오버로드가 걸릴 수 있음
    • 보조 프로그래머의 역할이 모호
slide52

분산형 팀 조직

계획 (Planning)

  • 민주주의식 의사 결정
    • 서로 협동하여 수행하는 비이기적인 팀
    • 자신이 있는 일을 알아서 수행
    • 구성원이 동등한 책임과 권한
  • 다각도의 의사 교환 경로 제공
  • 특징
    • 작업 만족도 높음 ( 이직률이 낮음)
    • 의사 교류 활성화
    • 장기 프로젝트에 적합
  • 단점
    • 책임이 명확하지 않은 일이 발생
    • 대규모에 적합하지 않음(의사 결정 지연 가능)
slide53

혼합형 팀 조직

계획 (Planning)

  • 집중형, 분산형의 단점을 보완
  • 특징
    • 초보자와 경험자를 분리
    • 프로젝트 관리자와 고급 프로그래머에게 지휘권한이 주어짐
    • 의사교환은 초보 엔지니어나 중간 관리층으로 분산
  • 소프트웨어 에 따라 계층적으로 분산됨
  • 단점
    • 기술인력이 관리를 담당
    • 의사 전달 경로가 김
slide54

We are now …

계획 (Planning)

프로젝트 관리

문제 정의

계획 (일정, 예산, 조직)

노력 추정

위험 분석

계획서 작성

slide55

위험 분석 (Risk Analysis)

계획 (Planning)

  • (내재된) 위험 요소를 인식하고 그 영향을 분석하여 관리
  • 실패에 영향을 미칠 위험 요소 인식하고 그 대책 수립
    • 인력의 부족  인력의 적극적 유치, 팀 구성 시 고려, 교차교육 등
    • 일관성 있는 해결 방안 (누가 못하면, 조금 여유 있는 옆 사람이 한다?) 체계적이고 조직적인 해결 방안(조수/사수 개념, 중복 배치 등)
  • 비용에 많은 영향을 미치는 요소  리스크
    • 요구분석의 변경
      • 위험 감소 방안  프로토타이핑, 설문지, 리뷰
    • 일정 지연의 위험
      • 작업 의존도를 낮춤 (한 가지 작업에 병목이 발생하는 것을 최소화한다.)
      • CPM 네트워크에서 outgoing edge가 많은 노드
slide58

We are now …

계획 (Planning)

프로젝트 관리

문제 정의

계획 (일정, 예산, 조직)

노력 추정

위험 분석

계획서 작성

slide59

계획서 작성 (1/3)

계획 (Planning)

1. 개 요

1.1 프로젝트 개요

1.2 프로젝트의 산출물

1.3 정의, 약어

2. 자원 및 일정 예측

2.1 자원

가. 인력

나. 비용

2.2 일정

3. 조직 구성 및 인력 배치

3.1 조직 구성

3.2 직무 기술

slide60

계획서 작성 (2/3)

계획 (Planning)

4. WBS

5. 기술관리 방법

5.1 변경 관리

5.2 위험 관리

5.3 비용 및 진도 관리

5.4 문제점 해결 방안

6. 표준 및 개발 절차

6.1 개발 방법론

7. 검토 회의

7.1 검토회 일정

7.2 검토회 진행 방법

7.3 검토회 후속 조치

slide61

계획서 작성 (3/3)

계획 (Planning)

8. 개발 환경

9. 성능 시험 방법

10. 문서화

11. 유지보수

12. 설치, 인수

13. 참고문헌 및 부록

slide64

Homework #2

계획 (Planning)