5/1 멘토링

[orlzlL]

프로젝트 관리 시스템 기능별 세부 요구사항

회원가입 및 관리

• 시스템 내 회원가입은 하지 않음.
• 회원은 관리자에 의해 회원 등록 페이지에서 추가됨.
• 외부 기업의 직원(개발자 포함)이 일정 확인 및 협업을 위해 등록됨.
• 회원가입보다 정보를 받아서 관리자가 등록하는 방식이 선호됨.
• 외부 공유자를 위해 soft delete를 통해 탈퇴 처리할 수 있음.
• ERP 시스템은 권한 처리가 중요하므로, 권한이 세분화되어 있어야 함.

일정 관리

• 일정 연장 요청 기능은 시스템에서 필요하지 않으며, 면담을 통한 요청이 선호됨.
• 일정 수정 시 변경 사유를 필수로 입력하도록 하여 이력 기록이 가능해야 함.
• 일정 관리에서 댓글 기능은 불필요함.

프로젝트 관리

• 대부분의 PM은 한 명당 하나의 프로젝트를 관리하며, 프로젝트끼리 비교는 불필요.
• 프로젝트 진척률은 프로젝트별로 따로 보여주고, 합쳐서 전체 진행률을 표시함.
• 프로젝트 템플릿 기능 대신, 이전에 했던 프로젝트 항목을 복사하여 재사용 가능하도록 함.

권한 관리

• 권한은 세분화되어야 하며, PM은 모든 프로젝트를 볼 수 있고, 개발자는 자신의 프로젝트만 볼 수 있도록 제한.
• 일정 관리에서 PL은 자신의 섹션만 접근할 수 있어야 함.
• 개발자는 해당 프로젝트에서 진행률과 상태만 수정할 수 있어야 함.

Task 페이지

• Task 페이지에는 오늘의 할 일 뿐만 아니라 금주, 차주 할 일 목록이 표시되어야 함.
• 주 단위로 표시하는 것이 선호됨.
• 보고서 작성 기능은 불필요함.

알림 기능

• 알림은 페이지 형태가 아니라 모달로 처리하는 것이 좋음.
• 알림이 너무 많이 가지 않도록 조절해야 함.
• 알림 기록은 1주일치 또는 1달치로 관리하며, 최근 일정에 대한 정보를 쉽게 확인할 수 있도록 함.
• PM에게는 프로젝트 예상 진행률이 95% 미만으로 떨어지면 이메일이 전송됨.
• 개발자에게는 완료되지 않은 작업에 대한 통합 알림을 보내는 것이 좋음.

프로필 및 조직 관리

• 프로필 기능은 불필요하며, 간단한 연락처 정보만 있으면 충분함.
• 조직도는 트리 구조로 관리하며, 프로젝트 생성 시 해당 팀과 연결되는 구조가 되어야 함.
• 팀장이 자신의 팀 프로젝트만 볼 수 있도록 권한 관리가 필요하며, 조직도는 사원번호를 기준으로 조인할 수 있어야 함.

공통 코드 및 DB 관리

• 공통 코드는 여러 곳에서 사용되므로, ERD에서는 외래키로 연결하지 않음. 실제 DB에서는 연결함.
• 공통 코드에는 재직 상태, 언어 등 다양한 정보를 포함할 수 있음.
• 모든 테이블에는 생성자, 생성 날짜, 수정자, 수정 날짜를 관리해야 함.
• DB 속성명은 컬럼명만 보고도 어떤 데이터인지 알 수 있도록 명명해야 함.

대시보드

• 대시보드는 종합 대시보드와 개별(상세) 대시보드로 나누어지며, 테이블 구성도 이에 맞춰져야 함.
• 가능하다면 대시보드의 위젯 관리 기능은 차트 부분이 늘어나거나 줄어들 때도 이쁘게 정리되도록 해야 함.
• 고정된 대시보드를 제공하도록 함.
• 위젯의 추가 및 삭제 기능이 가능하도록 대시보드 관리자 화면이 구성되어야 함.

기타 기능

• 일정에 해당하는 요구사항을 팝업으로 세부 정보를 확인할 수 있음.
• 공수 계산 시 공휴일을 제외한 기간을 고려해야 함.

[ms1011]

5/1 멘토링

피드백

