세미 프로젝트

프로젝트 명 : class-link

1조 클럽

조장 : 전수환

DB관리자 : 김정훈

이슈관리자 : 임성훈

형상관리자 : 박혜정

일정관리자 : 전원희

 

1. 프로젝트 구상

최초에 저희는 당근 마켓을 벤치마케팅하여 물건을 대여해주는 서비스 플랫폼을 제작하려 했습니다.

그러나 해당 서비스는 세미 프로젝트 주제인 erp와 많이 동 떨어져있다는 강사님의 피드백을 받고 계획을 모두 갈아엎고 학원 관리 시스템을 제작하기로 하였습니다.

 

저희가 학원 관리 시스템을 제작하기로한 이유는 이렇습니다.

 

1.학원에서의 출결 정정 처리가 수기로 이루어져 불편하고 한눈에 기록을 확인하기 어렵다.

 

2.또한 학원 내의 기자재를 관리하고 상담 신청, 반 관리등 다양한 행정처리를 묶어 하나의 통합 프로그램이 필요하다.

 

그에 따라 저희가 조사한 유사 프로그램은

00 대학교 출결 관리 어플.

. 학생이 앱을 통해 본인 인증 → 모바일 학생증 발급 → 출입/출결 체크 가능

. 학생이 자신의 출결 결과를 앱에서 조회하고, 이의신청하거나 유고결석(사유 있는 결석) 신청할 수 있다는 매뉴얼이 존재

K-12 온라인 학교

. Acellus는 명확히 세 가지 권한 계층(학생, 교사, 관리자)으로 나뉩니다.

. Acellus 자체는 온라인 출석(로그인/시청시간 기반)

. Acellus는 각 단원별 자동 퀴즈와 시험을 통해 성적이 실시간 업데이트 됨.

. 관리자는 학생별·반별 리포트를 조회 가능.

 

이렇게 두가지입니다.

 

두가지 유사프로그램을 보면서 저희는 고객의 입장에서 학원 관리 프로그램을 요청한다 하였을때 요구사항을 정의 하였습니다.

 

 

이렇게 정의한 요구사항에 따라서 피그마를 사용하여 화면 ui와 erd를 구성하였습니다.

 

 

구상한 화면과 erd를 토대로 토론을 통해서 개발할 화면과 기능을 정리하였고, 조장인 저를 제외한 인원들이 우선적으로 원하는 기능을 배분하기로 하였고 최종적으로 각자 개발하기로한 기능은 다음과 같습니다.

 

전수환 : 비밀번호 찾기 ,비밀번호 변경, 문의 게시판, 공지사항 게시판, 알림창, 출결관리, 직원 관리, 출결 현황

임성훈 : 일정조회, 강의만족도조사, 수업일정관리, 강의만족도관리, 일정관리

박혜정 : 로그인, 학생 대시보드, 강사 대시보드, 관리자 대시보드

김정훈 : 상담신청, 상담관리, 출결 정정 신청, 출결 정정 관리,기자재 관리

전원희 : 회원가입,성적 조회, 마이페이지, 강사 학생관리, 관리자 학생관리.

 

2. 프로젝트 구현.

 

각자 맡은 기능을 담당하여 개발하기로 결정하였고 , 그 과정에서 기능별로 컨트롤러를 분리하여 개발하기로 하였습니다. 

형상 관리 부분에서 각자 개발별 브랜치를 생성한뒤 푸시후 devloop쪽으러 머지를 하기로 결정하였으나 개발중 간단한 수정은 기능별 브랜치가 잘 지켜지지 않아 개인용 브랜치를 생성한뒤 사용하기도 하였습니다.

 

각자 담당한 화면을 개발중 어려움이 있다면 스스로 해결해보려는 경향이 조금 있었고, 1~2시간정도 스스로 해결이 안된다면 조장인 제가 도움을 주던가 아니면 강사님에게 도움을 요청하였습니다.

 

개발 진행도중 토론을 통해 비밀번호 변경과 비밀번호 찾기 기능을 마이페이지 담당자인 전원희씨가 담당하는게 어떤가 하는 의견이 있었으나 비밀번호 찾기의 경우 그 당시 eamil api를 사용하기로 결정된 상황에서 제가 직접 하는게 나을것이라 판단하여 비밀번호 변경의 담당자만 전원희씨로 변경되었습니다.

그리고 개발 진행중 현재 저의 화면상 기능으로썬 반을 추가하고 해당 반에 수업을 배정하는 화면이 없다는 것을 깨닫고 급하게 반 관리 화면을 제가 담당하여 개발하게 되었습니다.

 

또한 기자재 관리측면에서 기자재역시 신청과 처리가 있어야한다 판단하여 해당 부분을 기자재 관리 담당자인 김정훈씨가 담당하여 개발하게되었습니다.

 

그러다보니 출결 정정 신청이 시간 이슈로 인하여 급하게 담당자를 변경하여 제가 담당하게 되었고, 출결 정정 처리 역시 저와 임성훈씨가 개발하게 되었습니다.

 

3. 테스트 과정.

11월 18일에 모든 개발이 완료되었고, 그에따라 개발 소스를 모두 통합한뒤 전체 테스트를 진행하였습니다.

 

각자 개인 로컬 환경에서 테스트를 진행하였으며, 테스트 도중 발견된 에러는 각자 기록한뒤 테스트가 완료된후 하나의 파일로 모아서 중복건을 제거한뒤 테스트 케이스를 작성하였습니다.

작성된 테스트 케이스를 기반으로 각 담당자가 우선순위가 높은 에러를 선정하여 해당 에러를 우선적으로 처리하였습니다.

 

4.발표 Q&A

Q: 프로젝트 진행하면서 의견이 달랐던적은 없었나요?

 

