[정보시스템 구축 관리] 1. 소프트웨어 개발 방법론 활용

88. 익스트림 프로그래밍 (eXtreme Programming)의 5가지 가치에 속하지 않는 것은?
① 의사소통 ② 단순성
③ 피드백 ④ 고객' 배제

>> 정답 4번

 

익스트림 프로그래밍 xp
애자일 소프트웨어 개발 방법론
고객에게 최고의 가치를 가장 빨리
사용자 스토리(고객과 직접 대면)
점진적 개발, 작고 빈번한 릴리즈, 단순한 설계, 리팩토리, 고객의 전적인 참여
의사소통, 단순함, 피드백, 용기, 존중의 5가지 가치
팀 중심의 소프트웨어 프로그래밍

 

 

83. 다음 설명에 해당하는 생명주기 모형으로 가장 옳은 것은?

가장 오래된 모형으로 많은 적용 사례가 있지만 요구사항의 변경이 어려우며, 각 단계의 결과가 확인되어야지만 다음 단계로 넘어간다. 선형 순차적 모형으로 고전적 생명 주기 모형끼라고도 한다.

① 패키지 모형 ② 코코모 모형
③ 폭포수 모형 ④ 관계형 모델


>> 정답 3번

 

폭포수 모델 = waterfall model
소프트웨어 개발 시 단계적으로 개발하는 방법론
분석 > 설계 > 개발(디자인>퍼블리싱>프로그래밍)>테스트 > 적용 > 안정화의 단계를 따른다. 
폭포수가 거슬러 올라갈 수 없듯이, 소프트웨어 개발도 반드시 앞 단계가 먼저 완료되어야 다음 단계의 개발을 진행할 수 있다.

고전적인 방법론으로 적용 사례가 풍부하다
전체 과정이 이해가 쉽다
현재 단계에 대한 이해가 빠르고 쉽다
문서, 산출물의 관리와 적용이 쉽다

병행 작업이 안된다.
피드백에 대한 반복 단계가 어렵다
테스트 단계에 발견된 중요 결함에 대한 대응이 어렵다
고객 요구 사항에 대한 상세한 반영이 어렵다

 

코코모 모델 = cocomo 

b.boehm이 1981년 초기 모델 제안, 1995 cocomo 2 로 확장
먼저 오나성될 시스템의 규모(LOC)를 추정하고 이를 준비된 식에 대입하여 소유 인원/월을 예측

1. basic cocomo
소프트웨어 개발 노력과 비용을 LOC 형태로 추정한 후 비용을 산정하는 고정 단일값 모델

2. intermediate cocomo
프로젝트 형태, 개발 환경, 개발 인력 요소에 따라 15개의 특성치를 적용한 방식

3. detailed cocomo
대형 시스템에 대하여 서브시스테므이 상이한 특성을 반영하여 비용을 개별 산정한 후 합산하는 방식
3단계 비용 산정 : 모듈, 서브시스템, 시스템 레벨
개발 단계별(SDLP)로 비용 산정방식을 달리 할 수 있음


1. organic mode
단순형 모드
5만 라인 이하
소규모 팀이 개발하는 잘 알려진 응용 시스템

2. semi-detached mode
중간형 모드
30만 라인 이하
트랜잭션 처리, 운영체제, DBMS 등

3. embedded mode
임베디드형 모드
30만 라인 이상
하드웨어 포함된 최상위 규모의 실시간 처리 시스템
미사일 유도, 신호기 제어 시스템



90. 소프트웨어 개발 모델 중 나선형 모델의 4가지 주요 활동이 순서대로 나열된 것은?

Ⓐ 계획 수립 Ⓑ 고객 평가
Ⓒ 개발 및 검증 Ⓓ 위험 분석

① Ⓐ-Ⓑ-Ⓓ-Ⓒ순으로 반복
② Ⓐ-Ⓓ-Ⓒ-Ⓑ순으로 반복
③ Ⓐ-Ⓑ-Ⓒ-Ⓓ순으로 반복
④ Ⓐ-Ⓒ-Ⓑ-Ⓓ순으로 반복

>> 정답 2번

 

