1. 요건 분석

1.1 SD (Service Desk)

SD는 서비스 지역의 언어 문제 때문에 언어권역별로 6명씩을 한 조로 하여 4조 3교대로
24시간 가동하는데, 이를테면 하루를 3등분해서 아침조는 07시~15시, 주간조는 15시~23시, 야간조는 23시~익일 07시의 시간으로 근무를 하고, 한 조는 오프조가 되어 쉬는 형태이다.

1.1.1 언어권역 과 4개조 관련 속성 또는 엔터티

• 기준 정보 엔터티로 판단

• 속성 또는 엔터티 여부
  엔터티로 권역이나 조에 대해서 정의한 후 정의 정보가 변경이 된다면 , 참조성 값들은 전체적으로 바뀌게 된다.

예를 들면, 조별 관련정보 4개조에 대해서 정의를 하고 각각 조별 번호를 할당
이 조 별 정보를 참조하는 근무계획이 있다면 , 처음에는 문제가 없으나, 향후 조별 정보중 아침조의 근무시간이 07시 시작에서 06시로 변경이 된다면 , 변경전에 참조한 근무계획의 정보가 왜곡이 발생

이런 속성의 변경 가능성이 있으면 이런 형식의 속성 정보를 관계형식으로 참조를 하면 문제가 발생하여 관계를 통한 엔터티 속성 참조가 아닌 일반 속성으로 데이터 관리

• 데이터 모델 작성 시 처음에는 기준 엔터티를 참조하는 관계 형태로 정의

기준 정보와 관계를 유지한다면 근무계획이나 근무 관련 엔터티는 시점 정보가 필요한데, 관계를 통한 참조는 맞지가 않음.

속성을 통한 정보 관리 형태가 시점 데이터에는 적합
향후 데이터 모델 설계시 시점 정보인지에 대해서 고민 필요

• 자문

그렇다면 요건에서 향후 변경가능성에 대해서는 알수가 있을까?

시점별로 값이 변경이 되는 정보를 기준 정보로 쓸 수가 있나? 과거 정보까지 관리가 필요하다면 이건 이력 성격의 엔터티이며, 유효시작일자/종료일자 속성도 함께 필요
=> SQL 문 작성시 유효시작일자/종료일자를 항상 참조가 필요, 개발에 번거로움이 발생

어떤 정보를 부모/자식, 상위/하위 관계에서만 참조 관계를 맺어야 하나? 기준 정보는 그냥 코드성으로 이해를 해야 할까?

1.1.2 근무 계획

이와 같은 근무시간대 구분에 따라 하나의 근무조가 일정 기간 동안 하나의 근무시간대롤 반복적으로 근무하다가 기한이 지나면 다른 근무시간대로 이동하여 다시 일정 기간 동안 근무를 하고, 오프조 순서가 되면 일정 기간 동안 휴식을 취하게 된다

• 교대근무계획 : 4개조가 일정기간동안 교대로 근무시간을 변경, 조 단위로 일정기간(교대시작일자, 교대종료일자)을 근무, 근무 형태는 4개 Type(아침조,주간조,야근조,오프조)

1.2.3 직원의 역할

SD 담당자는 모두 계약직으로 채용하여 운영하고 있고, SD를 총괄하는 관리자와 각 언어권역별 관리자는 별도로 우리 회사의 정규직 직원이 전담으로 배치된다. SD 관리자로 근무하는 정규직 직원들은 2~3년 주기로 교체하고 있다

• SD 관련 직원들의 역할이 SD 담당자, SD 총괄관리자, SD 언어권역별관리자로 구분
• 이들은 SD 담당자는 계약직 Type, SD 총괄과 권역별 관리자는 정직원 Type
• 직원 엔터티의 고용형태 Type 언급
• SD 역할이 일정기간(역할시작일자,역할종료일자) 동안만 유지

1.2.4 근무 계획과 실제 근무 내역 및 급여

SD 담당자의 근무는 한 달씩 근무 계획을 미리 수립하여 매월 20일까지 익월의 근무계획을 각 언어권역별 관리자와 총괄 관리자의 승인을 거쳐 시행하도록 하고 있으며, SD 담당자들은 각자의 근무조 근무 계획에 따라 근무를 하고, 근무한 시간에 따라 시급을 계산하여 매월 정해진 급여일에 한 달 치 급여를 지급받는다

• 근무계획 엔터티의 속성중 승인자(언어권역별관리자,총괄관리자)를 언급, 승인 관련 승인자와 승인일시 속성이 필요

익월의 근무계획을 각 언어권역별 관리자와 총괄 관리자의 승인을 거쳐 시행

