정보처리기사 실기 수제비 1과목 요구사항 확인

현생 시스템 분석

현행 시스템 파악

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

현행 시스템 파악 절차

• 1단계 (구성/기능/인터페이스 파악)
  • 시스템 구성 현황 파악
  • 시스템 기능 파악
  • 시스템 인터페이스 현황 파악
• 2단계 (아키텍처 및 소프트웨어 구성 파악)
  • 아키텍처 파악
  • 소프트웨어 구성 파악
• 3단계 (하드웨어 및 소프트웨어 구성 파악)
  • 시스템 하드웨어 현황 파악)
  • 네트워크 구성 파악

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

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

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

• 4+1에서 1은 유스케이스 뷰 4는 논리 뷰, 구현 뷰, 프로세스 뷰, 배포 뷰
  • 유논프구배

개발 기술 환경 정의

운영체제 현행 시스템 분석

운영체제(Operationg System)의 개념

• 사용자가 컴퓨터를 좀 더 쉽게 사용하기 위해 지원하는 소프트웨어이다.

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

• 신뢰도
• 성능
• 기술 지원
• 주변 기기
• 구축 비용

OSI 참조 모델

OSI(Open System Interconnection) 참조 모델의 개요

• OSI 참조 모델은 다른 시스템 간의 원활한 통신을 위해 ISO(국제표준화 기구)에서 제안한 통신 규약(Protocol)이다.
  • OSI 7계층은 13계층을 하위 계층 , 47계층을 상위 계층이라고 한다
    • 하위계층
      • 물리 계층→ 데이터 링크 계층→ 네트워크 계층
    • 상위계층
      • 전송 계층 → 세션 계층 → 표현 계층 → 응용 계층

OSI 참조 모델에서의 데이터 단위

• 프로토콜 데이터 단위(PDU; Protocol Data Unit)
  • 응용 계층(데이터)
  • 표현 계층(데이터)
  • 세션 계층(데이터)
  • 전송 계층(세그먼트)
  • 네트워크 계층(패킷)
  • 데이터 링크 계층(프레임)
  • 물리 계층(비트) !기출

물리 계층 (Physical Layer)

• 물리 계층은 전송에 필요한 두 장치 간의 실제 접속과 절단 등 기계적, 전기적, 기능적, 절차적 특성에 대한 규칙을 정의한다
  • 물리적 전송 매체와 전송 신호 방식을 정의하며, RS-232C, X.21등의 표준이 있다
  • 관련 장비 : 리피터, 허브
  • 프로토콜 : RS-232C

데이터 링크 계층(Data Link Layer)

• 데이터 링크 계층은 두 개의 인접한 개방 시스템들 간에 신뢰성 있고 효율적인 정보 전송을 할 수 있도록한다
  • 송신 측과 수신측의 속도 차이를 해결하기 위한 흐름 제어 기능을 한다
  • 관련 장비 : 랜카드 , 브리지, 스위치
  • 프로토콜 : 이더넷

네트워크 계층(Network Layer, 망 계층)

• 네트워크 계층은 개방 시스템들 간의 네트워크 연결을 관리하는 기능과 데이터의 교환 및 중계 기능을 한다
  • 네트어크 연결을 설정, 유지, 해제하는 기능을 한다
  • X.25, IP 등의 표준이 있다.
  • 관련 장비 : 라우터
  • 프로토콜 : IP, ICMP

전송 계층(Transport Layer)

• 전송 계층은 논리적 안정과 균일한 데이터 전송 서비스를 제공함으로써 종단시스템(End-to-End) 간에 투명한 데이터 전송을 가능하게 한다.
  • OSI 7계층 중 하위 3계층과 상위 3계층의 인터페이스(Interface)를 담당한다.
  • 종단 시스템(End-to-End) 간의 전송 연결 설정, 데이터 전송, 연결 해제 기능을 한다.
  • 주소 설정, 다중화(분할 및 재조립), 오류 제어 , 흐름 제어를 수행한다
  • 프로토콜 : TCP, UDP 등의 표준이 있다.
  • 관련 장비 : 게이트웨이

세션 계층(Session Layer)

• 세션 계층은 송수신 측 간의 관련성을 유지하고 대화 제어를 담당한다
  • 대화(회화) 구성 및 동기 제어, 데이터 교환 관리 기능을 한다.
  • 송수신 측 간의 대화 동기를 위해 전송하는 정보의 일정한 부분에 체크점을 두어 정보의 수신 상태를 체크하며, 이때의 체크점을 동기점이라고 한다
  • 프로토콜 : SSH, TLS

표현 계층(Presesntation Layer)

