zheld.doden

유스케이스 모델링

유스케이스 

유스케이스는 시스템이 액터에게 관찰 가능한 가치의 결과를 만들어내기 위해 수행하는 일련의 행동 및 그 변형들의 집합을 말한다.

-> 기능을 명세한다.

지난시간에 요구사항 명세서에서는 기능적 요구사항과 비기능적 요구사항을 명세했다고 했었다. 유스케이스는 기능적 요구사항들을 구체화한 것이다. (기능은 시스템의 경계를 정의한다.)

유스케이스는 프로세스를 묘사한다. 프로세스란 조직이나 액터에게 가치있는 것을 생산하기 위해 필요한 사건, 행동 , 거래의 연속을 말한다. 예를 들어 계좌에서 현금 인출, 제품 주문, 강좌 등록같은 게 있다. 

유스케이스는 시나리오와 헷갈리기 쉽다. 

시나리오는 특정한 목표를 달성하기 위해 수행되는 일련의 프로세스이다. 유스케이스는 주어진 기능에 대해 가능한 모든 시나리오의 집합이다. 

따라서 시나리오는 유스케이스의 하나의 인스턴스(예)가 된다. 

유스케이스의 목적

- 요스케이스는 시스템의 기능 요구사항을 결정하고 기술한다. 이 기능 요구사항은 고객과 소프트웨어 개발자 간의 합의로 귀결된다.

- 유스케이프는 시스템이 무엇을 해야 하는지에 대해 명확하고 일관된 설명을 제공한다. 이것은 개발 프로세스 전반에 걸쳐 이러한 요구사항을 모든 개발자에게 전달하기 위해 사용된다. 

- 유스케이스는 시스템을 검증하기 위한 시스템 테스트를 수행할 수 있는 근거를 제공한다.

- 유스케이스는 기능 요구사항에서 시스템의 실제 클래스 및 오퍼레이션으로 추적할 수 있는 기능을 제공한다.

- 유스케이스 모델을 변경하여 시스템의 변경 및 확장을 단순화할 수 있다.

유스케이스 다이어그램

유스케이스 다이어그램은 외부 액터와 시스템이 제공하는 유스케이스와의 연결성을 다이어그램으로 보여준다.

유스케이스 다이어그램은 사용자 관점에서의 시스템 동작만 설명하고 시스템, 액터, 유스케이스와 같은 모델 요소를 포함하고 있다. 유스케이스에 대한 설명은 일반 텍스트로 기술한다.

유스케이스 모델링은 다음과 같은 절차를 밟는다.

유스케이스 모델링 절차

1. 시스템 정의

2. 액터 찾기

3. 유스케이스 찾기

4. 유스케이스 기술

5. 유스케이스 간의 관계 정의

6. 유스케이스 모델 검증

1. 시스템 정의

시스템이란 개발될 시스템의 경계이다. 시스템은 소프트웨어 시스템, 비즈니스 또는 기계를 말한다. 시스템의 경계와 전반적인 책임을 정의하는 것이 항상 쉬운 것은 아니다.  그러나 기본 기능을 식별할 필요가 있어서 정확한 범주를 설정해야한다. 

2. 액터찾기

액터는 시스템과 상호작용할 때 외부 에이전트가 수행하는 역할이다. 여기서 말하는 외부 에이전트는 사람, 하드웨어 장치 또는 다른 자동화된 시스템이다. 쉽게 생각하면 액터는 시스템의 사용자이다. 

예를들어 은행 시스템에서 사람은 대출 담당자의 역할을 수행할 수 있으며, 동일한 사람이 또한 그곳에 계좌를 가지고 있다면 , 고객 역할을 할 수 있다.

액터는 유스케이스를 수행한다. 액터에는 주 액터와 부 액터가 있는데 주 액터는 주 사용자이고 부 액터는 부 사용자이다. 부 사용자는 시스템이 정상적으로 작동할 수 있도록 유지보수하는 사람을 의미하고 주 사용자는 실제 유저를 생각하면 된다. 

유스케이스를 동작시키는 애들이  하나의 initiating actor(stimulus) 이다.  이는 시스템에 메시지를 보내는 역할을 수행한다. 또한 , 여러개의 participating actors 가 가능하다. 

우리는 액터를 찾기 위해 다음과같은 질문에 답을 해야한다.

- 누가 시스템의 주요 기능을 사용할 것인가? (주 액터)

- 누가 그들의 일상 업무를 수행하기 위해 시스템의 지원을 필요로 하는가?

- 누가 시스템을 유지, 관리 및 시스템의 작동을 지속해야하는가 (부 액터)?

- 시스템에서 처리해야할 하드웨어 장치는?

- 시스템이 상호 작용해야하는 다른 시스템은?

- 누가 시스템이 생성하는 결과에 관심이 있는가?

액터는 중요한 것이 사람, 하드웨어, 소프트웨어가 다 될수 있는데 사람이라하더도 사람 실체(entity)가 아니라 역할(role)이다.

UML 에서의 액터는 액터클래스가 속성과 행위를 둘 다 가질 수 있다.

액터간의 일반화

3. 유스케이스 찾기

유스케이스는 항상 액터에 의해 게시되고, 액터에게 가치를 제공한다. 유스케이스는 완전한 설명이어야 한다. 유스케이스를 너무 작은 유스케이스로 나누지 않아햐 하고, 최종 값이 생성될 때까지 유스케이스는 완전한 게 아니다.

유스케이스 찾기

