정보보안 정보처리 기술사

1.요구공학 개요

가.정의

-요구사항을 정의하고 문서화하는데 필요한 요구사항의 추출,분석,명세,검증,유지보수 및 관리의 제반공정에 대한 체계적 접근방법( IEEE standard)

나.요구공학의 특징

 -개발범위,각종테스트 기준(단위,통합,인수),감리,검수 등 프로젝트 수행의 중요한 기준으로 활용

 -사용자의 요구사항은 추상적,불분명 하므로 분석이필요,지속적으로 변화하는 특성 가짐

다.요구사항 문제점 및 해결방안

2.요구공학 프로세스 및  명세속성

가 요구공학 프로세스

3.요구사항 명세 기준

가. 요구사항 명세 속성

나.요구사항 명세기법 

다.요구사항 명세서 포함내용

라.요구사항 명세화의 기준(고려사항)

-명확한표현,일관된 용어,간결한 표현

-기술적 내용과 제약조건 언급 하지 않도록 한다

-RFP,제안서,상위요구사항에 기초하여 정확하게 작성

-비기능적 요구사항도 모두 포함 작성

-사용자별 중요도,난이도 고려하여 우선순위화

-요구사항간에 양방향 추적가능해야 한다.

4.요구공학의 기대효과 및 활용방안

가.업무측면:업무연속성 보장,환경변화 신속대응,개발비용 절감

나.개발측면:잠재적 위험 관리 기능,사용자간 의사소통 용이,업무이해도 향상

다.사용자 요구 해결하기 위해 도메인 및 정보시스템 지식을 겸비한 요구분석 전문가 양성필요

=======================================================================================================

요구사항특징,요구공학프로세스,정형및비정형명세기법

답)http://nexcore.skcc.com/alm/alcinous/manual/index.jsp?topic=/nexcore.tool.rm.help/manual/guide/deductionguide/analasysmethod/analasysmethod.html

1.지속적인 변화를 수용하기 위한 요구사항의 특징

1.     요구공학 프로세스

2.     정형 및 비정형 명세기법

https://moodle.shinhan.ac.kr/pluginfile.php/636/mod_resource/content/3/Chap%208.%20SW%20%EC%9A%94%EA%B5%AC%EC%82%AC%ED%95%AD%20%EB%B6%84%EC%84%9D.pdf

요구사항 명세

I. 재사용성과 유지보수성 향상을 위한, 객체지향 설계의 개요

가. 객체지향(Object Oriented)의 정의

- 실 세계의 개체(Entity)를 속성(Attribute)과 메소드(Method)가 결합된 형태의 객체(Object)로 표현하는 개념,UML을 이용한 비주얼 모델링과 의사교환하는 SW개발방법론

나. 객체지향 의 등장배경

- 전통적 개발의 문제점 극복: 재사용,확장성,유지보수성 증대

- SW 위기 해결 대안 : 많은 개발시간,낮은 품질,높은 위험요소로 개발생산성 저하 발생

다. 객체지향 의 장점

라. 객체지향 의 특성

2. 객체지향 설계 5원칙
  1) 인퍼페이스의 분리 (I/F: Interface)
    - 의미: 하나의 I/F는 하나의 기능 갖음, (ex: 입력, 출력 I/F 각각 구성)
    - 방법: 명확한 I/F 성격 분리, 공유 I/F 재사용 극대화, 기 구현  Client 변경 최소화
    - 특징: Client는 사용하지 않는 I/F에 의존관계 맺지 않음(소스레벨 가독성 향상)

  2) 개방폐쇠 원칙 (Open-Closed Principle)
    - 의미: 소프트웨어 Entity(classes, Modules, Function)는 확장에는 열려있고

               수정에는 닫혀있어야 한다는 설계 원칙(상속기능,유연성확보)

    - 방법: 클래스간 공통속성 추출 추상클래스 디자인, 상속받아 세부구현, Adapter 통한 접근
    - 특징: Class 변경에 따른 클라이언트 코드 변경 및 영향 최소화
  3) 단일책임의 원칙 : SRP (Single Responsibility Principle)
    - 의미: 객체가 제공하는 모든 서비스는 그 하나만의 책임만을 수행해야 한다는 원칙(응집도향상)

    - 방법: Extract Class, Extract Method 이용, 책임별 Class로 분할, 같은 책임 통합.
    - 특징: 함수(I/F)가 아닌 객체에 초점. 산탕총 수술 (변경 전파 폭풍) 방지
  4) 리스코프 치환원칙 (Liskov Substitution Principle)
    - 의미: 자식들은 부모타입들이 사용되는 곳에 대체될 수 있어야 함.
    - 방법: Overriding, Overloading. 부모 Class와 동이란 I/F 이름 이용.
    - 특징: 파생 클래스는 확장이 주요 목적, 추가는 부가적 문제. 부모 클래스 책임을 넘지 않음.
  (5) 의존관계 역전의 원칙 (The Dependency Inversion Principle)
    - 의미: 의존 대상은 파생 클래스가 아닌 추상 클래스여야 함.(상위레벨 클래스 의존만 가능)
    - 방법: Interface에 의한 프로그래밍, 객체간 연동.
    - 특징: 참조는 부모 클래스 I/F에 의존. LSP 선행 필수.

                 (낮은결합도,확장성 높아져 유지보수성 햐상)

