[정보처리기사] 필기 노트 - 요구사항 확인

• 현행 시스템 파악
  • 현행 시스템 파악의 개요
    • 요구사항을 확인하기 위한 준비 단계
    • 현재 운영되는 시스템의 주요 현황을 파악
    • 현행 시스템 파악 절차 : 현행 시스템의 구성, 기능, 인터페이스 현황을 파악 -> 현행 시스템의 아키텍처 및 소프트웨어 구성 현황을 파악 -> 현행 시스템의 하드웨어 및 네트워크 구성 현황을 파악
• 현행 시스템의 구성, 기능, 인터페이스 현황
  • 현행 시스템 구성 현황
    • 조직의 주요 업무를 처리하는 기간 업무와 지원 업무로 구분하여 파악
  • 기능 현황
    • 단위 업무 시스템이 현재 제공하고 있는 기능을 파악
  • 인터페이스 현황
    • 단위 업무 시스템이 다른 단위 업무 시스템과 주고받는 데이터의 종류, 데이터 형식, 프로토콜, 연계유형, 주기 등을 파악

• 현행 시스템의 아키텍처 및 소프트웨어 구성 현황
  • 현행 시스템 아키텍처 구성도
    • 기간 업무를 수행하기 위하여 계층별로 어떠한 기술 요소를 사용하고 있는지 최상위 수준에서 그림으로 표현
  • 소프트웨어 구성도
    • 업무 처리를 위해 설치된 소프트웨어들의 제품명, 용도, 라이선스 적용 방식, 라이선스 수를 명시
• 현행 시스템의 하드웨어 및 네트워크 구성 현황
  • 하드웨어 구성도
    • 서버의 주요 사양(CPU 처리속도, 메모리 크기, 하드디스크의 용량 등)과 수량, 이중화가 적용되어 있는지 여부를 명시
  • 네트워크 구성도
    • 업무 처리 시스템들이 어떠한 네트워크 구성을 가지고 있는지 그림으로 표현한 것
• 현행 시스템 분석
  • 운영 체제
    • 하드웨어와 소프트웨어 자원을 효율적으로 관리하고, 사용자가 컴퓨터를 편리하게 사용할 수 있는 환경을 제공하는 소프트웨어를 의미
    • 종류: Windows, Linux, UNIX, iOS, Android
  • DBMS
    • 사용자, 다른 애플리케이션, 데이터 베이스와 상호 작용하여 데이터를 저장하고 분석하기 위한 컴퓨터 소프트웨어 애플리케이션
    • 종류: Oracle, IBM DB2, Microsoft SQL Server, MySQL, SQLite, MongoDB, Redis 등
  • 미들웨어 (Middelware)
    • 운영체제와 해당 운영체제에서 실행되는 응용 소프트웨어 사이에 존재하는 소프트웨어
  • 웹 애플리케이션 서버
    • 동적인 웹 사이트, 웹 애플리케이션, 웹 서비스의 개발을 지원하기 위하여 설계된 미들웨어
    • 종류: GlassFish, JBoss, Jetty, JEUS, Resin, WebLogic, WebSphere 등
  • 오픈 소스
    • 소스 코드를 인터넷을 통해 무료로 공개하여 누구나 특별한 제한 없이 그 코드를 보고 사용할 수 있는 오픈 소스 라이선스를 만족하는 소프트웨어