- 이전에 정의한 액터로부터 시작

   ㅇ액터가 시스템에 요구하는 기능은 무엇인가? 그 액터는 무엇을 해야하는가?

   ㅇ액터는 시스템의 어떤 종류의 정보를 읽거나, 만들거나, 파괴하거나, 수정하거나, 저장하는가?

   ㅇ시스템에서 발생하는 이벤트에 대해 액터에게 알려야 하는가, 아니면 액터가 시스템에 알려야하는 것이 있는가? 이러한 이벤트는 기능 면에서 무엇을 나타내는가?

- 현재의 액터와 관련되지 않는 기타 질문

    ㅇ 시스템에 필요한 입/출력은 무엇인가? 이런 입출력은 어디에서 오거나 어디로 가는가?

    ㅇ 현재 이 시스템의 구현에서 가장 큰 문제점은 무엇인가?

UML 에서의 유스케이스

4. 유스케이스 기술

그림만 보고는 세부적인 것은 모르기 때문에 기능의 세부적인 것을 적어야한다. 

다음과 같은 내용을 기술한다.

- 유스케이스의 목적 ( 궁극적 목표)

- 유스케이스의 시작 방법/ 시기

    - 액터, 상황들

- 액터와 유스케이스 사이의 전형적인 메시지 흐름

- 유스케이스의 대체 흐름 ( 그것들은 너무 자세히 설명하지 않아야함)

- 액터에게 가치를 부여하여 유스케이스를 완료하는 방법/시점

- 참여 액터와의 상호작용 시점

- 텍스트

   - 고객이 이해하고 검증할 수 있도록 명확하고 일관성이 있어야함

   - 복잡한 문장을 피해야함

- 액티비티 다이어그램

유스케이스 템플릿

5. 유스케이스 간의 관계 정의

일반화 (Generalization)

– 자식 유스케이스는 부모의 행위(행동 순서)를 계승

– 자식 유스케이스는 부모 행위의 일부를 우선할 수 있음. 또한 행위 추가 가능

– 부모 유스케이스가 예상되는 곳이라면 어디든 자식 유스케이스를 사용할 수 있음

포함 관계 (Include relationship)

– 다수의 유스케이스가 공통적인 행동을 수행하는 경우, 이러한 행동 은 단일 유스케이스로 모델링 될 수 있으며 이 유스케이스는 다른 유 스케이스에 포함된다

– 유스케이스는 특정 위치에서 다른 유스케이스를 포함할 수 있다

  • 여러 유스케이스에 걸쳐 동일한 이벤트 흐름의 작성을 피하기 위해 사용 (복수 사본 방지용)

  • 포함되는 유스케이스가 그 자체로 완전할 경우

       – 일반적인 유스케이스와 마찬가지로 즉시 사용 가능

       – c.f. 불완전한 경우: 인스턴스화할 수 없는 유스케이스

 • <<include>> 는  함수 호출(function call)과 유사

       – included use case로 제어 이동, included use case 수행 후 제어 복귀

확장 관계 (Extend relationship)

- 한 유스케이스의 확장 지점(extension point)에 액션을 추가하여 다 른 유스케이스로 확장함

– 기본적으로 확장 관계는 일반화 관계와 유사

– 유스케이스는 기반 유스케이스의 지정된 위치에서 추가 행위를 합 병하여 기반 유스케이스를 확장할 수 있다

   • 기반 유스케이스는 독립된 유스케이스로 작용할 수 있다

   • 기반 유스케이스는 확장 지점이라고 불리는 특정 지점에서만 확장할 수 있다

   • 예외에 따라 실행되는 별도의 흐름을 모델링하는 데도 사용됨

   • 조건 확장 (conditional extension):

       – 조건은 불리안 수식

       – 불리안 수식이 참일 때만 확장이 이루어짐

6. 유스케이스 모델 검증

유스케이스 검증 (Testing Use Cases)

– 검증 (verification)

   • 시스템이 올바르게 개발되었는가, 또는 만들어진 명세에 따라 개발되었는가?

   • 구현을 테스트

– 확인 (validation)

   • 시스템이 고객 또는 최종 사용자의 요구를 충족시키는가?

   • 개발 프로세스 초기에 수행 (유스케이스 모델링 후)

– 유스케이스 워크쓰루 (walking the use cases)

   • 역할극: 액터 그룹, 시스템 그룹

   • 역할극에 참여하지 않은 개발자는 메모를 하고 유스케이스에서 결함을 찾으려고 노력한다

   • 몇 가지 대안을 찾을 수 있다

유스케이스 실현

유스케이스 실현 (Realizing Use Cases)

– 유스케이스는 collaboration으로 실현

– 유스케이스 내의 단계와 행동을 클래스, 오퍼레이션 및 이들 간의 관 계로 변환

– 각 단계의 책임을 collaboration에 참여하는 클래스에 할당 (반복 작 업)

요구사항 분석 과정

'어떻게' 보다는 '무엇을' 에 관심을 두어야한다.

1. 도메인 분석 : 문제의 배경가 성격, 범위를 파악한다.

2. 요구사항 추출: 사용자가 소프트웨어에 대해 무엇을 필요로 하는지 도출한다.

3. 분석 및 명세화: 도출된 요구사항을 분석하고 문서로 정리한다.

4. 검토 : 사용자가 요구한 사항과 일치하는지 검토한다.

이제 한 단계씩 살펴보자.

도메인 분석

: 소프트웨어 엔지니어가 문제를 더 잘 이해하기 위해 도메인에 대해 알아가는 과정이다.

도메인이란 소프트웨어를 사용할 것으로 예상되는 고객이 일하는 분야의 비즈니스나 기술을 지칭한다.