나선형 모델 = spiral model
시스템 개발 시 위험을 최소화하기 위해 점진적으로 완벽한 시스템으로 개발해 나가는 모델

리스크 최소화를 위해 위험분석 단계가 존재
점진적으로 단계를 반복 수행해 나가는 모델
위험 부담이 큰 대형 시스템 구축에 적합

목표 설정 > 위험분석 > 구현 및 테스트 > 고객평가 및 다음 단계 수립

프로토타입 모델을 기반

 

91. 소프트웨어 비용 추정모형(estimation models)이 아닌 것은?
① COCOMO
② Putnam
③ Function-Point
④ PERT

>> 정답 4번

 

소프트웨어 비용 추정 모형
1. cocomo 모형
보헴이 제안한 모형으로 프로그램 규모에 따라 비용 산정
2. putnam 모형
소프트웨어 개발 주기의 간 단계별 요구할 인력의 분포를 가정하는 모형
3. fp 모형
요구 기능을 증가시키는 인자별로 가중치를 부여하여 기능의 점수를 계산하여 비용을 산정하는 방식

프로젝트 일정 계획 
1. pert
작업들의 선후 관계를 표현 작업 패키지들의 순서에 관한 정보로 사이클이 없는 방향 그래프

2. was = work breakdown structure
작업 분할 구조 프로젝트 수행을 위해 개발 업무를 분할하여 계층 구조로 표현 최하위 수준의 작업을 작업 패키지라고 하며 정량적으로 측정 가능한 입력 물과 출력물을 가짐 프로젝트 계획과 관리를 위한 기초 자료

3. CPM
임계 경로 방법 임계 경로는 시작에서 종료 작업까지의 경로 중 가장 긴 경로 임계 경호 상의 작업들은 프로젝트의 일정 준수를 위해 지연이 허용되지 않는 작업 임계경로 상에 있지 않는 작업들은 여유 시간을 가진

4. 간트 gantt 차트
막대 모양으로 프로젝트 작업들의 순차 또는 병행 순서를 보여주는 차트 상단에 시간축을 표시, 작업별로 막대 표시 막대는 작업 시간에 맞추어지며 길이는 소요 시간을 의미 인력 배정 등의 자원 활용에도 사용됨

95. CBD(Component Based Development) 에 대한 설명으로 틀린 것은?
① 개발 기간 단축으로 인한 생산성 향상
② 새로운 기능 추가가 쉬운 확장성
③ 소프트웨어 재사용이 가능
④ 1960년대까지 가장 많이 적용되었던 소프트웨어 개발 방법 > 구조적 : 폭포수

>> 정답 4번

 

CBD 방법론
재사용 가능한 컴포넌트의 개발 또는 사용 컴포넌트들을 조합하여 어플리케이션 개발 생산성, 품질을 높이고, 시스템 유지 보수 비용을 최소화할 수 있는 혁신 개발 방법론
아키텍쳐 중심의 개발
사용자 관점에서의 출발
UML 사용
반복 개발 방법
재사용 중시

 

91. 프로토타입을 지속적으로 발전시켜 최종 소프트웨어 개발까지 이르는 개발방법으로 위험관리가 중심인 소프트웨어 생명주기 모형은?
① 나선형 모형 ② 델파이 모형
③ 폭포수 모형 ④ 기능점수 모형

>> 정답 1번
나선형 모델 = spiral model
시스템 개발 시 위험을 최소화하기 위해 점진적으로 완벽한 시스템으로 개발해 나가는 모델

리스크 최소화를 위해 위험분석 단계가 존재
점진적으로 단계를 반복 수행해 나가는 모델
위험 부담이 큰 대형 시스템 구축에 적합

목표 설정 > 위험분석 > 구현 및 테스트 > 고객평가 및 다음 단계 수립

프로토타입 모델을 기반

99. 폭포수 모형의 특징으로 거리가 먼 것은?
① 개발 중 발생한 요구사항을 쉽게 반영할 수 있다. > 애자일
② 순차적인 접근방법을 이용한다.
③ 단계적 정의와 산출물이 명확하다.
④ 모형의 적용 경험과 성공사례가 많다.

>> 정답 1번

 

