소프트웨어 설계 - 1

소프트웨어 설계 - 1

1. 플랫폼 성능 특성

(1) 플랫폼 성능 특성 분석 기법

분석기법	내용
사용자 인터뷰	현행 플랫폼 사용자 인터뷰를 통해 속도의 적정성을 확인하여 인터뷰 결과서를 도출.
성능 테스트	현행 플랫폼을 대상으로 성능/부하 테스트를 수행하여 결과서를 도출.
산출물 점검	현행 플랫폼과 유사한 타 제품의 성능 자료를 분석하여 벤치마킹 테스트 결과서를 도출.

(2) 플랫폼 성능 특성의 측정 항목

| 구분 | 내용 | | —- | —- |

:반환시간:(Turnaround Time)	작업을 요청한 시간부터 처리가 완료될 때까지 걸린 시간을 의미한다.
:사용률:(Utilization)	작업을 처리하는 동안 CPU(중앙처리장치), 메모리 등의 자원 사용률을 의미한다.
:응답시간:(Response Time)	요청을 전달한 시간부터 응답이 도착할 때까지 걸린 시간을 의미한다.
:가용성:(Availability)	시스템에서 제공되는 서비스가 다운되지 않고 정상적으로 유지되는 시간을 의미한다.

---

2. 요구사항

(1) 요구사항의 정의

1. 요구사항은 시스템에 대한 고객의 요청을 확정한 것으로, 이해 당사자와의 의사소통과 이해가

   필요하다.

2. 요구사항은 어떤 문제를 해결하기 위한 조건이나 제약조건으로, 소프트웨어 개발 전 과정에

   필요한 기준과 근거를 제공한다.

(2) 요구사항의 분류

요구사항은 기능적 요구사항과 비기능적 요구사항으로 나눌 수 있다.

• 기능적 요구사항
  • 시스템이 외형적으로 보여주는 기능과 동작
  • 사용자의 외부 요소들 간의 상호작용
  • 업무 절차나 입출력에 대한 요구
  • 쉽게 파악되고 사용 사례로 정리

ex ) ATM 기기의 입 • 출금 작업

• 비기능 요구사항
  • 시스템이 제공하는 기능에 직접 관련되지 않는 요구
  • 시스템에 대한 다양한 제약 조건
  • 성능, 품질, 보안, 안전, 인터페이스 등의 요구사항
  • 파악하기가 어렵고 품질 속성 시나리오로 정리

ex) ATM 기기의 응답 속도, 가동률

(3) 요구 도출

1. 사용자의 요구사항이 무엇인지 개발 관련자들이 기능적/비기능적 요구사항을 추출하는 과정
2. 다양한 요구사항을 도출하기 위해서 이해 당사자와의 의사소통과 이해를 필요로 한다.

인터뷰	개발 관련 이해 당사자와 일대일 직접 대화를 통해 요구사항 수집
설문조사	사용자가 다수이고, 지역이 분산되어 있을 때 간접적으로 요구사항 수집
워크숍	여러 사람들이 한 장소에 모여 의견을 교환하여 단기간에 요구사항 수집
프로토타이핑	프로토타입(견본)을 만들고 평가를 받으며 사용자의 요구사항을 수집
브레인스토밍	회의 참석자들이 자유롭게 아이디어를 제시하여 요구사항을 수집
유스케이스	사용 사례 분석으로 사용자 요구사항을 기능별로 구분하여 수집
JAD	개발자와 사용자가 만나서 요구사항 도출을 위한 공동 작업을 수행

(4) 요구 분석

1. 소프트웨어 개발의 실질적인 첫 단계로 사용자 요구에 대해 이해하는 단계이다.
2. 도출한 요구의 타당성을 조사하고 비용, 일정 등의 제약을 설정한다.
3. 요구 분석의 결과는 소프트웨어 설계의 기본 자료로 사용된다.
4. 요구 분석 기법은 구조적 분석, 객체지향 분석으로 구분된다.
5. 요구 분석시 필요한 기술
   • 청취와 인터뷰 질문 기술 : 요구사항 도출 단계의 면담, 설문, 브레인스토밍 등에서 필요
   • 분석과 중재 기술 : 요구사항 분석 기법의 개념 모델링에서 필요
   • 관찰 및 모델 작성 기술 : 요구사항 분석 기법의 정형 분석과 요구사항 협상에서 필요

