소프트웨어 생명 주기 모델

소프트웨어 생명 주기

소프트웨어 개발 방법론의 바탕이 되는 것으로. 개발 과정을 단계별로 나눈 것

단계별 결과에 대한 산출물로 표현 가능

생명 주기, 소프트웨어 공학 패러다임 이라고도 한다.

 

폭포수 모델

개발 이전 단계로 돌아갈 수 없다. - 확실히 매듭을 짓는다.

개발 과정의 한 단계가 끝나야만 다음 단계로 넘어갈 수 있다.

메뉴얼 작성이 필요하다.

단계별 결과물이 명확하게 산출 되어야함.

 

 

프로토타입 모델

폭포수 모형의 단점을 보완한 모델이다. (이전으로 돌아갈 수 없다)

견본품을 만들어 결과물을 예측한다.

 

 

나선형 모델

폭포수와 프로토타입의 장점에 위험 분석 기능을 추가했다.

결함을 관리하여 최소화하는 것을 목적으로 한다.

유지보수 과정이 필요없다.

 

 

애자일 모델

유연하게 대응할 수 있도록 일정 주기를 반복

고객과의 소통에 초점을 맞춘 방법론

 

핵심 가치 - 유연함

• 절차보다 상호작용
• 문서보다는 소프트웨어 자체
• 계약 내용보다는 고객과의 협업
• 계획을 따르기보다는 변화에 대응

 

 

스크럼 모델

팀을 중심으로 개발 진행

스크럼의 가치: 확약, 전념, 정직, 존중, 용기

 

스크럼 모델의 구성

 

제품 책임자

- 요구사항을 책임지고 의사를 결정

- 백로그에 스토리를 작성하고 우선순위를 지정, 갱신

 

스크럼 마스터

- 팀이 개발을 잘 수행하도록 가이드 역할

- 일일 스크럼 회의를 주관하고 발생된 장애 요소를 처리

 

개발 팀

- PO와 SM을 제외한 개발자 및 디자이너등 모든 팀원

 

 

개발 프로세스

 

제품 백로그

- 요구사항을 우선순위에 따라 나열한 목록

 

스프린트 계획 회의

- 스프린트에서 수행할 작업을 대상으로 짧은 일정을 수립

- 개발자들이 나눠서 작업할 수 있도록 작업을 분리한 후 스프린트 백로그를 작성한다.

 

스프린트

- 실제 개발을 2~4주간 진행

- Task를 대상으로 작업시간을 측정한 후 담당개발자에게 할당

- Task는 할일, 진행중, 완료의 상태로 구분

 

일일 스크럼 회의

- 모든 팀원이 15분정도의 짧은 시간동안 소멸차트를 통해 진행도 점검

- SM는 회의에서 발견된 장애요소를 해결하도록 도움

 

 

스프린트 검토 회의

- 참여인원 앞에서 부분 또는 완성된 제품을 테스트

- PO는 개선사항에 대한 피드백, 제품 백로그

 

스프린트 회고

- 규칙을 준수했는지, 개선점은 없었는지 확인

- 스프린트가 끝난 시점이나 일정 주기를 정하여 수행

 

 

XP 모델

고객의 참여와 개발을 극대화

짧고 반복적인 개발 주기

XP의 가치 : 의사소통, 단순성, 용기, 존중, 피드백

 

개발 프로세스

사용자 스토리

- 고객의 요구사항을 기능 단위로 구성

 

릴리즈 계획 수립

- 기능이 완성된 제품을 제공하는 것

 

스파이크

- 기술 문제를 해결하고자 별도로 제작하는 간단한 프로그램

 

이터레이션

릴리즈를 세분화한 단위

1~3주의 기간을 가짐

 

승인 검사

릴리즈 단위의 부분 완료 제품이 구현되는 테스트

사용자 스토리에 기재된 테스트 항목에 대해 고객이 테스트

 

소규모 릴리즈

 

XP의 기본 원리 12가지

01. Planning game (= Planning process)	User story를 이용해서 next release의 범위를 빠르게 결정, 비즈니스 우선순위와 기술적 평가가 결합
02. Small/short releases	필요한 기능들만 갖춘 간단한 시스템을 빠르게 프러덕션화 함, 아주 짧은(2주) 사이클로 자주 새로운 버전 배포
03. Metaphor	공통의 name system(개발 및 커뮤니케이션 과정에서 공통된 개념을 공유 가능하게 함)
04. Simple design 단순성	현재의 요구사항을 만족시키도록 가능한 한 단순하게 설계함
05. Testing	개발자 먼저 단위 테스트, 고객은 기능 테스트를 작성하여 요구사항이 모두 반영되었는지를 확인
06. Refactoring	프로그램의 기능을 바꾸지 안으면서, 중복제거, 커뮤니케이션 향상, 단순화, 유연성 추가 등을 위해 시스템 재구성
07.Pair programming	하나의 컴퓨터에 두 사람이 앉아서 같이 프로그램 함 (Driver / partner)
08. Collective ownership	시스템에 있는 코드는 누구든지 언제라도 수정 가능함
09. CI(Continuous integration)	하루에 몇 번이라도 시스템을 통합하여 빌드 할 수 있음
10. 40-hour week	일주일에 40 시간 이상을 일하지 말도록 규칙으로 정하고 2주를 연속으로 오버 타임 하지 않도록 함
11. On-site customer	개발자들의 질문에 즉각 대답해 줄 수 있는 고객을 프로젝트에 풀 타임으로 상주시킴
12. Coding standards	팀원들 간 커뮤니케이션을 향상시키기 위해서는 코드가 표준화된 관례에 따라 작성되어야 함

 

 

프로젝트 관리

사업 목적에 맞게 미리 계획된 일정과 비용 범위에서 목적을 달성하기 위한 모든 활동

정해진 시간안에 단계적으로 진행

업무마다 프로젝트 개발 방법이 다르다.

 

프로젝트 관리의 종류

일정 관리

예산 관리

인력 관리

위험 관리

품질 관리

프로젝트 관리의 3P : 사람, 문제, 절차

 

프로젝트 계획 수립

소프트웨어 영역 측정

처리 기능	소프트웨어 기능의 범위 측정
성능	소프트웨어 처리 속도 동시 접속자 수 등 측정
제한 조건	소프트웨어의 한계 등의 제약 조건 측정
개발 인원	개발 인력 수
일정 계획	기간, 작업 시간, 단계별 측정

자원 측정

하드웨어 자원	개발자 시스템, 사용자 시스템, 개발 자원 시스템 파악
소프트웨어 자원	프로그램 작성 도구, CASE 등 파악
인적 자원	개발 조직, 팀 구성, 프로그래밍 능력 파악

 

인적 자원

• 책임 프로그래머 팀
  • 단기적인 소규모
  • 이직률이 높다
  • 1인 독재 체제
• 민주주의식 팀
  • 장기적인 대규모 프로젝트에 유리
  • 팀원 대다수의 만족도가 높아 이직률이 낮음
  • 수평식 링형 구조