본문 바로가기
정보처리기사

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

by 하겐모아 2024. 1. 17.

🎇 UML (Unified Modeling Language)

> 시스템 분석, 설계, 구현 등 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 상호 간의 의사소통이 원활하게  이루어지도록 표준화한 대표적인 객체지향 모델링 언어

> 물, 계, 이어그램 으로 구성

 

📢 관계

> 사물과 사물사이의 연관성을 표현한것

 

📌 연관관계(Association)

> 2개 이상의 사물이 서로 관련되어 있는 관계

> 실선 화살표로 표시

 

📌  집합관계 (Aggregation)

> 하나의 사물이 다른 사물에 포함되어 있는 관계

> 속이 빈 마름모

📌 포함관계(Compositon)

> 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계

> 속이 채워진 마름모

📌 일반화 관계 (Generalization)

> 하나의 사물이 다른 사물에 비해 더 일반적이거나 구체적인 관계

> 구체적(하위)인 사물에서 일반적(상위)인 사물 쪽으로 속이 빈 화살표 

📌  의존 관계 (Dependency)

> 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계

> 점선 화살표로 표시

📌 실체화 관계 (Realization)

> 할 수 있거나 해야 하는 기능, 서로를 그룹화 할 수 있는 관계

> 속이 빈 점선 화살표

 

#01. 요구사항 확인

(1) 소프트웨어 생명 주기

📌 소프트웨어 생명 주기
> 소프트웨어를 개발하기 위한 설계, 운용, 유지보수 등의 과정을 각 단계별로 나눈 것


- 대표적인 생명 주기

📌폭포수 타입
> 각 단계를 확실히 매듭짓고 그 결과를 검토하여 승인 과정을 거친 후에 다음 단계를 진행하는 개발론

📌프로토타입 모형
> 실제 개발된 소프트웨어에 대한 견본품(Prototype)을 만들어 최종 결과물을 예측하는 모형

📌나선형 모형
> 여러번의 소프트웨어 개발과정을 거쳐 점진적으로 최종 소프트웨어를 개발

📌 애자일 모형
> 민첩한, 기민한의 의미로, 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발

- 애자일의 예
> 스크럼, XP...

📌 소프트웨어 공학
> 여러 가지 방법론과 도구, 관리 기법들을 통하여 소프트웨어의 품질과 생산성 향상을 목적으로 한다.


(2) 스크럼 기법

📌 스크럼
> 팀이 중심이 되어 개발의 효율성을 높이는 기법 (계획하여 진행(스프린트) 한 후 회의와 검토를 거쳐 회고한다.)

📌 백로그
> 제품 개발에 필요한 요구사항을 모두 모아 우선순위를 부여해 놓은 목록

 

📌 번 다운 차트

> 스크럼에서 해당 스프린트가 계획된 대로 나아가고 있는지, 정해진 목표를 달성하기 위해 팀 차원의 조정이 필요한지 알 수 있게 하고, 백

로그 대비 남아있는 시간을 확인할 수 있는 도구이다.

 

📌 칸반 보드

> Toyota에서 처음 사용한 Agile 프로젝트 관리에 사용되는 시각화 도구로 카드 형태로 나타내고 수행된 활동, 진행 중인 작업 및 보류 중인 활동을 구별할 수 있는 도구이다.


(3)XP 

📌 XP (eXtreme Programming)
> 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 높임
> 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발하는 것을 목적

📌 XP의 5대 가치
용기, 단순성, 의사소통, 피드백, 존중

- XP의 주요실천 방법
📌 Pair Programming (짝 프로그래밍)
> 다른 사람과 함께 프로그래밍을 수행함으로써 개발에 대한 책임을 공동으로 나눠 갖는 환경

📌 Collective Ownership (공동코드소유)
> 개발 코드에 대한 권한과 책임을 공동으로 소유함

📌 Test-Driven Development [TDD] (테스트 주도 개발) 
> 작성해야 하는 프로그램에 대한 테스트를 먼저 수행하고 이 테스트를 통과할 수 있도록 실제 프로그램의 코드를 작성한다는 원리이다.

📌 Whole Team (전체팀)
> 개발에 참여하는 모든 구성원들은 각자 자신의 역할이 있고 그역할에 대한 책임을 가져야 함.

📌 Continuous Integration (계속적인 통합)
> 모듈 단위로 나눠서 개발된 코드들은 하나의 작업이 마무리될 때마다 지속적으로 통합됨.

📌 Refactoring 
> 프로그램 기능의 변경없이 시스템을 재구성함. / 중복제거 단순화 등을 위해 시스템 재구성

(5) 개발 기술 환경 파악
📌 운영체제 (Operating System)
> 컴퓨터 시스템의 자원을 효율적으로 관리하며, 사용자가 컴퓨터를 편리하고 효율적으로 사용할 수 있도록 환경을 제공하는 소프트웨어

📌 데이터베이스 관리 시스템 (DBMS : DataBase Management System)
> 사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해 주고, 데이터베이스를 관리해 주는 소프트웨어

📌 웹 애플리케이션 서버 (WAS)
> 사용자의 요구에 따라 변하는 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어

(7) 요구사항

📌 요구공항
> 무엇을 개발해야 하는지 요구사항을 정의하고, 분석 및 관리하는 프로세스를 연구하는 학문

