37 posts tagged with "pe/software-engineering"

뮤테이션 테스트 개념​

• 소스 코드의 일부를 의도적으로 변경하여 테스트 케이스가 이 변경된 코드를 검출할 수 있는지 확인하는 화이트박스 테스트 기법
• 테스트 케이스 유효성 검증, 코드 품질 향상, 테스트 커버리지 보완, 버그 발견

뮤테이션 테스트 구성도, 구성요소, 적용방안​

뮤테이션 테스트 구성도​

뮤테이션 테스트 구성요소​

구분	내용	비고
원본 코드	테스트할 소스 코드	소프트웨어의 실제 기능을 수행하는 코드
뮤턴트	원본 코드를 변형하여 만든 코드	의도적으로 결함을 삽입한 코드
테스트 케이스	원본 코드와 뮤턴트를 검증하기 위한 테스트 시나리오	다양한 상황을 가정하여 작성된 테스트
킬드 뮤턴트	테스트 케이스가 검출한 뮤턴트	뮤턴트를 정확히 찾아내는 테스트 케이스
라이브 뮤턴트	테스트 케이스가 검출하지 못한 뮤턴트	테스트 케이스의 수정이 필요

뮤테이션 테스트 오퍼레이터​

구분	내용	비고
연산자 교체	코드 내의 연산자를 다른 연산자로 교체	+를 -로, >를 <로 변경
상수 값 변경	코드 내의 상수 값을 다른 값으로 변경	int x = 5;를 int x = 10;으로 변경
조건문 변경	조건문의 논리적 또는 비교 연산자를 변경	if (a > b)를 if (a < b)로 변경
논리적 연산자 변경	논리적 연산자를 다른 연산자로 교체	and를 or로 변경
제어 구조 변경	루프나 조건문 등의 제어 구조를 변경	for 루프를 while 루프로 변경
문장 삭제	코드의 특정 문장을 삭제	변수 할당 문장 또는 조건문 삭제
반환 값 변경	메서드의 반환 값을 다른 값으로 변경	return x;를 return -x;로 변경

뮤테이션 테스트시 고려사항​

• 많은 뮤턴트 생성으로 인한 높은 컴퓨팅 자원과 결과해석에 대한 인적 리소스 필요

ISO 25029 개념​

• 인공지능 SW시스템의 품질 속성 모델 표준
• 인공지능 SW는 일반적으로 불투명하고 예측이 어려움, 사용 학습 모델 구조, 학습 모델 파라미터 규모, 사용 데이터 양과 질, 학습 절차 등이 모두 품질 영향

ISO 25029 품질속성 개념도, 세부 내용​

ISO 25029 품질속성 개념도​

제강적 개투정

• ISO 25000 이하 AI 특징을 반영한 품질 속성 추가

ISO 25029 품질 속성 세부 내용​

구분	내용	비고
기능 정확성	요구되는 정확도로 올바른 출력을 생성하는지 확인	학습 모델 종류에 따라 분류, 클러스터링, 회귀 예측 평가
기능 적응성	AI시스템이 배포된 환경에 변화에 따라 행위를 맞춰 나가는 것	지속 학습, 확증 편향
제어 가능성	사용자가 원할 때 작동 중인 AI시스템에 개입 가능 여부	자율 주행
투명성	AI 시스템의 정보를 충분히 제공	해석 가능성, 설명 가능성
강건성	AI가 편향, 적대적 공격 등을 감내할 수 있는 환경 변화의 정도	운영 신뢰성
개입 가능성	쉽게 AI시스템을 운용 및 제어 가능하도록 인터페이스 설계가 되어있는지의 여부	인간중심적

ISO 25029 품질 속성 시험 기법​

