55 posts tagged with "pe/software-engineering"

ISO 12207 개요​

ISO 12207 개념​

• 소프트웨어 생명주기 프로세스를 위한 국제표준으로, SW개발 및 유지보수를 관리하는 구조화된 프레임워크 제공

ISO 12207 필요성​

• 조직이 SW를 효율적으로 개발하고 품질 표준을 충족하도록 하여 리스크를 줄이고 프로세스를 개선하는데에 필요

ISO 12207 구성도, 구성요소, 적용방안​

ISO 12207 구성도​

ISO 12207 구성요소​

ISO 12207 적용방안​

ISO 12207 고려사항​

• 조직 내 새로운 프로세스 도입에 대한 구성원들의 저항을 최소화하고, 적극적인 참여를 유도하기 위한 변화 관리 전략 필요

특징​

• 복잡성: Complexity
• 순응성: Conformity
• 변경성: Changeability
• 비가시성: Invisibility

종류​

• 주문형: 고객, 기업의 요구사항 만족
• 패키지형
• 임베디드형

위기​

• 요구 증가, 복잡도 증가, 난이도 증가

목표​

• 최소 비용
• 최고 효율

단계​

• 요구 분석
• 설계
• 개발
• 테스트
• 유지보수

품질 보증​

ISO 25010, 기신사효유이호보

• 기능적절성: Functional suitability
• 신뢰성: Reliability
• 사용성: Usability
• 효율성: Performance efficiency
• 유지보수성: Usability
• 이식성: Portability
• 호환성: Compatibility
• 보안성: Maintainability

프로젝트 관리​

• 계획
• 자원 관리
• 리스크 관리
• 프로젝트 수행 및 모니터링

연구 결과​

• 방법: Method
• 도구: Tool
• 프로세스: Process
• 패러다임: Paradigm

연관 분야​

ISO 24773, SWEBOK

vs 컴퓨터 과학​

소프트웨어 프로세스​

좋은 프로세스​

• 예측 가능성: Predictability
• 테스팅과 유지보수 용이성: Testability, Maintainability
• 변경 용이성: Changeability
• 결함 제거 용이성: Fault Tolerance

프로세스 모델​

폭포수모델​

V모델​

프로토타이핑 모델​

나선형모델​

• 프로토타입핑 반복

진화적 모델​

• 점증적: incremental
• 반복적: iterative

Unified Process​

• 여러 사이클: iteration
• 도입(inception) -> 정련(elaboration) -> 구축(construction) -> 전환(transition) 반복

애자일 프로세스​

• 2~6주간의 짧은 주기
• 익스트림 프로그래밍: XP, 사용자 스토리, 매일 빌드/통합, TDD, 페어프로그래밍
• 스크럼: 프로덕트 백로그 -> 스프린트 백로그 -> 2-4주기 개발, 스크럼미팅 -> 배포 가능 프로덕트 추가

지원 프로세스​

ISO 12207, SDLC

• 계약: 획득, 공급 프로세스
• 운영: 운영 프로세스
• 지원: 문서화, 형상관리, 품질 보증, 문제 해결 프로세스
• 관리: 관리, 개선 프로세스
• 엔지니어링: 개발, 유지보수 프로세스

관리 프로세스​

• 계획
• 모니터링
• 제어, 분석

품질보증 프로세스​

• 인스펙션 프로세스: 전문 인력, 고비용, 해결방법보다 이슈집중
• 프로세스 관리 프로세스: CMMI

형상 관리 프로세스​

• 원시코드, 목적코드, 스크리븥, 관련 문서 전체 형상 관리

구조적 방법론​

• 분할정복
• DFD: 배경도

정보공학 방법론​

• 기업중심
• 전략적 시스템 계획중심
• 데이터 중심
• 분할 정복
• 공학적 접근
• 사용자의 적극 참여

객체지향 방법론​

• 실세계를 객체로보고 객체사이 인터랙션을 모델링하는 방법
• 대규모 시스템을 클래스로 모듈화하고 캡슐화
• OMT: Object Modeling Technique, Booch, Usecase -> UML: Unified Modeling Language, UP: Unified Process

프로젝트 계획​

• 목표설정
• 프로젝트 범위 설정
• WBS작성
• 작업별 소요시간 및 노력 예측
• 작업 의존관계 정의
• 자원 할당
• 마일스톤 설정
• 일정 개발

CPM 네트워크​

