[소개원실/swpp] Software Development Process

Software Dev Process

Objectives

1. 소프트웨어 개발 단계를 이해한다.
2. 제품의 품질 향상을 위한 공정들을 이용하기.
   • 전통적인 방법
   • 더욱 모던한 방법
3. 어떤 것이 적용될 수 있고, 적용될 수 없는지 이해하기.

Development Phases

1. 시장 조사
2. 요구사항 수집 및 분석
3. Specification, planning, design
4. 구현과 테스팅
5. 배포
6. 지원 및 유지보수

시장 조사

• 유저 혹은 현장에 있는 사람, 내부 직원(개발자 등) 등이 조사 대상
• 사회적/경제적 실현 가능성 판단
• 시간/비용이 얼마나 필요한지 가늠해보기
• 마케팅을 무시하지 말 것.

요구사항 분석

• 제품 정의
  • information, function, behavior, performance, interfaces
  • 목표와 사용가능한 케이스를 이해해보기
• 소비자는 자신들이 원하는 것을 정확히 모를수도 있음.
  • "고객들에게 무엇을 원하는지 물으면, 그들은 빠른 말을 원헀다."(헨리 포드)
• Analysis: 무엇을 가져가고 무엇을 가지칠지 정하는 것.

계획과 디자인

• 요구사항 명세서를 디자인 명세서로 바꿔라
• 특히, class architecture, data structures, algorithmic details, 등을 구체화 하라
• 최대한 엄격하게 작성하라.
  • 예를 들자면 formal language를 사용한다던가..

구현과 테스팅

• write code: 전체 시간 중 15%까지 차지
• test and integrate: 전체 중 50%까지 차지
• 내부 디자인 사항을 문서화하라.
• 늦게 발견된 버그일수록 고치기 힘듦을 명심할 것.

배포, 지원, 유지보수

• 코드를 서비스나 제품으로 패키징
  • 여러 플랫폼으로 포팅되는 것을 포함
• 소비자 입장에서 설치하는 과정을 생각할 것.
• 버그를 탐지하고 고치기.

여러가지 개발 과정에 대한 모델들.

개발 모델 비교

The Waterfall Model

앞서 설명하고 있는 단계적인 과정을 거치는 개발 과정.
시스템 요구사항 -> 소프트웨어 요구사항 -> 분석 -> 프로그램 디자인 -> 코딩 -> 테스팅 -> 운영 등의 단계를 거친다.

특징

• 핵심 기능: 선형적, 순차적
  • 각 단계가 다음 단계가 시작되기 전에 끝난다
  • 문서화와 리뷰가 각 단계 변화마다 실행된다
  • spec이 계약의 역할을 함.
  • 'freeze dates'
• Model still used (in various forms)
• 강점
  • Early validation: 약 50배에서 200배의 비용 절감 가능
    • Structure + discipline
    • 과정을 잘 통제할 수 있음
    • 아직 미숙한 신입에게 좋음
    • 많은 직원이 바뀌는 경우 리스크를 감소시킬 수 있음
    • 명확한 진행 상황에 관한 지표, 리소스 활용하기 좋음
• 단점
  • Requirements must be known upfront
    • 이 과정을 완벽히 하기가 힘들다
    • 진행중 새로운 문제가 발생하기 때문.
  • 유연하지 않음 -> 느리고, 비용 많이 들고, 부담스러움
  • 소비자가 제품에 대해 미리 확인해볼 수 없음.
    • 제품 검증이 매우 미뤄진다.
    • 유저와 개발자 사이의 갭이 커짐

언제 사용하는 것이 좋을까?

• 목표와 해결책이 명확할때
• 경험이 적은 팀 or PM이 진행하는 경우
• Large, complex prj.

Prototyping Model

• 쌍방향 소통 가능. (waterfall과 반대)
  • 완성될때까지 진행
  • a.k.a. evolutionary model
• Typical sequence:
  • 프로토타입 제작
  • 유저에게 공개(use as a way to refine requirements)
  • 유저가 제품을 평가하고, 개선사항을 제안한다. 출시 준비가 되었는지도 결정함.
  • 개발자는 프로토타입을 개선시킴.
  • 이 과정을 반복.

강점

• 사용자가 니즈를 잘 표현하지 못하는 것에 잘 대처할 수 있음
• 유저의 참여를 장려 -> 유저의 만족도가 높아짐
• 명확하지 않은 목표를 해결하고, 타협할 수 있게 도와줌.
• 앞선 과정에서 얻은 지식을 잘 활용할 수 있음.
• 혁신적이고 유연한 디자인을 가능하게 함.
• 작동하는 어플리케이션을 더욱 빠르게 만들어낼 수 있음

단점