-근무계획 수립 주기는 1개월, 즉 근무계획년월 속성이 언급

SD 담당자의 근무는 한 달씩 근무 계획을 미리 수립

• 근무 계획과 실 근무는 상이하다고 언급

SD 담당자들은 각자의 근무조 근무 계획에 따라 근무를 하고

• 월별 총 근무 시간 속성이 언급

근무한 시간에 따라 시급을 계산

1.2.5 근무 시간별 시급할증율

이를 위한 시간당 근로 임금은 SD 담당자별로 채용 시 경력에 따라 차등적으로 정하고 있으며, 근무 시간이 자정부터 익일 오전 6시에 해당하는 경우에는 계약된 시급에 대해 시간당 1.5배로 계산하여 지급하고, 근무일이 일요일이거나 공휴일인 경우에도 시급의 1.5배를 적용하고 있다. 또한 정해진 시간 외의 연장근무를 한 시간에 대해서도 1.5배를 적용한다

• SD 담당자의 시급은 채용시 최초 결정, 계약직 직원 엔터티에 시급 속성 언급

  시간당 근로 임금은 SD 담당자별로 채용 시 경력에 따라 차등적

• 근무조의 근무 시간과 다른 실제 근무시간별 시급 할증율 언급

  근무 시간이 자정부터 익일 오전 6시에 해당하는 경우에는 계약된 시급에 대해 시간당 1.5배로 계산하여 지급하고, 근무일이 일요일이거나 공휴일인 경우에도 시급의 1.5배를 적용하고 있다. 또한 정해진 시간 외의 연장근무를 한 시간에 대해서도 1.5배를 적용한다

근무 시간의 급여 계산에서 일반 근무 시간과 할증이 적용되는 근무시간을 언급

• 조별 근무계획과 실제 근무가 상이할 수 있음을 언급

정해진 시간 외의 연장근무를 한 시간에 대해서도

• 근무 일자(요일) 속성 언급

근무일이 일요일이거나 공휴일인 경우에도 시급의 1.5배를 적용

근무일이 일요일 인지 공휴일인지 구분이 필요,근무일자 속성이 있으면 공휴일 여부는 추출속성으로 간주가능하며, 물리 모델링에서는 추가 가능

• (종합) 근무 시간별 시급할증을 적용한 급여 계산을 위해서는 근무계획과는 별도의 (실)근무 엔터티가 필요하며,속성으로는 근무자, 근무일자, 근무구분,근무시간(근무시작시간,근무종료시간) 필요

이 정보를 바탕으로 급여에서 월별 , 근무 시간 Type별 총 근무 시간, 각각의 근무 Type별 급여 액수, 마지막 총급여액수가 결정

1.2.6 시급 할증율 이력

SD 담당자의 시급할증율은 매년 초에 SD 담당자 대표와 단체임금교섭을 통해 조정하며, 결정된 할증율은 당해년도의 1월 1일에 시작되는 근무조부터 소급적용한다. 할증율의 변동사항은 이력으로
관리해서 SD 담당자의 급여계산에 반영하고, 간혹 과거 임의의 시점에 지급된 급여의 검증
이나 정정 등에 사용하기도 한다.

• SD 담당자의 년도별 시급 할증율 정보를 관리
• 관리 속성으로는 계약직 사원번호, 해당년도, 시급 할증율, 교섭한 SD 담당자 대표사원번호

1.2.7 급여 계산 담당자

SD 담당자들의 급여 계산은 노무관리를 전담하는 정규직직원이 담당하고 있으며, 이 외에도 경영관리나 기획관리를 담당하고 있는 많은 사무직군의정규직 직원들이 있다

• 급여 엔터티에 급여계산노무담당자 속성을 추가

SD 담당자들의 급여 계산은 노무관리를 전담하는 정규직직원

• 기타 다양한 담당자 Type이 존재

이 외에도 경영관리나 기획관리를 담당

1.3 SR(Sevice Request)

1.3.1 SR 엔터티 소개

고객사의 사용자들은 전화나 e메일, 또는 서비스요청 화면 입력을 통해 도움을 요청할 수
있으며, SD 담당자가 이를 접수하고 검토하여 이미 해결방안을 갖고 있는 문제인 경우는 곧
바로 해결방안을 제시하고, 익일에 다시 요청자에게 전화하여 해결여부와 서비스만족도를
확인한다. 이러한 모든 과정은 업무지원시스템에 기록하고 있으며, 향후 이를 이용하여 사
용자요구 발생의 경향을 분석하고 고객사 시스템의 부족한 부분을 찾아내어 사전에 개선함
으로써 최상의 서비스를 제공하려 한다.

