[소프트웨어 공학] 소프트웨어공학 이론

그동안 알고있던 요구공학 + 소프트웨어공학이 이번 특강을 듣고 머리가 탁 트이는 느낌이 든다

시험보기 전에 훑어보았던 마구잡이 요구공학 내용이다

유스케이스

1) 사용자 요구사항을 조사하기 위한 기법

2) 사용자 중심, 사용법 중심의 관점

3) 시스템과 사용자의 상호작용에 초점을 맞춤 

   → 최종 사용자용 응용프로그램과 상호작용하는데 매우 뛰어나다.

4) 데이터 웨어하우스, 임베디드 제어 소프트웨어, 실시간 시스템, 계산을 수행하는 복잡한 비즈니스 규칙을 포함하는 시스템에 대해서는 한계 

    → 복잡한 비즈니스 규칙의 상호작용에 의해 주도

        - 사용자와 시스템의 상호작용에 강한 복잡성이 없음

        - 유스케이스 분석은 모든 시스템의 동작을 정의하는 기술로서는 부족

5) 분석가가 사용자의 관점으로 작성하기 때문에 사용자의 비즈니스 측면을 설명하면서 유스케이스와 관련시킬 수 있다.

6) 개발자에게 시스템의 동작에 대한 전체적인 이해를 제공한다. 

    → 유스케이스와 요구사항 명세서를 조합하여 사용한다.

 

Q 유스케이스와 기능 요구사항의 차이점, 관계

유스케이스와 기능 요구사항은 칼처럼 나눌 수 있는 건 아니지만 같지는 않다. 그 근거로는

첫째, 유스케이스와 기능 요구사항이 같다고 하면 유스케이스는 기능요구사항만큼 모든 상세한 기능을 포함해야만 한다. 그러나 유스케이스는 그만큼 디테일하지 않고 이것은 유스케이스 용도에 맞지 않는다.

둘째, 유스케이스는 시스템을 설명하기 위한 컨테이너이다. 유스케이스가 요구사항을 유도하는 베이스가 되는 것이지 기능요구사항과 같은 것은 아니다.

셋째, 유스케이스는 사용자와 가깝고 기능요구사항은 한발짝 더 나아가 개발자와 가깝다.

따라서 유스케이스 구조와 SRS 구조는 매핑관계가 있지만 1:1 매핑이 될 수 없다.

연결 문서

SRS와 같은 문서들은 정보를 전달하는 가교 역할을 한다. 따라서 명확해야 한다. 얼마만큼 디테일해야할까요?

> 연결 문서를 작성자 관점보다는 소비자의 시각에서 작성해야한다.

*SRS - Software Requirement Specification, 소프트웨어 요구 사양서

얼마나 상세하게 기술해야 하는가

1) 상세한 요구사항이 덜 적합한 경우

    - 고객들이 광범위하다.

    - 개발자들이 상당한 분야의 경험을 가진다.

    - 선례를 사용할 수 있다.

    - 패키지 솔루션이 사용될 수 있다.

 

2) 요구사항이 더 상세해야 하는 경우

    - 개발은 아웃소싱될 것이다.

    - 프로젝트 팀 멤버들이 지리적으로 흩어져 있다.

    - 요구사항이 테스트의 근거가 될 것이다.

    - 정확한 평가가 필요하다.

    - 요구사항 추적이 필요하다.

* 추적성:

각 요구사항을 만족하기 위해 생성되는 개별 기능 요구사항들, 유스케이스, 제품 기능 또는 비즈니스 규칙 등 그리고 작업 산물 사이의 논리적인 연결을 생성하는 활동

> 요구명세에 대해 대단히 엄격할 때! 중요!

> 모든 요구사항은 설계 요소에 대해 전방향으로 추적한다.

> 각 설계 요소는 지정된 요구사항에 대해 역으로 추적 가능하다.

> 모든 요구사항은 코드로 구현된다.

> 모든 코드는 설계 요소에 대해 추적가능하고 요구사항도 추적한다.

> 테스트 케이스는 각 요구사항에 대해 추적한다.

  - 완전성, 정확성, 일관성과 관련이 있다.

 

요구사항 스타일의 요소

시스템 관점에서 기능 요구사항 작성 -“시스템은 ~”

사용자 관점 - “ 사용자는 ~”

 

요구사항과 설계 사이의 퍼지라인