(5) 요구 명세

1. 요구 분석의 결과를 바탕으로 요구 모델을 작성하고 문서화 하는 활동이다.
2. 기능 요구사항은 빠짐없이, 비기능 요구사항은 필요한 것만 기술한다.
3. 소단위 명세서를 이용해 사용자가 이해하기 쉽게 작성한다.
4. 요구 명세 기법은 정형 명세와 비정형 명세로 구분된다.

🔲 요구사항 명세 속성

구분	내용
정확성	요구사항은 정확해야 한다.
명확성	단 한 가지로 해석되어야 한다.
완전성	모든 요구사항(기능, 비기능)이 표현되어야 한다.
일관성	요구사항 간 충돌이 없어야 한다.
수정 용이성	요구사항의 변경이 가능해야 한다.
추적성	제안서 등을 통해 추적이 가능해야 한다.

🔲 요구사항 명세 기법

구분	정형 명세	비정형 명세
기법	수학적 기반/모델링 기반	상태/기능/객체 중심 명세 기법, 자연어 기반
종류	Z, VDM,Petri-Net, CSP, LOTOS	FSM, Decision Table, ER 모델링, SADT, UseCase
장점	시스템 요구 특성의 정확, 명세 간결	명세 작성 이해 용이, 의사전달 방법 다양성
단점	낮은 이해도, 이해관계자의 부담 가중	불충분한 명세 기능, 모호성

(6) 요구 검증

1. 요구사항이 고객이 원하는 시스템을 제대로 정의하고 있는지 확인하는 과정이다.
2. 요구사항에 자원이 배정되기 전에 문제 파악을 위한 검증을 수행해야 한다.
3. 요구사항이 실제 요구를 반영하는지, 문서상의 요구사항은 서로 상충되지 않는지 등 점검
4. 일반적으로 요구사항 관리 도구를 이용해 산출물에 대한 형상 관리를 수행한다.

---

📍 요구 도출 → 요구 분석 → 요구 명세 → 요구 검증

---

3. 구조적 분석

(1) 자료 흐름도 (Data Flow Diagram, DFD)

1. 자료 흐름도는 가장 보편적으로 사용되는 시스템 모델링 도구로서 기능 중심의 시스템을 모델링하는데 적합.
2. DeMarco, Youdon 에 의해 제안되었고, 이를 Gane, Sarson이 보완하였다.
3. 자료 흐름도의 구성 : 프로세스, 자료 흐름, 자료 저장소, 단말

프로세스(Process): 원

데이터 흐름도(Data Flow): 화살표

자료 저장소(Data Store): 직선(단선/이중선)

단말(Terminator): 사각형

(2) 자료 사전

자료 사전은 개발 시스템과 연관된 자료 요소들의 집합이며, 저장 내용이나 중간 계산 등에 관련된 용어를 이해할 수 있는 정의이다. 자료 사전은 다음과 같은 작업에 의해 자료 요소를 정의한다.

자료 사전 기호	의미
=	항목의 정의(~로 구성되어 있다)
+	그리고, 순차
( )	선택사양, 생략 가능(Optional)
{ }	반복(iteration)
[	]	여러 대안 중 하나 선택
* *	주석(comment)

(3) 프로세스 명세서

1. 자료 흐름도의 계층상에서 최하위 단계, 즉 더이상 분해할 수 없는 단계의 버블은 원시 버블 또는 프리미티브 버블(primitive bubble)이라 부르며, 그 처리 절차를 기술하는 것을 프로세스 명세(process specification)라 하고, 모델링한 결과를 명세서라고 한다.
2. DeMarco는 프로세스 명세서를 미니스펙이라 함.
3. 자료 흐름도상의 최하위 처리를 정밀하게 다룬다.

info-process 카테고리 내 다른 글 보러가기