• 외부 직원도 봐야할 경우 어떻게 해야할건지?
  • ERP에는 가입할 수 없으니 이 사이트를 위해 가입을 하는 기능은 있어야 한다
    1. 관리자가 회원가입 시켜주는 경우 (선호)
    2. 직접 회원가입 하는 경우
• 외부공유자에게 공유하는 기능을 만들어야 하는지?
  • 관리자가 가입을 시키는게 좋다
• 가입한 외부 공유자가 더이상 같이 일을 하지 않은 경우는 어떻게 하는지?
  • soft delete를 하여 탈퇴 처리를 한다
• 외부공유자 or 개발자는 데이터 수정 권한을 (진행률or진행상태)만 수정 가능하게 한다
  • 일정 추가 같은 경우는 PL에게 문의를 하고 추가는 PM이나 PL이 추가한다
• 일정 연장 요청은 대부분의 경우는 면담으로 진행이 된다. 굳이 안넣어도 괜찮다
  • 일정 수정이 될 경우 변경 사유를 작성하게끔 해야하는 기능이 더 좋다
    (일정이 이미 완료 된 경우 일정이 수정이 될 때 변경사유를 필수로 작성)
• PM은 SI가 1인 1플젝이 기본, 솔루션은 2~3개까지도 가능
  • 대시보드에서 플젝 여러개를 보여줄 필요는 없다. 비교하는 것도 아니고 진행이 잘 되는지만 보려고 하는것이기 때문에
  • 여러개를 동시에 보여줄 경우 각 프로젝트의 진행률이나 진행상태만 볼 수 있으면 된다
• 프로젝트 템플릿은 프로젝트마다 형태가 비슷하기 때문에 속성을 건드리는건 굳이 없어도 된다
  • 대신 프로젝트 안에 프로젝트가 있는 형태는 필요할 것 같다
    (ex. 일정관리 프로젝트 - 일정관리 사용자 페이지, 일정관리 관리자 페이지)
• 가중치 속성은 기능을 제공하기보다는 PM이 작성하게끔 해야한다
• 하위 프로젝트가 여러개 있는 경우, 권한별로 다른 프로젝트는 볼 수 없게끔 해야한다
• Task 페이지에는 오늘의 할 일이 아닌 금주, 차주 할 일이 보여줬으면 좋겠다
  • 보고서를 작성하기 위해 할 일은 보이는게 좋다
  • 보고서를 작성하는 기능은 필요없다.
• 프로필이 있을 필요가 있나? 그냥 연락처만 있으면 된다
  • 연락처는 단순 모달이나 사이드바만 있으면 된다
• 알림 설정 기능이 많지 않다면 페이지 형태가 아니라 모달도 좋다
• 알림 기능의 경우 알림이 많아진다면 메일 하나로 보내는게 좋다
• 알림이 너무 많이가면 알림 메일을 끌 것 같다
• PM에게는 프로젝트 예상 진행률 95% 미만으로 떨어지게되면 메일이 하나 간다
• 개발자에게 알림이 가는 것은 굳이 필요가 있을까 싶다
  • 만약 알림을 보낸다면 종료해야 되는 일을 등록 안한걸 한번에 취합해서 스케쥴링 걸어 통합 메일 알림 보내기
• 알림 기록은 1주일치, 1달치 이런식으로 모아서 보여주는 형태가 좋아보인다
• 일정 한번에 수정하는 기능은 플랫폼 서비스의 경우만 필요하기 때문에 굳이 없어도 될 것 같다
• 프로젝트 템플릿 -> 이전에 사용하던 프로젝트를 복사하여 껍데기만 가져오는 기능
• 일정관리에서 comment를 남기는 기능은 필요가 없다
• 대시보드 접근권한은 필요한 기능은 맞지만 조직관리가 되어야한다
  • 간단하게 조직도만 그린다면 괜찮다
  • 프로젝트의 권한은 어떻게 관리할건지
  • 조직도는 수정권한은 없고 인사쪽에서 가져왔다는 가정하에 진행

ERD

• 조직도가 필요하다면 프로젝트 테이블과 조직도 사이에 중간 매핑 테이블 추가하면 된다

• 도메인 기능 써보기

• 모든 테이블에 생성자, 생성날짜, 수정자, 수정날짜 관리하기

• 프로젝트 대시보드와 상세 대시보드로 나누기

• 쿼리는 보안에 위배

