1. 프로그램 개발 완료 후, 수정하게 되는 경우 기 개발된 로직과의 충돌(상호모순) 또는 무시하게 되는 경우를
사전에 예방할 수 있는 방법은? 또는 테스트 할 수 있는 방법은?
(예) 계산서 발행 프로그램에서 거래명세서 발행분만 발행 할 수 있도록 변경 하였더니
'매출할인'계산서(거래명세서 없음)도 발행 할 수 없게 되는 bug 생성.
2. 현업과의 업무분석 시 주의 점
- 모든 현업의 요구사항은 그 앞에 하나의 말이 생략 되어 있다. 바로
"지금은(현재는)" 이다.
- 어떠한 요구사항도 변경 될 수 있다는 점을 간과해서는 안된다.
"그런 프로세서는 없습니다." 라는 현업의 말 속에는
"지금은 그런 프로세스는 없습니다. 그러나 나중에는 발생 할 수 있습니다." 라는 뜻임을 명심할 것!
3. 생산, 매출, 반품, 환입 .... 회계(계산서)
- 생산 부터 이후의 모든 프로세스 까지 연결고리가 끊어지지 않도록 설계 되어야 한다.
- 생산(제조사업장), 도매(판매사업장) 사업장간의 자유로운 재고이동 및 매출/반품이 고려 되어야 한다.
(매출발생한 사업장으로 반품(재고, 계산서)이 발생)
4. 폐업이나 사업주 변경 등으로 거래처 잔고가 이동 할 때, 실적 또한 이동 해야 반품 시에 원래(변경전) 거래처를
찾아가서 단가정보 등을 찾을 수 있다.
여기서 실적이동 이란 실제로 전표내역이 이동한다기 보다, 변경 된 거래처코드 간 이력을 관리해야 한다는 의미 임.
변경된 거래처간 이력이 없을 경우 부동처조회에도 영향을 미친다. 즉 과거 거래처에서 수금이 6개월 이상 없어서
부동처 임에도 불구 하고 신규 거래처로 잔고 이동할 경우, 이동한 일자가 6개월 미만이라면 수금부동처에서 누락이 된다.
5. 설계변경시 유의점
- 변경하게 될 경우 과거 및 현재의 데이터를 어떻게 할 것인가?
(과거 데이터의 마이그레이션 및 현재 발생중에 있는 데이터의 처리)
'개발정보' 카테고리의 다른 글
HTML Submit 버튼 OnClick 이벤트 (0) | 2010.04.06 |
---|---|
MS SQL서버를 JDBC로 접속 하기 (0) | 2010.04.05 |
요구사항 분석시 검토사항 (0) | 2010.04.02 |
델파이 DB관련 클래스 설계 고찰 (0) | 2010.03.29 |
테이블 디자인시 고려할 점 (0) | 2010.03.29 |