도메인 전문가는 소프트웨어가 사용될 도메인 분야에 깊이 있는 지식을 가진 사람으로 대부분은 사용자이자 고객이 된다.

도메인 분석을 수행하면

1. 빠른 개발에 이점이 있다. 

: 이해 당사자들과 더욱 효과적으로 의사소통을 할 수 있어서 빠른 요구사항 파악이 가능하다.

2. 더 좋은 시스템을 구축할 수 있다.

: 고객의 문제를 효과적으로 해결하는 솔류선을 결정할 수 있다.

3. 확장 예견 가능

: 트렌드를 예측하는 능력을 갖춰 적응도 높은 시스템을 구축할 수 있다.

도메인 분석서

도메인 분석서 예시 1

https://ksp.etri.re.kr/ksp/plan-report/file?id=584 

도메인 분석서 예시2

도메인 분석이 끝나면 프로젝트를 착수한다.

프로젝트 착수

문제 정의와 범위 설정

문제란 고객이나 사용자가 직면한 어려움을 지칭한다. 동시에 생산성이나 매출을 높일 수 있는 기회도 뜻한다.

문제의 해결은 일반적으로 소프트웨어의 개발을 필요로한다.

해결을 위해 문제를 정의하고 범위를 설정해야한다.

문제 해결을 위한 좋은 문제 정의서는 짧고 간결해야한다.

범위 설정은 시스템이 해결할 수 있는 모든 일을 상상하여 리스트를 작성한다. 범위가 너무 넓다면 일부는 배제하고 범위가 너무 좁다면 시스템을 사용할 궁극적인 최상위 목표를 파악한다.

예를 들어 대학 수강신청 시스템의 목표는 원할한 수강 신청이다. 

요구사항 추출

요구사항은 제안된 시스템이 무엇을 하는가를 나타낸 문장으로 고객의 문제가 적절히 해결되기 위하여 관련자들이 동의한 것이다.

요구사항은 짧고 간결한 정보로 표현한다.(단순 명료한 그림이나 문장)

요구사항은 시스템이 무엇을 하는가를 나타낸다(시스템이 수행할 작업 기술)

요구사항은 관련자 모두가 동의한 것이다.( 관련자 : 사용자, 고객, 개발자, 관리자)

요구사항은 고객의 문제를 해결하기 위한 것이다.

이러한 요구사항을 모아놓은 것이 요구사항 문서이다.

요구사항에는 기능적 요구사항과 비기능적 요구사항이 있다. 기능적 요구사항은 시스템이 무엇을 하여야 하는가를 기술한 것으로 예를 들어 ATM 시스템은 현금인출, 잔액조회, 계좌 이체, 현금 서비스의 기능적 요구사항을 가진다.

비기능적 요구사항은 개발과정에 고수하여야할 제약 조건으로 성능, 효율, 반응시간, 소프트웨어 품질 특성에 대한 수준을 말한다.

비기능적 요구사항에서는 세가지 주요 유형이 있다.

1. 소프트웨어 품질 측면 :  소프트웨어는 반응 시간(탐색 결과 1초 이내), 처리량,(분당 처리 트랜잭션수) 자원 사용량(시스템이 사용하는 최대 용량)의 측면에서 우수해야하며, 소프트웨어는 신뢰할만 해야한다. 신뢰성이란 시스템이 고장없이 동작할 가능성이다. 또한 소프트웨어는 가용해야한다. 가용성은 시스템이  항상 실행되고 준비된 상태에 있는 시간으로 다운타임(DT(Downtime))이 길면 사용시간이 줄어들기 때문에 이 다운타임이 1분이내여야한다. 또한 고장에서의 회복이 가능해야하고 유지보수성과 확장이 가능해야하며 재사용성이 가능해야한다.

2. 시스템의 환경과 기술적 측면: 우리 마음대로 개발하는 데는 한계가 있다. 사용되는 기술에는 전자 정부 표준 프레임에 맞게 해야 한다. 플랫폼은 시스템이 동작하는 HW, OS 로 생각한다.

3. 프로젝트 계획과 개발 방법에 관한 측면: 사용하는 개발 프로세스에 대한 방법론과 비용, 납기일들이 포함될 수 있다. ( 비용 및 납기일은 시스템 개발 계약서나 별도의 프로젝트 계획서에 명시되어있어야함)

요구사항 추출방법

요구사항을 효과적으로 추출하고 분석하기 위해 체계화된 기술을 사용하자 .

1. 관찰

문서를 읽고 사용자와 함께 요구사항에 대해 논의한다. 잠재적인 사용자들이 수행하는 복잡한 일을 관찰한다. 이때, 사용자가 하는 일을 자세히 설명해 달라고 요청할 수 있다. 비디오 촬영을 해도 된다. 관찰은 많은 시간이 소요된다.

2. 인터뷰

인터뷰는 미리 잘 계획해야지 많은 정보를 얻을 수 있다. 가능하면 많은 당사자와 인터뷰를 진행한다. 인터뷰 시 관련자 이외의 사람과도 인터뷰를 진행하는 것이 좋다. 예를 들면 경쟁 제품 사용자나 마케팅 담당자 등이 있다. 인터뷰는 여유 시간을 할애해야한다.