• 대시보드에서 제공하는 api가 위젯 사이즈가 반응형으로 사이즈 조정이 된다면 db에서 관리하고
  사이즈 조정이 안되면 관리 안함

• PM은 모두 가능, PL은 일정의 ID와 깊이에 대한 값을 가지고 있어 그 섹션만 접근 가능하게 해야한다

• 개발자, 외부관계자는 이해관계자에 해당하는 일정들의 진행률과 상태만 수정할 수 있어야한다

• 공통코드로 상태값 관리하는걸 추천

  • 공통코드는 너무 많은 곳에서 사용되기 때문에 ERD에서는 외래키를 연결하지 않는다. DB에서는 연결 함
  • 공통코드를 가져올 땐 db function을 만들기도 한다

[ms1011]

프로젝트 관리 시스템 요구사항 정리

1. 외부 직원 관리

• 외부 직원이 프로젝트에 참여하려면 별도의 가입 기능이 필요하다.
  • 가입은 관리자에 의해 이루어지는 것이 선호됨.
  • 필요에 따라 직접 회원가입을 허용할 수 있지만, 관리는 관리자 중심으로 한다.

2. 외부 공유 기능

• 외부 공유를 위한 기능이 필요한가?
  • 공유의 주체는 관리자여야 하며, 외부 직원은 관리자에 의해 추가된다.
  • 추가된 외부 공유자는 soft delete를 통해 탈퇴 처리할 수 있다.

3. 데이터 수정 권한

• 외부 공유자와 개발자에게는 데이터 수정 권한을 제한한다.
  • 진행률과 진행상태만 수정 가능하다.
  • 일정 추가는 PM 또는 PL에게 문의 후 진행된다.
• 일정 수정이 발생하면, 완료된 일정의 경우 변경 사유를 필수로 작성해야 한다.

4. 대시보드 관리

• PM은 1인 1프로젝트가 기본이며, 솔루션의 경우 2~3개까지도 가능하다.
• 대시보드에서 여러 프로젝트를 동시에 볼 필요는 없다.
  • 여러 프로젝트를 보여줄 경우, 진행률과 진행상태만 볼 수 있으면 된다.
  • 세부사항이 필요할 경우 상세 대시보드로 분리한다.

5. 프로젝트 템플릿

• 프로젝트마다 구조가 유사하므로 프로젝트 템플릿은 단순한 복사 기능이 좋다.
• 프로젝트 내부에 하위 프로젝트가 있는 구조도 필요하다.
  • (예: 일정관리 프로젝트 -> 일정관리 사용자 페이지, 일정관리 관리자 페이지)
• 가중치 속성은 PM이 작성해야 하며, 시스템에 의해 자동으로 부여되지 않는다.

6. 권한 관리

• 하위 프로젝트가 여러 개 있을 경우, 권한별로 다른 프로젝트를 볼 수 없게 해야 한다.
• PL은 일정의 ID와 깊이에 따라 해당 섹션만 접근할 수 있어야 한다.
• 개발자와 외부 공유자는 자신과 관련된 일정의 진행률과 상태만 수정할 수 있어야 한다.

7. 업무 할 일

• Task 페이지에는 오늘의 할 일 뿐만 아니라 금주, 차주 할 일이 표시되어야 한다.
• 보고서 작성 기능은 필요하지 않지만, 할 일은 볼 수 있도록 해야 한다.

8. 알림 기능

• 알림은 페이지 형태가 아니라 모달로 처리하는 것이 좋다.
• 알림이 많아지면 이메일 하나로 통합해 보내는 것이 좋다.
• 알림이 너무 많이 가지 않도록 조절한다.
• 알림 기록은 1주일치, 1달치 등으로 모아서 보여주는 기능이 필요하다.
• PM에게는 프로젝트 예상 진행률이 95% 미만으로 떨어지면 이메일이 전송된다.
• 개발자에게는 스케줄링을 통해 통합 알림을 보내는 것이 좋다.

9. 프로젝트 관리

• 프로젝트 템플릿은 이전에 사용했던 프로젝트를 복사하는 기능으로 제공한다.
• 일정 관리에서 댓글 기능은 필요하지 않다.

10. 조직 관리

• 조직 관리를 위해 조직도를 추가해야 할 경우, 프로젝트 테이블과 조직도 사이에 중간 매핑 테이블을 추가한다.
• 조직도는 수정 권한이 없고, 인사 부서에서 가져온다는 가정 하에 진행한다.