• SR 신청 경로 : 전화나 e메일, 또는 서비스요청 화면 입력

1.3.2 SR 구분 및 구분별 속성

사용자 요구(Service Requests, SR)는 상담, 변경요청, 장애신고, 기타로 구분하며, 변경요청인 경우는 요청내용과 처리희망일을, 장애신고인 경우는 장애가 발생한 시점과 장애의 내
용, 장애 구분 등을 알아야 한다. 장애는 크게 하드웨어, 네트워크, 소프트웨어 분야로 나누
고, 다시 하드웨어는 서버와 PC, 네트워크장비로 세분하며, 소프트웨어는 시스템 소프트웨어
와 응용프로그램으로 세분하고 있다. 네트워크의 경우는 신고자가 상세하게 알 수 없는 경
우가 대부분이기 때문에 신고 시에는 단순하게 네트워크 분야로 체크만 하고, 전문인력이
장애조치 시 확인하여 인바운드인지 아웃바운드인지 여부의 세분류를 입력한다.

• SR 최상위 구분 : 상담, 변경요청, 장애신고, 기타

• 변경요청 Subtype의 속성 : 요청내용과 처리희망일

• 장애신고 Subtype의 속성: 장애가 발생한 시점과 장애의 내용, 장애 구분

• 장애구분 : 하드웨어, 네트워크, 소프트웨어

• 하드웨어 SubType : 서버와 PC, 네트워크장비

• 소프트웨어 SubType : 시스템 소프트웨어, 응용프로그램

• 네트워크 SubType : 인바운드 ,아웃바운드

1.3.3. 변경요청 SR 관련 장애 신고 SR

장애는 어떠한 경우라도 고객사 업무 수행에 지장을 주게 되기 때문에 최우선적으로 조치하며, 별도로 시간을 갖고 근본적인 원인을 제거하기 위한 조치가 필요하다고 판단되면 장애 조치를
수행하는 전문 인력이 별도의 변경요청 SR로 해당 내용을 등록하여 처리한다. 이때 변경요
청 SR을 처리하는 전문 인력이 상세한 장애 조치 내용을 파악할 수 있도록 관련된 장애신
고 SR과의 연결고리를 갖고 있어야 있다.

• 변경요청 SR 관련 장애신고 SR과 선택적 관계

• SR 우선순위 등급(선택) : SR의 처리 요청 우선 순위(최우선,우선, 여유 등)

1.3.4 Known Error

접수된 SR은 접수부터 처리가 완료되어 종결되는 과정이 모두 일목요연하게 관리되어야
하며, 이 과정에서 SR이 Known Error에 해당하는 경우는 SD 담당자가 업무지원시스템에서
해당 내용을 검색하여 곧바로 일차적인 조치를 한다.

-Known Error는 직접적인 요건 표현보다는 IT 정보시스템를 이해하는 관련자만이 강력한 정보시스템 검색기능으로 Known Error 여부를 판단할 수 있다는 우회적인 표현

• 여기에 관련 SR 들을 체계적이며, 연결성을 가지고 정보를 관리하여 이미 발생한 SR의 처리 결과를 신속하게 확인하고, 처리 완료인 경우 Known Error로 판단하여 고객에게 1차적으로 관련 사실을 알리는 조치가 가능

1.3.5 영향 평가

SD 담당자의 일차적인 조치로 해결되지 않거나 Known Error에 해당하지 않으면, 다음 단계로 변경관리 담당자가 SR처리를 위한 영향평가를 하게 되는데, 한 번의 영향평가로 부족한 경우는 평가자를 지목하여 몇 차례 더 영향평가를 할 수 있다.

• 다단계 영향평가와 여러명의 다단계 영향 평가자, 다단계 평가인 경우 속성으로 관련 SR번호,영향평가 일시, 영향 평가자, 영향 평가 내용

• 담당자 Type 중 변경관리담당자 언급

1.3.6 SR 처리 계획 과 처리

영향평가가 완료되면 변경관리 담당자는 이를 바탕으로 해당 SR의처리 담당자를 지정하게 되는데, 처리 대상이 H/W 분야인지 N/W 분야인지, 혹은 시스템 소프트웨어나 응용프로그램 분야인지에 따라 해당하는 CI 보전담당자나 응용프로그램 유지보수담당자가 처리 담당자로 선정된다. CI 보전담당자는 H/W나 N/W, 시스템소프트웨어의 유지관리를 담당하는 전문 인력을 의미하고, 응용프로그램 유지보수 담당자는 해당 고객사의 정보시스템을 구성하고 있는 응용프로그램의 변경이나 오류복구, 소규모 개발 등을 담당하고 있는 전문 인력을 의미한다. 변경관리 담당자가 선정한 SR 처리 담당자는 자신에게 할당된 SR의 변경 대상 및 요구사항, 제약조건 등을 확인하고, 일정 및 처리에 필요한 소요 자재나 장비, 투입인력 등을 포함한 처리계획을 수립⋅기록하고, 처리가 완료되면 각 계획내용의 처리완료일을 다시 기록한다.

