목적
최근에 이직을 준비하는중에 자격증이 너무 없다고 생각이 들어서 준비를 하게되었다. 또한 내가 다시 봤을때 복습겸 이해하기 글을 작성한다.
1과목 소프트웨어 설계
소프트웨어 개발 방법론 테일러링
방법론 데일러링 정의
개발 프로젝트의 특성 및 필요에 따라 기존의 소프트웨어 개발 모델을 최적화하는 활동이다.
기존 개발 모델의 절차, 활동, 산출물 등의 가공, 적용, 정제를 반복적으로 수행한다.
방법론 테일러링의 필요성
다양한 유형의 프로젝트를 하나의 정형화된 개발 모델만을 적용하기 어렵다.
개발 모델을 선정하기 위한 내부적, 외부적 요건이 서로 충돌하는 경우가 많다.
방법론 테일러링의 필요성 판단 기준
내부적 요건: 목표 환경, 요구사항, 프로젝트 규모, 보유 기술
외부적 요건: 법적 제약사항, 표준 품질 기준
개발 방법론 테일러링 프로세스
프로젝트 일정 및 자원현황 반영
기반이 되는 개발 모델에 맞춰 개발 단계별 절차수립
테일러링 완료된 개발 모델에 대한 매뉴얼 작성
소프트웨어 개발 프로젝트
미리 계획된 일정과 자원의 범위 안에서 정해진 목표를 달성하기 위한 모든 활동을 말한다.
프로젝트는 업무마다 개발 방법이나 시간이 정해져 잇으며 단계적으로 진행된다.
소프트웨어 개발 프로젝트 관리요소(5가지)
일정: 활동 순서, 활동 기간 산정, 일정 개발, 일정 통제
비용: 원가 산정, 예산 편성, 원가 통제
투입자원: 팀 편성 및 관리, 자원 산정, 조직 정의, 자원 통제
위험: 위험 식별, 위험 평가, 위험 대처, 위험 통제
품질: 품질 계획, 품질 보증 수행, 품질 통제 수행
프로젝트 비용을 결정하는 요소(3가지)
프로젝트 요소: 규모, 신뢰도, 복잡도
자원 요소: 인적자원, 하드웨어, 소프트웨어 라이선스
생산 요소: 개발 기간, 개발자의 능력
프로젝트 일정관리
시험에나옴
Brooks의 법칙: 프로젝트 진행 중에 새로운 인원을 투입할 경우 오히려 일정을 지연시킴
프로젝트 일정 계획 방법론
프로젝트 일정을 계획대로 진행할 수 있도록 스케줄을 작성하는 방법론이다.
소요 기간의 예측 가능성에 따라 PERT, CPM 등으로 나눤다.
PERT(Program Evaluation and Review Technique)
작업별 개발 기간이 불확실하여 개발 기간 내에 전체 프로젝트를 완료할 수 있을지에 대한 확률을 분석할 때 사용하는 방법이다.
암기
예측지 = (낙관지 + (4 * 기대치) + 비관치) / 6
CPM(Critical Path Method)
작업별 개발 기간이 확실한 경우에는 사용하는 방법으로 임계 경로 기법이라고도 한다.
2가지 종류의 노드와 간선으로 구성된다.
원형 노드: 특정 작업의 완료 시점
박스 노드(이정표): 해당 이정표에 정속된 모든 작업이 완료되어야 다음 작업 진해 가능
임계 경로(Critical Path=주공정): 작업 소요시간이 가장 오래 걸리는 경로
간트 차트(Cantt Chart)
프로젝트 개발 일정을 기능별로 시간의 흐름에 따라 막대 그래프를 사용하여 표현한 일정표이다.
작업 간의 의존성(선후관계) 및 작업의 문제 요인을 파악하기 어렵다.
상세한 정보를 표현하기 어려워 소규모 활동으로 이루어지는 프로젝트에 적합하다.
프로젝트 비용산정 모델
소프트웨어 사업비 종류(6가지)
정보 전략 계획 수립 비용: 적정성 및 타당성 분석을 통해 프로젝트 계획을 수립하는 업무에 대한 비용
소프트웨어 개발 비용: 소프트웨어 개발에 필요한 인원과 기간, 개발 도구 등에 대한 비용
소프트웨어 유지 보수 비용: 제품 지원, 기술 지원, 사용자 지원 등의 서비스 제공 비용
소프트웨어 재개발 비용: 개발된 소프트웨어의 일부를 다시 개발하는(유지 보수 범위를 초과하는) 비용
시스템 운영 환경 구축 비용: 테스트 단계의 시험 환경 및 운영 환경을 설계, 구축하는 비용
소프트웨어 비용 산전
소프트웨어 개발에 필요한 여러 가지 프로젝트 관리 요소를 기반으로 소프트웨어 프로젝트의 규모를 파악하여 개발에 필요한 비용을 미리 산정하는 활동이다.
비용이 너무 낮으면 개발자들의 부담이 커지고 곧 품질의 저하로 이어지므로 적정선을 잘 선정해야 한다.
정해진 산출법을 통해 가발 비용을 과학적이고 합리적으로 산정해야 한다.
대표적으로 하향식, 상향식 기법으로 나뉜다.
소프트웨어 비용 결정 요소
프로젝트: 제품 복잡도, 시스템 크기, 요구 신뢰도
자원: 인적자원, 하드웨어 자원, 소프트웨어 자원
생산성: 개발자 역량(지시, 경험, 이해도), 개발 기간
하향식 비용 산정기법
과거의 유사한 개발 경험을 기반으로 비용을 산정하는 비과학적인 기법이다.
전문가 측정 기법
경험이 있는 둘 이상의 전문가들이 신속하게 비용을 산정하는 것이다.
개인적이고 주관적인 판단이 포함될 가능성이 높다.
델파이(delphi) 측정 기법
전문가 측정 기법의 단점을 보완한 기법으로 조정자(Coordinator)가 여러 전문가의 의견을 종합하여 비용을 산정한다.
이부분 많이나옴
상향식 비용 산정 기법
프로젝트의 세부적인 작업 단위별로 비용을 산정한 뒤 전체 비용을 산정하는 방식이다.
LOC(Line Of Code) 기법
각 기능의 소스 코드 라인 수의 비관치, 낙관치, 기대치를 통해 예측지를 계산하고 이를 기반으로 비용을 산정하는 기법이다.
낙곽치: 가장 적은 예측 라인수
기대치: 평균적인 예측 라인수
비관치: 가장 많은 예측 라인수
예측지 = (낙관치 + (4 * 기대치) + 비관치) / 6
LOC 기반 비용 산정 공식
노력 = 개발 기간 투입 인원 = LOC / 인당 월평균 생산 코드 라인
개발 비용 = 노력 월 평균 인건비
개발 기간 = LOC / 인당 월평균 생산 코드 라인 / 투입 인원
개발 기간 = LOC / (인당 월평균 생산 코드 라인 * 투입 인원)
생산성 = LOC / 노력
단계별 노력(Effort Per Task) 기법
단순 코드 라인 수만으로 측정하는 LOC 기법을 보완한 기법이다.
각 기능들을 구현시키는 데 필요한 노력에 가중치를 별도로 반영하여 측정한다.
수식보다는 용어 중요
수학적 산정 기법
COCOMO(COnstructive COst MOdel)
Organic(조직형): 5만 라인(50KDSI) 이하의 사무처리, 업무용, 과학용 응용 소프트웨어
Semi-Detached(반분리형): 30만 라인(300KDSI) 이하의 운영체제, DBMS, 트랜잭션 처리 시스템
Embedded(내장형): 30만 라인(300KDSI) 이상의 초대형 규모의 시스템 소프트웨어
KDSI(Kilo Delivered Source Instruction): 소스 코드를 1,000단위로 표현
Putnam
Putnam이 제안한 비용 산정 기법으로 시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력 분포도에 기반한다.
Putname 모델을 기초로한 자동화 비용 측정 도구로 SLIM(Software Life cycle Management)이 있다.
기능 점수(Function Point) 기법
알브레히트가 제안한 기법으로 소프트웨어 기능을 증대시키는 요인(비용 산정요인) 별로 가중치를 부여하여 비용을 산정한다.
기능 증대 요인: 입력, 출력, 사용자의 질의, 데이터 파일, 인터페이스
FP 모델을 기초로 한 자동화 비용 측정 도구로 ESTIMACS가 있다.
투입 인력 자원 구성
책임 프로그래머 팀 유형
중앙 집중형 팀 구성
1인 책임 프로그래머를 위해 다수 보조 역할을 담당하는 성(Star)형 구조이다.
중앙 집중형 팀 구성 특정
소규모 소프트웨어를 단기적으로 개발하는 데 적합한 구조이다.
기능 구현의 분담이 필요 없는 단순한 난이도의 프로젝트에 적합하다.
대부분의 개발 팀원들의 만족도가 낮고 이직률이 높다.
민주주의식 팀 유형
분상형 팀 구성
개개인의 담당 개발 영역이 독립적으로 존재하는 링(Ring)형 구조이다.
분산형 팀 구성의 특정
대규모 소프트웨어를 장기적으로 개발하는 데 적합한 구조이다.
기능 구현의 분담을 통해 복잡한 난이도의 프로젝트에 적합하다.
대부분의 개발 팀원들의 만족도가 높고 이직률이 낮다.
소프트웨어 품질 관리
소프트웨어 개발 표준
ISO/IEC 12207
국제표준화기구(ISO)에서 제정한 표준 소프트웨어 수명 주기 프로세스이다.
기본 생명 주기 프로세스: 회득, 공급, 개발, 운영, 유지보수
지원 생명 주기 프로세스: 문서화, 형상 관리, 문제 해결, 품질 보증, 검증, 확인, 합동 검토, 감리
조직 생명 주기 프로세스: 관리, 기반 구조, 개선, 교육 훈련
ISO/IEC 12119
패키지 소프트웨어의 제품 품질 요구사항 및 테스트를 위한 국제 표준이다.
ISO/IEC 29119
소프트웨어 테스트를 위한 국제 표준이다.
이문제 자주 나옴
ISO/IEC 9126(25010)
소프트웨어 품질 특성 및 평가에 관한 표준으로, 2011년에 호환성과 보안성을 강화하여 25010으로 개정되었다.
ISO/IEC 9126(25010) 외부 품질 특성
기능성(Functionality): 명시된 요구사항을 만족하는 기능
신뢰성(Reliability): 정의된 성능 수준을 유지하는 능력
사용성(Usability): 사용자에 의해 이해, 학습, 사용, 선호되는 능력
효율성(Efficiency): 상용되는 자원에 따라 요구 성능을 제공하는 능력
유지보수성(Maintainability): 제품이 수정, 개선, 개작될 수 있는 능력
이식성(Portability): 서로 다른 환경으로 이식될 수 있는 능력
외부 품질 내부 품질
기능성: 적합성, 상호운용성, 보안성, 정확성, 준수성
신뢰성: 고장 허용성, 회복성, 성숙도, 준수성
사용성: 학습성, 운영성, 이해도, 친밀성, 준수성
효울성: 반응 시간, 지원 특성, 준수성
유지보수성: 분석성, 변경성, 안정성, 테스트 용이성, 준수성
이식성: 적용성, 설치성, 공존성, 교체성, 준수성
이부분도 중요함
CMM(Capability Maturity Model)
소프트웨어 개발 업체들의 업무 능력 평가 기준을 세우기 위한 평가 능력 성숙도 모델이다.
CMM 단계별 프로세스 성속도(5단계)
초기(Initial): 성공한 프로젝트의 프로세스를 반복
반복(Repeatable): 성공한 프로젝트의 프로세스를 반복
정의(Defined): 프로세스의 정의와 이해 가능
관리(Managed): 프로세스에 대한 성과를 측정, 분석, 개선, 관리 가능
최적화(Optimizing): 지속적인 품질 개선 진행
CMM 프로세스 관리 품질 평가 기준(레벨1 ~ 레벌 5)
레벨1(혼돈적 관리): 순서의 일관성 부재
레벨2(경험적 관리): 경험을 통관 관리
레벨3(정성적 관리): 경험의 공유 및 공식적인 관리
레벨4(정량적 관리): 조직적, 통계적 분석을 통한 관리
레벨5(최적화 관리): 위험 예측 및 최적화 도구 활용
CMMI(Capability Maturity Model Integration)
CMM을 발전시킨 것으로서, 소프트웨어와 시스템 공학의 역량 성숙도를 평가하기 위한 국제 공인 기준이다.
CMMI의 기반 모델(3가지)
SW-CMM: S/W 개발 및 유지보수에 관련된 성숙도 모델
SE-CMM: 시스템 엔지니어링 능력 성숙도 모델
IPD-CMM: 프로젝트 간 협동/통합 프로젝트 개선 모델
CMMId 단계별 프로세스 성숙도
초기(Initial): 표준화된 프로세스 없이 프로젝트 수행결과 예측 곤란
관리(Managed): 기본적인 프로세스 구축에 의해 프로젝트 관리
정의(Defined): 세부 표준 프로세스 기반 프로젝트 통제
정량적 관리(Quantitatively Managed): 프로젝트 활동이 정량적으로 관리, 통제되고 성과 예측 가능
최적화(Optimizing): 지속적인 개선활동이 정착화되고 최적의 관리로 프로젝트 수행
SPICE(Software Process Improvement and Capability dEtermination)
소프트웨어 품질 및 생산성 향상을 소프트웨어 프로세스를 평가하는 국제 표준(ISO/IEC 15504)이다.
SPICE의 목적(3가지)
프로세스 개선을 위해 개발 기관 스스로 평가
요구 조건 만족 여부를 개발 조직 스스로 평가
계약을 위한 수탁 기관의 프로세스를 평가
SPICE의 단계별 프로세스 성숙도(6단계)
레벨0(불완전): 프로세스가 구현되지 않거나 프로세스 목적을 달성하지 못함
레벨1(수행): 행당 프로세스의 목적은 달성하지만 계혹되거나 추적되지 않음
레벨2(관리): 프로세스 수행이 계획되고 관리되어 작업 산출물이 규정된 표준과 요구에 부합
레벨3(확립): 표준 프로세스를 사용하여 계획되고 관리
레벨4(예측 가능): 표준 프로세스 능력에 대하여 정량적인 이해와 성능이 예측
레벨5(최적): 정의된 프로세스와 표준 프로세스가 지속적으로 개선
CASE(Computer Aided Software Engineering) 도구
소프트웨어 개발 프로세스의 전 과정에서 자동화를 지원하는 소프트웨어 도구 이다.
컴퓨터 지원 시스템공학 도구라고도 하며 개발자의 반복적인 작업량을 줄이는 것을 목표로 한다.
CASE의 원천 기술은 구조적 기법, 프로토타이핑, 자동 프로그래밍, 정보 저장소, 분산 처리 등이 있다.
CASE 도구 특징
소프트웨어 품질과 생산성, 신뢰성을 향상시키는데 도움을 준다.
도구의 비용은 비싸지만 개발 비용, 기간을 절감된다.
명령어, 문법의 숙지가 필요하며 CASE 도구 간 호환성이 없다.
CASE 도구 계층적 분류
상위: 요구 분석과 설계 단계 지원
하위: 코드 작성과 테스트, 문서화, 유지보수 지원
통합: 전체 과정을 지원하기 위한 도구 통합
SADT(Structured Analysis and Design Technique)
SoftTech 사이에 개발한 구조적 분석 및 설계 도구이다.
블록 다이어그램을 채택한 자동화 도구이다.
SREM(Software Requirements Engineering Methodology)
TRW 사이에 개발한 RSL과 REVS를 사용하는 요구 분석용 자동화 도구이다.
RSL(Requirement Statement Language): 요소, 속성, 관계, 구조들을 기술하는 요구사항 기술언어
REVS(Requirement Enginerring and Validation System): RSL 기술 요구사항 분석 명세서를 출력하는 분석 시스템
TAGS(Technology for Automated Generation of Systems)
시스템 공학 방법 응용에 대한 자동 접근 방법으로 개발 주기의 전 과정에 이용할 수 있는 통합 자동화 도구이다.
PSL/PSA
미시간대학에서 개발한 PSL과 PSA를 사용하는 요구 분석용 자동화 도구이다.
PSL(Problem Statement Language): 요구사항 기술언어
PSA(Problem Statement Anayzer): PSL 기술 요구사항 분석 명세서를 출력하는 분석 시스템
프로젝트 형상 관리
형상 관리
소프트웨어 개발 프로젝트의 모든 과정에서 발생하는 산출물들의 종합 및 변경과정(version)을 체계적으로 관리하고 유지하는 활동 및 기법이다.
형상 관리 프로세스
형상 식별
형상 관리 대상을 식별하여 이름 및 관리번호를 부여하는 작업이다.
수정 및 추적이 가능하도록 기준선(Baseline)을 정하는 활동이다.
중요
형상 통제
형상 항목의 변경 요구를 검토하고 승인하는 작업이다.
변경 항목을 현재의 베이스라인 성공적으로 반영하도록 제어한다.
형상 변경은 별도 조직(형상통제위원회)의 승인을 통해 이루어질 수 있어야한다.
형상 상태보고
형상 관리 작업의 결과를 기록하고 관리하는 작업이다.
베이스라인의 상태 및 형상 반영 여부를 관리한다.
형상 감사
변경될 베이스라인의 무결성을 공식 승인하기 위해 검증하는 작업이다.
마무리
처음으로 정보처리기사에대한 정리를 했는데 외워야할 부분이 정말 많은것같다. 아직 시험까지 시간이 있기때문에 천천히 외워보겠다.