3. 객체지향 설계원칙의 활용 및 고려사항
  가. 설계 품질평가: Class Diagram, 참조도를 객체지향 원칙에 준하여 품질 평가
  나. 리팩토리 기준: Class 구성을 설계 원칙에 부합하도록 분해/통합 및 I/F 분리 수행
  다. 지나친 일반화 배제: Class의 비대화 및 기능 불명확 땨른 설계원칙 위해, 모호성 발생
  라. 디자인패턴 활용: 객체지향 설계원칙 적용의 Best Practice 도입으로 효과적인 적용.
"끝"

======================================================

1.컴포넌트 재사용을 통해 생산성을 향상시키는 CBD 방법론 개요
가.CBD (Component Based Development)방법론의 정의
- 컴포넌트 개발, Repository에 저장, 컴포넌트 조립을 통해
재사용성과 비즈니스 적시성을 향상시키는 개발 방법론
나.CBD 방법론의 진화형태
- Porduct Line : 제품중심 Core Assets 식별, CBD 기반 개발
- SoA : 공유와 재사용 가능한 서비스를 컴포넌트와 조합
2.CBD 방법론의 주요 특징
가.CBD 방법론의 주요 특징
1) UseCase Driven : 사용자 요구사항 분석으로 컴포넌트 식별
2) Blackbox Reuse : I/F 기반의 컴포넌트 호출
3) Iteration : 개발단계 반복을 통해 위험을 취소화
4) Lossely Coupled : MVC 모델에 기반한 약결합 구현
나.CBD 방법론 절차
1) 컴포넌트개발(CD) : usecase로 컴포넌트 식별하고 개발, 저장소저장
2)컴포넌트조립(CBSD) : 기존 컴포넌트를 조립하여 SW 개발
다.CDB 방법론의 종류
1)UP(Unified Process) : UML 기반, 아키텍처중심, 2차원구조(동적, 정적)
2)마르미III : 한국형CBD, 분석강조, 미니프로젝트 반복, 프로토타입 후 진행
3)Catalysis : UML 표기기반 CBD, 분산시스템 모델링/구축
3.CBD 개발 SW의 평가 요소
가.응집도:컴포넌트 기능의 충실도, 높을 수록 좋음
나.결합도:컴포넌트간의 관련성, 낮을 수록 좋음
다.독립성:플랫폼 종속성 여부, 종속되지 않아야 함
라.Round Trip Engineering : 분석/설계/구현/테스트 자동화 도구 지원 여부
=======================================================
*** 추가사항
1.CBD 방법론의 장점
가.생산성 : 부품 조립을 통해 APP 개발시간 단축 및 개발 생산성 향상
나.변경용이성 : 요구사항 수용에 안정적이고 신속한 변경 가능
다.재사용성 : 바이너리 기반의 재사용 및 컴포넌트 대체 용이
라.관리용이성 : 독립적인 컴포넌트 단위로 복잡성 최소화
마.기술집약성 : 기술 숙련에 대한 검증, 아키텍처, 프레임워크, 분산 객체 기술 등

2.컴포넌트 식별 방법
가.유즈케이스 시나리오 분석을 통한 컴포넌트 도출
- include : 동일하게 반복되는 <> 관계의 유즈케이스 도출
- extend : 특정조건에 의해 수행되는 <>관계의 유즈케이스 도출
나.설계단계의 UI Layout 설계 혹은 UI 네비게이션 설계 시 도출
- 공통 UI (공통화면일 경우), 공통 UI 컨트롤(페이지 Up/Down 등 상/하위 컨트롤 도출)
다.<> 클래스 상관관계 분석을 통한 컴포넌트 도출 : Core클래스 + 종속클래스그룹핑
라.Usecase와 <> 클래스의 상관관계 분석으로 도출
마.전문가 판단

문) MDA

1. 설계모델의 재사용 극대화 MDA

 가. MDA(Model Driven Architecture)의 정의

  - 핵심 메타모델을 근간으로 구현환경에 독립적인 모델을

    자동으로 구현환경 종속적 모델로 변환하는 컴포넌트 기반 구조

 나. MDA의 필요성

  - CBD의 기술 종속적인 모델의 재사용 욕구 증대

  - 설계와 구현의 분리로 설계모델 재사용 극대화

2. MDA의 절차 및 구성요소

 가. MDA의 절차

    - PIM(Platform Independent Model) : 기술모델에 독립적모델

    - PSM(Platform Specific Model) : 기술모델에 종속적모델

나. MDA 구성요소

다. 모델 변환의 종류

3. MDA의 고려사항 및 활용

 가. PIM변환 명확화, 변환작업의 자동화/경량화 및 기술변화에 대한

     구현환경의 지속적 UML Profile관리가 필요함

 나. MDA기반 프로세스 정립을 위해 MOF호환을 위한 UML 2.0 지원이

     필요하고 기술변화에 대한 유연적 대처및 유지보수비용절감이 가능함

●  주요특징

효율성 : 기술 변화 상황에 효율적으로 대처할 수 있다.

이식성 : MDA 방식으로 개발된 시스템은 PIM을 통해서 변경된 기술 플랫폼으로 이식이

쉽게 이루어질 수 있기 때문이다.

유연성 : 시스템 인프라 변화에 유연하게 대처할 수 있다.

유지보수성,투자비용 :MDA 방식으로 개발된 시스템은 그 시스템의 유지 보수

비용이 적으며 시스템의 수명이 길다.

따라서 투자 비용이 보존된다.

● UML Profile 

MDA에서 UML 프로파일은 중요한 위치를 점하고 있다.

