정처기 실기 파트1

１  요구사항확인

I.    소프트웨어 개발방법론

1.   소프트웨어 개발방법론

(1)  소프트웨어 생명주기 모델

-     소프트웨어 생명주기(SDLC) : 시스템의 요구분석부터 유지보수까지 전 공정을 체계화 한 절차

-     스프트웨어 생명주기 모델 프로세스 : 유설구테유 (요구사항 분석, 설계, 구현, 테스트, 유지보수)

-     소프트웨서 생명주기 모델 종류 : 폭프나반 (폭포수모델, 프로토타이핑모델, 나선형모델, 반복적모델)

(2)  소프트웨어 개발방법론

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

-     소프트웨어 개발방법론 종류

①  구조적 방법론 : 나씨-슈나이더만 차트

②  정보겅학 방법론

③  객체지향 방법론 : 객체, 클래스, 메시지

④  컴포넌트 기반 방법론 : 컴포넌트 조립

⑤  애자일 방법론 : 절차보다 사람 중심

⑥  제품계열 방법론 : 임베디드

-     애자일

①  개념 : 절차보다 사람 중심이 되는 신속 적응적 경량 개발방법론

②  애자일 방법론 유형 : XP , 린(Lean) , 스크럼(SCRUM)

③  XP

- 5가치 : 용단의피존 (용기, 단순성, 의사소통, 피드백, 존중)
- 12가지 기본 원리 : 짝 프로그래밍, 공동 코드 소유, 지속적인 통합, 계획 세우기, 작은 릴리즈, 메타포어, 간단한 디자인, 테스트 기반 개발, 리팩토링, 40시간 작업, 고객 상주, 코드 표준

④  스크럼 : 백로그, 스프린트. 스크럼 미팅, 스크럼 마스터, 스프린트 회고, 번다운 차트

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

2.   비용 산정, 일정관리 모형

(1)  비용산정 모형

-     분류

①  하향식 산정방법 : 전문가 판단 , 델파이 기법

②  상향식 산정방법 : 코드 라인 수(LoC) , Man Month, COCOMO모형, 푸트남모형, 기능점수(FP) 모형

-     비용산정 모형 종류

①  LoC모형 : 예측치 = (낙관치 + 4 * 중간치 + 비관치) / 6

②  Man Month 모형 : Man Month = LoC / 프로그래머의 월간 생산성
                  프로젝트 기간 = Man Month / 프로젝트 인력

③  COCOMO모형 : 보헴이 제안

조직형(Organic Model)	5만(50KDSI)라인 이하
반 분리형(Semi-Detached Model)	30만(300KDSI)라인 이하
임베디드형(Embedded Model)	30만(300KDSI)라인 이상

 

④  푸트남(Putnam) 모형 : Rayleigh-Norden 곡선

⑤  기능점수(FP;Function Point) 모형 : 기능점수(FP) = 총 기능점수 * [ 0.65 + (0.1 * 총 영향도)]

-     일정관리 모델

①  종류

주 공정법 (CPM;Critical Path Method)	노드간 연결을 통한 액티비티 표기법
PERT	비관치, 중간치, 낙관치의 3점 추정방식
중요 연쇄 프로젝트 관리(CCPM;Chain-CPM)	주 공정 연쇄법 + 자원제약사항 고려

(* 임계경로 (Critical Path) : 최장 경로)

II.   현행 시스템 분석

1.   현행 시스템 파악

(1)  현행 시스템 파악 절차 : 구기인아소하네(구성, 기능, 인터페이스, 아키텍처, 소프트웨어, 하드웨어, 네트워크 파악)

(2)  소프트웨어 아키텍처

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

①  구성요소 : 아키텍처 명세서, 이해관계자, 관심사, 관점, 뷰, 근거, 목표, 환경, 시스템

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

-     고객의 요구사항에 맞는 시나리오(유스케이스)를 4개의 관점에서 보는 것

-     구성요소

①  유논구프배 : 유스케이스 뷰(Usecase View) , 논리 뷰(Logical View), 프로세스 뷰(Process View), 구현 뷰(Implementation View), 배포 뷰(Deployment View)

-     소프트웨어 아키텍처 패턴

①   유형