• 표현 계층은 응용 계층으로부터 받은 데이터를 세션 계층에 보내기 전에 통신에 적당한 현태로 변환하고, 세션 계층에서 받은 데이터는 응용 계층에 맞게 변환하는 기능을 한다.
  • 서로 다른 데이터 표현 형태를 갖는 시스템 간의 상호 접속을 위해 필요한 계층이다.
  • 코드 변환, 데이터 암호화, 데이터 압축, 구문 검색, 정보 형식(포맷) 변환 , 문맥 관리 기능을 한다.
  • 프로토콜 : JPEG, MPEG

응용 계층(Application Layer)

• 응용 계층은 사용자(응용 프로그램)가 OSI 환경에 접근할 수 있도록 서비스를 제공한다
  • 응용 프로세스 간의 정보 교환, 전자 사서함, 파일전송, 가상 터미널 등의 서비스를 제공한다.
  • 프로토콜 : HTTP, FTP

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

기능

• 중복 제어
• 접근 통제
• 인터페이스 제공
• 관계 표현

현행 시스템 분석데이터베이스의 가용성, 성능, 기술 지원, 호환성, 구축 비용을 분석

미들웨어는 분산 컴퓨팅 환경에서 응용 프로그램과 프로그램이 운영되는 환경 간에 원만한 통신이 이루어질 수 있도록 제어해주는 소프트웨어. 운영체제와 소프트웨어 애플리케이션 사이에 위치. 대표적으로 WAS를 예로 들 수 있음.

현행 시스템 분석미들웨어의 가용성, 성능, 기술 지원, 구축 비용을 분석

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

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

온라인 트랜잭션 처리(OLTP) 시스템네트워크 상의 여러 이용자가 실시간으로 데이터베이스의 데이터를 갱신하거나 조회하는 등의 단위작업을 처리하는 방식

2. 요구사항 확인

요구사항

요구사항 개념

• 문제의 해결 또는 목적 달성을 위하여 고객에 의해 요구되거나, 표준이나 명세 등을 만족하기 위하여 시스템이 가져야하는 서비스 또는 제약사항이다.

요구사항의 분류

• 요구사항 파악의 기본은 시스템의 요구사항에 대한 파악이다

• 요구사항의 기능적 요구사항과 비기능적 요구사항으로 분류된다

• 요구사항의 분류

요구사항 개발 프로세스

• 도출 → 분석 → 명세 → 확인

요구사항 개발 프로세스 주요기법

 

도출

• 인터뷰
• 설문 조사
• 브레인 스토밍(아이디어 수용 회의)
• 워크숍

분석

• 자료 흐름 지향 분석 : DFD;Data Flow Diagram으로부터 소프트웨어 구조를 유도
• 객체지향 분석

 

확인 및 검증

• 동료 검토(Peer Review), 워크 스루(Walk Through), 인스펙션(Inspetion)은 확인 기법이자 검증 기법

• 동워인

  • 동쪽에서 워(war) 일으킨 사람(인) 확인,검증

요구사항의 분석

요구사항 분석 기법

• 요구사항 분류 : 기능인지 비기능인지
• 개념 모델링: 엔티티들과 개별 관계 및 종속성 반영, 유스케이스 다이어그램, UML 사용
• 요구사항 할당 : 요구사항을 만족시키기 위한 아키텍처 구성요소를 식별, 추가 요구사항의 발견
• 요구사항 협상 : 적절한 지점 합의
• 정형 분석 : 형식적으로 정의된 의미를 지닌 언어로 요구사항을 표현

UML(Unified Modeling Language)객체지향 소프트웨어 개발과정에서 산출물을 명세화, 시각화, 문서화할 시 사용되는 모델링 기술과 방법론을 통합해 만든 표준화된 범용 모델링 언어

요구사항의 확인

• 요구사항 검토
  • 여러 검토자들이 에러, 잘못된 가정, 불명확성, 표준과의 차이 검토
  • 고객 중심 프로젝트에서는 검토자 그룹에 고객 대표자 1명 이상 포함 필요
• 프로토타이핑
  • 새로운 요구사항을 도출하기 위한 수단 및 소프트웨어 요구사항에 대해 소프트웨어 엔지니어가 해석한 것을 확인하기 위한 수단으로 사용
  • 요구사항이 잘못된 경우 유용한 피드백 제공, 사용자 인터페이스의 동적인 행위가 문서나 그래픽 모델보다 이해 용이
• 인수 테스트
  • 요구사항의 중요한 속성은 최종 제품을 기준으로 요구사항을 만족시키는지 확인이 가능해야함
  • 각각의 요구사항을 어떻게 확인할 것인지에 대한 계획 수립 후 요구사항을 확인하는 테스트

요구사항의 확인 프로세스