폭포수 모델 = waterfall model
소프트웨어 개발 시 단계적으로 개발하는 방법론
분석 > 설계 > 개발(디자인>퍼블리싱>프로그래밍)>테스트 > 적용 > 안정화의 단계를 따른다. 
폭포수가 거슬러 올라갈 수 없듯이, 소프트웨어 개발도 반드시 앞 단계가 먼저 완료되어야 다음 단계의 개발을 진행할 수 있다.

고전적인 방법론으로 적용 사례가 풍부하다
전체 과정이 이해가 쉽다
현재 단계에 대한 이해가 빠르고 쉽다
문서, 산출물의 관리와 적용이 쉽다

병행 작업이 안된다.
피드백에 대한 반복 단계가 어렵다
테스트 단계에 발견된 중요 결함에 대한 대응이 어렵다
고객 요구 사항에 대한 상세한 반영이 어렵다

 

 

89. Rayleigh-Norden 곡선의 노력 분포도를 이용한 프로젝트 비용 산정기법은?
① Putnam 모형 ② 델파이 모형
③ COCOMO 모형 ④ 기능점수 모형

>> 정답 1번

 

 

 

 

 

86. COCOMO model 중 기관 내부에서 개발된 중소 규모의 소프트웨어로 일괄 자료 처리나 과학기술 계산용, 비즈니스 자료 처리용으로 5만 라인 이하의 소프트웨어를 개발하는 유형은?
① embeded ② organic
③ semi-detached ④ semi-embeded

>> 정답 2번
규모 > organic

분류 > embeded, 




90. 소프트웨어 비용 산정 기법 중 개발 유형으로 organic, semi-detached, embedded로 구분되는 것은?
① PUTNAM ② COCOMO
③ FP ④ SLIM


>> 정답 2번

87. 소프트웨어 비용 추정 모형(estimation models)이 아닌 것은?
① COCOMO ② Putnam
③ Function-Point ④ PERT

>> 정답 4번 pert 일정계획

83. CBD(Component Based Development) SW개발 표준 산출물 중 분석 단계에 해당하는 것은?
① 클래스 설계서 ② 통합시험 결과서
③ 프로그램 코드 ④ 사용자 요구사항 정의서

>> 정답 4번





94. S/W 각 기능의 원시 코드 라인수의 비관치, 낙관치, 기대치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정하는 기법은?
① Effort Per TSK 기법
② 전문가 감정 기법
③ 델파이기법
④ LOC기법

>> 정답 4번

97. 소프트웨어 생명주기 모형 중 Spiral Model에 대한 설명으로 틀린 것은?
① 비교적 대규모 시스템에 적합하다.
② 개발 순서는 계획 및 정의, 위험 분석, 공학적 개발, 고객 평가 순으로 진행된다.
③ 소프트웨어를 개발하면서 발생할 수 있는 위험을 관리하고 최소화하는 것을 목적으로 한다.
④ 계획, 설계, 개발, 평가의 개발 주기가 한 번만 수행된다. > 반복, 한번은 폭포수

>> 정답 4번

87. Cocomo model 중 기관 내부에서 개발된 중소규모의 소프트웨어로 일괄 자료 처리나 과학기술계산용, 비즈니스 자료 처리용으로 5만 라인 이하의 소프트웨어를 개발하는 유형은?
① Embeded ② Organic
③ Semi-detached ④ Semi-embeded

>> 정답 2번

86. 생명주기 모형 중 가장 오래된 모형으로 많은 적용 사례가 있지만 요구사항의 변경이 어렵고 각 단계의 결과가 확인 되어야 다음 단계로 넘어갈 수 있는 선형 순차적, 고전적 생명 주기 모형이라고도 하는 것은?
① Waterfall Model ② Prototype Model
③ Cocomo Model ④ Spiral Model

>> 정답 1번





97. 소프트웨어 개발 방법론 중 CBD(Component Based Development)에 대한 설명으로 틀린 것은?
① 생산성과 품질을 높이고, 유지보수 비용을 최소화할 수 있다.
② 컴포넌트 제작 기법을 통해 재사용성을 향상시킨다.
③ 모듈의 분할과 정복에 의한 하향식 설계방식이다.
④ 독립적인 컴포넌트 단위의 관리로 복잡성을 최소화할 수 있다.


