Part1.소프트웨어 설계(2)

송상민·2022년 4월 6일

정보처리기사

목록 보기

3/3

전에 이어서 공부한거 정리하려고 합니다.

Section03. 프로젝트 관리 및 생명주기 모형

프로젝트 관리⭐️

1. 일정 관리: 활동 순서, 활동 기간 산정, 일정 개발, 일정 통제
2. 예산 관리: 원가 산정, 예산 편성, 원가 통제
3. 인력 관리: 프로젝트팀 편성, 프로젝트 조직 정의, 프로젝트팀 개발, 프로젝트팀 관리, 자원 산정, 자원 통제
4. 위험 관리: 위험 식별, 위험 평가, 위험 대처
5. 춤질 관리: 품질 계획, 품질 보증 수행, 품질 통제 수행

관리를 구분할 수 있어야한다.

프로젝트 관리의 3P⭐️

1. 사람(People) 2. 문제(Problem) 3. 프로세스(Process)

프로젝트 계획 수립 목적 및 범위 측정 요소⭐️

목적

범위, 자원 비용 측정을 통해 위험성을 최소화함

범위 측정 요소

처리 기능: 소프트웨어 기능의 범위를 측정
성능: 소프트웨어의 처리 속도나 사용자 동시 접속자 수 등을 측정
제한 조건: 소프트웨어의 한계, 불가능한 기능 등의 제약 조건을 측정
개발 인원: 소프트웨어 개발 인력 수나 개발팀 조직의 형태를 측정
일정 게획: 기간, 작업 시간, 단계별 기간을 측정

목적을 찾을 수 있어야하며 측정 요소가 아닌 것을 찾을 수 있어야한다.

인적 자원⭐️

개발자팀 구성

책임 프로그래머팀: 1인 독재 체체. 다수는 1인을 위해 보조 역할
민주주의식팀: 다수 책임 체제. 개개인의 담당 분야가 독립적으로 존재
혼합형팀: 책임 프로그래머팀과 민주주의식팀의 장점을 결합한 팀 구성

책임 프로그래머팀의 구성원

책임 프로그래머(Chief Programmer): 요구분석과 설계, 기술적인 판단, 작업 지시와 배분 담당
보조 프로그래머(Back-up Programmer): 책임 프로그래머를 보좌, 기술적인 자문, 사용자, 품질 보증 담당자 섭외, Chief 감독하에 분석, 설계, 구현까지도 담당
프로그래머(Programmer): 책임 프로그래머의 지시에 따라 원시 코드 작성, 검사, 디버깅 및 문서 작성 등을 담당
프로그램 사서(Program Librarian): 프로그램 리스트, 설계 문서, 검사 계획서 등의 문서를 관리

개발자 팀 구성을 구분하고 책임 프로그래머팀의 구성원 역할을 구분할 수 있어야한다.

PERT(Program-Evaluation and Review Technique) 네트워크 CPM(Critical Path Method) 네트워크⭐️

	PERT	CPM
특징	-소요기간의 예측이 어려운 경우 유리 -작업별로 낙관치, 기대치, 비관치를 나누어 종료시기 결정 -노드에는 작업명, 간선에는 낙관치, 기대치, 비관치를 표시 -예측치 공식을 이용하여 소요 기간을 정함	-소요 기간이 확실한 경우에 유리 노드는 작업명, 간선은 작업 사이의 전후 의존 관계를 표시 원형 노드와 박스 노드로 구분 -원형 노드는 작업명, 박스 노드는 이정표와 예상 완료 시간을 표시 - 한 이정표에서 다른 이정표에 도달하기 전에 작업을 완료해야 함
*일정 계획 순서*	1.소프트웨어의 전체 규모를 추정 2.소프트웨어의 작업을 기능별, 특징별로 분류한다. 3.단계별로 작업 일정을 예측한다. 4.전체 소요 기간을 예측한다.	1.소프트웨어의 전체 규모를 추정한다. 2.소프트웨어의 작업을 기능별, 특징별로 분해한다. 3.단계별 상호 의존 관계를 CPM 네트워크로 도식한다. 4.간트 차트를 작성한다.

PERT의 일정 계획

전체 작업을 A~G 작업으로 구분한다.
작업별로 낙관치, 기대치, 비관치를 간선에 표시한다.
예측치 = $낙관치 + (4 * 기대치) + 비관치\over 6$

CPM 일정 계획

전체 작업을 A~I의 소작업으로 구분한다.
이정표에는 각 작업의 소요기간에 대한 세부적인 사항 기록
빠른 착수일, 늦은 착수일, 여유기간 구할줄 알아야한다.

