정보처리기사 실기 - 1. 요구사항 확인(1) /현행시스템/아키텍처

1) 현행 시스템 파악

• 현행 시스템 분석을 위한 단계

1단계 : 현행 시스템 분석 

• 현행 시스템 분석서 작성 (하드웨어 구성 -> 네트워크 구성 -> 현행 시스템 구성 장단점 분석 -> 개선 방안 도출)
• 고객 아카데미 요구사항 파악

 

2단계 : 목표시스템 아키텍처 선정 단계

• 목표 시스템 아키텍처 정의 (정의서 작성)
• 소프트웨어 아키텍처 정의서 작성 (아키텍처 스타일, 표준 패턴 정의 -> 시스템의 표준 연계 구조 정의 -> 소프트웨어 아키텍처 제약사항)
• 시스템 아키텍처 정의서 작성 (시스템 구성, 하드웨어 구성, 네트워크 구성, 소프트웨어 구성, 제약사항 기술)
• 이키텍처 평가 (유틸리티 트리를 작성하여 요구사항 간 상호 관계나 상충관계 파악 -> 아키텍처 평가 결과서 작성)

 

3단계 : 목표 시스템 개발 표준 정의 단계

• 목표 시스템 모델링 표준 정의
• 표준 표기법 (유스케이스는 액터가 시작하는 비즈니스 이벤트에 의해 흐름을 시작 -> 사용자 관점에서는 하나의 업무 단위로 인식 -> 독립적, 완결적 단위 -> 각 액터가 시스템에 요구하는 기능이 무엇인지를 중심으로 고려 -> 보안, 성능 같은 외적 사항 배제)

 

구성/기능/인터페이스 파악 -->

아키텍처 및 소프트웨어 구성 파악 -->

하드웨어 및 네트워크 구성

 

* 럼바우 모델 - 객체, 동적, 기능

* 분산 아키텍처 : 유저 인터페이스 티어와 비즈니스 객체 사이에 RMI를 사용

* EAI(Enterprise Application Integration) : 기업 어플리케이션 통합, 각종 어플리케이션 간에 상호 연동이 가능하도록 통합하는 솔루션

* Open API :  공통 서비스를 만들고, 이를 API로 호출하여 서비스를 사용할 수 있는 방식

* 유틸리티 트리 : 재사용성, 유지보수성, 성능, 상호운영성, 개발편의성, 사용편의성, 가용성, 무결성을 사례별로 검토하는 트리

 -> 유틸리티 : 시스템이 제공해야 하는 모든 품질

 -> 모든 시스템 이해관계자와 프로젝트 평가팀이 시스템 필수 성공요소를 한번에 파악하는 도구

 

유틸리티 트리

 

 

- 프로그램 표준 정의

 -> 명명 표준, 명명 규칙

 

- 프로그램 개발 표준

-> Core package structive 개발 표준 작성

• presentation layer : 사용자 화면에 보여지는 것들
• business layer : 비즈니스 로직, 업무분류 체계, 디렉토리 구조 등 개발 표준 정의
• Action Class(WebWork) : 개발 표준

 

- 개발환경 표준 정의

 -> 개발 환경 표준 정의서 작성

 

 

• 소프트웨어 아키텍처

 -> 개념적 설계도

 

- 아키텍처 표준, IEEE 1471

 -> 유연성과 확장성을 가진 개념적 프레임워크 프로토콜

  -> 아키텍처 프레임워크 : 다양한 아키텍처를 개발하기 위해 사용될 수 있는 틀

 

- IEEE 1471 특징

 -> 표준화, 독립성, 범용성, 의사소통, 가이드라인

 

- 아키텍처는 아키텍처 기술서로 표현

 -> 이해당사자의 관심사항을 각각의 뷰와 모델로 아키텍처 기술서를 표현

 

* 마이크로 서비스 아키텍처 : 하나의 큰 어플리케이션을 독립된 서비스 단위의 여러개의 작은 어플리케이션으로 나누어 변경과 조립이 유연

* 람다 아키택처 : Batch와 Realtime 모두 지원, 빅데이터 실시간 처리 아키텍처

* 카파 아키텍처 : 람다의 코드 공유 복잡성을 해결하기 위해 배치 레이어를 제거

 -> 모든 계산을 피드레이어에서 스트림으로 처리

 

- iEEE 1471 프레임워크 구성

•  Architecture Description(AD) : 아키텍처를 기록하기 위한 산출물들 (아키텍처 기술서), 하나의 AD는 관심사와 이에 대응하는 하나 이상의 이해 관계자와 연관됨
• 이해관계자 : SW 시스템 개발에 관련된 모든 사람과 조직을 의미
• 관심사 : 동일한 시스템에 대해 각 이해관계자들은 서로 다른 의견과 목표
• 뷰 & 뷰포인트 (뷰 -> 이해관계자들과 이들이 가지는 생각이나 견해로부터 전체 시스템을 표현, 뷰포인트 -> 뷰를 구성하기 위한 규칙을 정의하는 패턴 -> 각각의 뷰에 일대일로 대응 됨)

 