• Critical Path Method
• Critical Path: 가장 오래 걸리는 경로

비용 예측 기법​

• 전문가 판단
• PERT: Program Evaluation and Review Technique, 낙관적, 보통, 비관적
• 알고리즘식 방법: 코코모, FB

COCOMO​

• Constructive Cost Model
• LOC등 단계에 따라 값 예측하고 노력 추정

기능점수​

• Function Point
• 입력(트랜잭션), 출력(화면 및 출력양식), 질의, 파일, 응용 인터페이스

소프트웨어 대가 산정 가이드​

• 외부 입력: External Input, 내부 파일의 내용에 영향을 주는 사용자데이터 또는 입력을 트랜잭션 단위로 카운터 (입력, 수정, 삭제)
• 외부 출력: External Output, 소프트웨어 외부로 표출되는 사용자 데이터 또는 제어 출력을 트랜젝션 단위로 카운트 (계싼, 통계 그래프 등)
• 내부 논리 파일: Internal Logical File, 소프트웨어에 의해 생성, 사용, 관리되는 파일을 포함하여 시스템 내 존재하는 사용자 데이터 및 제어 정보의 그룹 카운트
• 외부 인터페이스 파일: External Interface File, 소프트웨어 시스템 사이에 전다로디거나 공유된 파일 카운트
• 외부 조회: External Query, 중간 출력을 생성하는 외부 조회를 카운트

프로젝트 모니터링​

• 어닝 밸류 분석: Earning Value Analysis, 비용과 일정 통합 모니터링
• BAC: 프로젝트 예산
• AC: 실제 비용
• PV: 계획된 비용
• EV: 어닝 밸류
• PV - EV: 일정 차이
• AC - EV: 비용 차이

리스크 관리​

• 6M: Machine, Method, Materials, Measurement, Man, Mother nature, 기계, 방법, 재료, 측정, 사람, 환경
• 8P: Price, Promotion, People, Process, Place/Plant, Policy, Procedure, Product, 가격, 광고, 인력, 프로세스, 장소, 정책, 절차, 제품
• SW프로젝트(Boehm): 인력부족, 비현실적 일정 및 예산, 잘못된 기능과 특징 개발, 잘못된 인터페이스 개발, 과포장, 계속적 요구변경, 외부 노출 컴포넌트 빈약, 실시건 성능 빈약, 녹슨 컴퓨터 분야 기술

요구​

• 시스템에 대한 고객의 요청을 확정한 것

기능 요구​

기능, 데이터, 입출력, 사용자

• 시스템과 외부 요소들 간의 인터렉션
• 입력 검증
• 정확한 작업 순서
• 비정상적 상태에 대한 응답 및 복구
• 매개변수 유효성
• 입출력 관계

비기능 요구​

성능, 품질, 안전, 보안, 사용성

• 시스템 구축에 대한 성능, 보안, 품질, 안전 등에 대한 요구 사항
• 외부 인터페이스
• 메모리 제약
• 성능 요구
• 사용자 특성과 가정
• 설치 환경의 적합성

요구 추출​

• Requirement Elicitation
• 요구에 대한 정보 출처 파악 > 요구에 대한 정보 취합 > 요구와 제한 사항 정리

요구 정보 출처​

• 고객
• 도메인 전문가
• 이해당사자
• 사용자
• 역공학
• 기존 문서
• 인터뷰
• 설문
• 브레인스토밍
• 프로토타이핑

요구 품질​

• 원자성: atomic, 요구사항이 복합 목적이 아니라 단일 목적인지
• 완전성: complete, 요구 사항 안에 정의된 것이 정보의 모든 것을 포함하는 것인지
• 비모호성, 통일성: unambiguous, consistent, 명확하지 않거나 같은 내용을 다르게 언급하지 않는 것
• 추적성: traceable, 요구 사항을 쉽게 추적할 수 있도록 고유번호
• 우선순위화: prioritize: 요구 사항의 중요도를 파악하는 성질
• 테스트 가능성: testable, 요구 사항이 검증 가능하도록 기술되어있는 특성

유스케이스​

• 찾아낸 각 액터에 대해 시스템과 관련된 작업은 무엇인가?
• 시스템에서 발생하는 특정 사건에 대해 액터에게 알려야 하는가?
• 액터가 갑작스런 외부 변화에 대해 시스템에 알려야 할 것인가?
• 시스템이 비지니스에 정확한 동작을 제공하나?
• 찾아낸 유스케이스로 모든 기능을 수행할 수 있는가?
• 어떤 유스케이스가 시스템을 지원하고 유지보수하나?
• 시스템에서 어떤 정보를 수정하거나 만들어야하나?

