반응형
[정보처리기사-필기] 익스트림 프로그래밍(XP; Extreme Programming)

익스트림 프로그래밍(XP)은 고객 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 기법

 

  1. XP는 짧고 반복적인 개발 주기, 단순한 설계, 고객의 참여를 통해 빠르게 개발하는 것을 목적으로 함
  2. 릴리즈의 기간을 짧게 반복하며 요구 사항 반영에 대한 가시성을 높임
  3. 릴리즈 테스트마다 고객을 참여시켜 요구 기능이 잘 동작하는지 직접 확인 가능
  4. 소규모 인원의 프로젝트에 효과적
  5. XP의 핵심 가치 : 의사 소통, 단순성, 용기, 존중, 피드백
※ 릴리즈 : 요구 사항이 부분적으로 완료된 제품을 제공
※ 가시성 : 일부 기능이 구현될 때 마다 고객에게 제품을 확인시켜주어 잘 반영되고 있음을 확인해준다는 의미

 

 


 

 

익스트림 프로그래밍 개발 프로세스

 

A. 사용자 스토리(User Story)
  • 요구 사항을 간단한 시나리오로 표현
  • 기능 단위로 내용을 작성하며 필요한 경우 간단한 테스트 사항(Test Case)을 기재함

 

B. 릴리즈 계획 수립(Release Planning)
  • 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것 → 스토리의 일부 기능 = 릴리즈(Release)
  • 릴리즈에 대한 일정을 수립하는 단계를 릴리즈 계획 수립이라 함

 

C. 스파이크(Spalike)
  • 불확실한 추정이 있을 경우 별도로 개발하는 간단한 프로그램
    → 기술 문제에 대한 위험을 감소 시킴
  • 불확실한 추정을 제외한 다른 조건은 모두 무시

 

D. 이터레이션(Iteration)
  • 릴리즈를 더 세분화 한 단위이며 일반적으로 1~3주간의 기간으로 진행됨
  • 새로운 스토리 작성 가능
    → 새로 작성된 스토리에는 진행중 또는 다음 이터레이션이 포함될 수 있음

 

E. 승인 검사(Acceptance Test, 인수 테스트)
  • 하나의 이터레이션이 완료 되었을 때, 즉 릴리즈의 일부 기능(이터레이션)이 완료된 제품을 테스트하는 과정
  • 테스트 사항에 대해 고객이 직접 수행
  • 발견된 오류 사항은 다음 이터레이션에 포함됨
  • 테스트 이후 새로운 요구사항 또는 기존에 존재하는 요구사항의 우선순위가 변경될 수 있음
  • 테스트 완료 시 다음 이터레이션 진행

 

F. 소규모 릴리즈(Small Release)
  • 고객 반응을 기능별로 확인 가능하여 요구 사항에 유연하게 대처 가능
  • 릴리즈 기간 동안 이터레이션이 모두 완료되면 고객의 최종 테스트를 수행 후 릴리즈를 고객에게 전달
    → 릴리즈의 일부 기능들(이터레이션)이 모두 완료되면 최종 테스트 후 최종 결과물(릴리즈)을 전달하는 것을 뜻함
  • 릴리즈가 완제품이 아닐 경우 다음 릴리즈 계획에 맞춰 개발 진행

 

 


 

 

 

익스트림 프로그래밍 주요 실천 방법(Practice)






반응형
반응형
[정보처리기사-필기] 스크럼(Scrum) 기법

스크럼은 팀이 중심이 되어 개발의 효율성을 높인다는 의미를 가지고 있습니다. 스크럼은 스스로가 팀을 구성(self-organizing) 할 수 있어야 하며 개발에 관련된 작업들을 스스로 해결(cross-functional)할 수 있어야 하고 제품 책임자(PO), 스크럼 마스터(SM), 개발팀(DT)로 나뉘어 집니다.

 

A. 제품 책임자(PO; Product Owner)

주로 개발 의뢰자 또는 사용자가 담당하며 요구 사항을 결정 및 작성하는 역할을 합니다.

제품 책임자는 백로그(Backlog)를 작성 및 우선순위를 지정하며, 제품의 테스트를 수행하며 요구사항의 우선순위를 지속적으로 갱신하는 업무를 담당합니다. 단, 백로그의 스토리는 팀원이 추가할 수 있지만 우선순위를 갱신할 수는 없습니다.

※ 백로그 : 제품에 대한 요구사항들의 우선 순위를 작성해둔 리스트
※ 스토리 : 백로그에 "고객은 글쓰기를 위해 로그인을 해야한다."와 같이 서술 형태로 표현 

 