• SR 처리 구분 : H/W , N/W , 시스템 소프트웨어, 응용프로그램

  처리 대상이 H/W 분야인지 N/W 분야인지, 혹은 시스템 소프트웨어나 응용프로그램 분야

• 담당자 Type 중 SR 처리 담당자 언급 (CI 보전담당자, 응용프로그램 유지보수담당자)

  변경관리 담당자는 이를 바탕으로 해당 SR의 처리담당자를 지정

CI 보전담당자나 응용프로그램 유지보수담당자가 처리 담당자로 선정

• CI 보전담당자 처리 분야 : H/W, N/W,시스템소프트웨어

  CI 보전담당자는 H/W나 N/W, 시스템소프트웨어의 유지관리를 담당

• 응용프로그램 유지보수 담당자 처리 분야 :응용프로그램의 변경, 오류복구, 소규모 개발

  응용프로그램 유지보수 담당자는 해당 고객사의 정보시스템을 구성하고 있는 응용프로그램의 변경이나 오류복구, 소규모 개발 등을 담당

• SR 처리 계획 엔터티는 각 SR 처리 담당자의 할당된 변경대상에 대해서 전반적인 일정(처리시작일자, 처리종료예정일자), 소요자재, 투입인력, 그리고 변경 관리 담당자,처리완료일자 속성을 포함

  일정 및 처리에 필요한 소요 자재나 장비, 투입인력 등을 포함한 처리계획을 수립⋅기록하고, 처리가 완료되면 각 계획내용의 처리완료일을 다시 기록한다.

• SR 처리 엔터티는 관련 처리 계획, 변경대상, 요구사항, 제약조건, 처리시작일자,처리완료일자 속성을 포함

  SR 처리 담당자는 자신에게 할당된 SR의 변경 대상(CI) 및 요구사항, 제약조건 등을 확인

1.3.7 고객의 SR 요청 처리 결과 및 서비스 만족도

처리가 완료된 SR은 SD 담당자가 요청자에게 전화나 메일로 안내하거나 포털사이트의 고객사별 SR 처리 화면에서 요청자가 직접 결과를 확인할수 있다. 처리 완료된 SR은 익일에 SD 담당자가 요청자에게 연락하여 결과를 확인하고 서비스만족도를 점수로 리턴받아 기록한다. SD 담당자나 변경관리 담당자는 업무지원시스템을통해 SR의 처리과정을 일목요연하게 확인하고, 예정된 일정대로 처리가 이루어지도록 관리한다.

• SR 고객의 속성 중 메일, 전화번호 , 포탈 ID/PW 언급

  SD 담당자가 요청자에게 전화나 메일로 안내하거나 포털사이트의 고객사별 SR 처리 화면에서 요청자가 직접 결과를 확인할수 있다.

• SR 속성 중 서비스만족도 언급

  처리 완료된 SR은 익일에 SD 담당자가 요청자에게 연락하여 결과를 확인하고 서비스만족도를 점수로 리턴받아 기록

1.4 CI(Configuration Item)

1.4.1 CI 구분

SR이 발생하는 대상은 고객사 정보시스템 구성 자원(Configuration Item, CI)으로, 서버, N/W, 시스템 소프트웨어, 응용프로그램, 데이터베이스로 구분하며,

• CI 구분 : 서버, N/W, 시스템 소프트웨어, 응용프로그램, 데이터베이스

1.4.2 CI 변경이력

접수된 SR을 처리하는 과정에서 복수의 해당 CI가 변경⋅폐기되거나 개선되기도 하고, 또는 새롭게 추가되기도 하는 등의 변동사항이 발생하기 때문에, 그 변동 내용과 변동을 유발한 근거에 해당하는 SR이 있으면 관련 SR번호까지 포함하여 CI의 변경이력으로 관리한다.

• SR 과 CI와의 관계가 1:M

  접수된 SR을 처리하는 과정에서 복수의 해당 CI

• CI 변경 사유 구분 : 신규, 변경, 개선, 폐기

  해당 CI가 변경⋅폐기되거나 개선되기도 하고, 또는 새롭게 추가되기도 하는 등의 변동사항이 발생

• CI 속성중 관련 변경을 유발한 SR 번호 포함(선택적 관계)

  변동 내용과 변동을 유발한 근거에 해당하는 SR이 있으면 관련 SR번호까지 포함하여 CI의 변경이력으로 관리

