[소프트웨어 개발의 모든 것] 중,
Part 2. 소프트웨어 개발을 성공으로 이끄는 법

소프트웨어 프로젝트 = 생명체

• 생명체와 같이 유기적으로 움직임
• 프로젝트 규모가 작다
  • 전문 지식 경험 없이 수행 가능
  • but. 규모가 커질수록 체계적인 관리 요구! 개발 방법론 도입

CASE1. 개발 방법론을 그냥 따라하면?

• 너무 복잡함
• 문서를 많이 만들어야 함
• 방향성을 잃어버림
• 제대로 도입하지 않으면 방해가 됨

CASE2. 세계적으로 검증된 유명한 개발 방법론을 도입했더니?

• 프로젝트 소요시간 증가
• 개발자의 불만 증가
• 제품의 품질 감소
• 작성해야 할 문서 증가
• 문서 내용 중복
• 형식적인 문서 작성
• 실제 개발에 도움 안됨
• 승인 절차로 인해 너무 지연됨

지쳐서 방법론 따위는 ...

효율적인 개발 방법론 도입

• SRS → 프로젝트의 기둥으로서의 역할

  SRS(Software Requirement Specification)
  소프트웨어 요구 명세, 기능 명세

  

• 도입한 개발방법론을 고집하지 않고 무엇이 문제인지 다시 생각
• 이론의 문제보다는 경험자의 지혜를 빌려야 함
• 코딩부터 시작 → 무엇을 만들어야 하는지 정확하게 모르는 상태에서 뭔가를 만든다.
• 불충분한 요구사항으로 인한 재작업은 재앙의 시작.

생애주기 모델을 제대로 선택하라

생애주기(Life Cycle) 모델

• 소프트웨어 탄생 ~ 소멸
• 생애주기에 대한 고민 ?!
• 일단 짜보고 고치기(Code-and-fix)의 딜레마
  • 문서도 없이 코딩하고 고치기를 반복
  • 빠른 시간안에 가시적인 결과물이 나온다
    • but. 많은 위험 잠재, 일정 산정, 진행 상황 체크하기 어려움
  • 생애 주기 모델의 범주에 조차 들어가지 않음.
• 적합한 생애주기 모델 선정의 어려움

폭포수 모델

• 모든 생애주기 모델의 근본
• 순차적인 단계 발전의 모델
  • 전 단계가 완벽하게 끝나야 하고 모든 결과 문서화
• 제품의 스펙이 거의 바뀌지 않거나 안정성이 아주 중요한 프로젝트
  • ex) 10년동안 개발하고 실제 환경에서의 테스트가 불가능한 화성탐사선

장점

• 소프트웨어 개발 공정을 이해하는데 도움
• 단계 별 작업 진행으로 각 단계의 진척 관리 용이
• 각 공정마다 명확하게 정의된 산출물 존재
• 일정관리 용이
• 스펙이 명확하여 산출물의 품질의 명확한 정의
• 이미 유사 제품의 경험이 있는 경우에 효과를 보임

단점

• 폭포는 거슬러 올라갈 수 없듯이, 앞 공정으로 되돌아갈 수 없음
  • 유연하지 못함
• 작성해야할 문서가 지나치게 많음
• 전체적 일정 지연
• 정확한 요구사항 파악 어려움
• 비즈니스 상황에 유연한 대처 X
• 프로젝트가 끝나기 전까지 진행상황을 거의 보여주지 못함
  • 사용자는 자신의 요구대로 만족스러운 제품이 나왔는지를 프로젝트가 끝난 뒤에야 알 수 있음

이외의 모델

반복 모델

• 소프트웨어 프로젝트를 원활하게 진행하기 위해 여러 번에 걸쳐 개발 공정을 반복하여 수행
• 각 공정을 반복적이고 점진적으로 진행
• 요구사항이 명확함
• 개발팀이 기술 및 요구사항에 익숙해짐
  • 우수한 소프트웨어를 개발하는데 도움이 됨
• 작은 폭포수 모델을 반복
  • 반복 주기마다 시연 가능한 제품을 릴리즈하는 과정을 반복하면서 점진적 향상에 도움

