전통적으로 가장 선호되는 개발 관리 방법론은 폭포수(waterfall) 방법론이다.
폭포에서 떨어진 물이 폭포 위로 거슬러 올라갈 수 없는것처럼 이론적으로는 각 단계의 선이 명확하게 그어진다.
프로젝트는 기본적으로 분석, 설계, 구현, 테스트, 운영의 단계를 거치며 완성된다.
2. 설계단계
IT 프로젝트에서 설계단계에 행하는 것은 분석단계에 도출한 요구사항과 프로세스에 맞는 화면과 프로그램의 개발을 위한 설계서를 만드는 것이다.
이를 위해 화면목록, 프로그램목록, 테이블정의 등을 동시에 진행하게 된다.
보통 화면부터 그리고 이를 토대로 테이블과 프로그램 개발을 진행하는데,
이는 고객과의 커뮤니케이션의 편의성 때문이다.
설계를 다 해놓고 고객이 "그게 아니고요..." 한 마디면 처음부터 다시 해야 하니까...
그래서 요즘은 간단히 설계서를 화면에 옮겨놓아 고객이 이해하기 쉽게 도와주는 프로토타입 프로그램을 많이 사용한다.
그래도 어차피 시작은 파워포인트다.
설계와 기획을 하다보면 파워포인트와 정말 친해져야 한다.
설계가 완성되고 고객의 컨펌이 끝나면 비로소 개발자가 개발을 시작하게 된다.
이게 워터폴 방식의 특징이다.
개발하고 있는데 옆에서 자꾸 설계를 변경하면 개발의 진행이 더디게 되고 품질도 보장 못하게 되기 때문이다.
그래서 워크샵 등을 통해 설계를 설명하고 확정짓는 행사를 하고는 한다.
흔히 이를 프리징한다고 한다.
(참고로 애자일 방식은 이런 프리징 단계가 약하거나 없다. 단위 설계와 동시에 프로그램을 개발하고, 고객과 함께 시제품을 운영해보면서 개선점을 도출한다. 그래서 애자일 방식 프로젝트 잘못 만나면 개발자가 죽어난다)
일반적인 설계단계 산출물은 다음과 같다.
- 화면 목록 및 화면 설계서
- 프로그램 목록 및 프로그램 설계서
- 엔티티 목록 및 테이블정의서
- 논리 및 물리ERD
- 매핑정의서
CBD 방법론 등에서는 클래스 설계서, 사용자인터페이스(UI) 설계서라고 표현한다.
화면목록 및 설계서
설계단계에 사용자와 접점을 찾으라면 이 화면설계서를 꼽을 수 있다.
사실 사용자는 이 화면을 통한 기능만 이용할 수 있다.
내부 로직이나 서버에 구축된 프로그램이 어떻게 작동하는지는 알 수가 없다.
그래서 설계자는 최종 사용자가 이해할 수 있도록 설계서에 표현할 필요가 있기도 한데,
원래 설계서는 개발자가 잘 이해할 수 있도록 제작해야 한다.
화면설계서의 구성, 또는 표현 방식에 따라 와이어프레임, 스토리보드, 화면설계서 등이 있다.
화면에서 작동하는 주요 기능과 입/출력 항목은 빠지지않게 표시해줘야 한다.
프로그램 목록 및 프로그램 설계서
화면설계서와 짝을 이루는것이 프로그램 설계서이다.
화면은 사실 정적인 구성일 뿐이고 그 속의 내용을 채우는 것은 모두 프로그램이다.
보통 데이터는 데이터베이스에 저장되고, 프로그램은 DB와 SQL 스크립트를 이용해 데이터를 조회하거나 저장한다.
설계서에는 프로그램의 설명, 모듈 흐름도, 프로그램 기능 설명, 관련 테이블 등을 기술한다.
설계서에 코딩 내용을 적는 것은 아니다.
엔티티 목록 및 테이블정의서
프로그램에서 참조하는 테이블과 컬럼 등의 정보를 정리한 문서가 테이블정의서이다.
테이블, 컬럼이 빠지지 않도록 주의해야 한다.
또, 데이터의 발생양과 관리주기 등을 고려하여 테이블에 담기는 데이터의 양과 보관주기 등을 명기한다.
동일한 컬럼명이 테이블 별로 다른 의미로 쓰이지 않도록 주의해야 한다.
테이블 설계가 잘못되면 프로그램 개발자가 극단적으로 어려움을 겪게 된다.
테이블 정의 및 참조 구조를 파악하는데는 ERD가 쓰인다.
ERD 제작용 프로그램은 보통 ERWin 을 많이 사용한다.
'IT세상 톺아보기' 카테고리의 다른 글
| SAP HANA DB vs Vertica DB 비교 (0) | 2021.11.30 |
|---|---|
| 웹 브라우저에서 프로그램 설치 여부 확인 (0) | 2021.10.15 |
| 기술 성숙도 (TRL) (2) | 2021.09.27 |
| 결국은 상상력과 공감이 답이다... 갤럭시 플립3에 쏟아지는 관심 (0) | 2021.09.22 |
| 메타버스 - 제페토(ZEPETO) (0) | 2021.09.05 |
댓글