반응형
1. 전통적인 소프트웨어 개발 단계 이해
전통적인 소프트웨어 프로세스 정형화
- SI(System Integration) 업계에서 적합하며, 배 만드는 작업과 유사함
- 소프트웨어 개발 관련자: 요청 고객(Client), 사용자(Customer), 프로젝트 관리자(PM), 개발자(Developer)
전통적인 소프트웨어 개발 생명주기(Life Cycle)
요구사항(Business Requirements)
- Customer Pain Points(WHY/문제점) + Scope(범위) + Benefit(얻을 수 있는 이익)
- 쇼핑몰을 예시로 들면
고객이 상품을 찾을 수 없어 구매를 못하는 것이 Pain Point일 때 전체 상품 검색 기능을 추가하는 것이 Scope이고,
이로 인해 고객 경험을 증대시키고 매출을 향상시킬 수 있다는 것이 Benefit
요구 명세+요구 분석(Requirements)
- 실제로 구현하라면 매우 상세한 기능 분석이 필요한데, 이 기능이 원하는 기능이 맞는지 명확히 확인할 필요가 있음
- 쇼핑몰을 예시로 상단에 검색창 제공 기능을 추가한다고 할 때,
상품 타이틀/상품 제공자/전체 검색 기능 및 옵션을 제공하며 검색 시간은 1초 내외 응답시간을 유지한다고 정의 - 상세하게 만들고 고객 컨펌을 받는 방법
- 요구사항 유도: 요청자와의 토의로 요구사항 구체화
- 요구사항 분석: 구체화한 요구사항을 명확하게 만드는 작업 진행
- 요구사항 기록: 요구사항을 문서화하여 요청자에게 확인을 받음
- 필요하다면, 항목별로 요구사항을 세분화
- 1) 기능적 요구 사항(Functinal Reqs)
- 2) 시스템 요구 사항(System Reqs)
- 3) 품질 테스트 요구 사항(Quality Reqs)
- 4) 외부(시스템) 요구 사항(External Reqs)
- 5) 제약 사항(Constraints)
설계(Design) - 세부적으로 구현 레벨로 설계하며, 절차지향과 객체지향으로 나뉨
- 절차지향: 구조도/협력도/데이터 흐름도를 그려 설계함
- 객체지향: UseCase Diagram/Class Diagram/Sequence Diagram을 그려 설계함
구현(Implementation)
- Project Management로 각 구현/테스트 단계 세분화(요구사항 분석~출시까지 전체 관리하기도 함)
테스트(Implementatiion)
- QA라고 하며, 소프트웨어 버그를 확인하는 과정을 의미
배포/납품(Release)
- 테스트 단계에서 완벽한 버전을 수차례 확인한 후 공식 릴리즈
- Pre-alpha: 핵심 기능이 동작하기 시작한 상태
- Alpha: 소프트웨어 테스트 단계
- Beta: 외부에 테스트 단계로 명시해서 오픈한 후 내외부 테스트 진행
- RC(Release Candidate): 정식 릴리즈 후보
- Official Release: 고객이 사용하는 완벽한 버전
유지보수(Maintenance)
- 배포/납품 후 운영에 많은 비용이 들며, 프로그램 유지보수 및 추가 요구사항 반영이 필요함
- 전체 개발 프로세스에서 30%의 비중을 차지함
2. 전통적인 개발 프로세스 이해
개발 방법론 - 폭포수 모델
- 완벽하게 설계해서, 완벽하게 개발 가능한 기간까지 예측
- 개발 일정은 항상 늦어지며, 개발하는 동안 고객의 상황이 변해서 추가 요구사항이 생기게 됨
개발 방법론 - 프로토타입 모델(Prototype model)
- 고객이 원하는 핵심 기능만 만들어서 보여준 후, 고객이 원하는 기능이 맞다면 제대로 개발 시작
개발 방법론 - 나선형 모델(Spiral model)
- 개발 시 위험을 최소화하기 위해, 점진적으로 단계를 반복적으로 수행하며 완벽한 프로그램을 개발해 나감
반응형