[소프트웨어 개발의 모든 것] 중,
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. 소프트웨어 개발을 성공으로 이끄는 법