본문으로 건너뛰기

"pe/software-engineering" 태그로 연결된 55개 게시물개의 게시물이 있습니다.

기술사 소프트웨어공학 토픽

모든 태그 보기

ISO 29119

· 약 5분

ISO 29119 개념

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

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

ISO 29119 구성요소

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

ISO 29119 테스팅 프로세스

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

ISO 29119 테스트 설계 기법

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

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

ISO 29119 관련 고려사항

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

소프트웨어 안전관리

· 약 4분

소프트웨어 안전관리 개념

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

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

소프트웨어 안전진단 영역

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

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

소프트웨어 안전 동향

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

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

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

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

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

인수테스트, 알파테스트, 베타테스트

· 약 4분

인수테스트의 개념

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

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

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

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

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

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

알파테스트, 베타테스트 적용방안

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

인수테스트 고려사항

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

성능테스트

· 약 3분

성능테스트의 개념

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

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

성능테스트 구성도

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

성능 테스트 구성요소

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

성능 테스트 주요 지표

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

동시사용자 계산

Little's Law

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

페어 프로그래밍, 핑퐁 프로그래밍

· 약 4분

페어 프로그래밍 개념

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

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

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

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

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

페어 프로그래밍 적용방안

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

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

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

ATAM, CBAM 비교

· 약 4분

SW아키텍처 평가모델의 개요

  • 시나리오 기반에서 품질속성을 평가하여 아키텍처 내부 리스크를 파악하고, 설계타협점을 찾는 ATAM 기법, 경제성까지 고려한 CBAM 평가기법으로 진화

ATAM, CBAM의 절차, 구성요소, 적용방안

ATAM, CBAM의 절차

  • 리스크를 고려한 설게 타협안 선택, 비용대비 편익이 높은 효율안 선택.

ATAM, CBAM의 구성요소

구분ATAMCBAM
초점아키텍처 품질비용, 이해관계자 이익
시점프로젝트 초기ATAM 수행 이후
평가요소품질속성, 시나리오비용, 편익, ROI
장점기존시스템 분석 용이비용, 일정, 경제성 파악
단점경제성 평가 미흡품질속성 평가 미흡

프로젝트별 적용방안

구분ATAMCBAM
대규모 시스템복잡한 아키텍처 품질속성 및 트레이드 오프 분석에 효과적높은 개발비용 예상시 투자 효율성 분석 용이
고가용성 시스템성능, 보안 등 핵심 품질 속성 확보 용이품질속성 확보를 위한 비용 효율적 아키텍처 수립
예산 제약 시스템제한된 예산 내에서 최적의 아키텍처 설계제한된 예산 내에서 최대 효과의 아키텍처 설계
  • 상호보완적인 관계로 ATAM과 CBAM을 함께 사용하여, 아키텍처 설계의 기술적, 경제적 측면을 고려한 최적의 의사결정 필요

스프링 부트

· 약 3분

스프링부트의 개념

  • 스프링 프레임워크를 기반으로 하여 쉽게 독립 실행형 어플리케이션을 만들 수 있도록 도와주는 오픈소스 프레임워크
  • 스프링 프레임워크의 복잡한 설정과 구성 문제를 해결하기 위해 등장

스프링부트의 구성도, 구성요소, 비교

스프링부트의 구성도

스프링부트의 구성요소

구분내용비고
내장톰캣서버스프링부트 자체 웹서버독립 실행 가능
컨트롤러사용자 요청 처리, 비지니스 로직 응답 반환RestController 등
서비스레이어비지니스 로직을 처리하는 계층DB연동, 트랜잭션 관리
레파지토리DB 접근하여 CRUD 작업 수행JpaRepository 등
모델데이터 구조를 정의하는 클래스Entity, DTO
  • Spring Starter, Auto Configurator 등 스프링부트 모듈을 활용하여 쉽게 기본 구성 사용 가능

스프링 프레임워크와 스프링부트 비교

구분스프링 프레임워크스프링 부트
설정방식수동설정, XML, Properties 등최소설정, 자동설정
의존성 관리직접 의존성 명시, 관리스타터를 통한 의존성 그룹화, 자동 관리
내장서버없음있음
목적엔터프라이즈 앱 개발 등REST API 개발 등

스프링부트 사용시 고려사항

  • 많은 어노테이션과 추상화된 설정과 라이브러리를 사용해야하므로, 개발자 숙련도를 고려하여 기능 선택 필요

노코드

