1. 요구사항 확인

계획 → 분석 → 설계 → 구현 → 시험/디버깅 → 인수인계 → 운영/유지보수

✅ 현행 시스템 분석

1. 현행 시스템 파악

(1) 현행 시스템 파악의 개념

• 개발하고자 하는 응용 소프트웨어에 대한 이해를 높이기 위해 현행 시스템의 적용 현황을 파악함으로써 개발 범위와 향후 개발될 시스템으로의 이행 방향성을 분석할 수 있다.

💡 시스템
목적을 달성하기 위하여 구성 요소들이 상호 유기적으로 구성된 집합체를 의미

(2) 현행 시스템 파악 절차

[1단계]

• 구성/기능/인터페이스 파악
  • 시스템 구성 현황 파악
  • 시스템 기능 파악
  • 시스템 인터페이스 현황 파악

[2단계]

• 아키텍처/소프트웨어 구성 파악
  • 아키텍처 파악
  • 소프트웨어 구성 파악

[3단계]

• 하드웨어/네트워크 구성 파악
  • 시스템의 하드웨어 현황 파악
  • 네트워크 구성 파악

💡 현행 시스템 파악의 규칙

1. 일관성을 유지할 것시작, 중간, 종료가 분명하도록 설계할 것
2. 오류 처리 기능을 간단히 할 것
3. 단순화시켜 기억의 필요성을 줄일 것
4. 단축키를 제공할 것

💡 현행 시스템의 분석 종류

1. 플랫폼 기능 분석
2. 플랫폼 성능 특성 분석
3. 운영체제 분석
4. 네트워크 분석
5. DBMS 분석
6. 비즈니스 융합 분석

2. 플랫폼 기능 분석

(1) 플랫폼의 개념

• 다양한 종류의 시스템이나 서비스를 제공하기 위해 공통적이고 반복적으로 사용하는 기반 모듈
• 일종의 토대라고 할 수 있음
• 일반적으로 응용 프로그램을 구동시키는 데 사용되는 하드웨어와 소프트웨어의 결합이라고 할 수 있다.

(2) 플랫폼의 기능

• 소프트웨어의 개발 및 운영 비용을 감소
• 소프트웨어 개발의 생산성을 향상
• 동일한 플랫폼 간 커뮤니티를 형성하여 네트워크 효과를 유발 → 네트워크 효과? 플랫폼 간의 상호작용이 늘어나면서 제품의 사용가치가 높아지는 것으로, 가치상승효과이다.

💡 컴퓨터 시스템의 구성 요소

1. 입력
2. 처리
3. 출력
4. 피드백
5. 제어

(3) 플랫폼의 종류

구분	내용
하드웨어 플랫폼	표준 기술을 통하여 다양한 제품을 만들 수 있는 기술 도구 예 ) 데스크톱, 메인프레임 등
소프트웨어 플랫폼	소프트웨어를 쉽게 개발 및 구동하기 위한 기술 도구 예 ) 윈도우, 리눅스, 안드로이드
서비스 플랫폼	다양한 서비스를 제공할 수 있는 기술 환경 예 ) 트위터, 페이스북 등

(4) 플랫폼 기능 분석 절차

[1단계]

• 현행 플랫폼 자료 수집

[2단계]

• 수집 자료 분석

[3단계]

• 결과 산출물 작성

3. 플랫폼 성능 특성 분석

(1) 플랫폼 성능 특성 분석의 개념

• 현재 사용하는 플랫폼의 성능을 분석해야(하드웨어 교체 등) 객관적인 성능 평가를 제시할 수 있고, 사용자에게 안정적 서비스를 제공할 수 있다.
• 일반적으로 성능 평가는 초기 조건과 종료 조건을 설정하고, 여러 개의 파라미터를 측정하여 수행

💡 파라미터 = 인수 = 인자 = 매개변수
- 사용자가 원하는 방식으로 자료가 처리되도록 하기 위하여 명령어를 입력할 때 추가하거나 변경하는 수치 정보를 의미

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

• 사용자 인터뷰
• 성능 테스트
• 산출물 점검

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

구분 내용

구분	내용
반환 시간 (Turnaround Time)	작업을 요청한 시간부터 처리가 완료될 때까지 걸린 시간을 의미 → 작업의 완료 시간
사용률 (Utilization)	작업을 처리하는 동안 CPU(중앙처리장치), 메모리(주기억장치) 등의 자원 사용률을 의미 → 높을 수록 좋음 CPU나 메모리가 놀지 않고 계속 움직여주는 것
응답 시간 (Response Time)	요청을 전달한 시간부터 응답이 도착할 때까지 걸린 시간을 의미 → 작업이 처음 실행되기까지 걸린 시간
가용성 (Availability)	시스템에서 제공되는 서비스가 다운되지 않고 정상적으로 유지되는 시간을 의미

4. 운영체제 분석

(1) 운영체제(OS : Operating System)의 개념

• 컴퓨터의 제한된 각종 리소스(자원)을 효율적으로 관리/운영함으로써 사용자에게 편리성을 제공하고자 하는 인간과 컴퓨터 사이의 인터페이스(소통)를 위한 시스템 소프트웨어

💡 인터페이스(Interface)
- 서로 다른 두 개의 시스템, 장치 사이에서 정보나 신호를 주고받는 경우의 접점이나 경계면이라 할 수 있다.
즉, 사용자가 기기를 쉽게 동작시키는 데 도움을 주는 시스템을 말한다.

(2) 운영체제의 구성