요구분석 명세서​

• SRS: Software Requirement Specification
• 소개
  • 목적
  • 제품 범위
  • 정의, 동의어, 약어
  • 참조문서
  • 개요
• 일반적인 기술사항
  • 제품의 개관
  • 제품의 기능
  • 사용자 특성
  • 제약사항
  • 가정 및 의존성
• 상세한 요구사항
  • 외부 인터페이스
  • 기능요구
  • 성능요구
  • 논리 데이터베이스 요구
  • 설계 제약사항
  • 소프트웨어 시스템 속성
  • 상세요구 사향의 구성
• 부록
• 색인

요구 검증​

• 이해용이성: comprehensibility, 요구 명세서를 읽을 떄 요구의 의미를 잘 이해할 수 있는가?
• 중복: redundancy, 필요없이 중복된 부분이 없는가?
• 완전성: completeness, 빠진 요구가 없는지, 요구 기술시 빠진 정보가 없는가?
• 일관성: consistency, 요구사항이 모순되지 않는가?
• 모호성: ambiguity, 요구분석 내용이 모호함 없이 모든 참여자들에 의해 명확하게 이해될 수 있는가?
• 검증가능성: verifiable, 요구분석 명세서에 기술된 내용이 사용자의 요구를 만족하는가? 개발된 시스템이 요구사항 분석 내용과 일치하는지 검증할 수 있는가?
• 추적가능성: traceable, 시스템 요구사항과 시스템 설계문서 및 구현과 매핑되어 추적할 수 있는가?

요구 모델링​

• 도메인지식을 체계화하는 과정
• 도메인지식: 업무 프로세스, 기능, 역할, 업무 규칙
• 기능적 모델링: 유스케이스 다이어그램, 액티비티 다이어그램
• 정적 모델링: 클래스 다이어그램, ERD
• 동적 모델링: 시퀀스 다이어그램, 협동 다이어그램
• 제어 모델링: 액티비티 다이어그램

UML​

• 구조다이어그램: 클래스, 객체, 컴포넌트, 배치, 패키지, 컴포지트 구조
• 동작 다이어그램: 유스케이스, 액티비티, 상태
• 인터랙션 다이어그램: 시퀀스, 커뮤니케이션, 인터랙션 오버뷰, 타이밍

아키텍처 평가 모델​

SAAM​

• Software Architecture Analysis Method
• 이해관계자 품질 민감 시나리오 도출, 시나리오 우선순위, 시나리오 기반 아키텍처 평가

ATAM​

• Architecture Trade-off Analysis Method
• 업무 배경 및 요구사항으로 품질 속성 도출, 시나리오 기반 아키텍처 절충점, 리스크 분석, 아키텍처 반영 및 평가
  • 품질속성: 유지보수성, 성능, 가용성, 보안성, 사용용이성

UI​

• 관련 분야
  • HCI 인간 컴퓨터 상호작용
  • 인터렉션 디자인, 사용자 중심 디자인, 상황별 디자인, 참여 디자인, 목표지향 디자인
  • 사용자 경험
  • 인간 공학
• 사용성 (효과적 -> 쉬움 -> 즐거움)
  • 학습용이성
  • 효율성
  • 기억용이성
  • 낮은 오류율

참조​

• 소프트웨어 공학의 모든 것
• ISO 12207: SDLC
• ISO 24773: SWEBOK
• ISO 25010: 소프트웨어 품질특성

MAS 개념​

• 공공기관이 다양한 수요 충족을 위해 2인 이상(다수)을 대상으로 단가 계약을 체결하는 제도
• 조달제품 다양화로 수요기관의 선택권 확대

MAS의 특징​

• 여러 공급자와 계약을 체결하여 수요기관의 선택 폭을 확대
• 기업에게 정부조달시장 참여 기회 제공
• 업체 간 경쟁의 확대

MAS 의 평가 절차, 항목, 2단계 경쟁​

MAS의 평가 절차​

• 조달사업법 제13조 기반하여 계약 진행

MAS의 절차 세부 항목​

• 5천만원 이상의 경우, 2단계 경쟁으로 투명성, 경쟁성 강화

MAS 2단계 경쟁 제도​