PERT, CPM을 구분할 줄 알고, 일정 계획 순서와 임계경로 착수일, 여유 기간을 계산할 수 있어야한다.

위험 관리⭐️

위험 관리 순서

1. 위험 식별: 위험 요소가 될 사항들을 파악한다.
2. 위험 분석 및 평가: 위험의 비중과 영향력을 파악한다.
3. 위험 관리 계획: 위험을 예방하고 발생 시에 대인들을 준비하고 문서화한다.
4. 위험 감시 및 조치: 위험을 항상 관찰하고, 발생 시 조치한다.

위험표의 항목

1. 위험의 내용 2.위험의 종류 3. 위험 발생 확률 4. 영향력 5. 대안

위험 관리 순서 기억하고 위험표 항목 기억!

비용 측정⭐️

비용 측정 요소

직접 측정 요소
- 수치, 양 크기처럼 직접적으로 측정이 가능한 요소이다.
- 노력(인월), 비용, 라인 수(LOC), 오류 수, 투입 인원, 처리 속도, 문서 수 등이 있다.
간접 측정 요소
- 비교 대상이 있어야 측정이 가능한 요소이다.
- 생산성, 품질, 기능 점수(FP), 문서화 비율, 효율성, 신뢰도, 유지보수성 등이 있다.

직접 측정 요소와 간접 측정 요소를 구분할 수 있어야함

비용 측정의 원칙

1. 소프트웨어 비용 측정을 최대한 지연 시킨다.
2. 분해 기술 이용한다.
3. 실험적 비용 측정 모델 이용한다.
4. 자동화 도구를 이용한다.

비용 측정의 원칙이 아닌 것은?

간접 측정 평가 공식

 생산성 = LOC / 인월
 개발 기간 = 인월 / 개발 인원
 개발 비용 = 인월 * 단위 비용

비용 측정 방법론

하향식 - 전체 비용 측정 후 기능이나 단계별 비용으로 분리
- 전문가 측정
- 델파이식 측정
상향식 - 기능이나 단계별로 비용 측정 후 전체 비용 측정
- LOC 측정
- 단계별 인월
- 수학적 산정
  - Walston 모형
  - COCOMO 모형
  - Putnam 모형
  - 기능 점수 모형
  - 간이 기능 점수

COCOMO모형(Basic COCOMO)

유기형(Organic)
- 기간내부에서 개발된 중소 규모의 소프트웨어로 일괄 처리나 과학기술 계산용, 비즈니스 자료 처리용으로 5만 라인 이하의 소프트웨어를 평가하는 유형

MM = 2.4 * [KDSI]^1.05

TDEV = 2.5 * [MM]^0.38

여기서 KDSI는 KLOC(전체 라인 수)에서 공백 라인, 주석, 라이브러리
등을 제외한 실제 수행되는 명령어 라인 수이다.  MM은 인월을 의미한다.
TDEV는 개발기간을 의미한다.

