[정보처리기사실기]요구사항 확인1

안녕하세요! 오늘 부터 정보처리기사실기 공부를 시작해 봅시다!😊

---

[Chapter 1. 요구사항 확인]

1.소프트웨어 개발방법론(⭐⭐⭐)

1) 소프트웨어 생명주기 모델

-소프트웨어 생명주기 모델이란?

: 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차.

: 시스템이 개발될 때부터 운용과 유지보수를 거쳐 생애를 마칠 때까지의 작업 프로세스를 모델화 한 것.

 

-소프트웨어 생명주기 모델 프로세스

: 요구사항 분석 → 설계 → 구현 → 테스트 → 유지보수

*요구사항 분석 : 사용자의 요구와 조건을 결정하는 단계, 개발할 소프트웨어의 기능과 제약조건, 목표 등을 명확히 정의하는 단계

*설계 : 시스템 명세 단계에서 정의한 기능을 실제 수행할 수 있도록 수행 방법을 논리적으로 결정하는 단계

*구현 : 설계 단계에서 결정한 방법을 특정 프로그래밍 언어를 사용하여 실제 프로그램을 작성하는 단계, 언어선택, 기법 스타일, 순서 등 결정

*테스트 : 시스템이 정해진  요구를 만족하는지 검사하고 평가하는 단계

*유지보수 : 시스템이 인수되고 설치된 후 일어나는 모든 활동

 

-소프트웨어 생명주기 모델 종류

: 폭포수 모델, 프로토타이핑 모델, 나선형 모델, 반복적 모델

*폭포수 모델 : 개발의 각 단계를 확실히 마무리 지은 후에 다음 단계로 넘어가는 모델, 단계별 정의와 산출물이 명확, 요구사항 변경이 어려움 : 타당성 검토 → 계획 → 요구사항 분석 → 설계 → 구현 → 테스트 → 유지보수

*프로토타이핑 모델 : 고객이 요구한 기능을 프로토타입(구현 단계의 골격)으로 구현하여 고객의 피드백을 반영하며 만들어가는 모델

*나선형 모델 : 위험을 최소화하기 위해 점진적으로 완벽한 시스템으로 개발하는 모델 : 계획 및 정의 → 위험 분석 → 개발 → 고객 평가

*반복적 모델 : 구축대상을 나누어 병렬적으로 개발 후 통합하거나, 반복적으로 개발하여 점증 완성시키는 모델 : 사용자의 요구사항 일부분 혹은 제품 일부분을 반복적으로 개발하여 최종 시스템으로 완성하는 모델

구분	특징	장점	단점
폭포수 모델	순차적	이해 및 관리가 편리	요구사항 변경 어려움
프로토타이핑 모델	프로토타입	요구분석 용이	비용증가(프로토 타입 폐기)
나선형 모델	위험분석 , 반복 개발	위험성 감소, 변경에 유연한 대처 가능	반복에 따른 관리 어려움
반복적 모델	증분방식, 병행 개발	일정 단축 가능	비용 증가(병행 관리)

---

2) 소프트웨어 개발방법론

-소프트웨어 개발방법론이란?

: 소프트웨어 개발 전 과정에 지속적으로 적용할 수 있는 방법, 철차, 기법.

 

-소프트웨어 개발 밥법론 종류

: 구조적 방법론, 정보공학 방법론, 객체지향 방법론, 컴포넌트 기반 방법론, 애자일 방법론

*구조적 방법론 : 시스템을 기능에 따라 나누어 개발하고 통합한다.(분할과 정복 접근 방식) : 하양식 방법론 : 나씨-슈나이더만(Nassi-Shneiderman) 차트 사용

*정보공학 방법론 : 정보시스템 개발에 필요한 관리 절차와 작업 기법을 체계화한 방법론 : 개발주기를 이용해 대형 프로젝트를 수행하는 체계적인 방법론

*객체지향 방법론 : '객체'라는 기본 단위로 시스템을 분석 및 설계하는 방법론 : 현실 세계를 사람이 이해하는 방식으로 시스템에 적용 : 객체, 클래스, 메시지 사용

*컴포넌트 기반 방법론 : 소프트웨어를 구성하는 컴포넌트(개발된 모듈 단위)를 조립해서 하나의 새로운 응용 프로그램을 작성하는 방법론 : 개발 기간 단축, 생산성 향상 : 새로운 기능 추가가 쉬움(확장성) : 소프트웨어 재사용 가능

*애자일 방법론 : 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적인 신속 정응적 경량 개발방법론 : 개발 과정의 어려움을 극복하기 위해 적극적으로 모색한 방법론

-애자일(Agile) 방법론이란?

