4. 요구사항 관리
4.1 요구사항 관리의 개념
4.2 요구사항의 발견
4.3 요구사항의 발견 절차
4.4 정보시스템에서 요구사항 관리의 위치
4.5 정보시스템 요구사항 관리 라이프 사이클
4.6 사전탐색 단계
4.7 문제분석 단계
4.8 요구사항 분석 단계
4.9 제안요청 및 업체결정 단계
4.10 정리
4.11 연습문제
4.1 요구사항 관리의 개념
요구사항 관리는 요구사항 발견
, 문제 분석, 정리의 과정을 통칭하는 개념이다.
요구사항 관리를 위하여 가져야 하는 기본적인 사항은 아래와 같다
- 우리가 관리해야 하는 요구사항은 정보시스템에 대한 것이다
- 정보시스템에 대한 요구사항 관리는
정보시스템 관련자
(임원, 사용자, 시스템 설계자, 시스템 개발자) 과점과
정보시스템 분석관점
(Data, Process, 연결서비스, 외부서비스)에서 수행한다
- 요구사항은 두가지의 종류가 있다
: 기능적 요구사항(Functional Requirement) : Information System에서 구현해야 하는 기능적 요구사항을 정리한것
(예) 기능 관점: 입력기능, 보고서 작성 …
데이터 관점
: 입력데이터, 출력데이터
입
,출력 방식 : 모바일 지원, 외부 연결…
화면 구동방식
: 화면의 구성 및 연결 ….
: 비기능적 요구사항(Nonfunctional Requirement) : 기능외의 요구사항을 말한다
(예) 요구되는 성능, 산출물의 품질/형식, 시스템의 보안 기능, 사용의 편리성
4.1 요구사항관리의 개념
요구사항의 발견
(Requirement Discovery)은
- 시스템의 문제를 발견하거나 도출시키고,
- 고객이 원하는 것을 발견하고 정리하기 위하여
- 시스템 분석가에 의해 사용되는 기법을 포함하는 개념이다
문제 분석
(Problem Analysis)는
- 문제를 이해하고
- 문제를 인식하며
- 문제에 해당하는 제약사항을 확인하는 것을 말한다
요구사항의 정리는
- 정리되거나 발견된 요구사항을
- 주어진 목적에 맞추어
- 분류하는 과정을 말한다
4.2 요구사항의 발견
[ 요구사항 발견이 어려운 이유 ]
고객과 개발자는 각각 다른 분야에서 일을 하기 때문에 각기 사용하는 용어가 다르다
그러므로 정확한 의미전달이 부족한 경우가 많다
개발자는 고객이 처한 상황과 환경에 대해 잘 알지 못한다
고객은 개발자가 가지는 기술적 한계와 문제점에 대해 잘 알지 못한다
고객은 자신이 원하는 것을 개발자가 이해하도록 정확하게 표현하지 못하거나
, 정확하게 인식하지 못한다
고객은 자신의 입장에서 생각한다
(임원입장, 각 사용자는 자신의 입장)
요구사항은 계속해서 변하고 있다
고객이 표현하지 않은 요구사항도 많다
기능적인 요구사항 외에도 비 기능적인 요구사항도 동시에 고려해야 한다
4.2 요구사항의 발견
요구사항의 발견
(Requirement Discovery)에서 중요한 것은 동일한 말에 대해서 사람마다 느끼는 것이
다르다는 것을 이해하는 것에서 시작한다
. 그러므로 요구사항은 누구나 동일하게 이해할 수 있는
표준적인 형식과 용어를 사용하여 쓰여져야 한다
(예) “이번에 개발하는 시스템은 웹을 지원하여야 한다”라는 요구사항은 명확하지 않다.
구체적으로 어떤 점이 애애한지에 대하여 정리해 본다
- 모바일 웹을 지원해야 하는가 ?
- 어떤 브라우저의 어떤 버전을 지원해야 하는가?
- 한글만 지원하면 되는가? 영문은?
- ……
잘못된 요구사항은
- 개발 비용을 증가 시키고,
- 개발 기간을 맞추지 못하게 하고
- 고객의 만족을 얻을 수 없다
요구사항 오류의 발견시점
상대 비용
요구사항 수렴단계
1
설계단계
4~7
코딩단계
11
통합테스트단계
(개발자)
20~60
인수테스트단계
(고객참여)
40~80
운영단계
50~2000
4.3 요구사항의 발견 절차
요구사항의 발견
(Requirement Discovery) 절차
문제의 발견 및 분석
문제에 대한 요구사항 발견
요구사항 관리
요구사항 분석 및 문서화
이시가와 다이어그램
기존 시스템의 분석
문헌조사
, 인터뷰
브레인스토밍
프로토타이핑
사용자스토리
유스케이스
DFD
요구사항 변경 절차
요구사항별 수해일정 및 진행상태 관리
기능적
, 비기능적 요구사항 정리
요구사항 정리 형식의 표준화
개발 또는 운영에 대한
제약사항에 대한 명시
인터페이스나 네트웍으로
연결되는 시스템에 대한 명시
기존환경의 문서
, 화면, 데이터베이스 등의 분석 후에
고객을 방문하여 실제 운영되는 것을 살펴보고서
고객및 시스템에 대해 이해한다
그다음
, 고객과의 인터뷰를 위한 준비를 한 다음
고객과 인터뷰를 하고
이것을 기반으로 프로토타입을 제작한 다음
JRP를 수행해서 요구사항을 발견한다
요구사항 발견 절차
(예)
자세한 설명은 다음장에 있다
경영진
사용자
시스템
설계자
시스템
개발자
( S
y
s
te
m
A
n
a
ly
s
t
)
시
스
템
분
석
가
데이터 관점
(Data)
프로세스 관점
(Process)
연결 서비스
관점
(Interface)
외부서비스
관점
(Network)
서비스 수준
서비스 기능
연결 서비스
요구사항
외부 서비스의
요구사항
필요한
데이터
업무처리
순서
연결서비스의
기능
, 위치
외부 서비스의
기능
, 위치
데이터베이스
구조
어플리케이션의
구조
연결서비스의
연결방안
외부 서비스의
연결 방안
데이터베이스
프로그램
어플리케이션
제작
연결서비스의
연결
외부서비스의
연결
PIECE Framework
Hardware/Software 제품
지식 및 표줕화 동향
Communication &
Documentation Skill
1. 사전탐색
2. 문제분석
4. 제안요청 및
업체 결정
요
구
사
항
관
리
3. 요구사항분석
객체지향 관점
(Object-Oriented View)프로그래밍 + Framework
class, object, inheritance, encapsulation, polymorphism, interface
component, service, design pattern, refactoring, TDD, unified process
프
로
젝
트
관
리
1. 범위협상 및
확정
2. 타스크 식별
3. 타스크수행
기간 예측
4. 타스크간 의존성
확인 및 일정관리
5. 자원의 할당 및
조직구성
6. 개발팀의 구성
및 운영
7. 감시와 통제
8. 프로젝트 종료
공통 기술
임원
,
외부컨설턴트
문제분석
(Problem
Analysis)
요구사항분석
(Require-
mentAnaly-
sis)
제안요청 및
업체 결정
(RFP)
프로젝트팀
(Project Team)
: 고객, 임원, System Analyst, System Designer
-
새로운 비즈니스의 수행
-
새로운 영역의 추가
-
운영중인 시스템의
문제 해결
-
관련된 사람 참여
-
범위나 제약
-
예산
, 일정
-
개발 환경분석
승인
-
사실과 환경분석
-
영향분석
-
원인분석
시스템 개선 목표 확정
(System Improvement
Objectives fix)
-
요구사항 정리
-
우선순위 설정
비즈니스요구사항
명세서
(=정의서)(Business
Requirement Statement)
[ RFP&제안 ]
-
아키텍쳐
-
구현일정
-
구현방법
-
팀의구성
프로젝트
시작
사전탐색
(Prelimi-
nary Inves-
tigation)
제안에 대한
승인 및 보완
4.5 정보시스템 요구사항 관리 라이프 사이클
구현
(Implementa-
tion)
실무자
,
시스템 운영자
프로젝트팀
(Project Team)
: 고객, 임원, System Analyst, System Designer
-
관련된 사람 참여
-
범위나 제약
-
예산
, 일정
-
개발 환경분석
-
사실과 환경분석
-
영향분석
-
원인분석
-
요구사항 정리
-
우선순위 설정
[ RFP&제안 ]
-
아키텍쳐
-
구현일정
-
구현방법
-
팀의구성
-
아이디어
-
표준
, 기술
-
구현방향
-
WBS
-
설계 및 개발
-
데모 및 피드백
-
팀구성
-
단위
,통합테스트
-
문서화
-
교육
-
리펙토링
-
인수테스트
-
프로젝트팀 해체
-
인수테스트
-
종료보고서
-
운영상황에 대한 보고
-
요구사항에 대한
시스템의 대응 보고
-
문제발생 및 대응 보고
4.6 사전 탐색 단계
임원
, 경영진
문제
, 기회 또는
새로운 비즈니스
뱡향에 대한
요청 목록 제작
프로젝트
요청
공유된 프로젝트범위
기술서를 이용하여
사전 범위 협상
PIECE 프레임웍과
Information Sys-
tem Architecture
사용
예비 문제 기술서
조정된
프로젝트범위 기술서
예비문제 기술서를 통합하여
프로젝트 범위 기술서를
제작 및 공유
프로젝트범위 기술서를
기반으로 프로젝트의
가치 평가
간단하고
, 예측을
포함한
프로젝트 계획 수립
프로젝트 계획에
대한 설명
프로젝트가
가치가 있다고 판단한 경우
일정
, 리소스 추가
프로젝트 범위 기술서
프로젝트 계획
발표와
협의
승 인
서비스요청서
서비스요청서
, 예비문서 기술서의 양식 및
실제 작성 사례는 뒷페이지에서 제공
: 새로운 비즈니스의 수행, 영역의 추가, 문제해결에
대한 서비스 요청을 하는 것이다
입력
: 서비스 요청서, 출력 : 프로젝트의 승인
서비스 요청서
요구일자
: 2019. 2. 11
요구부서
: 중원대학교 학사운영팀
요구 담당자
: 조현희 (학사운영팀 대리)
이전요구날짜
:
[ 요구사항 설명 ]
현재의 학사 운영 시스템에서 가장 중요하고 많이 사용하는 기능이 수강 신청 기능이다
수강시청 기능을 늘 사용하는 것이 아니고
, 일년에 2번 단기간에 많은 학생이 사용하는 특성이 있다
현재 시스템은 평상시에는
3초이내의 속도를 보이는데, 수강신청 기간에는 제대로 속도가 나지 않아서 많은 학생들의 불만이 많은 상황이다
특이한 경우에는 신청된 수강 신청 내역이 늦은 속도로 인하여 두번 입력되거나
, 다른 것으로 바꾸어서 들어가는 경우가 많다
[ 요구사항에 대한 기대 ]
현재의 수강 신청 시스템을 학생들이 모이는 시기에도
5초 이내의 성능을 나타내도록 보완해야 한다
수강신청 시스템의 성능이 늦어지더라도
, 잘목 입력되거나 두번 입력되는 경우가 발생하지 않도록 보완해야 한다
[ 비용 및 중요성 정리 ]
긴급성
: ASAP , 3개월 , 6개월 , 1년
소요비용
: W _______________________________________
[ 승인 ] 전산팀장 ________________________ 경영기획실장 ______________________________________
예비문제기술서 양식
프로젝트명
: 중원대 학사 운영 시스템 개발
프로젝트 관리자
: 조민호
작성
: 조현영, 조현익
처음 작성일
: 2019. 3. 1
개정일
(1차) : 2019. 4. 1
개정일
(2차)
문제나 기회 또는 개발하기를 원하는 방향
급한정도
리스트 중
우선순위
연관된
요구사항
타시스템에
대한 영향도
제안된 방법
1. 학사 운영 시스템이 수강신청 기간에 반응 속도가
30초이상인데
이것을
5초이내로 작동하기를 원한다
ASAP
1
DB, H/W를 포함한
재개발
2. 학사 운영 시스템에서 수강신청 화면에 이전에 수강했던 과목에 대한
정보가 동시에 보여지기를 원한다
ASAP
2
6
수강
DB연결
수강
DB와 연결기능
개발
3. 학사 운영 시스템에 로그온시에 다른 시스템과 동일한 ID/PWD를
사용하도록 만들고 싶다
1 Year
5
통합로그온
통합로그온 기능을
사용하도록 변경
4. 학사 운영 시스템의 화면색과 라인이 너무 흐려서 전체 내용을 볼 때
,
위
, 아래의 항목을 식별하기 어렵다
1 Year
6
화면 디자인 보완
5. 학사 운영 시스템을 외국인도 사용할 수 있도록 영어, 중국어를 지원
해야 한다
ASAP
3
별도 개발
6. 학사 운영 시스템에서 수강 신청이 가능한 항목을 별도로 보여주어야
한다
6 Month
4
2
수강
DB연결
수강
DB와 연결기능
개발
예비문서 기술서는 각 문제나 기회
, 개발을 원하는 요청을 지정된 양식으로 받아서 정리한 것이다
프로젝트의 범위가 정해지면
, 예비문서 기술서의 내용 중에서 프로젝트 범위 기술서에 속하는 것이 새로 정리되어 “범위에 맞춘 예비문서 기술서＂를 구성한다
구축
(Construc-
tion)
구현
(Implementa-
tion)
실무자
,
시스템 운영자
프로젝트팀
(Project Team)
: 고객, 임원, System Analyst, System Designer
-
관련된 사람 참여
-
범위나 제약
-
예산
, 일정
-
개발 환경분석
-
사실과 환경분석
-
영향분석
-
원인분석
-
요구사항 정리
-
우선순위 설정
[ RFP&제
안
]
-
아키텍쳐
-
구현일정
-
구현방법
-
팀의구성
-
아이디어
-
표준
, 기술
-
구현방향
-
디자인 스펙
-
프로젝트 계획서
-
WBS
-
설계 및 개발
-
데모 및 피드백
-
팀구성
-
단위
,통합테스트
- 개발완료
-
문서화
-
교육
-
리펙토링
-
인수테스트
-
프로젝트팀 해체
-
인수테스트
-
종료보고서
-
운영상황에 대한 보고
-
요구사항에 대한
시스템의 대응 보고
-
문제발생 및 대응 보고
4.7 문제 분석 단계
임원
, 경영진
문제 영역에
대한 분석
프로젝트
승인
문제와
기회 분석
프로젝트범위 기술서
(
문제중심
)
현시스템 문서
모델링 및 운영
환경 분석을 이용한다
문제영역 확정과
관련용어나 처리절차 확인
프로젝트범위 기술서 및
관련 문서를 기반으로
Cause/Effect 분석 수행
비즈니스
절차 분석
시스템의
개선 목적 설정
프로젝트
계획의 보완
문제와 프로세스에 대한
분석 완료
시스템 개선 목적
과
cause-effect,
제약사항 정리 후
개선 대상의 선정
최종 선정된
시스템 개선 목적
발표와
협의
시스템 개선 목표 확정
문제 영역의
프로세스 분석
Cause/Effect , 시스템 개선목적 및 제약사항
정리를 위한 양식과 샘플은 뒤에 있다
4.7 문제 분석 단계
Cause and Effect Analysis는
- 주어진 문제에 대하여 원인(Cause)과 영향(Effect)를 분석하는 기법이다
- 분석은 단위작업수준까지 내려가서 분석이 수행되어야 한다
단위작업
: 더 이상 쪼개서는 의미가 없고, 다른 것과 연관을 가지지 않는 수준의 작업
(예) 로그온 작업은 ID/ PWD입력을 쪼개는 것은 의미가 없다.
그리고 다른 것과 연관없이 단위 작업을 수행한다
시스템 개선 목적
(System Improvement Objectives)
- 올바른 목적의 설정은 프로젝트를 투명하게 하고 성공을 위한 첫 걸음이다
- 목적은 구체적이어야 한다
(예) 3초이내의 작업 종료, 주말 배치 작업을 2시간 이내 완료 …..
제약사항
(Constraint)
- 목적에 맞추어 개발하거나 정의할 때 반드시 지켜야 하는 사항이다
- 설정된 제약사항은 변경될 수 없다
4.7 문제 분석 단계
Cause-Effect and System 개선 목적의 정리
프로젝트명
: 중원대 학사 운영 시스템 개발
프로젝트 관리자
: 조민호
작성
: 김민중, 박연수
처음 작성일
: 2019. 3. 1
개정일
(1차) : 2019. 4. 1
개정일
(2차)
Cause and Effect Analysis(원인과 영향 분석)
System Improvement Objectives(시스템 개선 목적)
문제나 기회
원인과 영향
시스템의 목적
시스템의 제약사항
1. 학사 운영 시스템이
수강신청 기간에 반응
속도가
30초이상인데,
이것을
5초이내로
작동하기를 원한다
단기간에 너무 많은 접속자수로 발생
교육이나 학교에 대한 만족도에 영향을
미치고 있음
잘못된 입력으로 사후 수정에 많은 노력이
들어가고 있음
…….
수강신청 기간동안
5초 이내의
성능이 필요함
외부 인터넷망의 속도는 증가될 수
없다
하드웨어
, 데이터베이스를 모두
개선할 예산이 없음
2. 학사 운영 시스템에서
수강신청 화면에 이전에
수강했던 과목에 대한
정보가 동시에 보여지기를
원한다
복학생들이나 편입생의 경우
, 본인이 수강한
과목에 대한 것을 기억하지 못함
수강신청을 위해 여러 개의 윈도우를 수행
하는 것은 화면이 복잡해 져서 사용이
어려움
….
수강신청 화면에 이전에 수걍했던
과목을 리스트로 보여주어야 함
현재시스템에서 수강테이블을
조작하는 기능을 추가해야 하는데
개발자가 퇴사해서 지원 불가
3. 학사 운영 시스템에
로그온시에 다른 시스템과
동일한
ID/PWD를
사용하도록 만들고 싶다
별도의
ID/PWD를 기억하는 것이 번거로움
학생들이 여러 번 로그인하는 과정에 대하여
불편을 호소함
이미 사용중인 통합로그온 시스템과
연계하여 운영해야 함
학사운영 시스템의 로그온 부분의
연결은 프로젝트 팀이 수행해야 함
………………….
구축
(Construc-
tion)
구현
(Implementa-
tion)
실무자
,
시스템 운영자
프로젝트팀
(Project Team)
: 고객, 임원, System Analyst, System Designer
-
관련된 사람 참여
-
범위나 제약
-
예산
, 일정
-
개발 환경분석
-
사실과 환경분석
-
영향분석
-
원인분석
-
요구사항 정리
-
우선순위 설정
[ RFP&제안 ]
-
아키텍쳐
-
구현일정
-
구현방법
-
팀의구성
-
아이디어
-
표준
, 기술
-
구현방향
-
디자인 스펙
-
프로젝트 계획서
-
WBS
-
설계 및 개발
-
데모 및 피드백
-
팀구성
-
단위
,통합테스트
- 개발완료
-
문서화
-
교육
-
리펙토링
-
인수테스트
-
프로젝트팀 해체
-
인수테스트
-
종료보고서
-
운영상황에 대한 보고
-
요구사항에 대한
시스템의 대응 보고
-
문제발생 및 대응 보고
4.8 요구사항 분석단계
임원
, 경영진
요구사항 정리
시스템개선
목적 확정
기능적
요구사항 분석 및
정리
시스템 개선 목적
기능적
, 비기능적
요구사항을고려
Reverse Engineering
GUI 분석
Process(절차) 분석
요구사항
리스트 확정
요구사항의
우선순위 결정
프로젝트
계획의 보완
최종 요구사항 내용 확정
요구사항에 대한
우선순위 협의
요구사항명세서
제출
발표와
협의
비즈니스 요구사항
명세서
(정의서) 완성
요구사항 구체화
프로토타입을 포함한
모델화 단계 수행
요구사항 정리
완료
요구사항 명세서에 포함되어야 하는 내용은
뒤에 정리되어 있다
4.8 요구사항 분석 단계
요구사항 명세서에 포함되어야 하는 내용
- 프로젝트에 대한 설명
- 시스템의 목적과 제약사항
- 시스템의 기능 설명과 사용자의 특성 정리
- 시스템의 데이터 모델과 요구사항 명세
- 시스템의 프로세스 모델과 요구사항 명세
- 시스템의 인터페이스 모델과 요구사항 명세
- 시스템의 네트웍 모델과 요구사항 명세
- 만들어진 프로토타입 화면과 프로세스 명세
- 설계(Design) 단계의 계획과 일정
- 성능요구사항 및 설계 제약사항
IEEE std 830-1998 에서 권고하는 요구분석 명세서의 항목
문서에서
21 페이지 이후에 보면 실제 요구사항명세서의
목차가 예시되어 있다
.
실제 작성하고자 하는 경우에는 제시된 목차를 기반으로
필요한 내용을 추가
/삭제 하는 방식으로 진행하면 된다
중요한 내용은 오른쪽에 정리하였다
구축
(Construc-
tion)
구현
(Implementa-
tion)
실무자
,
시스템 운영자
프로젝트팀
(Project Team)
: 고객, 임원, System Analyst, System Designer
-
관련된 사람 참여
-
범위나 제약
-
예산
, 일정
-
개발 환경분석
-
사실과 환경분석
-
영향분석
-
원인분석
-
요구사항 정리
-
우선순위 설정
[ RFP&제안 ]
-
아키텍쳐
-
구현일정
-
구현방법
-
팀의구성
-
아이디어
-
표준
, 기술
-
구현방향
-
디자인 스펙
-
프로젝트 계획서
-
WBS
-
설계 및 개발
-
데모 및 피드백
-
팀구성
-
단위
,통합테스트
- 개발완료
-
문서화
-
교육
-
리펙토링
-
인수테스트
-
프로젝트팀 해체
-
인수테스트
-
종료보고서
-
운영상황에 대한 보고
-
요구사항에 대한
시스템의 대응 보고
-
문제발생 및 대응 보고
4.9 제안요청 및 업체 결정 단계
임원
, 경영진
RFP 발행
비즈니스 요구사항
명세서 제공
각 제안의
솔루션 분석
(외부전문가 활용
가능
)
전문업체에게
RFP 전송
개발 요청 또는
통합
SI 요청
각 제안별
적합성
(Feasibility) 분석
제안된
솔루션간의 비교
제안사와의
변동사항 협의
프로젝트
계획의 보완
제안사의 선택
상세사항에 대한
협의 수행
합의된
내용 제출
발표와
협의
제안에 대한
승인 및 보완
모든 제안에 대한
분석을 마친후 진행
업체는 제안요청서에 맞추어
제안서를 제출
제안사 통합 비교
적합성
(Feasibility) 분석
자체 개발하는 경우는 이번 슬라이드의 내용 중에서 제안서를 받는 부분을
자체 설계 부분으로 대신하면 된다
. RFP는 가능하면 자체 제작하는 것이 좋다
제안별 적합성 분석
특징
제안사
A
제안사
B
제안사
C
제안사
D
웹을 지원하는가
?
(Explorer, Chrome, Fire-
fox)
Yes
Firefox, Chrom Only
Firefox, Chrom Only
Firefox, Chrom Only
웹서버는 어떤 환경인가
?
MS WebServer
Apache Tomcat
Apache Tomcat
Apache Tomcat
클라이언트 개발 언어는
무엇인가
?
HTMS, CSS, JavaScript
jQuery, HTML, CSS
JQuery, HTML, CSS
Sencha Touch, HTML,
CSS
수행을 위해 필요한 서버수
?
MS Window 8대
Linux 8대
Linux/MS Server 각 4대
Linux 8대
팩키지이나 개발인가
?
개발
팩키지
팩키지
+ 개발
개발
수행되는 운영체제는
?
MS Window
MS Window+Linux
MS Window+Linux
MS Window+Linux
시스템 아키텍쳐는
?
3 Tier
3 Tier
3 Tier
3 Tier
사용하는
DBMS는?
MySQL
Oracle
Oracle
Oracle
서버 모듈 개발언어는
?
ASP
JSP
JSP
JSP
서버 프로그램의
프레임워크는
?
MVVC
MVC
MVC
MVC
……………………..
………………..
…………….
고객은 자신의 시스템에서 요구하는 특징을 정리하고 여기에 맞추어 각 제안사의 제안서를 분석하여
,
고객의 요구사항에 얼마나 적합한지에 대하여 정리해야 한다
. 이것을 통하여 기본적으로 부족한 제안을
발견
, 제거할 수 있고, 나중에 선택된 제안사와의 업무 협의를 위한 기초 자료로 활용한다
4.9 제안요청 및 업체 결정 단계
적합성
(가능성) 분석(Feasibility Analysis)의 종류
-
기술 적합성
(Technical Feasibility)
: 솔루션이 기술적으로 적합하고, 가능성이 있는가?
: 관여된 사람들이 제안된 솔루션에 대하여 경험이 충분한가?
-
운영 적합성
(Operational Feasibility)
: 사용자의 요구를 충실히 반영하고 있는가?
: 사용자가 느끼는 운영환경은 쉬운가?
: 환경의 변화에 대하여 어떻게 대처하는가 ?
-
경제적 적합성
(Economic Feasibility)
: 비용 대비 효과가 적절한가?
-
일정 적합성
(Schedule Feasibility)
: 원하는 기간과 일정에 맞출 수 있는가 ?
4.9 제안요청 및 업체 결정 단계
제안사 통합 비교 적합성 분석
적합성
(Feasibility) 범위
비중
제안사
A
제안사
B
제안사
C
Operational(운영) 적합성
-
현재 사용중인
NMS와 연결되어야 한다
-
운영팀에 의한 기능 추가가 가능해야 한다
-
Explorer는 전 버전을 지원해야 한다
35%
-
NMS, 기능추가 불가
-
Explorer 지원
점수
: 60
-
NMS무상연결
-
기능추가 가능
-
Explorer 지원
점수
: 100
-
NMS, 기능추가 불가
-
Explorer 지원
점수
: 60
Technical(기술) 적합성
-
서버는
Linux의 TomCat 환경을 지원한다
-
JSP/Servlet을 사용한다
-
백업툴과 연계되어야 한다
-
HTML 5가 지원하는 그래픽기능을 사용한다
(CANVAS, SVG)
15%
-
TomCat,Linux 사용
-
SVG, CANVAS 사용
-
JSP/Servlet 사용
점수
: 100
-
SVG, CANVAS 사용
-
Explorer 지원
-
Tomcat, Linux 미 지원
점수
: 40
-
SVG, CANVAS 사용
-
Explorer 지원
-
Tomcat, Linux 미 지원
점수
: 40
Economic(경제) 적합성
-
개발비용은
3억 이내
-
연간 유지보수는
5천이내
-
1년간 무상유지 보수 지원
30%
-
2억 제안
-
3천 유지보수
-
2년 무상보증
점수
100
-
5억 제안
-
5천 유지보수
-
1년 유지모수
점수
: 60
-
2억 제안
-
3천 유지보수
-
2년 무상보증
점수
100
Schedule(일정) 적합성
-
2019년 10월 1일 오픈해야 한다
-
오픈 전 한달간 정밀 테스트 기간을 가진다
20%
-
가능
점수
100
-
한달 테스트는 불가
점수
: 50
-
가능
점수
100
4.9 제안요청 및 업체 결정 단계
4.10 정리
