정보처리기사 실기 1-2장

유스케이스 다이어그램 a

사용자와 다른 외부 시스템들이 개발될 시스템을 이용해 수행할 수 있는 기능을 사용자의 관점에서 표현한 것

구성요소

구성요소 표현방법 내용
시스템(System), 시스템 범위(System Scope) 상품주문 시스탬 내부의 유스케이스들을 사각형으로 묶어 시스템의 범위를 표현한 것
액터(Actor)
  • 주액터
    주액터
  • 부액터
    부액터
  • 시스템과 상호작용을 하는 모든 외부요소
  • 주로 사람이나 외부 시스템을 의미함
  • 주액터 : 시스템을 사용함으로서 이득을 얻는 대상르로, 주로 사람이 해당
  • 부액터 : 주액터의 목적 달성을 위해 시스템에서 서비스를 제공하는 외부 시스템. 조직이나 기관 등이 될 수 있음.
유스케이스(Use Case) 상품조회 사용자가 보는 관점에서 시스템이 액터에게 제공하는 서비스나 기능을 표현한 것
관계(Relationship)
  • 포함
    include
  • 확장
    extends
  • 일반화
    일반화
  • 유스케이스 다이어그램에서 관계는 액터와 유스케이스와 유스케이스 사이에서 나타날 수 있음
  • 유스케이스에서 나타날 수 있느 관계 : 포함(Include)관계, 확장(Extends)관계, 일반화(Generalization)관계

유스케이스 다이어그램 예제

  1. useCaseDiagramExample

유스케이스에서 나타날 수 있는 관계 a

포함(Include) 관계 두 개 이상의 유스케이스에 공통적으로 적용되는 기능을 별도로 분리하여 새로운 유스케이스로 만든 경우. 원래 유스케이스와 새롭게 분리된 유스케이스와의 관계
확장(Extends) 관계 유스케이스가 특정조건에 부합되어 유스케이스의 기능이 확장될 떄 원래의 유스케이스와 확장된 유스케이스의 관계

활동 다이어그램 (Activity Diagram) c

사용자 관점에서 시스템이 수행하는 기능을 처리흐름에 따라 순서대로 표현한 것

구성요소

구성요소 표현방법 내용
액션(Action), 액티비티(Activity)
  • 액션
    액션
  • 액티비티
    액티비티
  • 액션 : 더이상 분해할 수 없는 단일작업
  • 액티비티 : 몇개의 액션으로 분리될 수 있는 작업
시작 노드 start 액션이나 액티비티가 시작됨을 표현한 것
종료 노드 end 액티비티 안의 모든 흐름이 종료됨을 표현한 것
조간(판단) 노드 조건(판단)노드
  • 조건에 따라 제어의 흐름이 분리됨을 표현한 것
  • 들어오는 제어흐름은 한개 나가는 제어흐름은 여러개
병합 노드 병합 노드
  • 여러 경로의 흐름이 하나로 합쳐짐을 표현한 것
  • 들어오는 제어 흐름은 여러 개 나가는 제어흐름은 한개
포크(Fork) 노드 포크 노드
  • 액티비티의 흐름이 분리되어 수행됨을 표현한 것
  • 들어오는 액티비티의 흐름은 한개 나가는 액티비티의 흐름은 여러개
조인(Join) 노드 조인 노드
  • 분리되어 수행되던 액티비티의 흐름이 다시 합쳐짐을 표현한 것
  • 들어오는 액티비티의 흐름은 여러개 나가는 액티비티의 흐름은 한개
스윔레인(Swim Lane) 스윔레인
  • 액티비티 수행을 담당하는 주체를 구분하는 선
  • 가로 또는 새로 실선을 그어 구분함

활동 다이어그램 예제

  1. 액티비티 다이얼로그 예제

클래스 다이어그램 (Class Diagram) a

클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현한 것

구성요소

구성 요소 표현 방법 내용
클래스 (Class) class
  • 각각의 객체들이 갖는 속성과 오퍼레이션(동작)을 표현한것
  • 일반적으로 3개의 구획(Compartment)으로 나눠 클래스의 이름, 속성, 오퍼레이션을 표기함
  • 속성(Attribute) : 클래스의 상태나 정보를 표현함
  • 오퍼레이션(Operation) : 클래스가 수행할 수 있는 동작으로, 함수(메소드, Method)라고도 함
