Project/NAWA

NAWA 프로젝트 설명

 

1. 문서 작업

 

한달 동안 진행된 문서작업

문서 작업은 예상만큼이나 어렵고 시간이 많이 들어갔다.

처음으로 개발 예정 보고서로 역할분담, 일정, 시스템 구성도, 구현을 작성하였다.

학원에서 같이 배운 언어와 개발도구를 사용 했기 때문에 어렵지 않았다.

역할분담에서 개인의 역량 차이 때문에 조금 시간이 지체되었지만, 프로젝트를 진행할 때 추가, 수정되었다.

 

시스템 아키텍쳐

그 후 기능정의서 (FBS)를 시작하며 정말 힘들었다...

그 후에 만든 문서에서 조금이라도 바뀌면 FBS도 바꿔야 하는 상황이어서

처음 계획할 때 좀 더 신중했어야 했다는 걸 뼈저리게 느꼈다...

구현되어야 할 기능이 하나하나 나열되어있다.

계속해서 바뀐 기능정의서
이벤트 참가 기능
공지사항 게시판

대망에 요구사항 명세서 , 가장 시간을 많이 쏟아부었던 것 같다. 그래서 개발할 때 무척 도움이 많이 되었다.

팀 프로젝트이다 보니 서로 명확했어야 하는 부분을 개발하면서 확인할 수 있었다. 이때 서로 부를 용어나 기능 작동 방식을

팀원 모두가 명확하게 알 수 있었다.

명확한 설명! 정말 큰 도움이 되었다.

작업 분류 체계 (WBS) 작성

WBS가 변경될 때마다 FBS 또한 변경되었다. (그 반대일 때도 있었다..)

개발 진행도를 진척율로 나타내서 PM이 팀원을 관리하고 도와주는 데 큰 도움이 되었다.

 

FBS 설명에 담긴 기능들을 나열하여 세세한 개발진척율 기록

프로젝트의 전체적인 흐름도를 이해하기 위해 유스 케이스 명세서를 작성했다.

강사님께 많이 혼났던 기억이 난다..ㅠㅠ 검색을 해봐도 애매하고 명확하게 잡히지 않았던 부분이지만

팀원들과 공부하고 혼나고.... 완성했던 유스 케이스다.

쿼리 테스트FBS를 참고하여 기능에 따른 쿼리 테스트를 진행했다.

예상 결과, 시험 결과, 결함 내용, 조치 작성하고 쿼리에서 필요한 argument와 result를 따로 분류해서 작성해서 가독성을 높였다.

쿼리 테스트도 개발을 하면서 많이 바뀌는 부분이 많았다.

생각해둔 기능이 실행되려면 다른 기능을 추가해야 하는 부분이 있어 개발 마지막까지도 수정되었던 문서이다.

 

 

테이블 정의서

DB에 테이블 정의서이다. 개발을 하다 확인해야 할 부분 Default값, NULL, CHECK을 작성하여 개발할 때 많은 도움을 주었다.

내가 맡은 부분이 아니어도 명확하고 쉽게 알아볼 수 있어서 내가 맡은 부분의 쿼리와 다른 사람이 맡은 쿼리에 대한 이해를 더 쉽게 만들어 주었다.

 

 

시나리오 테스트

시나리오 테스트에서 화면 전환에 따른 테스트를 작성했다.

넘어가는 페이지의 이름과, SPRING VALUE를 명시하여서 다른 사람이 만든 기능 이어도 쉽게 구분해서 볼 수 있었다.