구분	시험 기법	내용
기능 정확성	분류	학습 당시 없던 새로운 데이터 입력시 데이터가 어디에 속하는지 분류
-	-	Accuracy, Precision, Recall, ROC
-	회귀 분석	시계열 데이터에 대해 직선, 곡선을 추론하는 기법
-	-	평균절대오차MAE, 평균제곱오차MSE, 평균제곱근오차RMSE
-	군집화	고객 분할, 이미지 분할, 비정상적 탐지 군집화
-	-	Purity, NMI, RI
강건성	악의적 입력 생성	화이트박스기반 손실 함수 기울기 반대방향으로 노이즈를 주어 오판 유도
-	-	블랙박스기반 학습 모델을 대체품으로 만들어 악의적 입력 활용
-	분포 외 데이터 처리	학습 데이터와 동떨어진 데이터 OOD 검증
-	블랙박스 시험 기법	메타몰픽 테스트, 초기 테스트 사례와 후속 테스트 사례 입력 사이의 편차를 검증 (A/B)
-	화이트박스 시험 기법	CNN기반 커버리지, 뉴런 커버리지, 부호 변화 커버리지, 값 변화 커버리지, 부호-부호 커버리지
-	-	RNN기반 커버리지, 셀 스테이트(반대단어), 히든 스테이트(유사단어)

IEC 61508의 개념​

• 산업분야에서 전자, 전기, 프로갦 가능 전자 시스템의 기능 안전을 위한 국제 표준으로 위험 분석을 통한 SIL 설정으로 시스템 안전 기능에 대한 요구 수준 결정 표준
• 인명, 재산 손실 소화, 법적 규제 요구사항 충족, 안전 관련 설비 신뢰성 향상

IEC 61508 구성도, 주요 유형, 적용방안​

IEC 61508 구성도​

IEC 61508 주요 유형​

구분	내용	비고
하드웨어 안전 무결성	환경 요소에 의한 HW 성능 저하, 부품 제작 상의 허용 오차	평균 고장 발생률로 측정 가능
시스템 안전 무결성	안전 요구사항 명세, 설계, 구현 오류 관련 휴먼 에러	평균 고장 달성률 측정 불가

IEC 61508 안전 무결성 수준​

수준	내용	비고
SIL1	경미한 부상, 재산 피해	낮은 위험
SIL2	심각한 부상, 재산 피해	중요 위험
SIL3	사망 또는 심각한 환경 피해	높은 위험
SIL4	다수 사망, 대규모 환경 피해	매우 높은 위험

IEC 61508 고려사항​

• SW의 전체 수명주기 동안 기능, 성능 안전을 유지하기 위한 안전 유지활동 필요

CMMI의 개념​

• SW개발조직의 시스템 개발 능력과 조직 성숙도를 평가하기 위한 지속적 품질 개선모델
• CMM 모델들의 상호 중첩과 상이한 구조로 인해 모델 적용시 중복 투자 및 비용 지출되어 모델 통합

CMMI의 구성도, 구성요소, 성숙단계​

CMMI 구성도​

구분	내용
SW-CMM	SW프로세스 성숙도 측정, 개선
SA-CMM	SW획득 과정 능력 개선
SE-CMM	시스템 공학적 적용요소
P-CMM	인적자원 능력수준 향상
IPD-CMM	통합제품 개발프로세스 개선

CMMI 구성요소​

구분	내용	비고
프로세스 영역	특정 비지니스 목적을 달성하기 위해 필요한 관련 활동들의 집합	22개 영역
성숙도 레벨	조직의 프로세스 성숙도를 나타내는 5단계	초기-최적화
프로세스 수행	프로세스 영역 내에서 수행할 활동 및 방법	구체적인 실행 방법
목표	각 프로세스 영역이 달성해야하는 목표	개선 방향 제시

CMMI 성숙단계​

도정통량최

구분	단계	내용
5	최적화	지속적인 프로세스 개선
4	정량적 관리	프로세스 정량적 성과측정, 관리
3	정의	프로세스 표준 정의, 전사 사용
2	관리	프로세스 관리 프로세스 수립, 문서화
1	도입	프로세스 미정의, 예측 불가