제약조건 제약조건
  • 속성에 입력될 값에 대한 제약조건이나 오퍼레이션 수행 전후에 지정해야 할 조건이 있다면 이를 적음
  • 클래스 안에 제약조건을 기술할 떄는 중괄호 {}를 이용함
관계 (Relationship)
  • 관계는 클래스와 클래스 사이의 연관성을 표현함
  • 클래스 다이어그램에 표현하는 관계에는 연관관계, 집합관계, 포함관계, 일반화 관계, 의존관계가 있음

클래스 다이어그램 예제

  1. 클래스 다이어그램 예제

연관 클래스 c

시퀀스 다이어그램 b

시스템이나 객체들이 메시지를 주고받으며 상호작용하는 과정을 그림으로 표현한 것

구성요소

구성 요소 표현 방법 의미
액터(Actor) Actor 시스템으로부터 서비스를 요청하는 외부 요소로 사람이나 외부 시스템을 의미함
객체(Object) Object 메시지를 주고 받는 주체
생명선(Lifeline) lifeline
  • 객체가 메모리에 존재하는 기간으로, 객체 아래쪽에 점선을 그어 표현함
  • 객체 소멸(X)이 표시된 기간까지 존재함
실행상자(Active Box, 활성상자) Active Box 객체가 메시지를 주고 받으며 구동되고 있음을 표현함
메시지(Message) Message 객체가 상호 작용을 위해 주고받는 메시지
객체 소멸 객체 소멸 해당 객체가 더 이상 메모리에 존재하지 않음을 표현한 것
프레임(Frame) 프레임 다이어그램의 전체 또는 일부를 묶어 표현한 것

시퀀스 다이어그램 예제

  1. 시퀀스 다이어그램 예제

커뮤니케이션 다이어그램 (Communication Diagram) a

시스템이나 객체들이 메시지를 주고받으며 상호작용하는 과정과 객체들 간의 연관을 그림으로 표현한 것

구성요소

구성요소 표현 방법 의미
액터(Actor) actor 시스템으로부터 서비스를 요청하는 외부 요소로, 사람이나 외부 시스템을 의미함
객체(Object) Object 메시지를 주고받는 주체
링크(Link) Link
  • 객체들 간의 관계를 표현
  • 엑터와 객체, 객체와 객체간에 실선을 그어 표현함
메시지(Message) Message
  • 객체가 상호 작용을 위해 주고받는 내용
  • 화살표의 방향은 메시지를 받는 쪽으로 향하게 표현함
  • 일정한 순서에 의해 처리되는 메시지의 경우 숫자로 순서를 표현함

커뮤니케이션 다이어그램 예제

  1. 커뮤니케이션 다이어그램 예제

상태 다이어그램 a

객체들 사이에 발생하는 이벤트에 의한 객체들의 상태변화를 그림으로 표현한 것

구성 요소

구성 요소 표현 방법 의미
상태(State) State 객케의 상태를 표현한 것
시작 상태 Start 상태의 시작을 표현한 것
종료 상태 End 상태의 종료를 표현한 것
상태 전환 End 상태 사이의 흐름, 변화를 화살표로 표현한 것
이벤트(Event) End
  • 상태에 변화르 주는 현상
  • 이벤트에는 조건, 외부 신호, 시간의 흐름 등이 있음
프레임(Frame) End 상태 다이어그램의 범위를 표현한 것

상태 다이어그램 예제

  1. State Diagram Example

패키지 다이어그램 (Package Dirgram) a

유스케이스나 클래스 등의 요소들을 그룹화한 패키지 간의 의존 관계를 표현한 것

구성 요소

구성 요소 표현 방법 의미
패키지(Package) package
  • 객체들을 그룹화한 것
  • 단순 표기법 : 패키지 안에 패키지 이름만 표현
  • 확장 표기법 : 패키지 안에 요소까지 표현
객체(Object) object 유스케이스, 클래스, 인터페이스, 테이블 등 패키지에 포함될 수 있는 다양한 요소들
의존관계(Dependency) dependency
  • 패키지와 패키지, 패키지와 객체 간을 점선 화살표로 연결하여 표현함
  • 스테레오 타입을 이용해 의존 관계를 구체적으로 표현할 수 있음
  • 의존 관계의 표현 형태는 사용자가 임의로 작성할 수 있으며, 대표적으로 import 와 access가 사용됨
    • «import» : 패키지에 포함된 객체들을 직접 가져와서 이용하는 관계
    • «access» : 인터페이스를 통해 패키지 내의 객체에 접근하여 이용하는 관계

