메타 스터디 그룹

[소공 목차]

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 구성요소

3. Capability Area 4개 범주

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

4. CMMi 성숙도 레벨

1) CMM2 Practice Level

2) CMMi 성숙도 수준별 PA

5. CMMi 2가지 표현 방법

6. CMMi 1.3 vs. CMMi 2.0

* 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 비교

IV.  안전성 보증 프로세스

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

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

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

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

④ 안전성 감사 활동 : Safety Gate

⑤ 안전성 지원 : Visualization

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

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

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

[소공 목차]

개념

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

ISO/IEC 25000의 등장 배경

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

SQuaRE 시리즈 표준문서

[소공 목차]

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

1) Class

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

2) Method

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

2. Class, Method 의 구현

1) 구현 코딩

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

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

  {

    .....

    return 리턴타입 값;

  }

}

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

[소공 목차]

1. 마이크로 서비스 아키텍쳐 개요

• 하나의 큰 어플리케이션을 여러 개의 작은 마이크로서비스 단위로 나누어 변경과 조합이 가능하도록 구성된 아키 텍쳐
• 소프트웨어 응용 프로그램을 독립적으로 배치 가능한 서비스 단위로 분리하고, 이들의 조합으로 시스템을 구성하는 아키텍처 스타일
• 데이터에서부터 비즈니스 로직까지 독립적으로 상호 컴포넌트간의 의존성이 없이 개발된 컴포넌트로 REST API와 같은 표준 인터페이스로 그 기능을 외부로 제공하기 위한 서비스 아키텍처
• 특징) 소규모 팀이 다룰 정도의 크기가 충분히 작아야함.
            다른 서비스와 영향을 주고 받지 않고 자율적 개발, 배포, 운영, 확장 할 수 있어야 함.          
• 필요성) 스트리밍 서비스-넷플릭스 예) 장애 발생시, 전체서비스를 다운하고 대응해야 하는 부분에서 마이크로 서비스 단위만 수정 배포를 통해 전체 사이트 장애를 막을 수 있다.            
  모놀리스 시스템의 특정 기능의 조회가 많고 요구사항에 의해 빈번한 업데이트가 필요시 전체프로그램을 업데이트 해야함(MSA는 특정 서비스만  수정, 배포가 가능함.)

2. 마이크로 서비스 아키텍쳐 구성도 및 구성 요소

1) 마이크로 서비스 아키텍쳐  구성도

2) 마이크로 서비스 아키텍쳐  구성요소

- DevOps -> 마이크로 서비스 라이프사이클의 효과적인 관리, 빠른 개발, 서비스 안정성, 유연한 확장성 

2. 마이크로 서비스 아키텍쳐와 모놀리스 아키텍쳐 비교

1) 마이크로 서비스 아키텍쳐와 모놀리스 아키텍쳐 개념도 비교

  -마이크로서비스 아키텍쳐는  서비스 단위로 분리, 모놀리스 아키텍쳐는 하나의 단일프로그램임.

2) 마이크로 서비스 아키텍쳐와 모놀리스 아키텍쳐 비교