CMMI, SPICE 비교​

구분	CMMI	SPICE
개발주체	카네기 멜론 대학교	ISO 표준
적용범위	SW, 시스템, 서비스 등	SW 및 시스템
평가방식	조직의 성숙도 수준 평가	프로세스 수행 능력 평가
평가단계	5단계	6단계
초점	프로세스 개선 및 성숙도 향상	프로세스 평가 및 개선
인증	공식 심사 통한 인증	없음

CMMI 도입시 고려사항​

• 도입 목적과 기대효과를 명확히 정의하고 조직 내 가이드하여 조직문화 조성 선행 필요

소프트웨어 품질성능평가 개념​

• 동종의 경쟁제품간 비교시험을 통해 SW 구매자의 요구사항을 만족하고 품질 및 성능이 우수한 제품을 선정하는 시험
• 공공 및 민간 부문 SW구매 결정의 신뢰성 제고, 비용절감

소프트웨어 품질성능평가 개념도, 대상​

소프트웨어 품질성능평가 개념도​

• 품질성능평가 후 SW 도입으로 안정성 증가

소프트웨어 품질성능평가 적용 및 제외대상​

적용대상	제외대상
구매금액 1억 이상 상용 소프트웨어	조달청 쇼핑몰 등록 제품
직접구매제외대상인 경우, 구매금액 2억 이상 상용 소프트웨어	정보보호제품 성능평가를 통과한 소프트웨어

소프트웨어 품질 성능 평가 절차​

소프트웨어 평가시험 대상 소프트웨어 분야​

구분	분야	내용
시스템SW	통신SW	논리적 망분리, 망연계SW
-	유틸리티SW	화상회의, OCR
-	시스템관리SW	시스템관리, NW관리, APM, AI플랫폼
-	정보보호SW	DB, 보안, 접근제어, 개인정보SW
-	미들웨어SW	WAS, WEB서버, 가상화, 검색
개발용SW	데이터관리용SW	DBMS, OLAP, 메타데이터 관리
응용SW	기업관리SW	전자문서관리(EDMS)
-	GIS SW	GIS
-	기타 응용SW	자연어처리, 분배 관리

소프트웨어 품질성능 평가시 고려사항​

• ISO 25000 시리즈를 참조하여 평가항목 선정 필요

ISO 29119 개념​

• SW개발 생명주기 전 과정에 걸쳐있는 테스팅 프로세스와 관련 산출물에 대한 표준
• 최근 GDC를 활용한 글로벌 원격지 개발로 인해, 테스트 프로세스 정의와 테스트 문서화의 중요성 대두

ISO 29119 구성요소, 프로세스, 설계기법​

ISO 29119 구성요소​

• 소프트웨어 테스팅 원리, 개요, 테스팅 프로세스, 테스팅 관련문서 템플릿, 테스팅 기법으로 구성

ISO 29119 테스팅 프로세스​

• 조직 테스트의 명세 개발 및 관리, 개별테스트 단계의 테스트 관리, 특정 테스트 단계 또는 테스트 유형 내에서 동적 테스팅을 수행 관리하는 프로세스 제공

ISO 29119 테스트 설계 기법​

명세기반 테스트 설계기법과 품질 속성​

기법	품질 속성	비고
경계값 분석	기능 적합성	완전성, 정확성, 적절성
-	성능 효율성	시간 반응성, 용량성
-	사용성	사용자 오류 방지성
-	신뢰성	결함허용성
-	보안성	기밀성, 무결성
원인결과그래프	기능적합성	완전성, 무결성, 적절성
-	사용성	사용자 오류 방지성
-	호환성	공존성
분류트리	기능적합성	완전성, 정확성, 적절성
-	사용성	사용자 오류 방지성
동등분할	기능적합성	완전성, 정확성, 적절성
-	사용성	사용자 오류 방지성
-	신뢰성	가용성

ISO 29119 관련 고려사항​

