그냥 게임개발자
1. 요구사항 확인 본문
■ 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 |