[데이터베이스 목차]

 

 

 

 
회복기법
동작 방식
상세 설명
즉시갱신
기법
- 트랜잭션 갱신
  Log, DB 반영
- 장애시 Log
 파일 참조 
- 트랜잭션완료시 REDO, 트랜잭션 미완료시 UNDO 연산
지연갱신
기법
- 트랜잭션 갱신
  Log 반영(DB
  종료후 반영)
- 장애시 Log
-트랜잭션 완료시 REDO, 트랜잭션 미완료시 로그 폐기
- UNDO 불필요
체크
포인트
- 로그기반 기법은 전체 로그 대상으로 REDO 수행하기때문에 비효율발생하여 검사시점을 세분화할 필요성제기
- 검사점 기준
로그 파일 기록
- UNDO(미종료)
- REDO(종료)
- UNDO 실행
 후 REDO
그림자
페이지
- 트랜잭션 시작
 전 그림자 페이지 테이블 생성
- 트랜잭션 종료후 저장 및 장애시 페이지 복구
AREIS
- WAL(Write-Ahead Logging) 및 LSN(Log Sequence Number) 이용하는 회복 기법
 

 

[소공 목차]

 

 

1. CMMi(Capability Maturity Model Integration) 개요

  • 개발에 대한 조직의 능력 및 성숙도에 대한 평가와 프로세스 개선 활동에 광범위한 적용성을 제공하는 지속적인 품질 개선 평가 모델(산업계 표준, De-facto Standard)
  • SEI에서 만든 조직 성숙도 평가 모델로, 기존에 여러개로 나누어진 CMM을 통합한 모델(v1.0~2.0)

등장배경

  • CMM 모델간 상호 중첩과 구조의 상이함으로 인해 현장에 적용하기 어려움
  • 각각의 모델 적용에 따른 중복 투자로 비용의 과다 지출 등의 문제점 발생
  • ISO/IEC에서  CMM이 아닌 유럽의 SPICE를  국제 표준으로 제정함에 따라 이에 대응

 

2. CMMi 구성도 및 구성요소

1) CMMi 구성도

2) CMMI 구성요소

구성요소 세부항목 설명
Model Views 최종 사용자에게 선택되고 중요하다고 여겨지는 구성요소의 집합
Categories for Capability Area 솔루션을 생성하거나 비즈니스가 직면한 보편적 문제를 다루는 논리적 그룹
Capability Areas(CA) 해당 Practice Area에 설명된 의도, 가치를 달성할 수 있는 유사성 묶음
Practice Area(PA) Required/Explanatory PA Information Practice Group 정의된 목적 및 가치를 달성하기 위해 필요한 주요 활동을 설명하는 일련의 Practice들의 집합
Practice Group(PG) Level1, Level2, ... Practice Area 내에서 레벨 1, 2 등으로 표시된 일련의 진화적 수준으로 구성되어 성과 향상을 위한 경로 제공
Practices 수행목표, 설명, 가치 사례 목표 충족을 위한 구체적인 활동

 

3. Capability Area 4개 범주

Capability Category
(Model)
설명 Capability Area Practice Area
(Level, Practices)
Doing 품질 솔루션 생산 및 제공 ·  Ensuring Quality
·  Engineering and Developing Product
·  Delivering and Managing Services
·  Delivering and Managing Supplier
7
Managing 솔루션 이행을 계획하고 관리 ·  Planning and Managing Work
·  Managing Business Resilience
·  Managing the Workforce
5
Enabling 솔루션 이행 및 제공을 지원 ·  Supporting Implementation
·  Safety
·  Security
3
Improving 성과 향상과 유지 ·  Improving Performance
·  Building and Sustaining Capability
5

·         Capability Area 하위에 20개의 PA 할당

 

4. CMMi 성숙도 레벨

1) CMM2 Practice Level

Level Practice Performance Objective
Level 5 Optimizing (최적화) 성과 최적화
Level 4 Quantitatively Managed (정량적관리) 성과 예측 및 개선
Level 3 Defined (정의) 조직 성과 초점
Level 2 Managed (관리) 프로젝트 성과 초점
Level 1 Initial (초기화) 성과 이슈 집중
Level 0 Incomplete 성과 미고려