• 요구사항명세서 기반의 명세기반 테스트 계획과, 프로그램 사양서 기반의 구조기반 테스트 계획으로 소프트웨어 품질 제고

소프트웨어 안전관리 개념​

• SW자체에 내포된 위험뿐 아니라 시스템 전체에 대한 위험요인을 고려하여 사람의 신체와 재산을 보호하는 관리 방법
• 시스템 안정성, 신뢰성 보장, 오작동으로 인한 사고 예방

소프트웨어 안전진단 영역, 프레임워크, 동향​

소프트웨어 안전진단 영역​

안전 기능 충분성	SW 품질 안정성	기반 SW 안정성
시스템 잠재위험분석	주요 기능 정상동작	기반SW 지속 운영 진단
위험원 감지, 회피, 제거	안전 관련기능 정상동작	장애감지, 백업, 복구
안전기능마련 여부 진단	정적분석 통한 잠재결함 진단	성능, 다중화

소프트웨어 안전진단 프레임워크​

소프트웨어 안전 동향​

구분	동향	비고
국내	정부주도 소프트웨어 안정성 강화 정책	TTA, 국가기술 표준원 주도
-	ISO26262 적용 확대	-
국외	유럽, 미국 기능 안전 표준 강화	IEC 61508
-	자율주행차 등 신기술 적용 확대	ISO 26262

소프트웨어 안전, 보안, 품질 비교​

구분	안전	보안	품질
보호대상	사람 신체, 생명, 재산	시스템, 데이터 기밀성, 무결성, 가용성	사용자 요구사항, 성능, 스펙
주요 활동	위험 식별, 완화, 평가	접근제어, 암호화, 인증, 인가	요구사항 분석, 테스트, 검증
위험요인	안전요구사항 누락, 설계 오류, 오구현	접근제어 오류, 해킹, 제로데이공격	기능 미구현, 요구 변경
위험결과	사망, 부상, 재물 손실	정보 유출, 손실, 제어권 상실	시스템 미동작, 기능 오류, 사용자 불편
예상시스템	안전필수시스템	모든 SW	모든 SW
예시	항공관제, 열차제어, 자동차제어	IDS, IPS, DDoS 대응	DBMS, OS, 웹
표준	IEC 61508, ISO 26262	ISO 27000, ISO 15408	ISO 25000, ISO 12207

소프트웨어 안전관리 원칙 GAMAB, ALARP 비교​

구분	GAMAB	ALARP
목표	기존 시스템 이상의 안전수준 유지	합리적으로 실현 가능한 최소 위험 수준
적용범위	철도,항공 등 고안전성 산업	원자력, 화학, 섬유 등
접근방법	기존시스템과 비교 평가	비용대비 효과 분석
특징	최소 안전 수준, 지속적 개선	상위, 중간, 하위 위험도

인수테스트의 개념​

• 시스템 인수를 위해 기능, 비기능적 요구사항을 사용자가 직접 테스트하여 개발이 완료되었음을 증명하는 테스트
• 준수성 확인, 고객 피드백, 배포 가능성 평가

알파테스트, 베타테스트 개념도, 특징, 적용방안​

알파테스트, 베타테스트 개념도​

• 소규모, 한정된 개발환경에서 고객 피드백을 반영하고, 최종 사용자의 사용경험 확보와 이해 향상

알파테스트, 베타테스트 특징​

구분	알파테스트	베타테스트
환경	개발환경	사용자환경
목표	결함발견, 부하검사, 신뢰성	사용자제품평가, 공개테스트서비스
시점	서비스 개발 완성 시점	공개 서비스 발매 전 최종 심의
참가자	개발자, 테스터, 선택된 사용자	고객, 최종 사용자

알파테스트, 베사테스트 적용방안​

