소프트웨어 공학 - 요약 #4

---

프로세스와 방법론의 비교

	프로세스	방법론
특징	1. 단계적인 작업의 틀을 정의한 것 2. 무엇을 하는가에 중점 3. 결과물이 표현에 대하여 언급 없음 4. 패러다임에 독립적 5. 각 단계가 다른 방법론으로도 실현 가능	1. 프로세스의 구체적인 구현에 이름 2. 어떻게 하는가에 중점 3. 결과물을 어떻게 표현하는지 표시 4. 패러다임에 종속적 5. 각 단계의 절차, 기술, 가이드라인을 제시
사례	- 폭포수 모델 - 나선형 모델 - 프로토타이핑 모델 - 통합 프로세스 - 애자일 프로세스	- 구조적 분석, 설계 방법론 - 객체지향 방법론 - 컴포넌트 - 애자일 방법론

• 크게 구분하지 않고 쓰는 경우도 많음

---

지원 프로세스

• 국제 표준 기구에서 개발 프로세스 말고도 여러 프로세스가 존재한다고 정함
• 다양한 시각에서 프로세스들이 있을 수 있다는 것

1. 관리 프로세스

• 결국은 개발이 진행되는걸 관리하는 것에 필요한 작업들을 명시
• 초반에는 계획을 세우고 중간에는 모니터링과 제어, 후반에는 결과분석

2. 품질 보증 프로세스

• 고품질의 소프트웨어를 어떻게 효율적으로 개발하는가?
• 개발 산출물과 개발 프로세스에 대한 품질을 관리하고 향상시킬 목적의 프로세스 
• 인스펙션 프로세스 : 검사 프로세스
• 프로세스 관리 프로세스 : 개발 프로세스 하나하나를 관리해야 하는 프로세스 → 개발 프로세스가 잘 진행이 되어야 함 / 능력 성숙도 모델(CMM)

3. 형상 관리 프로세스

• 프로젝트 산출물들의 모양을 관리
• 베이스라인 관리

---

방법론

1. 구조적 방법론

• 폭포수 모델부터 쓰이던 것
• 요구 정의 필요 → 요구에 대한 분리와 정복 원리 적용
• 자료 흐름도, 구조도, 상태도, 페트리네트 등

구조도 : 모듈 사이의 관계를 나타내는 그래프(밀러의 법칙)

2. 정보공학 방법론

• 기업 중심
• 전략적 시스템 계획 중심
• 데이터 중심
• 사용자 적극적 참여

3. 객체지향 방법론

• 구조적 방법론은 기능을 뽑아내는 것에 주를 둠
• 대상들을 정해놓고 대상들을 상호 작용하도록 만듦
• 대상이 자기의 기능과 속성, 정보를 가지고 있음
• 모든 대상은 정보를 가지고 있는데 이 정보라는 것은 어떤 행위를 통해 변경됨
• 여러 객체들이 상호작용
• 객체가 선언되어 있음 → 객체는 클래스로부터 만들어짐
• 객체는 이름과 속성, 메소드로 구성 

---

프로젝트 관리와 계획

프로젝트 관리의 목적

• 프로젝트 목표 달성을 위함

소프트웨어 공학의 목표

1. 고품질 소프트웨어 개발
2. 고품질의 소프트웨어를 정해진 비용 안에서 개발
3. 정해진 기간 안에 개발 - 프로젝트 관리

소프트웨어 프로젝트만의 어려움 존재

1. 눈에 보이지 않는 소프트웨어 → 관리 어려움
2. 기술 자체가 빠르게 변하고 있음 → 그 전의 방법, 표준, 절차를 다음 프로젝트에 적용하기 어려움
3. 조직마다 다른 프로세스와 성숙도

프로젝트 관리 활동

• 관리 활동의 요소

1. 계획
2. 조직
3. 모니터링
4. 조정

프로젝트 시작

• 모든 프로젝트는 타당성 분석 필요 → 예산, 시간, 일정, 인원, 대안, 품질 파악
• 프로젝트 가치 명시
• 프로젝트 리스크 알고 있어야 함

프로젝트 계획

• 목표 설정 : 개발할 소프트웨어에 대한 범위나 기능이 나와야 함
• 일정 정의 : 개발에 필요한 기간 정의
• 비용 추정
• 조직 구성
• 프로젝트 목표 및 범위 설정

---

작업 분해

• 필요한 작업을 계층적으로 분해
• 일정 예측이 가능한 수준까지 소작업으로 분해(WBS 사용)

일정 계획

• WBS를 기초로 작업 → 자원 할당(예측 소요 시간, 담당자), 작업 사이의 의존관계 파악
• CPM 네트워크 사용 → 최소 소요 시간과 여유 시간 산정, 병행 작업 표시
• 간트 차트 사용

PERT/CPM 네트워크

• 수 많은 경로 존재
• 모든 경로를 다 거쳐야 종료 가능
• 경로마다 소요시간 다름 

간트 차트

• CPM 네트워크 정보로부터 작성

애자일 계획의 장점

1. 높은 우선순위를 가진 사용사례가 먼저 개발, 설치
2. 사용사례 사이에 선행관계 유지
3. 각 열의 점수의 합은 개발팀의 작업 속도를 초과하지 않아야 함

---

비용 예측

비용에 영향을 주는 요소

1. 제품의 크기 : 크기가 커지면 비용도 기하급수적으로 늘어남
2. 제품의 복잡도 → 응용:개발지원:시스템 = 1:3:9
3. 요구되는 신뢰도 수준
4. 기술 수준 (개발 장비, 도구, 조직 능력, 관리, 방법론 숙달)
5. 남은 시간 → 프로젝트의 노력은 남은 개발 기간의 4제곱에 반비례(Putnam)

비용 예측 방법

1. 상향식

• 작은 일들에 대한 비용을 일일이 예측하고 나면 위의 일도 예측 가능하다는 것
• 투입 인력과 참여도를 곱하여 최종 인건비 계산

2. 하향식

• 규모 예측(LOC, 기능점수)
• 과거 경험을 바탕으로 규모를 예측
• 규모에 대한 소요 인력과 기간을 추정
• COCOMO, 기능점수, 객체점수 모델

COCOMO-81

• 1981년도 Bohem이 개발
• 통계적으로 많은 소프트웨어 분석(2K~32K 정도) 후 제안

• 사이즈 알면 사이즈에 개수 곱해주면 됨
• 어려운 프로그램일수록 MM이 1000에 가까워짐

보정계수 M

• 해당 식의 단점

1. 개발해보지 않은 프로젝트의 Size 알아야 함 → 프로젝트 초기 단계에서 해당 프로젝트의 규모 예측 어려움
2. 기본 예측 모델에서 B와 M의 값에 영향을 주는 요소들 주관적 → 보정 어려움
3. 개발 언어에 따른 코드 수 차이가 큼
4. 재사용 코드의 포함 여부

COCOMO Ⅱ

• 1995년도 Bohem이 개발
• 예측 시점에 따른 세 가지 모델 제시

1. 프로토타입 제작 단계(요구 추출 단계) : 응용 점수(어플리케이션 기능 점수) 계산
2. 초기 설계 단계 : 단위 기능들 카운트
3. 구조 설계 이후 단계 : 코드 라인 수 확장 → COCOMO-81 사용

기능 점수

• 입력, 출력, 질의, 파일, 응용 인터페이스로 크게 5가지로 분류

---