: 절차보다 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템을 개발하는 방법론.

: 개발 기간이 짧고 신속하며, 폭포수 모형에 대비되는 방법론, 개발과 함께 즉시 피드백을 받아 유동적 개발.

: 기존 개발방법론의 한계(문서 및 절차 위주로 인한 변화에 신속 대응 어려움)를 극복하기 위해 등장.

: XP, 린(Lean), 스크럼(SCRUM) 등..

*XP : 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론 : 1~3주의 반복 개발주기 : 5가지 가치(용기,단순성,의사소통,피드백,존중) : 12가지 기본원리(짝 프로그래밍, 공동 코드 소유, 지속적인 통합, 계획 세우기, 작은 릴리즈, 메타포어, 간단한 디자인, 테스트 기반 개발, 리팩토링, 40시간 작업, 고객 상주, 코드 표준)

*린(Lean) : 도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해서 낭비 요소를 제거하여 품질을 향산시킨 방법론 : JIT(Just In Time), 칸반(Kanban) 보드 사용 : 7가지 원칙(낭비제거, 품질 내재화, 지식 창출, 늦은 확정, 빠른 인도, 사람 존중, 전체 최적화)

*스크럼(SCRUM) : 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론 : 백로그(요구사항) : 스프린트(2~4주의 짧은 개발 기간, 반복적 수행) : 스크럼 미팅(매일 15분 정도 미팅으로 To-Do List 계획수립) : 스크럼 마스터(프로젝트 리더) : 스프린트 회고(스프린트 주기를 되돌아보며 정해놓은 규칙 준수 여부, 개선점 등을 확인 및 기록) : 번 다운 차트(남아있는 백로그 대비 시간을 그래픽적으로 표현한 차트)

비교 항목	애잘일 방법론	전통적 방법론
계획수립	유동적 범위 설정	확정적 범위 설정
업무수행	팀 중심	관리자 주도적(개인 단위 업무수행)
개발,검증	반복 주기 단위로 개발, 검증	분석,설계,구현,테스트 순차적 수행
팀관리	팀 평가	경쟁, 개별 평가
문서	문서보다 코드 강조	상세한 문서화 강조
성공요소	고객 가치 전달	계획/일정 준수
유형	XP, 스크럼, 린	폭포수, 프로토타입, 나선형

---

2.비용산정, 일정관리 모형(⭐⭐⭐)

1) 비용산정 모형

-비용산정 모형이란?

: 소프트웨어 규모파악을 통한 투입자원, 소요시간을 파악하여 실행 가능한 계획을 수립하기 위해 비용을 산정하는 방식.

 

-비용산정 모형 분류

:하양식 산정방법, 상향식 산정방법

*하향식 : 경험이 많은 전문가에게 의뢰(전문가 판단, 델파이 기법)

*상향식 : 요구사항과 기능에 따라 필요한 비용 계산(코드 라인 수, Man Month, COCOMO, 푸트남, 기능점수)

*델파이 기법 : 전문가의 경험적 지식을 통한 문제 해결 및 미래예측을 위한 기법. : 하향식 산정방법.

*LoC(Lines of Code) : 원시 코드 라인 수의 낙관치, 중간치, 비관치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정한다. : 측정이 쉽고 이해하기 쉬워 많이 사용한다. : 예측치를 이용하여 생산성, 노력, 개발 기간 등의 비용을 산정한다. 낙관치(a) : 가장 적게 측정된 코드 라인 수 중간치(b) : 측정된 모든 코드 라인 수의 평균 비관치(c) : 가장 많이 측정된 코드 라인 수

*Man Month : 한 사람이 1개월 동안 할 수 있는 일의 양을 기준으로 프로젝트 비용을 산정하는 방식. (Man Month) = (LoC)/(프로그래머의 월간 생산성) (프로젝트 기간) = (Man Month)/(프로젝트 인력)

*COCOMO(COnstructive COst MOdel) : 보헴(Bohem)이 제안한 모형으로 프로그램 규모에 따라 비용을 산정하는 방식이다. : 비용산정 결과는 프로젝트를 완성하는 데 필요한 노력(Man_Month)으로 산정한다. : 비용 견적의 강도 분석 및 비용 견적의 유연성이 높아 소프트웨어 개발비 견적에 널리 통용된다. : 규모에 따라 유형이 조직형(기본형,단순형), 반 분리형, 임베디드형으로 나뉜다.

*푸트남(Putnam) 모형 : 개발주기의 단계별로 요구할 인력의 분포를 가정하는 방식 : 푸트남이 제안한 것으로 생명주기 예측 모형이라고 한다. : 시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력 분포도를 기초로 한다.