1.4.3 점검활동과 CI 변경이력

CI의 변경은 사용자요구에의해서만 발생하지 않고 때로는 자체적인 점검 활동에 의해서도 발생한다. 점검활동은 일상적인 모니터링과 정기 점검으로 구분되는데, 예를 들면, 시스템관리자가 수시로 응용시스템의 성능모니터링을 하는 것이 일상적인 모니터링이라 할 수 있고, 정기 점검은 별도의 대상CI와 점검을 수행할 담당자, 점검일정 및 점검 항목⋅내용을 사전에 정의하여 승인을 거쳐
시행하는 것으로, 서버의 작동 상태 및 외관, 서버와 서버실 주변 환경 등을 점검하거나, 서버, 응용시스템, 데이터베이스 등에 대한 보안 점검, 노후 부품의 교체나 업그레이드, 파라미터 점검 등을 예로 들 수 있다. 때로는 사용자들의 PC에 대한 점검이 포함되기도 한다. 일상적인 모니터링은 특정 CI를 대상으로 수시로 수행되지만, 정기 점검의 경우는 점검 시마다 다수의 CI를 대상으로 선정하고 수행되기 때문에, 대상으로 선정된 CI들의 특성에 따
른 다수의 점검 항목과 점검 내용이 사전에 계획되고 내부 승인을 거쳐 시행하게 된다. 이
와 같은 정기 점검은 연간 3~4 회 정도 실시한다.

• CI 변경 근거 중 하나인 점검활동 : 변경 근거가 SR과 점검활동

  CI의 변경은 사용자요구에의해서만 발생하지 않고 때로는 자체적인 점검 활동에 의해서도 발생한다

• 점검 활동 구분 : 모니터링과 정기 점검

  점검활동은 일상적인 모니터링과 정기 점검으로 구분

• 일상적인 모니터링 SubType의 속성 : 다음 항목에 설명

• 정기점검(계획)과 점검대상 CI와의 관계는 1:M

  정기 점검의 경우는 점검 시마다 다수의 CI를 대상으로 선정하고 수행

• 점검대상 CI와 점검 항목과 관계는 1:M

  대상으로 선정된 CI들의 특성에 따른 다수의 점검 항목과 점검 내용

• 정기점검(계획) SubType의 속성 : 점검번호(인조식별자),점검수행년도, 점검회차, 점검승인자,점검일정(점검시작일자/예상종료일자),점검완료일자

  이와 같은 정기 점검은 연간 3~4 회 정도 실시한다.

정기 점검은 별도의 대상CI와 점검을 수행할 담당자, 점검일정 및 점검 항목⋅내용을 사전에 정의하여 승인

• 정기점검대상 엔터티의 속성 : 정기점검번호,점검대상CI번호, 점검수행자,점검일정(점검시작일자/종료일자) ,점검완료일자

  정기 점검은 별도의 대상CI와 점검을 수행할 담당자, 점검일정

• 정기점검항목 엔터티의 속성 : 정기점검번호,점검대상CI번호,점검항목구분,점검 항목

  정기 점검은 별도의 대상CI와 점검을 수행할 담당자, 점검일정 및 점검 항목⋅내용

• 점검항목구분 : 서버의 작동 상태 , 외관, 서버와 서버실 주변 환경,서버, 응용시스템, 데이터베이스 등에 대한 보안 점검,노후 부품의 교체나 업그레이드, 파라미터 점검, 사용자 PC

  서버의 작동 상태 및 외관, 서버와 서버실 주변 환경 등을 점검하거나, 서버, 응용시스템, 데이터베이스 등에 대한 보안 점검, 노후 부품의 교체나 업그레이드, 파라미터 점검 등을 예로 들 수 있다. 때로는 사용자들의 PC에 대한 점검이 포함되기도 한다.

1.4.4 일상 모니터링 점검활동 SubType

일상적인 모니터링을 수행하고 나면 담당자는 그 결과를 업무지원시스템에 기록한다. 언제, 누가, 어떤 CI에 대해 어떤 내용을 모니터링 했고, 그 결과가 어땠는지 등을 일지 형식으로 기록한다. 일상적인 모니터링에서 성능문제가 발견되는 경우에는 그러한 문제의 원인이 되는 서버나 응용프로그램을 추적하여 자체적으로 SR로 등록한 후 자체 인력이나 외부전문가를 투입하여 개선

• 일상 모니터링 SubType의 속성 : 점검활동번호(인조식별자),점검일자,점검대상CI,점검수행자,점검항목,점검결과)

