SW Engineering - 프로세스와 방법론

서론

나는 지난 1년동안 "도깨비 서재"라는 모바일 게임을 개발을 했다. 1인 개발을 진행했기 때문에, 귀찮다는 이유로 버전관리를 소홀히 하고 단일성의 원칙을 지키지 않고 주석처리를 통해 해결하려고 했다. 이때 나는 알았어야 했다. 생각보다 게임개발에는 시간이 투자되었고, 코드 수도 길어지게 되었다. 코드가 길어지게 되니 코드간 의존성이 높은 부분은 버그를 하나 고치기 위해 수정을 하면 그에 파생되는 다른 버그가 생겨났다. 직접 부딫히면서 설계가 얼마나 중요한지 뼈저러게 느끼게 되었고, 사실 지금도 지속적인 업데이트를 하면서 느끼고 있다. 혹시라도 앱이나 서비스를 개발중이라면 제발!!! 설계를 통해 유지보수가 쉽게 만들었으면 한다.

SW Engineering?

소프트웨어 공학이란 소프트웨어를 효율적으로 개발, 유지보수, 관리하기 위한 실무 분야이다.

우리는 흔히 이렇게 개발을 진행한다. 특히 규모가 작은 팀단위 일수록 개발과 수정을 반복하게 된다.(나처럼...)

• 요구사항 만족 가능성 낮음
• 개발이 지연됨
• 품질이 낮고 유지보수가 어려워짐

그래서 최소한 이런 형태는 지켜줘야 어느정도 좋은 소프트웨어를 개발할 수 있다. 타겟층의 요구사항을 분석하고 이를 명세화한다. 그리고 그런 아이디어를 바탕으로 설계를 하고 코딩을 시작하는것이다.

프로세스

프로세스는 소프트웨어를 체계적으로 개발하기 위한 단계적 절차와 활동의 집합이다.

• 검토와 검증 : 잘 작동하는 지 확인(검토), 이게 정말 타겟층에게 효과적인지 확인(검증).
• 진입조건, 출구 조건 : 작업을 시작하기 위해서 만족해야 하는 조건과 종료하기 위해 산출물(앱)이 만족해야 되는 조건.

그렇다면 좋은 프로세스란 어떤 것일까?

1. 예측 가능성
   : 소프트웨어 공학은 "제한된 리소스"로 "원하는 목표 달성"을 위해 "효율적인 대안을 찾는것" 이다. 따라서 비용 과 품질 에 대해서는 예측이 가능할 수록 좋은 프로세스이다.

2. 테스팅 & 유지보수 용이성

3. 변경 용이성
   : 요구사항 변경, 버그, 리팩토링

4. 결함 제거 용이성
   : 막바지에 생긴 버그일수록 고치기가 힘들다. 따라서 각 코드가 서로 독립적일수록 연계적인 문제가 생기지 않기 때문에 독립적으로 작성해야한다.

프로세스 모델

1. Waterfall Model(폭포수 모델)

각 단계를 위에서부터 순서대로 수행한다.
그 단계의 결과물을 다음 단계로 수행하는 것이므로 각 단계 사이에는 상호작용이 거의 없이 순서적으로 수행된다. 보통 각 단계 전문가들이 일을 처리하고 후속 팀으로 넘김( 공장 느낌 )

<장점>

• 단계별 구분이 명확해서 이해하기 쉬움
• 중간 산출물이 명확하므로 관리가 용이함
• 코드 생성 전 충분한 연구와 분석을 수행할 수 있음

<단점>

• 불필요한 문서 작업이 발생할 수 있음
• 이전 단계에서 문제가 발견되거나 수정 사항이 있어도 뒤로 돌아갈 수 없음

폭포수 모델 변형 - V 모델

이런식으로 모델을 확장해서 검증을 강화한 V모델 이라는 것도 존재한다.

2.프로토타이핑 모델

전체 기능을 구현하는게 아니라 기능을 시뮬레이션 할 수 있는 정도로만 만드는 방법

<장점>

• 요구 사항에 대한 효과적인 커뮤니케이션 가능.
• 적은 비용으로 제작 가능성을 볼 수 있음.