패키지 다이어그램 예제

  1. State Diagram Example

구조적 방법론 b

구조적 방법론의 개발 절차

타당성 검토 단계→계획 단계→요구사항 단계→설계 단계→ 구현 단계→시험 단계→운용/유지보수 단계

객체지향 방법론 c

객체지향 방법론의 개발 절차

요구 분석 단계→설계 단계→구현 단계→테스트 및 검증 단계→인도 단계

컴포넌트 기반 방법론 (CBD : Component Based Design) b

컴포넌트 기반 방법론의 개발 절차

개발 준비 단계→분석 단계→설계 단계→구현 단계 →테스트 단계→전개 단계→인도 단계

소프트웨어 재사용 (Software Reuse) a

소프트웨어 재사용 방법

합성 중심 (Composition Based) 전자 칩과 같은 소프트웨어 부품 즉 블록을 만들어서 끼워 맞춰 소프트웨어를 완성시키는 방법. 블록 구성 방법이라고도 함.
생성 중심 (Generation Based) 추상화 형태로 써진 명세서를 구체화하여 프로그램을 만드는 방법. 페턴 구성 방법이라고도 함.

소프트웨어 재공학 (Software Reengineering) c

CASE a

비용 산정

하향식 비용 산정 기법 c

전문가 감정 기법 조직 내에 있는 경험이 많은 두 명 이상의 전문가에게 비용 산정을 의뢰하는 기법
델파이 기법 전문가 감정 기법의 주관적인 편견을 보완하기 위해 많은 전문가의 의견을 종합하여 산정하는 기법

상향식 비용 산정 기법 c

LOC (source Line Of Code, 원시 코드 라인수) 기법 a

수학적 산정 기법 b

COCOMO 모형 (COnstructive COst MOdel) c
COCOMO의 소프트웨어 개발 유형 a
Putnam 모형 b
기능 점수 모형 (FP : Function Point) b

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

SLIM Rayleigh-Norden 곡선과 Putnam 예측 모델을 기초로 하여 개발된 자동화 추정 도구
ESTIMACS 다양한 프로젝트와 개인별 요소를 수용하도록 FP 모형을 기초로 하여 개발된 자동화 추정 도구

PERT (Program Evalustion and Review Technique) c

CPM (Critical Path Method, 임계 경로 기법) b

  1. CPM Example

그림에서 굵은선이 임계경로(최장 경로)입니다.

간트 차트 c

ISO/IEC 12207 a

ISO/IEC 12207 구분

기본 생명 주기 프로세스 획득, 공급, 개발, 운영, 유지보수 프로세스
지원 생명 주기 프로세스 품질 보증, 검증, 확인, 활동 검토, 감사, 문서화, 형상 관리, 문제 해결 프로세스
조직 생명 주기 프로세스 관리, 기반 구조, 훈련, 개선 프로세스

CMMI (Capability Maturity Model Intergration) b

CMMI의 소프트웨어 프로세스 성숙도

단계 특징
초기(Initial) 작업자의 능력에 따라 성공 여부 결정
관리(Managed) 특정한 프로젝트 내의 프로세스 정의 및 수행
정량적 관리(Quantitaltively Managed) 프로젝트를 정량적으로 관리 및 통제
최적화(Optimizing) 프로세스 역량 향상을 위해 지속적인 프로세스 개선

SPICE (Software Progress Improvement and Capability dEntermination) c

SPICE의 프로세스 수행 능력 단계 a

수준 단계 특징
0 불완전 (Incomplete) 프로세스가 구현되지 않았거나 목적을 달성하지 못한 단계
1 수행 (Performed) 프로세스가 수행되고 목적이 달성된 단계
2 관리 (Managed) 정의된 자원의 한도 내에서 그 프로세스가 작업 산출물을 인도하는 단계
3 확립 (Established) 소프트웨어 공학 원칙에 기반하여 정의된 프로세스가 수행되는 단계
4 예측 (Predictable) 프로세스가 목적 달성을 위해 통제되고, 양적인 측정을 통해서 일관되게 수행되는 단계
5 최적화 (Optimizing) 프로세스 수행을 최적화하고, 지속적인 개선을 통해 업무 목적을 만족시키는 단계