• 제어 프로그램(Control Program)
  • 컴퓨터 전체의 동작 상태를 감시/제어하는 기능을 수행

  감시 프로그램 제어	제어 프로그램의 중추적 기능을 담당하는 프로그램, 처리 프로그램의 실행 과정과 시스템 전체의 동작 상태를 감독하고 지원하는 프로그램
  데이터 관리 프로그램	- 컴퓨터에서 취급하는 각종 파일과 데이터를 표준적인 방법으로 처리할 수 있도록 관리하는 프로그램 그룹을 의미 - 주기억장치와 보조기억장치 사이의 데이터 전송, 파일의 조직 및 활용, 입출력 데이터와 프로그램 논리의 연결 등을 담당한다.
  작업 관리 프로그램	어떤 업무를 처리하고 다른 업무를 자동적으로 이동하기 위한 준비 및 완료 처리를 담당하는 기능을 수행한다
  통신 제어 프로그램	통신 회선을 경유하는 터미널과 중앙의 컴퓨터 사이에서 데이터를 주고받는 경우 또는 컴퓨터에서의 데이터를 송수신하는 경우에 사용되는 프로그램

• 처리 프로그램(Processing Program)
  • 제어 프로그램의 감시 하에 특정 문제를 해결하기 위한 데이터 처리를 담당하는 프로그램
  
  

  언어 번역 프로그램	컴퓨터 언어로 작성된 프로그램을 시스템이 이해할 수 있는 기계어로 바꾸어 주는 프로그램으로, 컴퓨터 언어의 종류에 따라 각각의 언어 번역 프로그램을 갖고 있다.
  서비스 프로그램	컴퓨터 사용에 있어 공통으로 사용 빈도가 높은 기능을 미리 프로그램으로 작성하여 사용자에게 제공함으로써 사용자의 시간 및 노력을 경감시키고 업무 처리 능력을 향상시킬 수 있다
  사용자 정의 프로그램	사용자가 업무상의 문제를 컴퓨터로 처리하기 위해 작성한 프로그램

(3) 운영체제의 종류

유닉스(UNIX)	AT&T사에서 개발하여 멀티 태스킹이 가능하고 다중 사용자 환경을 지원하는 운영체제 → 유닉스 운영체제는 컴퓨터 서버, 워크스테이션, 휴대용 기기 등에서 사용됨
리눅스(Linux)	1991년 리누스 토발즈에 의해 유닉스를 기반으로 만들어졌으며, 소스 공개를 원칙으로 하기 때문에 무료 사용이 가능
윈도우(Windows)	안정적이고 표준화된 GUI(그래픽 사용자 인터페이스)를 갖추고 있는 운영체제로 PC, 중소 규모 서버, 태블릿 PC 등에서 사용
모바일 운영체제의 종류	Android, iOS

💡 GUI(Graphical User Interface)
- 사용자가 컴퓨터와 정보를 교환할 때, 그래픽을 통해 조금 더 용이하게 작업할 수 있는 환경 마우스 등을 이용하여 화면에 있는 메뉴를 선택하여 작업함

(4) 운영체제 분석의 특성

• 현재 사용하는 시스템의 운영체제를 분석
• 현재 시스템의 운영체제의 종류를 파악하고, 버전 / 패치 / 백업 주기 등을 분석

(5) 운영체제 현행 시스템 분석 시 고려사항

• 품질 측면
  • 신뢰도
    • 장기간 시스템 운영 시 운영체제의 장애 발생 가능성 예) 운영체제의 버그(오류)로 인한 재기동 여부
  • 성능
    • 대규모 및 대량 파일 작업(배치 작업)처리 예) 지원 가능한 메모리 크기(32bit 또는 64bit 주소체계 지원)
• 지원 측면
  • 기술 지원
    • 공급사들의 안정적인 기술 지원
    • 오픈 소스 여부
  • 주변 기기
    • 설치 가능한 하드웨어
    • 다수의 주변 기기 지원 여부
  • 구축 비용
    • 지원 가능한 하드웨어 비용
    • 설치할 응용 프로그램의 라이선스 정책 및 비용
    • 유지 및 관리 비용

네트워크 분석

(1) 네트워크 개념

• 컴퓨터와 같은 통신 기능을 갖춘 두 개 이상의 통신 장치 사이에서 동선이나 광섬유, 혹은 무선 링크를 포함하는 전송 미디어를 사용하여 정해진 규칙으로 통신 프로토콜에 따라 데이터로 표현되는 정보를 교환하는 통신망 → 정확한 약속이 중요

(2) OSI 7계층 참조 모델(ISO Standard 7498)

• 같은 종류의 시스템만이 통신을 하는 것이 아니라 서로 다른 기종이 시스템의 종류, 구현 방법 등에 제약을 받지 않고 통신이 가능하도록 통신에서 요구되는 사항을 정리하여 표준 모델로 정립한 것
• 개방형 시스템과 상호 접속을 위한 참조 모델 → 다양한 플랫폼에서 사용 가능
• 각 계층을 독립적으로 관리 → 유지보수 용이

✅ 물데네 트세프 응🔥

응용 계층
프리젠테이션 계층
세션 계층
트랜스포트 계층	TCP / UDP
네트워크 계층	IP
데이터 링크 계층	MAC
물리적 계층

프로토콜(Protocol) = 통신규약

- IP (Internet Protocol) 주소
: 통신을 할 때, 송신자와 수신자를 구별하기 위한 고유의 주소 → 고유의 주소
- ICMP (Internet Control Message Protocol)
: IP가 패킷을 전달하는 동안에 발생할 수 있는 오류 등의 문제점을 원본 호스트에 보고하는 일 → 오류보고
- ARP (Address Resolution Protocol)
: 네트워크 계층 주소와 링크 계층 주소 사이의 변환을 담당하는 프로토콜 - IP → MAC
- IGMP (Internet Group Message Protocol)
: 네트워크의 멀티캐스트 트래픽을 자동으로 조절 / 제한하고, 수신자 그룹에 메시지를 동시에 전송, 멀티캐스킹 기능을 수행하는 프로토콜