• 관리하기 힘들다
• poor design으로 이어질수도 있음. evolution이 항상 좋은 것은 아님.
  • 숙련되지 않은 사람에게는 어울리지 않음.
  • 여러 기능들을 throwaway 모델에 따라 버리고 만들어짐.
  • 프로토타입을 어쩌다보니 최종 프로덕트로 출시하고 있을 수 있음.
• 문제사항 분석이 완벽하지 않음.
  • 피상적인 니즈만 다뤄짐
  • 성급하게 reject하거나 영원하 iterate할수도 있음.
• 디자인 초이스를 할 때, 원래 의도를 살리지 못하는 경우, 이성적인 판단을 못하는 경우도 생김.

언제 사용하면 좋은가?

• 짧은 라이브 데모, UIs, etc.
• 유저 요구사항이 명확하지 않고, 계속 바뀌는 경우
  • iteration을 이용하여 리스크 줄이기
• User or customer not very knowledgeable
• 급하게 구현해야할 경우
• 경험이 있는 팀
• Flexible designs "for the future" are not essential

Incremental Model

• Waterfall with a divide-and-conquer strategy
  • 프로젝트를 더욱 작은 부분으로 쪼갠다.
  • linear 모델을 iterative approach와 결합하여 리스크 줄이기
• 3가지 방법
  • 순처적으로 mini-waterfall을 수행. 각 릴리즈마다 기능이 추가됨
  • mini-waterfall을 병렬적으로 실행.(must design interface carefully)
  • Do a waterfall up to (and including) design, then do iterative prototyping.강점
• 이전 incerment에서의 지식을 이용할 수 있음
• Better control (문서화, 리뷰 등)
• 소비자는 중요한 기능을 일찍 받아볼 수 있음.
• Integration 리스크를 줄인다.
• 요구사항 변경을 다룰 수 있음.

단점

• mini-waterfall들은 더욱 큰 그림을 보고 생각하기에는 적합하지는 않음
• 반드시 좋은 인터페이스를 정의해야한다. 그렇지 않으면 integration에 실패할 수 있음
• 어려운 기능은 나중으로 미루고 싶어하는 유혹이 생김
• 모든 요구사항을 초반에 적지 않음 => 호환되지 않는 부분들이 이후에 발견될 수 있다.

Spiral Model

Spiral Model

• Barry Boehm
  • 주된 목표: 매 단계에서의 리스크를 최소화
• 4개의 quadrants(사분원)
  • Objectives, Alternatives, Constraints (2사분면, 시작지점)
    • Objectives: 기능, 성능, 인터페이스 등
    • Alternatives: 빌드, 재사용, 구매, sub-contract 등
    • Constaraints: 비용, 일정, 인터페이스 등
  • Evaluate, Identify & Resolve Risks (1사분면)
    • 경험 부족, 새로운 기술, 너무 버거운 일정
  • Develop & Verify(4사분면)
    • 디자인, 디자인 리뷰, 코드 작성, 코드 inspect, 제품 테스트
  • 다음 단계 계획(3사분면)강점
• 리스크를 일찍 발견 가능
• 유저가 각 단계마다 참여할 수 있다 -> 빠른 프로토타이핑
• 다른 대안과 제한점에 대해 일찍 확실히 알 수 있음.
• 디자인을 발전시킬 수 있음
• 크고 복잡한 프로젝트에 적합
• 유지보수도 이 나선에 포함되어있다.

약점

• 많은 시간이 리스크와 objective들을 평가하는데에 사용된다.
• 복잡하다(특히 다른 소프트웨어 개발 방법론을 포함하는 경우)
• 명확한 데드라인이 없다.
• 개발자는 개발 기간이 아닌 경우 반드시 re-assign 되어야함.
• 계약에 의해 개발을 진행하는 경우, 클라이언트가 모든 리스크를 평가해야한다.(계약 이전에)
  • Spiral 모델 사용시 어려움.

언제 사용하면 좋은가?

• 중~고 위험 프로젝트들
• 중~대형 시스템
• 리소스 소비를 견뎌낼 수 있을 때(시간, 자본 여유가 있을 때)
• 공식적인 승인이 필요한 경우(?) (원문 :Formal approval process already required)
• 기능보다는 견고한 구현이 더욱 중요할 경우
• 많은 변화가 예상되는 경우.

Agile Development(애자일 개발)

Agile Methods

• Builds upon iterative development
  • 90년대 중반에 사용되던 헤비한 방법론에 대한 대안으로 나옴
  • leverage iterative dev (uncover problems early)
• 사람 중심의 관점을 더함.
• 원칙: "if something is good, do it a lot"
  • 피드백을 활발히 하기(planning 보다)
  • 방해, 장애가 되는 것에 대해 의사소통하기
  • 요구사항에 대해 자세히 알기 위해 프로토타입을 활용.
• 도구들
  • 스크럼(Scrum)
  • Adaptive Software Development
  • 기능 주도 개발(Feature Driven Development, FDD)
  • Crystal Clear
  • Extreme Programming
  • Rapid Application Development
  • Rational Unify ProcessScrum

