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

인수테스트의 개념​

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

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

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

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

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

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

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

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

인수테스트 고려사항​

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

성능테스트의 개념​

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

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

성능테스트 구성도​

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

성능 테스트 구성요소​

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

성능 테스트 주요 지표​

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

동시사용자 계산​

Little's Law

$$CU = \lambda * W$$

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

페어 프로그래밍 개념​

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

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

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

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

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

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

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

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

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

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

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

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

ATAM, CBAM의 절차​

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

ATAM, CBAM의 구성요소​

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

프로젝트별 적용방안​

구분	ATAM	CBAM
대규모 시스템	복잡한 아키텍처 품질속성 및 트레이드 오프 분석에 효과적	높은 개발비용 예상시 투자 효율성 분석 용이
고가용성 시스템	성능, 보안 등 핵심 품질 속성 확보 용이	품질속성 확보를 위한 비용 효율적 아키텍처 수립
예산 제약 시스템	제한된 예산 내에서 최적의 아키텍처 설계	제한된 예산 내에서 최대 효과의 아키텍처 설계

• 상호보완적인 관계로 ATAM과 CBAM을 함께 사용하여, 아키텍처 설계의 기술적, 경제적 측면을 고려한 최적의 의사결정 필요

UML 개념​

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

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

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

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

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

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

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

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

UML 작성시 고려사항​

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

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

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

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

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

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

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

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

MSA 적용 방안​

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

MSA 도입시 고려사항​

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

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

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

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

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

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

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

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

커버리지 측정시 고려사항​

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

품질비용 항목의 개념​

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

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

품질비용항목 개념도​

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

품질비용항목 구성요소​

예평내외

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

품질비용항목 주요사례​

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

• 품질비용은 예방, 평가, 내부실패, 외부실패 순으로 사용 권장

품질비용 고려사항​

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

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

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

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

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

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

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

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

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

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

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

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

오픈 관련 문제점의 원인​

기술적 원인​

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

관리적 원인​

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

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

재발 방지를 위한 대책​

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

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

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

오픈준비 점검지표​

ISO 25010 기반

기능 점검지표​

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

성능 점검지표​

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