11. 공통 코드 관리

• 상태값은 공통코드로 관리하며, ERD에서는 외래키를 연결하지 않는다.
• 공통코드는 DB function을 사용하여 가져올 수 있도록 한다.

12. DB 관리

• 모든 테이블에 생성자, 생성 날짜, 수정자, 수정 날짜를 관리한다.
• 쿼리는 보안에 유의하여 작성하며, 위젯 사이즈 조정이 가능한 경우 DB에서 관리하고, 조정이 불가능한 경우 관리하지 않는다.

[orlzlL]

Q. 회원가입에 대해

A. 회원가입 안 함

회원 등록 (회원 관리 페이지) 에서 관리자가 만들어주고 이걸로 로그인하라는 방식이 더 ERP스럽다

회원 가입보다는 회원 등록과 회원 삭제하는 관리 페이지가 필요함

외부 기업 -> 주로 개발자 -> 언제 뭘 개발해야하는 지 일정 확인해야하는데 그럼 이쪽으로 와서 볼 수 밖에 없음 -> 그럼 가입을 시켜야함 -> 회원가입보다는 정보를 받아서 등록시켜주는 게 확실함 (회원가입은 우리프로젝트 인원인지아닌지 확인하고 승인하는 절차를 또 만들어야해서 번거로움)

ERP는 결국 권한 처리이므로 권한이 세분화되어 있어야함

권한

개발자 또는 외부인력들이랑 협업할 때 :

외부 인력들은 열람만 가능하게 시트쪽만 열어주기 (권한)

일정 수정은 못 하지만 했다안했다 라는 체크만 가능하도록 권한 설정 (특정 셀에만 권한을 부여), 퍼센트로 입력하는 필드 하나만 외부 직원들이 수정할 수 있도록 처리

(메모: PM한테는 자기가 관리하고있는 프로젝트들을 다 볼 수 있고 어떤 프로젝트에 참여 중인 개발자에게는 자기가 참여하고 있는 프로젝트만 볼 수 있고, 표시할 수 있도록)

Q. 일정 연장 요청 기능

A. 일정 연장 요청은 시스템보다 면담으로 먼저 요청할 것임. 시스템으로 기능 넣어도 괜찮긴한데 어쨌든 연장요청하면 회의가 일어나게 될 것임.

연장 요청 기능은 필요 없고 (PM이)일정 수정할 때 무조건 사유를 입력하게 하면 됨. 수정할 때마다 이력을 남기도록

게시 여부 이런 개념으로 플래그에 따라 수정되거나 추가될때마다 이력을 남길지 안남길지

Q. 주로 최대 몇 개의 프로젝트를 관리하는지?

A. 거의 한 명당 하나의 프로젝트를 맡음

(프로젝트 여러 개가 한 페이지에 나오는 건에 대해)

프로젝트 각각 잘 되고있는지 보면되지 프로젝트끼리 비교분석할 필요는 없음 (진행도를 비교하면서 따질 건 없다)

괜히 세개 비교해서 보여주면 더 눈에 안 들어올 것 같음. 세 개 진척률이 잘 되고 있는지 어떤 프로젝트가 빨간불이 들어왔는지만 명확하게 보여주면 됨

Q. 자주 사용하는 컬럼 명을 템플릿처럼 지정해서 사용하는 기능에 대해

A. 고정적인 항목, 필수 항목은 당연히 넣어놓고 추가 항목은 PM에게 맡겨야 함

필수 항목은 당연히 고정해 두어야 함

이런 형태에서 여러개가 나오긴 하는지?

필수 사항만 두고 개인이 필요한 것만 추가해서 쓰라고 하는 게 맞을 것 같다

템플릿화라고하면 위치, 배치, 색깔, 형태가 있어야 하는데 그런 형태가 굳이 안 나올 것 같다

프로젝트 형태 따라서 일정이 많이 달라지지는 않을 것 같다.

템플릿보다 프로젝트 안에 프로젝트를 관리하는 게 좋을 것 같다

각각 리더도 다를 거고 각각에 대한 일정관리도 해야하고 통합한 전체 진도율도 나와야 함

전체와 서비스별 따로 나와야 함

depth에 따라 UI를 어떻게 구성하느냐에 따라 화면 구성은 달라질 것 같다

맨 앞은 종합, 탭 별로 서비스 별로 종합하는 등