소프트웨어 개발 방법론 테일러링 c

테일러링 : 프로젝트 상황 및 특성에 맞도록 정의된 소프트웨어 개발 방법론의 절차, 사용기법 등을 수정 및 보완하는 작업

소프트웨어 개발 방법론 테일러링 고려사항 : 테일러링이 필요한 경우

기준 내용
내부적 기준
  • 목표 환경 : 시스템의 개발 환경과 유형이 서로 다른 경우
  • 요구사항 : 프로젝트의 생명 주기 활동에서 개발, 운영, 유지보수 등 프로젝트에서 우선적으로 고려할 요구사항이 서로 다른 경우
  • 프로젝트 규모 : 비용, 인력, 기간 등 프로젝트의 규모가 서로 다른 경우
  • 보유 기술 : 프로세스, 개발 방법론, 산출물, 구성원의 능력 등 서로 다른 경우
외부적 기준
  • 법적 제약사항 : 프로젝트별로 적용될 IT Compliance 가 서로 다른 경우
  • 표준 품질 기준 : 금융, 제도 등 분야별 표준 품질 기준이 서로 다른 경우

소프트웨어 개발 프레임워크 (Framework) b

스프링 프레임워크 (Spring Framework) c

소프트웨어 개발 프레임워크의 특성 b

모듈화(Modularity)

재사용성(Reusability)

프레임워크는 재사용 가능한 모듈들을 제공함으로써 예산 절감, 생산성 향상, 품질 보증이 가능하다.

확장성(Extensibility)

프레임워크는 다형성(Polymorphism)을 통한 인터페이스 확장이 가능하여 다양한 형태와 기능을 가진 애플리케이션 개발이 가능하다.

제어의 역흐름(Inversion of Control)

개발자가 관리하고 통제해야 하는 객체들의 제어를프레임워크에 넘김으로써 생산성을 향상시킨다.