(3) 네트워크 분석의 특성

• 현재 사용하는 시스템의 네트워크를 분석
• 현재 시스템의 네트워크 구조를 분석 → 전체 시스템의 네트워크 구성도를 작성
• 현재 시스템의 구조를 분석하기 위하여 스위치, 라우터, IDC, 백본망, 방화벽, IDS 등을 분석
• 네트워크 장애 발생의 추적 및 대응 등 다양한 용도로 활용

구분	내용
스위치	- 일반적으로 스위칭 허브를 말함 - MAC 주소를 이용하여 어느 세그먼트로 패킷을 보내야 할지를 결정할 수 있으며, 이를 위해서 맥 테이블(MAC table)을 메모리에 저장하여 스위칭 기능을 수행
라우터	- 원거리에서 네트워크 간 통합을 위해 사용되는 장비 - 라우터를 이용해서 복잡한 인터넷상에서 원하는 목적지로 데이터를 보낼 수 있으며, 원하는 곳의 데이터를 가져올 수도 있음
IDC(Internet Data Center)	- 인터넷 연결의 핵심이 되는 서버(Server)를 한데 모아 집중시킬 필요가 있을 때 설립하는 시설
백본망	- 다양한 네트워크를 상호 연결하는 컴퓨터 네트워크의 일부 - 각기 다른 LAN이나 서브 네트워크 간에 정보를 교환하기 위한 경로를 제공하는 말
방화벽 (침입 차단 시스템, Firewall)	- 외부로부터 내부망을 보호하기 위한 네트워크 구성 요소 중 하나 - 외부의 불법 침입으로부터 내부의 정보 자산을 보호하고, 외부로부터 유해 정보 유입을 차단하기 위한 정책과 이를 지원하는 하드웨어 및 소프트웨어
IDS (침입 탐지 시스템, Intrusion Detection System)	- 대상 시스템(네트워크 세그먼트 탐지 영역)에 대한 인가되지 않은 행위와 비정상적인 행동을 탐지하고, 탐지된 불법 행위를 구별하여 실시간으로 침입을 차단하는 기능을 가진 보안 시스템

DBMS 분석

(1) DBMS(DataBase Management System)의 개념

• 응용 프로그램과 데이터베이스의 중재자로서, 모든 응용 프로그램들이 데이터베이스를 공유할 수 있도록 관리해주는 시스템 소프트웨어
• 데이터베이스를 효과적으로 이용할 수 있도록 하기 위해 필요한 제어, 접근 방법, 관리등의 기능을 수행하는 소프트웨어

(2) DBMS 분석의 특성

• 현재 사용하는 시스템의 DBMS를 분석
• 현재 시스템의 DBMS 종류, 버전, 구성 방식, 백업 주기 등을 분석
• DBMS 분석 시 고려사항 : 가용성, 성능, 기술 지원, 상호호환성, 구축 비용 등🔥

구분	내용
가용성	- 장기간 시스템을 운영할 때 발생할 수 있는 장애 발생 가능성 - DBMS의 결함 등으로 인한 패치 설치를 위한 재기동, 백업 및 복구 편의성, DBMS 이중화 및 복제 지원
성능	- 대규모 데이터 처리 성능, 대량 트랜잭션 처리 성능, 다양한 튜닝 옵션 지원, 비용 기반 최적화 지원 및 설정의 최소화
기술 지원	- 공급 벤더들의 안정적인 기술 지원 - 많은 사용자들 간의 정보 공유
상호호환성	- 설치 가능한 운영체제 종류, 다양한 운영체제에서 지원되는 JDBC, ODBC와 같은 인터페이스 호환
구축 비용	- 라이선스 정책 및 비용, 유지 및 관리 비용

💡 JDBC (Java Database Connectivity)
자바와 데이터베이스를 연결해 주는 응용프로그램 인터페이스
💡 ODBC (Open Database Connectivity)
마이크로소프트사가 개발한 데이터 베이스 접근을 위한 응용 프로그램 인터페이스

(3) DBMS의 필수 기능

• 정의 기능(DDL : Definition Facility)
  • 데이터베이스 구조를 정의
• 조작 기능(DML : Manipulation Facility)
  • 데이터 조작어로 데이터베이스를 조작
• 제어 기능(DCL : Control Facility)
  • 데이터베이스 내용의 정확성과 안정성을 유지

비즈니스 융합 분석

(1) 비즈니스 융합의 개념

• 산업 또는 시장 간의 경계를 허물고 ICT(Information & Communication Technology, 정보 통신 기술) 등을 통한 새로운 전달 방식을 도입함으로써 비즈니스 모델의 적용 범위를 확대시키는 것을 의미
  • 비즈니스 모델이란? 가치를 창출하고 시장에서 성공적인 경쟁을 하기 위해 고안된 조직 목표, 전략, 프로세스, 기술, 구조 등을 포함하는 요소들의 구성체

(2) 비즈니스 융향 분석의 유형

1. 고객 분석 : 비즈니스 모델 상에서 사업자에게 수익을 제공하는 참여자를 식별하고 분석
2. 제품 서비스 및 서비스 분석
   1. 비즈니스 모델 상에서 자사가 제공하는 상품 또는 서비스를 식별하고 분석
   2. 비즈니스 융합 참여자 간 제공하는 서비스와 제공받는 서비스를 식별하고 분석
