개발/학교 수업

[소개원실/swpp] Software Development Process

Woogie2 2021. 10. 12. 17:07
반응형

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 간의 빈 기간이 없도록 함.
  • 프로덕트 오너가 제품이 완성되었다고 판단하면, 최종적으로 출시를 위한 스프린트를 진행한다.
반응형
저작자표시 비영리 동일조건