>> 정답 3번

96. 소프트웨어공학에 대한 설명으로 거리가 먼 것은?
① 소프트웨어공학이란 소프트웨어의 개발, 운용, 유지보수 및 파기에 대한 체계적인 접근 방법이다.
② 소프트웨어공학은 소프트웨어 제품의 품질을 향상시키고 소프트웨어 생산성과 작업 만족도를 증대시키는 것이 목적이다.
③ 소프트웨어공학의 궁극적 목표는 최대의 비용으로 계획된 일정보다 가능한 빠른 시일 내에 소프트웨어를 개발하는 것이다.
④ 소프트웨어공학은 신뢰성 있는 소프트웨어를 경제적인 비용으로 획득하기 위해 공학적 원리를 정립하고 이를 이용하는 것이다.

>> 정답 3번

최소 비용 최대 효과


87. 정형화된 분석 절차에 따라 사용자 요구사항을 파악, 문서화하는 체계적 분석방법으로 자료흐름도, 자료사전, 소단위명세서의 특징을 갖는 것은?
① 구조적 개발 방법론 ② 객체지향 개발 방법론
③ 정보공학 방법론 ④ CBD 방법론

>> 정답 1번


86. LOC기법에 의하여 예측된 총 라인 수가 36,000라인, 개발에 참여할 프로그래머가 6명, 프로그래머들의 평균 생산성이 월간 300라인일 때 개발에 소요되는 기간은?
① 5개월 ② 10개월
③ 15개월 ④ 20개월

>> 정답 4번


84. 나선형(Spiral) 모형의 주요 태스크에 해당되지 않는 것은?
① 버전 관리 ② 위험 분석
③ 개발 ④ 평가

>> 정답 1번

93. 다음 내용이 설명하는 소프트웨어 개발 모형은?

소프트웨어 생명주기 모형 중 Boehm이 제시한 고전적 생명주기 모형으로서 선형 순차적 모델이라고도 하며, 타당성 검토, 계획, 요구사항 분석, 설계, 구현, 테스트, 유지보수의 단계를 통해 소프트웨어를 개발하는 모형

① 프로토타입 모형 ② 나선형 모형
③ 폭포수 모형 ④ RAD 모형

>> 정답 3번





95. 소프트웨어 개발 모델 중 나선형 모델의 4가지 주요 활동이 순서대로 나열된 것은?

Ⓐ 계획 수립 Ⓑ 고객 평가
Ⓒ 개발 및 검증 Ⓓ 위험 분석

① Ⓐ－Ⓑ－Ⓓ－Ⓒ 순으로 반복
② Ⓐ－Ⓓ－Ⓒ－Ⓑ 순으로 반복
③ Ⓐ－Ⓑ－Ⓒ－Ⓓ 순으로 반복
④ Ⓐ－Ⓒ－Ⓑ－Ⓓ 순으로 반복

>> 정답 2번


94. 소프트웨어 생명주기 모형 중 고전적 생명주기 모형으로 선형 순차적 모델이라고도 하며, 타당성 검토, 계획, 요구사항 분석, 구현, 테스트, 유지보수의 단계를 통해 소프트웨어를 개발하는 모형은?
① 폭포수 모형
② 애자일 모형
③ 컴포넌트 기반 방법론
④ 6GT 모형

>> 정답 1번

88. COCOMO 모델의 프로젝트 유형으로 거리가 먼 것은?
① Organic ② Semi-detached
③ Embedded ④ Sequential

>> 정답 4번


86. Putnam 모형을 기초로 해서 만든 자동화 추정 도구는?
① SQLR/30 ② SLIM
③ MESH ④ NFV

>> 정답 2

84. 기능점수(Functional Point)모형에서 비용 산정에 이용되는 요소가 아닌 것은?
① 클래스 인터페이스
② 명령어(사용자 질의수)
③ 데이터파일
④ 출력보고서

>> 정답 1번

---

https://www.youtube.com/watch?v=hUxv_x6aEnA&list=PLSJppxP3IVqV8DkvGqZIv4q6VVMerJRYy&index=16&t=4s 

---