요구사항과 설계는 구분이

 > 명확 : 구조적 분석 (분석: DFD, 설계: 구조도(Flow Chart))

 > 모호 : 클래스다이어그램 (분석:클래스다이어그램, 설계:클래스다이그램 => ?? 노테이션의 차이는 없어. 설계에 관계된 클래스들이 등장하면 설계단이라고 생각하는 거야.)

클래스 다이어그램에서 보듯이 이것은 어느 수준에서 보느냐에 따라 달라진다. 즉 추상화 수준에 따른 관찰자의 시각 차이에서 기인한다. 추상정도와 대상이 다를 뿐 연관이 깊고 같은 표현이라고 할 수 있다. 비즈니스 목표단으로 올라갈수록 추상성이 증가하며 밑으로 내려갈수록 추상성은 감소하고 구체적이게 된다. 추상성이 클수록 사용자들이 요구하는 에센스들이 나타나고 구체적일수록 기계들이 요구하는 에센스들이 추가된다.

 

> 프로젝트를 착수한 이유 – 비즈니스 목표

> 사용자가 제품으로 할 수 있는 것 – 유스케이스, 시나리오, 스토리

> 개발자가 구축하는 것 – 특징, 기능요구사항, 제품 특성

> 시스템 구성요소들과 이들을 함께 조합하는 방법 – 제품 아키텍쳐, 사용자 인터페이스 아키텍쳐,

> 개별 요소들의 동작 – 상세 모듈, 클래스 설계, 데이터베이스 설계, 사용자인터페이스 설계

> 각 구성 요소의 구현 – 알고리즘, 사용자 인터페이스

 

제약 사항을 만족하기 위해 여러 가지 대안 중에서 요구사항으로 하나의 솔루션을 채택한다.

SRS, 설계물은 분리해서 생각해야하지만, 새로운 제품 개발이 아닌 기존 시스템을 고도화 시킬 때는 설계 제약을 설계 단계에서 생각하는 것이 아니라 SRS 초기 단계에 생각하는 것이 편할 때도 있다. (물론, 설계 제약을 강제해서는 안된다)

 

프로젝트 범위 정의

- 사용자, 액터가 어디까지 보는가, 개발자가 어디까지 개발해야하는가는 제품 범위와 관련이 있다. 

- 제품 범위는 현재 프로젝트가 다룰 궁극적인 제품 비전에 대한 부분, 프로젝트 입력과 출력 사이의 경계를 말한다. 

  (제품 비전은 궁극적이 목적에 대한 장기 전략 개념과 새로운 형식의 시스템을 말함)

- 범위는 컨텍스트 다이어그램, 유스케이스, 특징 수준에 의해 설정될 수 있다.

- 컨텍스트 다이어그램은 원의 원주인 시스템 경계 밖에는 외부엔티티인 터미널이 있다. 

- 프로젝트 이해 관계자들이 시스템 경계 외부에 놓여 있는 것에 대한 공통의 이해를 전달하는데 도움을 준다. 

- 유스케이스의 사각형 박스는 컨텍스트 다이어그램의 원과 비슷하게 시스템 경계를 나타낸다. 

- 박스 외부의 사람 모양은 액터를 나타내는데 어떤 목적을 가지고 시스템에 접근하는 사람, 시스템, 하드웨어 등이며, 이들이 보는 서비스 단위가 유스케이스이다. 이 또한 시스템 바운더리로 사용되기에 적합하다.

- 사용자에게 능력을 제공하고 비즈니스 목표를 충족시키는 논리적으로 관련된 일련의 기능요구사항이다.

- 릴리즈 근거 요소 value-oriented

 

모래 위에 그은 선

요구는 계속해서 변경한다. 이로 인해 비용, 일정, 인원 등이 영향을 받는다. 이때 요구관리가 필요하다. 베이스라인은 공식적으로 검토하여 동의한 명세나 제품으로 그 후 향후 개발을 위한 기준으로서 다루어지고 공식 변경 통제 절차를 통해서만 변경될 수 있다. 공식 변경 통제를 시작한다. ? 프로젝트 관리자는 일정, 예산, 인원에 대해 책임을 가진다.

 

여섯 명의 장님과 요구사항

자연어는 

 1) 모호성이 강하다

 2) 명세가 길어진다 

 3) 추상성 수준이 낮다 

 4) 검증이 힘들다

 와 같은 문제를 갖는다.

글로 표현하는 방법 외에 그래픽 분석 모델이 있다.

- 시스템 외부 인터페이스 : 컨텍스트 다이어그램 / 유스케이스

