[프로젝트] 해양 재난 상황판 (1)

(깃헙은 프라이빗인데다가 교수님이 포크를 막아놓으셨다....... 그럴실필요는 없었는데요 )

4학년 여름, 현장실습 기간동안 진행한 프로젝트

해양경찰이 사용할 수 있을법한 상황판 프로그램을 만드는 것이 목표이다.

 

나는 DB설계와 스프링 부트를 사용한 REST API 서버를 만들었다.

따라서 닷넷을 이용해 구현한 클라이언트쪽은 잘 모른다...

 

SI회사에서 진행해서 회사에서 진행하는 방법대로 프로젝트의 시작부터 끝까지 배울 수 있었다.

총 4가지의 단계로 프로젝트를 진행했다.

 

글이 길어질 것 같아서 이번 글에서는 분석, 설계를 정리할 것이다.

 

0.분석

왜 0번인진 모르겠는데 암튼

분석단계에서는 요구사항을 분석하고, 기능을 정의했다.

소프트웨어 공학때 요구사항 분석, 유스케이스 작성 이런것들을 배우고 과제에서도 하긴 했는데,

뭣도 모르고 그냥 하라니까 했었다.

물론 회사에서 알려준거랑 좀 다르긴 하지만 막상 회사에서 하려니까 좀 더 전문적이어야 할 것만 같은 느낌..이 들어서 열심히 작성했다.

 

예상보다 더 본격적인 문서작업이었는데, 실제 회사에서는 우리가 수행했던 것 보다 훨씬 더 많은 문서를 작성해서 프로젝트를 관리한다고 한다.

 

요구사항 분석

임의로 고객(해양경찰)이 되어 요구사항을 정의했다.

요구사항정의서

요구사항을 정의할 때, 어떤 기능이 필요한지만 적는게 아니고,

이를 구현하기위해서 대략적으로(전문용어 없이) 그림을 그려준다. 

전제조건과 테스트방안도 적어줬다.

 

원래는 훨씬 많았는데, 팀원들과 회의 끝에 "기간 내에 일단 만들고, 기능을추가하자!"는 마인드로 쳐낼건 다 쳐냈다.

총 12개의 요구사항으로 프로젝트 시작.

 

업무 기능 분해도

본격적으로 설계를 하기 전에 요구사항으로부터 나온 기능들을 확실하게 정리했다.

또한 각 기능들을 최소단위 기준으로 모두 쪼개었는데, 이렇게하면 최소기능 하나씩 개발할 수 있어서 

더 집중력있게 개발할 수 있다고 멘토님께서 말씀하셨다.

기능분해도

기능을 나누는 기준은 다양할 수 있는데, 우리는 상황 표시가 주된 목적이므로 어떤 것을 표시하는 지에 따라서 나누었다.

다른 예로는 화면이 여러개일 경우 화면별로 나눌 수도 있겠다.

세분화된 기능들을 보면, 조회, 표시 등으로 진짜 그냥 기능 하나만 나타낼 수 있게 모두 쪼개었다.

다시 말하자면, CRUD기준으로 하나씩 나누는 작업이었다.

나름 ID도 붙여가면서 관리하려고 노력했다.

 

멘토님 말씀으로는 많은 경험으로 큰 기능을 어떻게 구현해야할지 감이 있어야 할 수 있는 작업이라고 했다.

이를 잘해야 좋은 개발자라고도 하셨다.

 

요구사항 추적표

순전히 관리를 위한 문서.

기능을 요구사항이랑 매칭해서 요구사항이 만들어졌나 확인겸, 길을 잃지 않기위한 문서

요구사항 추적표

아쉽게도 한번 만들고 안 썼다...

 

1.설계

설계 단계부터는 조금씩 파트를 나누었다. 물론 확실히 딱딱 나눈게 아니고,

한 파트의 일이 10이라면 맡은사람이 5정도 하는 느낌으로 했다.

나는 데이터 쪽을 맡아서, 어떤데이터가 필요한지 명세를 작성하고 DB를 설계했다.

 

멘토님 피드백도 받아야해서 전체 타임라인을 만들어서 듀데이트를 지키면서 진행했던것 같다.

 

시스템 인터페이스 설계서

각 시스템별로 인터페이스를 설계해야 하는데, 우리 프로그램은 하나의 기능만 갖고 있었던 터라

외부 API와의 인터페이스 설계를 위주로 작성했다. 지도를 사용해야 했기에 카카오맵 api를 가져왔다.

놀랐던 점은 수도함수 느낌으로 함수명을 대충 정해놓는 것이었다. 

문서를 작성할때는 이게 의미있나? 싶었는데, 서로 각자의 로컬에서 개발하다가 합치려니까 왜 하는지 알게 되었다.

 

화면설계서

화면설계서

화면설계???가 뭐지? 라고 생각 했는데,

화면을 기준을 기능을 나누어 각각을 어떻게 구현해야 할 지 설계하는 작업이었다.

위젯유형, 이벤트, 함수 등을 다 정하고 그에 맞게 구현하려는 의도였다.

 

DB설계 & 데이터 명세

DB설계

컬럼정의

이전까지는 간단한 프로젝트만 해서 DB설계의 필요성을 느끼지 못했다.

그래서 DB를 설계하려고 공부를 많이 했다. 사실 아직도 이게 효율적인 DB인지는 모르겠다. 암튼 칭찬받음

밑의 그림은 이제 테이블 별로 자세하게 적어놓은 명세서인데, 데이터 형식, 길이 PK, FK등을 정의한다.

지금 보니까 엔티티명이나 속성명을 안적었었다...

 

멘토님 말씀으로는 원래는 DB팀이 따로 있어서 개발팀에서 필요한 데이터를 정리해서 주면 DB팀에서 설계를 해준다고 한다. 하지만 개발자가 잘 정리해서 주면 서로 좋다고...

 

---

여기까지 하는데 3주가 걸렸다.

이 글에는 최종본만 잘 안보이게 올렸지만

업무기능 분해도가 뭔지, 인터페이스 설계서가 뭔지, DB설계는 또 어떻게 하는지 찾아보면서 작성했고,

또 작성한 걸 검사 받으면서 수정할 건 수정하고, 없앨건 없애느라 오래걸렸다.

 

그래도 멘토님이 잘한다고 칭찬 많이 해주셔서 '맞게 하고 있구나'라는 생각은 갖고 문서를 작성했던 것 같다.