3. 사업 구조 분석 : 상품 및 서비스의 제공자, 소비자 등 참여자 간의 관계와 구조를 식별하고 분석

(3) 비즈니스 융합 유형

1. 제품과 IT 융합
   • 기존 제품에 IT 부품 또는 자재, 소프트웨어 등을 추가
2. 제품과 서비스 통합
   • 사용자의 요구에 부합하는 시스템 또는 솔루션을 말함
3. 제품 융합
   • 두 가지 이상 제품의 기능과 속성을 하나로 모음
4. 서비스 융합
   • 두 가지 이상 서비스의 기능과 속성을 하나로 모음

효과적인 프로젝트 관리의 3P🔥

- 사람 (People) : 프로젝트 관리에 있어 가장 기본이 되는 인적 요소
- 문제 (Problem) : 처리해야 할 사항을 사용자 입장에서 분석하고, 기획하는 것
- 프로세스 (Process) : 소프트웨어 개발에 필요한 골격을 제공

Product 제품은 아님!

✅ 요구사항 확인

1. 요구사항의 개념

(1) 요구사항의 정의

• 요구사항은 시스템에 대한 고객의 요청을 확정한 것으로 이해 당사자와의 의사통과 이해가 필요하다.
• 요구사항은 어떤 문제를 해결하기 위한 조건이나 제약 조건으로 소프트웨어 개발 전 과정에 필요한 기준과 근거를 제공한다.

(2) 요구사항의 분류

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

구분	내용	예
기능 요구사항 → 사용자가 원하는 기능 ex) 계산기 기능 +,-,*,%	- 시스템이 외형적으로 보여주는 기능과 동작 - 사용자와 외부 요소들 간의 상호작용 - 업무 절차나 입출력에 대한 요구 - 쉽게 파악되고 사용 사례로 정리	ATM 기기의 입출금 작업
비기능 요구사항 → 암묵적인 기능 요구사항 ex) + 계산을 계산기 평균에 맞춰서 작동 요청	- 시스템이 제공하는 기능에 직접 관련되지 않는 요구 - 시스템에 대한 다양한 제약 조건 - 성능, 품질, 보안(기밀성), 안전, 인터페이스 등의 요구사항 - 파악하기가 어렵고 품질 속성 시나오로 정리	ATM 기기의 응답 속도, 가동률

※ 요구 분석 기법의 문제점 및 해결 방안

문제점	해결방안
이해 부족	경험 있는 인력 투입, 유스케이스 모델링
의사소통 부족	Work-through, Insepction, 워크숍, 의사소통 채널 단일화
표현의 어려움	모델링 기법(구조적 분석 기법, 객체지향 분석 기법)으로 가시화
요구사항 변경	변경 관리 계획, 유형별 분리

2. 요구사항 확인 단계

요구 도출 ———— 요구 분석 ———— 요구 명세 ———— 요구 검증

(Elicitation)                           (Analysis)                                (Specification)                      (Validation)

(1) 요구 도출(Elicitation)

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

※ 요구 도출 방법

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

(2) 요구 분석

• 소프트웨어 개발의 실질적인 첫 단계로 사용자 요구에 대해 이해하는 단계
• 도출한 요구의 타당성을 조사하고 비용, 일정 등의 제약을 설정
• 요구 분석의 결과는 소프트웨어 설계의 기본 자료로 사용
• 요구 분석 기법은 구조적 분석, 객체지향 분석으로 구분
• 요구 분석 시 필요한 기술🔥

청취와 인터뷰 질문 기술	요구사항 도출 단계의 면담, 설문, 브레인스토밍 등에서 필요하다
분석과 중재 기술	요구사항 분석 기법의 개념 모델링에서 필요하다.
관찰 및 모델 작성 기술	요구사항 분석 기법의 정형 분석과 요구사항 협상에서 필요하다.

(3) 요구 명세

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

※ 요구사항 명세 속성

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

※ 요구사항 명세 기법

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

💡 정형적 명세 기법

- 정형적 명세서의 형식은 수학적이며, 명세와 설계 시 시스템의 기능과 행위를 표현하는 정형적 문법(Formal Syntax)과 의미(Semantix)를 사용해서 기술한다.
- 분석, 설계 동안 적용된 소프트웨어 공학 방법들은 수학적 엄격함의 정도에 따라 정형성의 스펙트럼으로 분류된다.
- Z(제드) 또는 VDM과 같은 정형적 명세 언어로 표현된 명세서를 생성한다.

(4) 요구 검증

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

요구사항 관리도구의 필요성

- 요구사항 변경으로 인한 비용 편익 분석
- 요구사항 변경의 추적
- 요구사항 변경에 따른 영향 평가

3. 구조적 분석

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