*기능점수(FP:Function Point) 모형 : 요구 기능을 증가시키는 인자별로 가중치를 부여하고, 요인별 가중치를 합산하여 총 기능의 점수를 계산하여 비용을 산정한다. : 경험을 바탕으로 단순, 보통, 복잡한 정도에 따라 가중치를 부여한다. 기능점수(FP) = 총 기능점수 × [0.65+(0.1 × 총 영향도)]

2) 일정관리 모델

-일정관리 모델이란?

: 프로젝트가 일정 기한 내에 적절하게 완료될 수 있도록 관리하는 모델.

 

-일정관리 모델의 종류

: 주 공정법, PERT, 중요 연쇄 프로젝트 관리

*주 공정법(CPM:Critical Path Method) : 여러 작업의 수행 순서가 얽혀 있는 프로젝트의 일정을 계산하는 기법. : 모든 자원 제약사항을 배제한 상태로 프로젝트의 시작과 끝을 나타내는 노드(Node)와 노드 간을 연결을 통해 공정을 계산하기 위한 액티비티(Activity) 표기법 :임계 경로(Critical Path)는 가장 긴 시간이 걸리는 경로이다.

*PERT(Program Evaluation and Review Technique) : 일의 순서를 계획적으로 정리하기 위한 수렴 기법. : 비관치, 중간치, 낙관치의 3점 추정방식을 통해 일정을 관리하는 기법.

*중요 연쇄 프로젝트 관리(CCMP:Critical Chain Project Management) : 주 공정 연쇄법으로 자원제약사항을 고려하여 일정을 작성하는 기법.

---

3.현행 시스템 파악(⭐⭐⭐)

-현행 시스템 파악이란?

: 현행 시스템이 어떤 하위 시스템으로 구성되었고, 제공 기능 및 연계 정보는 무엇이며 어떤 기술 요소를 사용하는지를 파악하는 활동.

 

1)현행 시스템 파악 절차

 1단계 - 구성/기능/인터페이스 파악

 2단계 - 아키텍처 및 소프트웨어 구성 파악

 3단계 - 하드웨어 및 네트워크 구성 파악

[1단계] *현행 시스템 구성 현황 파악 : 조직의 주요 업무를 처리하는 기간 업무와 이를 지원하는 지원 업무로 구분하여 파악한다. : 각 업무에 속하는 정보시스템들의 명칭, 주요 기능들을 명시한다. : 조직 내 존재하는 모든 정보시스템의 현황 파악이 가능하도록 한다. *기능 현황 파악 : 단위 업무 시스템이 현재 제공하고 있는 기능을 파악한다. : 단위 업무 시스템 기능들을 주요 기능과 하부 기능으로 구분하여 계층 형으로 표시한다. *인터페이스 현황 파악 : 단위 업무 시스템이 다른 시스템과 주고 받는 데이터의 종류, 데이터 형식, 프로토콜, 연계유형, 주기를 파악한다. : 데이터 형식(XML, 고정 포맷, 가변 포맷 등..)을 주고받는지, 어떤 통신규약(TCP/IP, X25 등..)을 사용하고 있고, 연계유형(EAI 등..)은 무엇인지 등을 표시한다.

[2단계] *현행 시스템 아키텍쳐 구성 파악 : 기간 업무를 수행하기 위하여 계층별로 어떠한 기술 요소들을 사용하고 있는지 최상위 수준에서 파악한다. : 단위 업무 시스템별로 아키텍처가 다른 경우 가장 핵심이 되는 기간 업무 처리 시스템을 기준으로 파악한다. *소프트웨어 구성 파악 : 단위 업무 시스템의 업무 처리를 위해 설치된 소프트웨어들의 제품명, 용도, 라이선스 적용 방식, 라이선스 수를 파악한다. : 상용 소프트웨어의 경우에는 라이선스 적용 방식의 기준(사이트, 서버, 프로세서, 코어, 사용자 수 등..)과 보유한 라이선스 수량 파악이 중요하다.

[3단계] *하드웨어 구성 파악 : 단위 업무 시스템들이 운용되고 있는 서버의 위치, 서버의 주요 사양(CPU 처리 속도, 메모리 크기, 하드디스크의 용량 등..)과 수량, 이중화 구현 여부를 파악한다. : 이중화는 기간 업무의 서비스 기간, 장애 대응 정책에 따라 필요성 여부가 결정되며, 이에 따라 인프라 구축 기술 난이도 및 비용 증가 가능성이 존재한다. *네트워크 구성 파악 : 업무 처리 시스템을 위해 어떤 네트워크 장비를 사용하여 어떻게 구성되어 있는지 파악한다. : 네트워크 구성도의 작성을 통해 서버의 위치, 서버 간의 네트워크 연결 방식을 파악할 수 있도록 표현한다.