<단점>

• 버전관리가 어려움 -> 프로토타입이 계속 나오기 때문에.
• 오해를 하거나 지나친 기대심리를 유발할 수 있다.

3. 나선형(Spiral) 모델

소프트웨어의 기능을 나눠서 점진적으로 개발한다.
-중간중간 작은 테스트가 포함된다.
-개발 실패의 위험을 줄일 수 있다.

각 릴리즈 사이클은 다음 4단계를 거친다.

1. 이번 사이클에서의 목표, 방법, 제약조건을 결정한다.
2. 프로토타입을 만들면서 위험 요소를 분석한다.
3. 개발과 검증을 한다.
4. 다음 릴리즈 사이클을 계획한다.

<장점>

• 다른 모델들에서는 간과하는 위험 관리가 가능함 -> 위험분석을 계속하기 때문.
• 반복적인 개발로 품질이 향상된다.
• 적은 사이클부터 점진적으로 돌면서 요구사항을 명확히 할 수 있다.
• 사이클 수를 정해서 계속할지 말지 정할 수 있다.(리스크 큰 프로젝트)

<단점>

• 각 사이클 관리가 어렵다.
• 위험 분석이 제대로 이루어지지 않으면 피해가 발생함.

4. 단계적 모델

개발과 사용을 병행하는 방법을 반복한다. -> 일단 출시를 하고 사용자 피드백 받고 다시 업데이트를 반복

• 초기 단계에서 모든 요구사항을 확정할 필요는 없다.
• 릴리즈 - 점증적 방법 : 릴리즈마다 새 기능을 추가한다.
  ex) 이번에는 채팅기능.. 다음에는 선물하기 기능...
• 릴리즈 - 반복적 방법 : 릴리즈마다 완성도를 높인다.
  ex) 이번에는 텍스트 챗.. 다음에는 이모티콘 챗...
  

<단점>

• 이전 릴리즈와 개발중인 릴리즈를 같이 관리해야해서 복잡할 수 있다.
• 점증적으로 기능 추가시, 기능끼리의 유기성이 떨어질 수 있다.
• 언제까지 개선해야하는지 명확하지 않아 프로젝트가 지연될 수 있다.

5. 통합 프로세스(Unified Process)

폭포수 모델의 "사용자 요구사항에 대응하기 어렵다"라는 단점을 해결하기 위해 작업을 계속 반복 수행하는 반복적 개발론

• 도입 : 목표 수립, 사업 타당성, 비용 산정, 계획 작성
• 구체화 단계 : 설계작업 및 일부 구현.
• 구축 단계 : 구현 작업.
• 전이 : 완성된 제품을 배포, 베타 테스팅 등등 작업.

<장점>

• 문서화가 강조된다. -> 유용하게 사용및 프로젝트 관리성 올라감
• 반복을 통해 고객의 요구 변경에 유연한 대처 가능.
• 코드 재사용 가능

<단점>

• 불필요한 문서화 작업 발생 가능.
• 프로세스가 복잡해짐.
• 프로젝트 참여자들의 협동이 중요해짐.

---

Agile 프로세스

애자일 선언에 기초한 빠르고 적응력 높은 개발 기술들의 총칭.
애자일은 개발 방법론 보다는 원칙에 가깝다.

애자일 12가지 원칙

1. 빠르고 지속적인 제품 전달을 통한 고객 만족을 최우선으로 한다.
2. 요구 조건에 변경 사항이 있어도 이를 수용할 수 있다.
3. 동작하는 소프트웨어를 자주(몇 주에 한 번 혹은 몇 달에 한 번) 배포한다.
4. 사업팀과 개발팀은 매일 같이 일해야 한다.
5. 개발에 관련된 사람들이 동기 부여된 상태에서 일할 수 있게 환경을 제공한다.
6. 얼굴을 마주 대하는 것이 가장 효율적인 의사 전달 방식이다.
7. 개발 진도를 파악하기 위한 1차적 방법은 동작하는 소프트웨어를 통해서이다.
8. (지치지 않고 일정한 속도로 계속해서 할 수 있는) 지속 가능한 개발 방식을 추구해야 된다.
9. 기술적 탁월함과 좋은 설계에 대해 꾸준히 관심을 가져야만 agile 하게 개발할 수 있다.
10. 단순함은 필수 덕목이다.
11. (남이 시켜서가 아니라) 스스로 잘 굴러가는 팀이라야 최고의 설계와 구조를 만들어 낼 수 있다.
12. 팀은 어떻게 하면 좀 더 효율적으로 일할 수 있는지를 주기적으로 자아성찰 할 수 있어야 한다.