구분	알파테스트	베타테스트
기능적합성	요구 기능 검증, 주요 기능 확인	실제 사용자 요구 충족, 기능의 실사용 평가
효율성	코드 최적화, 성능문제 발견	실제 사용 환경 내 성능테스트, 자원 사용 검토
사용성	사용자 인터페이스 기본 검토, 개선	실제 사용자 경험 수집, 만족도 평가
호환성	다양한 내부시스템 및 환경과 호환성 테스트	다양한 사용자 환경 및 플랫폼 호환성 테스트
신뢰성	주요 결함, 버그 식별, 시스템 안정성 초기 검토	장기간 사용 안정성 평가, 시스템 실패율 검증

인수테스트 고려사항​

• 실제 사용자 환경에서 보안성 검토 필요

성능테스트의 개념​

• 시스템의 비기능 요구사항을 만족하는지 확인하기 위해 실제 환경과 비슷한 환경에서 수행하는 테스트
• 시스템 안정성 확인, 사용자 경험 개선, 비용 절감, 확장성 검증

성능테스트 구성도, 구성요소, 주요 지표​

성능테스트 구성도​

• 테스트 시나리오를 작성 후 부하생성, 모니터링 및 분석 후 시스템에 추가 반영

성능 테스트 구성요소​

구분	내용	비고
부하 생성기	시나리오를 기반으로 시스템에 부하를 발생시키는 도구	JMeter, LoadRunner
모니터링, 분석 도구	시스템 성능 지표 실시간 모니터링, 테스트 결과 분석, 성능 문제 식별	New Relic, ELK Stack

성능 테스트 주요 지표​

구분	지표	내용
테스트환경	동시사용자	성능테스트의 가상사용자 수
-	활성사용자	서버에 연결되어 요청을 처리 중인 사용자로 트랜잭션 발생 사용자
성능	응답시간	요청 후 응답이 완료되어 사용자 화면에 출력될 때까지 시간
-	대기시간	하나의 요청에 응답을 수신하고 다음 요청을 보낼 때까지의 시간
-	TPS	단위 시간 당 서버, DB에서 처리된 요청 수

TPS 계산​

Little's Law

$$CU = \lambda * W$$

• 동시사용자 = TPS * (Request Time + Think Time)
• 웹 시스템에선 동시 사용자와 활성사용자 간 차이가 있으므로 TPS 가정 하에 활성 사용자 계산

페어 프로그래밍 개념​

• XP 개발 방법론에서 개발자 고립과 낮은 생산성 문제를 해결하기 위해 페어프로그래밍 기법 등장, 애자일 방법론에서 TDD 기반의 핑퐁 프래밍 기법으로 발전.
• 오류에 빠른 대응 가능, 코드에 대한 책임 분담으로 실수 방지 가능

페어 프로그래밍, 핑퐁 프로그래밍의 개념도, 구성요소, 적용방안​

페어 프로그래밍, 핑퐁 프로그래밍의 개념도​

페어 프로그래밍, 핑퐁 프로그래밍 구성요소 비교​

구분	페어 프로그래밍	핑퐁 프로그래밍
개념	두 개발자가 한 컴퓨터에서 개발하는 프로그래밍 방식	두 개발자가 번갈아가며 테스트와 코드 작성
역할	드라이버, 네비게이터	테스트 작성자, 코드 작성자
특징	코드 품질 향상, 코드 리뷰	TDD 촉진
장점	오류 감소, 지식 공유, 생산성 향상	테스트와 코드 작성의 연계
단점	의사소통 비용 발생	잦은 인터럽트 발생

페어 프로그래밍 적용방안​

구분	방안	비고
숙련도가 다른 개발자	시니어-주니어 페어로 네비게이터-드라이버 역할 수행	주니어의 빠른 성장 기대
신기술 학습	새로운 기술 적용시 여러 관점 고려 가능	학습효과 극대화
문제 해결	다양한 접근 방식으로 빠른 이슈 해결	역할 교체

페어 프로그래밍시 고려사항​

• 서로 신뢰하고 존중하는 분위기가 선행되어야 페어 프로그래밍시 커뮤니케이션 비용 대비 생산성 효과 극대화