2)소프트웨어 아키텍처

- 소프트웨어 아키텍처(Software Architecture)란?

: 여러 가지 소프트웨어 구성요소와 그 구성요소가 가진 특성 중에서 외부에 드러나는 특성, 구성 요소 간의 관계를 표현하는 시스템의 구조나 구조체.

 

-소프트웨어 아키텍처 프레임워크(Software Architecture Framework)란?

: 소프트웨어 집약적인 시스템에서 아키텍처가 표현해야 하는 내용 및 이들 간의 관계를 제공하는 아키텍처 기술 표준.

 

-소프트웨어 아키텍처 프레임워크 구성요소

: 아키텍처 명세서, 이해 관계자, 관심사, 관점, 뷰, 근거, 목표, 환경, 시스템

*아키텍처 명세서 : 아키텍처를 기록하기 위한 산출물들 : 이해관계자들의 시스템에 대한 관심을 관점에 맞추어 작성한 뷰로 표현 : 개별 뷰, 뷰 개괄 문서, 인터페이스 명세 등..

*이해관계자 : 시스템 개발에 관련된 모든 사람과 조직 : 고객, 최종사용자, 개발자, 프로젝트 관리자, 유지보수자, 마케팅 담당자 등..

*관심사 : 시스템에 대해 이해관계자들의 서로 다른 의견과 목표 : 사용자 입장 - 기본적인 기능, 신뢰성, 보안, 사용성 등.. : 유지보수자 입장 - 유지보수의 용이성 : 개발자 입장 - 적은 비용과 인력으로 개발

*관점 : 개별 뷰를 개발할 때 토대가 되는 패턴이나 양식 : 이해관계자들이 서로 다른 역할이나 책임으로 시스템이나 산출물들에 대해 보고 싶은 관점

*뷰 : 서로 관련 있는 관심사들의 집합이라는 관점에서 전체 시스템을 표현 : 시스템에 대한 아키텍처 설명에는 하나 이상의 뷰로 구성

*근거 : 아키텍처 결정 근거 : 회의 결과, 보고 결과

*목표 : 환경 안에서 한 명 이상의 이해관계자들이 의도하는 시스템의 목적, 사용, 운영 방법.

*환경 : 시스템에 영향을 주는 요인으로 개발, 운영 등의 외부 요인 등..

*시스템 : 각 애플리케이션, 서브 시스템, 시스템의 집합, 제품군 등의 구현체

-소프트웨어 아키텍처 4+1 뷰란?

: 고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 소프트웨어적인 접근 방법.

: 4개의 분리된 구조로 구성되는 아키텍처 개념을 제시, 4개의 구조가 충돌되지 않는지, 시스템의 요구사항을 충족시키는지를 증명하기위해 유스케이스를 사용한다.

 

-소프트웨어 아키텍처 4+1 구성요소

: 4(논리 뷰, 구현 뷰, 프로세스 뷰, 배포 뷰) + 1(유스케이스 뷰)

[4] *논리 뷰 : 시스템의 기능적인 요구사항이 어떻게 제공되는지 설명해주는 뷰 : 설계자, 개발자 관점 *프로세스 뷰 : 시스템의 비기능적인 속성으로서 자원의 효율적인 사용,  병행 실행, 비동기, 이벤트 처리 등을 표현한 뷰 : 개발자, 시스템 통합자 관점 *구현 뷰 : 개발 환경 안에서 정적인 소프트웨어 모듈의 구성을 보여주는 뷰 : 컴포넌트 구조와 의존성을 보여주고 컴포넌트에 관한 부가적인 정보 정의 *배포 뷰 : 컴포넌트가 물리적인 아키텍처에 어떻게 배치되는가를 매핑해서 보여주는 뷰

[1] *유스케이스 뷰 : 유스케이스 또는 아키텍처를 도출하고 설계하며 다른 뷰를 검증하는데 사용되는 뷰 : 사용자, 설계자, 개발자, 테스트 관점

-소프트웨어 아키텍처 패턴이란?

: 소프트웨어를 설계할 때 참조할 수 있는 전형적인 해결 방식

: 주어진 상황에서의 소프트웨어 아키텍처에서 일반적으로 발생하는 문제점들에 대한 일반화되고 재사용 가능한 솔루션

 

-소프트웨어 아키텍처 패턴 필요성

: 고객과 의사소통을 통해 고객의 요구사항을 만족시키고, 소프트웨어 개발 생산성과 품질 확보.