인터뷰 절차는 { 대상자 선정 -> 일정 계획 -> 질문 작성 -> 인터뷰 -> 분석 및 정리} 의 절차를 가진다.  인터뷰는 (1) 최대, 최소, 예외 규칙, 예상되는 변동 등 자세한 사항까지 질문한다. 예를 들어 업무 프로세스를 구성하는 각단계가 무엇인지, 단계 개수의 변경 여부를 묻고, 설계 단계에서의 확장 가능성을 묻는다. 육하원칙(누가, 언제, 어디서, 무엇을, 왜 , 어떻게) 을 적용해야한다. 그리고 관련자에게 (2) 시스템에 대한 미래 비전을 질문한다. 예를 들어 어떤 융통성을 가져야 할지, 다른 차선의 방법이 있는지, 개발 측이 가지고 있는 대안에 대해 어떻게 생각하는지와 같은 질문이 있다. 또, (3) 문제에 대해 최소한의 허용 가능한 솔루션이 무엇인지 질문한다. 너무 많은 아이디어를 얻으면 사용되지 않을 기능을 생성할 수 있다. 이 때 고객과 사용자가 기본적으로 필요한 것이 무엇인지 확인한다. 

그리고 (4) 다른 정보원에 대해 요청한다. 보고 싶은 문서를 요청하거나 유용한 지식을 지닌 다른 사람을 소개해달라 요청한다.

(5) 다이어그램 작성을 요구한다. 다이어그램을 통해 정보의 흐름, 명령의 순서, 기술이 어떻게 작용하는지 등을 파악한다. 다이어그램은 정보 수집을 촉진하는 좋은 툴이다.

3. 브레인스토밍

브레인스토밍은 아이디어를 낼 목적으로 여러 명으로부터 정보를 얻기 위한 회의이다. 훈련된 요원이 주재를 하는 것이 좋다. 토론보다는 아이디어를 쏟아내는 회의에 가깝고 익명성이 보장된다. 

JAD( Joint Application Development)

- 최종 사용자와 개발자가 시스템 개발 논의, 격리된 장소에서 개발자는 고객과 사용자르 ㄹ만나 요구사항을 정의하기 위해 공동 작업, 집중 브레인스토밍 세션, 요구사항 분석에 필요한 기간을 획기적으로 단축 가능

브레인스토밍 과정

4번 단계에서 토론을 유도핢 질문에는 예를 들어 "이 시스템에서 중요한 기능은 무엇인가?" " 이 시스템에 포함되어야 할 기능은 무엇인가?" " 미래에 어디서 새로운 자료가 발생할 것으로 예상되는가?" "시스템에서 어떤 출력이 생성되어야하는가?" "도메인 모델에서 어떤 클래스가 필요한가?" "고려하지 않을 이슈는 무엇인가?" "이 프로젝트의 리스크는 무엇인가?" 등이 있다.

4. 프로토타이핑

프로토타입은 최종 시스템의 예상 기능 중 일부를 빠르게 구현한 프로그램이다. 가장 단순한 형태로는 paper prototype 이 있다. 페이퍼 프로토타입은 사용자 인터페이스를 종이에 그리고 시스템의 화면을 순서대로 사용자에게 보여주는 형태이다. 아이디어 추출, 피드백 받기에 적합하다. 다수의 개발자가 시스템에 대한 자신의 관점을 병행하여 작성하고 결과를 평가한다.

가장흔한 형태는 mock-up ot the UI 이다. 이것은 프로토타이핑 전용 언어로 작성된다. 컴퓨팅, 데이터베이스 접근, 다른 시스템과의 상호작용은 불가한다.

시스템의 특별한 측면을 프로토타이핑 하기도 한다. 예를들어 알고리즘과 데이터베이스가 있다.

5.  요구사항 문서화

요구사항을 문서화한다. 이 요구사항 문서는 두개의 극단적인 형태가 존재한다. 우선 몇 문단의 글이나 다이어그램으로 요구사항의 아우트라인을 정의한 것으로 요구사항 정의라고 한다. 다음은 수천 페이지의 복잡하고 자세한 명세 리스트로 요구사항 명세서라고 한다.

대규모 시스템을 위한 요구사항 문서는 계층적으로 정리한다.

요구사항 문서를 얼마나 자세히 기술하여야 하는가는 다음 사항을 고려하여 결정한다.

- 시스템의 크기, 다른 시스템에 대한 인터페이스 요구(통신 프로토콜), 목표로 하는 독자(일반 사용자, 전문인), 개발을 위한 계약(외주 계약 , 정부 기고나 계약), 요구 사항 취합 단계(초기 단계 - 시스템이나 서브시스템 개요 간략), 도메인 및 기술에 대한 경험 수준, 요구사항의 오류로 인한 손해 비용

요구사항 문서의 구성

요구사항 검토

요구사항을 검토할 때는 각 요구사항이 다음을 만족하는지 검토한다.

요구사항의 변경 관리

요구사항은 계속 바뀐다. 비즈니스 프로세스가 변경될 수도 있고, 기술이 변경될 수도 있고 문제 이해가 향상될 수도 있다. 이렇게 요구사항을 변경할 시 고려할 사항들이 있다.

요구사항 변경 시 고객 및 사용자와 지속적인 상호작용을 해야한다. 변경으로 인한 이익이 변경 비용을 초과하여야한다. 작은 변화는 적은 비용으로 빠르고 신속하게 가능하나 대규모 변화는 신중하게 접근해야한다. 어떤 변경은 위장된 확장이 가능성일 수도 있다는 점을 인지한다. 변경인지 확장인지를 잘 구분해야한다. 변경이 위장된 확장이어서는 안된다. 시스템 확장은 못하나요? 라는 질문이 있을 수도 있는데 확장은 이미 시스템이 작동하는데 기존 시스템에 새로운 요구사항을 추가하는 것이며 지금은 A라는 소프트웨어 개발하는데 B로 변경하는 문제이므로 확장과 개발은 다르다. 지금은 시스템의 규모를 키우는 것은 피하고 오직 더 좋은 시스템이 되도록 노력한다. 

