소프트웨어공학 중간고사 정리 (2)

카테고리 없음

소프트웨어공학 중간고사 정리 (2)

hjr067 2024. 10. 17. 04:37

4. Requirements Engineering 요구 공학

초반에 무엇을 만들지 정의하는 것은 매우 중요 !
고객이 시스템에서 요구하는 서비스와 시스템의 운영과 개발에 대한 제약사항을 설정하는 과정
요구사항
- 서비스, 제약 사항
- 사용자 요구사항 - 고객을 위해 작성
  - 고객 관리자
  - 시스템 최종 사용자
  - 고객 엔지니어
  - 계약 관리자
  - 시스템 아키텍트
- 시스템 요구사항 - 사용자 요구사항보다 상세하게 설명한 구조화된 문서, 구현해야 할 사항을 정의
  - 시스템 최종 사용자
  - 고객 엔지니어
  - 시스템 아키텍트
  - 소프트웨어 개발자
- → 소프트웨어 요구사항 문서는 사용자 요구사항의 정의와 시스템 요구사항의 사양을 모두 포함해야 함.
  - 문서에는 시스템이 수행해야 하는 방법보다 해야하는 작업을 작성
- 기능 요구사항 (기능 혹은 시스템 서비스를 설명)
  - 시스템이 제공해야 하는 서비스
  - 특정 입력에 대해 시스템이 반응하는 방식
  - 특정 상황에 시스템이 동작해야 하는 방식
  - 시스템이 해서는 안 되는 일을 명시
  - 사용자 기능 요구사항 / 시스템 기능 요구사항
- 비기능 요구사항 (시스템의 속성과 제약 조건을 정의) ex. 안전성, 응답시간, 메모리 공간
  - 시스템이 제공하는 서비스나 기능에 대한 제약 사항 : 시간적 제약, 개발 프로세스에 대한 제약, 표준 등
  - 전체 시스템에 적용되는 경우 ↑ (개별 기능, 서비스보다)
  - 기능 요구사항이 아니기에 프로그래밍 언어, 개발 방법(waterfall, 애자일 등) 지정 가능
  - 비기능이 기능보다 더 중요할수도!
- 도메인 요구사항
  - 운영 영역에서 시스템에 대한 제약사항(도출하기 어려움)
  - SW 랑 HW언어가 달라 도메인 요구사항 도출 어려움
  - ex. 열차 제어 시스템은 다양한 기상 조건에서 제동 특성을 고려해야 한다.
부정확한(모호한) 요구사항은 다르게 해석할 가능성이 있음.
- 요구사항은 완전성(사용자가 필요로 하는 모든 서비스와 정보가 포함)과 일관성(요구사항에 대한 설명에 충돌이나 모순이 없어야 함)이 있어야 함
- 그러나... 실제로 완전하고 일관된 요구사항 문서를 생성하는 것은 불가능
software quality characteristics
- 기능성, 효율성, 사용성, 신뢰성, 유지보수성, 이식성
- 기능 적합성, 성능 효율성, 호환성, 사용성, 신뢰성, 보안성(굉장히 강조), 유지보수성, 이식성으로 upgrade!
- 사용성 중 사용자 인터페이스 심미성은 주관적일 수 있으니 정확한 기준 필요
Goals and Requirments
- 비기능 요구사항은 정확하게 기술하기 매우 어렵고 부정확한 요구사항은 검증하기 어려움 ...
- 그럼 검증 가능한 비기능 요구사항은?
  - 객관적으로 test할 수 있는 몇 가지 척도(Metric)를 사용해서 요구사항 작성
    - 속도 - 처리한 트랜잭션/초, 사용자/사건 반응 시간, 스크린 refresh 시간
    - 크기 - Mbyte, ROM 칩의 개수
    - 사용 편리성 - 교육 시간, 헬프 프레임의 수
    - 신뢰성 - 가용성, 고장 발생 비율, 비가용확률, 고장까지의 평균시간(높을수록 굿!) -> 안정적으로 이 시스템이 동작하는가 ?
    - 견고성 - 고장 후 재가동 시간, 고장 원인 사건의 백분율, 고장에 의한 데이터 손상 확률
    - 이식성 - 타켓 시스템 수, 타겟 시스템에 종속된 문장의 백분율
  - 요구사항은 1문장당 1개씩 들어가야 함
  - ex) 의료 직원은 네 시간의 교육을 받은 후 모든 시스템 기능을 사용할 수 있어야 한다. 이 교육이 끝나면, 숙달된 사용자가 저지르는 오류의 평균 개수는 시스템 사용 한 시간에 2개를 넘지 않아야 한다. (→ 테스트 가능한 형태의 비기능 요구사항)