?일상모니터링과 정기점검의 점검항목은 상이한가?

1.4.5 CI 변경이력 과 SR 처리(조치사항)

정기 점검을 통해 노후화된 부품을 교체하거나 패치가 필요한 경우는 SR과 무관하게 이루어지기도 한다. 예컨대 어떤 고객사에서 사용하고 있는 오라클 DBMS에 대해 보안 패치를 적용하고자 하는 경우는 정기 점검 계획에 따라 계획된 일정에 DBMS 패치 작업을 수행하고, 이 내용은 CI 변경이력에 기록하게 된다. 이와 같이 고객사의 CI에 발생하는 변동사항을 관리하는 것을 형상관리라 하는데, 시스템관리자는 고객사 CI에 대한 형상관리를 전담한다. 우리는 포털사이트를 통해서 고객 측에서 직접 CI 목록과 변경 내역들을 확인할 수 있도록 하며, 변경 내역과 관련된 SR이 있는 경우에는 해당SR의 내용과 조치사항들까지 확인할 수 있도록 한다. SR의 조치사항에는 어떤 CI가 어떻게조치⋅변경되었는지에 대한 상세 내용이 포함되며, 이 중에는 데이터를 저장하는 테이블이
나 인덱스와 같은 DB Object에 대한 변경 내용도 포함된다

• CI 변경 이력 엔터티는 CI 변경 시스템 관리자 속성을 포함

  이 내용은 CI 변경이력에 기록하게 된다. 이와 같이 고객사의 CI에 발생하는 변동사항을 관리하는 것을 형상관리라 하는데, 시스템관리자는 고객사 CI에 대한 형상관리를 전담한다.

• 위에서 언급한 CI 변경이력 엔터티에 변경원인근거구분 중 점검활동이면 점검활동번호)속성이 포함

  정기 점검을 통해 노후화된 부품을 교체하거나 패치가 필요한 경우는 SR과 무관하게 이루어지기도 한다.예컨대 어떤 고객사에서 사용하고 있는 오라클 DBMS에 대해 보안 패치를 적용하고자 하는 경우는 정기 점검 계획에 따라 계획된 일정에 DBMS 패치 작업을 수행하고, 이 내용은 CI 변경이력에 기록하게 된다.

• SR의 조치사항 엔터티와 CI의 변경이력 엔터티와의 관계 설정

  변경 내역과 관련된 SR이 있는 경우에는 해당 SR의 내용과 조치사항들까지 확인할 수 있도록 한다.

• SR 조치사항 엔터티의 속성중 상세내용 속성이 포함

  SR의 조치사항에는 어떤 CI가 어떻게 조치⋅변경되었는지에 대한 상세 내용이 포함되며, 이 중에는 데이터를 저장하는 테이블이나 인덱스와 같은 DB Object에 대한 변경 내용도 포함된다

1.4.6 CI 폐기계획

형상관리를 하고 있는 CI 중 폐기할 대상이 발생하면 시스템관리자는 폐기계획을 수립한
다. 폐기계획은 폐기사유와 함께 해당 CI의 특성을 고려하여 업무영향, 환경영향, 안전, 보
안 등의 분야에 대한 검토 결과를 각 분야의 검토자와 함께 기록하고, 폐기예정일과 폐기장
소, 폐기방법, 폐기수행자, 폐기확인방법, 폐기공지계획 등을 기입하여 폐기계획을 수립하며, 우리 회사 내부 및 고객사 승인을 거쳐 시행한다. 승인 단계에 따른 각 단계의 승인자 및
승인일시는 중요한 관리 사항이며, 승인 단계는 고객사와의 협의나 우리 회사 내부 규정 등
에 따라 변경될 수 있다. 폐기 계획이 승인되고, 이에 따라 폐기 처리가 이루어지고 나면
해당 CI를 목록에서 삭제하지 않고 관련 내용을 해당 CI의 변경 내용으로 기록하여 관리하
며, 해당하는 폐기 계획과 그 승인 내역을 확인할 수 있도록 폐기계획번호를 함께 관리한
다.

• 폐기계획 엔터티는 담당 시스템 관리자 속성을 포함

  형상관리를 하고 있는 CI 중 폐기할 대상이 발생하면 시스템관리자는 폐기계획을 수립한다.

• 폐기계획 엔터티는 폐기계획번호(인조식별자), 대상 CI번호, 폐기사유,폐기예정일, 폐기장소,폐기방법,폐기수행자, 폐기확인방법, 폐기공지계획 속성을 포함

  해당하는 폐기 계획과 그 승인 내역을 확인할 수 있도록 폐기계획번호를 함께 관리