• 자료 흐름도는 가장 보편적으로 사용되는 시스템 모델링 도구로, 기능 중심의 시스템을 모델링하는데 적합
• DeMarco와 Youdon에 의해 제안되었고, 이를 Gane와 Sarson이 보완하였다.
• 자료 흐름도의 구성🔥
  • 프로세스(Process)
  • 자료 흐름(Data Flow)
  • 자료 저장소((Data store)
  • 단말(외부 개체)(Terminator)

(2) 자료 사전(DD : Data Dictionary)

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

자료 사전 기호 기능 의미

자료 사전 기호	기능	의미
=	정의	~로 구성되어있음
+	연결	그리고, 순차(and)
( )	생략	선택 사양, 생략 가능(Optional)
{ }	반복	반복(lteration)
[	]	선택
* *	설명	주석(Comment)

(3) 프로세스 명세서(Mini-spec)

• 자료 흐름도의 계층상에서 최하위 단계, 즉 더 이상 분해할 수 없는 단계의 처리 절차를 기술하는 것으로 구조적 언어를 사용한다.
• DeMarco는 프로세스 명세서를 **소단위 명세서(Mini-spec)**라고 하였다.
• DFD 그림을 보고 이해하기 어려운 복잡한 구조를 이해할 수 있게 도와주는것

4. 객체지향 분석

(1) 객체지향 분석(OOA : Object Oriented Analysis)의 개념

• 동적 모델링 기법이 사용될 수 있으며, 데이터와 행위를 하나로 묶어 객체를 정의하고, 추상화시키는 작업

(2) 럼바우(Rumbaugh)의 OMT(Object Modeling Technique) 기법🔥

• 소프트웨어 구성 요소들을 그래픽 표기법을 이용하여 객체들을 모델링하는 기법
• 객체들의 연관성을 강조하며, 조직적인 모델링 방법론을 이용하여 실세계의 문제들을 다른 방법보다 상세하게 나타낸다.
• 시스템의 분석, 설계, 구현 단계 전 과정에 객체지향 개념을 적용했다.
• 객체모델링 → 동적모델링 → 기능모델링 순서로 진행된다.🔥
• OMT 3단계🔥

객체 모델링 (Object Modelling)	- 객체 다이어그램으로 표시하며, 정보 모델링이라고도 한다. - 일대다의 객체 의존 관계를 정의한 것 - 시스템에서 요구되는 객체를 찾아내어 속성과 연산 식별 및 객체들 간의 관계를 규정하여 다이어그램으로 표시하는 모델링이다.
동적 모델링 (Dynamic Modelling)	- 시스템이 시간의 흐름에 따라 변화하는 것을 보여주는 상태 다이어그램(State Diagram)을 작성한다.
기능 모델링 (Function Modelling)	- 시스템 내에서 데이터가 변하는 과정을 나타내며 자료 흐름도(DFD)를 이용한다.

(3) Booch의 OOAD(Object Oriented Analysis and Design)

• 여러 가지 다른 방법론을 통합하여 하나의 방법론으로 만들었는데 분석보다는 설계에 더 많은 중점을 두고있다.
• 전체 시스템의 가시화와 실시간 처리에 유용하며, 설계를 위한 문서화 기법이 강조된다.
• 규모가 큰 프로젝트 수행 시 과정이 매우 복잡해지며, 구현 언어(Ada)에 제한된다.

(4) Coad/Yourdon방법

• E-R 다이어그램을 사용하여 객체의 행위를 모델링 하는 데 초점을 둔 방법
• 객체 식별, 구조 식별, 주체 정의, 속성 및 관계 정의, 서비스 정의 등의 과정으로 구성된다.

💡 요구사항 정의 및 분석/설계의 결과물을 표현하기 위한 모델링 과정에 사용되는 다이어그램

- DFD, E-R다이어그램, UML 다이어그램 등

5. UML

(1) UML(Unified Modeling Language)의 정의

• 객체지향 분석/설계용의 모델링 언어이며, 기존의 객체지향 방법론과 함께 제안되어 모델링 언어 표기법의 표준화를 목적으로 한 것
• 시스템의 다양한 특성을 표현하는 방법이 있으며, 객체지향 분석 및 설계 표현 방법에 대한 표준으로 받아들여지고 있다.
• UML은 객체지향 소프트웨어를 모델링하는 표준 그래픽 언어로, 심벌과 그림을 사용해 객체지향 개념을 나타낼 수 있다.
• UML은 소프트웨어 개발의 중요한 작업인 분석, 설계, 구현의 정확하고 완벽한 모델을 제공한다.

(2) UML의 특성

1. 시스템의 정적인측면
   • 클래스 다이어그램(Class Diagram)
2. 시스템의 동적인측면 → 화살표를 사용하여 흐름을 나타냄
   • 시퀀스 다이어그램(Sequence Diagram), 상태 다이어그램(State Diagram), 콜라보레이션 다이어그램(Collaboration Diagram)
3. 시스템의 기능적측면
   • 유스케이스 다이어그램(UseCase Diagram)

💡 UML의 기본 구성 요소

- 사물(Things) : 모델을 구성하는 가장 중요한 요소로 다이어그램 안에서 관계가 형성될 수 있는 대상을 말한다.
- 관계(Relationships) : 사물과 사물 사이의 연관성을 표현하는 것 (연관 관계, 집합 관계, 포함 관계, 일반화 관계, 의존 관계, 실체화 관계)
- 다이어그램(Diagram) : 사물과 관계를 도형으로 표현한 것

(3) UML 다이어그램의 종류🔥

(정적) 구조적 다이어그램	Class Diagram / Object Diagram / Component Diagram / Deployment Diagram / Composite Diagram / Pakage Diagram
(동적) 행위 다이어그램	UseCase Diagram / Sequence Diagram / State Diagram / Activity Diagram / Timing Diagram / Communication Diagram

💡 UML 스테레오 타입

- UML에서 표현하는 기본 기능 외에 추가적인 기능을 표현하기 위해 사용
- 기호 << >> 사이에 표현할 형태를 기술하며 **길러멧(Guilmet)**이라고 부른다.
ex ) <<INCLUDES>>, <<EXTENDS>>

유스케이스 다이어그램(UseCase Diagram)