: 개발에 대한 시행착오를 줄여 개발 시간 단축, 높은 품질의 소프트웨어 생산 가능

: 이미 검증된 구조로 개발하기 때문에 소프트웨어 개발을 안정적으로 수행 가능

: 시스템의 특성을 개발 전에 예측 가능.

 

-소프트웨어 아키텍처 패턴 유형

: 계층화 패턴, 클라이언트-서버 패턴, 파이프-필터 패턴, 브로커 패턴, 모델-뷰-컨트롤러 패턴 등..

*계층화 패턴 : 시스템을 계층으로 구분하여 구성하는 패턴 : 각 하위 모듈들은 특정한 수준의 추상화를 제공하고, 각 계층은 다음 상위 계층에 서비스를 제공. : 계층화 패턴은 서로 마주 보는 두 개의 계층 사이에서만 상호작용이 이루어짐.

*클라이언트-서버 패턴 : 하나의 서버와 다수의 클라이언트로 구성된 패턴 : 사용자가 클라이언트를 통해서 서버에 서비스를 요청하면 서버는 클라이언트에게 서비스 제공 : 서버는 계속 클라이언트로부터 요청을 대기

*파이프-필터 패턴 : 데이터 스트림을 생성하고 처리하는 시스템에서 사용 가능한 패턴 : 서브 시스템이 입력 데이터를 받아 처리하고, 결과를 다음 서브 시스템으로 넘겨주는 과정을 반복 : 필터 컴포넌트는 재사용성이 좋고, 추가가 쉽기 때문에 확징이 용이

*브로커 패턴 : 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용, 컴포넌트들은 원격 서비스 실행을 통해 상호작용이 가능한 패턴 : 컴포넌트 간의통신을 조정하는 역할 수행 : 서버는 자신의 기능들(서비스 및 특성)을 브로커에 넘겨주며, 클라이언트가 브로커에 서비스를 요청하면 브로커는 클라이언트를 자신의 레지스트리에 있는 적합한 서비스로 리다이렉션 함

*모델-뷰-컨트롤러 패턴(MVC 패턴) : 대화형 애플리케이션을 모델, 뷰, 컨트롤러 3개의 서브 시스템으로 구조화하는 패턴 : 각 부분이 별도의 컴포넌트로 분리되어 있어서 서로 영향을 받지 않고 개발 작업 수행 가능 : 컴포넌트를 분리하며 코드의 효율적인 재사용을 가능하게 하고, 여러 개의 뷰가 있어야 하는 대화형 애플리케이션 구축에 적합 : 모델 - 핵심 기능과 데이터 보관 : 뷰 - 사용자에게 정보 표시 : 컨트롤러 - 사용자로부터 요청을 입력받아 처리

-소프트웨어 아키텍처 비용 평가 모델이란?

: 아키텍처 접근법이 품질 속성에 미치는 영향을 판단하고 아키텍처의 적합성을 평가하는 모델

 

-소프트웨어 아키텍처 비용 평가 모델 종류

: SAAM, ATAM, CBAM, ADR, ARID

*SAAM(Software Architecture Analysis Method) :변경 용이성과 기능성에 집중, 평가가 용이하여 경험이 없는 조직에서도 활용 가능한 비용 평가 모델

*ARAM(Architecture Trade-off Analysis Method) : 아키텍처 품질 속성을 만족시키는지 판단 및 품질 속성들의 이해 상충관계까지 평가하는 모델

*CBAM(Cost Benefit Analysis Method) : ATAM 바탕의 시스템 아키텍처 분석 중심으로 경제적 의사결정에 대한 요구를 충족하는 비용 평가 모델

*ADR(Active Design Review) : 소프트웨어 아키텍처 구성요소 간 응집도를 평가하는 모델

*ARID(Active Reviews for Intermediate Designs) : 전체 아키텍처가 아닌 특정 부분에 대한 품질요소에 집중하는 비용 평가 모델

3)디자인 패턴

- 디자인 패턴(Design Pattern)이란?

: 소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴

 

-디자인 패턴 구성요소

: 패턴의 이름, 문제 및 배경, 솔루션, 사례, 결과, 샘플 코드

*패턴의 이름 : 디자인 패턴을 부를 때 사용하는 이름과 대자인 패턴의 유형

*문제 및 배경 : 디자인 패턴이 사용되는 분야 또는 배경, 해결하는 문제를 의미

*솔루션 : 디자인 패턴을 이루는 요소들, 관계 협동 과정

*사례 : 디자인 패턴의 간단한 적용 사례

*결과 : 디자인 패턴을 사용하면 얻게 되는 이점이나 영향