• 요구사항 목록 확인
• 요구사항 정의서 작성 여부 확인
• 비기능적 요구사항의 확인
• 타 시스템 연계 및 인터페이스 요구사항 확인

비용산정 모델

비용 산정 모델 개념

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

비용 산정 모델 분류

• 하향식 산정방법
  • 경험이 많은 전문가에게 비용산정을 의뢰하거나 여러 전문가와 조정자를 통해 산정하는 방식
    • 전문가 판단, 델파이 기법
• 하향식 비용산정 모델
  • 전문가 판단
    • 조직 내에 있는 경험이 많은 두 명이상의 전문가 에게 비용산정을 의뢰하는 기법
  • 델파이 기법
    • 전문가의 경험적 지식을 통한 문제해결 및 미래 예측을 위한 기법
    • 전문가들의 편견이나 분위기에 지배되지 않도록 한 명의 조정자와 여러 전문가로 구성
• 상향식 산정방법
  • 세부적인 요구사항과 기능에 따라 필요한 비용을 계산하는 방식
    • 코드라인 수(LoC; Line of Code)
    • Man Month
    • COCOMO모형
    • Putnam 모형
    • FP(Function Point) 모형
• 상향식 비용산정 모델
  • LoC(Lines of Code)
    • 소프트웨어 각 기능의 원시 코드 라인 수의 비관치, 낙관치, 기대치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정
    • 측정이 쉽고 이해하기 쉬워 많이 사용
    • 예측치를 이용하여 생산성 노력, 개발 기간의 비용을 산정
      • ex)LoC가 5000000라인이고 한 프로그래머가 한 달에 25000라인을 개발할 수 있다면 Man Month는 얼마인가?
      • Lines of Code(LoC) / 프로그래머의 월간 생산성 = 500000/ 25000 = 20개월
  • Man Month
    • 한 사람이 1개월 동안 할 수 있는 일의 양을 기준으로 프로젝트 비용을 산정하는 기법
    • Man Month = LoC / 프로그래머의 월간 생산성
    • 프로젝트 기간 = Man Month / 프로젝트 인력
      • ex) Man Month가 50개월일 때 10명이 프로젝트를 수행한다면 프로젝트 총 기간은 얼마인가?
      • 프로젝트 기간 = Man Month / 프로젝트 인력 = 50 / 10 = 5개월
  • COCOMO
    • 보헴(Bohem)이 제안한 모형
    • 단순형(Organic Mode)
      • 기관 내부에서 개발된 중소규모의 소프트웨어로 일괄 자료 처리나 과학기술 계산용, 비즈니스 자료 처리 개발에 적용 5만(50KDSI) 라인 이하의 소프트웨어를 개발하는 유형
    • 중간형(Semi-Detached Mode)
      • 단순형과 임베디드형의 중간형
      • 트랜잭션 처리 시스템이나 운영체제, 데이터베이스 관리 시스템 개발에 적용
      • 30만(300KDSI) 라인 이하의 소프트웨어를 개발하는 유형
    • 임베디드형(Embedded Mode)
      • 초대형 규모의 트랜잭션 처리 시스템이나 운영체제 개발에 적용
      • 30만(300KDSI)라인 이상의 소프트웨어를 개발하는 유형

분석 모델 확인하기

분석 모델검증 ★★★

분석 모델 검증 방법

• 유스케이스 모델 검증
  • 시스템 기능에 대한 유스케이스 모형 상세화 수준 및 적정성 검증을 위해서 액터, 유스케이스, 유스케이스 명세서 점검
• 개념 수준의 분석 클래스 검증
• 분석 클래스 검증

분석 클래스의 스테레오 타입

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

분석 모델 검증방법

• 유개분
  • 유스케이스 모델 검증/ 개념 수준의 분석 클래스 검증/ 분석 클래스 검증
    • 유순한 개가 분노함

분석 모델 검증 프로세스

검토의견 컬럼 추가 → 검토의견 작성 → 검토의견 정제

분석 모델의 시스템화 타당성 분석 ★★

분석 모델이 개발할 응용 소프트웨어에 미칠 영향을 검토하여 기술적인 타당성을 조사

분석 모델의 기술적 타당성 검토

• 성능 및 용량 산정의 적정성
• 시스템 간 상호 운영성

• IT 시장 성숙도 및 트렌드 부합성

  • 분석 자동화 도구 활용 방안 고려
• 기술적 위험 분석
• 성상아기
• 성모마리아 상이 아기를 안고 있다.

분석 모델의 시스템화 타당성 분석 프로세스

• 타당성 검토의견 컬럼 추가
• 타당성 검토의견 작성
• 타당성 분석 결과 검증
• 타당성 분석 결과 확인 및 배포 / 공유

컬작검확

• 컬러로 작성된 문서는 검토 확인이 편리하다