• 시스템이 어떤 기능을 수행하고, 주위에 어떤 것이 관련되어 있는지 나타낸 모형
• 각 기능을 정의함으로써 시스템에 대한 전반적인 이해를 높이고, 문제 영역에 대해 개발자와 사용자 간의 의사소통을 원할하게 하는 데 도움을 줄 수 있다.
• 시스템의 기능을 나타내기 위해 사용자의 요구를 추출하고 분석하는데 사용된다.
• 외부에서 보는 시스템의 동작으로 외부 객체들이 어떻게 시스템과 상호작용하는지(시스템이 외부 자극에 어떻게 반응하는지) 모델링하는 것
• 액터는 시스템 번위 바깥쪽에 있고 유스케이스는 액터에게 보이는 시스템의 기능이다.

📌 유스케이스 다이어그램의 구성 요소

액터(Actor)	시스템과 상호작용하는 시스템 외부 사람이나 다른 시스템 혹은 시스템 환경, 하드웨어
유스케이스 (Use Case)	액터의 요청에 의해서 수행하게 되는 시스템의 기능으로 완전하고 의미있는 이벤트의 흐름을 나타내며, 유스케이스의 집합은 시스템을 사용하는 모든 방법을 이룬다.
시나리오 (Scenario)	유스케이스는 시스템의 기능을 나타내는 모든 가능한 시나리오를 추상화한 것이며, 시나리오는 실제 일어나는 일들을 기술한 유스케이스의 인스턴스이다.

• 유스케이스의 관계
  • 연관(Assosiation) 관계
    • 액터와 유스케이스가 연관이 있음을 나타내며, 실선으로 표기한다.
  • 의존(Dependency) 관계
    • 포함관계와 확장관계가 있다.

포함(Include) 관계🔥	- 복잡한 시스템에서 중복된 것을 줄이기 위한 방법으로 함수의 호출처럼 포함된 사용사례를 호출하는 의미 - 필수적 관계이며 하나의 유스케이스가 실행되기 위해선 다른 유스케이스가 반드시 실행되어야 할 때 사용 - 점선 화살표에 <<Include>> 라고 표기
확장(extends) 관계🔥	- 예외 사항을 나타내는 관계로 이벤트를 추가하여 다른 사례로 확장 - 선택적 관계이며 유스케이스가 특정 조건을 만족할 경우 실행되는 부가적인 기능을 나타냄 - 점선 화살표에 <<extends>> 라고 표기

• 일반화(Generalization) 관계
  • 사용사례의 상속을 의미하며, 유사한 사용사례를 모아 일반적인 사용사례를 정의한다.
  • 구체적인 유스케이스에서 일반화된 유스케이스쪽으로 향하는 끝부분이 삼각형인 실선 화살표로 표기

클래스 다이어그램(Class Diagram)

• 클래스 다이어그램은 객체지향 분석 및 설계의 핵심이다.
• 객체, 클래스, 속성, 오퍼레이션 및 연관 관계를 이용하여 시스템을 나타낸다.
• 사용자는 보다 쉽게 원하는 시스템의 구조를 정의할 수 있고, 입출력 화면도 하나의 객체로 나타나기 때문에 시스템의 구조화가 용이하다.
• 분석 단계에서 사용자 인터페이스 프로토타이핑 작성이 쉬워진다.

📌 클래스 다이어그램의 구성 요소

클래스	각 객체들이 갖는 속성과 동작 표현, 접근 제어자 설정
관계	클래스와 클래스 관계 설정: 연관, 집합, 일반화 등
제약 조건	속성에 입력된 값에 대한 제약 조건

• 클래스 다이어그램의 유형

| 

 

연관 관계 (Association)	연관 관계를 표시한 선분의 끝에는 역할을 표시하는데, 이는 연관 관계가 어떤 클래스로부터 연유된 것인지를 나타내기 위함이다.
일반화 관계 (Generalization)	상속 관계라고도 하며, 한 클래스가 다른 클래스를 포함하는 상위 개념일 때 이를 IS-A 관계라고 한다.
부분 전체 관계	- 집합(Aggregation)관계 = 포함 관계 ◇ : 구성 요소(부분)가 없어도 전체 개념이 존재할 수 있다. (자동차 내 에어컨, 라디오 등) - 복합(Composition)관계 = 합성 관계 ◆ : 집합 관계의 강한 형태로서, 복합 관계에서 부분은 한 순간에 하나의 전체에만 포함된다. (자동차 내 엔진, 타이어 등)
의존 관계 (Dependency)	연관 관계와 같이 한 클래스가 다른 클래스를 사용할 때 나타난다. 두 클래스 관계가 한 메소드의 실행 동안과 같이 매우 짧은 시간 동안만 존재한다. 일반적으로 한 클래스가 다른 클래스를 오퍼레이션의 매개 변수로 사용하는 경우에 나타나는 관계이다.
실체화 관계 (Realization)	책임들의 집합인 인터페이스와 이 책임들을 실제로 실현한 클래스들 사이의 관계에서 나타낸다. - 인터페이스 실현 관계 - 인터페이스 의존 관계

시퀀스(순차)다이어그램(Sequence Diagram)🔥

• 시퀀스 다이어그램은 객체 간의 메시지 통신을 분석하기 위한 것
• 시스템의 동적인 모델을 아주 보기 쉽게 표현하고 있기 때문에 의사 소통에 매우 유용

📌 시퀀스(순차) 다이어그램의 구성 요소🔥

액터(Actor)	시스템과 상호작용하는 시스템 외부의 사람이나 다른 시스템을 의미
객체(Object)	메시지를 주고받는 주체
생명선(Lifeline)	객체가 메모리에 존재하는 시간을 의미
실행(Activation)	객체가 메시지를 주고받으며 실행되고 있음을 표현
메시지(Message)	객체가 상호작용을 위하여 주고받는 것