B. 스크럼 마스터(SM; Scrum Master)

객관적인 시각에서 조언을 해주는 가이드 역할을 수행하며, 회의를 준관하여 진행 사항 점검/장애 요소 공론화 등을 처리합니다. 

※ 팀원의 통제 목적이 아닌, 스크럼 팀이 스크럼을 잘 수행할 수 있도록 도와주는 역할을 합니다.

 

C. 개발팀(DT; Development Team)

제품 책임자와 스크럼 마스터를 제외한 모든 팀원들을 뜻하며 개발자, 디자이너, 테스트 등 제품을 개발하기 위해 참여하는 모든 사람이 대상이 되어 7~8명으로 구성됩니다.

 

 


 

 

스크럼 개발 프로세스

스크럼의 개발 프로세스는 아래와 같은 내용들로 나누어 집니다.

 

A. 제품 백로그(Product Backlog)
  • 제품의 요구 사항(User Story)을 우선 순위에 따라 작성한 리스트이며 우선 순위는 지속적으로 업데이트
  • 요구 사항을 기반으로 전체 일정 계획(릴리즈 계획)을 수립

 

B. 스프린트 계획 회의(Spring Meeting)
  • 백로그 중 이번 스프린트에서 수행할 작업들을 단기 일정 수립
  • 테스크 작업 단위로 분할하여 각각의 개발자들이 수행할 작업 목록(스프린트 백로그)을 작성
    * 테스크 : 요구사항을 개발자별로 작업할 단위

 

C. 스프린트(Sprint)
  • 개발 작업을 진행하는 과정
  • 스프린트 백로그에 작성된 테스크들의 속도(Velocity)를 추정 후 개발자에게 할당
    * 속도 : 한 번의 스프린트가 진행될 때 하나의 스크럼 팀이 감당할 수 있는 제품 백로그 양의 추정치
  • 테스크는 개발자가 원하는 작업을 직접 선별할 수 있도록 하는것이 좋으며, 할당된 테스크는 할 일(To Do), 진행중(In Progress), 완료(Done) 상태를 가짐

 

D. 일일 스크럼 회의(Daily Scrum Meeting)
  • 매일 진행 상황을 점검하는 회의이며 남은 작업 시간은 소멸 차트에 표시함
  • 스크럼 마스터는 장애 발생 요소를 해결할 수 있도록 도와주는 역할을 수행

 

E. 스프린트 검토 회의(Sprint Review)
  • 요구 사항이 잘 적용 되었는지 사용자 앞에서 테스트를 수행하며 한 주당 한 번 진행
  • 제품 책임자는 개선 사항에 대하여 피드백을 정리하고, 다음 스프린트에 적용될 수 있도록 제품 백로그를 업데이트

 

F. 스프린트 회고(Spring Respective)
  • 스프린트를 되돌아보며 규칙을 잘 준수했는지, 개선할 점이 없는지에 대하여 확인 및 기록
  • 일정 주기 또는 스프린트가 종료된 후 수행

 

 

※ 스크럼 개발 과정 순서
스프린트 계획 회의 → 스프린트 → 일일 스크럼 회의 → 스프린트 검토 회의 → 스프린트 회고

반응형
반응형

 

소프트웨어 생명 주기(Software Lift Cycle)

소프트웨어 개발 방법론의 바탕이 되며 운용, 유지보수 등의 과정을 각 단계별로 나눈것을 의미하며 일반적으로 사용되는 모형에는 폭포수 모형, 프로토 타입 모형, 나선형 모형, 애자일 모형 등이 있습니다.

 

A. 폭포수 모형(Warterfall Model)

폭포수와 같이 한번 떨어지면 거슬러 올라갈 수 없듯이 이전 단계로 돌아갈 수 없다는 전제하에 각 단계를 확실히하여 결과를 철저하게 검토 및 승인 과정을 거친 후 다음 단계로 나아가는 개발 방법론

  1. 전통적인 소프트 웨어 생명 주기 모형 (고전적 생명 주기 모형)
  2. 선형 순차적 모형
  3. 다음 단계를 수행하기 위한 결과물을 명확하게 산출되며 두개 이상의 과정이 병행하여 수행될 수 없음

 

 

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

