1. 폭포수 모형
- Waterfall Model
- 소프트웨어 생명 주기(Software Life Cycle) 모형의 하나
- 가장 오래되고 폭넓게 사용
- 한 단계가 완전히 끝나야 다음 단계로 넘어감
2. 애자일 모형
- Agile Model
- 고객의 다양한 요구사항의 변화에 유연하게 대응
- 일정 주기를 반복
| 비교 | 폭포수 | 애자일 |
|---|
| 새로운 요구사항 반영 | 어려움 | 지속적 반영 가능 |
| 고객과의 의사소통 | 적음 | 지속적으로 가능 |
| 테스트 진행시기 | 마지막 단계 | 일정주기 끝날 때 |
| 개발시 | 계획, 매뉴얼 중심 | 고객 중심 |
3. 나선형 모형
- Spiral Model(점진적 모형)
- 나선을 따라 돌듯이 소프트웨어 개발 과정을 여러 번 반복
- 누락되거나 추가된 요구사항을 첨가 가능
- 위험 분석 기능을 추가
4. 스크럼
- Scrum
- 럭비에서 양 팀이 대치해 있는 대형
- 개발에서 팀의 중요성 강조
- 스크럼 팀의 구성원 및 역할
- 제품 책임자(PO; Product Owner): 백로그(Backlog) 작성
- 스크럼 마스터(SM; Scrum Master): 일일 스크럼 회의(Daily Scrum Meeting) 주관
- 개발팀(DT; Development Team): 제품 책임자와 스크럼 마스터를 제외한 팀원
- 스크럼 개발 과정 순서
1. 제품 백로그(Product Backlog): 개발에 필요한 요구사항(User Story)에 우선순위를 부여한 목록 작성 후 업데이트
2. 스프린트 계획 회의(Sprint Planning Meeting): 백로그 중 처리할 User Story를 개발자별로 나눠 스프린트 백로그(Sprint Backlog) 작성
3. 스프린트(Spring): 2-4주 정도 기간으로 실제 개발 진행
4. 일일 스크럼 회의(Daily Scrum Meeting): 매일 15분 정도 진행 상황하며 남은 작업시간을 소멸 차트(Burn-down Chart)에 표시
5. 스프린트 검토 회의(Sprint Review): 주당 1시간 내로 제품 요구사항에 부합되는지 테스팅하고 제품 책임자(PO)가 백로드 업데이트
6. 스프린트 회고(Sprint Retrospective): 규칙 준수했는지, 개선점 없는지 등 확인하고 기록
5. XP(eXtreme Programming)
- 일부 기능 완성될 때마다 고객 앞에서 테스팅하고 반응 확인하는 과정을 최종 제품 완성시까지 지속 반복
- 릴리즈(Release)를 소규모로 반복하여 고객 요구사항 반영 여부에 대한 가시성(Visibility)을 높임
- XP 개발 과정 순서
1. 사용자 스토리(User Story): 고객의 요구사항을 기능 단위로 표현
2. 릴리즈 계획 수립(Release Planning): 몇 개의 스토리가 적용된 제품 제공 일정 수립
2.1. 스파이크(Spike): 신뢰성 높이고 기술 문제 위험 감소를 위해 별도로 만드는 프로그램
3. 이터레이션(Iteration): 릴리즈를 더 세분화하여 1~3주 정도 기간으로 진행하며 새로운 스토리 작성 가능
4. 승인 검사(Acceptance Test): 사용자 스토리 단계에서 작성한 테스트 사항(Test Case)을 고객이 수행하고 완료되면 다음 이터레이션 진행
5. 소규모 릴리즈(Small Release): 릴리즈가 최종 완제품이 아니면 다음 릴리즈 일정에 맞춰 개발 진행
6. 기능 요구사항
- Functional requirements
- 시스템의 기능에 관한 요구사항
- 시스템의 입출력, 데이터 저장이나 연산 등 사용자가 제공받기 원하고 시스템이 반드시 수행해야하는 기능
7. 비기능 요구사항
- Non-functional requirements
- 시스템의 품질이나 제약조건 등에 관한 요구사항
- 장비 구성(하드웨어, 소프트웨어, 네트워크 등)
- 성능(처리 속도, 처리량, 적용량, 가용성 등)
- 인터페이스
- 데이터 구축
- 성능 테스트 혹은 시스템 운영 점검
- 보안
8. 프로토타이핑
- Prototyping
- 문서화된 요구사항 명세서를 최종적으로 확인하는 기법
- 초기 도출된 요구사항을 바탕으로 프로토타입(Prototype)을 만든 후 개발 과정에서 새롭게 도출된 요구사항을 반영하여 지속적으로 재작성
- 장점
- 빠른 제작 가능
- 반복에 따라 프로토타입 개선되고 요구사항 감소
- 쉬운 이해로 사용자와 개발자 간 소통 원활
- 최종완성 전 요구사항 등에 대한 피드백 가능
- 최종완성 전 문제점 식별 가능
- 단점
- 프로토타입에만 관심 집중되어 대상 범위 잘못 이해 우려
- 반복된 프로토타이핑으로 비용 증가 우려
9. UML
- Unified Modeling Language
- 시스템 개발시 공통된 모델링 언어를 만들어 개발 대상물을 다이어그램으로 표현
- 사물(Things): 우리 주위의 개체(Entity)를 컴퓨터 내에서 추상적으로 표현한 것
- 구조 사물(Structural Things)
- 행동 사물(Behavioral Things)
- 그룹 사물(Grouping Things)
- 주해 사물(Annotation Things)
- 관계(Relationships): 사물과 사물 간의 연관성
- 연관(Association): 두 개 이상의 사물이 서로 관계
- 실선으로 연결하고 일방향 관계는 화살표로 표현
- 객체 수(1, n, 0..1, 0.., , 1.., n.., n..m)를 의미하는 다중도(Multiplicity)를 선 위에 표현
- 집합(Aggregation): 서로 독립적인 사물이 다른 사물에 포함
- 포함되는 쪽(Part)에서 포함하는 쪽(Whole)으로 빈 마름모 연결
- 포함(Composition): 서로 독립적이지 않은 사물이 다른 사물에 포함
- 포함되는 쪽에서 포함하는 쪽으로 속이 찬 마름모 연결
- 일반화(Generalization): 구체적인 사물과 일반적인 사물의 관계
- 구체적인 사물에서 일반적인 사물 쪽으로 빈 화살표 연결
- 일반적인 사물이 상위(부모), 구체적인 사물이 하위(자식)
- 의존(Dependency): 짧은 시간만 영향 주고받음
- 영향 주는 사물(이용자)이 받는 사물(제공자) 쪽으로 점선 화살표
- 실체화(Realization): 할 수 있거나 해야 하는 기능(인터페이스)를 그룹화 가능
- 사물에서 기능 쪽으로 빈 점선 화살표
10. UML 다이어그램
- 사물과 관계를 도형으로 표현
- 구조적(Structural) 다이어그램
- 클래스(Class)
- 객체(Object)
- 컴포넌트(Component)
- 배치(Deployment)
- 복합체 구조(Composite Structure)
- 패키지(Package)
- 행위(Behavioral) 다이어그램
- 유스케이스(Use Case)
- 시퀀스(Sequence)
- 커뮤니케이션(Communication)
- 상태(State)
- 활동(Activity)
- 상호작용 개요(Interaction Overview)
- 타이밍(Timing)