Scrum

• 기본적인 구조 = 스프린트(Sprint)
  • 1~4주(rigidly fixed length)
  • 순차적으로 진행. 스프린트 1 => 스프린트 2...
  • 각 스프린트 마무리에는 프로덕트가 동작해야함.
• Cross-functional teams of 3-9 people
• 매일 만날 것.

출처: 소개원실 강의 슬라이드

• Product Owner
  • 고객이나 end-user의 interest를 전달
  • 사업적 가치를 극대화
  • 니즈를 우선순위 리스트로 변환
  • 기존의 Product manager(PM)과 동일한 역할.
• The Team
  • 제품을 만든다.
  • 교차 기능 팀(개발자, 디자이너, 테스터, 분석가 등이 한 팀으로 일한다.)
  • Self-managing -> 자율적이고 책임감이 있어야 함(autonomous + accountable)
  • 작은 팀(5~10명)
  • 큰 프로젝트에는 작은 스크럼 팀을 여러개 구성한다.
• Scrum Master
  • 역할: ensure team's success
  • 팀의 매니저는 아님
  • 팀을 외부의 간섭으로부터 지킴(from Project Owner)
  • 방해물을 해결할 수 있게 도움
  • 백그라운드가 다를 수 있음(개발자, 매니저, 디자인, 테스팅 등등)
  • 스크럼 마스터는 팀의 멤버 중에서 정해야함
    • 그러나 Project Owner와는 확실히 다를 것.
• Manager(이 수업의 경우 조교님들)
  • Not a nanny, but a guru
  • 멘토, 코치, 문제 해결을 돕는 사람
  • 예전에 스크럼 마스터를 해본 사람
• Product Backlog(프로덕트 백로그, 제품 관련 미완성 사항)
  • 프로덕트 오너가 프로덕트의 비전을 명확히 해야함
  • To-do list의 우선 순위는 소비자에게 가치가 높은 것부터 차례로 매김
  • Contains
    • 기능
    • 개발 요구사항
    • 리서치/조사 업무
    • 버그들
  • Articulated in terms of “user stories”
  • 점점 발전해야함
  • Is the definite view of "everything that could be done by the team ever, in order of priority”
• Team provides time estimates. 각 항목에 대한 예상 소요시간 도출
  • 프로덕트 오너는 이를 활용하여 Backlog에 우선순위를 매김
• 스프린트 계획 미팅
  • 매 스프린트의 첫 과정
  • 프로덕트 오너와 팀은 '프로덕트 백로그'를 리뷰
    • 팀에게 고객 관점에서의 인사이트를 줄 수 있음.
  • 이번 스프린트에서 완성시킬 아이템들을 선택(시작부터 끝까지?)
  • 팀은 각 아이템을 태스크로 쪼개어, 스프린트 백로그를 생성
  • 팀이 한 번 약속한 프로덕트 백로그는 변경하지 않기.
• Daily Scrum(일일 스크럼)
  • 스탠드업 미팅을 매일 정해진 시간에 진행
  • 매 미팅은 15분 이내로
  • 각 팀원은 3가지를 보고해야함
    • 지난 미팅 이후로 무엇을 했는가?
    • 다음 미팅까지 무엇을 할 것인가?
    • 막힌 부분이나 어려움이 있었는가? 있었다면 무엇인가?
    • 토의는 하지말 것, 그냥 보고만 진행!
  • 일일 스크럼 이후
    • 스크럼 마스터가 방해 사항을 해결하고 진행 사항에 관련된 문서를 업데이트
• Sprint Duration
• 스프린트는 절대 연장하지 않는다.
• 목표를 달성하지 못했으면, team must own up to it
  • 실험을 통해 태스크가 얼마나 걸릴지 결정 -> 시간이 갈수록 팀에서 소요 시간 예측을 더 잘할 것임
• 하나의 스프린트 기간을 정해서 그것을 고수하라.
  • helps team improve their estimates
• Sprint Review(스프린트 리뷰)
  • Demo the Product (준비시간 30분 이내로)
  • 참여자: 팀 + 스크럼 마스터 + 프로덕트 오너 + 고객 + 이해관계자 + 전문가
  • 누구나 질문 가능
  • Meeting lasts as long as necessary
• Sprint Retrospective(스프린트 회고)
  • 참여자: 팀 + 스크럼 마스터 + 프로덕트 오너
  • 중립적인 외부인에 의해 진행되는 것이 수월함.(다른 스크럼의 스크럼 마스터: good for cross-pollination)
  • 프로덕트 오너는 프로덕트 백로그를 최신화(다음 스프린트 계획 미팅에 회고를 반영)
  • 스프린트와 maintain pace 간의 빈 기간이 없도록 함.
• 프로덕트 오너가 제품이 완성되었다고 판단하면, 최종적으로 출시를 위한 스프린트를 진행한다.