프로세스 없는 개발 (Code-and-fix)

• 설계 작업의 중요성을 깨닫지 못함
• 계획이 없어 작업 목표가 없음
• 체계적인 테스트/품질보증 활동 필요성 인식이 없음

---

프로세스 vs 방법론 비교

프로세스(Process)

소프트웨어를 개발하는 공정

• 단계적인 작업의 틀을 정의
• 무엇을 하는가(What) 중심
• 결과물이 “어떻게 표현되는지”는 언급 없음
• 패러다임에 독립적
• 각 단계는 다른 방법론으로도 실현 가능
• 예: 폭포수, 나선형, 프로토타이핑, Unified, 애자일

방법론(Methodology)

• 프로세스의 구체적인 구현(실행 방식)
• 어떻게 하는가(How) 중심
• 결과물을 어떻게 표현하는지까지 제시
• 패러다임에 종속적
• 단계별 절차/기술/가이드라인 제시
• 예: 구조적 분석·설계, 객체지향, 컴포넌트, 애자일 방법론

---

1 소프트웨어 생명주기 (Software Life Cycle)

• 소프트웨어 개발에 대한 기술적 + 관리적 이슈를 다루는 작업
• 개발 모델에 따라 컴포넌트 프로세스/부프로세스가 존재
• 각 프로세스는 목적이 다를 수 있으나 서로 협력해 전체 목적을 만족

• 요구분석 → 설계 → 구현 → 테스팅 → 유지보수

---

2 프로세스

프로세스 정의

• 소프트웨어 시스템을 구축하기 위해 수행되는 작업의 단계
• 개발의 기술적/관리적 이슈를 다루는 작업

프로세스 모델

• 일반적인 프로세스를 추상적으로 기술한 것
• 프로젝트를 위한 작업의 단계와 순서, 각 단계 작업 수행의 제약 사항이나 조건 등을 모아 둠
• 프로세스 : 구체적인 작업 흐름
• 프로세스 모델 : 프로젝트를 위하여 알맞은 프로세를 개발하기 위한 일반적인 가이드라인

프로세스 명세와 프로세스 모델

프로세스의 종류

• 프로젝트 중심 프로세스
  • 개발 프로세스
  • 관리 프로세스
• 기타 프로세스
  • 형상 관리 프로세스
  • 프로세스 관리 프로세스

2.1 프로세스 정의

프로세스를 명확하게 설명하기 위한 최소한의 정의

• 목적

• 작업 방법

  • 프로세스에서 해야 할 작업이 무엇인지 명시

• 성과

작업 결과와 검증 조건을 명확히 정의

작업 방법

진입 조건 / 출구 조건

좋은(바람직한) 프로세스의 특성

• 예측 가능성
  

• 테스팅과 유지보수 용이성
  

• 변경 지원(변경을 쉽게 다룰 수 있어야 함)
  

• 결함 제거
  

초반에 결함을 잡아두는 것이 뒤에서 결함을 찾는거보다 좋다.

---

2.2 프로세스와 품질

강의록 x

3 전통적인 모델 ←시험 많이 나올 수 있음

프로세스 모델 정의

• 일반적인 모델이 될 만한 프로세스를 기술한 것

대표 프로세스 모델

• 폭포수 모델
• 프로토타이핑 모델
• 나선형 모델
• 진화적 모델
• Unified Process
• 애자일 프로세스

---

3.1 폭포수(Waterfall) 모델

• 가장 오래되고 널리 사용된 프로세스 모델
• 각 단계는 다음 단계 시작 전에 완료되어야 함(순차적)
  • 다시 위로 돌아가는 경우는 없다.
  • 역할 분담이 확실하다.
• 단계 결과는 다음 단계 전 점검
• 직능 중심 조직에 적합
• 각 단계가 끝난 후 결과물 정의가 중요

적용 분야

• 크고 복잡하고 오래 지속되는 프로젝트에 적합
• 교수: 이게 맞는 말인지 모르겠다. 오히려 안좋은거 같다.
  왜냐하면, 설계자와 구현자 등이 분단되어 있기 때문.

V 모델

• “검증을 강화”하는 관점에서 폭포수 모델을 확장한 모델

코딩 단계에서 위로 꺾여 올라가며 검증한다.

• 알파 테스트(Alpha test): 개발사(내부) 환경에서 개발자/QA가 먼저 하는 사전 테스트
• 베타 테스트(Beta test): 실제 사용자/고객 환경(고객이 처한 상황)에서 사용자가 참여해 하는 현장 테스트

장점

• 단순해서 초보자도 적용 쉬움
• 중간 산출물이 명확해 관리 용이
• 코드 생성 전 충분한 연구/분석 단계 확보

단점