*샘플 코드 : 디자인 패턴이 적용된 원시 코드

-디자인 패턴 유형

: 목적(생성, 구조, 행위), 범위(클래스, 객체)

[목적] *생성 : 객체 인스턴스 생성에 관여, 클래스 정의와 객체 생성 방식을 구조화, 캡슐화를 수행하는 패턴 *구조 : 더 큰 구조 형성 목적으로 클래스나 객체의 조합을 다루는 패턴 *행위 :클래스나 객체들이 상호작용하는 방법과 역할 분담을 다루는 패턴

[범위] *클래스 : 클래스 간 관련성(상속을 다루는 패턴) : 컴파일 타임에 정적으로 결정 *객체 : 객체 간 관련성을 다루는 패턴 : 런타임에 동적으로 결정

-디자인 패턴 종류

: 생성 패턴, 구조 패턴, 행위 패턴

[생성 패턴] *Builder : 생성과 표기를 분리해서 복잡한 객체를 생성 *Prototype : 기존 객체를 복제함으로써 객체를 생성 *Factory Method : 생성할 객체의 클래스를 국한하지 않고 객체를 생성 *Abstract Factory : 동일한 주제의 다른 팩토리를 묶음 *Singleton : 한 클래스에 한 객체만 존재하도록 제한

[구조 패턴] *Bridge :구현뿐만 아니라, 추상화된 부분까지 변경해야 하는 경우 활용 *Decorator : 객체의 결합을 통해 기능을 동적으로 유연하게 확장 *Facade : 통합된 인터페이스 제공 *Flyweight : 여러 개의 '가상 인스턴스'를 제공하여 메모리 절감 *Proxy : 특정 객체로의 접근을 제어하기 위한 용도로 사용 *Composite : 복합 객체와 단일 객체를 동일하게 취급 *Adapter : 인터페이스가 호환되지 않는 클래스들을 함께 이용할 수 있도록 타 클래스의 인터페이스를 기존 인터페이스에 덧씌움

[행위 패턴] *Mediator : 상호작용의 유연한 병경을 지원 *Interpreter : 문법 자체를 캡슐화하여 사용 *Iterator : 내부구조를 노출하지 않고, 복잡 객체의 원소를 순차적으로 접근 가능하게 해주는 행위 패턴 *Template Method : 상위 작업으 ㅣ구조를 바꾸지 않으면서 서브 클래스로 작업의 일부분을 수행 *Observer : 객체의 상태 변화에 따라 다른 객체의 상태도 연동, 일대다 의존 *State : 객체의 상태에 따라 행위 내용을 변경 *Visitor : 특정 구조를 이루는 복합 객체의 원소 특성에 따라 동작을 수행할 수 있도록 지원하는 행위 *Command : 요구사항을 객체로 캡슐화 *Strategy : 행위 객체를 클래스로 캡슐화해 동적으로 행위를 자유롭게 변환 *Memento : 객체를 이전 상태로 복구시켜야 하는 경우, '작업 취소(Undo)' 요청 가능 *Chain of Responsibility : 한 요청을 2개 이상의 객체에서 처리

4)현행 시스템 분석서 작성 및 검토

-현행 시스템 관련 자료 수집

: 수집 자료의 특성에 따라 3개의 팀을 구성한다.

: 정보시스템 구성/기능 및 인터페이스 자료 수집팀, 현행 시스템 아키텍처 및 소프트웨어 자료 수집팀, 하드웨어 및 네트워크 자료 수집팀

*정보시스템 구성/기능 및 인터페이스 자료 수집팀 : 정보시스템 구성도, 정보시스템 기능 구성도, 정보시스템 인터페이스 현황 *현행 시스템 아키텍처 및 소프트웨어 자료 수집팀 : 현행 시스템 아키텍처 구성도, 소프트웨어 구성도 *하드웨어 및 네트워크 자료 수집팀 : 하드웨어 구성도, 네트워크 구성도

-수집 자료의 분석

: 수집된 정보들을 취합/정제하고, 중복되거나 유효하지 않은 정보들을 삭제한다.

: 불명확한 부분은 체크한 후 분석 및 설계 단계를 통해 구체적으로 조사한다.

: 현행 시스템의 이슈 및 문제점을 파악한다.

 

-분석한 결과를 기반으로 산출물 작성

: 각 취득 자료를 분석한 결과를 기반으로 산출물을 작성한다.

: 현행 시스템의 이슈나 문제점을 산출물에 상세하게 포함하여 작성한다.

 

-산출물에 대한 검토 수행

: 팀별로 작성된 산출물을 상호 검토하여 의견을 제시한다.