(8) 요구사항 분석
📌 요구사항 분석
> 소프트웨어 개발의 실제적인 첫 단계로, 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화 하는 활동

📌 자료 흐름도 (DFD : Data Flow Diagram)
> 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법

📌 자료 흐름도 기호
> 프로세스(Process), 자료흐름(Data Flow), 자료 저장소(Data Store), 단말(Terminator)

 

📢 비용산정 모형 분류

📌 하향식산정방법

> 전문가 판단

> 델파이 기법 : 전문가의 경험적 지식을 통한 문제 해결 및 미래예측을 위한 기법

 

📌 상향식산정방법

> LoC(Lines of Code) 코드라인수 : 원시 코드 라인수의 낙관치, 중간치, 비관치를 측정하여 예측치를 구해 비용산정

> COCOMO모형 : 보헴이 제안한 모형으로 프로그램 규모에 따라 비용산정

> Putnam모형 : Rayleigh-Norden 곡선의 노력 분포도 

> 기능점수(FP)모형 : 소프트웨어 기능을 증대시키는 요인별로 가중치를 부여하여 비용산정

 

📢 일정관리 모델

📌 CPM (주 공정법)

> 여러 작업의 수행 순서가 얽혀 있는 프로젝트의 일정을 계산하는 기법

> 프로젝트의 일정을 계산하는 기법으로 모든 자원 제약 사항을 배제한 상태로 프로젝트의 시작과 끝을 나타내는 노드와 노드 간을 연결을 통해 공정을 계산하기 위한 액티비티 표기법 

 

📌 PERT

> 일의 순서를 계획적으로 정리하기 위한 수렴 기법, 비관치, 중간치, 낙관치 3점 추정방식을 통해 일정을 관리

 

 

#요구사항 정의

📌 기능 요구사항

> 시스템이 무엇을 하는지, 어떤 기능을 하는지 등 사용자가 시스템을 통해 제공받기를 원하는 기능이나 시스템이 반드시 수행해야 하는 기능을 의미

📌 비기능 요구사항

> 품질이나 제약사항과 관련된 요구사항, 시스템의 장비 구성, 성능, 인터페이스, 테스트, 보안 등의 요구사항

 

CH02 현행 시스템 분석

 

📢 소프트웨어 아키텍처

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

 

📢 소프트웨어 아키텍처 4 + 1 뷰 [유논프구배]

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

 

📌 유스케이스 뷰 

>  유스케이스 또는 아키텍처를 도출하고 설계하며 다른 뷰를 검증하는데 사용되는 뷰

📌 논리 뷰

> 시스템의 기능적인 요구사항이 어떻게 제공되는지 설명해주는 뷰

📌 프로세스뷰 

> 시스템의 비기능적인 속성으로 자원의 효율적인 사용, 병행, 실행, 비동기, 이벤트 처리 등을 표현한 뷰로 개발자, 시스템 통합자 관점의 뷰.

📌 구현 뷰

> 개발 환경 안에서 정적인 소프트웨어 모듈의 구성을 보여주는 뷰, 컴포넌트 구조와 의존성을 보여주고 부가적인 정보 정의

📌 배포 뷰

> 컴포넌트가 물리적인 아키텍처에 어떻게 배치되는가를 매핑해서 보여주는 뷰

> 물리적인 시스템을 구성하고 있는 각 부분들의 분산 형태와 설치에 초점을 둔다.

 

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

 

📌 계층화 패턴

> 시스템을 계층으로 구분하여 구성하는 패턴

📌 클라이언트-서버 패턴

> 하나의 서버와 다수의 클라이언트로 구성된 패턴

📌 파이프-필터 패턴

> 데이터 스트림을 생성하고 처리하는 시스템에서 사용 가능한 패턴, 재사용성이 좋고 추가가 쉬워 확장에 용이

> 결과를 다음 서브 시스템으로 넘겨주는 과정을 반복하는 패턴이다.

📌 모델 뷰 컨트롤러 패턴 (MVC패턴)

> 대형 애플리케이션을 3개의 서브 시스템으로 구조화한 패턴, 컴포넌트로 분리되어 있어 서로 영향을 받지 않고 개발 작업 수행 가능

 

#디자인 패턴

> 소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 것으로 구성요소에는 이름, 문제 및 배경, 솔루션, 사례 등이 있다.

 

📢 생성 패턴

📌 builder : 복잡한 인스턴스를 조립해 만드는 구조

📌 prototype : 처음부터 일반적인 원형을 만들어 놓고, 그것을 복사한 후 필요한 부분만 수정해 사용하는 패턴

📌 factory method : 상위 클래스에서 인터페이스 정의, 하위클래스에서 인스턴스 생성

📌 abstract factory : 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스를 제공

📌 singleton : 전역 변수 사용하지 않고 객체 하나만 생성, 그 객체는 어디서든지 참조할 수 있음

 

📢 구조 패턴

📌 Bridge : 기능 계층과 구현 계층을 연결, 구현부에서 추상 계층 분리

📌 Decorator : 기존에 구현되어 있는 클래스에 필요한 기능 추가해 나감

📌 Facade : 복잡한 시스템에 대해 단순한 인터페이스 제공, 시스템 구조에 대한 파악 쉽게

📌 Flyweight : 메모리 절약, '클래스의 경량화' 목적

📌 Proxy : 실제 객체에 대한 대리 객체

📌 Composite : 객체들의 관계를 트리 구조로 구성