· 약 2분

노코드 개념

  • 프로그래밍 지식 없이 UI와 드래그 앤 드랍 기능 등을 활용하여 SW를 개발할 수 있도록하는 플랫폼 또는 도구
  • 개발 속도 향상으로 인한 비용절감과 비전문가도 어플리케이션을 개발할 수 있는 접근성 향상

노코드 구성도, 구성요소, 적용방안

노코드 구성도

노코드 구성요소

구분내용비고
사용자 인터페이스시각적으로 어플리케이션 또는 워크플로우 조작드래그 앤 드랍
모듈사전 구성된 기능 모듈재사용 가능
버전관리다중 사용자 환경 구축문서 버저닝
데이터 모델 통합기능과 비지니스 로직, 데이터 모델 통합API, 데이터 제어

노코드 적용방안

구분내용비고
공공코딩 없는 SW 개발 교육생산성 향상
금융데이터 분석 도구 시각화대쉬보드 사용성
민간빠른 프로토타이핑, 시장 출시효율성, 비용절감

노코드 사용시 고려사항

  • 커스터마이징이 필요한 경우, Low-code 플랫폼이나 Pro-code 방식으로 어플리케이션 구현 필요.

UML, Unified Modeling Language

· 약 4분

UML 개념

  • SW산출물을 가시화, 명세화, 구축, 문서화하는 도구로 구조, 동작, 인터랙션 다이어그램으로 구분

시퀀스 다이어그램, 커뮤니케이션 다이어그램 구성도, 구성요소, 절차

시퀀스 다이어그램, 커뮤니케이션 다이어그램 구성도 비교

  • 시퀀스 다이어그램은 시간 순서에 따라, 커뮤니케이션 다이어그램은 구조에 따라 인터렉션 표현

시퀀스 다이어그램, 커뮤니케이션 다이어그램 구성요소 비교

구분시퀀스커뮤니케이션
개념객체 간 상호작용을 시간 흐름에 따라 메세지 표현객체 간 메세지의 구조적 구성 표현
핵심요소라이프라인, 액티베이션박스, 메세지객체, 링크, 메세지
사례시스템 내부 프로세스, 실행 순서시스템 아키텍처 개념적 이해

시퀀스 다이어그램, 커뮤니케이션 다이어그램 절차 비교

구분절차비고
시퀀스 다이어그램액터와 활성 객체 나열시간순서 배치
객체 간 메세지 작성상호 작용 추가
활성객체별 액티베이션박스 작성활성화 시간 표현
커뮤니케이션 다이어그램중요 객체, 클래스, 액터 식별구조적 중요성 강조
객체 및 액터 배치, 연결커뮤니케이션 구조 중심
메세지 링크 강조연결성 명확화

UML 작성시 고려사항

  • OMG 글부 표준을 준수하여 정확성, 효용성, 유지보수성을 가진 산출물 작성

MSA, 모놀리틱 아키텍처

· 약 3분

MSA, 모놀리틱 아키텍처 개념

  • 모놀리틱 아키텍처에서 비지니스 프로세스를 독립된 서비스로 분리한 SOA로 전환, SOA의 ESB 부하집중, 기술스택 일원화 문제를 해결하기 위해 MSA 등장

MSA, 모놀리틱 아키텍처 구성도, 구성요소, 적용방안

MSA, 모놀리틱 아키텍처 구성도

  • 하나의 어플리케이션을 여러 개의 서비스로 나눠 조합하여 서비스를 제공

MSA, 모놀리틱 아키텍처 구성요소

구분모놀리틱MSA
모듈성영향도, 의존성 높음서비스 간 의존성 낮음
유지보수성규모가 커질수록 어려움개별 서비스
확장성부분 Scale-out 어려움서비스 단위 유연한 Scale-out
조직기능 중심 조직 구조비지니스 중심 DevOps 구조
장점배포, 테스트 표준화된 방식으로 관리 용이서비스 단위 빠른 개발, 배포 용이
단점One Codebase로 의존성이 높아 신규 개발 어려움분산시스템에서 트랜잭션 관리 어려움

MSA 적용 방안

  • Istio 등 서비스 메쉬를 도입하여 MSA 간 서비스 디스커버리, 라우팅, 보안, 로드밸런싱 등 처리

MSA 도입시 고려사항

  • MSA 전환시 네트워크 지연시간이 추가되므로 성능에 민감한 시스템일 경우 도입을 신중히 검토해야함