제3자 단가계약과 MAS차이점​

참조​

• 조달청: MAS 다수공급자계약

ISO 25000의 개요​

• SQuaRE: Software Product Quality Requirements and Evaluation
• SW 품질 평가 모델 ISO 9126과 SW 품질 평가 절차 모델 ISO 14598을 통합한 품질 평가 모델
• 기존 SW 품질 평가 표준 모델의 모호성 개선 및 통합 품질 요구 명세부터 품질 판정까지 표준 지침 제공

ISO 25000 구성도 및 구성요소​

ISO 25000 구성도​

ISO 9126 품질특성 + ISO 14598 품질평가 절차

                        +----------------+
                        | 품질모델 (25010) |
                        +----------------+
                                |
+----------------+       +-------------+        +----------------+
| 품질평가 (25040) |-------|    품질관리    |-------| 품질측정 (25020)  |
+----------------+       +-------------+        +----------------+
                                |
                        +----------------+
                        | 품질요구 (25030) |
                        +----------------+

ISO 25000 구성요소​

• 기능적합성, 신뢰성, 사용성, 실행효율성, 유지보수성, 이식성, 호환성, 보안성 품질 제고

ISO 25000 활용 및 기대효과​

• SW 품질 평가의 편리성, 신뢰성, 명확성 제공
• SW 품질 향상 및 경쟁력 확보 지표 제시
• ISO 9126과 ISO 14598 표준 간 갭을 제거하여 품질 평가의 일관성 확보

소프트웨어 진화 법칙 개요​

소프트웨어 진화 법칙 개념​

• 대부분의 소프트웨어가 존재하는 동안 변경이 일반적이며, 지속적으로 유지되기 위해 준수해야하는 법칙
• 품질관리와 변경관리의 중요성 강조, 유지보수 비용증가에 따른 관리전략 수립을 위해 필요

소프트웨어 진화 법칙 필요성​

• SW 변화의 특성을 이해하여 유지보수, 변경관리, 형산관리, 품질 통제의 중요 모델로 반영할 수 있으므로 효과적인 유지보수 및 변화관리 가능.

소프트웨어 진화 법칙 개념도, 핵심요소, 적용방안​

소프트웨어 진화 법칙 개념도​

소프트웨어 진화 법칙 핵심요소​

• SW 변화 특성을 이해하고, 유지보수, 변경관리, 형상관리, 품질 통제의 중요 모델로 반영

소프트웨어 진화 법칙 적용방안​

소프트웨어 진화법칙 추가적인 고려사항​

• 신기술 도입과 기존 기술의 진화를 지속적으로 모니터링하여 SW 기술 부채를 최소화하는 활동 필요

화이트박스, 블랙박스 테스트 개요​

화이트박스, 블랙박스 테스트 개념​

화이트박스, 블랙박스 테스트 배경​

• 테스트 V모델에서 요구사항/분석/설계/코딩 측면은 개발자 관점의 화이트박스 테스트로 Verification 하고,
• 단위/통합/시스템/사용자 테스트 측면은 사용자 관점의 블랙박스 테스트로 Validation 하게 설계 필요.

화이트박스, 블랙박스 테스트 개념도, 핵심요소, 적용방안​

화이트박스, 블랙박스 테스트 개념도​

• 내부구조를 파악하는지 여부에 따라 기법 변경

화이트박스, 블랙박스 테스트 핵심요소​

화이트박스, 블랙박스 테스트 적용방안​

테스트시 고려사항​

• 화이트박스와 블랙박스 테스트의 장점을 결합하여 제한적 내부 정보를 활용한 그레이박스 테스트 기법 고려

모듈화​

모듈화의 개념​

• 시스템을 분해하고 추상화하여 SW 성능을 향상시키거나, 시스템의 디버깅, 테스트, 통합 및 수정을 용이하도록 하는 SW 설계 기법

모듈화의 장점​

• 모듈 재사용성, 개발과 유지보수성
• 복잡성 감소
• 오류 파급효과 최소화
• 기능 분리가능, 인터페이스 단순화
• 낮은 결합도, 높은 응집도

응집도와 결합도 개요​

응집도와 결합도의 개념​

• 응집도: 하나의 모듈 내부의 처리요소 간 기능적 연관성을 측정하는 척도
• 결합도: 모듈 간의 관련성을 측정하는 척도

응집도와 결합도의 배경​