계층화 패턴(Layered Pattern)	시스템을 계층으로 구분하여 구성하는 패턴
클라이언트-서버 패턴(Client-Server Pattern)	하나의 서버와 다수의 클라이언트로 구성된 패턴
파이프-필터 패턴(Pipe-Filter Pattern)	서브 시스템이 입력 데이터를 받아 처리하고 결과를 다음 서브 시스템으로 넘기는 패턴
브로커 패턴(Broker Pattern)	서버가 자신의 기능(서비스 및 특성)을 브로커에 넘겨주면(Publish), 브로커는 클라이언트를 자신의 레지스트리에 있는 적합한 서비스로 Redirection 하는 패턴
MVC 패턴(Model-View-Controller Pattern)	대화형 어플리케이션을 모델, 뷰, 컨트롤러 3개의 서브 시스템으로 구조화 하는 패턴 모델 : 핵심 기능과 데이터 보관 뷰 : 사용자에게 정보 표시(하나 이상의 뷰 정의 가능) 컨트롤러 : 사용자로부터 요청을 입력받아 처리

 

-     소프트웨어 아키텍처 비용 평가 모델

①  종류 : SACAA

SAAM	변경 용이성 및 기능성에 집중 평가
ATAM	SAAM + 아키텍처 품질 속성 평가
CBAM	ATAM에서 부족한 경제성 평가 보강
ADR	소프트웨어 아키텍처 구성요소 간 응집도를 평가
ARID	ATAM + ADR/전체가 아닌 특정 부분에 대한 품질요소 집중 비용 평가

 

(4)  디자인 패턴

-     디자인 패턴 유형 : 목적(생구행/생성, 구조, 행위) , 범위(클객/클래스, 객체)

-     디자인 패턴 종류

①  생성패턴(생빌프로패앱싱)

Builder : 복잡한 인스턴스를 조립하여 만드는 구조

Prototype : 일반적인 원형 만들고 복사 후 필요한 부분만 수정하여 사용

Factory Method : 상위 클래스에서 객체 생성 인터페이스 정의만, 하위클래스에서 실 생성

Abstract Factory : 구체적인 클래스에 의존하지 않고 연관되거나 의전적인 객체들의 집합을 만드는 인터페이스 제공

Singleton : 한 클래스에 한 객체만 존재하도록 제한

②  구조패턴(구브데퍼플프록컴어)

Bridge : 기능 클래스 계층과 구현 클래스 계층 연결

Decorator : 구현되어 있는 클래스에 필요 기능 추가

Facade : 복잡한 시스템에 대해 단순한 인터페이스 제공

Flyweight : 메모리 절약 및 클래스 경량화를 목적

Proxy : 실체 객체에 대한 대리객체, 미리 할당하지 않아 메모리 절감 및 정보은닉 효과

Composite : 트리구조로 구성, 복합 객체와 단일 객체를 동일하게 취급

Adapter : 기존 생성된 클래스를 재사용 가능하게 중간에 맞춰주는 역할을 하는 인터페이스 사용

③  행위패턴(행미인이텝옵스테비커스트메체)

Mediator : 중재자를 두어 통신의 빈도수 줄이는 디자인 패턴

Interpreter : 여러 형태의 언어 구문을 해석할 수 있게 만드는 디자인 패턴

Iterator : 내부구조를 노출하지 않고 객체의 원소에 순차적 접근 가능하게 하는 디자인 패턴

Template Method : 상위 작업의 구조는 변경하지 않으면서 서브클래스로 작업의 일부분 변경하는 디자인 패턴

Observer : 한 객체의 상태가 바뀌면 의존하는 다른 객체에서도 자동 갱신되는 디자인 패턴

State : 객체상태를 캡슐화하여 클래스화 하는 디자인 패턴

Visitor : 클래스의 메서드가 각 클래스를 돌아다니며 특정 작업을 수행하게 만드는 디자인 패턴

Command : 실행될 기능을 캡슐화하여 하나의 추상 클래스에 메서드를 만들면 그에 맞는 서브 클래스가 선택되어 실행되는 디자인 패턴

Strategy : 행위 객체를 클래스로 캡슐화 하여 동적으로 행위를 자유롭게 변화한 디자인 패턴

Memento : 객체를 이전 상태로 복구시켜야 하는 Undo기능의 디자인 패턴

Chain of Responsibility : 한 요청을 2개 이상의 객체에서 처리

(5)  현행 시스템 분석서 작성 및 검토

-     분석 산출물의 종류

①  현기인아소하네(정보시스템 구성 현황, 정보시스템 기능 구성도, 인터페이스 현황, 현행 시스템 아키텍처 구성도, 소프트웨어 구성도, 하드웨어 구성도, 네트워크 구성도)

2.   개발 기술 환경 정의

(1)  개발 기술 환경 현행 시스템 분석

-     운영체제 현행 시스템 분석

①  운영체제 개념 :  하드웨어 및 소프트웨어 사용이 가능하게 하고, 사용자와 하드웨어 간 인터페이스를 담당하는 프로그램