그래픽 표현 - UML 유스케이스와 시퀀스 다이어그램을 흔히 사용 / 기능 요구사항을 정의한다.
Structured natural language
- 기능이나 개체에 대한 설명
- 입력과 입력의 출처에 대한 설명
- 출력과 출력의 목적지에 대한 설명
- 수행해야 하는 동작에 대한 설명
- 사전 조건과 사후 조건(필요한 경우)
- 기능으로 인한 부작용

[Requirments Engineering Process]

요구공학에서 사용되는 프로세스는 애플리케이션 도메인, 관련된 사람 및 요구사항을 개발하는 조직에 따라 크게 달라짐
공통적인 일반 활동들
1. 타당성 조사 → (타당성 조사 보고서)
2. Requirments elicitation and analysis 요구사항 도출 / 요구사항 발견 → (System models)
  - 기술 스태프가 고객과 협력하여 애플리케이션 도메인, 시스템이 제공해야 하는 서비스 및 시스템의 운영상 제약사항을 찾아내는 것
  - 이해관계자 : 최종 사용자, 관리자, 유지보수와 관련된 엔지니어, 도메인 전문자, 노동 조합
    - 이해관계자들이 모여 system 요구사항 도출
    - 이해관계자들은 자신이 진정으로 원하는 것이 무엇인지 모름
    - 이해관계자들은 요구사항을 자신의 용어로 표현
    - 이해관계자마다 요구사항이 상충할 수 있음
    - 조직적 및 정치적 요인이 시스템 요구사항에 영향을 미칠 수 있음
    - 요구사항은 분석 프로세스 도중 변경됨(새로운 이해관계자 등장, 비즈니스 환경 변경)
  - [요구사항 도출 및 분석 단계]
    - 요구사항 발견
    - 요구사항 분류 및 구성 (clinic 요구사항, 수정할 요구사항 ....)
    - 요구사항 우선순위 정하기 및 협상
    - 요구사항 문서화
  - [요구사항 도출 방법]
    - Interviewing - 폐쇄적 인터뷰, 개방적 인터뷰 → 일반적으로 혼합
      - 대상자 : 스프링보드 질문, 요구사항 제안 혹은 프로토타입 시스템 함께 사용하여 토론
    - Scenarios 시나리오 - 실제 예
      - 시작 상황에 대한 설명, 사건들의 정상적인 흐름에 대한 설명, 잘못될 경우에 대한 설명, 동시에 진행할 수 있는 다른 활동에 대한 정보, 시나리오가 종료되었을 때의 시스템 상태에 대한 설명
    - Use cases - 상호작용에서 행위자를 식별하고 상호작용 자체를 설명하는 UML의 시나리오 기반 기술
      - 시스템과의 가능한 모든 상호작용을 설명해야 함
      - 자세한 표 설명
      - 시퀀스 다이어그램 - event 처리 순서를 보여줌 - use case에 세부 사항을 추가하는데 사용 가능
3. Requirments specification 명세화 → (User and system requirments)
4. Requirments validation 검증 과정 → (Requirments document) 문서화시켜서 정리
  - 고객이 진정으로 원하는 시스템을 요구사항이 정의하고 있는가?
  - 요구사항 문제 수정 비용 > 설계, 코드 오류 수정 비용 → 검증 매우 중요
  - Requirments checking
    - 유효성 - 고객의 요구를 가장 잘 반영하는 기능을 제공하는가?
    - 일관성 - 요구사항 충돌이 있는가?
    - 완전성 - 고객이 요구하는 모든 기능이 포함되어 있는가?
    - 실현성 - 요구사항이 주어진 예산과 기술로 구현 가능한가?
    - 검증가능성 - 요구사항 확인이 가능한가?
  - [요구사항 검증 방법]
    - 요구사항 리뷰
      - 정의가 공식화되는 동안 정기적인 리뷰 필요
      - 고객과 계약 직원 모두 !! 리뷰에 참여해야됨
      - 리뷰는 공식적, 비공식적 둘 다 가능. 원활한 의사소통은 초기단계에서 문제를 해결 가능
    - 프로토타이핑 - 시스템의 실행 가능한 모델을 사용하여 요구사항 확인

: 1 → 2 → 3 ↔ 4

4번의 산출물로는 2 3 4 다 접근 가능

- 요구사항 관리는 변화하는 요구사항을 관리하는 프로세스 (개발되고 사용되기 시작한 후에 새로운 요구사항 계속 나타남), 개별 요구사항 추적, 종속된 요구사항간의 링크를 유지

5. Architectural Design

[Advantage of explicit architecture]

