2.1 Software Process
: 과정을 잘 정의된 task로 나누고 순서를 정한 것
No software process
- 코딩 - 픽스의 반복
Software process 범위
1) software development process : 직접적으로 개발과 연관되어 있는 task에 관련된 절차
2) support process : 간접적으로 개발을 도와주는 task에 관련된 절차
Software development process
= Software development model
= Software development life cycle (SDLC)
: 소프트웨어 개발에 직접 관여하는 활동 혹은 절차
개발 절차가 필요한 이유
- (이론적으로) 정해진 절차를 따라 개발하면 일정 이상의 품질 보장
- 각 단계 사이 평가 기준이 존재하여 진행 상황 판단
Software Activities
1) 요구사항 분석 (Requirement engineering)
- 추출
- 분석
- 명세
- 검증
- 변경 추적 관리
2) 설계 (Design)
- 아키텍쳐
- 인터페이스
- 모듈 상세 설계
- 사용자 인터페이스
- 데이터베이스
3) 구현 (Implemenntation)
- 쉽게 이해하고 사용하도록
- 계획되지 않은 변경에 대비
- 테스트하기 쉬운 구조
- 표준 규격 (있는 경우에는 맞춰서)
4) 검증 (Verification & Validation)
- Verification : 설계한 명세(system description)를 만족하는지
- Validation : 고객의 요구사항에(custom wants) 만족하는지
5) 유지/보수 (Maintecance)
- 오류 수정
- 새 기능 추가
- 새로운 환경에 인식
2.2 Good(좋은) 소프트웨어의 특성
1) Predictability (예측 가능성) : 동일한 절차를 따라 수행했을 때 이전 프로젝트의 비용, 품질 등 데이터를 참조하면 새로 진행할 프로젝트에 대해 예측이 가능하다.
2) 테스트, 유지보수가 쉽다. -> 비용이 많이 드는 단계
3) 계획하지 않았던 변화에 잘 대응할 수 있다. (주기적인 feedback)
4) 오류를 수정하는 데 적은 비용이 든다. - 후반부로 갈수록 버그 수정에 필요한 비용이 늘어남
2.3 소프트웨어 개발 모델
1. Plan-and-documentation model
⭐️ 특징
1) The waterfall model : 전통적, one-shot
2) Rapid prototyping model : 계속 유저에게 피드백 받기
3) The evolution model : 계속 유저에게 피드백 받기
4) The spiral model : 위험 분석 위주로
5) The V model : 많은 테스팅이 필요한 경우 - 고위험 환경에서 사용되는
6) The unified process : waterfall model + 반복적으로 진행
=> waterfall model 과 변형 모델
2. 단기 계획 & 문서 작성 최소화
- The Agile process : 고객과의 커뮤니케이션
The Waterfall Model
코딩 전 충분한 시간을 가져 계획을 세우고 고객과 대화하여 요구사항 파악이 핵심
- 다른 모델들의 가장 기본이 되는 모델
- 순차적
- one-shot : 마지막 단계(유지/보수)까지 끝나면 추가적인 절차가 없음
장점 : 절차가 단순명료하여 산출물들이 정확하게 정의가 되어있어 예측이 쉽고, 관리가 명확하다.
=> 미리 계획을 세울 수 있는 도메인에 적용
단점 :
-- 각 단계마다 문서 작업이 필수이기 때문에 코딩시간 대비 문서작성 시간이 더 오래 걸린다.
-- 절차 변화 대응에 유연하지 못한다.
Rapid Prototyping Model
- waterfall 모델의 유연하지 못한 대응을 보완한 모델
- 요구사항 분석 후 프로토타입 개발 후 이를 가지고 고객과 커뮤니케이션을 통해 정확한 요구사항 분석
-- 장점 : 유연한 피드백
-- 단점 :
- 고객의 오해(초기 프로토타입을 최종 결과물로 착각)
- 개발 통제 어려움 (ex. 언제 프로토타입 중지하고 구현으로 넘어갈 지에 대한 기준)
Evolutionary Model
- 최소한의 기능이 완성되면 사용자에게 제공 -> 고객에게 피드백을 받고 새로운 기능을 추가하여 업데이트
--장점 : 즉각적인 피드백
-- 단점 : 계획 수립의 어려움 - 피드백에 따라 방향이 달라지기 때문에
The Spiral (나선형) Model
- 리스크 분석
- 각 옵션의 위험도를 평가 후 진행
-- 장점 :
- 리스크 분석을 통해 위험을 줄임
- 사이클을 돌기 때문에 변화에 빠른 대응
- 한 사이클이 돌면 소프트웨어 릴리즈 -> 고객 피드백이 가능해짐
-- 단점 :
- 위험 분석이 어려움
- 전체 성공이 위험 분석에 의존적
- 복잡, 고비용
The V Model
- 버그가 발생했을 경우 사람의 목숨, 재산 등에 큰 피해를 줄 수 있는 소프트웨어를 개발할 때 사용하는 모델
- 각각의 개발 단계에 대해서 테스팅이 연관되어 있기 때문에 V model 이라고 불림
The Unified Process
- 반복적으로 개발 (4단계로 나누어)
- use case (사용자 관점에서 소프트웨어 동작 기술) 주도로 개발 진행
- x축: 4단계, y축: waterfall 모델의 단계
- 각각의 단계에서 waterfall 단계 반복하는 형식
각 단계 설명
1) Inception (도입) : 프로젝트나 할 일들의 범위 지정 (명확하지 않으면 프로토타입을 만들기도)
2) Elaboration (설계) : 시스템 아키텍쳐 설계 -> 명확한 구조
3) Construction (구현): 개발 - 릴리즈 - 피드백 반복
4) Transition (전이) : waterfall 모델에서의 마지막 단계들의 활동 비중이 커짐 (최종 산출물 배포 등)
The Agile Process
: 문서보다는 프로그래밍에 초점을 맞추고 고객과의 커뮤니케이션 중요시
특징
1) Individuals and interactions : 팀의 중요성, 고객의 피드백
2) Working software : 실제 동작하는 소프트웨어를 보여주는 방식
3) Customer collaboration : 고객과 협업 하는 방식 (소프트웨어를 보여주고 피드백 받는 식)
4) Responding to change : 최소한의 계획으로 변화에 대응하는 방식
개발 모델을 선택하는 방법
Q. 요구사항을 잘 이해하고 있나요?
A: Yes -> 전통적인 모델
A: No -> 변화에 잘 적응하는 모델 (agile), 경직된 절차를 따르기엔 어려움이 있음
Q. 어떤 리스크가 있나요?
A: 리스크를 충분히 파악하고 있고, 감당 가능 -> 전통적인 모델
A: 리스크가 높고 변경 가능성도 높다 -> agile
Q. 고객과 충분히 많은 소통이 가능한가요?
Q. 프로젝트의 기대되는 주기, 스케줄의 제약성
Q. 개발자들의 전문성
2.4 Umbrella Process
: 간접적으로 개발을 지원하는 프로세스
- 프로젝트 관리에 관련된 프로세스, 프로세스를 관리하는 프로세스, 최종 산출물 (소스코드, 문서) 관리에 대한 프로세스
2.5 Methods and Tools
Agile methods
- Scrum
- XP (extreme programming)
- TDD (test-driven development)
- 테스트케이스를 먼저 만들고 이를 만족하는 함수를 구현하는 방식 - Pair programming
- 두 사람이 같이 프로그래밍 하는 것 - CI (Continuous integration)
-구현이 덜 됐더라도 지속적으로 빌드하여 완성해가는 방식
- TDD (test-driven development)
구조적 분석과 설계 방법
- Data Flow Diagram (DFD)
-plan and documentation model에서 주로 사용
객체지향 분석 설계 방법
- Unified Modeling Language (UML)
-plan and documentation model에서 주로 사용
Scrum
- SW 개발 팀 혹은 팀을 관리하는 방법
- 일정 주기를 가지고 개발 후 고객 피드백 사이클 반복
- 매일 개발 진행 상황 공유
용어
- Scrum : 팀 자체, 팀을 관리하는 방법
- Sprint : SW 개발 주기
- Product backlog : 요구사항 목록 - 고객과 커뮤니케이션 할 때 사용
- Sprint backlog : 현재 진행상황을 보여주는 게시판, 게시물
- Daily scrum : 아침 미팅
- Sprint demo : 한 주기가 끝날 때 고객에게 결과물을 보여주는 것
- Sprint retrospective : 회고 (주도자 : Scrum master)
- Slack time between sprints : 주기 사이의 쉬는시간