2) CMMi 성숙도 수준별 PA

5. CMMi 2가지 표현 방법

구분 Continuous Staged
설명 조직의 비즈니스 목적 충족을 위한 개선 사항 제시
Capability Level을 이용 하여 프로세스 영역(PA) 별로 성숙도 평가 가능
수준별 프로세스를 제시
조직 간 비교를 가능하게 하는 단일한 등급 체계 제공
특징 능력 수준을 프로세스에 적용
프로세스 영역의 능력수준을 결정하므로 프로세스 개선에 유연한 접근 방식
선 순위 기준 능력수준 개선 가능
성숙도 수준으로 조직간 비교 모델단일 등급체계 평가 결과이므로 이해하기 쉬운 프로세스 개선 결과 제시
입증 순서로 개선 활동 제공
레벨구분 Capability Level Maturity Level
성숙도 0 ~ 5 단계 ( 6단계) 1 ~ 5 단계 ( 5단계)
예제 SE-CMM(연속적 표현) SW-CMM(단계적 표현)

 

6. CMMi 1.3 vs. CMMi 2.0

구분 CMMi v1.3 CMMi v2.0
구조 ·   Specific Goal
·   Generic Goal
·             Practice Group
·             Practices
PA 구성 ·   22 Process Area ·             20 Practice Area
유지 심사 ·   없음 ·             2년에 1번
모델 ·   CMMi-DEV
·   CMMi-SVC
·   CMMi-ACQ
·             CMMI-DEV (Development)
·             CMMI-SVC (Service)
·             CMMI-SPM (Supplier Mgmt)
·             CMMI-PPL (People)
·             Core Practice Area
신규 개념 ·         4 Capability Category, 12 Capability Area로 PA 그룹화

* IT위키 인용

[소공 목차]

 

 

I. 시스템 신뢰성 향상을 위한 소프트웨어 안전성 개요

-. 소프트웨어의 동작으로 인한 위협(Threat)이나 피해(Hazard)가 야기되지 않는 속성

-. 목적: 시스템 신뢰성 향상, 시스템 실패 방지, 위험도 분석

 

 

 

 

II. 소프트웨어 안전성 분석 방식 및 기법

가. 소프트웨어 안전성 분석 방식

 

나. 소프트웨어 안전성 분석 기법

 

기법 개념도 설명
FTA
  • 결함 위험 분석(Fault Tree Analysis)
  • 트리를 이용하여 위험 요소들의 원인을 찾고 목록화하여 분석
  • 전형적인 연역적 분석 기법
  • 최상위 사상(Top Event)으로부터 최상위 사상을 일으키는 사건(Event)를 여러 논리 게이트를 이용하여 연결
  • Top-down 방식
FMEA
  • 결함유형과 영향분석(Failure Mode and Effect Analysis)
  • 시스템을 구성하는 한 요소의 고장이 시스템 전체에 미치는 영향을 해석
  • 대표적 정성적 분석 기법
  • 설계된 제품에서 발생할 수 있는 가능한 고장 모드 및 원인을 부품수준에서 파악하고 원인 도출에 유용
  • Bottom-up 방식의 귀납적 방법
HAZOP
  • Hazard and Operability Study
  • 요구사항 중심의 분석 기법
  • 결함 상황을 미리 예측하여 발생 원인과 시나리오 분석 수행
  • 사고가 발생하기 전에 대책을 미리 수립하는 분석 기법
  • brainstroming 등을 통한 자유로운 발생을 유도
  • 다양한 기술적 배경의 전문가 참여

 

 

III. 소프트웨어 안전성 관련 표준

가. 소프트웨어 안전성 관련 표준 분류

 

 

나. IEC 61508, ISO 26262 비교