• 시스템의 동작을 정형화하고 객체들의 메시지 교환을 시각화하여 나타낸다.
• 객체 사이에 일어나는 상호작용을 나타낸다.
• 시간의 흐름을 파악할 수 있다.

콜라보레이션 다이어그램(Collaboration Diagram)

• 시퀀스 다이어그램이 객체 간의 메시지 처리에 대한 순서에 중점을 둔 반면에, 콜라보레이션 다이어그램은 관련 객체와의 연관성 분석에 중점을 두고 있다.
• 객체들 간의 정적인 상호 연결 관계를 표현하고 있기 때문에 객체 간의 결합도나 메시지 처리를 관찰하기 쉽다는 것이 장점
• 시퀀스 다이어그램은 메시지의 작업 순서를 명확하게 알 수 있지만, 콜라보레이션 다이어그램은 확인하기 어렵다. (시간의 흐름을 파악하기가 어렵다.)
• 시퀀스 다이어그램을 보기 쉽게 정리한 것이라고 이해하면됨

상태 다이어그램(State Diagram)

• 객체 내의 동적 행위를 모형화하기 위한 것, 복잡한 객체 혹은 객체 내부의 프로세스를 표현하고자 할 때 사용된다.
• 상태는 둥근 사각형으로, 상태의 흐름은 화살표로 표시
• 시스템의 흐름을 객체 단위로 자세히 표현할 수 있다는 장점을 갖지만, 작성이 매우 어려우므로 꼭 필요한 경우가 아니면 쓰지 않는 것이 좋다.
• 어떤 객체의 동적인 행동을 표현하기 위해 사용되며, 여러 유스케이스들 사이의 한 객체가 수행하는 기능은 나타낸다.
• 전체가 아닌 부분 부분을 표현할 때 사용

활동 다이어그램(Activity Diagram)

• 시스템의 흐름 전체를파악하기 용이하도록 행위를 중심으로 흐름을 표현한 것
• 현재 업무의 흐름 파악이 용이하다. → 업무 흐름 지향적인 문제 영역에서 작성하는 것이 좋다.
• 시스템을 액티비티로 표현한 것으로, 오퍼레이션의 집합이 수행됨을 나타내는 상태

컴포넌트 다이어그램(Component Diagram)

• 시스템을 구성하는 실제 소프트웨어 컴포넌트 간의 구성 체계를 기술하므로 아키텍쳐 표현에 우수하다.
• 각 컴포넌트와 컴포넌트 간의 의존성 관계를 화살표로 나타낸다.

💡 소프트웨어 컴포넌트(Sorftware Component)
- 마치 기계의 부품과 같이 소프트웨어도 부품화하여 제작한 다음 이를 조립해 더 복잡한 소프트웨어를 제작할 수 있는 조립형 소프트웨어이다.

패키지 다이어그램(Package Diagram)

• 분석된 결과를 시스템으로 구현하기 위하여 기존의 구조적 기법에서는 전체 시스템을 프로그램 모듈로 나누는 기능 분할 기법을 사용한다.
• 하나의 패키지는 여러 개의 서브 패키지나 클래스를 가질 수 있다. 이들은 또한 나중에 하나의 모듈 혹은 컴포넌트가 된다.
• 패키지 다이어그램은 분석적 측면에서 클래스들 간의 관계를 이해하기 위해서도 필요하지만, 실제 구현을 위하여 모듈로 그룹화하는 도구로서도 사용될 수 있다.

6. 애자일

(1) 애자일(Agile)의 정의

• 애자일 소프트웨어 개발 모형 혹은 애자일 개발 프로세스는 소프트웨어 엔지니어링에 대한 개념적인 얼개로, 프로젝트의 생명주기 동안 반복적인 개발을 촉진한다.
• 애자일 개발 프로세스란 어느 특정 개발 방법론을 가리키는 말은 아니고, 애자일 개발을 가능하게 해주는 다양한 방법론 전체를 일컫는 말이다.
• e-비즈니스 시장 및 SW 개발 환경 등 주위 변화를 수용하고, 이에 능동적으로 대응하는 여러 방법론을 통칭한다.
• 애자일 기법은 계획 수립과 문서화에 크게 중점을 두지 않는다.

(2) 애자일의 특성(5가지)🔥

1. 프로세스 중심이 아닌 사람 중심 → 책임감 있는 개발자와 전향적인 고객
2. 전반적인 문서화보다는 제대로 작동하는 소프트웨어를 만들어야한다.
3. 계약 협상보다는 고객 협력이 중요하다.
4. 계획을 따르기보다는 변화에 대응한다.
5. 모든 경우에 적용되는 것이 아니고 중소형, 아키텍처 설계, 프로토타 이핑에 적합 → 대규모 X

(3) 애자일의 종류

구분 내용

