Post

정보처리기사 실기 :: 1장 요구사항 확인

정보처리기사 실기 :: 1장 요구사항 확인

1장 요구사항 확인

1) 현행 시스템 파악

  • 현재 개발하고자 하는 시스템의 개발 범위를 설정하기 위해 구성과 기능, 연계정보, 소프트웨어, 하드웨어, 네트워크의 구성을 파악하는 과정을 의미한다.


2) 현행 시스템 파악 절차

  • 현행 시스템 구성 파악: 기간 업무, 지원 업무
  • 현행 시스템 기능 파악: 제공하는 기능 파악, 계층형 표시
  • 인터페이스 현황 평가: 데이터 종류, 통신규약, 연계 유형
  • 아키텍처 구성 파악: 업무 수행 기술 요소들이 사용되는지 최상위 수준에서 파악
  • 소프트웨어 구성 파악: 소프트웨어 제품명, 용도, 라이센스 수, 적용 방식 명시
  • 하드웨어 구성 파악: 서버의 주요 사양, 서버의 이중화, 수량
  • 네트워크 구성 파악: 네트워크 구성 파악을 위해 네트워크 연결 방식을 구성도로 작성


3) 소프트웨어 아키텍처

  • 여러가지 소프트웨어 구성요소와 외부 특성, 구성요소 간의 관계를 표현하는 시스템 구조
  • 구성요소 간의 관계를 표현하는 시스템의 구조나 구조체


4) 소프트웨어 아키텍처 프레임워크

  • 소프트웨어 집약적인 시스템에서 아키텍처가 표현해야 하는 내용 및 이들 간의 관계를 제공하는 아키텍처 표준 기술을 의미한다.
  • 기본 구조, 소프트웨어의 베이스
  • 역할: 품질유지, 원칙, 지침
  • 동일한 아키텍쳐 = 기본 구조가 같은 여러 형태의 결과물


*소프트웨어 프레임워크의 특징

  • 모듈화(Modularity): 프레임워크는 인터페이스에 의한 캡슐화를 통해서 모듈화를 강화하고 설계와 구현의 변경에 따르는 영향을 극소화하여 소프트웨어의 품질을 향상시킨다.
  • 재사용성(Reusability): 프레임워크가 제공하는 인터페이스는 반복적으로 사용할 수 있는 컴포넌트를 정의할 수 있게 하여 재사용성을 높여준다. 또는 재사용성은 소프트웨어의 품질을 향상시킬 뿐만 아니라 개발자의 생산성도 높여준다.
  • 확장성(Extensibility): 프레임워크는 다형성을 통해 애플리케이션이 프레임워크의 인터페이스를 넓게 사용할 수 있게 한다. 또한 애플리케이션 서비스와 특성을 변경하고 프레임워크를 애플리케이션의 가변성으로부터 분리함으로써 재사용성의 이점을 얻게 한다.
  • 제어의 역흐름(Inversion of Control): 프레임워크 코드가 전체 애플리케이션의 처리 흐름을 제어하여 특정 이벤트가 발생할 때 다형성을 통해 애플리케이션이 확장한 메서드를 호출함으로써 제어가 프레임워크로부터 애플리케이션으로 반대로 흐르게 한다.


5) 소프트웨어 아키텍처 4+1 뷰

  • 고객의 요구사항을 정리해둔 시나리오 4개의 관점으로 바라보는 소프트웨어적인 접근 방법
  • 유스케이스 뷰: 아키텍처를 도축하고 설계하는 작업을 주도하는 뷰
  • 논리 뷰: 설계 모듈의 추상화, 클래스 식별 -> 클래스 다이어그램
  • 프로세스 뷰: 런타임시 스레드와 프로세스 사이의 상호작용
  • 배포 뷰: 물리적인 노드의 구성 -> 배포 다이어그램
  • 구현 뷰: 정적인 소프트웨어 구현 -> 컴포넌트 뷰, 컴포넌트 다이어그램


*런타임: 컴퓨터 프로그램이 실행되고 있는 동안의 동작 상태

*스레드: 프로세스의 실행을 담당하는 실행의 기본 단위

*프로세스: 운영체제가 관리하는 실행 단위이며 PCB를 가진 시스템

*프레임워크: 소프트웨어의 특정 부분을 설계 및 구현시 재사용 가능하도록 클래스 제공


6) 개발 기술 환경 정의

*운영체제: 사용자와 하드웨어의 인터페이스 역할을 하며 컴퓨터 시스템의 자원을 관리하는 소프트웨어

-키워드: 신뢰성, 성능, 기술 지원, 주변 기기, 구축 비용


*DBMS

  • 사용자와 Database 사이에서 사용자의 요구에 따라 정보를 생성해주고 Database를 관리해주는 소프트웨어
  • 데이터의 중복성과 종속성을 해결
  • 키워드: 가용성, 성능, 기술 지원, 상호 호환성, 구축비용


*JDBC: 자바 언어를 이용하여 DB에 접근하여 관리할 수 있는 인터페이스

*ODBC: 응용프로그램에서 DB에 접근하여 데이터를 관리할 수 있는 표준 인터페이스


*미들웨어: 운영체제와 소프트웨어 Application 사이에서 원만한 통신이 이루어질 수 있도록 중개 및 제어 역할을 하는 소프트웨어