A: 효울보단 저희가 편한 부분부터 생각했었는데 그런것 말곤 크게 달랐던 적은 없었습니다.

 

Q: 그러면 의견을 내면 대부분 다 수용하는 편으로 진행했나요?

 

A: 완전 수용은 아니였고 대부분 조율을 통해 진행하였습니다.

 

Q: 조율은 어떤식으로 진행하셨나요?

 

A: 다 같이 토론을 하면서 어떤 의견이 더 좋은지 어떤 것을 선택했을땐 어느 이점이 있는지 이런걸 정리하면서 진행하였습니다.

 

Q: 프로젝트 진행하면서 가장 어려웠던 점은 어떤것이 있나요?

 

A: ERD와 DB가 복잡하게 꼬여있다보니 그 부분을 이해하는게 좀 힘들었습니다.

 

Q: 프로젝트 진행하면서 초기엔 계획에 없었는데 추가된 부분이 있나요?

 

A: 기자재의 경우 초반에는 단순히 관리만 한다는 개념이였는데 중간에 신청과 처리등이 추가되었습니다.

 

Q: 기술적인 측면에선 없었나요?

 

A: 초반엔 비밀번호 찾기를 간단한 방식으로 처리하려 했으나 그 부분은 보안적인 측면에서 안좋은것 같아 emailJs를 사용하여 이메일 api를 추가하였습니다.

 

Q: 보안적으로 안좋다는게 무슨 의미인가요?

 

A: 처음에 저희가 생각한 비밀번호 찾기는 간단한 질문리스트를 만들어 정답을 맞추면 비밀번호를 변경할수있게 할까? 라는 생각을 했는데 이 부분은 해당 질문리스트와 정답만 알수있다면 바로 뚫을수있기 때문에 다른 방법을 생각했습니다. 이때 생각한게 전화번호 본인 인증과 이메일인증입니다. 다만 전화번호 인증의 경우 무료 api를 찾기 어려워서 이메일쪽으로 방향을 전환했습니다.

이때 가장 쉽게 사용할수있는 api가 emailJs라서 해당 api를 선택하였지만 emailJs역시 이메일을 전송하는 부분이 백이 아닌 스크립트쪽에 존재하다보니 그 부분이 화면에서 개발자모드로 접근이 가능하여 실제 실무에선 보안이슈로 잘 사용되지 않는것으로 알고있습니다.

 

Q: 비밀번호 찾기에 토큰이 사용된것으로 보이는데 유효기간이 있나요?

 

A: 30분의 유효기간이 존재하며 유효기간이 만료시 알람창과 함께 접근이 불가능합니다.

 

Q: 토큰이 DB에 저장되나요?

 

A: 토큰과 함께 비밀번호 찾기에 사용된 ID가 DB에 저장되며 url에 함께 토큰이 전송됩니다. 토큰이 포함된 url로 비밀번호 변경 페이지에 접근시 해당 토큰을 가져와서 DB와 비교하여 사용자 ID를 불러온뒤 비밀번호 변경에 사용자가 입력한 비밀번호로 비밀번호를 변경합니다.

 

5. 과정중 이슈 사항.

5-1. 최초 구현단계에서 erd가 너무 복잡하게 구성되어 저를 포함한 다수의 인원이 헷갈리는 일이 많았습니다.

그때마다 대화를 통해 서로 이해하고있는 부분을 연결하여 그 부분을 해결하였습니다.

 

5-2. 깃 커밋 관련 이슈가 조금 있었습니다. 대다수의 인원들이 깃에 익숙하지 않다보니 main쪽으로 머지를 하는경우도 있었고 머지 없이 devloop에 커밋을 하는 경우도 있었지만 그래도 큰 이슈없이 넘어갈수 있었습니다.

 

5-3. 프로젝트 후반부에 일정 이슈가 생겼었습니다. 신규로 추가된 화면들 때문에 기존 일정이 밀리고 전체적으로 후반부에 야근을 자주하게된 원인인것 같습니다.

 

6. 아쉬웠던점.

최초 구상 단계시 저는 제가 경력자이다보니 제가 나서서 하게된다면 조원들의 협업기회를 빼앗을수도 있겠다는 판단을 하였고, 초반부에는 조언역할을 해야겠다 생각했었습니다. 현재까지도 그 판단이 완전히 틀렸다고 생각하진 않지만 제가 주도해야할 타이밍을 너무 늦게 잡은것은 문제였다고 생각합니다. 

 

초반부 설계가 조금 느슨해서 추가되는 화면과 기능이 후반부에 튀어나왔고 그에 따라 일정이 밀려서 후반부에 야근이 잦았던것 같아서 이부분은 굉장히 아쉽고, 조원들에게 미안한 생각을 가지고 있습니다.

 

또한 일정이 밀리는 바람에 제가 개인적으로 추가하고 싶었던 기능을 추가하지 못한것도 아쉬운점으로 남아있습니다.

 

7.개선하고 싶은점.

우선 아직 남아있는 오류들을 모두 처리하고 싶습니다.

 

추가적인 개발하고 싶은 기능으로는 출결정보를 엑셀로 출력하는 기능.

시험관련 시스템.

기자재 반납.

회원가입시 이메일인증.

 

이 정도를 생각 중이며 추후 조금씩 개선해나가려 합니다.

 

8. 프로젝트를 통해 배운점.

 

조장으로써의 역할과 책임감에 대해 많은것을 배운것 같습니다.

조장으로써 조원들을 이끄는데에 있어 많이 부족했고, 이렇게 하면 안된다는 것을 깨달았습니다.

 

파이널때는 좀더 적극적인 자세로 초반설계부터 제대로 하면서 구상할 생각입니다.