• 최근 MSA 적용에 따른 모듈화의 중요성이 증가되었고, MSA의 각 서비스 단위(컴포넌트)는 응집도가 높고 결합도가 낮게 구현되어야함.

응집도와 결합도 종류 및 설명​

응집도의 종류 및 설명​

우논시절통순기

• 가능한 높은 응집도를 추구하여 유지보수 용이성 확보
• 모듈 간 결합도는 최소화하여 각 모듈은 높은 응집도 확보
• Co-incidental -> Logical -> Temporal -> Procedural -> Communicational -> Sequential -> Functional

결합도의 종류 및 설명​

내공외제스자

• 모듈 상호간 낮은 결합도 추구
• 모듈 간 사이드 이펙트(리플 이펙트) 최소화
• Contents -> Common -> External -> Control -> Stamp -> Data

응집도, 결합도 적용방안​

모듈성을 높이기 위한 고려사항​

• 코드리뷰를 통해 개발단계에서의 의존성 문제, 인터페이스 불일치 등 저해요인 방지
• MSA 설계시 서비스 단위로 높은 응집도, 낮은 결합도를 갖게 설계

몽키테스트, 회귀테스트 개요​

몽키테스트와 회귀테스트 개념​

몽키테스트와 회귀테스트 배경​

• 애자일 개발 방법론 도입으로 소프트웨어의 잦은 변경으로 인하여 자동화되고 연속적인 테스트의 필요성 증가
• 기존 테스트를 지속하면 살충제 패러독스가 발생하므로, 새로운 버그 발견을 위해 몽키테스트 실행

몽키테스트와 회귀테스트 개념도, 구성요소​

몽키테스트와 회귀테스트의 개념도​

• 테스트케이스나 시나리오 없이 예측할 수 없는 방식으로 무작위 테스트

• 코드, 기능 변경 후 기존 기능이 정상적으로 동작하는지 테스트

몽키테스트와 회귀테스트 구성요소​

통합테스트 계획시 포함할 주요사항​

• 시스템 목적, 범위
• 대상시스템 구조
• 테스트 자원, 일정
• 시작 및 종료 조건
• 테스트 시나리오
• 테스트 방법 및 절차 교육

데이터옵스, 데브옵스 개념​

• 데이터옵스: 데이터 분석/관리 프로세스에 DevOps 원칙을 적용하여 분석 처리의 효율성을 높이는 방법론
• 데브옵스: 개발과 운영을 통합하여 SW개발주기를 단축하고 품질을 향상시키는 방법론
• 데이터 요구사항, 비지니스 요구사항에 실시간으로 대응하기 위해 필요성 대두

데이터옵스, 데브옵스 개념도, 구성요소, 적용방안​

데이터옵스, 데브옵스 개념도​

데이터옵스, 데브옵스의 구성요소​

데이터옵스의 추가적인 고려사항​

• AI를 활용하는 MLOps로까지 확장하여, 데이터 기반의 의사결정을 더 빠르게 가져갈 수 있음.

소프트웨어 안정성 분석 개요​

• 각 개발 수명주기에서 안전 보증, 확인 활동 수행
• SW시스템의 오류, 장애, 실패를 예방하고, 위험을 회피, 전가, 감수, 수용하기 위해 시스템 위험요소를 식별하고 평가하는 과정.
• IoT와 안전필수시스템(자율주행, UAM 등)의 기능적 사고로 인한 인명피해방지를 위해 필요

소프트웨어 안정성 분석 주요 기법​

FTA, Fault Tree Analysis​

• 시스템 주요 실패 이벤트를 트리구조롤 분석하여 원인 규명
• Top-Down 방식
• 분석범위의 정의 및 분석수준의 결정 -> 대상제품의 특성 파악 -> 정상사상 정의 -> 결함수의 구성 -> 결함트리의 정성적 분석 -> 결함트리의 정량적 분석 -> 분석결과의 평가 및 보고

FMEA, Failure Mode and Effects Analysis​

• 분석 과제 정의 및 분석 준비 -> 분석 실시 -> 분석 결과의 정리 및 심층 분석

HAZOP, Hazard and Operability study​

• 목적 및 분석범위 설정 -> 분석팀 구성 -> 예비조사 -> 브레인스토밍 -> 분석결과 기록

소프트웨어 안정성 분석시 고려사항​

• ISO 26262 등 해당 산업의 규제 및 표준을 준수하여 분석 수행