사용자의 요구사항을 정확히 파악하기 위해 개발할 소프트웨어의 시제품(Prototype)을 만들어 최종 결과물을 예측하는 모형

  1. 시제품(Prototype)은 의뢰자 및 개발자 모두에게 공동의 참조 모델이 됨
  2. 시스템의 일부 혹은 시스템의 모형을 만드는 과정(요구된 소프트웨어를 구현)하며 이는 추후 구현 단계에서 사용할 골격 코드가 됨
  3. 단기간 제작을 목적으로 사용됨 → 비효율적인 언어나 알고리즘이 사용될 가능성이 있음

 

 

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

폭포수 모형과 프로토타입 모형의 장점+위험 분석 기능을 추가한 모형으로써 보헴(Boehm)이 제안한 모형

  1. 나선처럼 여러 번의 개발 과정을 거쳐 점진적으로 최종 소프트웨어를 개발
  2. 위험을 관리 및 최소화 하는것을 목적으로 함
  3. 핵심 기술에 문제가 있거나 요구사항이 이해하기 어려운 경에 적합한 모델
  4. 점진적으로 개발 과정이 반복되어 누락되거나 추가된 요구사항을 첨가할 수 있음 (정밀 및 유지보수 과정이 필요치 않음)

 

 

D. 애자일 모형(Agile Model)

'민첩한', '기만한'이라는 의미로써 고객의 요구사항을 바로 적용하며 일정 주기를 반복하는 개발 과정

  1. 빠르게 개발하기 위해 고객과의 소통에 초점을 맞춘 방법론
  2. 기업활동 전반에 걸쳐 사용
  3. 스프린트(Sprint) 또는 이터레이션(Iteration)이라고 불리는 짧은 개발 주기를 반복
  4. 고객에 초점을 맞춘 방법론으로써 소규모 프로젝트, 숙달된 개발자, 급현하는 요구사항에 적합

 

애자일 모형을 기반으로 하는 소프트웨어 개발 모형

  • 스크럼(Scrum)
  • XP(eXtreme Programming)
  • 칸반(KanVan)
  • Lean
  • 크리스탈(Crystal)
  • ASD(Adaptive Software Development)
  • 기능 중심 개발(FDD; Feature Driven Development)
  • DSDM(Synamic System Development Method)
  • DAD(Disciplined Agile Delivery)
  • ...

 

※ 애자일을 조금 더 쉽게 외우는 방법

애 : 애새끼가
자 : 자꾸
일 : 일을 만든다

 

 

반응형
반응형

 

STS3에서 MVC Project를 찾을 수 없음(STS MVC Project invalid thread access, org.springframework.samples.mvc failed)

2월 이후 STS3 버전을 다운로드 받고 워크스페이스를 변경하면 Spring MVC Project를 찾을 수 없는 현상이 발생했습니다.

일부 블로그에서는 워크스페이스\.metadata\.plugins\org.springsource.ide.eclipse.commons.content.core에 https-content.xml을 작성하면 MVC Project를 생성할 수 있다는 글도 있지만, 프로젝트 생성 시 보이기는 하지만 만들수는 없는 현상이 발생 했습니다.

※ https-context.xml을 넣어서 프로젝트를 생성할 때 MVC Proejct를 보이게끔 해주어야 합니다. 해당 파일은 이후 업로드 예정입니다. 
※ 기존에 사용하던 프로젝트가 있으신 분들은 https-context.xml을 가져와서 넣으시면 됩니다.

 

Spring 홈페이지나 여러가지 레퍼런스들을 찾아봣지만 그렇다할 오피셜은 없었습니다. https-content.xml을 봣을 때 MVC Project를 다운로드 받기 위한 URL을 어떠한 이유로 차단하고 있거나, 더이상 서비스하지 않는것으로 추측됩니다. (이슈로 인해 잠시 안되는 것인지, MVC Project에 대한 지원이 아예 종료된것인지는 확인이 되지 않습니다.)

https-content.xml

 

URL을 통해 다운로드를 받아오지 않고 아래에 배포한 zip 파일을 직접 워크스페이스\.metadata\.sts\content\org.springframework.templates.mvc-3.2.2에 넣음으로써 해결할 수 있습니다.

 

※ 해당 zip 파일에 있는 내용은 이전에 작업하셨던 프로젝트가 있다면 해당 경로에 찾아가면 있습니다. 기존 프로젝트가 있으신 분이라면 워크스페이스\.metadata\.sts\content\org.springframework.templates.mvc-3.2.2 경로로 이동하여 파일들을 새로운 워크스페이스 경로에 넣으시면 됩니다.

 

org.springframework.templates.mvc-3.2.2.zip
0.01MB

 

반응형

+ Recent posts