- 프로세스 흐름 단계 : DFD, Flow Chart / Activity, Sequence Diagram

- 데이터나 개체의 상호관계 : ERD / Class, Instance Diagram

- 시스템이나 개체 상태 : 상태전이 다이어그램 / State Diagram

- 사용자 인터페이스 아키텍처 : 다이얼 로그 맵

+ petri net

include / extends

<<include>>

재사용의 개념에서 반복되어 서술되는 유스케이스가 있는 경우에 간결한 서술을 하도록 한다.

<<extends>>

기존의 유스케이스의 행위를 확장 혹은 추가시키는 용도로 사용된다.

 

시스템 서술의 누락

일차 액터가 없는 경우

인터페이스 세부사항이 너무 많은가?

매우 낮은 목표수준인가?

목적과 내용이 다른 경우인가?

 

상세 기술 결정 , 언제?

-> 비용, 위험 관계에 대한 균형 필요

 

 

브레인스토밍

 

생성단계 – 가능한 많은 참여자들의 의견을 수집한다.

통합단계 – 1. 의견 분류 및 논의 2. 의견 명확화 및 구조화 3. 의견 우선순위화

 

Critical – 없어서는 안 될 필수적인 feature을 의미

          - 이 feature 없이는 시스템이 무의미함

Important – 시장 점유율, 사용성에 중대한 영향을 줄 수 있는 부류

              - 올바로 구현되지 못했을 때 구매를 포기하거나 싫어하게 함

Useful – 갖추면 좋은 사항들

          - 편리함을 제공해 주는 요소

          - 가능한 많은 의견을 생성하고, 자유로운 의견을 표현하며 의견을 공개한다.

 

품질 요구사항은 올바른 문법, 정확한 철자법, 잘 구성된 문법, 논리적인 구조를 갖는다.

Should, may, might와 같은 단어 사용을 피한다.

명시적인 우선순위를 별도로 표기한다.

 

시스템관점

시스템은 ~에서 ~에 대해 ~를 만족하는 ~를 제공해야 한다.

사용자 관점

~은 ~에 대해 ~를 만족하며 ~를 수행해야한다.

 

- 바람직한 형태로 바꾸어 쓴다.

- 계층적 방식의 요구 서술은 부모 요구사항과 하나 이상의 자식 요구사항을 갖는다.

- 복잡한 논리는 요구사항을 모호하게 만들 위험이 있다.

- 부정적, 혹은 반대 요구사항은 혼란의 원인이 된다.

- 이중 삼중 부정 표현은 삼간다.

- 부정은 only 제약을 사용한 긍정으로 바꾼다.

- 요구사항은 중요한 정보가 결핍되어 있기도 하다. 분석가가 이를 발견하고 끄집어내야한다.

 

컨텍스트 다이어그램

1. 1970년대 구조적분석에서부터 시작됨

2. 원과 터미네이터를 통해 시스템의 경계를 나타냄

3. 외부 엔티티의 대상 : 사용자 클래스, 조직, 액터, 엔티티를 연결하는 다른 SW, HW

4. 고수준의 추상화로 범위를 나타낸다.

5. 어떤 특징과 기능이 범위 내에 있는지 명백히 식별하지 않는다.

6. 프로젝트 이해 관계자들이 시스템 경계에 놓인 것에 대한 공통 이해를 전달하는 데 도움을 준다.

 

유스케이스 다이어그램

1. UML을 구성하는 중요한 요소로 사용자 요구사항을 표현한다.

2. 사각형 박스는 컨텍스트 다이어그램의 원과 비슷하게 시스템의 경계를 표현한다.

3. 액터는 외부 엔티티로 시스템과 작용한다.

4. 컨텍스트 다이어그램과는 달리 유스케이스는 시스템의 가시성을 제공한다.

5. 화살표는 데이터 흐름을 표현하는 것이 아니다.

6. 유스케이스는 컨텍스트 다이어그램보다 더 많은 범위를 제공한다.

7. 그러나 매우 큰 소프트웨어 시스템인 경우 유스케이스와 액터사이에 많은 연결선을 가진 수십개의 유스케이스가 등장할 수 있다.

 

 

특징 수준

특징 : 사용자에게 기능을 제공하고 비즈니스 목표를 충족시키는 논리적으로 관련된 일련의 기능 요구사항

특징은 사용자가 인식할 수 있는 제품의 능력이다.

릴리즈를 반복적으로 생산할 때 특징은 향상된다.