폐기예정일과 폐기장소, 폐기방법, 폐기수행자, 폐기확인방법, 폐기공지계획 등을 기입하여 폐기계획을 수립

• 폐기계획승인 엔터티는 폐기계획번호,승인단계,서비스제공업체승인자,서비스제공업체승인일시, ,고객사승인일시자,고객사승인일시속성을 포함

  승인 단계에 따른 각 단계의 승인자 및 승인일시는 중요한 관리 사항이며, 승인 단계는 고객사와의 협의나 우리 회사 내부 규정 등에 따라 변경될 수 있다.

• 폐기검토 엔터티는 폐기계획번호,검토분야,검토자,검토결과 속성을 포함

  해당 CI의 특성을 고려하여 업무영향, 환경영향, 안전, 보안 등의 분야에 대한 검토 결과를 각 분야의 검토자와 함께 기록

• CI 엔터티의 속성에 폐기일자, 폐기계획번호 속성을 포함

  이에 따라 폐기 처리가 이루어지고 나면 해당 CI를 목록에서 삭제하지 않고 관련 내용을 해당 CI의 변경 내용으로 기록하여 관리하며, 해당하는 폐기 계획과 그 승인 내역을 확인할 수 있도록 폐기계획번호를 함께 관리한다.

1.5 직원

SR 요청자는 대체로 고객사의 사용자들이지만 때로는 우리 회사의 직원들이 될 수도 있
으며, 정규직원은 물론이고, 계약직 직원이나 임시직 직원들도 불편한 사항이나 장애신고
등을 할 수 있다. SR 처리에 관련된 변경관리 담당자나 각 분야의 처리 담당자는 대부분 우
리 회사의 기술직군에 속하는 정규직 직원들이지만 때로는 CI별로 외부의 전문가가 SR 처
리에 투입되기도 한다. SR 처리에 투입될 수 있는 외부 전문가는 기술 분야별로 분류하여
별도의 POOL로 관리하고 있으며, SR 처리 담당자가 외부 전문가의 필요성을 판단하여 투입
여부를 결정하게 되고, 이렇게 투입된 외부 전문가들에 대해서는 사전에 각 인원별로 협의
하여 결정된 시간당 금액을 토대로 투입된 시간만큼 계산하여 지급하기 때문에, 그들의 투
입 시간과 활동 내용이 정확하게 관리되어야 한다. 우리의 업무지원시스템과 관련되는 모든
인원들에 대해서 항상 긴급연락이 가능한 연락체계를 갖추고 있어야 하기 때문에, 그들의
정확한 연락전화번호(유선, 무선)와 메일주소, 거주지 주소 등은 필수적으로 관리해야 하고, 외부 전문가 중 특정 업체에 소속되어 있는 경우에는 소속회사까지 관리해야 한다. 외부 전
문가는 때때로 기업이 될 수도 있는데, 예를 들면 어떤 회사는 특정 분야의 전문성이 매우
높고, 그 회사에 소속된 인력 중 아무나 투입해도 SR 처리에 전혀 문제가 없기 때문에, 그 회사를 외부 전문가로 등록하고 필요에 따라 투입을 요청하기도 한다.

• SR 요청 가능자는 고객사의 사용자, 내부회사직원(정규직,계약직,임시직) : SR 요청가능자를 직원 엔터터외 관계를 하는 것 보다 정보시스템 운영이나 개발 또는 처리자들의 역할을 맡은 직원이 요청하는 게 맞을 것 같다고 판단

SR 요청자는 대체로 고객사의 사용자들이지만 때로는 우리 회사의 직원들이 될 수도 있
으며, 정규직원은 물론이고, 계약직 직원이나 임시직 직원들도 불편한 사항이나 장애신고
등을 할 수 있다

• SR 처리 가능자는 내부회사정직원과 외부전문가가 가능 : SR처리 엔터티에 SR처리자구분 속성을 추가하여 외부전문가인 경우 관련 투입내역과 관계

  SR 처리에 관련된 변경관리 담당자나 각 분야의 처리 담당자는 대부분 우리 회사의 기술직군에 속하는 정규직 직원들이지만 때로는 CI별로 외부의 전문가가 SR 처리에 투입되기도 한다.

• SR 관련 이해관계자는 고객사 사용자, 내부회사직원, 외부전문가로 가능

• SR 처리 외부 전문가도 다른 직원처럼 동일하게 직원 엔터티로 관리, 추가로 소속회사 속성도 선택적으로 포함

  SR 처리에 투입될 수 있는 외부 전문가는 기술 분야별로 분류하여 별도의 POOL로 관리하고 있으며

