그냥 게임개발자

1. 요구사항 확인 본문

나만의 정처기 공부

1. 요구사항 확인

sudoju 2022. 3. 7. 01:13

■ SDLC : 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차

종류

- 폭포수 모델 : 가장 오래된 모델, 각 단계를 확실히 마무리 지은 후 다음 단계로 넘어감

- 프로토타이핑 모델 : 주요기능을 프로토타입으로 구현, 고객의 피드백을 반영하여 S/W 만듬

- 나선형 모델 : 위험을 최소화하기 위해 점진적으로 시스템 개발

- 반복적 모델 : 구축대상을 나누어 병렬적으로 개발 후 통합하거나, 반복적으로 개발

 

■ 소프트웨어 개발 방법론

- 소프트웨어 개발의 시작부터 시스템을 사용하지 않는 과정까지의 전 과정을 형상화한 방법론

종류

1. 구조적 방법론

- 전체 시스템을 기능에 따라 나누어 개발, 이를 통합한 방법론

  *나씨 슈나이더만 차트 : 논리의 기술에 정점을 둔 도형식 표현방법

2. 정보공학 방법론

- 정보시스템 개발에 필요한 관리 절차와 작업 기반을 체계화한 방법론

3. 객체 지향 방법론

- '객체'라는 기본 단위로 시스템을 분석 및 설계하는 방법론

4. 컴포넌트 기반 방법론

- 컴포넌트를 조립해서 하나의 새로운 응용프로그램을 작성하는 방법론

5. 애자일 방법론

- 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적인 시스템을 개발할 수 있는 신속 적응적 개량 개발 방법론

6. 제품 계열 방법론 : 특정 제품에 적용하고 싶은 공통된 기능을 정의해 개발하는 방법론, 임베디드 s/w에 유용

 

■ 애자일 방법론 유형

1. XP(eXtreamProgramming)

- 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론

         용단의 피죤

              용기, 단순성, 의사소통, 피드백, 존중

2. 스크럼

- 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론

3. 린

- 도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해서 낭비 요소를 제거하여 품질을 향상시킨 방법론

      7가지 가치 : 낭비제거, 품질 내재화, 지식 창출, 늦은 확정, 빠른 인도, 사람 존중, 전체 최적화

 

■ 객체 지향 분석(OOA)

- 사용자의 요구사항을 분석하여 요구된 문제와 관련된 모든 클래스(객체), 속성과 연산, 관계를 정의

 

종류

OOSE(Object Oriented Software Engineering)

- 유스케이스를 모든 모델의 근간으로 활용되는 방법론

OMT(Object Modeling Technology)

- 그래픽 표기법을 이용하여 소프트웨어 구성요소를 모델링

       분석 절차 : 객체 모델링 -> 동적 모델링 -> 기능 모델링(객동기)

       객체 모델링 : 객체들 간의 관계를 정의하여 ER 다이어그램을 만드는 과정까지의 모델링, 객체 다이어그램 활용

       동적 모델링 : 시간의 흐름에 따라 객체들의 동적인 행위를 표현하는 모델링, 상태 다이어그램 활용

       기능 모델링 : 프로세스들의 자료 흐름을 중심으로 처리 과정 표현하는 모델링, 자료흐름도(DFD)활용

 

■ 비용산정 모형 분류

- 하향식 산정 방법 : 경험이 많은 전문가에게 비용산정 의뢰 또는 전문가와 조정자를 통해 비용산정

          전문가 판단

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

- 상향식 산정 방법 : 세부적인 요구사항과 기능에 따라 필요한 비용 산정

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

         Man Month : 한 사람이 1개월 동안 할 수 있는 일의 양을 기준으로 비용산정

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

            - 조직형 : 5만라인 이하

            - 반 분리형 : 30만 라인 이하

            - 임베디드형 : 30만 라인 이상

        푸트남 모형 : 개발주기의 단계별로 요구할 인력의 분포를 가정하는 방식

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

 

■ 비용 산정 자동화 추정 도구

SLIM : Rayleigh-Norden 곡선과 Putnam예측 모델을 기초로 하여 개발된 자동화 추정 도구

ESTIMACS : 다양한 프로젝트와 개인별 요소를 수용하도록 FP모형을 기초로 하여 개발된 자동화 추정 도구

 

