소프트웨어 공학 이론 정리 -5장- <Perescriptive Process 마무리와 요구사항 분석의 시작>

Agility Principles

-      Customer의 만족은 Customer가 요구하는 가치를 제공하는 소프트웨어를 최대한 빠르게 전달시킬 수 있을 때 충족된다.

-      요구사항은 반드시 바뀌며, 바뀌는 요구사항을 잘 받아들일 수 있어야 한다.

-      소프트웨어의 증진은 매주[Not Monthly] Stakeholder에게 내용을 전달해 피드백을 확인받으며 가치를 입증 받아야 한다.

-      Stakeholder는 서로 face-to-face 하여 communication을 하게 되며, 이들 모두 같이 agile team에 소속된다.

-      팀으로 이뤄지는 process는 기술적인 전문성과, 좋은 디자인, 단순화라는 가치를 얻게 해준다.

-      Customer의 요구에 맞는 소프트웨어를 제작하는 것이 가장 중요한 목적이다.

-      팀워크의 방향성은 지속 가능하다? [하나의 요구사항만이 아닌, 여러 요구사항을 지속적으로 끝까지 이뤄 나갈 수 있도록 한다.]

-      Agile team은 스스로 조직되는 팀이다. 따라서 상호간 신뢰할 수 있는 개발이 지속될 수 있으며 이는 Solid한 디자인과 고객을 만족시킬 수 있는 결과를 생산할 수 있다.

-      팀의 문화[성격]은 마치 자기성찰[반성]하 듯해왔던 일들을 돌아보며, 팀을 개선해 가장 큰 목적인 customer의 만족도를 높여 나가야 한다.

 

 

Agile Process Scrum Framework

-      하루 작업이 끝나면 15분간 데일리 미팅을 하게 된다. [Scrum]

-      Product Backlog : 해야 하는 일들이 우선순위 별로 정리되어 있다.

-      Sprint Backlog : 전력질주하여 빨리 해결해야 하는 일 들

-      New Functionality is demonstrated at end of sprint

Scrum Details

-      Backlog Refinement Meeting :
개발자와 stakeholder들이 Product Backlog를 만들기위해 갖는 회의

-      Sprint Planning Meeting :
backlog 중 sprint해야하는 작업을 분류하고 다음 sprint 작업 또한 정의한다.

-      Daily Scrum Meeting : [15 min Max]
팀 멤버가 당일 한 일과, 앞으로 해야 할 일을 이야기 나누며 작업 현황을 동기화한다.

-      Sprint Review :
동작가능한 Demo를 Stakeholder에게 제공하고 피드백을 제공 받는다.
[Approval or Rejection]

-      Sprint Retrospective :
Sprint가 종료되고, 어떤 것을 증진시킬 수 잇는지, 어떤 일이 잘 진행됐는지 논의.

-      장점

• 제품의 owner가 우선순위를 정할 수 있다.
• 팀이 의사결정을 할 수 있다.
• 문서화가 가볍다.
• 빈번한 업데이트를 할 수 있다.

-      단점

• 변화에 대한 기회비용을 조절하기 쉽지 않다.
• 매우 큰 규모의 팀에겐 맞지 않다.
• 전문적인 팀 구성을 요구한다.

 

 

 

Extreme Programming (XP) Framework

-      Planning
유저의 요구사항과 가치, 테스트의 기준, 몇 주기를 거칠 것인지에 대한 기획

-      Design
OOP 기준으로 Class를 만들 때, CRC[Class Responsibility Collaboration]을 기초로 디자인한다.
솔루션을 분류하고 해당 솔루션에 맞는 프로토타입을 설계한다.
[Design에서 프로토타입을 만든다. 다만 Running이 안될 수 있다.]

-      Coding
프로그래머를 짝지어 개발시킨다. 그 후 Refactoring 과정을 거친다.

-      Testing
Customer가 받아들일 수 있는지 Testing한다.
Unit test를 Coding-Testing에 걸쳐 진행한다.

-      Release
프로젝트가 얼마나 속도감 있이 진행되고 있는가를 계산하고, 앞으로의 일을 결정한다.

 

 

XP Details

-      XP Planning :
User Stories, Team Estimates Cost, 품질향상을 위한 Stories 정리, 무조건 완성되어야 하는 날짜를 정하고, 프로젝트의 진행 속도를 계산한다.

-      XP Design :
CRC cards의 사용을 권고하고, 프로토타입을 디자인하고 리펙토링을 거친다.

-      XP Coding :
unit tests를 coding을 들어가기 전 구조화한다음, pair programming[사수, 부사수]를 진행시킨다.

-      XP Testing :
unit tests를 매일 진행하며, customer가 해당 테스트를 수용할지 결정한다.

-      장점

• Customer의 참여를 확대할 수 있다.
• 합리적인 계획과 스케쥴을 짤 수 있다.
• 완제품 출시에 대한 개발자의 신빙성 있는 약속을 받을 수 있다.
• Product가 거절될 가능성을 줄일 수 있다.
  [customer가 involvement 하고 있고, 정해진 날에 피드백 및 반영할 수 있기 때문]

-      단점

• 빈번한 요구사항의 변동이 비용을 유발할 수 있다.
• 과다한 변화를 요구하고 이것을 수용할 위험성이 있다.
• 팀원의 전문성에 의지한다.
  

 

Chapter 7 - 요구사항의 이해

Requirements Engineering [요구사항 공학]

-      7단계

• Inception:
  문제상황[유저의 요구]의 이해, 이 솔루션을 요구하는 사람이 누군가, 솔루션의 본질 [문제상황에 따라 제공해야하는 것들]에 대해 customer와 developer가 communication할 수 있도록 명시해야 한다.
• Elicitation:
  요구사항과 사업 목표를 뽑아낸다. [모든 stakeholder로 부터!]
• Elaboration:
  요구사항 모델을 정교하게 만들어 내야 한다. 여기엔 소프트웨어의 기능, 행동, 제공하거나 필요한 정보를 내포한 모델이어야 한다.
• Negotiation:
  Developer와 Customer가 최종적으로 만들어질 소프트웨어의 범위를 협상한다.
• Specification:
  앞으로 만들어질 소프트웨어를 문서, graphical model, 수학적 모델 등 어떤 규격으로 보여줄 것 인지 정한다.
• Validation:
  요구사항 공학으로 만들어진 모델이 Stakeholder들의 요구사항에 대해 얼마나 가치가 있는지를 매긴다.
• Requirements Management:
  프로젝트가 진행됨에 따라, 요구사항의 변화를 계속 추적 관리한다.