구분	내용
익스트림 프로그래밍 (XP : eXtreme Programming)	- 애자일 개발 프로세스의 대표자로 애자일 개발 프로세스의 보급에 큰 역할을 하였다. - 이 방법은 고객과 함께 2주 정도의 반복 개발을 하고, 테스트 우선 개발을 특징으로 하는 명시적인 기술과 방법을 가지고 있다.
스크럼 (Scrum)	- 30일 마다 동작 가능한 제품을 제공하는 스플린트를 중심으로 하고 있다. - 매일 정해진 시간과 정해진 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심의 방법론
크리스털 패밀리 (Crystal Family)	- 프로젝트의 규모와 영향의 크기에 따라서 여러 종류의 방법론을 제공 - 그 중에서 가장 소규모 팀에 적용하는 크리스털 클리어는 익스트림 프로그래밍만큼 엄격하지 않고 효율도 높지 않지만, 프로젝트에 적용하기 쉬운 방법론이다.
기능 주도 개발 (FDD : Feature-Driven Development)	- Feature마다 2주 정도의 반복 개발을 실시하다. - Peter Coad가 제창하는 방법론으로써, UML을 이용한 설계 기법과도 밀접한 관련을 가진다.
ASD (Adaptive Software Development)	- 소프트웨어 개발을 혼란 자체로 규정하고, 혼란을 대전제로 그에 적응할 수 있는 소프트웨어 방법을 제시하기 위해 만들어진 방법론이다. - 내용적으로는 다른 방법론들과 유사하지만, 합동 애플리케이션 개발(Joint Aplication Devleopment, 사용자나 고객이 설계에 참가하는 개발 방법론)을 사용하는 것이 조금 다르다.

💡 애자일 개발 프로세스 vs 전통적인 개발 프로세스

- 폭포수 모델과 계획 기반 개발 기법들은 차례와 탄탄한 계획을 기반으로 하여 개발을 진행시킨다.
→ 이해하기 쉽고 사용하기 쉬운 바람직한 기법이기도 하지만, 계획대로 진행되지 않을 경우 많은 부작용이 발생할 수 있다.
→ 한번에 크게크게 진행 시킨다.

- 소프트웨어를 포함한 IT 개발은 경험적 프로세스 제어 모델로 접근할 필요가 있다. 경험적 프로세스 제어 모델은 항상 불확실성을 수반 및 포용하고 있다.
→ 애자일 개발 프로세스는 경험적 프로세스 제어 모델로 개발을 관리한다.

익스트림 프로그래밍(XP : eXtreme Programming)

1. 개요
   1. 켄트 벡(Kent Beck) 등이 제안한 소프트웨어 개발 방법
   2. 애자일 프로세스의 대표적 개발 기법
   3. 비즈니스 상의 요구가 시시각각 변동이 심한 경우에 적합한 개발 방법
   4. 개발자, 관리자, 고객이 조화를 극대화하여 개발 생산성을 높이고자 하는 접근법
2. XP의 5가지 핵심 가치🔥구분 내용

   구분	내용
   존중(Respect)	팀 기반의 활동 중 팀원 간의 상호 존중을 강조
   단순성(Simplicity)	사용되지 않는 구조와 알고리즘 배제
   의사소통(Communication)	개발자, 관리자, 고객 간의 원활한 의사소통
   피드백(Feedback)	지속적인 테스트와 통합, 반복적 결함 수정, 빠른 피드백
   용기(Courage)	고객의 요구사항 변화에 능동적인 대처

XP의 12가지 실천 사항🔥구분 내용

구분	내용
계획 세우기 (Planning Process)	- User Story를 이용해서 Next Release의 범위를 빠르게 설정하고, 비즈니스 우선순위와 기술적 평가가 결합한다. → 전통적인 개발 프로세스 보단 아니지만 계획을 세움
소규모 릴리즈 (Small/Short Releases)	- 필요한 기능들만 갖춘 간단한 시스템을 빠르게 프로덕션화하고, 아주 짧은(2주) 사이클로 새로운 버전을 자주 배포한다.
메타포어 (Metaphor)	- 공통의 이름 체계(개발 및 커뮤니케이션 과정에서 공통된 개념을 공유 하게함)
단순한 디자인 (Simple Design)	- 현재의 요구사항을 만족시키도록 가능한 한 단순하게 설계한다.
테스트 기반 개발 (TDD: Test Drvien Develop)	- 작성해야 하는 프로그램에 대한 테스트를 먼저 수행한 다음 코드를 작성하고 테스트를 통과할 수 있도록 실제 프로그램의 코드를 작성한다.
리팩토링 (Refactoring)	- 프로그램의 기능을 바꾸지 않으면서, 중복 제거, 커뮤니케이션 향상, 단순화, 유연성 추가 등을 위해 시스템을 재구성한다.
짝 프로그래밍 (Pair Programming)	두 사람이 같이 프로그래밍한다.(Driver/Partner)
공동 코드 소유 (Collective Ownership)	시스템에 있는 코드는 누구든지, 언제라도 수정 가능하다.
지속적인 통합 (Continuos Integration)	하루에 몇 번이라도 시스템을 통합하여 빌드할 수 있다.
40시간 작업 (40-hour Week)	일주일에 40시간 이상을 일하지 않도록 규칙으로 정하고, 2주 연속으로 오버 타임 하지 않도록 한다.
고객 상주 (On site Customer)	개발자들의 질무네즉각 대답해 줄 수 있는 고객을 프로젝트에 풀타입으로 상주 시킨다. → 현장의 고객
코드 표준 (Coding Standards)	팀원들 간 커뮤니케이션 향상을 위해서는 코드가 표준화된 관례에 따라 작성되어야한다.

💡 소프트웨어 위기(Software Crisis)

- 소프트웨어 위기는 소프트웨어 공학 초기에 사용되던 용어로 F.L Bauer가 1968년 독일에서 열린 첫 번째 나토 소프트웨어 공학회에서 처음 사용하였다.
- 소프트웨어 위기의 현상 : 프로젝트 개발 일정과 예산 측정의 어려움, 소프트웨어 유지보수 비용의 증가, 소프트웨어 개발 적체 현상, 개발 인력의 감소
→ 하드웨어의 급발전 (반도체 등) 반면에, 소프트웨어는 너무 커짐