이해관계자 커뮤니케이션
시스템 분석 : 시스템이 비기능적 요구 사항을 충족할 수 있는지 여부에 대한 분석이 가능
대규모 재사용
- 아키텍처는 다양한 시스템에서 재사용이 가능
- <아키텍처 패턴> 반복적으로 발생 문제 대해 일반적인, 재사용 가능한 패턴(아키텍처 요소와 요소 간의 관계를 패턴으로 표현한 것)
  - 계층형 아키텍처(Layered architecture)
    - 서브 시스템의 인터페이스를 모델링하는데 사용
    - 시스템을 일련의 서비스를 제공하는 계층 집합(비슷한 service 제공하는 것들끼리 묶어서)으로 구성
    - 다양한 계층에서 서브 시스템의 증분 개발을 지원. 계층 인터페이스가 변경되면 인접한 계층만 영향을 받음.
    - 기존 시스템 위에 새로운 설비를 구축할 때 사용
    - 더보기
      맨 밑 DB가 젤 방대 -> 그 위 Library index -> 그 위 핵심 business logic들 -> 그 위 web browser interface
      
      이런식으로 위 계층을 통해 접근 가능
      
      공통으로 들어가는 것들 상위에 배치!
      
      장 ) 인터페이스가 유지되는 동안은 전체 계층 교체가 가능, 중복 기능(예:로그인)을 각 계층에 제공하여 시스템의 신뢰성을 높일 수 있음
      
      단 ) 계층간 명확한 분리를 제공하기 어려움. 상위 계층은 바로 아래 계층 통하지 않고 direct로 하위 계층과 직접 상호작용 해야할 수도... , 서비스 요청이 각 계층에서 처리될 때 여러 계층에서의 해석으로 인해 성능 문제가 발생할 수 있음
  - 리포지토리 아키텍처
    - 서브시스템들은 데이터를 교환해야 함(2가지 방법)
      - 공유 데이터는 중앙 DB 또는 저장소에 보관되며 모든 서브 시스템에서 접근 가능 (like 전역변수) - 데이터 간 일관성 유지 어려울수도...
      - 각각의 서브 시스템이 자체 DB를 유지 관리하고 다른 서브시스템이 명시적으로 데이터전달
    - 많은 양의 데이터를 공유해야한다면 공유를 위한 저장소 모델이 가장 일반적
    - 장기간 저장해야 하는 대량의 정보가 생성되는 시스템이 있을 때 사용
    - 더보기
      
      장) 모든 컴포넌트가 독립적일 수 있음. 각 컴포넌트는 다른 컴포넌트의 존재를 알 필요 X / 한 컴포넌트의 변경 사항을 모든 컴포넌트에 전파할 수 있음 / 모든 데이터가 한 곳에 있어 일괄적으로 관리 가능(ex. 동시에 백업 수행)
      
      단 ) 저장소에 실패가 발생하면 전체 시스템에 영향을 미침 (모든 데이터가 한 곳에 있기에) / 저장소를 통해 모든 커뮤니케이션을 구성하는 것이 비효율적 / 여러 컴퓨터에 저장소 배포 어려움
  - 클라이언트-서버 아키텍처
    - 데이터 및 처리가 다양한 컴포넌트에 분산되는 방식을 보여주는 분산 시스템 모델(ex. youtube)
    - 인쇄, 데이터 관리 등과 같은 특정 서비스를 제공하는 독립 실행형 서버 집합
    - 서비스를 호출하는 client 집합
    - 네트워크를 통해 클라이언트가 서버에 접근할 수 있도록 !
    - 공유 DB의 데이터를 다양한 위치에서 접근해야 할 때
    - 더보기
      
      장 ) 서버는 네트워크를 통해 분산될 수 있음. 일반 기능(ex. 인쇄 서비스)은 모든 클라이언트에서 사용될 수 있으며 모든 서비스에서 구현될 필요는 X
      
      단 ) 각 서비스는 단일 장애 지점이므로 서비스 거부 공격이나 서버 장애에 취약 / 성능은 네트워크에 따라 달라지기에 예측 불가 / 다른 조직에서 서버 소유한 경우, 관리 문제 발생
  - 파이프-필터 아키텍처
    - 우리가 만든 프로그램이 어떠한 과정으로 입력과 출력이 이루어지는지 구조화
    - 기능 변환은 입력을 처리하여 출력을 생성
    - 대화식 시스템에는 부적합
    - 배치 순차 모델
    - 일반적으로 입력이 관련 출력을 생성하기 위해 별도의 단계에서 처리되는 데이터 처리 애플리케이션에서 사용(일괄처리 및 트랜잭션 기반 모두)
    - 더보기
      입력이 들어오고, 그에 맞는 출력(절차적 진행, 순서대로)
      
      그러나 하나의 입력에 따라 과정이 두개로 나뉠 수 있음(동시 실행 가능)
      
      장 ) 워크플로 스타일(작업 process)은 많은 비즈니스 프로세스의 구조와 일치 / 순차 또는 동시 시스템으로 구현할 수 있음. (병행되는 system)
      
      단 ) 데이터 전송 포맷은 변환을 위한 통신 사이에 합의되어야 함 / 각 변환은 입력을 해석하여 처리한 후, 출력을 생성할 때 합의된 형식으로 출력. 이러한 과정은 시스템 오버헤드 ↑, 호환되지 않는 데이터 구조를 사용하는 기능 변환에는 재사용이 불가
  - 모델-뷰-컨트롤러 아키텍처
    - 시스템은 서로 상호 작용하는 세 가지 논리적 컴포넌트로 구성됨
      - Model : (내부로직들 다 여기에) 시스템 데이터 및 해당 데이터와 관련된 작업 관리 → 사용자 요구사항 바뀌어서 UI에 영향이 가더라도 모델엔 영향 X
      - View : 데이터가 사용자에게 표시되는 방식을 정의하고 관리
      - Controller : 사용된 상호 작용(ex. 키 누름, 마우스 클릭)을 관리하고 이러한 상호 작용을 뷰 및 모델 컴포넌트에 전달
    - 데이터를 보고 상호 작용하는 방법이 여러가지일 때 사용 / 데이터 상호 작용 및 표시에 대한 향후 요구사항 없는 경우에도 사용
    - 더보기
      복잡성이 증가할 수 있음
      
      장 ) 데이터가 해당 표현과 독립적으로 변경되거나 그 반대로 변경될 수 있음 / 동일한 데이터를 다른 방식으로 표시할 수 있도록 지원
      
      단 ) 데이터 모델과 상호 작용이 단순한 경우에는 추가되는 코드 및 코드 복잡성이 포함