MDA에서 PSM은 UML로 표현되어야 한다. 하지만 특정 기술 플랫폼의 개념들이 UML로

어떤 식으로 표현되어야 하는지에 대한 것은 UML 자체에 포함되어 있지 않다. 예를 들면

이를 위해서 OMG에서는 해당 플랫폼에 따라서 UML 프로파일을 만드는 작업을 진행

-------------------------------------------------

문) MDA
1.디자인 패턴 활용 극대화 모델 MDA
가.MDA(Model Driven Architecure)의 개요
  - 메타모델을 기반, 구현환경독립적 시스템(PIM)개발,
    자동화 도구를 통해 구현환경종속모델(PSM) 변환 SW 방법론    
나.MDA 주요 특징
  - 구현자동화 : 메타모델 통한 CORBA, EJB, .NET, COM 구현
  - 상호운영성 ; UML 표준 사용으로 이기종 플랫폼에 독립
2.MDA 핵심기술와 구축 절차 및 변환도구
가.MDA 핵심기술
  1)) MOF(Meta-Object Facility) : 정보 모델의 저장소, 문법과 구조를 정의한 메타모델
  2) UML 2.0 : MOF와의 호환성을 위한 메타모델
  3) UML Profile : 사용자 정의 언어, UML 확장, 구현모델 자동 매핑  
  4) CWM : 메타 데이터 상호 교환을 위한 표준 저장소, DB 모델 변환
  5) XMI : MoF를 XML로 매핑하기 위한 표준 사양
나. MDA  구축절차(MDD 개발)
  1) CIM : 개념화 관점의 요구사항을 모델에 적용
  2) PIM :  요구사항 분석,설계 내용을 가지는 플랫폼 독립적 모델
  3) PSM : 구현을 위한 상세 설계내용을 가지는 플랫폼 종속적 모델
다.MDA의 변환 도구
  1) UMT : 중간모델기반, XML,XMI,XSLT를 이용한 모델변환 및 코드 생성
  2) MTL : 직접변환, 다중상속 지원,메타모델 저장소를 통한 메타모델 재사용
  3) ATL : 직접변환, ATL 변환 규칙 정의 언어를 사용해 UML->XMI->JAVA 변환
3.MDA의 주요 현황과 고려사항
가.재사용 관점 진화 : 구현 모듈 재사용에서 설계 재사용으로 변화
나.Round Trip Engineering : SDLC 전과정의 자동화 지원
다.UML 2.0 : UML 1.X의 MOF 와의 호환 미흡 완벽 지원
=====================================================
CIM : Computation Independent Model), PIM(Platform Independent Mode)
PSM(Platform Specification Model), CWM(Common Warehouse Model)

-----------------------------------------------------------------------

I. MDA 기반의 PIM,PSM와 변환을 위한 도구의 개념
    -PIM:요구사항 분석,설계 내용을 가지는 플랫폼 독립적 모델
    -PSM:구현을 위한 상세 설계내용을 가지는 플랫폼 종속적 모델
    -MDA는 PIM을 PSM 형태로의 변환을 통해 요구분석->설계 또는 설계->
     구현 과정의 재사용성 향상,코드의 자동생성,개발속도 향상 개발 방법
    -모델변환과정:PIM --> (Intermediate Model) --> PSM
                          --------------------
     실체변환과정:UML -->        XMI           --> JAVA,C++ 등
II. PIM,PSM 변환 도구의 종류 및 선택 기준
  가. PIM,PSM 변환 도구의 종류
  --------------------------------------------------------------------
  구분 변환도구                 도구 특징 설명
  --------------------------------------------------------------------
  중간  UMT    -XML,XMI,XSLT를 이용한 모델변환 및 코드 생성
  모델         -UML->WSDL,XML Schema,Java Interface,EJB 등으로 변환
  기반         -Source Model->Intermediate Model->Transformer 변환
               -XMI Light Model 사용을 통한 양방향 모델 변환 매핑 지원
  --------------------------------------------------------------------
  직접  MTL    -모델변환 엔진과 모델변환 정의 언어 기능
  변환         -다중상속 지원,메타모델 저장소를 통한 메타모델 재사용
               -쉽고 명확한 명세가 어렵고 복잡한 변환규칙 미지원
        ATL    -ATL 변환 규칙 정의 언어를 사용해 UML->XMI->JAVA 변환
               -변환규칙 정의가 명확하고 이해하기 쉬움
               -변환모델에 대한 재사용,합성 지원
               -Header(목표모델정의),Helper(명세),Rule(변환규칙) 구성
  --------------------------------------------------------------------
  나. PIM,PSM 변환 도구 선택 기준
  --------------------------------------------------------------------
                ATL,MTL                           UMT
  --------------------------------------------------------------------
   -변환규칙 추상화레벨 제공               -명확한 변환 규칙 제공
   -변환모델의 재사용,합성제공(ATL)        -양방향 모델 변환 매핑 지원
   -Repository 활용한 변환모델 재사용(MTL)
  --------------------------------------------------------------------
    -변환 방식에 따른 특징이 존재하며 재사용성과 양방향 모델 변환 매핑
     측면에서 개발 조직에 보다 가치가 있는 방법을 선택 사용
III. MDA 효과성 향상 방안
    -Embedded SW:동일한 Logic의 Target 형태에 따른 서로 다른 구현에
     대한 개발 속도 및 품질 향상에 적용
    -AOP(Aspect Oriendted Programming) 기법의 적용을 통한 핵심,횡단
     관심사 구현 용이성,효율 향상 활용