• 요구사향 기법
  • 요구사항 개발 프로세스
    • 요구사항 도출
      • 요구사항이 어디에 있고, 어떻게 수집할 것인가와 관련됨
    • 요구사항 분석
      • 요구사항들 간 상충되는 것을 해결하고, 소프트웨어의 범위를 파악하며, 소프트웨어가 환경과 어떻게 상호 작용하는지 이해
    • 요구사항 명세
      • 체계적으로 검토, 평가, 승인이 될 수 있는 문서를 작성하는 것
    • 요구사항 확인
      • 분석가가 요구사항을 이해했는지 확인(Validation)하고, 요구사항 문서가 회사의 표준에 적합하고 이해 가능하며, 일관성이 있고, 완전한지 검증(Verification)
  • 요구 분석 기법
    • 요구사항 분류
      • 요구사항을 같은 유형으로 분류하는 과정
    • 개념 모델링
      • 요구사항을 쉽게 이해할 수 있도록 하는 과정
    • 요구사항 할당
      • 요구사항을 만족시키기 위한 아키텍처 구성 요소를 식별하는 과정
    • 요구사항 협상
      • 요구사항 간의 상충되는 부분을 합의하는 과정
    • 정형 분석
      • 정확하고 명확하게 요구사항을 정의하는 과정
  • UML (Unified Modeling Language)
    • ULM이란?
      • 요구 분석, 시스템 서례, 시스템 구현 등의 시스템 개발 과정에서, 개발자간의 의사소통을 원활하게 이루어지게 하기 위하여 표준화한 모델링 언어
    • 다이어그램(Diagram)
      • 사용자 관점의 요구나 서비스 또는 기능을 보여주는 그림
      • 다이어그램의 구성 요소
        • 액터(Actor): 시스템 외부에서 시스템과 상호 작용을 하는 사람이나 다른 시스템 (예: 학생, 교수)
        • 시스템(System): 개발하고자 하는 어플리케이션 (예: 게시판)
        • 유스케이스(Usecase): 시스템이 액터에게 제공해야 하는 기능 (예: 글을 등록한다)
        • 관계(Relationship): 액터와 유스케이스들 사이의 의미있는 관계
      • 다이어그램의 종류
        • 구조 다이어그램(Structure Diagram)
          • 시스템의 정적 구조(Static Structure)와 다양한 추상화 및 구현 수준에서 시스템의 구성 요소, 구성 요소들 간의 관계를 보여줌
          • 클래스 다이어그램, 객체 다이어그램, 복합체 구조 다이어그램, 배치 다이어그램, 컴포넌트 다이어그램, 패키지 다이어그램 등
        • 행위 다이어그램(Behavior Diagram)
          • 시스템 내의 객체들의 동적인 행위(Dynamic Behavior)를 보여주며, 시간의 변화에 따른 시스템의 연속된 변경을 설명
          • 활동 다이어그램, 상태 머신 다이어그램, 유스케이스 다이어그램, 상화작용 다이어그램 등
    • 애자일 모형
      • 애자일이란?
        • 애자일(Agile)이란 단어는 '날렵한', '민첩한'이란 뜻을 가진 형용사
        • 정해진 계획만 따르기보다, 개발 주기 혹은 소프트웨어 개발 환경에 따라 유연하게 대처하는 방식
      • 폭포수 모델과 애자일 모델의 비교
        • 폭포수 모델
          • 계획, 프로세스에 중점
          • 프로젝트 관리에 중점
          • 문서(산출물)에 중점
        • 애자일 모델
          • 고객과의 협업 강조
          • 빠른 시간 안에 작동하는 소프트웨어 강조
          • 환경/고객 변화에 능동적 대처를 강조
      • 애자일 개발 방법론
        • Scrum, XP(eXtreme Programming), 적응형 소프트웨어 개발 방법론(Adaptive software development)
        • 린 소프트웨어 개발 방법론, Crystal family, 기능 주도 개발 방법론(FDD; Feature Driven Development), 동적 시스템 개발 방법론(DSDM; Dynamic Systems Development Method), 애자일 UP(AUP; Agile Unified Process) 등
    • 모델링 기법
      • 분석 모델 검증
        • 분석 모델 검증 절차: 유스케이스 모델 검증 -> 개녀 수준 분석 클래스 검증 -> 분석 클래스 검증
        • 유스 케이스 모델 검증
          • 액터, 유스케이스, 유스케이스 명세서에 대해 검증
        • 개념 수준 분석 클래스 검증
          • 시스템의 주요 도메인 개념을 분석 클래스로 도출하여 유스케이스 분석에 활용
        • 분석 클래스 검증
          • 분석 클래스가 적절히 도출되었고, 제어 클래스의 도출 등이 충분하고 상세하게 도출되어 클래스의 역할, 클래스 간의 관계, 메시지 흐름 등을 확인할 수 있는지 검토
      • CASE 도구
        • CASE(Computer Aided Software Engineering)란?
          • 요구분석, 설계, 구현, 검사 및 디버깅 과정 전체 또는 일부를 컴퓨터와 전용 소프트웨어 도구를 사용하여 자동화하는 것
        • CASE 의 분류
          • 상위 CASE (Upper CASE)
            • 소프트웨어 생명 주기 전반부에서 사용, 문제를 기술하고 계획하며 요구분석과 설계 단계를 지원
          • 하위 CASE (Lower CASE)
            • 소프트웨어 생명 주기 하반부에서 사용, 코드의 작성과 테스트, 문서화하는 과정을 지원
          • 통한 CASE (Integrate CASE)
            • 소프트웨어 생명 주기가 포함되는 전체 과정을 지원, 공통의 정보 저장 장소와 통일된 사용자 인터페이스를 사용하여 도구를 통합