하드웨어 > 인프라

소프트웨어 개발 방법론 
> 프로그램

1. 구조적 방법론
분할과 정복의 원칙 divide&conquer
프로그램 로직 중심
컨트롤 가능한 모듈로 구조화 > 재사용, 유지보수성 제고
계산용

개발 단계별 주요 산출물
계획 > 도메인 분석서, 프로젝트 계획서
분석 > Data flow diagram, process 중심
프로그램 로직 중심이기 때문에 로직 중심의 분석을 한다. 
설계 > structure chart, 프로그램 명세서

>> 로직, 프로세스

2. 정보공학 방법론
상용 소프트웨어 등장(기업 비중이 늘어남)
기업 업무 지원 시스템 지원 방법론
data model 중시
프로그램 로직은 데이터 구조에 종속 CRUD
데이터 중심
전사적 통합 데이터 모델

개발 단계별 주요 산출물
계획 > 도메인 분석서, 프로젝트 계획서
분석 > E-R diagram, 기능차트, event 모델
E-R 다이어그램 : 엔티티와 릴레이션 모델이 중요함
설계 > 어플리케이션 궂도, 프로그램 명세서,  table 정의서/목록
데이터가 중요하기 때문에 table 정의서가 중요

>> 데이터

3. 객체 지향 방법론
상용 소프트웨어(개인 및 다양한 분야에서 확장되어 사용됨)
프로그램원소는 객체
데이터와 로직을 통합(객체)
고도의 모듈화
상속에 의한 재사용( white box Reuse)
분석-설계간 gap이 없음

개발 단계별 주요 산출물
계획 > Biz process/cocept model, 프로젝트 계획서
분석 > use case diagram, sequence diagram, class diagram.
>> 분석은 이용자 설계는 개발자 둘 사이의 차이가 있었으나 객체를 통하여 통합됨
설계 > sequence diagram, class diagram, domponent diagram, deployment diagram.
분석과 설계의 다이어그램(그림, 매개체로)사용한다
이를UML이라고 한다. > 사용자와 개발자 둘다 이해할 수 있다

>> 프로세스 + 데이터 = 객체

4. CBD 방법론
객체 방법론의 진화된 형태
interface 중시
인터페이스의 구현이 컴포넌트
black box reuse 지향 > 컴포넌트 속의 기능은 모르지만 인터페이스를 통해서 이용
>> 컴포넌트 조립

개발 단계별 주요 산출물
계획 > Biz process/concept model, 프로젝트 계획서
분석 > use case diagram, business type diagram, component diagram(논리), 재사용 계획서
설계 > sequence diagram, class diagram, component diagram(물리)


>> component > 객체들의 집합(단독 실행이 가능한)

위의 모두 절차와 개발 산출물을 중요시 하는 방법론

애자일 방법론 원리
애자일 방법론은 요구 사항을 민접하게 개발에 반영한다.
프로토타입 으로 반영 > 요구 사항 반영 > 개발 반영 > 프로토타입으로 반영 (반복)

 
고객 참여 : 고객은 개발 프로세스 전체에 긴밀하게 참여해야 한다. 고객의 역할은 새로운 시스템 요구 사항을 파악하고 우선순위를 결정하고, 시스템의 반복을 평가한다.
>> 모든 일에 고객이 참여한다.

점증적인 인도 : 소프트웨어 각 증분에 포함될 요구 사항을 명세화하는 고객에게 점증적으로 인도된다

사람은 프로세스가 아님 : 개발팀의 기술이 인식되고 활용되어야 한다. 팀 구성원들은 규정된 프로세스 없이 자신들의 작업 방식으로 개발해야 한다.

변경을 수용 : 시스템 요구 사항이 변경될 것을 예상하여, 이 변경들을 수용할 수 있도록 시스템을 설계한다.

단순성의 유지 : 개발중인 소프트웨어와 개발 프로세스 모두 단순성에 초점을 맞춘다. 가능하면 시스템에서 복잡성을 제거하기 위해 적극적으로 작업한다.


전통적인 개발 방법과 애자일 개발 방법의 비교