서비스 단위별로 붙일 수 있는 기능, 서비스 단위별로 거기만 담당자들이 일정관리하게

전체 일정 기준으로 서비스별로 나누어서

(예를 들어 세 개면)세개마다 진행률 따로 표시, 합쳐서 전체 진행률 표시

템플릿? 보다는 전에 했던 프로젝트 항목을 그대로 가지고 오도록 하는 기능

Q. 가중치 기능

A. 그냥 PM이 가중치 작성할 수 있게만 해주면 됨

기능적으로 뭘 할 필요는 없을 것 같음

할 수도 없음

프로젝트마다 어떤게 가중치가 더 높을 지 모르는데 시스템적으로 해줄 수 있는 게 없을 것 같음

Q. task 페이지

A. 주 단위로 볼 수 있으면 좋을 것 같음

이번 주에 해야될 것들이 표시되도록 (금주, 차주)

필터 기능보다는 그냥 금주 할일, 차주 할일 나오게. 대부분 주간 보고를 하기 때문

Q. 프로필

A. 프로필 자체가 굳이 있을 필요가 있을까?

있으면 좋은데 여기 등록된 게 결국 contact에 나타나고 간단한 정보만 있으면 될 것 같고 프로필이 굳이?

외부 등록 해도 자세하게 등록 안 하고 아이디, 전화번호, 메일주소, 회사명 정도까지만 있을 거라서 프로필 페이지가 아니라 간략한 팝업 레이어로 나와서 거기서 수정하고 닫는 형태로

Q. 알람 기능 설정하는 페이지

A. 알람 항목 갯수에 따라 프로필에 이쁘게 설정하는 메뉴가 들어갈 건지 따로 뺄건지 결정될 것

많을 시 : 알람 설정 페이지를 따로 뺌

적을 시 : 지금처럼 프로필 화면 우측 구석에서 설정할 수 있도록

어떤 알람을 보낼 것인지 설계가 먼저

오늘까지 마감인 일이 다섯개면 알림을 다섯 개 보낼건지 ?;

→ 카운트해서 다섯개 있다고 알림…?

일정을 세부적으로 작성하면 알람이 너무 많이 가면 귀찮아서 알림을 꺼버리고 그럼 기능이 무용지물이 될 것

기능별로 일정을 다 잡아주는데 그러면 알람이 너무 많이 쌓이게 될 것

일정을 기준으로 알람을 보내면 너무 많은 알람이 간다

알람이 PM에게 가는지 개발자에게 가는지에 대한 기준

→ PM은 5% 넘어가면 기획대비 실행률이 94% 미만으로 내려가지면 알람이 보내도록 (경고 메세지)

늦어졌을 때 알림 가는 기능

→ 어짜피 자기가 늦었다는 것을 알고 있을 것

세부적으로 업무 태스크, 일정을 잡으면 하루이틀이 대부분인데 내가 안 했다라는건 개발자들이 이미 알고있음

개발자에게 알람을 주기가 애매함. 만약에 준다면 얼마나 업무가 안 되어있다고 주는 정도

며칠까지 끝내기로 했는데 완료처리가 안 되어있으면 완료 처리가 몇개몇개 안 되어있다고 알림을 하는 것은 괜찮음

미리 알림은 필요 없고 안 된 것에대한 noti

알림 페이지

알림은 한 가지 색으로만 되어있어도 괜찮을 것 같음

최대 몇 개 표시할 지?

최근 한달 최근 일주일 이렇게만 표시되도록

최근 n일 것만 보여주도록해서 굳이 페이징은 필요 없음

Q. 관련된 일정이 한 번에 미뤄지는 경우가 있는지?

A. 서비스 회사면 그럴 수 있는데 SI 이면 미루면 다 돈드니까 미룰 일이 딱히 없다

Q. comment 기능 필요성

A. 필요 없다.

Q. 상급자가 프로젝트 진척률을 보고싶어하는 경우?

A. 팀장인데

이걸 넣으려면 조직 관리를 넣어야 함

우리 팀에서 하는 프로젝트만 나오게 하는 프로그래밍이 해야하는데 할 수 있으면 하면 됨

필요한 기능은 맞고 할려면 우리 팀 것만 봐야해서 조직관리가 이루어져야함

조직도 자체가 트리 구조로 가야하고 프로젝트 생성할 때 이프로젝트가 어떤 팀인지 ?