■ 일정 관리 모델 : 프로젝트가 일정 기한 내에 완료될 수 있도록 관리하는 모델

  주 공정법(CPM) : 여러 작업의 수행 순서가 얽혀 있는 프로젝트의 일정을 계산하는 기법

     주 공정(Critical Path : 임계 경로) : 프로젝트의 시작에서 종료까지 가장 긴 시간이 걸리는 경로

  PERT : 일의 순서를 계획적으로 정리하기 위한 수렴기법, 비관치, 중간치, 낙관치 이용

  중요 연쇄 프로젝트 관리(CCPM) : 주 공정 연쇄법으로 자원제약사항을 고려하여 일정을 작성하는 기법

 

 

 

챕터2 현행 시스템 분석

 

■ 현행 시스템 파악 : 현행 시스템의 어떤 기술 요소 사용을 하는지 파악하는 활동

■ 현행 시스템 파악 절차

 - 구성/기능/인터페이스 파악 -> 아키텍처 및 소프트웨어 구성 파악 -> 하드웨어 및 네트워크 구성 파악

 

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

 

■ 소프트웨어 아키텍처4+1뷰(유논프구배)

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

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

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

  - 프로세스 뷰 : 시스템의 비기능적인 속성으로 자원의 효율적인 사용, 병행 실행, 비동기, 이벤트 처리 등을 표현한 뷰

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

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

 

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

 - 계층화 패턴(Layerd Pattern) : 시스템을 계층으로 구분하여 구성하는 패턴

 - 클라이언트 - 서버 패턴(Client-Server Pattern) : 하나의 서버와 다수의 클라이언트로 구성된 패턴

 - 파이프 - 필터 패턴(Pipe - Filter Pattern) : 데이터 스트림을 생성하고 처리하는 시스템에서 사용 가능한 패턴, 재사용이 좋고 추가가 쉬워 확장에 용이

 - 브로커 패턴(Broker Pattern) : 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용, 각 컴포넌들 원격 서비스 실행을 통해 상호작용이 가능

- 모델-뷰-컨트롤러 패턴(MVC) : 대형 애플리케이션을 3개의 서브 시스템으로 구조화한 패턴, 컴포넌트로 분리되어 있어 서로 영향을 받지 않고 개발 작업 수행 가능

       모델 : 핵심 기능과 데이터 보관

       뷰 : 사용자에게 정보 표시

       컨트롤러 : 사용자로부터 요청을 입력받아 처리

 

■ 소프트웨어 아키텍처 비용 평가 모델 종류(SACAA)

 - SAAM : 변경 용이성과 기능성에 집중, 경험이 없는 조직에서도 활용 가능 비용평가 모델

 - ATAM : 아키텍처 품질 속성을 만족시키는지 판단 및 품질 속성들의 이해 상층관계까지 평가하는 모델

 - CBAM : ATAM 바탕의 시스템으로 경제적 의사결정에 대한 요구를 충족하여 평가 모델

 - ADR : 소프트웨어 아키텍처 구성요소 간 응집도 평가 모델

 - ARID : 전체 아키텍처가 아닌 특정 부분에 대한 품질요소에 집중하여 비용 평가 모델

 

 

■ 디자인 패턴 : 소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴

■ 디자인 패턴 유형

        - 목적

               - 생성 : 객체 인스턴스 생성에 관여, 클래스 정의와 객체 생성방식을 구조화, 캡슐화를 수행하는 패턴

               - 구조 : 클래스나 객체의 조합을 다루는 패턴

               - 행위 : 클래스나 객체들이 상호 작용하는 방법과 역할 분담을 다루는 패턴

       - 범위

               - 클래스 : 상속 관계를 다루는 패턴, 컴파일 타임에 정적으로 결정

               - 객체 : 객체 간 관련성을 다루는 패턴, 런타임에 동적으로 결정

 

■ 디자인 패턴 종류

     - 생성패턴 : Builder, Prototype, Factory Method, Abstract Factory, Singleton

     - 구조 패턴 : Bridge, Decorator, Facade, Flyweight, Proxy, Composite, Adapter

     - 행위 패턴 : Mediator, Interpreter, Iterator, Teplate Method, Observer, State, Visitor, Command, Strategy, Memento, Chain of Responsibilty

 

 

■ 운영 체제 (Operating System) : 컴퓨터 사용자와 컴퓨터 하드웨어 간의 인터페이스를 담당하는 프로그램

         운영체제 종류

              PC : 윈도우, 유닉스, 리눅스

              모바일 : 안드로이드, IOS

 

 