표준 번호 IEC 61508 ISO 26262
표준명 산업 전기 전자·장치 기능 안전 자동차 시스템 기능 안전
표준 구성 Part.1 ~ Part.7 Part1 ~ Part.10
안전성 등급 SIL 1~4등급 ASIL A~D등급
산업 특성 Project. 장치 산업 위주 대량 생산, 이동하는 차량
사용자 일반적으로 훈련된 인원 불특정 다수의 운전 면허 소지자
운영 조건 지정되어 있음 주행도로가 불특정
환경 조건 지역에 맞는 환경 조건 분석이 가능 환경조건이 불특정
유지 보수 예방, 예측 보전 실시 사용자의 판단에 따라 정비·보전
내구 수명 정해져 있다 정해져 있지 않음

 

IV.  안전성 보증 프로세스

  • SW 안전성 보증 프로세스는 SW 개발시 안전성 분석, 개발 프로세스, Verification, 시각화 절차를 기준으로 SW 안전성을 보증하는 프로세스

① 안전성 분석 : 목표식별, 위험분석

② 안전성 보증 개발 : 시스템 수준, 하드웨어 수준, 소프트웨어 수준, 표준 적용

③ 안전성 Verification : 안전성 테스팅

④ 안전성 감사 활동 : Safety Gate

⑤ 안전성 지원 : Visualization

 

V. SW 수명주기에 따른 안전성 관리방안

 

  • IT와 산업 간의 융합이 가속화 됨에 따라 국민의 안전 및 생명과 직결
  • 안전성 관리표준 : ISO 26262, ISO 61508
  • 안전성 분석기법 : FTA, FMEA, HAZOP, PHA

 

VI. 소프트웨어 안전 VS  소프트웨어 보안

구분 소프트웨어 안전 소프트웨어 보안
목적 소프트웨어 오류로 인한 수용불가능한 위험을 제거 외부로부터의 보안위협에 대응하기 위한 취약점 제거
범위 기능 단위의 국소적 범위 시스템 단위
요구분석 기능 요구 안전 분석 SDLC 보안 요구 분석
분석기법 정형기법(FTA, FMEA, HAZOP) 정성적 분석, 정량적 분석
표준 ISO 61508(기능), ISO 26262(자동차),
ISO62278(철도), ISO61513(원자력),
ISO60601(의료기기), IEC 61511(프로세스산업)
OWASP Top 10, 시큐어 코딩 가이드라인, CWE
영향 사람의 생명이나 신체에 직접적 영향 시스템 기능 마비, 시스템 침해를 통한 금전요구, 정보유출
평가수준 ASIL, SIL EAL

[소공 목차]

 

개념

  • 소프트웨어 개발 공정 각 단계에서 산출되는 제품이 사용자 요구를 만족하는지 검증하기 위해 품질측정과 평가를 위한 모델, 측정기법, 평가방안을 통합한 국제표준
  • SQuaRE, Software Product Quality Requirement and Evaluation

ISO/IEC 25000의 등장 배경

  •  SW 제품 품질 모델(ISO 9126), SW 제품 품질 평가 지침(ISO 14598), SW 패키지 제품품질 및 시험(ISO 12119)를 하나로 통일하고자 함
  •  품질요구 명세부터 품질 판정까지 일관된 표준 지침서 필요


SQuaRE 시리즈 표준문서