================================================================

1.설계단위 재사용을 위한 MDA(Model Driven Architecture)의 개요

  가. MDA의 정의

    -SW 설계 모델을 명세하고 이를 상세설계 모델과 코드로 변환하여 프로그램을 자동으로       생성하는 새로운 기술 개발

  나.MDA의 활용의 장점

    1)재사용(reuse):시스템 분석,설계,구현,결과 관리등 프로젝트 전체 과정 재사용 가능

    2)구현 자동화: 메타모델을 이용하여 구현 정의 대부분을 자동화할수 있는구조.

    3)이식성(Portability):구현환경과 독립적으로 정의되므로 이식성 증가

    2)소프트웨어 품질(Quality):설계모델 재사용으로 품질 향상.

    -어플리케이션 개발비용,품질,생산성 향상을 가지고 옴

2.MDA 구성요소 및 활용분야

  가.MDA 구성요소

   1)MOF(Meta Object Facility):플랫폼에 독립적인

   2)CWM(common warehouse Meta)

   3)UML Profile:

   4)XMI(XMLmetadata interchange)

  나.mda적용시 기대효과 및 전망

   1)프로젝트 진행 과정 전체를 재사용 할 수 있다

   2)메타모델을 이용한 구현 공정 자동화 용이함

   3)공공 콤포넌트 개발:

   4)소프트웨어 아키텍처:

문)       유즈케이스 모델링
답)
1.        시각적 요구사항 분석표현 유즈케이스 모델링의 개요
    가.    유즈케이스 모델링(UseCase Modeling)의 정의
       -  행위자(Actor),유즈케이스(usecase),관계(relation)를 통하여 시스템
          의 기능이나 요구사항등을 시각적으로 표현한 모델링기법
    나.   유즈케이스 모델링의 구성요소
       -  행위자(Actor):시스템과 상호작용하는 사람 또는 사물
       -  유즈케이스(Usecase):시스템이 제공하는 서비스
       -  관계(Relation):행위자와 유즈케이스간,행위자간,유즈케이스간
           상호연관성
2.        유즈케이스 모델링의 절차 및 사용예제
    가,   유즈케이스 모델링 절차
       1) 행위자 식별
       2) 유즈케이스 식별
       3) 관계 설정:행위자,유즈케이스간 관계 및 제약조건 분석
       4) 유즈케이스 구조화:공통 서비스 및 제약,확장 관계 정의
       5) 유즈케이스 명세:업무흐름의 다양성 기록,대안흐름,선후행조건기술
나.    과목 수강신청 유즈케이스 모델링 예제

문) Usecase Modeling
답)
1. 객체지향 요구사항 분석 UseCase Modeling의 개요
 가. UseCase Modeling의 정의
  - 사용자의 시각에서 SW의 범위와 기능을 쉽게 정의하고, 기능적 요구사항을 나타내는 모델링기법
 나. UseCase Modeling의 구성요소
  - Actor : 시스템 외부에 독립적으로 존재하면서 시스템과 교류, 상호작용을 하는 것
  - Usecase : 시스템이 Actor를 위해서 수행하는 작업
  - Relation : Actor와 UseCase, UseCase간, Actor간의 상호연관성
  - 주요산출물 : Usecase Diagram, UseCase명세서, 부가기술서
2. Usecase 작성절차와 작성규칙
 가. UseCase 작성절차
  절차                                 내용
1. Actor 식별                    사용자의 역할, 상호작용하는 타 시스템, 연동HW식별
2. UseCase식별                Actor가 요구하는 정보, 서비스를 식별
3. 관계설정                      Actor, Usecase간 관계분석 및 정의
4. Usecase구조화             UseCase의 공통 서비스 추출
5. Usecase명세                 업무흐름다양성 기록, 대안흐름작성 등 UseCase명세서 작성
 나. Use Case 작성규칙
  - Actor 와 UseCase 명칭을 직관적으로 이해가 쉽도록 정의
  - 모든 UseCase는 하나이상의 Actor와 교류해야함
  - UseCase의 추상화 레벨은 일정한 수준 유지
  - UseCase의 크기 단위에 대한 일관성 정의
3. UseCase Model의 활용 시 고려사항
 가. 현업사용자 : 업무를 UseCase화 하는 교육, 훈련 참여
 나. 개발자 : 플랫폼 독립적 설계하여 재사용성을 높일 필요성 있음
 다. 관리자 : 정확한 요구사항 파악을 위한 반복적 분석 필요
끝.

======================================================================================

요구사항 2교시

architecture view

나선형

유즈케이스모델링

공공 ipin 취약점

문) UML 2.0
답)
1. 객체지향 개발을 위한 통합 모델링 UML2.0의 개요
    가. UML2.0(Unified Modeling Language)의 정의
          - OMG에서 다양한 모델링 기법을 통합하여 개발. 실행 모델 기반
            MDA와 MDD등 OMG 표준간의 상호호환성 제공하는 모델링 언어
    나. UML2.0의 개선 사항
          - 자동화 강화 : 분석에서 개발 테스트까지의 과정을 자동화 지향
          - 정확성과 표현력 확장 : 추가 다이어그램 및 OCL 기능 추가