준 분리형(Semi-Detached)
- 트랜잭션 처리 시스템이나 운영체제, 데이터베이스 관리 시스템 등의 30만 라인 이하의 소프트웨어를 평가하는 유형 $MM = 3.0 * [KDSI]^1.12$ $TDEV = 2.5 * [MM]^0.35$
내재형(Embedded
- 최대형 규모의 트랜잭션 시스템이나 운영체제 등의 소프트웨어를 평가하는 유형 $MM = 3.6 * [KDSI]^1.20$ $TDEV = 2.5 * [MM]^0.32$

유형별로 특징을 알고 해당 유형을 설명할 수 있어야함.

Putnam 모형

대형 프로젝트에 이용되는 기법
시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력 분포도 곡선으로 그려진다.
개발 기간이 연장될수록 프로젝트 적용 인원의 노력이 감소하므로 대형 프로젝트의 노력 분포 산정에 용이
putnam 모형을 기초로 해서 만든 자동화 추정 도구는 SLIM이다.
SLIM은 총인월(MM), 개발 기간 등의 비용 측정값을 입력하면 소프트웨어 비용 산출을 자동으로 출력해준다.
putnam 모형 공식

MM =

LOC^3 \over [개발 기술 지수]^3 * [개발 기간]^4

LOC =

[개발 기술 지수] * [MM]^1/3* [개발 기간]4/3

SLIM 은 Putnam을 통해 만들어졌으며 공식 알아야함

기능점수모형

기능 점수 모형과 LOC 측정의 비교

구분	기능 점수	LOC 측정
적용 시점	전체 생명 주기	구현 이후
고객과의 소통	좋음	나쁨
관점	고객 관점 논리적	개발자 관점 물리적
표준	국제 표준(ISO/IEC 14143)	없음

기능 점수의 비용 산정 요소

입력 유형의 수: 형식이 다른 입력 양식의 수, 입력 파일
출력 유형의 수: 형식이 다른 출력 양식의 수, 출력 보고서
사용자 명령어 수: 데이터 구조 변경을 위한 명령이 아니라 프로그램을 실행하는 명령 수, 사용자 질의 수
데이터 파일의 수: 시스템에 의해 생산되는 내부 파일의 수
인터페이스의 수: 외부 프로그램과의 연계되는 수

기능 점수 모형과 LOC 측정 구분, 기능 점수의 비용 산정 요소가 아닌 것을 찾을 수 있어야함.

형상 관리(SCM: Software Configuration Management)⭐️

형상 관리 절차

➀형상 식별

형상 관리 대상을 식별하고 이름과 관리 번호를 부여하여 계층 구조(트리구조)로 구분한다.
수정 및 추적이 용이하도록 하는 작업으로 베이스라인의 기준을 정하는 활동이다.

➁변경 제어

식별된 형상 항목의 변경 요구를 검토, 승인하여 적절히 통제함으로써 현재의 베이스라인에 잘 반영될 수 있도록 조정하는 작업이다.
적절한 형상 통제가 이루어지기 위해서는 형상통제위원회 승인을 통한 통제가 이루어질 수 있어야 한다.

➂형상 상태 보고

베이스라인의 현재 상태 및 변경 항목들이 제대로 반영되는 여부를 보고하는 절차이다.
형상의 식별, 통제, 감사 작업의 결과를 기록 및 관리하고 보고서를 작성하는 작업이다.

➃형상 감사

베이스라인의 무결성을 평가하기 위해 확인, 검증 과정을 통해 공식적으로 승인하는 작업을 말한다.

형상 관리 항목

- 소프트웨어 공학 기반 표준과 절차: 방법론, 개발 표준 등
- 소프트웨어 프로젝트 계획서
- 소프트웨어 요구사항 명세서
- 소프트웨어 아키텍처, 실행 가능한 프로토타입
- 소프트웨어 화면, 프로그램 설계서

-데이터베이스 기술서: 스키마, 파일 구조, 초기 내용등
-소스 코드 목록 및 소스 코드
- 실행 프로그램
- 테스트 계획, 절차, 결과
- 시스템 사용 및 운영과 설치에 필요한 매뉴얼

- 유지보수 문서: 변경 요청서, 변경 처리 보고서 등
- 개발 비용은 절대 형상 관리 항목이 될 수 없음

형상 관리 절차, 형상 관리 항목이 아닌것을 기억. 비용은 형상 관리 항목x

소프트웨어 개발의 생명주기 모형⭐️❗️

폭포수 모형

개발순서

폭포수의 물흐름처럼 한 번 지나가면 다시는 되돌릴 수 없듯이 각 단계를 명확히하고 다음 단계로 넘어가는 모형
단계가 이미 정해져 있으며 어느 한 단계에 문제가 생겨도 이전 단계 혹은 전전 단계로 되돌아갈 수 없는 것이 원칙
가장 오래된 모형으로 많은 적용 사례가 있지만 요구사항의 변경이 어려움
각 단계의 결과가 확인되어야만 다음 단계로 넘어감
선형 순차적 모형으로 고전적 생명주기 모형이라고도 함
두 개 과정이 병행 수행되거나 이전 단계로 넘어가는 경우가 없음
사용자의 요구를 만족하는지는 최종적인 결과물이 나와야 확인할 수 있음

특징

순차적인 접근 방법을 이용
단계적 정의와 산출물이 명확
단계별로 문서화 작업이 필요
오류 없이 명확하게 다음 단계로 진행
새로운 요구나 경험을 설계에 반영하기 어려움
개발이 완료되고 사용자의 의견을 반영 가능
항공 방위 소프트웨어 시스템 개발 경험을 토대로 처음 개발
유사한 개발 경험이 있는 경우 효율적이고, 품질 우수
명확성이나 정밀성을 강조하는 경우 코딩이나 테스트 작업이 지연될 수 있음.

프로토타입

개발 순서

프로토타입

특징

요구사항의 변경이 용이
최종 결과물의 일부 또는 전체 모형을 볼 수 있음
공동의 참조 모델을 제공
구현 단계에서 구현 골격이 됨
단기간에 개발하기 때문에 비효율적인 알고리즘이나 언어를 사용할 수 있음
가상으로 시뮬레이션을 통해 결과에 대한 예측이 가능한 모델

	브룩스의 이론 
    -프로토타입 소프트웨어는 폐기 처분하는 첫 번째 시스템
    -개발 일정이 지연된다고 말기에 새인원을 투입하면 더 늦어짐

나선형 모형

개발 순서

나선형

특징

계획 수립부터 모든 단계를 반복하면서 개발
프로토타입을 지속적으로 발전시켜 최종 소프트웨어 개발, 위험 관리가 중심
폭포수와 프로토타입의 장점을 살린 모형으로 사용자 요구 확인에 의한 시스템 개발
나선형 모형은 위험 분석을 해나가면서 시스템을 개발
대규모 시스템의 소프트웨어 개발에 적합

V 모형

개발 순서

특징

V 모형은 검증을 강조한 기법
폭포수 모형에서 오류 발생 시 각 단계로 되돌아갈수 있다는 것을 드러냄
산출물보다는 각 개발 단계의 테스트에 중점을 두며 테스트 활동이 분석 및 설계와 어떻게 관려되어 있는지 보여줌
V 모형은 높은 신뢰성을 필요로 하는 의료 제어 시스템이나 원자력 발전소 제어 시스템의 등에 개발에 적합

개발 순서 알아야하고, 다른 특징을 알 수 있어야함.

테일러링을 위한 품질 관리⭐️

ISO 12207 표준

개념

소프트웨어 개발 프로세스를 정의하고 향상시키기 위한 프로세스
ISO 12207 표준은 기본 공정, 지원 공정, 조직 공정으로 구성된다.
- 기본 공정: 공급, 획득, 개발, 운영, 유지보수
- 지원 공정: 문서화, 형상 관리, 문제 해결, 품질 보증, 검증, 확인, 합동 검토, 감리
- 조직 공정: 관리, 기반 구조, 개선, 교육 훈련

ISO/IEC

ISO/IEC 9126: 소프트웨어 품질 특성과 척도에 관한 표준 지침서이다.
ISO/IEC 12119: 패키지 소프트웨어의 일반적인 제품 품질 요구사항 및 테스트를 위한 국제 표준
ISO/IEC 12509: OSI 7계층의 관리 기능에 대한 공통된 정보를 명세화하는 규격. 폐지되었다.
ISO/IEC 29119: 소프트웨어 테스트 관련 국제 표준

ISO/IEC 품질 특성

품질 특성 중 신뢰성만 순수성을 포함하지 않는다. 특성 구분과 영어로 나올 수 있으니 영어단어 숙지

CMM(Capability Maturity Model)

CMM의 5가지 성숙 단계와 핵심 프로세스

성숙 단계	정의	핵심 프로세스
1.초기 단계(Initial)	-소프트웨어 개발 관리 부재 -프로세스 성과를 예측 불가	없음
2.반복 단계(Repeatable)	-성공 프로젝트 반복 사용 -통계적 관리가 가능	요구 관리, 계획, 추적, 감시, 형상 관리, 품질 보증
3.정의 단계(Defined)	-프로세스 작업 정의와 이해 가능 -데이터로 프로젝트 관리 -발전되는 상태	조직 프로세스 관리, 교육 훈련 프로그램, 통합 소프트웨어 관리, 생산 공학, 동료 검토, 그룹 간 조정, 중간 심사
4.관리 단계(Managed)	-프로세스 성과 측정, 분석기능 -프로세스 성과 개선, 관리 기능	정량적 프로세스 관리, 소프트웨어 품질 관리
5.최적 단계(Optimizing)	질적, 양적 개선이 지속적인 상태	결함 예방, 기술 변화 관리, 프로세스 변경 관리

CMM 모델 프로세스 평가 기준

Level	관리 명칭	주요 내용	평가
Level1	혼돈적 관리	순서의 일관성이 없음	위험성
Level2	경험적 관리	일정, 비용의 경험적 법칙 적용	↑
Level3	정성적 관리	경험 공유, 공식적 프로세스 관리
Level4	정량적 관리	통계적 방법과 조직적 분석	↓
Level5	최적화 관리	위험 예측, 최적화 도구 이용	생산성, 품질

SPICE(Software Process Improvement and Capability dEtermination)모델

개념

소프트웨어의 품질 및 생산성 향상을 위해 소프트웨어 프로세스를 평가 및 개선하는 국제 표준이다.
소프트웨어 프로세스에 대한 개선 및 능력 측정 기준에 대한 국제 표준이다.

SPICE 모델의 프로세스 수행 능력 수준 6단계

SPICE 모델

목적

개발 기관이 프로세스 개선을 위하여 스스로 평가하는 것
기관에서 정한 요구조건을 만족하는지 개발 조직 스스로 평가
계약을 맺기 위하여 수탁 기관의 프로세스를 평가하는 것

SPICE의 CMM 단점 개선

CMM은 조직을 평가하므로 제품의 품질과는 직접적인 연관성이 없다.
CMM은 조직 전체에 대한 등급 판정이 비효율적, 비현실적이다.
CMM은 소규모 업체에서는 적용이 곤란하다.

CMMI 모델

CMMI의 프로세스 영역(PA: Process Areas)

프로세스 관리
프로젝트 관리
엔지니어링
지원

CMMI의 모델의 종류

SW-CMM: 소프트웨어 능력 성숙도 모델
SECM: 시스템 엔지니어링 능력 모델
IPD-CMM: 통합 제품 개발 능력 성숙도 모델
People-CMM: 인력의 개발과 관리
SA-CMM: 소프트웨어 획득
SECAM: 시스템 엔지니어링 능력 심사 모델

이번꺼는 여기까지!

👐🏻

송상민

실력있는 Flutter 개발자가 되어보자

이전 포스트

Part1.소프트웨어 설계(2)

정보처리기사

Section03. 프로젝트 관리 및 생명주기 모형

프로젝트 관리⭐️

관리를 구분할 수 있어야한다.

프로젝트 관리의 3P⭐️

프로젝트 계획 수립 목적 및 범위 측정 요소⭐️

목적

범위 측정 요소

목적을 찾을 수 있어야하며 측정 요소가 아닌 것을 찾을 수 있어야한다.

인적 자원⭐️

개발자팀 구성

책임 프로그래머팀의 구성원

개발자 팀 구성을 구분하고 책임 프로그래머팀의 구성원 역할을 구분할 수 있어야한다.

PERT(Program-Evaluation and Review Technique) 네트워크 CPM(Critical Path Method) 네트워크⭐️

PERT의 일정 계획

CPM 일정 계획

PERT, CPM을 구분할 줄 알고, 일정 계획 순서와 임계경로 착수일, 여유 기간을 계산할 수 있어야한다.

위험 관리⭐️

위험 관리 순서

위험표의 항목

위험 관리 순서 기억하고 위험표 항목 기억!

비용 측정⭐️

비용 측정 요소

직접 측정 요소와 간접 측정 요소를 구분할 수 있어야함

비용 측정의 원칙

비용 측정의 원칙이 아닌 것은?

간접 측정 평가 공식

비용 측정 방법론

COCOMO모형(Basic COCOMO)

유형별로 특징을 알고 해당 유형을 설명할 수 있어야함.

Putnam 모형

SLIM 은 Putnam을 통해 만들어졌으며 공식 알아야함

기능점수모형

기능 점수 모형과 LOC 측정의 비교

기능 점수의 비용 산정 요소

기능 점수 모형과 LOC 측정 구분, 기능 점수의 비용 산정 요소가 아닌 것을 찾을 수 있어야함.

형상 관리(SCM: Software Configuration Management)⭐️

형상 관리 절차

형상 관리 항목

형상 관리 절차, 형상 관리 항목이 아닌것을 기억. 비용은 형상 관리 항목x

소프트웨어 개발의 생명주기 모형⭐️❗️

폭포수 모형

개발순서

특징

프로토타입

개발 순서

특징

나선형 모형

개발 순서

특징

V 모형

개발 순서

특징

개발 순서 알아야하고, 다른 특징을 알 수 있어야함.

테일러링을 위한 품질 관리⭐️

ISO 12207 표준

개념

ISO/IEC

ISO/IEC 품질 특성

품질 특성 중 신뢰성만 순수성을 포함하지 않는다. 특성 구분과 영어로 나올 수 있으니 영어단어 숙지

CMM(Capability Maturity Model)

CMM의 5가지 성숙 단계와 핵심 프로세스

CMM 모델 프로세스 평가 기준

SPICE(Software Process Improvement and Capability dEtermination)모델

개념

SPICE 모델의 프로세스 수행 능력 수준 6단계

목적

SPICE의 CMM 단점 개선

CMMI 모델

CMMI의 프로세스 영역(PA: Process Areas)

CMMI의 모델의 종류

👐🏻

Part1. 소프트웨어 설계(1)

0개의 댓글