우리의 업무지원시스템과 관련되는 모든 인원들에 대해서 항상 긴급연락이 가능한 연락체계를 갖추고 있어야 하기 때문에, 그들의 정확한 연락전화번호(유선, 무선)와 메일주소, 거주지 주소 등은 필수적으로 관리해야 하고

• SR 처리별 외부전문가투입내역 엔터티 : SR 처리별로 투입된 외부 전문가의 협의된 시급 과 투입 시간,활동 내용

  SR 처리 담당자가 외부 전문가의 필요성을 판단하여 투입여부를 결정하게 되고, 이렇게 투입된 외부 전문가들에 대해서는 사전에 각 인원별로 협의하여 결정된 시간당 금액을 토대로 투입된 시간만큼 계산하여 지급하기 때문에, 그들의 투입 시간과 활동 내용이 정확하게 관리되어야 한다.

?전반적인 SR 처리 과정 : SR 신청 -> SR 접수 -> 1차 응대 -> SR 영향평가 -> SR 조치 -> SR 관련 CI 변경 -> SR 처리 완료 -> 서비스 만족도

• 이해관계자 엔터티의 소속회사(외부법인회사) 속성

이해관계자 엔터티의 SubType

1차 이해관계자구분(법인,개인)

법인 ->
2차구분(법인구분) 고객사, 서비스운영회사,외부전문가회사

개인 ->
2차구분(개인구분) 고객사 사용자, 서비스 운영회사의 직원(정직원, 계약직, 임시직),외부전문가

3차구분은 서비스 운영회사의 고용형태 : 정직원, 계약직, 임시직

외부 전문가 중 특정 업체에 소속되어 있는 경우에는 소속회사까지 관리해야 한다. 외부 전
문가는 때때로 기업이 될 수도 있는데, 예를 들면 어떤 회사는 특정 분야의 전문성이 매우
높고, 그 회사에 소속된 인력 중 아무나 투입해도 SR 처리에 전혀 문제가 없기 때문에, 그 회사를 외부 전문가로 등록하고 필요에 따라 투입을 요청하기도 한다.

1.6 포탈사이트

고객사의 사용자들은 우리 회사의 포털사이트에서 서비스 요청(SR)을 할 수 있고, SR 처리 결과도 확인할 수 있으며, 요청한 SR의 진행 상태와 CI 목록, CI 변경내역 등을 확인할 수도 있다. 또한 고객사별 게시판을 통해 공지사항을 확인하거나 문의사항을 등록하고 답변을 얻을 수도 있다. 그 외에 고객사별로 FAQ(Frequently Asked Question) 게시판도 운영하는데, 접수 및 처리된 SR 내용을 정기적으로 재검토 하여 자주 발생하는 SR들을 분류하고 FAQ로 정리 및 게재하여 고객사 사용자들이 SR을 요청하기 전에 미리 확인하여 스스로 해결이 가능하도록 하며, 등록된 FAQ는 미리 정해진 분류에 따라 검색하거나 원하는 특정 단어를 입력하여 빠르고 편리하게 검색할 수 있다.

1.6.1 포탈사이트 접속 관리 : 이해관계자번호, 접속ID, 패스워드,접속회사구분(고객사 사용자, 서비스운영회사 직원)

우리는 원활한 서비스 제공을 위해서 포털사이트를 운영하고 있다. 포털사이트의 이용은
고객사 사용자와 우리 회사 직원들에 국한되며, 사용자 가입 후 로그인 과정을 거쳐 이용할
수 있다

1.6.2 고객사별 게시판

• 고객사별게시판 엔터티 속성으로는 고객사번호, 게시판구분(공지사항, 문의사항, FAQ), 게시판글번호,제목, 내용, 문의사항 SubType인 경우 답변 시 원게시판글번호, 작성일시, 작성자

  고객사별 게시판을 통해 공지사항을 확인하거나 문의사항을 등록하고 답변을 얻을 수도 있다. 그 외에 고객사별로 FAQ(Frequently Asked Question) 게시판도 운영하는데

1.6.3 게시판 검색 기능

• FAQ 게시판인 경우 관련 SR를 분류할수 있는 분류코드를 포함, 분류코드는 SR 요청시의 분류코를 준수

  접수 및 처리된 SR 내용을 정기적으로 재검토 하여 자주 발생하는 SR들을 분류

1.6.4 FAQ게시판검색어

• SR분류코드 , 검색어 , 해당FAQ게시판글번호,등록일시

  등록된 FAQ는 미리 정해진 분류에 따라 검색하거나 원하는 특정 단어를 입력하여 빠르고 편리하게 검색할 수 있다.

2. 본격적인 요건 분석 이전 데이터 모델

3. 본격적인 요건 분석 이후 데이터 모델