• 불필요한 문서가 많이 생성될 수 있음
• 애매한 부분/진행 중 변경을 수용하기 어려움
• 테스트가 후반(시스템 완성 후)에 시작됨 → 결함을 수정할 때 비용이 많이 든다.

---

3.2 프로토타이핑(Prototyping) 모델

• 요구사항 피드백을 받기 위해 시스템을 실험적으로 만들어 사용자에게 보여주고 평가하게 하는 방법
• 도구 예: 화면 생성기, 동작 시뮬레이션 등 (피그마)
• 사용자-개발자 의사소통을 돕는 공동 참조 모델 역할

프로토타입을 만들고 허가되면 그대로 진행하면 되고, 안되면 다시 만들어야한다.
→ 개발 부담될 수 있다.

프로토타입은 쓰고 버리는 일회용과 계속 발전시켜 나가는 진화형으로 나눌 수 있음.

프로토타입 목적

• 단순 요구 추출(만들고 버림)
• 제작 가능성 타진(개발 단계에서 유지보수까지 이어질 수 있음)

장점

• 사용자 의견 반영이 잘 됨
• 사용자의 참여/관심 증가, 요구를 더 정확히 도출 가능

단점

• 오해/기대심리 유발 가능 → 최종 산출물이 예상보다 안좋을 수 있음
• 중간 산출물 정의가 난해해서 관리가 어려움

적용 상황

• 개발 착수 시점에 요구가 불투명할 때
• 실현 가능성을 실험적으로 타진하고 싶을 때
• 혁신 기술을 적용해보고 싶을 때

---

3.4 나선형(Spiral) 모델

• 1986년 Boehm이 제안
• 기능을 나누어 점증적으로 개발
  • 실패 위험 감소
  • 테스트 용이
  • 피드백 가능
• 여러 번의 점증적 릴리스(incremental releases)

4가지 단계를 반복 순환하면서 시스템을 확장

1. 목표/방법/제약 조건 결정
2. 위험 요소 분석 및 해결
3. 개발과 평가
4. 다음 단계 계획

장점

• 대규모 시스템에 적합(리스크 감소 메커니즘)
• 반복 개발/테스트로 강인성 향상
• 한 사이클에 못 넣은 기능을 다음 단계에 추가 가능

단점

• 관리가 복잡 : 중간마다 확인하고 그 다음에 나아가는게 관리의 어려움
• 위험 분석이 과하거나 잘못되면 피해가 큼
• 성공 사례가 많이 알려지지 않음

적용 상황

• 재정적/기술적 위험 부담이 큰 경우
• 요구사항/아키텍처 이해가 어려운 경우

---

3.3 진화적(Evolutionary) 모델

• 개발 사이클이 짧아야 하는 환경(빠른 출시가 이윤에 직결)
• 개발 시간을 줄이기 위해 시스템을 나누어 릴리스
  • 1차 릴리스 = MVP(최소 기능)
  • 이후 릴리스 = 피드백 반영해서 기능 추가/개선(진화적으로 발전)

릴리스 구성 방법

• 점증적 방법: 기능별로 릴리스
• 반복적 방법: 릴리스 할 때마다 기능 완성도 향상

장점

• 일부 기능이 부족해도 초기부터 사용 교육 가능
• 사용자 요구를 빠르게 반영
• 신기능 SW 시장을 빨리 형성
• 운영 중 예상치 못한 문제를 신속/꾸준히 개선 가능

단점

• 관리가 복잡해져 큰 프로젝트엔 부적합
• 끝이 안 보일 수 있어 실패 위험 증가
• 진행이 위험 분석에 크게 의존

나선형 모델과 비슷하지만, 나선형은 종착지를 정해두고 길게가는 느낌이고, 진화적 모델은 최종 종착지는 모르겠지만 짧게 기획을 세우면서 발전해 나간다.

---

3.6 Unified Process

• 시간 흐름 속에서 여러 디스플린(요구/분석/설계/구현/테스트/배포/형상·변경관리/프로젝트관리)이 반복적으로 수행됨
• 처음에는 비즈니스 모델링에 방점을 두고 진행하고, 다음에는 요구에 방점을 두고 진행하는 방식

4단계

1. 도입(Inception): 1~2회 반복 / 간단 유스케이스 모델, 구조, 계획 작성
2. 정련(Elaboration): 여러 번 반복 / 대부분 유스케이스 작성 + 아키텍처 설계
3. 구축(Construction): 남은 유스케이스 구현·통합 / 목표 환경에 점증적 설치
4. 전환(Transition): 배치·교육 / 베타테스트, 결함 수정, 기능 개선

장점

• 문서화가 잘 되어 있어 교육받기 좋음
• 요구 변경 리스크를 적극적으로 해결
• 통합 노력/시간 감소
• 코드 재사용이 쉽고 빠름

