ݺߣ

ݺߣShare a Scribd company logo

04 워터폴모델-개발프로세스

•
•
Andrew Sungjin Kim
Andrew Sungjin Kim

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

1 of 20
Download to read offline
개발 프로세스 Briefing (Waterfall Model) 마크베이스
SWEBOK From www.swebok.org
Requirement
Requirement : Issues • 현실적 문제 : 현실적으로 투자하기 힘듦 • 긴급한 개발 및 Ad Hoc 요구 사항 • Role & Responsibility confliction • Who is the major decision maker? • Market forecasting? •  아직 초기 단계, 시간과 노력, 투자 필요
Requirement Mgmt • 누가? • Product Manager를 보유한 조직 • 그 역할과 수행 방식이 조직의 성숙도와 관련 • 언제? • About Product Manager Group (CTO, PM, PGM, AK) • 시스템 
Design
Interface Design : Issues • 인터페이스를 결정하는 주체는 누구인가? • 그 결정이 정확한지 어떻게 판단하나? • 실제로 내용의 혼용 • 설계 이후 변경에 대한 형상관리 • Product Manager • Tech + Market • 한국에서는 생소한 개념
Interface Design • 사용자 관점에서 인터페이스 설계 • SQL Specification • User API (CLI, ODBC, ADO.NET) • Server Usability • Message • 이 문서가 사용자 매뉴얼에 대한 기반 자료로 활용 • 기술적인 Survey (Feasibility 테스트) • Review • Senior 개발자에 의해서 반드시 리뷰되어야 함. • 일관성, 변경 범위, 고객 요구사항과의 매칭 • 다양한 관점에서 제품의 완성도를 높일 수 있게 함. • 테스트 설계 시작
Detail Design : Issue • Drill Down Level Problem • 개발자 마다 깊이가 다름 • 문서의 형태와 순서가 다를 수 있음. • 형상 관리 문제 : 구현시 설계 Defect 발생  Document Feedback?
Detail Design • 문서를 통해 실제 구현 단계까지 고려 • 제품의 전 영역에 영향을 미치는 부분까지 세밀하게 • SQL 기능 추가? • SQL Spec 매뉴얼 • Embedded SQL Spec 변경 • ODBC, CLI, ADO.NET, JDBC, CDBC … • Protocol? Replication? GUI Admin Tool • 리뷰 필요 (Architect, Senior Developer) • 아키텍쳐 관점, 복잡도 관점, 알고리즘 등등.. • 테스트 설계 및 수정
Construction (Implementation)
Implementation : Issue • 가장 섬세하고, 중요하다고 여겨지는 단계 • 자칫, 구현단계에 편향될 가능성이 높음. • But, 모든 단계가 공평하게 중요하다는 관점 필요 • Bug Injection 이 가장 많이 발생. • 시스템화를 통한 표준화가 핵심! • 소스코드의 가독성, 유지 보수성, 독립성
Implementation • 가장 복잡하고, 다양한 Activity • 개발 가이드 라인 • 호환성, 변경 가능성, 성능 • 코딩 규약 • nbasis • Error handling • Coding convention • 리뷰 시스템 • 테스트 구현 • 테스트 시나리오의 실제 구현 단계
Testing
Testing : Issue • 누가 할 것인가? • 테스터(QA Staff) • 언제 할 것인가? • 어떻게 할 것인가? • But, • 개발 프로젝트에 대한 이해 • 테스터의 역량 부족 • 테스터 자체의 업무 선호도 • 개발자와 테스터를 분리하는 작업 진행중. • 최적의 비율은?  1:1 vs 5:1
Testing • 품질 본부 산하 QC 조직을 통해 프로젝트 테스팅 • 개발자와 테스터의 분리 개념 도입 • 현실적인 문제와 이상과의 괴리를 좁히기 위한 노력 • 오라클의 경우 개발자와 테스터의 조직이 명확히 분리 • MS의 경우 1:1 의 비율로 유지, 타이틀도 개발자로 명명 • SUN의 경우 프로젝트 재무성과에 따라 1:1에서 10:1 까지 동적으로 부여 • 우리는 어떻게 발전시켜 나가야 하나?
Release Management
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 • 국내에서 아직 세분화되지 않은 영역!
Maintenance
유지/보수 • 가장 힘들고, 지난한 작업이자, 가장 중요한 작업 중의 하나 • 제품의 품질과 밀접하게 연관 • 유지보수 프로세스 필요 • 유지 보수 정책의 필요성 • 제품 개발 측면의 유지보수 • 고객 지원 관점에서 유지보수 • CDR Review (Critical Design Review) • 기반 정책에 부합하지 않은 요구 사항에 대한 의사 결정 프로세스 • 예) 2.0 에 LSM 인덱스를 넣어달라…

More Related Content

04 워터폴모델-개발프로세스

  • 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) • 시스템 
  • 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) • 아키텍쳐 관점, 복잡도 관점, 알고리즘 등등.. • 테스트 설계 및 수정
  • 12. Implementation : Issue • 가장 섬세하고, 중요하다고 여겨지는 단계 • 자칫, 구현단계에 편향될 가능성이 높음. • But, 모든 단계가 공평하게 중요하다는 관점 필요 • Bug Injection 이 가장 많이 발생. • 시스템화를 통한 표준화가 핵심! • 소스코드의 가독성, 유지 보수성, 독립성
  • 13. Implementation • 가장 복잡하고, 다양한 Activity • 개발 가이드 라인 • 호환성, 변경 가능성, 성능 • 코딩 규약 • nbasis • Error handling • Coding convention • 리뷰 시스템 • 테스트 구현 • 테스트 시나리오의 실제 구현 단계
  • 15. Testing : Issue • 누가 할 것인가? • 테스터(QA Staff) • 언제 할 것인가? • 어떻게 할 것인가? • But, • 개발 프로젝트에 대한 이해 • 테스터의 역량 부족 • 테스터 자체의 업무 선호도 • 개발자와 테스터를 분리하는 작업 진행중. • 최적의 비율은?  1:1 vs 5:1
  • 16. Testing • 품질 본부 산하 QC 조직을 통해 프로젝트 테스팅 • 개발자와 테스터의 분리 개념 도입 • 현실적인 문제와 이상과의 괴리를 좁히기 위한 노력 • 오라클의 경우 개발자와 테스터의 조직이 명확히 분리 • MS의 경우 1:1 의 비율로 유지, 타이틀도 개발자로 명명 • SUN의 경우 프로젝트 재무성과에 따라 1:1에서 10:1 까지 동적으로 부여 • 우리는 어떻게 발전시켜 나가야 하나?
  • 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 • 국내에서 아직 세분화되지 않은 영역!
  • 20. 유지/보수 • 가장 힘들고, 지난한 작업이자, 가장 중요한 작업 중의 하나 • 제품의 품질과 밀접하게 연관 • 유지보수 프로세스 필요 • 유지 보수 정책의 필요성 • 제품 개발 측면의 유지보수 • 고객 지원 관점에서 유지보수 • CDR Review (Critical Design Review) • 기반 정책에 부합하지 않은 요구 사항에 대한 의사 결정 프로세스 • 예) 2.0 에 LSM 인덱스를 넣어달라…