②  운영체제 종류 및 특징 : PC(윈도우, 유닉스, 리눅스), 모바일(안드로이드, iOS)
                       (안드로이드는 리눅스 OS 위에서 동작)

-     네트워크 현행 시스템 분석

①  네트워크 개념 : 노드 간 연결(데이터 링크)을 이용한 데이터 교환 기술

②  OSI 7계층 : 아파서 티내다 피나다(Application, Presentation, Session, Transport, Network, Data Link, Physical)

-     DBMS 현행 시스템 분석

①  DBMS 개념 : 데이터 베이스라는 데이터의 집합을 만들고, 저장 및 관리할 수 있는 기능들을 제공하는 응용기술

②  기능 : 중복제어, 접근통제, 인터페이스 제공, 관계표현, 샤딩/파티셔닝, 무결성 제약조건, 백업 및 회복

③  현행 시스템 분석 : 성능 측면(가용성, 성능, 상호 호환성), 지원 측면(기술 지원, 구축 비용)

-     미들웨어 현행 시스템 분석

①  미들웨어 개념 : 운영체제와 소프트웨어 어플리케이션 사이에 원만한 통신 이루어지게 제어 하는 소프트웨어

②  WAS 개념 : 서버계층에서 어플리케이션이 동작할 수 있는 환경을 제공, 안정적인 트렌젝션 처리 및 관리, 다른 이 기종 시스템과의 어플리케이션 연동 지원 서버

III.  요구사항 확인

1.   요구사항

(1)  요구사항 개념

-     요구공학의 개념 : 사용자 요구사항에 대한 도출, 분석, 명세, 확인 및 검증하는 구조화된 활동

-     요구사항 분류

	기능적 요구사항	비기능적 요구사항
개념	기능, 서비스	기능 이 외, 제약 사항 등
도출 방법	입력 혹은 상황에 따른 반응, 동작	품질 속성 관련, 시스템이 준수해야 할 제한 조건
특성	기능성, 완전성, 일관성	신뢰성, 사용성, 효율성, 유지보수성, 이식성, 보안성 및 품질관련 요구 사항, 제약 사항

 

(2)  요구공학 프로세스

-     요구 공학 프로세스 : 요구사항 개발 단계 + 요구사항 관리 단계

-     요구사항 개발 단계 구성(CMM Level 3)

①  도분명확(도출, 분석, 명세, 확인)

②  요구사항 도출 단계
기법 : 인터뷰, 브레인스토밍, 델파이기법, 롤플레잉, 워크숍, 설문 조사

③  요구사항 분석 단계
절차 : 요구사항 분류, 개념 모델링 생성 및 분석, 요구사항 할당, 요구사항 협상, 정형분석
기법 : 자료 흐름 지향 분석(데이터 흐름도, 자료 사전), 객체지향 분석(UML)
기술 : 청취 기술, 인터뷰와 질문 기술, 분석 기술, 중재 기술, 관찰 기술, 작성 기술, 조직 기술, 모델 작성 기술

④  요구사항 명세 단계
기법 : 비정형 명세 기법(자연어 기반), 정형 명세 기법(수학적인 원리 및 표기법)
원리 및 검증항목 : 명완검일수추개(명확성, 완전성, 검증 가능성, 일관성, 수정 용이성, 추적 가능성, 개발 후 이용성)

⑤  요구사항 확인 및 검증 단계
절차 : 요구사항 목록 확인, 요구사항 정의서 작성 여부 확인, 비기능적 요구사항의 확인, 타 시스템 연계 및 인터페이스 요구사항 확인

⑥  기법 : 요구사항 검토, 정형 기술 검토 활용(동료검토, 워크스루, 인스펙션), 프로토타이핑 활용, 모델 검증, 테스트 케이스 및 테스트를 통한 확인, CASE 도구 활용 검증, Baseline을 통한 검증, 요구사항추적표(RTM)를 통한 검증

⑦  상세 정형 기술 검토 기법 : 관리 리뷰, 기술 리뷰, 인스펙션, 워크스루, 감사

-     요구사항 관리 단계(CMM Level 2)

①  요구사항 관리 절차 : 요구사항 협상, 요구사항 기준선 설정, 요구사항 변경관리, 요구사항 확인 및 검증

2.   요구사항의 시스템화 타당성 붙석

(1)  요구사항의 기술적 타당성 검토

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

(2)  요구사항의 기술적 타당성 분석 프로세스

-     타당성 분석 결과 기록, 타당성 분석 결과의 이해관계자 검증, 타당성 분석 결과 확인 및 배포/공유

IV.  분석 모델 확인하기

1.   분석 모델 검증

(1)  분석 모델 검증 방법

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

(2)  분석 모델 검증 프로세스

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

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

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

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

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

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