특징이 향상되는 것은 사용가치를 향상시키는 것이다.

분석가는 최우선 순위 특징에 대해 집중할 필요가 있다.

 

요구사항 우선순위화

모두 다 할 수 없으며 더욱이 더 잘할 수는 없다.

모든 요구를 똑같이 처리하면 위험이 커진다.

상호간의 합의가 어렵다.

Value-Oriented

Value, Cost, Rist 제약 안에서 Product Value를 최대화

목표로 하는 핵심 비즈니스 가치를 평가 근거로 사용

 

VOP

우선순위를 부여할 모든 Feature, Use cases를 listing

각 Feature가 제공하는 상대적 benefit을 예측

Feature가 포함되지 않을 때 상대적 panelty를 예측

상대적 benefit과 penalty를 계산

구현을 위한 상대적 비용 예측

기술적 또는 그 외 위험의 상대적 정도를 예측

각 기능에 대한 우선순위를 계산

features 리스트를 정렬

 

 

현 시스템 정의, 평가, 제안 시스템을 위한 비즈니스 요구 정의, 처리요구 정의, 교육 및 시스템 인수 조건 정의

 

 

구조적 분석 자료의 흐름과 가공 절차를 그림 중심으로 표현하는 방법

배경도 작성

상위 자료 흐름도 작성

하위 자료 흐름도 작성

자료 사전 작성

소단위 명세서 작성

하향식 원리 적용

 

베이스라인 

공식적으로 검토하여 동의된 명세나 제품으로 그 후 향후 개발을 위한 기준으로서 다루어지며 공식 변경 통제 절차를 통해서만 변경할 수 있다.

공식 변경 통제를 시작

프로젝트 관리자가 스태프와 예산을 결정한다.

프로젝트 관리자가 일정에 대한 책임을 갖는다.

요구사항을 일찍 정의하는 것은 통제 프로세스를 지나치게 압박할 수 있다.

베이스라인 구축이 너무 오래 거리는 것은 분석 불능상태라는 신호로 될 수 있따.

 

비정형 기법 – 자연어

- 작업 및 이해 용이, 사용자와 개발 팀간의 의사전달 용이

- 불충분환 명세, 일관성 결여, 내용의 모호성, 완전성 검증 논란.

- 가장 일반적이며 친숙하다.

- 명세 언어로 가장 바람직하지 못한 형태이다.

준정형 기법

- 구조적 분석/ 데이터 모델/ 객체지행 표기법/ 프로세스 기반 표기법

- 보통 수준의 엄밀성을 가진다.

- 쉽게 배울 수 있고 활용이 용이하다.

- 다양한 형태의 도구가 지원된다.

정형기법

- 명세의 정확성, 불완전성, 불일치 검토 입증, 모호성 방지

- VDM, Z, Petri-net

- 가장 강력한 표현 기법이다.

- 습득과 활용에 많은 시간이 걸린다.

- Mission Critical & Safety Critical

- 어려운 요구 분석, 검증 기술

- 간결한 표현

- 명세에 일관성, 완정성 증명 가능

- 도구 사용이 필수적

 

Flow Chart

- 분석보다는 설계를 표현하는 방법

- 처리의 제어에 관심 => 시작, 종료, 분기, 반복 등의 제어 흐름을 표현

- 자료는 처리 표현의 부분으로 등장

- 자료구조는 나타나지 않음

 

Decision Tables

- 요구 명세를 테이블의 형태로 표현

- 기능 요소에 관한 모든 조건과 이에 관한 모든 반응이 나열됨

- 복합조건에 유리함

- 완전성, 모호성 확인에 유리함

- 변수의 개수에 비례하여 테이블 크기가 증가

- 이해의 용이성으로 인해 많이 사용됨

 

Petri-net

- 시스템의 정적, 동적 특성을 표현

- 정보의 흐름을 표현하기 위한 다이어그램

- 장소, 천이 두 종류의 노드가 있다.

- 노드는 아크에 의해 연결된다.

- 토큰은 시스템의 동적 특성을 표현한다.

  

유한 상태 기계

- 상태 : 시스템을 구성하는 값들의 집합으로 시간의 흐름에 따라 변한다.

- 상태 기계의 구성을 통해 시스템이 작동하는 과정을 검증할 수 있다.

- 시작상태 -> 종료상태로 값들을 이동시킨다.

- 상태집합, 천이함수

- 상태 기계의 표현은 상태 천이 다이어그램 혹은 상태천이표로 나타낸다.