장점

• 반복 릴리즈
  • 통합 및 테스트 단계에서 발생할 수 있는 위험요소 분산
• 각 단계 제품 시연
  • 피드백을 제품에 반영할 수 있음
• 비즈니스 상황 변화에 대처 용이
• 요구사항 파악에 용이

단점

• 여러 차례 릴리즈에 들어가는 부수적 비용 부담
• 사양이 정확하게 정해진 프로젝트에 비효율

XP(eXtreme Programming) 모델

• 애자일 소프트웨어 개발 방법론의 하나
• 고객에게 최고의 가치를 가장 빨리 전달하는 목적
• 요구사항 변화가 자주 일어날 때 효율적임
• 같은 공간에서 소규모 개발자들이 같이 일할 때 효율적임
• Simple Is Best 요구
• 필요할때마다 방향을 바꾸기 위해

장점

• 요구사항이 변해도 일정에 영향이 적음
• 작은 프로젝트에 효율적임
• 작은 개발팀 규모에 적합
• 문서를 최소화
• 지식공유 용이

단점

• 큰 프로젝트에 부적합
• 테스트가 어려운 프로젝트에 사용 불가능
• 빌드 과정이 자동화 되지 않으면 사용이 어려움
• 테스트가 자동화 되지 않으면 사용하기 어려움

사시미 모델

• 폭포수 모델의 변형
• 각 단계의 상당 부분을 중첩하여 진행
• 요구사항 분석 완료 전에 설계 → 설계가 완료되기 전에 구현
• 작은 프로젝트를 진행할 때 효과적

장점

• 문서의 양을 줄일 수 있음
• 앞 단계의 오류를 빨리 찾을 수 있음
• 위험 요소를 빨리 발견할 수 있음

단점

• 각 단계가 애매해져 프로젝트 관리가 어려움
• 일정이 모호해서 진행사항 파악에 난관을 겪음
• 여러가지 활동을 동시에 수행 → 프로젝트 진행 혼란, 비효율성 초래

발전적 프로토타이핑 모델

• 프로젝트를 진행하면서 점점 제품의 개념을 잡아감
• 주요 부분 프로토타입 제작 → 사용자의 피드백을 반영하면서 점진적으로 제품 발전
• 요구사항이 분명하지 않거나, 변할 가능성이 클 때 용이
• 고객과 개발자 모두가 익숙하지 않은 분야를 개발하고 있을 때
  

장점

• 요구사항 오류로 인한 문제 감소
• 프로젝트의 위험을 초기에, 진행 여부를 조기에 판단 용이
• 작업 진척이 가시적으로 보이므로 고객을 안심시킬 수 있음

단점

• 프로젝트 초반에 일정 수립이 어렵고 일정 지연의 위험이 높음
• 체계적인 설계 부족으로 제품의 아키텍처가 깔끔하지 못함
  • 이식성이 떨어짐
• 설계에 대한 미비
  • 성능의 저하
• '일단 짜보고 고치기' 모델의 위험성

개발 단계별 계획을 수립해라

• 모든 개발은 여러 단계를 거쳐 진행
• 빅뱅 테스트(Big bang)
  
  • 개발을 단계적으로 진행하지 않는 회사는 업무와 일정에 대한 정교한 구분없이 일을 진행하다가 적당한 시점에서 한 번의 테스트를 통해 제품을 완성하는 것
  • 운 좋게 개발 기간을 단축시켜 줄지도 모른다는 근거없는 생각과 기대감으로 중구난방 일을 진행
  • 테스트가 언제 끝날지 예측 불가
  • 일정 기간 내에 품질의 향상 추측 불가
  • 버그 파악 불가능
• 프로젝트를 단계별로 진행 및 관리
  • 각 단계가 명확해짐
  • 프로젝트 진행 상황이 가시적임
  • 혼란으로 인한 재작업 감소, 비용 절약
• 높은 품질의 제품을 출시하기 위해서?!
  • 단계별 릴리즈 실행
  • 알파, 베타, RC(Release Candidate)

개발의 각 단계