프로젝트 관리

프로젝트 관리란

프로젝트를 계획하고 수행하는데 필요한 모든 작업을 말한다.

예를 들어 필요한 작업을 결정하거나, 프로젝트에 적합한 인력을 확보하거나, 직무를 정의하고, 일정을 계획하고, 지시, 감독, 기술적 리더, 결정 검토 승인, 모니터링, 통제, 보고, 프로세스 개선, 다른 프로젝트 관리자와 협력 등 모~든 작업을 말한다.

위 내용은 프로젝트 관리 활동들의 비기술적, 기술적 측면을 다 말한 것이고

기술적 측면만 이야기하면

1. 제안서 작성

2. 프로젝트 계획 및 스케줄링

3. 프로젝트 비용, 계획

4. 인력 선발 및 평가

5. 보고서 작성 및 프레젠테이션

으로 이야기할 수 있다. 

앞서 프로젝트 관리는 프로젝트를 계획하고 수행하기 위해 필요한 모든 작업이라고 했었다.

프로젝트를 계획하려면

우선 프로젝트 계획 수립 작업이 필요하다.

-계획 수립은 시간이 많이 걸리는 프로젝트 관리활동이다.

- 초기 개념에서 시스템 제공에 이르기까지 지속되는 활동이다.

- 새로운 정보를 이용할 수 있을때마다 계획을 정기적으로 수정해야한다.

- 주요 소프트웨어 프로젝트 계획을 지원하기 위한 다양한 종류의 계획이 있다. 

      * Quality plan(품질 계획: 품질 확보를 위한 절차 표준 기술), Validation plan(검증 계획 : 시스템 검증 위한 자원및 스케줄 기술)

       * Staff development plan(시스템 개발 인원 관련 플랜) 등등 10여개 이상의 계획 종류가 있다. 각각의 상황에 맞게 플랜을 참조하             면   좋다.  소규모 프로젝트는 이러한 플랜들을 다 적진 않지만 대규모 프로젝트는 개발에 앞서 여러 종류의 계획을 다 작성해야한다.

다음은 프로젝트의 기술적으로 수행해야할 관리활동은

1. 개발 노력 추정

2. 일정 관리

3. 인력 관리

4. 위험분석

크게 4가지를 거쳐야한다. 이 활동들은 아래에서 하나하나 살펴보자.

1. 프로젝트 개발 노력 추정

프로젝트 개발 노력 추정 시 고려 사항

개발 노력 추정 시 두 가지 모델이 주로 사용된다.

1. 기능 점수 모델

- 논리적 설계를 기초로 사용자에게 제공되는 소프트웨어의 기능을 정량화하여 소프트웨어의 규모ㅗ 산정

- 데이터 관리 위주의 소프트웨어에 적합

- 조직에 관계없이 애플리케이션 복잡도 계산의 일관성 제공

- 프로그래밍 언어와 무고나하게 객관적인 복잡도 산정이 가능

- 기능 점수 산정 절차

  - 기능 점수 모델 : UFP(Unadjusted Function Point) 산정

      - 다섯 가지 소프트웨어 구성요소 : 외부 입력, 외부 출력, 외부 질의, 내부 논리 파일, 외부 인터페이스 파일 

                                                          => 이 다섯 요소의 가중치를 계산하여 UFP 를 계산한다.

    - 기능 점수 모델 : VAF (Value Adjustment Factor) 산정

      - 14개 기술적 분야에 대한 복잡도를 고려하여 0-5의 점수 부여 : 데이터 통신, 분산 데이터, 성능 중요도, 과중한 하드웨어 사용, 높은 트랜잭션 비율, 온라인 데이터 입력, 온라인 업데이트, 이식성, 재사용성, 오퍼레이션 용이성, 설치 용이성, 유지보수성, 복잡한 계산, end-user 의 효율

   - 기능 점수 모델 : AFP (Adjusted Function Point) 산정

         - AFP(FP) = UTP * TCF 

        - 노력 추정 = (w FP) / (y FP/1MM) = z MM

               - FP/1MM : 개발 팀의 생산성 (개발자 1인이 1개월에 개발할 수 있는 평균 FP)

2. 객체 점수 모델

- 객체 지향 시스템을 개발할 때 객체를 기초로 한 추정 방법이다.

 1. 문제 도메인에 있는 클래스 개수 추정( Cc) : 요구 분석과 UML 모델링을 통해 추정

 2. 사용자 입력의 종류 분류 및 가중치 부여(Wi)

    - UI 없음:2.0  / 단순한 텍스트 UI:2.25 / 복잡한 UI : 3.0 / 그래픽 UI 2.5

 3. 최종 클래스 개수 (TCc) = Cc * Wi + Cc

 4. Effort = TCc * MD (MD : 클래스 하나를 개발하는데 소요되는 생산성 추정 값)

2. 프로젝트 일정 관리

프로젝트 일정 관리를 위한 프로세스들 먼저 알아보자.

프로젝트 일정 관리 프로세스

- 활동 정의

   : WBS 에서 정의한 활동을 달성하기 위해 구체적인 활동 식별

- 활동 순서 정의

  : 활동 간의 논리적인 순서 관계를 정의

- 활동 자원 추정

  : 개별 활동의 수행을 위해 필요한 자원을 추정

- 활동 기간 추정

  : 개별 활동을 완료하기 위해 필요한 작업 기간을 추정

- 일정 계획 수립

  : 개별 활동의 순서, 기간 및 필요한 자원 등을 분석하여 일정을 작성