구성항목 문서 내용
품질 관리 부분
(ISO/IEC 2500n)
SQuaRE안내서
(25000)
SQuaRE구조 모델, 용어,문서개요, 대상 사용자 및 연관된 시리즈 및 참조 모델 제공
계획 및 관리
(25001)
소프트웨어 제품 요구사항 명세 및 평가 관리를 담당하는 기능을 지원하는데 필요 사항 및 평가 제공
품질 모델 부분
(ISO/IEC 2501n)
품질모델
(25010)
소프트웨어 제품의 내/외부 품질 및 사용 품질에 대한 모델을 설명. 주특성과 부특성, 사용품질의 특성 제시
품질 측정 부분
(ISO/IEC 2502n)
측정 참조모델 및 지침
(25020)
개요 설명과 함께 품질 측정 요소, 품질 측정에 공통적으로 적용되는 참조 모델 제시
사용자가 국제표준에 따라 측정을 선정 또는 개발, 적용하기 위한 지침 제시 
품질측정요소
(25021)
소프트웨어 개발 생명주기에서 사용할 목적으로 추천된 기본 및 유도된 측정 집합에 대한 정의와 명세
내부품질측정
(25022)
내부 소프트웨어 품질 특성 및 부특성 관점에서 정량적 측정을 위한 내부 측정들을 정의
외부품질측정
(25023)
외부 소프트웨어 품질 특성 및 부특성 관점에서 정량적 측정을 위한 외부 측정들을 정의
사용품질측정
(25025)
사용 품질을 측정하기 위한 일련의 측정들을 설명하고 사용 품질 측정을 사용하기 위한 지침 제공
품질 요구사항 부분
(ISO/IEC 2503n)
품질요구사항
(25030)
품질 요구사항 명세에 필요한 사항 및 지침과 함께 품질 요구사항 개발을 위한 프로세스에 대한 요구사항과 지침을 제공
품질 평가 부분
(ISO/IEC 2504n)
평가 참조모델 
및 지침
(25040)
소프트웨어 품질 명세 및 평가를 위한 일반적인 요구사항을 포함하고 품질을 평가하기 위한 프레임워크 제시
제품 측정 및 평가 기법에 대한 요구사항 제시
평가모듈
(25041)
평가 모듈을 기술하는데 사용될 문서화의 구조 및 내용 정의
개발자용 평가 프로세스
(25042)
소프트웨어 제품 평가가 개발과 병행하여 이루어질 경우에 그 평가가 실제적인 구현을 위한 요구사항 및 권고 사항 제공
구매자용 평가 프로세스
(25043)
상업용 패키지 소프트웨어 제품, 맞춤형 소프트웨어 제품의 구매, 기존 소프트웨어 제품의 변경 과정에서 품질을 체계적으로 측정, 판정 및 평가하기 위한 요구사항, 권고사항 및 지침을 포함
평가자용 평가 프로세스
(25044)
여러 부서에서 평가 결과를 이해하고 받아들이며 신뢰할 필요가 있는 경우에 소프트웨어 제품 평가의 실제적인 구현을 위한 요구사항 및 권고 사항 제공
SQuaRE확장부분
(25050 ~ 25099)
상업용 패키지 요구사항/테스트 지시사항
(25051)
COTS 제품에 대한 품질 요구사항, 제품 테스팅과 관련하여 테스트 요구사항, 테스트 케이스 및 테스트 결과서 작성 등 테스트 문서화에 대한 요구사항, COTS 소프트웨어 제품의 적합성 평가를 위한 지시사항 등을 설정
사용성 테스트 결과서를 위한 공통 포맷
(25062)
특정한 사용 상황에서 사용성 테스트 결과를 보고하는 방법을 명시

[소공 목차]

 

1. 객체지향 프로그래밍 언어의 Class와 Method

1) Class

 - 현실 세계의 객체(entity)를 속성과 메소드로 구성된 객체(Object)로 생성하기 위한 형식, 구조

2) Method

 - Class로 만들어진 객체의 동작 기능

 

2. Class, Method 의 구현

1) 구현 코딩

[접근제한자] [제한자] class 클레스명{

  [접근제한자] [제한자] 리턴타입 메소드명 ( [인자] )

  {

    .....

    return 리턴타입 값;

  }

}

2) 접근 제한자 및 제한자 종류

항목 종류 설명
접근 제한자 public - 외부에서 접근 가능 (클래스 외부, 패키지 외부)
protected - (클래스) 동일 패키지 접근 가능
- (메소드) 상속관계 클래스 접근
 private - 외부 접근 불가 (class는 private 사용 안함)
제한자 static - 객체(Object) 생성 없이 사용가능
- 프로그램내에 유일
abstract - (클래스) 단독 객체생성 불가, 상속하여 사용 가능
- (메소드) 단독 실행 불가, 오버라이딩하여 사용 가능
final - (클래스) 상속 불가, 자식 클래스 생성 불가
- (메소드) 오버라이딩 불가

 

+ Recent posts