<장점>

• 신속한 개발 및 빠른 출시.
• 요구 사항 변경에 유연한 대처.
• 생산성이 올라간다.

+) 애자일 방법론은 기업들에서 많이 사용하는 형태다.

Scrum - 스크럼

Sprint라는 2~4주 단기 개발을 반복한다.

1. Sprint Planning

• 이번 스프린트의 목표는 000이고 000중에서 xxx가 완료되어야 합니다.
• 이번 스프린트의 목표를 세우는 것.
• 소요시간 1~2h/weeks (2주짜리면 2~4시간 안에 계획 끝내기)

2. Daily Scrum

• 저는 어제 000작업을 했고 오늘은 xxx작업을 할 계획입니다.
• 날마다 짧은 미팅(15분 내)을 통해 업무를 정리하는 것.
• 자기 작업중 blocker이 있다면 도움을 받을 수 있음.

3. Sprint Review

• 이번에 만든것은 이겁니다. 의견 주세요~
• 작업 결과물에 대해 showcase를 진행하는 것.
• 소요시간 45min/week.

4. Sprint Retrospecitive

• 지금 방식중에서 이런것을 고치면 더 빨리 할 수 있을 것 같아요.
• Sprint 프로세스 자체에 대한 점검.
• 45min/weeks.
• 개발 문화가 발전됨.

---

목표의 크기별 구분

1. Initiavite

   여러 팀이 합쳐서 만들어낼 큰 목표
   ex) SNS시장 점유율 10%이상 달성

2. EPIC

   주로 수개월 혹은 분기 단위 목표
   ex) 이번 분기 채팅 앱 시장에서 10%성장을 한다.

3. User Story

   소프트웨어 기능을 캐주얼하게 나타냄, 최종 사용자 관점에서 기술해야한다. 개발팀이 명확히 인식해야함. - 주로 한 sprint 단위 목표임.
   ex) 최종 사용자는, AI를 이용한 사진 편집 기능을 활용할 수 있고, 이를 통해 사진을 업로드 하는 부담감을 낮춰준다.

그 밖에 sprint관련 내용들

• Product backlog : 우선 순위가 부여된 작업 목록
  * 고객의 우선순위, feedback급한 정도, 구현 난이도, 작업간 의존성
• Sprint backlog : Product backlog중에서 해당 스프린트를 위해 선택 된 것들. + 세부 작업들을 포함

• Burndown Chart : 남아있는 작업량에 대한 그래프
• Burnup Chart : 한 작업량에 대한 그래프

-> 중간에 예상치 못한 작업이 생겨서 그래프가 바뀔 수 있다.
-> burndown의 경우, 예상치 못한 작업이 생긴다면, 작업이 추가됐다는 사실을 알아차리기 어렵다.(새로 생긴 일을 오늘 다 처리할 수 있으므로)

• KanbanBoard
  
  : To-do, WIP, Done으로 구성된다.
  : 가급적 빨리 to-do에서 done으로 옮기는게 목표임.

애자일 정리

<장점>

• 빠르고 잦은 배포로 고객 관점에서 상황이 잘 보인다.
• 요구사항에 빠른 대처 가능(유연함).
• 개발 속도가 빠르다.

<단점>

• 고객과의 상호작용으로 업무량 증가.
• 프로젝트 종료 개념이 명확하지 않아서 비용 파악이 어려움.

DevOps

Development + Operation : 개발팀과 운영팀을 묶어서 개발자가 전 과정을 다 하는 것.
개발, 테스트, 배포, 운영, 모니터링