- 일정 통제 

  : 계획 대비 일정 차이를 모니터링하여 필요한 조치를 취함

우선 과정에 대한 학습 전에 관련 배경 지식을 정리를 해보자

프로젝트에서의 활동(Activity)은

관리 측면에서 진행 상황을 판단할 수 있도록 가시적 산출물을 생산하도록 조직되어야한다.

여기서 중요한 개념인 마일스톤은 이정표란 뜻으로 프롲게트 진행 과정에서 중요한 이벤트 또는 활동의 완료 시점을 나타낸다. 

Dliverable 은 산출물이란 의미로 고객에게 제공되는 프로젝트 결과물이다.

프로젝트 일정 관리를 위해선 일련의 프로세스를 거쳐야 한다.

1. 일정 계획을 수립한다.

: 개발 프로세스를 이루는 활동을 파악하고 순서와 일정을 정하는 작업이다. 

산출물 생산에 소요되는 작업을 결정하고 작업의 예상 시간을 결정하고 작업의 종속 관게(선행 작업)을 파악해야한다.

이를 위해선 PERT/CPM 차트를 활용할 수 있다.

PERT/CMP차트는

Program Evaluation and Review Rechnique/Critical Path Method 이다.

세분화된 작업을 효율적으로 일정 관리하고 지원하기 위한 기법으로 관리에 대한 작업도 포함할 수 있다.

여기서는 작업 시간을 정확하게 예측학는 것이 중요하다.

PERT/CPM 차트는 다음과 같은 장점을 가진다.

- 관리자의 일정 계획 수립에 도움이 된다.

- 프로젝트 안에 포함된 작업 사이의 관계를 표현할 수 있다.

- 병행 작업 계획을 세울 수 있다.

- 일정 시뮬레이션이 가능하다.

- 일정 점검, 관리가 가능하다.

예를 들어 다음과 같은 작업들이 있다고 하자.

작업의 소요시간과 의존성을 나타낸 표이다.

이에 대해 아래와 같은 PERT/CPM 차트를 작성할 수 있다. 

그 후 임계 경로를 구한다. 임계 경로란 Critical Path 로 Pert Chart 에서 소요 시간이 가장 긴 경로이다. 프로젝트를 완수하기 위해 필요한 최소시간을 나타낸다.

위 예시에서는 

간트차트 

간트 차트는 활동 별로 작업의 시작과 끝을 나타낸 그래프이다.

가로축에는 시간 세로축에는 작업이 나오고 마일스톤은 마름묘 표사, 파란색 막대는 여유시간을 의미한다.

간트 차트는 계획 대비 진척도를 표시할 수 있으며 개인별 일정표를 표시할 수 있다.

https://create.microsoft.com/ko-kr/templates/gantt-%EC%B0%A8%ED%8A%B8

마이크로소프트에선 여러 간츠 엑셀파일을 제공한다. 앞으로의 프로젝트에서 활용해야 겠다.

개발 프로세스란

프로젝트를 소규모 작업으로 구성하는 일반적인 접근 방법으로 관리자와 팀원들이 작업의 순서를 결정하는데 도움이 된다.

모델은 작업 방식을 엄격하게 규정하기 보다는 생각하는 데 도움이 되어야한다.

각 프로젝트는 고유의 계획을 가지고 진행되어야하는데 이때 필요한 것이 개발 프로세스이다.

즉흥적인 개발 프로세스

일련의 개발 절차를 개발 프로세스라고 할 때 좋은 엔지니어링 과정을 따르지 않으면 어떻게 될까?

예를 들어 집을 짓는다고 하자. 방은 몇개고 배치는 어떻게 하고, 화장실은 몇개고 이런 것을 정하기만 하고 바로 집을 지을 순 없다. 사용자가 만족할만한 집을 짓기 위해선 충분한 요구사항을 수집한 다음에 그러한 요구사항을 바탕으로 프로토타입을 만들고 고객에게 보여줘야한다. 그 후 구체적인 설계작업에 들어간다. 설계 작업이 끝나면 설계서가 나온다. 이를 시공업자에게 넘기면 시공업자가 집을 만들 것이다.

만약 이러한 엔지니어링 과정을 따르지 않는다면

- 구현하기 전에 요구나 설계 등의 중요성을 인식하지 못할 수 있다.

- 설계가 잘되지 않는다면 소프트웨어의 질이 떨어질 수 있다.

- 계획이 없음으로 인해 목표 없이 일하게 된다.

- 체계적인 테스트나 품질 보증 같은 작업의 필요성을 간과하게 된다.

- 이상의 이유로 개발과 유지보수 비용이 증가한다.

소프트웨어란 프로그램의 개발, 운용, 보수에 필요한 관련 정보 일체를 뜻한다

소프트웨어가 복잡해질수록 설계가 중요해진다.

소프트웨어의 특징을 알아보자

소프트웨어 특징

1. 손에 잡히지 않는다(intangible) (invisible)

- 개발 작업을 이해하기 어렵고, 소프트웨어의 구조를 파악하기 쉽지가 않다. 구조를 파악하기 어려우면 구조를 망가뜨리기도 쉽다. 이 점이  소프트웨어의 어려운 점이다.

2. 대량 생산하기 쉽다 (reproducible)

- 비용의 대부분이 개발 과정에 소요된다. 건축과 같은 다른 엔지니어링은 생산(제조) 단게의 비용이 크나 소프트웨어는 개발 과정에 소요된다. 따라서 한 번 개발을 한 후 최종 산출물이 만들어지면 그 다음 카피를 만들어내는 것은 쉽다. 개발 비용만 들고 생산 비용은 들지 않기 때문에 대량 생산이 쉽다는 강점을 가진다. 