단점

• 너무 복잡해서 이해/정확한 적용이 어려움
• 협동/의사소통 가이드가 없음
• 조직화되지 않은 개발로 이어질 수 있음

---

4 애자일(Agile) 프로세스

• 2~6주 단위의 짧은 주기(스프린트)로 반복 개발
• 현재 상황에 가장 잘 맞는 프로세스
• 실행되는 SW를 개발해 점진적으로 전체 시스템 완성

  애자일 선언

  1. 형식적 문서보다 커뮤니케이션으로 목표 지향
  2. 문서가 아니라 실행되는 SW로 요구 확인
  3. 비즈니스 환경에 따라 요구가 중간에 바뀔 수 있음을 고려
  4. 짧은 주기 안에 요구정의-구현-테스트까지 수행하고, 회고 의견을 다음 계획에 반영

• Epic(에픽): 큰 목표/기능 묶음(여러 스토리 포함)
• Story(스토리): 사용자 관점의 기능 단위(에픽을 쪼갠 요구사항)
• Task(태스크): 스토리를 구현하기 위한 구체 작업(개발/테스트/문서 등)
• Sub-task(서브태스크): 태스크를 더 잘게 쪼갠 작업(선택)
• Backlog(백로그): 해야 할 일 목록 (피드백)
  • Product Backlog: 전체 할 일(에픽/스토리/버그/개선 등)
  • Sprint Backlog: 이번 스프린트에서 할 일(선택된 스토리/태스크)
• Post-mortem(포스트모템): 배포/장애/이슈 같은 “사건” 이후에 원인·영향·대응·재발방지 액션을 정리하는 사후 분석 문서/회의(Blameless로 진행하는 경우 많음)

---

(수업 추가) Brooks’ Law / Man-hour 관점

• Brooks’ Law: 나중에 고치려고 할수록 수정 비용이 더 많이 든다
• Man-hour(맨아워) 관점: 후반에 인력을 더 투입하면 단순히 빨라지는 게 아니라, 협업/커뮤니케이션 비용 때문에 인력을 쓰는 시간 자체가 늘어날 수 있다
• 그래서 애자일은 뒤로 갈수록 수정비용이 커지는 걸 줄이기 위해, 스프린트로 잘게 나눠 자주 점검/수정하면서 진행한다고 보면 됨

4.1 애자일 모델의 특징

• 가장 큰 특징 : 설계보다 코딩 중심!
• 개발 사이클이 짧고 반복적
• 기존의 모델들은 구현할 때 개발하는 시스템이 이미 결정되었다는 전제이지만 애자일에서는 변화하는 요구를 빨리 받아들이고 빨리 개발할 수 있게 하자는 것이 특징.

1. 짧은 개발 주기의 반복
   단기간에 반복 주기로 개발하면서 중간 결과를 확인
2. 우선순위
   모든 기능을 같은 우선순위로 한꺼번에 만드는 전통적인 방법과 달리 우선순위가 높은 기능부터 개발
3. 변하는 범위
   구현 범위를 고정하지 않고 유연하게 대처
4. 프로젝트 팀
   전통적인 프로세스는 각 단계별로 분업화를 추구하지만, 애자일은 함께 일하는 팀이라는 개념으로 모든 것을 제안하고 수행한다.

장점

• 빠르게 배포하여 빠른 피드백을 받을 수 있다.
• 항상 최신 작업을 수행 → 자원의 낭비가 적음
• 문제와 결함을 빨리 감지하고 수정
• 불필요한 문서화에 시간을 덜쓴다. 또한 비용이 저렴하므로 아이디어를 실험하고 테스트할 수 있다.

단점

• 문서화 등한시 → 새로운 개발자가 속도를 높이기 어려움
• 개발자와 고객이 지속적으로 상호작용 → 모든 사람에게 더 많은 시간과 에너지를 요구
• 명확한 끝이 정의되지 않으면 프로젝트가 종료되지 않고 계속될 수 있음
• UX 및 아키텍처 관점에서 전체적인 디자인이 부족하여 제품을 완성시키기 위한 작업이 더 많이 들 수 있음

---

4.2 익스트림 프로그래밍(XP)

• 애자일의 프레임워크(방법)
• 소규모 개발 조직이 불확실하고 변경이 많은 요구를 접하였을 때
• (교수님 코멘트) DevOps는 XP의 실천 중 자동화 테스트·지속적 통합(CI)·빈번한 릴리스처럼 배포/운영과 연결되는 부분을 상당 부분 커버한다.
  • 단, XP의 전부(예: 페어 프로그래밍, 현장 고객 등)를 의미하진 않음.