전통적인 개발 방법 
> 구조적, 정보공학, 객체지향, CBD
계획 수립 : 확정된 범위, 초기에 상세 요구사항 확정, 초기 일정 계획 수립
개발 및 테스트 : 분석, 설계, 구현, 테스트를 순차적으로 수행
프로세스 view : 정형화되고 상세화됨
업무 수행 형태 : 관리자 주도적 명령과 통제 개인 단위로 업무 수행
조직 : functional team, 분업화되고 역할이 한정
팀관리 : 지시 및 감시, 경쟁, 개별 평가
문서화 : 중량 프로세스, 상세한 문서화 강조
성공요소 : 계획 준수

> 계획 확정, 문서화

애자인 개발
계획수립 : 유동적인 범위 및 상세 요구 사항 조정 주기적인 상세계획
개발 및 테스트  : 이터레이션 단위로 실행 소프트웨어를 전달(적시설계,개발)
프로세스 view : 유연하고 간소함. 프로젝트 성향에 따라 주기적 조정
업무 수행 형태 : self-organizing 팀, 팀 중심 업무 수행 collective ownership
조직 : cross-functional team, 전문가가 다기능을 수행
팀관리 : 업무 몰입 및 코칭, 팀평가
문서화 : 경량 프로세스 및 문서화 보다 코드 강조
성공요소 : 고객 가치 전달

> 요구 사항 반영(계획 변경), 고객 만족 = 품질 만족


애자일 방법론 절차

릴리즈 계획을 세운다. 
유저 스토리를 통해 요구 사항을 받고 
구조적 스파티크를 통해 시스템 은유를 받고
스파이크를 통해서 불확실한 추정을 전달 후 믿음직한 추정을 받아서 계획을 세운다.
이후 이 계획을 주기대로 진행한다. 
승인테스트를 해서 버그가 나오면 다시 수정하고 나오지 않는다면 고객승인 이후 작은 릴리즈를 진행한다.
승인 테스트는 유저스토리의 테스트 시나이로를 바탕으로 한다.

사용자 스토리 : 요구 사항 수집, 의사소통 도구 , 기능단위 필요한 내용을 간단하게 기재
스파이크 ; 어려운 요구 사항 혹은 잠재 솔루션을 고려한 간단한 프로그램, 사용자의 스토리 신뢰성 증대, 기술 문제의 위험 감소 목적
릴리즈 계획 ; 전체 프로젝트에 대한 배포 계획, 하나의 반복을 1-3주로 나누어 반복들을 균일하게 유지
승인ㅔ스트 릴리즈 전 인수 테스트 고객이 수행
소규모 릴리즈 작은 배포는XP 주기의 마지막 단계 소규모로 빈번하게 배포하면 고객에게 여러 이득을 조기에 제공

애자인 방법론 종류
1. 익스트리 프로그래밍 XP
애자일 방법론의 대표주자로 애자일 방법론 보급에 큰 역할을 함. 이 방법은 고객과 함께 2주 정도의 반복 개발을 하고, 테스트와 우선 개발을 특징으로 하는 명시적인 기술과 방법을 가지고 있음

2. 스크럼 scrum 
30일마다 동작 가능한 제품을 제공하는 반복적인 개발주기sprint를 중심으로 학 있음. 메일 정해진 삭ㄴ에 정해진 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심의 방법론

3. 크리스털 패밀리 cystal family
프로젝트의 규모와 영향의 크기에 따라서 여러 종유릐 방법론을 제공함. 그중에서 가장 소규모 팀에 적용하는 크리스털 클리어는 익스트림 프로그래밍만큼 엄격하지 않고 효율도 높지 않지만 프로젝트에 적용하기 쉬운 방법론임.

4. FDD : Feature-Driven Development
기능마다 2주 정도의 반복 개발을 실시. UML을 이용한 설계기법과도 밀접한 관련이 있음

5.ASD : Adaptive Software Development
소프트웨어개발을 혼란 자체로 규정하고, 혼란을 대전제로 그에 적용할 수 있는 소프트웨어개발 방법을 제시하기 위해 만들어진 방법론. 내용은 다른 방법론들과 유사하지만, 합동 어플리케이션 개발 joint application development; 사용자나 고객이 개발에 참가하는 개발 방법론을 사용

