SWEBOK에 있는 개발 프로세스 단계를 워터폴 모델로 설명합니다. 요구사항 분석, 설계, 구현, 테스트, 유지보수에 대한 단계에 대해 간략하게 설명합니다.

1. 개발 프로세스 Briefing
(Waterfall Model)
마크베이스

2. SWEBOK
From www.swebok.org

3. Requirement

4. Requirement : Issues
• 현실적 문제 : 현실적으로 투자하기 힘듦
• 긴급한 개발 및 Ad Hoc 요구 사항
• Role & Responsibility confliction
• Who is the major decision maker?
• Market forecasting?
•  아직 초기 단계, 시간과 노력, 투자 필요

5. Requirement Mgmt
• 누가?
• Product Manager를 보유한 조직
• 그 역할과 수행 방식이 조직의 성숙도와 관련
• 언제?
• About Product Manager Group (CTO, PM, PGM, AK)
• 시스템 

6. Design

7. Interface Design : Issues
• 인터페이스를 결정하는 주체는 누구인가?
• 그 결정이 정확한지 어떻게 판단하나?
• 실제로 내용의 혼용
• 설계 이후 변경에 대한 형상관리
• Product Manager
• Tech + Market
• 한국에서는 생소한 개념

8. Interface Design
• 사용자 관점에서 인터페이스 설계
• SQL Specification
• User API (CLI, ODBC, ADO.NET)
• Server Usability
• Message
• 이 문서가 사용자 매뉴얼에 대한 기반 자료로 활용
• 기술적인 Survey (Feasibility 테스트)
• Review
• Senior 개발자에 의해서 반드시 리뷰되어야 함.
• 일관성, 변경 범위, 고객 요구사항과의 매칭
• 다양한 관점에서 제품의 완성도를 높일 수 있게 함.
• 테스트 설계 시작

9. Detail Design : Issue
• Drill Down Level Problem
• 개발자 마다 깊이가 다름
• 문서의 형태와 순서가 다를 수 있음.
• 형상 관리 문제 : 구현시 설계 Defect 발생 
Document Feedback?

10. Detail Design
• 문서를 통해 실제 구현 단계까지 고려
• 제품의 전 영역에 영향을 미치는 부분까지 세밀하게
• SQL 기능 추가?
• SQL Spec 매뉴얼
• Embedded SQL Spec 변경
• ODBC, CLI, ADO.NET, JDBC, CDBC …
• Protocol? Replication? GUI Admin Tool
• 리뷰 필요 (Architect, Senior Developer)
• 아키텍쳐 관점, 복잡도 관점, 알고리즘 등등..
• 테스트 설계 및 수정

11. Construction
(Implementation)

12. Implementation : Issue
• 가장 섬세하고, 중요하다고 여겨지는 단계
• 자칫, 구현단계에 편향될 가능성이 높음.
• But, 모든 단계가 공평하게 중요하다는 관점 필요
• Bug Injection 이 가장 많이 발생.
• 시스템화를 통한 표준화가 핵심!
• 소스코드의 가독성, 유지 보수성, 독립성

13. Implementation
• 가장 복잡하고, 다양한 Activity
• 개발 가이드 라인
• 호환성, 변경 가능성, 성능
• 코딩 규약
• nbasis
• Error handling
• Coding convention
• 리뷰 시스템
• 테스트 구현
• 테스트 시나리오의 실제 구현 단계

14. Testing

15. Testing : Issue
• 누가 할 것인가?
• 테스터(QA Staff)
• 언제 할 것인가?
• 어떻게 할 것인가?
• But,
• 개발 프로젝트에 대한 이해
• 테스터의 역량 부족
• 테스터 자체의 업무 선호도
• 개발자와 테스터를 분리하는 작업 진행중.
• 최적의 비율은?  1:1 vs 5:1

16. Testing
• 품질 본부 산하 QC 조직을 통해 프로젝트 테스팅
• 개발자와 테스터의 분리 개념 도입
• 현실적인 문제와 이상과의 괴리를 좁히기 위한 노력
• 오라클의 경우 개발자와 테스터의 조직이 명확히
분리
• MS의 경우 1:1 의 비율로 유지, 타이틀도 개발자로
명명
• SUN의 경우 프로젝트 재무성과에 따라 1:1에서 10:1
까지 동적으로 부여
• 우리는 어떻게 발전시켜 나가야 하나?

17. Release
Management

18. Release Mgmt
• 정식 릴리즈 (12~24개월)
• Major Upgrade (v1, v2, v3…)
• 메이저 릴리즈 (3~6 개월)
• Minor Upgrade (2.0, 2.1, 2.5…)
• 패치 릴리즈 (2~4 주)
• Minor Upgrade (2.1.1, 2.5.1, 2.5.2…)
• 제대로 릴리즈를 하기 위해 별도의 조직이 필요한가?
• Yes!
• 비전문화된 형태로 Ad Hoc Release
• 국내에서 아직 세분화되지 않은 영역!

19. Maintenance

20. 유지/보수
• 가장 힘들고, 지난한 작업이자, 가장 중요한 작업 중의
하나
• 제품의 품질과 밀접하게 연관
• 유지보수 프로세스 필요
• 유지 보수 정책의 필요성
• 제품 개발 측면의 유지보수
• 고객 지원 관점에서 유지보수
• CDR Review (Critical Design Review)
• 기반 정책에 부합하지 않은 요구 사항에 대한 의사
결정 프로세스
• 예) 2.0 에 LSM 인덱스를 넣어달라…