• 사용자 스토리

  • 각 기능의 비즈니스 가치와 우선순위를 정한 것.
  • 긴 요구사항 문서가 아니라 간결한 문장으로 표현한 시스템의 기능

• 매일 빌드와 통합 (거의 상시로 돌아가는 흐름)

• 테스트 주도 개발(TDD): 커밋함과 동시에 테스트

  • → 커밋 전에 충분히 검증하고 올려야 함
  • 젠킨스(ci/cd)를 실습할 예정

• 페어 프로그래밍: 짝을 이뤄 개발(옆에서 즉시 코드 리뷰/검토, 실제 코드를 보고 확인)
  - 하나의 컴퓨터를 두명이 공유하면서 한명은 코딩, 한명은 확인
  - 역할을 바꿔가면서 구현해 나감

(수업 코멘트) 개발자는 AI 대체 1순위라고도 하지만, 품질 보증(QA)·테스트 직군은 살아남을 여지가 있음

---

4.4 스크럼(Scrum)

• 애자일의 대표적인 프레임워크(방법)
• 팀원 전원이 소통/협력하여 짧은 주기를 반복하며 개발(작업·역할·결과물 포함)
• 빠른 결함 발견 및 수정 → 폭포수모델의 반대
• 백로그를 정하고 팀원들과 협의해 우선순위를 부여
  백로그: 제품 개발을 위하여 남겨진 일
• 짧은 주기(스프린트)로 진행
• 스크럼 미팅 = 데일리 미팅(데일리 스크럼): 매일 진행 상황 공유/동기화

이벤트

• 스프린트 계획 회의
  프로덕트 오너와 팀이 스프린트 주기 동안 무엇을 구현할 것인지 결정
• 일일 스크럼
  팀 멤버가 같이 모여서 제대로 진행되는지 확인하고 도움을 요청하는 짧은 회의
• 스프린트 리뷰
  스프린트 주기 마지막에 이루어짐.
  필요하면 프로덕트 백로그를 조정한다.
  다음 스프린트에 무엇을 할지 의논.
• 스프린트 회고
  스프린트 리뷰가 끝난 후 마지막 날에 그동안의 결과와 얻은 교훈, 개선 점등을 논의하여 다음 스프린트에 반영시킨다.

스크럼 산출물

• 프로덕트 백로그
  개발을 위하여 남아 있는, 즉 작업하여야 할 요구나 사용자 스토리의 순서 리스트.
• 스프린트 백로그
  현재 수행 중인 스프린트에서 해야 할 작업의 순서 리스트.
• 동작하는 소프트웨어
  이전의 모든 스프린트와 현재의 스프린트에서 구현된 요구의 총합.
  완전체는 아니지만 배포 가능하여야 함.

---

2.4 지원 프로세스

교재에서 2에 해당

2.2 프로세스와 품질

관리 프로세스

• 비용·품질 목표 달성을 위해 프로젝트 관리에 필요한 모든 작업 관리 프로세스 작업의 분류 - 계획 프로젝트의 목적에 맞는 소프트웨어 개발 계획을 세움 - 모니터링 수행하는 모든 작업이 프로젝트의 목적에 부합되며 개발이 계획대로 진척되는지 확인하기 위하여 여러 데이터를 수집한다. - 분석과 조절 모니터링에 의하여 확인된 사실을 분석하고, 계획과 차이나는 부분에 대하여 조정하고 조치한다.
• 프로젝트 모니터링/제어는 개발의 모든 단계를 포함 → 가장 긴 기간 동안 수행

품질 보증 프로세스

• 프로세스/프로덕트 품질을 관리하고 향상
• 인스펙션 프로세스
  • 개발 결과에서 결함을 찾거나 방지하려는 노력
  • 정의된 프로세스에 따라 동료 그룹이 작업 결과를 검사
• 프로세스 관리 프로세스

형상 관리 프로세스

• 개발 중 발생하는 변경을 체계적으로 컨트롤
• 개발작업과 독립적인 작업

---

5 방법론

• 방법론: 소프트웨어 프로세스의 각 작업을 어떻게 수행할지 정의
• 프로세스: 개발할 때 해야 하는 작업을 주로 명시(관계 표현은 약함)

구조적 방법론 ←여기부터 그냥 스킵함

• 분리와 정복(divide and conquer) 원리 적용
• 자료 흐름도를 구조도로 변경하는 과정
  • 구조도: 모듈 사이 관계를 나타내는 그래프

정보공학 방법론(특징)

• 기업 중심
• 전략적 시스템 계획 중심
• 데이터 중심
• 분할과 정복
• 공학적 접근
• 사용자의 적극적 참여

객체지향 방법론

• 자료와 함수를 가까운 곳에 정의해 객체로 묶고, 객체 사이 메시지 호출로 기능을 수행
• 객체지향 패러다임 기반

---