3. 노동 집약적(laobr-intensive) 

- 자동화하기 어렵다. 노동집약적이라는 말은 "1차산업" "2차산업" 과 같은 단어를 지칭할 때 많이 쓰이는 말이다. 소프트웨어 또한 노동집약적이라고 할 수 있다. 소프트웨어는 이에 대한 많은 교육을 받은 사람들이 산업에 투입된다. 따라서 여러 고용이 이루어지는 고부가가치 산업이다.

4. 잘 훈련 받지 않으면 제작하기 어려움

- 앞서 설명했듯이 소프트웨어는 복잡하고 정교한 시스템이기에 훈련을 잘 받은 사람만이 제작할 수 있다. 잘 훈련받지 않으면 품질 문제를 인식하기 어렵고 객체 지향, 컴포넌트, 분산 시스템 등의 여러 기술 사용이 어렵다.

5. 쉽게 변경 가능하다.

- 완전한 이해 없이 변경할 수 있다. 다만 변경을 가하면서 구조 전체가 망가질 수도 있다.

6. 닳아 없어지는 것이 아님.

소프트웨어는 잘 만들어지면 계속 쓸 수 있다. 플라스틱과 같은 자원은 닳을 수도 있지만 소프트웨어는 그렇지 않는다.

다만 설계 변경으로 인해 품질이 저하되거나 노후화 될 수는 있다. 예를 들어 오류를 발생하거나 소프트웨어가 복잡해질 수 있다. 

이번에는 소프트웨어의 종류를 살펴보자

소프트웨어 종류

1. 주문형 소프트웨어

- 특정 고객의 수요를 만족하기 위하여 개발된 소프트웨어이다.

ex) 항공 교통 제어 시스템, 재정관리 시스템, 학사정보관리 시스템

순수한 소프트웨어

2. 패키지 형(범용) 소프트웨어

- 공개된 시장에서 판매되는 소프트웨어이다.

COTS(Commercial Off-The-Shelf) 또는 Shrink-wrapped 라고도 불리어진다. 

ex) MSWord, MS-PowerPoint

순수한 소프트웨어

3. 임베디드 시스템

- 하드웨어에 탑재된 소프트웨어이다. 변경이 어렵다.

소프트웨어에서 상당히 핫한 분야이다. ex) 자동차 SW / 장난감, 세탁기 등에 들어가는 SW

SW+HW

소프트웨어는 다른 관점으로도 분류할 수 있다.

1. 실시간(Real-time) 소프트웨어 : 제어, 모니터링 소프트웨어로 신속하게 반응해야하며 안정성 확보가 중요함

2. 자료처리 소프트웨어 : 비즈니스 업무 처리에 사용되며 자료의 정확성, 보안이 관건이다. 일괄 처리한다.

( 두 가지 성격을 동시에 지니는 S/W 도 있음)

소프트웨어 공학이란 무엇일까?

소프트웨어 공학은

고객의 문제를 해결해 주기 위하여 대규모의 품질 좋은 소프트웨어 시스템을 정해진 시간과 비용으로 개발하거나 발전시키는 체계적인 프로세스이다.

고객의 문제를 해결하는 것이 소프트웨어 공학의 궁극적인 목표라고 할 수 있다. 문제를 해결하기 위해선 꼭 개발하지 않고, 솔루션을 구매할 수도 있다. 고객의 문제를 해결해야하므로 고객이 필요로하지 않는 불필요한 기능을 추가하는 것은 문제 해결에 도움이 되지 않는다. 문제를 파악하고 이해하기 위해 효과적으로 커뮤니케이션하는 것이 중요하다.

체계적인 개발과 발전을 위해선 표준을 따르고 공학적 프로세스를 따라야한다. 표준은 예를들면 ISO, IEEE.. 같은 표준을 말한다.

공학적 프로세스란 잘 이해하고 있는 기술을 조직화되고 훈련된 방식으로 적용하는 것이다. 대부분의 개발 작업은 진화적 개발이다.

 또한 대규모의 고품질 S/W 시스템을 만들어야한다. 개발에는 많은 시간과 노력이 필요하므로 고품질의 시스템을 만들어야 한다. 이 과정에서는 팀워크와 협동이 필요하다. 한 사람이 완전하게 이해하고 완성할 수 없기 때문에 엔지니어링 기술이 필요한 것이다. 작업의 분할과 시스템의 각 부분이 잘 작동하느냐가 관건이 된다. 

 비용, 시간, 기타 제약이 존재함을 인지해야 한다. 대부분의 소프트웨어 개발은 한정된 자원을 사용한다. 따라서 얻는 이익은 비용을 초과해야하며 더 빠르고 값 싸게 개발하여야한다. 대부분의 프로젝트는 비용과 시간의 부정확한 예측으로 실패로 끝나기도 한다.

 '소프트웨어 엔지니어링'

용어는 1968년 NATO conference 에서 처음 언급되었다. 소프트웨어 개발에 엔지니어링의 원리가 도입되어야 함을 처음으로 인식하였다. 초창기에는  소프트웨어 개발자가 자신이 만든 프로그램을 다른 사람이 이해하지 못하면 뿌듯해했다. 그러나 만들어진 코드를 내가 보고도 이해못하는 문제가 발생하였다. 또한 대규모 소프트웨어를 만들기 시작하면서 공학적 접근 방식의 필요성이 제기되었다.

 엔지니어링은 공공을 보호하기 위해 자격증 제도가 필수이다. 그러나 소프트웨어에서는 의사나 변호사들 처럼 필수까지는 아니다. 없는 것보단 있는 게 낫지만..

