[ 정보처리기사 ] 1장 - 소프트웨어 생명 주기 정리

 

소프트웨어 생명 주기 

• 소프트웨어를 개발하기 위한 과정을 각 단계별로 나눈 것
• ex ) 폭포수 모형, 프로토타입 모형, 나선형 모형, 애자일 모형

 

폭포수 모형 ( Waterfall Model )

• 한 단계가 완전히 끝나야만 다음 단계로 넘어가는 개발 방법론 => 다음 단계 수행을 위한 결과물 명확히 산출
• 가장 오래된 전통적인 소프트웨어 생명 주기 모형 => 모형을 적용한 경험, 성공 사례 많음.

 

프로토타입 모형 ( Prototype Model, 원형 모형 )

• 폭포수 모형은 폭포가 떨어지는 것처럼 한번 떨어지면 다시 돌아갈 수 없지만, 프로토타입은 돌아갈 수 있음.
• 모델하우스를 통해 미리 집을 볼 수 있듯이, 견본품을 만들어 최종 결과물을 예측하는 모형
• 견본품을 통해 사용자의 요구사항 파악 가능

 

나선형 모형 ( Spiral Model, 점진적 모형 )

• 많은 기능이 있는 대규모 프로젝트의 경우 한번의 프로토타입만으로는 힘들어서 나온 모형
• 나선을 돌듯 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 개발하는 모형
• 보헴(Boehm) 이 제안
• 폭포수 모형, 프로토타입 장점 + 위험 분석 기능 추가
• 별도의 유지보수 과정 필요 X

 

https://itwiki.kr/w/%EB%82%98%EC%84%A0%ED%98%95_%EB%AA%A8%EB%8D%B8

 

애자일 모형 (  Agile Model )

• 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발하는 모형
• 좋은 것을 빠르고 낭비 없게 만들기 위해 고객과의 소통에 초점을 맞춘 방법론
• 폭포수와 대조 ( 고객의 평가 적극 수용, 이전 단계로 돌아갈 수 있음)
• 개인과 상호작용, 실행되는 SW, 고객과 협업, 변화에 반응에 더 가치를 둠
• ex) 기스XL칸 ( 기능 중심 개발(FDD), 스크럼, XP, Lean, 칸반)

 

애자일 모형  -  스크럼 ( Scrum ) 

• 팀이 중심이 되어 개발의 효율성을 높이는 기법
• 백로그 (Backlog) : 제품 개발에 필요한 요구사항을 모두 모아 우선순위를 부여해 놓은 목록

구성원	역할
제품 책임자 (PO, Product Owner)	- 이해관계자들 중 개발될 제품에 대한 이해도가 높고, 요구사항을 책임지고 결정하는 사람 - 백로그를 작성하는 주체
스크럼 마스터  (SM, Scrum Master)	스크럼을 잘 수행할 수 있도록 가이드 역할 수행
개발팀 (DT, Development Team)	제품책임자, 스크럼 마스터 제외한 모든 팀원

• 스프린트 계획 회의 -> 스프린트 -> 일일 스크럼 회의 -> 스프린트 검토 회의 -> 스프린트 회고

https://jinhojapan.tistory.com/72

 

 

애자일 모형  -  XP ( eXtreme Programming )

• 고객 요구사항 유연하게 대응 -> 고객의 참여와 개발 과정의 반복 극대화하여 개발 생산성 향상시키는 방법 
• 짧고 반복적 개발 주기, 단순한 설계 (고객들이 알 수 있도록)
• 피존의 용기 단순(암기방법) - 의사소통(Communication), 단순성(Simplicity), 용기(Courage), 존중(Respect), 피드백(Feedback)
• 릴리즈 ( Release ) : 부분적으로 기능 완료된 제품 제공하는 것
• XP 개발 프로세스 : 릴리즈 계획 수립 -> 이터레이션 -> 승인 검사 -> 소규모 릴리즈 

http://blog.skby.net/xp-extreme-programming/

 

• XP 주요 실천 방법

실천 방법	내용
Pair Programming (짝 프로그래밍)	다른 사람과 프로그래밍 함께 수행, 책임 공동으로 나눠 갖음
Collective Ownership (공동 코드 소유)	개발 코드 권한 책임 공동 소유
Test-Driven Development (테스트 주도 개발)	코드 작성 전 테스트 케이스 먼저 작성 -> 자신이 무엇 할지 파악
Whole Team (전체 팀)	개발 참여 모든 구성원들 각자 역할과 역할에 대한 책임 존재
Continuous Integragion (계속적인 통합)	모듈 단위로 나눠서 개발 -> 지속적 통합
Refactoring (리팩토링)	프로그램 단순화, 유연성 강화 위해 프로그램 기능 변경 없이 재구성
Small Release ( 소규모 릴리즈 )	릴리즈 기간 짧게 반복 -> 고객 반응 신속 대응

 

소프트웨어 공학

• 위기를 극복하기 위한 방안으로 연구된 학문
• 기본 원칙 - 현대기술 계속 적용, 품질 지속적 검증, 명확한 기록 유지