등록한 사람의 조직을 따라갈 건지 아니면 등록할 때 어디팀꺼다라고 할건지에 대한 고민

마리아디비에서 트리구조로 데이터를 뽑으려면 오라클보다는 번거로울 것

조직도를 넣으면 팀장이 프로젝트 여러개가 잘 돌아가는지 안 돌아가는지 확인

Q. 단어사전 어케

A. 영문을 풀네임으로 쓸거냐 약자로 쓸거냐

user인지 usr 인지

이걸 어떤 규칙을 따를 건지도 단어사전에서 정하면 됨

대부분 영단어로 하다보면 너무 길어져서 약자로 함

디비 할 때부터 약자로 넣고 그대로 변수도 똑같이 감

VO객체를 쓰는 이유 → 데이터 오염방지도 있는데 해킹 방지를 위해서 씀

이거 조회할 때 이 컬럼만 조회하겠다는 의미가 됨

VO로 하면 다른 컬럼은 조회할 수 없으니까 VO를 씀

schedule → schdl 이런 식으로 약자로 많이 사용

Q. DB속성명 정할 때 어떤 식으로 정의하는 지

A. 컬럼명만 봐도 뭔지 알 수 있도록

제목 내용 겹치면

스케줄_내용 스케줄_제목 이런 식으로 컬럼명만 봐도 알 수 있도록

DB

SaaS 형태 → 회사 관리까지 필요

외부직원이 PM이 될 수도 있으므로 역할은 무조건 필요함

(회원등록할 때 역할 부여)

사원번호 구별

내부 : 숫자
외부 : e_어쩌고

알림 자체에 대한 테이블, 알림 보내는 것에 관련된 테이블 따로

순수하게 알림관리, 발신관리, 설정관리 세 개로 나누어질 수도 있음

→ 안 나누면 알림 설정 관리 할 때 UPDATE 할 때 곤란해지므로 분리되는게 맞음

생성날짜 수정날짜 생성자 수정자 → 전부 관리 (내역 관리)

대시보드

종합 대시보드/개별(상세) 대시보드로 나누어지려면 테이블도 나누어져야함

테이블 속성으로 쿼리를 사용하면 보안 적인 문제가 발생하므로 불가능함.

쿼리로 가져오는 게 아니라 개발을 해 두고서 끌어오는 형태가 되어야 함

대시보드를 설정하는 관리자 화면을 어떻게 만들 지에 따라 디비 달라짐

대시보드의 위젯 관리 → 추가하고 삭제하고 할 때 이쁘게 정리가 되게 하는 것에 대해 고민을 해야됨

특히 차트부분들 늘어나거나 줄어들면 안에 내용이 어그러져서 보이게 될 것임

이 기능이 되면 대시보드관리를 넣고 안되면 걍 고정형으로하고 관리 X

권한 관리를 위해 일정에 담당자 속성 추가해서 나중에 조인걸 때는 사원번호로 조인

일정 → 분석, 설계, 개발의 단계에 따라서 task를 좀 나누어야됨

공수 → 시작일 종료일에 공휴일 빼고 계산

템플릿 복사 할 때 → 임시 테이블 ?

임시 테이블 거로 보여주다가

프로젝트에서 확정됐으면 일정 바라보고 수정하게 하고

확정 안 됐으면 임시테이블에서 자유롭게 수정할 수 있음

확정 눌렀을 땐 일정에서 수정되게

(확정되는 건 PM이 직접 눌른다음에 확정됨. 분석/설계 단계에서도 바뀔 여지 잇기때문)

상태값에 따라 어떤 테이블을 바라볼 지 query 할 때 잘 해줘야 함

요구사항ID 눌렀을 때 (매칭 되어서) 팝업으로 요구사항 내용까지 나오는 기능 있으면 좋을 듯함

프로젝트 : 조직도

추후 다대다 매핑 테이블 확장

공통코드로 관리

재직상태, 상태,언어 등 여러 곳에서 사용되는 것들을 공통코드(그룹)로 관리

추후에 공통코드가 없으면 하드코딩을 해야할 수도 있음

[ms1011]

프로젝트 관리 시스템 기능별 세부 요구사항

회원가입 및 관리