: 다른 팀의 검토의견을 반영하여 산출물을 수정하고 최종 완료한다.

---

4.개발 기술 환경 정의(⭐⭐⭐)

1)운영체제 현행 시스템 분석

-운영체제란?

: 컴퓨터 시스템이 제공하는 모든 하드웨어, 소프트웨어를 사용할 수 있도록 해주고, 컴퓨터 사용자와 컴퓨터 하드웨어 간의 인터페이스를 담당하는 프로그램.

 

-운영체제 현행 시스템 분석 시 고려 사항

: 품질 측면(신뢰도, 성능)과 지원 측면(기술 지원, 주변 기기, 구축 비용) 등을 고려한다.

[품질 측면] *신뢰도 : 장기간 시스템 운영 시 운영체제의 장애 발생 가능성 : 운영체제의 버그로 인한 재기동 여부 *성능 : 대규모 및 대량 파일 작업(배치 작업) 처리 : 지원 가능한 메모리 크기(32비트. 64비트)

[지원 측면] *기술 지원 : 공급사들의 안정적인 기술 지원 : 오픈 소스 여부 *주변 기기 : 설치 가능한 하드웨어 : 다수의 주변 기기 지원 여부 *구축 비용 : 지원 가능한 하드웨어 비용 : 설치할 응용 프로그램의 라이선스 정책 및 비용 : 유지 및 관리 비용

-운영체제 종류 및 특징

: 대표적으로 PC, 모바일 운영체제로 나뉜다.

[PC] *윈도즈(Windows) : 저작자 - Microsoft : 중/소규모 서버, 일반 PC 등 유지, 관리 비용 장점 *유닉스(UNIX) : 저작자 - IMB, HP, SUM : 대용량 처리, 안정성 높은 엔터프라이즈급 서버 *리눅스(Linux) : 저작자 - Linus Torvalds : 중/대규모 서버 대상, 높은 보안성 제공

[모바일] *안드로이드(Android) : 저작자 - Google : 리눅스 운영체제 위에서 구동, 휴대용 장치를 위한 운영체제 : 개발자들이 자바, 코틀린 언어로 응용 프로그램을 작성할 수 있다. *iOS : 저작자 - Apple : 스파트폰, 태블릿PC의 높은 보안성과 고성능 제공

2)네트워크 현행 시스템 분석

-네트워크(network)란?

: 컴퓨터 장치들의 노드 간 연결(데이터 링크)을 사용하여 서로에게 데이터를 교환할 수 있도록 하는 기술.

: 데이터 링크들은 광케이블과 같은 유선 매체 또는 와이파이와 같은 무선 매체를 통해 확립된다.

 

-OSI 7계층(Layer)

:네트워크 통신에서 생긴 여러 가지 충돌 문제를 완화하기 위해 국제 표준화 기구(ISO:International Standardization Organization)에서 제시한 네트워크 기본 모델이다.

*응용 계층 : 사용자와 네트워크 간 응용서비스 연결, 데이터 생성 : HTTP, FTP *표현 계층 : 데이터 형식 설정과 부호교환, 암/복호화 : JPEG, MPEG *세션 계층 : 연결 접속 및 동기제어 : SSH, TLS *전송 계층 : 신뢰성 있는 통신 보장, 데이터 분할과 재조립, 흐름 제어, 오류 제어, 혼잡제어 등.. : TCP, UDP *네트워크 계층 : 단말 간 데이터 전송을 위한 최적화된 경로 제공 : IP, ICMP *데이터 링크 계층 : 인접 시스템 간 데이터 전송, 전송오류 제어, 동기화 흐름 제어 기능 제공, 오류검출 / 재전송 등 기능 제공 : 이더넷 *물리 계층 : 0과 1의 비트 정보를 회선에 보내기 위한 전기적 신호 변환 : RS-232C

-네트워크 현행 시스템 분석

: 현행 시스템이 구성된 네트워크 구조를 네트워크 구성도를 통해 분석한다.

: 네트워크 구성도를 통해 서버 위치, 서버 간 연결 방식을 파악할 수 있다.

: 백본망, 라우터, 스위치, 게이트웨이, 방화벽 등을 대상으로 분석한다.

: 네트워크 분석 시 물리적인 위치 관계 파악, 조직 내 보안 취약성 분석 및 대응이 가능하다.

: 네트워크 장애 발생 추적 및 대응 등의 다양한 용도로 활용할 수 있다.

 

3)DBMS 현행 시스템 분석

-DBMS(Database Management System)란?

: 데이터베이스라는 데이터의 집합을 만들고, 저장 및 관리할 수 있는 기능들을 제공하는 응용 프로그램

 