• 프로젝트 단계는 크게 요구분석, 설계, 구현, 테스트로 나뉨

요구분석 단계

• 개발에 관련된 모든 내용 검토 및 분석
  • SRS 작성, 프로젝트 계획서 작성, 리스크 분석, 일정 산정 등의 개발 계획 수립
• 프로젝트의 범위와 일정, 진행상의 이유를 명확하게 알 수 있음

설계 단계

• 제품의 아키텍처를 의논과 설계를 통해 정하는 단계
• 제품을 이해하고 구현하는데 있어서 필요한 것들을 표현
  • 많은 규칙 강요 회피
• 바람직한 설계
  • 설계를 보고 코딩이 가능한 수준
  • 훌륭한 회사와 보통 회사를 가르는 경계
  • 상세하고 정확한 일정의 수립과 일일빌드가 시작
• 요구분석 단계와 설계단계 사이에 애매모한 겹침 발생

구현 단계

• 설계에 따른 소스코드 작성
• 잘 설계된 제품 → 임시계약 직원이라 할지라도 구현할 수 있음
• 일일 소스코드 빌드 → 테스트 케이스의 작성 완성
• 구현단계의 마지막(릴리즈)
  • 일반적인 경우 → 알파 버전
  • 규모 혹은 복잡성에 따라서 베타버전 혹은 RC버전 릴리즈

테스트 단계

• 제품을 테스트하고 수정을 반복하여 출시 가능한 제품을 만드는 단계
  
  • 프리 알파
    • 알파 이전에 벌어지는 엔지니어링 빌드나 일일빌드
  • 알파
    • 기능이 모두 구현됬으나, 버그가 많은 상태
    • 일부 작동이 안되는 기능이 있음
    • 공식적인 버그 등록, 통계
  • 베타
    • 중요한 버그는 거의 수정이 되어서 작은 버그들만 남음
    • 사용자 평가 및 외부 테스트를 위해서 외부에 배포하는 단계
    • 베타테스터 선정
  • RC(Relese Candidate)
    • 출시를 위해 만들어진 버전
    • FCS, 감마 또는 델타라고도 부름
  • GA(General availability)
    • RTM(Release to Manufacturing)이라고 부름
    • RC 중에서 테스트를 통과하여 출시 할 수 있는 버전
• 모든 소프트웨어를 개발할 때마다 이 같은 단계를 전부 거쳐야 하는 것은 아님
• 규모, 난이도, 성격에 따라 다르게 정해야 함

프로젝트 활동을 확실하게 관리하라

프로젝트 성공 기준 마련

• 소프트웨어 프로젝트를 성공하기 위해서는 성공의 기준이 무엇인지를 파악
  
• 성공 기준?!
  • 자신의 관심사에 따라 다름
  • PM → 일정에 맞추어 프로젝트를 완료
  • 개발자 → 일정이 지연되더라도 기술적으로 보람이 있고 완성도가 높아야 함
  • 영업자 → 고객의 요구사항이 프로젝트에 제대로 반영되었는지의 여부
• 프로젝트 성공 기준의 사전적인 의미?
  • 10개월을 예상한 프로젝트가 8개월에 끝났다고 해서 성공적인 프로젝트는 아니다
  • 정해진 기능 이외에 다양하고 화려한 부가 기능을 추가했다고 성공적인 프로젝트는 아니다
  • 스펙대로 만들었다고해도 고객이 만족하지 못한다면 프로젝트가 성공했다 할 수 없다.

정해진 일정 안에 정해진 비용으로 정해진 품질의 제품을 만들어서 고객을 만족시킨다

• 프로젝트에 알맞게 성공 기준을 만들어 개발 계획서에 포함시킨 뒤, 프로젝트 참여자 모두가 알 수 있도록 해야함
  • 프로젝트 참여자들이 일정이 중요한지, 기술이 중요한지, 고객 만족이 더 중요한지에 대해 생각을 하게 되고, 프로젝트 팀이 더 효율적으로 움직이게 된다.

Referenced

• [소프트웨어 개발의 모든 것] 중, Chapter 2. 소프트웨어 개발을 성공으로 이끄는 법