- 제품 라인 아키텍처가 개발될 수 있음 : Software product-line

< 클라이언트 서버 아키텍처 vs 리포지토리 아키텍처>

두 아키텍처의 차이

데이터 저장 및 접근 방식:
- 리포지토리 모델은 모든 데이터가 하나의 중앙 저장소(리포지토리)에 있고, 모든 시스템 요소가 이 저장소와 상호작용합니다.
- 클라이언트-서버 아키텍처는 데이터가 서버에 저장되어 있으며, 클라이언트가 요청을 통해 서버로부터 데이터를 받아옵니다.
구조적인 차이:
- 리포지토리 모델에서는 시스템 구성 요소들이 리포지토리에 접근하는 것이 일반적이며, 각 구성 요소 간에는 직접적인 통신이 없습니다.
- 클라이언트-서버 모델에서는 클라이언트가 서버와 상호작용하여 데이터를 처리하고, 서버는 다수의 클라이언트 요청을 처리합니다.

언제 사용하는가?

리포지토리 모델은 공유 데이터의 일관성이 중요할 때, 여러 구성 요소가 동일한 데이터를 참조할 필요가 있을 때 유용합니다.
클라이언트-서버 아키텍처는 분산된 환경에서 여러 위치에서 서버에 접근하여 데이터를 사용해야 할 때 적합합니다.

두 모델 모두 공유 데이터를 다루지만, 시스템 구성 요소들 간의 상호작용 방식과 데이터 접근 구조가 다릅니다.

< Control styles >

중앙 집중식 제어 : 하나의 시스템이 다른 서브 시스템들을 시작/정지/제어하는 전반적인 책임
- 콜-리턴 모델
  - 제어가 서브루틴 계층의 맨 위에서 시작해서 아래로(하향식 서브루틴 모델), 순차시스템에 적용가능
- 관리자 모델 (위보다 조금 더 실시간 처리할 수 있는)
  - 동시 시스템에 적용 가능(다른 프로세스 끝날 때까지 기다리지 X, 동시에 호출하고 제어하는) 하나의 시스템 controller가 다른 시스템 프로세스의 시작, 중지 및 조정을 제어
이벤트 기반 제어 : 정말 event가 발생했을 때에만 실행 (ex. 키 입력 event)
- 브로드캐스트 모델 (like 방송)
  - 이벤트가 모든 서브 시스템으로 전달됨(각자!) 나에게 해당하는 것만 듣지 못하고 전부 다 들어야됨
  - 더보기
- 인터럽트 기반 모델
  - 인터럽트가 인터럽트 핸들러에 의해 감지되면, 처리를 위해 다른 컴포넌트로 전달되는 실시간 시스템에서 사용
  - 나에게 해당하는 것만 들을 수 있음 ! (필요한 process 호출)