-DBMS의 기능

: 중복 제어, 접근 통제, 인터페이스 제공, 관계 표현 등..

*중복 제어 : 동일한 데이터가 여러 위치에 중복으로 저장되는 현상 방지 *접근 통제 : 권한에 따라 데이터에 대한 접근 제어 *인터페이스 제공 : 사용자에게 SQL 및 CLI, GUI 등 다양한 인터페이스 제공 *관계 표현 : 서로 다른 데이터 간의 다양한 관계를 표현할 수 있는 기능 제공 *샤딩/파티셔닝 : 구조 최적화를 위해 작은 단위로 나누는 기능 제공 *무결성 제약조건 : 무결성에 관한 제약조건을 정의/검사하는 기능 제공 *백업 및 회복 : 데이터베이스 장애 발생 시 데이터의 보존 기능 제공

-DBMS 현행 시스템 분석

: 데이터 베이스의 성능 측면(가용성, 성능, 호환성), 지원 측면(기술 지원, 구축 비용)을 분석한다.

[성능 측면] *가용성 : 장기간 시스템을 운영할 때 장애 발생 가능성 : 백업 및 복구 편의성 : DBMS 이중화 및 복제 지원 여부 *성능 : 대규모 데이터 처리 성능 : 대량 거래 처리 성능 : 다양한 튜닝 옵션 지원 여부 : 비용 기반 최적화 지원 및 설정의 최소화 지원 여부 *호환성 : 설치 가능한 운영체제 종류 : 다양한 운영체제에서 지원되는 JDBS, ODBS

[지원 측면] *기술 지원 : 공급 업체들의 안정적인 기술 지원 여부 : 다수의 사용자 간의 정보 공유 여부 : 오픈 소스 여부 *구축 비용 : 라이선스 정책 및 비용 : 유지 및 관리 비용

4)미들웨어의 현행 시스템 분석

-미들웨어(Middleware)란?

: 응용 프로그램과 프로그램이 운영되는 환경 간에 원만한 통신이 이루어질 수 있도록 제어해주는 소프트웨어

:운영체제와 소프트웨어 애플리케이션 사이에 위치하고 있다.

: 대표적인 미들웨어는 WAS가 있다

 

-웹 애플리케이션 서버(WAS)란?

: 서버계층에서 애플리케이션이 동작할 수 있는 환경을 제공하고 안정적인 트랜잭션 처리와 관리, 다른 기종 시스템과의 애플리케이션 연동을 지원하는 서버

 

-미들웨어의 현행 시스템 분석

: 미들웨어의 성능 측면(가용성, 성능), 지원 측면(기술 지원, 구축 비용)

[성능 측면] *가용성 : 장기간 시스템을 운영할 때 장애 발생 가능성 : 안정적인 트랜잭션 처리 능력 : WAS의 버그 등을 개선하는 패치 설치를 위한 재기동 기능 지원 여부 : WAS 이중화 지원 여부 *성능 : 대규모 데이터 처리 성능 : 다양한 설정 옵션 지원 여부 : 가비지 컬렉션의 다양한 옵션 기능 여부

[지원 측면] *기술 지원 : 공급 벤더들의 안정적인 기술 지원 여부 : 다수의 사용자들 간의 정보 공유 여부 : 오픈 소스 여부 *구축 비용 : 라이선스 정책 및 비용 : 유지 및 관리 비용 : 총 소유 비용

5)오픈 소스 사용 시 고려 사항

: 라이선스의 종류, 사용자 수, 기술의 지속 가능성 등을 고려해야한다.

 

6)개발 기술 환경 요구사항 파악

-기술 환경 정의를 위한 자료 수집

: 수집 자료 목록 및 조사 항목을 설정한다.

 

-조사 자료 분석 및 갭라 기술 환경 결정

: 운영체제, 데이터베이스, 웹 애플리케이션 서버 등을 결정한다.

: 조사 자료 분석 시 각 항목별 고려 사항을 반영하여 개발 기술 환경을 결정한다.

 

-요구사항 정의서, 목표 시스템 구성도 반영 및 검토

: 운영체제, 데이터베이스, 웹 애플리케이션 서버 등 시스템 용량 산정 결과를 요구사항 정의서, 목표 소프트웨어 구성도, 목표 하드웨어 구성도에 반영한다.

:각 팀별로 작성된 산출물을 상호 검토하여 의견을 제시한다.

: 다른 팀의 검토의견을 반영하여 산출물을 수정하고 최종 완료한다.

---

오늘의 공부는 여기까지 입니다!😊

다음 공부내용으로 또 만나요!

도움이 되셨다면 공감버튼💕 감사합니다!