예상문제

  1. 다음은 유스케이스(Use Case) 다이어그램의 일부이다. 제시된 다이어그램에 표현된 관계를 쓰시오.
    1. quiz1
    답
    • 일반화(Generalization) 관계
  2. 다음은 상품대여 시스템에 대한 유스케이스 다이어그램과 그에대한 해석이다. 해석을 참고하여 유스케이스 다이어그램의 괄호 (1,2)에 들어갈 알맞은 내용을 쓰시오.
    1. quiz2
    • 사용자는 고객과 직원으로 구분된다
    • 직원은 상품등록 기능을, 고객은 상품대여 기능을, 사용자는 로그인 기능을 사용할 수 있다.
    • 직원이 상품등록 기능을, 고객이 상품대여 기능을 사용하려면 상품검색을 수행해야 한다.
    • 상품반납시 반납일이 지난 경우 연체금부과 기능을 수행한다.
    답
    • 1 : «include»
    • 2 : «extends»
  3. 다음은 활동(Activity)다이어그램과 그에 대한 해석이다. 해석을 참고하여 다이어그램의 괄호 (1 ~ 3)에 들어갈 알맞은 내용을 쓰시오
    1. quiz3

    회원 액터

    • 회원이 카드를 신청하기 위해 로그인 단추를 클릭한 후 회원정보를 입력한다.
    • 입력된 정보가 잘못됐으면 회원정보를 다시 입력받고, 그렇지 않으면 '카드발급 신청'으로 이동한다.
    • 카드발급 신청을 완료하고 액티비티를 종료한다.

    인증 시스템

    • 회원에 대한 본인 인증을 진행한다.
    • 인증에 성공하면 '신용 확인'으로 이동하고, 인증에 실패하면 '인증 재시도'로 이동한다.
    • 다시 진행한 본인 인증에 성공하면 '신용 확인'으로 이동하고, 이번에도 인증이 실패하면 액티비티를 종료한다.

    신용확인 시스템

    • 회원에 대한 신용 확인을 진행한다.
    • 신용 상태가 '신용 양호'로 확인되면 '신청 완료'로 이동하고, 신용상태가 '신용 불량'으로 확인되면 '발급 취소'로 이동한 후 액티비티를 종료한다.
    답
  4. 다음 괄호에 공통적으로 들어갈 가장 적합한 UML 클래스 다이어그램의 요소를 쓰시오
    • 주석(Note), 도형(quiz4)안에 ( )을 기술한 후( )이 적용될 속성이나 오퍼레이션을 점선으로 연결한다.
    • 클래스안에 ( )을 기술할 때는 중괄호 { } 를 이용한다.
    답
    • 제약조건
  5. 다음은 시퀀스(Sequence) 다이어그램의 일부와 그에 대한 해석이다. 해석을 참고하여 다이어그램의 괄호에 들어갈 알맞은 내용을 쓰시오.
    1. quiz5

    회원 액터

    • 로그인 버튼을 클릭한다.
    • ID와 비밀번호를 입력한다.
    • 로그인이 완료되면 카드 선택 화면에서 신청할 카드를 선택한다.

    카드선택화면 객체

    • [회원]이 신청할 카드를 선택하면 선택된 카드에 대한 [카드 : 신규신청] 객체를 생성한 후 소멸된다.

    카드 : 신규신청 객체

    • "신청생성" 메시지를 받으면 새로운 객체로 생성된다.
    • [인증 시스템]에게 회원에 대한 본인 인증을 요청한다.
    • 회원에 대한 인증이 성공하면 소멸된다.
    답
    • 신청생성
  6. 다음에 제시된 항목 중에서 UML의 시퀀스(Sequence) 다이어그램과 관계된 것만 모두 골라 쓰시오
    Object, Lifeline, Active Box, Swimlane, Message, Frame
    답
    • Object, Lifeline, Active Box, Message, Frame
  7. 다음 설명에 가장 적합한 UML시퀀스(Sequence) 다이어그램의 요소를 쓰시오.
    • 객체가 메모리에 존재하는 기간으로, 객체 아래쪽에 점선을 그어 표현한다.
    • 객체 소멸이 표시된 기간까지 존재한다.
    답
    • 생명선(Lifeline)
  8. 클래스(Class) 다이어그램에서 사용되는 연관 클래스의 개념을 간략히 서술하시오.
    답
    • 연관 클래스는 연관 관계에 있는 클래스에 추가적으로 표현해야 할 속성이나 오퍼레이션이 있는 경우 생성하는 클래스이다.
  9. 다음은 회원의 카드 발급 신청 과정을 표현한 커뮤니케이션 다이어그램이다. 회원액터와 직접적으로 관계된 객체를 모두 쓰시오
    1. quiz9
    답
    • 로그인 화면, 카드 선택 화면, 카드 : 신규신청, 신용: 신용확인 화면
  10. 다음은 본인인증 객체의 상태 변화를 표현한 상태(State) 다이어그램과 그에 대한 해석이다. 해석을 참고하여 다이어그램의 괄호(1~4)에 들어갈 알맞은 내용을 쓰시오.
    1. quiz10

    인증 준비 상태의 상태변화

    • 본인 인증 과정이 시작되면 객체는 인증 준비 상태로 전환된다.
    • 본인정보 입력 이벤트에 의해 인증 대기 상태로 전환된다.

    인증 대기 상태의 상태변화

    • 정보 일치 이벤트에 의해 인증 완료 상태로 전환된다.
    • 정보 불일치 이벤트에 의해 인증 실패 상태로 전환된다.

    인증 실패 상태의 상태변화

    • 인증 재시도 이벤트에 의해 인증 준비 상태로 전환된다.

    인증 완료 상태의 상태변화

    • 정보 일치 이벤트에 의해 인증 완료 상태로 전환된다.

    답
    • 1 : 본인 정보 입력
    • 2 : 인증 재시도
    • 3 : 정보 불일치
    • 4 : 정보 일치
  11. 다음이 설명하고 있느 소프트웨어 개발 방법론이 무었인지 쓰시오.
    • 현실 세계의 개체를 기계의 부품처럼 하나의 객체로 만들어, 소프트웨어를 개발 할 때 기계의 부품을 조립하듯이 객체들을 조립해서 필요한 소프트웨어를 구현하는 방법론이다.
    • 구조적 기법의 문제점으로 인한 소프트웨어 위기의 해결책으로 체택되었다.
    • 구성 요소에는 객체,클레스,메시지 등이 있다.
    • 기본 원칙에는 캡슐화, 정보 은닉, 추상화, 상속성, 다형성 등이 있다.
    답
    • 객체지향 방법론
  12. 소프트웨어 재사용(Software Reuse)의 개념을 간략히 서술하시오
    답
    • 소프트웨어 재사용은 이미 개발되어 인정받은 소프트웨어를 다른 소프트웨어 개발이나 유지에 사용하는 것이다.
  13. 비용 산정 기법 중 소프트웨어 각 기능의 원시 코드 라인 수의 비관치, 낙관치, 기대치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정하는 기법은 무었인지 쓰시오 답
    • LOC(원시 코드 라인수) 기법
  14. 다음이 설명하고 있는 알맞은 용어를 쓰시오.
    • 새로운 요구에 맞도록 기존 시스템을 이용하여 보다 나은 시스템을 구축하고, 새로운 기능을 추가하여 소프트웨어 성능을 향상시키는 것이다.
    • 유지보수 비용이 소프트웨어 개발 비용의 대부분을 차지하는 문제를 염두에 두 어 기존 소프트웨어의 데이터와 기능들의 개조 및 개선을 통해 유지 보수성과 품 질을 향상시키려는 기술이다.
    답
    • 소프트웨어 재공학 (Software Reengineering)
  15. LOC 기법에 의하여 예측된 총 라인수가 36,000라인, 개발에 참여할 프로그래머가 6명, 프로그래머들의 평균 생산성이 월간 400라인일 떄 개발에 소요되는 기간을 계산식과 함께 쓰시오
    답
    • 계산식 : (36,000 / 6 ) / 400 = 15
    • 15개월
  16. COCOMO 모델은 보헴(Boehm)이 제안한 것으로, 원시 프로그램의 규모인 LOC(원시 코드 라인수)에 의한 비용 산정 기법이다. COCOMO 모델의 3가지 프로젝트 유형을 쓰시오.
    답
    • 조직형(Organic Mode), 반분리형(Semi-Detached Mode), 내장형(Embedded Mode)
  17. 소프트웨어 비용 산정 기법 중 Rayleigh-Norden 곡선의 노력 분포도를 이용한 프로젝트 비용 산정 기법이 무었인지 쓰시오. 답
    • Putnam 모형
  18. 다음이 설명하고 있는 프로젝트 일정 계획 관련 용어를 쓰시오
    • 프로젝트 완성에 필요한 작업을 나열하고 작업에 필요한 소요 기간을 예측하는 데 사용하는 기법이다.
    • 노드에서 작업을 표시하고 간선은 작업사이의 전후 의존관계를 나타낸다.
    • 원형 노드는 각 작업을, 박스 노드는 이정표를 의미하며, 간선을 나타내는 화살표의 흐름에 따라 각 작업이 진행된다.
    답
    • CPM(Critical Path Method, 임계 경로 기법)
  19. 다음은 SPICE의 프로세스 수행 능력 단계를 순서대로 나열한 것이다. 괄호에 들어갈 알맞은 단계를 쓰시오.

    불완전→( )→관리→( )→( )→최적화

    답
    • 수행(Performed), 확립(Established), 예측(Predictable)
  20. 다음은 CPM(Critical Path Method) 네트워크이다. 임계 경로의 소요기일을 구하시오.
    1. quiz20
    답
    • 18일
  21. 소프트웨어 개발 표준 중 SPICE(소프트웨어 처리 개선 및 능력 평가 기준)의 개념을 간략히 서술하시오.
    답
    • SPICE 는 소프트웨어의 품질 및 생산성 향상을 위해 소프트웨어 프로세스를 평가 및 개선하는 국제표준이다.
  22. 다음은 소프트웨어 개발 방법론 테일러링 작업시 고려해야 할 사항들을 내부적 기준과 외부적 기준으로 분류하여 설명한 것이다. 괋호(1,2)에 들어갈 알맞은 기준을 쓰시오. 답
    • 1 : 프로젝트
    • 2 : 표준 품질
    내부적 기준
    • 목표 환경 : 시스템의 개발 환경과 유형이 서로 다른 경우
    • 요구사항 : 프로젝트에서 우선적으로 고려할 요구사항이 서로 다른 경우
    • ( 1 ) 규모 : 비용, 인력, 기간 등 ( 1 )의 규모가 서로 다른 경우
    • 보유 기술 : 프로세스, 개발 방법론, 산출물, 구성원의 능력 등이 서로 다른 경우
    외부적 기준
    • 법적 제약사항 : 프로젝트별로 적용될 IT Compliance가 서로 다른 경우
    • ( 2 ) 기준 : 금융, 제도 등 분야별 ( 2 ) 기준이 서로 다른 경우