엔지니어의 설계 작업은 수학, 과학, 경제 등의 원리를 적용할 수 있도록 충분한 연습을 필요로 한다. 뿐만 아니라 도덕적 윤리 의식도 필수적이다. 

IEEE : 소프트웨어의 개발, 운용, 유지보수 및 파기에 대한 체계적인 접근 방법

W.Humphrey : 질 좋은 소프트웨어를 경제적으로 생산하기 위해서 공학, 과학, 수학적 원리에 의하여 소프트웨어를 개발하는 것

목표: 품질 좋은 소프트웨어를 최소의 비용으로 계획된 일정에 맞춰 개발하는 것

소프트웨어 공학 관련자

1. 사용자(유저) : 소프트웨어를 사용하는 사람들

2. 고객(customer) : 소프트웨어에 대해 비용을 지불하는 사람

3. 소프트웨어 개발자 : 요구분석가, 데이터베이스 전문가, 기술문서 작성자, 프로그래머, 테스트엔지니어, QA 엔지니어

4. 개발관리자 : 프로젝트 관리 및 비즈니스 경영하는 사람

소프트웨어 품질

소프트웨어에도 품질이 있다. 

몇 가지만 살펴보도록 하자.

1. 사용용이성 (usibility) 

빨리 배우고 작업을 쉽게 할 수 있는 특성이다. 상업용 시스템에서는 굉장히 중요하다. 기능이 잘 동작하는지만 생각하는 것이 아닌 쉽게 작업할 수 있도록 해야한다. 

2. 효율성 ( efficiency)

CPU 시간과 메모리 같은 자원을 효율적으로 사용할 수 있는 특성이다. 적절한 자료구조의 사용이 중요하다.

3. 신뢰성(reliability)

요구한 기능을 실패없이 수행할 수 있는 특성이다. 이 소프트웨어가 오류 없이 동작하는지에 관한 문제이다. 오류를 찾고 없애는 과정에 노력이 들어가야 신뢰성을 높일 수 있다.

4. 유지보수성(maintainability)

유지 보수를 쉽게 수행할 수 있는 특성이다. 소프트웨어는 한 번 개발된 후 발전을 겪게 된다. 이러한 유지 보수를 쉽게 할 수 있어야 한다. 

5. 재사용성(reusability)

부품이 다른 프로젝트에서 사용될 수 있는 특성이다. 소프트웨어를 한 덩어리를 크게 만들어놓으면 다른 데서는 사용되기 어렵다. 만약 모듈화해서 만들어놓으면 다른 데서도 사용되기 쉽다.

 이러한 품질들은 상충되는 경우도 있다. 예를 들어 효율성을 높이면 유지보수성이나 재사용성이 낮아질 수 있다. 유지보수성이 높다는 것은 여러 모듈, 컴포넌트로 나누는 것을 의미한다. 기능을 개선하려면 어떤 모듈을 다른 모듈로 대체해야한다. 이러다 보면 모듈의 개수가 늘어날 수 있다.따라서 효율성을 개선하면 유지보수성이나 재사용성은 낮아질 수 있고 사용용이성을 높이면 효율성이 낮아질 수 있다.

 품질들은 상충되는 경우도 있고 관계자에 따라 중요하게 여기는 품질 관점도 다르기 때문에 품질의 목표설정이 중요한 작업이 된다. 목표를 설정한 후 이에 맞게 설계해야한다. 이에 따라 자원을 과다하게 낭비하는 엔지니어링은 피해야한다. 

또 품질을 위해선 때때로 최적화가 필요하다. 한정된 예산으로 최대의 효율/ 신뢰도를 얻기 위해서이다.

소프트웨어 품질 관점

1. 고객 : 고객입장에서는 받아들일 만한 비용을 지불해서 문제를 해결할 수 있는지가 문제

2. 사용자 : 배우기 쉽다. 효율적이다. 일을 끝내는데 도움이 된다.

3. 개발자 : 디자인하기 쉽다. 유지보수가 쉽다. 재사용이 쉽다.

4. 개발관리자 : 더 많이 팔고 비용이 적게 들어야한다.

단기/ 장기 품질

1. 단기적 품질 : 고객의 당면 문제, 요구사항을 만족하고 있는가, 현재 처리할 자료의 분량을 효율적으로 처리할 수 있는가

2. 장기적 품질 : 유지보수성, 고객의 미래 요구

소프트웨어 프로젝트 유형

소프트웨어 프로젝트 작업

- 요구분석과 명세화

 : 도메인 분석, 문제정의 , 요구 추출(가능한 많은 소스에서 입력을 취함), 요구 분석(정보를 분석하고 정리), 요구 명세화(소프트웨어가 어떻게 작동하는지에 대한 자세한 사항을 기술)

- 설계

 : 요구사항이 가용한 기수롤 어떻게 구현되어야 하는지를 기술

 : 중요 기술 

 - 시스템 엔지니어링, 소프트웨어 아키텍처 , 서브시스템의 내부에 대한 상세 설계, 사용자 인터페이스 설계, 데이터베이스 설계

- 모델링

 : 요구사항 명세 ~> 설계 과정에서 등장함. 도메인이나 소프트웨어의 표현을 만들어나가는 과정이다.

 : 유스케이스 모델링, 정적 모델링, 동적 모델링, 행위 모델링

- 프로그래밍

- 품질 보증

  :  테스트 - unit test , integration test, system test

      리뷰 인스펙션

- 배포

- 프로세스 관리