2. UML2.0의 주요 개선 사항 및 추가 다이어그램
    가. UML2.0의 주요 개선 사항
          - MDA 지원 : PIM, PSM 모델 통한 플랫폼 비 종속적 개발
          - BPEL 지원 : 비즈니스 서비스 오케스트레이션 지원
          - MDD : Round Trip Engineering의 전 개발과정 지원
          - 상부영역과 하부영역의 모델 구조
     나. UML2.0의 추가 디이어그램
            - Composite Diagram : [그림] 컴포넌트 상호 작용 및 내부 구조 표현
            - Package Diagram : [그림] 컴포넌트 그룹 관계 표현, 패키지 구조 표현
            - Timing Diagram : Sequence Diagram + State Machine Diagram, 시간 흐름
            - Interaction OverView Diagram : Activity Diagram + Sequence Diagram, 논리 흐름
3. UML2.0의 활용방안 및 기대 효과
    가. UML2.0을 통한 전체 개발 과정의 자동화 및 재사용성 향상
          개발자간 또는 사용자 간 가시적 모델링 통한 이해 용이성 향상.
    나. UML Profile 활용 : 개발 영역, 개발 언어, 개발 환경에 따른 Profile 활용
          자동화 도구 활용 : CASE 툴, UML 지원 IDE 등을 활용한 FrameWork 활용

1.java코드변환
2.유즈케이스 모델링
3.MDA
4.SCRUM
5.나선형모델
6.소프트웨어아키텍처뷰
7.요구공학(2교시)
8.감리
9.기능점수(2교시)
10.객체지향설계원칙(2교시)

문) RUP 4+1 View
답)
1. SW요구사항-분석-설계-구현-시험의 일관성 유지 RUP4+1View
 가. RUP 기본 시스템을 바라보는 관점
  1) 사용자(고객) : 요구사항(Usecase), 사용사례, 명세등 자연어 접근
  2) 설계자 : 요구사항 분석/설계/시험공정을 Object & Association
  3) 개발자 : class & component, interface & Deploy 로 파악
  4) 시스템엔지니어 : 실제 패키지의 HW배치, 실행모듈 상태로 접근
 나. RUP 4+1 View의 Usecase driven 특징
  1) usecase 중심으로 4 view 균형 잡음
  2) 각각 view가 연관/종속 관계 유지, 요구사항~시험공정 전체 표현 가능
2. 4+1 View 구성요소 & SA의 4View 비교
 가. 4+1 View 구성요소
  1) Usecase : 액터관점, Usecase식별, 관계파악, Usecase/Activity diagram
  2) Logic : 분석, 설계, class & interface, class/sequence diagram
  3) Implementation : 구현패키지/Interface, 구현아키텍처 적용, 컴포넌트 diagram
  4) Process : 컴포넌트/패키지가 실행상태 일때 표현(DLL, ActiveX)
  5) Deployment : 컴포넌트/패키지가 HW에 설치된 상태, HW구성/제원표기
 나. RUP 4+1 View와 SA 4View 비교
    RUP 4+1 View                       SA 4View
  1) usecase                         C&C view    : 개념,시스템상위레벨,컴포넌트관계식별
  2) logic                              Model view    : 논리,분할(MVC), Layed, Pipe&Filter
  3) Implementation              Code view      : 물리,소스코드 구조화
  4) Process&Deployment    Allocation view : 실행, 시스템 런타임 객체 속성정의
3. RUP 4+1 view 사용시 기대효과
 가. 고객중심 : 시스템 중심에 usecase위치, view간 균형이 어긋날 경우, usecase가 판단기준, 고객과 의사소통(usecase spec.)
 나. usecase>class분석/설계>component구현>Testcase연결 : 사용사례 실체화(usecase Realization)통한 추적성/연관성 관리
끝.

----------------------------------------

1   소프트웨어 아키텍처를 위한 UP의 아키텍처 뷰 개요
 가  UP의 아키텍처 뷰(Unified Process Architecture View) 정의
  1) Software Architecure: 소프트웨어 요소와 이들 요소의 외부속성 그리고 이들
   사이의 관계를 구성하는 시스템 구조
  2) 아키텍처 뷰: 소프트웨어 아키텍처의 논리적 구성,기능,병행성,설치위치 등의
   특정관점에서 시스템을 해석(UP는 UML를 사용하여 4+1 View정의)
2   아키텍처 뷰의 종류 
 가  4+1 아키텍처 뷰
  - UseCase: 액터와 유즈케이스간의 관계정의, 시스템아키텍처 도출
  - Logical: 시스템의 기능요구사항설명, 클래스/인터페이스/협력관계 정의
  - Process: 독립실행 컴포넌트와 이들간의 관계를 정의
  - Implement: 스레드와 프로세스정의(병렬/동화기처리), 비기능적요구사항설명
  - Deployment: 실행되는 시스템 H/W와 S/W의 관계 정의
 나  소프트웨어 아키텍처 4가지 뷰
  - Componet Connector: 핵심컴포넌트정의, 각 컴포넌트간 인터페이스 정의
  - Allocation: 컴포넌트의 배치(H/W), H/W현황정보 제공
  - Module: 컴포넌트에서 수행되는 모듈정의, 모듈기능정의
  - Code: 컴포넌트가 사용하는 패키지 정의
3.   4+1 아키텍처 뷰의 활용 및 고려사항
  - 4+1 View는 사용자,분석가/테스터,프로그래머,시스템통합자,시스템엔지니어어게
   전체 시스템의 모습을 보여줄 수 있는 아키텍처를 제시
  - 기능적, 비기능적(품질특성)을 반영하여 소프트웨어의 품질을 향상 시킴
  - 아키텍처 구축시에 반복적 프로세스 수행을 통해서 품질향상을 수행함. “끝”