상기 소개된 애자일 방법론들은 각자 다른 특징과 적용 범위가 있으며 서로 간의 조합도 가능하다. 여러 방법 중에서 자신의 프로젝트에 맞는 부분을 취사선택하여 조합하고 또 독자적인 방법을 만들어 냄으로써 큰 효과를 올리고 있다.

비용산정의 기법의 종류

상향식 비용 산정 > LOC, KLOC 등
> bottom up > 객관적인 = 코드로 판단
하향식 비용 산정 > 전문가 감정 기법, 델파이 기법
> top down > 주관식
수학적 비용 산정 > 기능점수, 코코모, putnam
 > 계산

* 하향식 비용 산정 기법
1. 전문가 판단 기법
전문가 : 사내, 발주기관 담당자, 소프트웨어 개발 수요 기관/부서에서 판단

경험이 많은 전문가가 개발 비용 선정 > 신뢰성 높음
짧은 시간에 개발비를 산정하거나 입찰에 응해야 하는 경우 많이 사용
단점 : 수학적 계산방법보다 경험에만 의존할 경우 부정확할 수 있음

2. 델파이
전문가 판단 기법 보완
외부 전문가에게 의뢰

전문가 비용 산정 > 익명 제출
조정자 낭독(전문가 의견)
전문가 의견 일치 여부 
일치하면 비용 산정
아니라면 처음부터 다시 시작

* 상향식 산정 기법
세부 작업 단위별로 비용 산정한 후 전체 비용 합산
단점 : 수학적 계산 방법보다 경험에 의존할 경우 부정확할 수 있음

1. 원시코드라인수 LOC 기법
원시 코드 라인 수의 비관치, 낙관치, 중간치를 측정한 후 예측지를 구해 비용 산정
> 수학적 계산보다는 예측치를 가 있기 때문에

측정이 용이하고 이해가 쉬워 가장 많이 사용된다
예측치를 이용하여 생산성, 노력 개발 기간 등의 비용을 산정한다.

예측치 : 낙관치 + (4*중간치(기대치))+비관치 /6


2. 개발 단계별 노력 effort per task 기법
생명주기의 각 단계별(분석, 설계, 개발, 테스트) 노력 m/m 을 산정(인건)
> 원단위 인건비

LOC를 보완해서 등장한 방법 + 인력과 자원
코딩만 대상으로 산정하는 LOC보다 더 정확
민간에서 많이 사용하는 산정 기준


* 수학적 산정 기법
상향식 비용 산정 기법
경험적 추정 기법 도는 실험적 추정 기법

1. COCOMO 기법
소프트웨어 규모 (LOC) 예측한 후 소프트웨어 종류에 따라 각 비용 산정 공식에 대입하여 비용 산정

<소프트웨어 규모로 구분>
> organic 소프트웨어 : 유기적, 조직적 50KDSI(5만라인) 이하의 프로젝트
일반 응용 프로그램
DP 및 과학용 업무 급여 관리 프로그램 등

> semidetached 소프트웨어 : 반 내장형
300KDSI(30만라인) 이하의 프로젝트
트랜잭션 처리 시스템, OS, DBMS 등

> embedded 소프트웨어 : 내장형
300KDSI(30만라인) 이상의 프로젝트
하드웨어가 포함된 실시간 시스템, 미사일 유도, 신호기 제어 시스템 등

<적용 변수 및 구체화 정도에 따른 분류>
= cocomo 종류

> basic cocomo
프로젝트 크기나 특성과는 관계 없이 원시 코드 라인 수만으로 비용을 계산
소프트웨어 크기와 모듈 개발에 의해 산정(LOC에 의존)
= 기본

>intermediate COCOME
basic cocomo 모델을 토대로 계산하거나, 다음의 4가지 특성의 15가지 요인을 의미하여 곱한 가중치 계수(노력 승수) 사용
제품의 속성 : 요구되는 신뢰도, 데이터베이스 크기, 제품의 복잡도
컴퓨터의 속성 : 수행시간의 제한, 기억장소의 제한, 가상기게의 안정성
개발요원의 속성 ; 분석가의 능력, 응용 경험, 컴퓨터와이 친숙성, 프로그래머의 능력, 프로그래밍 언어의 경험
프로젝트 속성 : 소프트웨어 도구의 이용, 프로젝트 개발 일정, 소프트웨어 공학의 활용도
= 가중치 계산 추가

