Skip to main content

39 posts tagged with "pe/software-engineering"

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

View All Tags

성능테스트

· 3 min read

성능테스트의 개념

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

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

성능테스트 구성도

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

성능 테스트 구성요소

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

성능 테스트 주요 지표

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

동시사용자 계산

Little's Law

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

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

· 4 min read

페어 프로그래밍 개념

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

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

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

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

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

페어 프로그래밍 적용방안

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

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

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

ATAM, CBAM 비교

· 4 min read

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

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

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

ATAM, CBAM의 절차

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

ATAM, CBAM의 구성요소

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

프로젝트별 적용방안

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

UML, Unified Modeling Language

· 4 min read

UML 개념

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

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

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

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

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

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

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

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

UML 작성시 고려사항

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

MSA, 모놀리틱 아키텍처

· 3 min read

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

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

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

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

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

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

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

MSA 적용 방안

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

MSA 도입시 고려사항

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

테스트 커버리지, 코드 커버리지

· 3 min read

테스트 커버리지와 코드 커버리지의 개념

  • 테스트 커버리지: SW 테스트시 얼마나 많은 기능이 테스트되었는지를 측정하는 지표
  • 코드 커버리지: 코드의 각 구문이 테스트 중 얼마나 실행되었는지 측정하는 지표

테스트 커버리지, 코드 커버리지 구성요소, 적용방안

테스트 커버리지, 코드 커버리지 구성요소

구분커버리지비고
테스트 커버리지기능 커버리지요구사항별, 유스케이스, 시나리오
-사용자시나리오 커버리지UI, 통합, 시스템
코드 커버리지라인 커버리지코드라인, 구문, 조건
-함수 커버리지함수 호출, 함수 내부
-분기 커버리지조건, 결정, 다중 조건

테스트 커버리지, 코드 커버리지 적용방안

구분적용방안비고
테스트 커버리지테스트 계획 단계부터 목표 수립테스트 관리도구 활용
-테스트 실행시 커버리지 측정 보고서 작성-
코드 커버리지코드 커버리지 측정도구 활용적정분석도구 통합
-테스트 실행 후 커버리지 분석CI/CD 통합

커버리지 측정시 고려사항

  • 비용과 시간, 테스트 품ㅈ딜을 고려한 현실적인 커버리지 목표 설정 필요

품질비용 항목

· 4 min read

품질비용 항목의 개념

  • SW제품의 품질을 유지하고, 향상시키기 위해 설계부터 유지보수 단계까지 발생하는 모든 비용
  • SW개발 초기 단계부터 품질 비용 항목을 관리해야 후속 단계에서 결함 수정 및 유지보수 비용 절감 가능
  • 품질비용을 투자하면 원가가 줄어든다는 것은 6시그마(DMAIC)에서 증명

품질비용항목 개념도, 구성요소, 주요사례

품질비용항목 개념도

  • 예방, 평가 비용을 높혀 실패비용을 줄이는 것이 품질비용 관리의 목표

품질비용항목 구성요소

예평내외

구분내용비고
예방비용결함 예방 투입 비용교육, 훈련, 프로세스 개선
평가비용제품 품질 평가 및 검증 비용테스트, 리뷰, 감리
내부실패비용개발단계에서 발견된 결함 수정 비용재작업, 수정, 폐기
외부실패비용출시 후 결함 발생 비용고객지원, 환불, 소송

품질비용항목 주요사례

구분사례비고
예방비용프로젝트 및 자원관리품질 계획, 수립, 통제, 형상, 보안 관리
-예방품질활동프로세스 점검, 산출물 검토, 내부QA
평가비용평가품질활동장비검수, 피어리뷰, 코드리뷰
-테스트단위, 통합, 시스템, 인수
내부실패비용내부실패 관리, 품질활동추가 작업비용, 조치
-테스트 결함 조치테스트 후 결함 조치
외부실패비용결함 처리 조치이미지 손실, 고객불만 처리
-납기 지연 대응프로젝트 지연 대응, 장애 복구
  • 품질비용은 예방, 평가, 내부실패, 외부실패 순으로 사용 권장

품질비용 고려사항

  • 납기일을 준수하기 위해 테스트기간을 줄이고 있는 현황을 해결하기 위해, 프로젝트 계획 단계에서부터 품질비용을 고려한 기간산정 필요.

구조적 방법론, 애자일 방법론

· 4 min read

구조적 방법론, 애자일 방법론 개념

  • 구조적방법론: 전체 시스템을 기능에 따라 분할하여 개발하고, 이를 통합하는 프로세스 중심의 하향식 방법론
  • 애자일방법론: SW개발을 반복적이고 점진적으로 진행하고, 변경에 유연하게 대응하는 방법론

구조적 방법론, 애자일 방법론 구성요소, 주요 기법, 적용방안

구조적 방법론, 애자일 방법론 구성요소 비교