문)나선형 모델
답)
1. 진화적 프로토타입 모델 나선형 모델의 개요
 가. 나선형 모델(Spiral Model)의 정의
  - 개발될 주요기능을 사전에 위험분석을 통해 반복적으로 수행하여 최종 소프트웨어 개발까지 순차/점진적으로 구현하는 모델
 나. 나선형 모델의 특징
  - 대규모, 위험의 높은 프로젝트에 적합(예, 신기술 및 신규 도메인 프로젝트)
  - 위험 관리를 통한 위험최소화(위험식별, 발생가능성,영향도출PI metrix 활용)
2. 나선형 모델의 접근전략 및 비교
 가. 나선형 모델의 접근전략
  1) 계획 및 정의 : 요구사항 분석, 계획수립, 고객의 평가반영
  2) 위험분석 : 초기위험분석, 정성적위험분석(전문가감정,델파이기법), 정량적위험분석
  3) 개발 : 초기 프로토타입, Horizental, Vertical
  4) 고객평가 : 사용자관점 Validation, 인스펙션, 체크리스트 활용
 나. SDLC 모델간 비교
    비교항목               폭포수                      나선형                   RAD
       위험                  낮은위험                 높은위험              낮은위험
     SW규모           소~중규모                  대규모                   소규모
      접근                     순차적                 순차및반복형          반복형
    주요특징         명세화강조                  위험분석           사용자참여(JRP,JAD)
3. 나선형모델의 기대효과 및 고려사항
 가. IT Compliance : Secure코딩 의무화에 따라 보안공통부분 나선형모델 적용
 나. Framework : 핵심공통모듈, 품질확보를 위한 적용고려
 다. 발주기관 : 프로토타입 통해 검증된 기능 품질
 라. 사업자측면(PM) : 불명확한 요구사항으로 반복횟수 증가 등 일정지연 고려.
끝.

#############################################################################

정리)SCRUM
 1. 팀의 유기적 결합, Tracking을 중시하는 SCRUM
가. SCRUM의 개요
- 작은 개발팀, 짭은 개발주기, 팀 집중력과 생산성 유지로
   점진적, 박복적으로 SW를 개발하는 Agile Process
 2.SCRUM의 특징과 프로세스
 가.SCRUM의 특징
  1)독립적 : 개발언어나 개발 방법론에 종속되지 않음
  2)팀중심 : 팀 단위의 활동과 구현
  3)범용성 : SW 개발, 유지보수, 프로젝트 적용 가능
 나.SCRUM 프로세스
  1)Product Backlog : 요구사항목록(기능, 비기능)
   2)Sprint : 스크럼 팀의 반복 주기(2~4주)
   3)Daily SCRUM : Daily 회의(15분, 진행상황, 팀 진척 확인)
   4)Sprint Review Meeting : 산출물 데모,  Sprint Review
   5)Sprint Restrospective : 지속적 개선 검토
3.SCRUM 이해관계자와 관리대상
  1)Product Owner : User Story 작성 및 우선순위화, Product Backlog작성
  2)Scrum Master : 장애물 제거,불안요소 중재,계획 주도, 코치역할
  3)Scrum Team : Sprint 달성위한 주도적 작업수행, 자율성 강조
  4)관리대상 : Product BackLog, Story(요구사항), Estimate
 ====================================================================== 
추가적 파악사항
1.SCRUM의 프로젝트 관리 영역별 방안
 가.프로젝트관리품질(개발 일정) : 스프린트 백로그
 나.프로젝트관리품질 진척도 : 소멸 챠트
 다.프로세스품질(생산성) : 소멸 챠트 , 수행속도 , 스프린트 주기
 라.프로세스품질(재작업율) : 스프린트 백로그

2.SCRUM과 XP
가.개발(XP) : 지속적인 통합, 공동 소유, Pair 프로그래밍
 나.설계(SCRUM) : 테스트부터 시작하고 설계 및 구현, 반복과 단순화로 설계
 다.테스트전략 : 코딩보다 단위테스트를 먼저하고, 테스트를 자동화
 라.계획세우기, 작은 시스템 릴리즈, Metaphor 등 XP의 12가지 실천사항 병행
 마.기존 방법론과의 결합은 SCRUM의 장점과 유연성이 감소

3.방법론과 Agile방법론의 결합하여 Enterprise Project 수행 방안
 가.전통적 개발프로세스
  - 프로젝트 관리, 일정관리, PM 및 PMO수행
 나.SCRUM
   - 세부 Task 관리, 세부 일정 및 리소스 관리, PM 및 PL수행
 다.SCRUM과 XP 결합 :
   - Sprint시 XP의 Pair Programming, TDD, Refactoring 등
    실천법을 적 용한 개발

문제)정보시스템 감리
답)
1.공공정보화 개발사업에 대한 의무감리의 개요
  가.정보시스테 감리의 목적
    1)사업의 성공적 수행을 위해 sw개발의 문제점 개선
    2)객관적 평가 및 검토:발주기관 및 사업자에 독립된 기관의 평가
  나.최근 정보시스템 감리의 동향
    1)전자정부법:5억이상 sw개발 사업의 의무감리 시행
    2)감리해설서:사업의 유형별,감리관점별,감리영역별 점검사항 제시