> detailed cocomo
시스템을 모듈, 서브 시스템으로 세분하여 intermdiate cocomo 방식 적용
소프트웨어 환경과 구성요소가 사전에 정의되어 있어야 하며, 개발 과정의 후반부에 주로 적용, intermediate cocomo 산정 공식을 그대로 사용 
노력 승수 = 개발 공정별 노력 승수 * 개발 공정별 가중치
= 세분화 하여 가중치 계산 추가


2. Putnam 방법
소프트웨어 생명주기의 전 과정에 사용될 노력의 분포를 가정해주는 방법



3. 기능점수 FP 방법
기능 점수를 구한 후 이를 이용해 비용 산정
현장에서 사용, 공공프로젝트는 사용하도록 권장한다. 

<정의>
소프트웨어의 양과 질을 동시에 고려한 소프트웨어 규모 측정 방식
정보처리 규모와 기능적 복잡도에 의해 소프트웨어 규모를 사용자의 관점에서 특정

<등장배경>
프로그램의 재사용으로 인한 생산성 향상으로 기존 LOC 방식의 문제점 극복

<특징>
최종 사용자 입장에서 소프트웨어 규모를 견적하는 값임(개발자 입장에서 소프트웨어 견전량인 소스코드의 양과는 무관함)
프로젝트 완료 후 생산성 평가를 위해 개발되었으나 사전에 개발 소요 공식을 예측하는 모델로도 사용 가능
개발환경과 기술에 무관하게 측정가능하고, 사용자 요구에 따라 시스템 기능 설계 시 개발 중에도 측정 가능함
생산성가 품질 등의 척도로도 활용 가능

= 기능별 단가 + 단계별 투입 인력 단가 

<용도>
개발시 비용 산정
유지 보수 비용 산정
개발시 필요한 자원 산정

<특징>
소프트웨어 규모를 측정하는 방법
기능적 요구 사항이 중심이 되는 측정 방법
소프트웨어의 요구 사항 복잡도를 측정
구현 관점이 아닌 사용자 관점의 요구 기능을 정량적으로 산정 > 가중치
측정의 일관성을 유지를 위해 개발 기술, 개발방법, 품질 수준 등을 고려 하지 않음
소프트웨어 개발에 사용하는 언어와 무관
소프트웨어 개발 생명주기의 전체 단계에서 사용 가능


기능점수 
> 데이터 기능 = 내부 논리 파일 ilf + 외부 연계 파일 eif
> 트랜잭션 기능 = 외부 입력 + 외부 출력 + 외부 조회


1. 정규 기능 점수법
설계 단계 이후 사용 하면 유용
기능 도출 > 유형별 복잡도 계산 > 기능 점수 산정

2. 간이 기능 점수법
기획 및 발주 단계에서 사용
기능 도출 > 평균 복잡도 적용 > 기능 점수 산정
프로젝트 초기 단계에서 평균 복잡도 가중치를 사용하여 소프트웨어 기능의 크기를 측정
1. 측정 유형 결정 : 개발, 개선, 애플리케이션
2. 측정 범위와 애플리케이션 경계 식별 
3. 데이터 기능 점수 계산 : 데이터 기능(내부 논리 파일, 외부 연계 파일) 도출 > 도출된 데이터 기능(내부 논리/외부 연계 파일)의 개수 * 평균 복잡도 가중치
4. 트랜잭션 기능 점수 계산 : 트랜잭션 기능(외부 입출력, 외부 조회) 도출 > 도출된 트랜잭션 기능(외부 입출력, 외부 조회)의 개수 * 평균 복잡도 가중치
5. 보정 전 개발 원가 계산 : 총 기능 점수 * 기능 점수당 단가(총 기능 점수 = 데이터 기능 점수 + 트랜잭션 기능 점수)
6. 보정후 개발 원가 계산 : 보전 전 개발 원가 * 4가지 보정 계수(규모, 애플리케이션 유형, 언어, 품질 및 특성)