• 시스템 내 회원가입은 하지 않음.
• 회원은 관리자에 의해 회원 등록 페이지에서 추가됨.
• 외부 기업의 직원(개발자 포함)이 일정 확인 및 협업을 위해 등록됨.
• 회원가입보다 정보를 받아서 관리자가 등록하는 방식이 선호됨.
• ERP 시스템은 권한 처리가 중요하므로, 권한이 세분화되어 있어야 함.
• 외부 직원에게 일정 확인 권한만 부여하고, 수정 권한은 부여하지 않음.
• 외부 직원에게 허용되는 수정 권한은 진행률 입력 정도로 제한됨.

일정 관리

• 일정 연장 요청 기능은 시스템에서 필요하지 않으며, 면담을 통한 요청이 선호됨.
• 일정 수정 시 변경 사유를 필수로 입력하도록 하여 이력 기록이 가능해야 함.
• 일정이 수정될 때마다 이력을 남기도록 하고, 일정 연장 요청 기능은 생략.

프로젝트 관리

• 대부분의 PM은 한 명당 하나의 프로젝트를 관리하며, 프로젝트끼리 비교는 불필요.
• 프로젝트 진척률은 프로젝트별로 따로 보여주고, 합쳐서 전체 진행률을 표시함.
• 프로젝트 템플릿 기능 대신, 이전에 했던 프로젝트 항목을 복사하여 재사용 가능하도록 함.

권한 관리

• 권한은 세분화되어 있어야 하며, PM은 모든 프로젝트를 볼 수 있고, 개발자는 자신의 프로젝트만 볼 수 있도록 제한.
• 외부 인력에게는 열람 권한만 부여하고, 일정 수정 권한은 제한함.
• 일정 관리에서 PL은 자신의 섹션만 접근할 수 있어야 하며, 개발자는 해당 프로젝트에서 진행률과 상태만 수정할 수 있어야 함.

Task 페이지

• Task 페이지에는 금주, 차주 할 일 목록이 표시되어야 함.
• 주 단위로 표시하는 것이 선호됨.
• 보고서 작성 기능은 불필요하지만, 주 단위로 할 일 목록이 표시되어야 함.

알림 기능

• 알림은 모달 또는 간단한 형태로 관리하며, 알림 설정 기능은 알림의 개수에 따라 페이지 형태 또는 프로필 내 설정으로 처리.
• 알림이 너무 많아지지 않도록 조절하고, 개발자에게는 완료되지 않은 작업에 대한 알림을 통합하여 보내도록 함.
• 알림 기록은 최근 1주일치 또는 1달치로 관리하여, 최근 일정에 대한 정보를 쉽게 확인할 수 있도록 함.

프로필 및 조직 관리

• 프로필 기능은 불필요하며, 간단한 연락처 정보만 있으면 충분함.
• 조직도는 트리 구조로 관리하며, 프로젝트 생성 시 해당 팀과 연결되는 구조가 되어야 함.
• 팀장이 자신의 팀 프로젝트만 볼 수 있도록 권한 관리가 필요하며, 조직도는 사원번호를 기준으로 조인할 수 있어야 함.

공통 코드 및 DB 관리

• 공통 코드는 여러 곳에서 사용되므로, ERD에서는 외래키로 연결하지 않음.
• 모든 테이블에는 생성자, 생성 날짜, 수정자, 수정 날짜를 관리함.
• DB 속성명은 컬럼명만 보고도 어떤 데이터인지 알 수 있도록 명명해야 함.
• 테이블 속성 관리 및 쿼리 처리 시 보안에 유의해야 함.

대시보드

• 대시보드는 종합 대시보드와 개별(상세) 대시보드로 나누어지며, 테이블 구성도 이에 맞춰져야 함.
• 대시보드의 위젯 관리 기능은 차트 부분이 늘어나거나 줄어들 때도 이쁘게 정리되도록 해야 함.
• 위젯의 추가 및 삭제 기능이 가능하도록 대시보드 관리자 화면이 구성되어야 함.

기타 기능

• 템플릿 기능 대신, 이전 프로젝트 항목을 복사하여 재사용 가능하도록 함.
• 프로젝트 상태값에 따라 다양한 테이블과 매칭할 수 있어야 하며, 팝업으로 세부 내용을 확인하는 기능이 포함될 수 있음.
• 공수 계산 시 공휴일을 제외한 기간을 고려해야 함.
• 공통 코드를 활용하여 재직 상태, 상태, 언어 등 다양한 정보를 관리해야 함.