*미들웨어의 종류

  • DB(Database): 데이터베이스 벤더에서 제공하는 클라이언트에서 원격의 데이터베이스와 연결하기 위한 미들웨어


  • RPC(Remote Procedure Call): 응용 프로그램의 프로시저를 사용하여 원격 프로시저를 마치 로컬 프로시저처럼 호출하는 방식의 미들웨어
  • MOM(Message Oriented Middleware): 메시지 기반의 비동기형 메시지를 전달하는 방식의 미들웨어
  • TP-Monitor(Transaction Processing Monitor): 항공기나 철도 예약 업무 등과 같은 온라인 트랜잭션 업무에서 트랜잭션을 처리 및 감시하는 미들웨어
  • ORB(Object Request Broker): 객체 지향 미들웨어로 코바 표준 스펙을 구현한 미들웨어
  • WAS(Web Application Server): 사용자의 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어


*가비지 컬렉션: 실제로 사용되고 있지 않지만 반환되지 않은 메모리 공간을 강제로 해제하여 사용할 수 있도록 하는 메모리 관리 기법

*오픈소스: 누구나 제한없이 사용할 수 있는 소스코드를 공개한 라이선스를 만족하는 소프트웨어

*tpmC: 1분당 최대 처리 건수, 하드웨어 성능 지표로 사용 *OLTP/배치/데이터베이스 서버 -> tpmC *WEB/WAS 서버 -> OPS(Operations per Second)


7) 요구사항

  • 소프트웨어가 문제를 해결하기 위해 제공되는 서비스 설명과 제약조건을 나타낸다.
  • 기능적 요구사항: 시스템이 제공하는 기능, 서비스 (기능성, 완전성, 일관성)
  • 비기능적 요구사항: 기능 외의 제약사항이나 보안적인 요소
  • 사용자 요구사항: 사용자 관점에서 시스템이 제공해야 할 기능 및 서비스
  • 시스템 요구사항: 개발자 관점


  • 요구사항 개발 프로세스
    • 도출: 요구사항 식별, 인터뷰, 브레인스토밍, 리서치, 워크숍
    • 분석: 요구사항 분류, 개념 모델링, 요구사항 협상, 요구사항 할당, 정형 분석
    • 명세: 문서화, 시스템 요구사항 명세서, 시스템 정의서
    • 확인: 요구사항 검토, 프로토타이핑, 모델 검증, 인수 테스트


*개념 모델링: 요구사항 분석의 핵심으로 요구사항을 단순화하여 개념적으로 표현한 것

*유스케이스 다이어그램: 액터와 시스템의 관계를 표현하고 기능적인 요구사항을 유스케이스라는 단위로 표현

*UML: 개발자들이 효율적으로 의사소통을 하기 위해 만들어진 표준 통합 모델링 언어

*요구사항 할당: 아키텍처 구성요소 식별

*정형 분석: 구문과 의미를 갖는 정형화된 언어를 수학적 기호로 표현하여 분석

*모델 검증: 정적 분석 수행

*인수테스트: 사용자의 입장에서 테스트하는 방법으로 알파 테스트와 베타 테스트가 존재

*프로토타이핑: 새로운 요구사항을 도축하기 위한 수단 또는 요구사항에 대해 소프트웨어 엔지니어가 해석한 것으로 확인하기 위한 수단


8) 비용 산정 모델

  • 하향적 선정 방법: 전문가 판단, 델파이 기법
  • 상향식 선정 방법: LOC, M/M(Man/Month), Putnam, COCOMO

*Putnam: 개발 주기의 단계별 요구, 인원 분포도 가정

*COCOMO: 보헴이 정의/프로그램 규모에 따라 비용 산정

*상호 운용성: 서로 다른 시스템 간의 데이터를 주고 받아 효율적으로 운용될 수 있는 특성


9) 분석 모델 검증

  • 유스케이스 모델 검증
  • 개념 수준의 분석 클래스 검증
  • 분석 클래스 검증


  • 경계: 외부 액터와 상호작용
  • 엔티티: 시스템이 유지해야 하는 정보를 관리
  • 제어: 시스템이 제공하는 기능의 로직, 제어 담당


*기술적 타당성 검토

  • 성능 및 용량 산정의 적정성
  • 시스템 간 상호 운용성
  • IT 시장 성숙도 및 트렌드 부합성
  • 기술적 위험 분석


10) UML

  • 개발자들이 원활한 의사소통을 하기 위해 고안된 표준화 통합 모델링 언어
  • 6개의 구조 다이어그램 + 7개의 행위 다이어그램
  • 구성요소: 사물, 관계, 다이어그램

  • 사물: 구조, 그룹, 행동, 주해


*관계

  • 연관관계: 2개 이상의 사물이 서로 연관
  • 집합관계: 하나의 사물이 다른 사물에 포함
  • 포함관계: 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계
  • 일반화: 상속 관계
  • 의존: 필요에 의해 짧은 기간 동안 관계 유지
  • 실체화: 서로를 그룹화할 수 있는 인터페이스


  • 구조 다이어그램: 클래스, 객체, 컴포넌트, 배치
  • 행위 다이어그램: 유스케이스, 시퀀스, 커뮤니케이션, 상태


*유스케이스 다이어그램 구성요소: 액터, 유스케이스, 시스템, 관계

*유스케이스: 액터에게 제공하는 서비스, 기능을 표현

This post is licensed under CC BY 4.0 by the author.