2.
  가.정보시스템 감리의 절차
    1)예비조사:주요이슈,위험식별하여 기본적 점검가이드(항목)  정의
    2)현장감리:사업관리 및 품질,응용DB,시스템 구조 및 보안에 대한 점검
    3)시정조치:개선사항에 대한 조치를 확인한다(시정조치 보고서 작성)
    4)검수지원:공식적인 활동은 아니지만 추가지원을 실시한다.
  나.감리시의 주요활동

3.최근 감리의 문제점과 동향
 가.개발일정의 변경
   -사업자의 일정변경과 감리일정에 대한 조율이 필요함.
 나.발주기관에 대한 의존성:감리제안과 평가에 의한 의존성 발생
 다.보안에 대한 점검:개발보안 의무 점검 실시(취약점 점검 등은 제외)
 라.운영감리:ITSM을 이용한 운영감리 의무화 미비

4.
  가.정보시스템 감리와 ISMS(관리체계인증)와의 차이점        
  

  나.감리의 수행인력           

============================================================================================================

=============================================

1.지속적인 기능 개선 sw 유지보수의 문제점

가. 문제점 및 개선방향

문제점                                                                                 개선방향

2.유지보수 비용

3.유지보수 종류

가.목적에 따른 분류

1)하자보수(corrective):발견되지 않은 오류가 시스템 인수되어 사용시 발견됨

           유지보수 도중 오류가 유입됨(장애장치 분리 및 재구성,원래상태로 복구)

2)기능개선(perfective):새로운 기능추가 (sw개선)

3)환경적응(adaptive):환경의 변화에 의해 수행되는 변경

4)예방조치(preventive):유지보수성이나 신뢰성 향상시키는 작업,재공학(문서갱신,설명추가)

나.시간에 따른 분류

   1)계획보수:정해진 기일에 정해진 변경내용 수행 하는 것

   2)예방보수:에러발생을 미리 방지하기 위해 수행하는 형태(예:Fail Over)

   3)응급보수:예측못한 에러가 발생할 경우 수행하는 유지보수

   4)지연보수:유지보수가 필요하나 긴급성 정도에 따라 추후 수행하는 유지보수

1. 구조기반 기법(Structure based techniques = White Box) 개요

- 소프트웨어가 어떻게 구성되었는가에 대한 정보. 즉, 코드와 디자인의 테스트케이스를 유도하는데 사용.

2. 구조기반 테스트 기법 종류 및 제어흐름 테스트 기법

가. 구조기반 테스트 기법 종류

나.제어흐름 테스트 기법

3.구조기반 테스트기법과 명세기반 테스트 기법 차이점

===================================================

1.경로검증 테스트 whitebox test검증기준 개요

  가.화이트박스 테스트의 정의

     -프로그램 로직 테스트. 모든 경로에 대하여 테스트를 수행하였는지 경로를 확인

  나.검증 목표

     -모들의 기능을 모두 테스트하여 모듈 오류를 최소화

 2.화이트박스 테스트 예제 및 검증기준

3.화이트 박스 테스트 검증 기준의 활용 및 현황
가. 소프트웨어 알고리즘이 복잡한 경우 모든 경로를 분석하여 테스트를 수행
나. 모듈에서 오류가 발생할 경우가 많은 대규모 시스템 및 위험이 높은 소프트웨어 적용
나. 모든 경로를 테스트 하는 경우 많은 비용/시간/인력이 필요함.
다. 전문 테스터 및 테스트 검증 자동화 툴을 활용하여 테스트 정확성과 생산성을 향상 “끝

======================================================================

문)구조기반 테스트
답)
1.구조기반테스트(화이트박스 테스트)의 개요
가.구조기반테스트의 정의
  -개발자 입장에서 프로그램의 내부 논리적 구조및 복잡도 초점에 맞춰
   수행하는 동적 테스트
나.구조기반테스트의 특징
  -개발자입장:코드내부구조의 효율성,동적테스트(실행)
  -Coverage 제공:오류발견,순환복잡도(테스트 수 상한성)제공
2.구조기반테스트 기법및 검증기준
가.구조기반테스트 기법
  1)기초경로검사
   -제어흐름도:제어흐름을 표현하기 위해 사용되는 그래프
   -순환복잡도:논리적 복잡도 측정을 위한 SW척도,프로그램 독립 경로수 파악

  2)제어구조검사
   -Condition Testing:프로그램 모듈내 논리적 조건 검사|조건검사 범위 측정
   -Loop Testing:반복구조에 초점,검사사례기법(단순,중첩,연결,비구조적 루프)|경계값오류
   -Data Flow Testing:프로그램 변수의 정의와 사용 위치 초점|프로그램 사용변수
나.구조기반 테스트 검증기준
  -문장검증기준:원시코드 각 라인 최소 한번이상 수행
  -선택검증기준:경로에 나타나는 모든 분기점 파악,참/거짓 모두 테스트
  -경로검증기준:수행가능한 모든경로 검사
  -조건검증기준:if문장,while문장 안 모든 조건 검사
3.구조기반 테스트의 활용방안및 고려사항
가.테스트 설계:초기 고객 요구사항으로부터 설계 어려움
나.테스트 커버리지 측정:목표 커버리지 달성위한 케이스 도출
다.SW구현정보(코드,설계)기반:분석 장시간 소요우려
라.컴포넌트레벨(구문/결정/분기문테스트),통합레벨(모듈간 호출관계 테스트),
  시스템레벨(메뉴,비즈니스프로세스,웹페이지 구조 테스트)

========================================================

75회 Whitebox test

84회 블랙박스테스트(Balckbox Test)와 화이트박스테스트(Whtiebox Test)를 비교 설명하시오