- 4+1 뷰 모델

 -> 고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점으로 바라보는 소프트웨어적 관점

 -> 유스케이스 하나가 표현하는 요구사항을 만족시키려면 4개 뷰가 협업 필요

 -> 4+1이라는 것은 유스케이스가 나머지 4개 뷰에 모두 참여하면서 영향을 준다는 뜻

* 4+1 뷰 구조

• Use-Case View : 요구사항을 분석해 시스템의 기능을 명세화 -> 이해당사자 : End-User
• Logical View : Use-Case View에 표현된 요구사항들을 시스템의 구조와 행동으로 명세화 -> 이해당사자 : Analysts, Designers
• Process View : 쓰레드와 프로세스에 의한 동작을 중점적으로 표현 -> 이해당사자 : System Integreters
• Implementation(Development) View : Logical과 Process에서 설계된 UML모델 요소들을 물리적인 소프트웨어 모듈로 표현하는데 사용 -> 이해당사자 : 프로그래머
• Deployment(Phsical) View : Implementation에서 정의한 UML 모델 요소들을 배치할 하드웨어 표현 -> 이해당사자 : System-Engineer

 

- 아키텍처 드라이버

 아키텍처 요구사항 항목들을 분석하여 설계에 직접적으로 근간이 될 수 있는 항목들을 추출하고 정제

 -> 설계의 원칙 : 기능 요구사항, 품질 속성, 제약사항

 -> 시스템의 다은 여러 기능 요소와 어떤 요구사항과 상호 작용을 갖게 되는지 판단

  -> 셋 중 하나에 해당하면 아키텍처 드라이버 

  -> 일반적으로 10개 미만이 적정

 

* 기능 요구사항 : 시스템이 수행해야 하는 기능

* 제약사항 : 시스템에 영향을 주는 사전에 고려해하는 제약적인 요구사항

* 품질 요구사항 : 품질 및 성능, 안정성 등 수행해야 하는 품질적 고려사항

 

- 아키텍처 품질 속성 시나리오

- 품질 속성 시나리오 : 요구사항과 관련된 품질 속성들을 도출하고 구체적으로 명세

 -> 시스템에 대해 자극과 반응을 측정함으로써 품질 요구 사항을 찾아내기 위한 시나리오

 -> 품질 속성 시나리오를 바탕으로 시스템이 받아들여야할 자극과 시스템이 제공해야 할 반을을 파악하고 품질 속성 달성 방안을 결정

• 자극의 원천
• 자극
• 대상체
• 환경 : 특정 상황이나 환경, 해당 자극이 발행할 때나 혹은 다른 조건이 만족 되었을 때 시스템의 상태
• 응답
• 응답 측정

 

- SW 아키텍처 스타일

 아키텍처 설계에서 반복해서 나타나는 문제를 해결하고 만족시켜야 하는 시스템 품질속성을 달성할 수 있는 방법을 정리한 패턴

 -> 아키텍처 스타일의 유형별 분류

• 데이터 중심(Data-Centered) : 데이터의 정합성을 위한 품질 특성을 구현하기 위한 구성, 데이터 저장소에 대한 접근과 갱신에 초점       -> * Repository(저장소 오류가 시스템 전제에 영향), * Blackboard
• 데이터 흐름(Data-Flow) : 연속적으로 연결된 입력 데이터에 대한 일련의 변형동작으로 구성, 데이터의 재사용과 수정성 구현에 초점 -> * Batch Sequence, * Pipe and Filters(서브시스템을 필터, 서브시스템간 관계를 파이프라 함, 이해가 쉽고 필터 단위 재사용, Output or Input으로 들어가기 때문에 필터만 Data Format이 같아야 함)
• 가상머신 : SW 시스템의 이식성 구현에 초점, 시스템이 구현될 HW나 SW에서의 시뮬레이션 수행 -> * Interpreter, * Rule-Based System
• 호출과 리턴 : 네트워크 상에 연결되는 작은 단위 서브루틴으로 구성하며 처리 -> * Main Program & Sub Routine, * 원격 Procedure call
• 독립적 컴포넌트 : 상호간 메세지 통신 -> 컴포넌트, CBD, Web Service -> * Communication Processing, * Event System

 

- 주요 아키텍처 스타일 상세 설명

• 저장소 구조
• Pipe & Filters
• MVC 구조 : 모델(Model), 뷰(View), 제어(Controller,상호작용 정의)로 분리 -> 장점 : Data 구조가 변해도 다른 컴포넌트에 영향 없음 , 하나의 데이터를 여러 방법으로 표현 가능 -> 단점 : 시스템이 복잡해짐
• 클라이언트/서버 구조 : 장점 : Data 분배 쉬움, 클라이언트는 매우 편리 -> 단점 : 서버의 의존성이 강해 서버 오류시 시스템 중지, 네트워크의 영향 많이 받음, 서버 관리 어려움
• 계층 구조(Layered) : 추상화의 성질, OSI 7계층이나 Internet 5계층 등 -> 장점 : 유지보수 용이, 각 층을 쉽게 변경 가능 -> 단점 : Layer 분리 어려움 및 성능 저하 

 

다음 포스팅

정보처리기사 실기 - 1. 요구사항 확인(2) /애자일 방법