[SI]프로젝트 2주차

1주차 회의를 진행하고, 2주차에는 어떤 업무들이 진행이 되는지 궁금하여 WBS를 열어 확인했다.
문서작업을 해야하는 것처럼 보이는 일들이 있었고, 그 업무는 왜 하는 것이며 이 프로젝트에 어떤 역할을 하는 업무인지 알아 보았다.

[2주차]

데이터 요구사항 정의서
테이블 정의서
ERD 작성
배치 프로그램 설계

<데이터 요구사항 정의서>

클라이언트와 프로젝트 수행자 간 합의서

문서 기반으로 필요 기능을 정리해 보다 명확하게 필요 사항들을 합의해 나갈 수 있다.
나는 데이터 팀에 속해있어, 데이터 정의서 작성을 하였다. 예시는 아래와 같다.

이렇게 히스토리를 알 수 있고 내용이 잘 정리된 문서를 작성하게 되면 서로간의 명확한 합의가 될 수 있어서 좋은거 같다.

그렇다면, 회의록도 그날의 서로간의 결정된 내용인데 요구사항 정의서가 될 수 없는것일까?
대답은 없다고 한다.

요구사항 정의서는 특정 양식을 가지고 있다고 한다.
요구사항을 요청했다고 한들 모든 내용을 들어 줄 수 없으며, 다양한 경우의 수가 있다 보니 회의록을 요구사항 정의서로 보기에는 한눈에 보기도 어렵고 이해하기도 힘들다는 문제가 생겨버린다.

<테이블 정의서>

DB 설계 시 테이블의 구조와 칼럼의 특성을 알기 쉽게 요약한 내용

테이블 목록과 테이블, 컬럼 목록 추출은 Query를 통해 추출이 가능하며 시스템명, 테이블ID, 테이블 명, 속성, 컬럼, Tyoe, 길이, PK, NULL여부 설명등을 작성한다.

이렇게 작성한 내용을 가지고 실제 개발때, 정의서를 통해 테이블에 어떤 데이터가 있는지 한눈에 알아 볼 수 있어서 개발하는 동안 너무 편리했다.
다만, 처음 작성시 단추를 잘못 꾀면 그 후의 작업에 있어 실수가 계속 도출되므로 다음엔 많은 동료 검토를 통해 실수를 줄여 나아가야 될거 같다.

<ERD 작성>

개체-관계 모델, 테이블간의 관계를 설명하는 다이어그램

우리는 ERD TOOL이 따로 없어 엑셀에 그려 진행했다.

[ERD를 작성하는 이유..]

• 명확한 데이터 구조 이해
  ERD는 데이터베이스에 포함될 각 엔터티와 그들 간의 관계를 시각적으로 보여준다. 이를 통해 데이터 구조를 명확하게 이해할 수 있게 된다.
• 효과적인 커뮤니케이션
  ERD를 통해 모든 팀원이 데이터 모델을 동일하게 이해할 수 있습니다.
• 데이터베이스 설계의 기초
  데이터베이스 테이블, 열, 인덱스 등을 설계하기 전에 ERD를 통해 전반적인 구조를 검토하고 최적화할 수 있다.
• 문제 식별 및 수정
  데이터베이스를 설계하는 초기 단계에서 ERD를 사용하면 잠재적인 문제나 비효율성을 미리 식별하고 수정할 수 있다. 이렇게 하면 나중에 데이터베이스를 수정하는 데 드는 비용과 시간을 절약할 수 있다고 한다.
• 데이터 모델 검증
  ERD는 데이터 모델이 실제 요구 사항을 충족하는지 검증하는 데 사용된다. 그래서 이해 관계자와 함께 ERD를 검토함으로써 데이터 모델의 정확성을 확인할 수 있다.

결론적으로, ERD는 데이터베이스 설계 과정에서 중요한 도구로 사용된다.
이유는 데이터 구조를 명확히 하고 효율적인 설계를 도와주기 때문이다.

<배치 프로그램 설계>

시스템의 효율성, 유지보수성, 일관성을 보장하기 위함

여기서 배치 프로그램은
데이터 처리를 자동화하기 위해 사용되는 소프트웨어 애플리케이션으로, 대량의 데이터를 일괄 처리 하는 것을 목적으로 한다.

[배치 프로그램 설계서의 주요 구성 요소]

• 개요
  배치 프로그램의 목적과 목표
• 기능 명세
  프로그램이 수행할 주요 기능과 그 상세 설명
• 프로세스 흐름
  배치 작업의 단계별 흐름도
• 데이터 사양
  입력 및 출력 데이터 형식, 데이터 소스 및 대상
• 스케줄링 정보
  배치 작업의 실행 시간과 주기
• 오류 처리
  오류 발생 시 대응 방법과 재시작 전략
• 성능 요구 사항
  처리 시간, 리소스 사용량 등 성능 관련 요구 사항

배치 프로그램 설계서를 작성함으로써 개발 과정이 더 체계적이고 효율적으로 진행될 수 있다.

나중에 느낀점은

단위테스트를 진행할때, 내가 설계한 배치 프로그램 설계서를 확인하여 정확하게 데이터가 처리가 되는지 검토할 때 주로 사용하게 되었다.

그래서 초반에 배치 프로그램 설계서를 단순하게 생각했던 나는,
이후 내가 설계하려고 했던 방향성이 맞는지에 대한 여부를 파악하기가 힘들어 어려움을 겪었다.

이로써 2주차가 끝나므로써 느낀점은

1. 업무에대한 문서화 하는 작업이 단순 노동같이 느끼겟지만 이후 개발할때 큰 영향을 준다는 점
2. 초반 문서가 엉망으로 진행되지 않게 동료검토가 중요하다는 사실

신입인 나로썬 그저 단순 문서를 작성한다는 사실에 불만이 많았다.

하지만 이후 데이터를 다루게 되면서 초반에 안일하게 생각했던 문서작업들이 하나하나 영향이 왔고

단순 문서 작업이라 생각해왔던 위와 같은 내용들이 개발 진행할때, 얼마나 중요한지를 큰 깨닳음을 얻게 되었다.