86회 Testcase

White Box/Black Box Test 설명

가.White Box Test

• program source code의 논리적인 구조를 cover하도록 test case를 설계하는 방법(구조 test)
• program 내부 구조에 존재하는 모든 경로를 실행

1. 문 cover 범위(statement coverage) : program내의 모든 문장들을 한번 이상 실행하도록 요구하는 기준
2. 결정 cover 범위(decision coverage) = 분기 cover 범위 : 각 결정의 참과 거짓을 적어도 한번 이상 실행시키는 것을 기준으로 하는 test 방법
3. 조건 cover 범위(condition coverage) : 결정내에 존재하는 각 조건들의 참과 거짓을 한번 이상 실행하도록 test case를 작성
4. 결정-조건 cover 범위(decision/condition coverage) : 결정내에 존재하는 조건들의 참과 거짓을 모두 cover하고 각 결정의 참과 거짓에 해당하는 모든 분기들이 모두 cover 될 수 있도록 충분히 test case를 만들어 나가는 방법

나.Black Box Test

-.원시 코드는 보이지 않고 목적코드를 실행시켜 테스트하는 입출력 위주의 방법

-.사용자 중심의 테스트 유형

문)프로젝트 위험관리
답)
1. 위험의 예측 및 통제를 위한 프로젝트 위험관리의 개요
     가. 프로젝트 위험관리(Project Risk Management)의 정의
            - 프로젝트 완수에 부정적 영향요소 식별/측정/통제/대응을
               통해 Risk 요소의 Issue화를 억제하는 관리 기법
     나. 프로젝트 위험관리의 필요성
            - 비즈니스 연속성 : 제난, 장애, 오류로 인한 업무 중단 방지
            - 대응 비용 절감 : 사전 예측, Issue 대응 비용 최소화
2. 프로젝트 위험관리 기법의 종류
    가. 정성적 위험관리 기법
         - 위험요소의 식별, 중요도, 우선순위 관리
         - Risk Rating Analysis Matrix : 발생가능성, 우선순위 판별
         - BIA : 비즈니즈 영향도/범위 평가
         - Risk Diagram : 발생 확률 기반. 몬테카를로 시뮬레이션 활용
         - Delphi Technoque : 반복 회의를 통한 위협 식별
    나. 정량적 위험관리 기법
         - 정성적 위험을 정량화 통해 수치적 관리
         - Risk Return Model : 위험과 기회 간의 비용 순환 관계 분석
         - 민감도 분석 : Issue화 가능 수치. 발생률 측정
         - 의사결정 트리 : Decision node, event node, cost, 기대치 결과값의 트리
         - EMV : 위험/기회의 화폐가치 측정.
3. 프로젝트 위험관리 전략 및 관리
    가. 절차 : 전략수립->위험식별->분석->대응전략->통제
          대응 전략 : 위험 분석통한 회피, 수용, 억제, 전가, 공유 대응 수립
     나. 지속적인 Risk 관리를 통해 Risk가 파급 영향을 주는
            Issue가 되지 않도록 모니터링 및 통제. "끝"

=================================================================

http://i-bada.blogspot.kr/2012/05/blog-post_6750.html

1. 성공적인 소프트웨어 개발을 위한 위험관리 개요
가. 위험관리(Risk Management) 정의
- 프로젝트 위험을 식별하고 분석하여 대응방안을 수립, 실천하는 과정
- 프로제트 진행 중에 주기적으로 수행해야 하는 프로젝트 관리사항

-기회는 극대화, 위험을 최소화하여 프로젝트의 성공가능성을 높이기 위한 일련의 행위

나. 정성적 및 정량적 위험분석 관계

    위험식별 ---------> 정성적 위험분석 ------------>정량적 위험분석(영향도 분석)

                위험요소                            위험우선순위

다. 프로젝트 위험관리의 목표  
   1) 프로젝트의 성공가능성을 높이기 위한 활동
   2) 정상적인 프로젝트의 수행환경을 조성
   3) 프로젝트의 불확실성을 지속적으로 감소
   4) 프로젝트 수행 중 발생하는 위험요소를 사전에 감지하고 제거하는 것

2. 정성적 위험분석 기법
가. 정성적 위험분석 정의
- 식별된 위험을 심층 분석하기 전에 위험에 대한 우선순위를 정하는 단계이다.

   우선순위를 정하기 위해 위험이 발생할 확률 및 영향을 ‘정성적’으로 판단한다

나.위험 확률 및 영향 평가 /확률 및 영향 매트릭스(PI Matrix)

3.정량적 위험분석

가.정의
-위험의 영향을 구체적인 수치로 분석하는 단계이다. 정량적 분석을 통해 프로젝트 목표의 달성확률을 구한다

나.정량적 위험분석 종류

1)인터뷰 - 프로젝트 이해 관계자, 전문가들에 대한 위험에 관한 설문 조사

2)민감도 분석-프로젝트 성공에 영향을 주는 여러 요인 중 어떤 요인이 잠재적으로 가장 영향을 미칠 것인지를 판단하   

                  는 기법이다. 독립변수와 종속변수의 두 변수로 판단하는 기법이며 단순하고 오차가 많은 대신 신속히

                 파악할 수 있다는 장점이 있다.

3)의사결정 트리 분석-어떤 의사결정을 했을 때 어떤 결과가 나타나는지 그 경우를 따져보는 기법이다
                               의사결정 트리를 만들어가면서 의사결정수 분석을 수행한다