구분구조적 방법론애자일 방법론
접근방식계획중심, 단계적반복적, 유연한 방식, 짧은 개발 사이클
문서화모든 단계에서 상세한 문서화문서보다는 동작하는 SW에 가치
고객 참여프로젝트 초기에 요구사항 정의 후 참여 없음지속적인 피드백과 개선
변경관리변경에 유연하지 않음유연한 변경 수용
개발 속도긴 개발 주기빠른 개발 주기
장점명확한 구조와 규정된 프로세스를 통한 크고 복잡한 프로젝트 적합변화하는 시장 요구사항에 빠른 대응
단점유연성 부족, 계획 변경 어려움문서 부족으로 인한 리스크
주요 기법데이터 흐름 다이어그램, 분할 정복, 정형화스크럼, 칸반, TDD

애자일 방법론의 주요 기법 스크럼, 칸반 비교

구분스크럼칸반
개념고정된 역할과 이벤트를 통한 작업관리시각화를 통한 작업 흐름 관리
특징스프린트, 데일리스크럼, 회고칸반보드, 대기행렬, 총 주기 시간
장점명확한 역할분담, 짧은 주기와 반복작업유연한 작업관리, 지속적인 개선
단점초기적응 어려움역할 불명확, 관리 어려움

개발 방법론 선택시 고려사항

  • 레거시시스템 여부, 팀 성숙도 측면을 고려하여 구조적 방법론과 애자일 방법론 중 선택 필요.

차세대시스템과 오픈결함

· 4 min read

차세대 시스템 오픈관련 문제점 개요

  • 사업 사전준비 부족과 프로젝트 관리 역량 부족 등 미진한 대응으로 대국민 서비스 품질 저하 및 공공기관 신뢰성 저하

오픈 관련 문제점의 원인

기술적 원인

구분문제짐내용
데이터데이터 전환 미흡마이그레이션 후 정합성 문제
-도메인 분석 미흡시스템 통합에 딸느 영향도 파악 부족
기능기능 미구현다양한 유저의 필요 기능 불안전 구현
-개발자 역량개발자의 도메인 지식 부족
시스템테스트 부족시스템 통합 후 미구현 기능 발견
-시스템 검수 미흡성능 요구사항 미준수

관리적 원인

구분문제점내용
요구사항불명확한 요구사항일정 지연 원인
-리스크 관리 부족위험 수집, 판별, 분석, 대응 미흡
제도대기업 참여제한프로젝트 관리 경험 부족
-감리체계 미흡산출물 위주 감리로 실무 괴리
적정대가 미지급불공정한 과업 변경이해관계자 협의 없는 변경
-개발자 이탈핵심인력 중 90% 과업 진행 중 이탈

재발 방지를 위한 대책 및 법,제도 보완점

재발 방지를 위한 대책

구분대책내용
요구사항공공 PMO 활용사업의 성공적 수행을 위한 관리
-사전심사제도과제 진행 전 이슈 분석
적정대가 미지급과업심의위원회심의 의무화로 합의 진행
-RFPFP 기반한 대가 산출
데이터데이터 품질 검증마이그레이션 테스트 계획 수립
-전문가 활용업무 도메인, 데이터 전문가 활용

재발 방지를 위한 법, 제도 보완점

구분보완점내용
발주발주 시행근거 마련발주기관 지표 항목 개선
-분리분할발주 강화사업 규모 따른 관리 위험 완화
사업참여대기업 참여제한 완화프로젝트 관리 경험 증가로 안정성 증가
-컨소시엄 구성 체계 변경동일 사업 참여 컨소시엄 책임 조정
제도감리제도 강화업무 부문 감리 항목 강화
-하도급 제도 개선하도급 관리 기준 개정 효율화
-SW산업 진흥법 개선공공 SW사업 기반 제도 수정

오픈준비 점검지표

ISO 25010 기반

기능 점검지표

  • 적합성
  • 정확성
  • 상호운용성
  • 호환성

성능 점검지표

  • 사용성
  • 신뢰성
  • 유지보수성

요구사항 추출

· 3 min read

요구사항 추출의 개념

  • 시스템, 제품, 서비스를 개발하는 과정에서 이해관계자들의 원하는 바를 파악하고 명확하게 정의하는 활동
  • 프로젝트의 명확한 목표 설정, 이해관계자 만족, 리소스 절감, 리스크 관리를 위해 필요.

요구사항 추출 기법, 품질 속성, 개발 프로세스

요구사항 추출 기법

구분내용비고
인터뷰이해관계자와 직접 대화심층적 정보
설문조사설문지 통한 다수 이해관계자 요구사항 확보효율적, 정량적
브레인스토밍다수가 자유롭게 아이디어 제시창의적 아이디어
프로토타이핑시스템 초기 모델 제작, 사용자 피드백사용자 중심 요구사항
워크숍이해관계자가 모여서 토론, 협의합의 도출 효과
역공학기존 시스템 및 문서 분석숨겨진 요구사항 발견

요구사항 품질 속성

구분내용비고
원자성요구사항이 복합 목적이 아닌 단일 목적인지요구사항 충돌 방지
완전성요구사항이 정보의 모든 것을 포함하는지모든 이해관계자 요구 반영
비모호성명확하지 않거나 같은 내용을 다르게 언급했는지오해소지 제거
추적가능성요구사항을 쉽게 추적가능한 고유번호변경관리 대응
테스트가능성요구사항이 검증가능하게 기술되었는지객관적 기준

요구사항 추출 프로세스

요구사항 추출시 고려사항

  • 제한된 리소스 내에서 효율적인 개발을 위해 우선순위 설정 필요