■ OSI 계층 : 네트워크 통신에서 충돌 문제를 완화하기 위해 국제 표준화 기구(ISO)에서 제시한 모델

   - 응용 계층(Application Layer) : 사용자와 네트워크 간 응용서비스 연결, 데이터 생성

   - 표현 계층(Presentation Layer) : 데이터 형식 설정과 부호교환, 암/복호화

   - 세션 계층(Session Layer) : 연결 접속 및 동기제어

   - 전송 계층(Transport Layer) : 신뢰성 있는 통신 보장. 데이터 분할과 재조립, 흐름 제어, 혼잡제어 등 담당,

   - 네트워크 계층(Network Layer) : 단말 간 데이터 전송을 위한 최적화된 경로 제공

   - 데이터 링크 계층(Data Link Layer) : 인접 시스템 간 데이터 전송, 전송오류 제어

   - 물리 계층(Physical Layer) : 0과 1의 비트 정보를 회선에 보내기 위한 전기적 신호 변환

 

 

DBMS : 데이터의 집합을 만들고, 저장 및 관리할 수 있는 기능들을 제공하는 응용 프로그램

 

미들 웨어 : 분산 컴퓨팅 환경에서 응용프로그램과 프로그램이 운영되는 환경 간에 원만한 통신이 이루어질 수 있도록 제어해주는 소프트웨어.

대표적인 미들웨어 : WAS

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

 

 

 

챕터 3 요구사항 확인

 

■ 요구공학 : 사용자의 요구가 반영된 시스템을 개발하기 위해 사용자의 요구사항에 대한 도출 분석 명세 확인 및 검증하는 구조화된 활동

 

■ 요구사항의 분류 

        - 기능적 요구사항 : 시스템이 제공하는 기능, 서비스에 대한 요구사항

             특정 입력/상황에 대해 시스템이 어떻게 반응/동작 해야하는지에 대한 기술

             특성 : 기능성, 완전성, 일관성

        - 비기능적 요구사항 : 시스템 구축에 대한 제약사항에 관한 요구사항

             품질 속성에 관련하여 시스템이 갖춰야할 사항에 관한 기술, 시스템이 준수해야 할 제한 조건에 관한 기술

             특성 : 신뢰성, 사용성, 효율성, 유지보수성, 이식성, 보안성 및 품질관련 요구사항, 제약사항

 

 

■ 요구공학 프로세스 : 도출 -> 분석 -> 명세 -> 확인 및 검증

 

■ 도출 단계 주요기법

 - 인터뷰, 브레인스토밍, 델파이기법, 롤플레잉, 워크숍, 설문조사

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

 

■ 확인 및 검증 단계 주요 기법

- 요구사항 검토 : 여러 검토자들이 에러, 잘못된 가정, 불명확성, 표준과의 차이 검토

 - 정형 기술 검토 활용

        - 동료 검토 : 2~3명이 리뷰진행, 요구사항 명세서를 설명하고 이해관계자들이 들으면서 결함을 발견하는 형태로 진행

        - 워크 스루 : 검토 자료를 회의전에 배포하여 짧은 시간동안 회의를 진행하는 형태

        - 인스펙션 : 소프트웨어 요구, 설계 원시 코드 등의 저작자 외의 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 공식적 검토 방법

 

- 프로토타이핑 활용 : 프로토타입을 통해 효과적으로 요구분석을 수행하면서 명세서를 산출하는 작업

- 모델 검증 : 분석단계에서 개발된 모델의 품질 검증 필요

- 테스트 케이스 및 테스틀 통한 확인 : 각각의 요구사항을 어떻게 확인할 것인지에 대한 계획을 수립하고 테스트케이스 작성

- CASE 도구 활용 검증 : 자동화된 일관성 분석을 제공하는 CASE 도구 활용

- 베이스라인을 통한 검증 : 요구사항 변경을 체계적으로 추적하고 통제하는 시점인 베이스라인을 통한 요구사항에 대한 지속적 검증 수행

- 요구사항 추적표(RTM)를 통한 검증 : 요구사항 정의서를 기준으로 개발 단계별 최종 산출물이 어떻게 반영되고, 변경되었는지 확인이 가능한 문서

 

 

챕터4 분석 모델 확인하기

■ 분석 모델 검증 방법 : 유스케이스 모델 검증, 개념 수준의 분석 클래스 검증, 분석 클래스 검증

'나만의 정처기 공부' 카테고리의 다른 글

2. 화면설계(2)  (0) 2022.03.11
2. 화면설계  (0) 2022.03.08
02. 현행 시스템 분석  (0) 2022.02.08
정처기 예상문제01 푼 거  (0) 2022.02.08
01. 소프트웨어 개발 방법론-02  (0) 2022.02.07