소프트웨어의 이해

• 프로그램: 프로그래밍한 source code
• 소프트웨어: 프로그램을 비롯해 개발 과정에서 생성되는 모든 산출물(자료구조, DB 등)과 각 단계에서 만들어지는 문서, 메뉴얼 등을 모두 포함하는 것
• 소프트웨어 공학 -> 소프트웨어 개발 과정에 공학적 요소를 접목시켜 개발 과정에서 생산성을 높이고, 고품질의 소프트웨어를 생산해 사용자를 만족시키는 것
  소프트웨어 개발 과정: 하나의 제품인 소프트웨어를 만들기 위해 일련의 과정을 의미함

소프트웨어의 특징

• 제조되지 않고 개발됨 -> 프로그래머의 실력에 따라 결과물의 차이가 커짐
• 소모가 되지 않지만 사용자의 요구 등으로 인해 품질이 저하될 수 있음
• 개발 과정이 복잡하고, 참여 인력이 많으며, 개발 기간이 길음 -> 개발의 복잡함을 줄이기 위한 방법과 기술이 필요하고, 팀을 구성하고 관리하는 효율적 방법이 필요하며, 프로젝트를 효율적으로 관리하기 위한 체계가 필요함

소프트웨어 개발 프로세스

• 프로세스: 주어진 일을 해결하기 위한 목적으로 그 순서가 정해져 수행되는 절차
• 소프트웨어 개발에서 프로세스는 일을 수행하는 작은 단위인 작업(task)들의 집합들과 일정, 예산과 가튼 제약 조건을 포함하는 일련의 활동으로 볼 수 있음 -> 소프트웨어 개발 목적을 이루는데 필요한 통합적 수단
• 소프트웨어 개발 프로세스를 통해 시행착오를 줄이고 빠르게 일을 수행할 수 있는 가이드 역할 수행
• 소프트웨어 개발 프로세스 모듈을 통해 소프트웨어를 개발하는 전 과정을 하나의 프로세스로 정의할 수 있음 -> 프로젝트에 대한 기본 골격을 세워주고 일정 계획이나, 비용 산정 등에 도움을 주게 됨

주먹구구식 모델

• 가이드라인이나 프로세스가 없는 개발 방식
• 코드를 작성해 제품을 만든 뒤 요구분석, 설계, 유지보수에 대해 생각하게 됨 (문제가 있으면 수정하고 없으면 그대로 사용)
• 개인이 빠르게 작업을 마칠수 있을때 사용가능한 정도고, 실제 개발에 사용하기에는 어려운 모델임

선형 순차적 모델

• 폭포수(waterfall) 모델로도 불림
• 소프트웨어 개발 생명주기(Sowfware Development Life Cycle)에 맞춘 프로세스를 통해 소프트웨어를 순차적으로 개발하게 됨
• 이 과정은 계획 -> 분석 -> 설계 -> 구현 -> 테스트 -> 유지보수의 순서를 가짐
• 각 단계가 끝날 때마다 이를 확실히 정리하고 다음단계로 넘어가며, 반대로 돌아가지 않음
  ex) 요구사항 분석 단계가 끝나면 요구분석명세서를 작성해 사용자에게 이상유무를 확인 -> 확인이 완료되면 설계 절차로 넘어감
• documentation이 체계적이고 프로젝트 관리가 용이하다는 장점이 있음
• 각 단계는 반드시 앞 단계가 완료되야 수행할 수 있고, 추후 문제점을 해결하기 어려우며, 사용자가 중간에 결과물을 볼 수 없다는 단점이 있음
• 초기에 어느정도 요구사항이 확정되는 변화가 적은 프로젝트에 적합한 모델
• 폭포수 모델의 단점을 보완하기 위해 테스트 단계를 확장한 V모델이 존재함
  V 모델은 모듈 설계를 검증하기 위한 단위 테스트, 아키텍쳐 설계를 검증하기 위한 통합 테스트, 요구분석 내용을 검증하기 위한 시스템 테스트와 최종적인 인수 테스트를 거치게 됨

진화적 프로세스 모델

• 선형 프로세스 모델의 단점을 보완하기 위한 방식
• 최초의 사용자 요구를 반영한 프로토타입을 만들고, 이를 기반으로 추가적인 요구사항들을 반영하는 과정을 반복하게 됨
• 완성 제품을 대폭 수정하게 되는 상황을 미리 방지하고, 사용자가 만족할 수 있는 완제품 개발에 도움이 됨

프로토타입 모델

• 정식 절차에 따라 소프트웨어를 만들기 전에 프로토타입을 만들고, 피드백을 받아 수정해 가는 방식을 사용한 모델
  프로토타입을 만드는 것을 포로토타이핑(prototyping)이라 함
• 프로토타이핑은 요구사항을 정의하고 분석하는 과정에서 시행하며, 프로토타입이 완성된 다음 설계 단계로 넘어가게 됨
• 폭포수 모델에서는 요구사항 정의를 완전하게 명세한 다음 설계로 넘어가지만, 프로토 타입 모델에서는 개략적인 요구사항을 정의한 뒤에 프로토타입을 계속 만들어가는 과정에서 완성도를 높임
• 프로토타입 개발시에는 시스템의 동작과정의 대략적인 모습을 보여주기 위해 사용자 인터페이스를 중심으로 설계하게 됨
• 사용자의 요구가 불투명하고 요구사항의 변화가 계속 발생하는 경우에 적합함
• 사용자의 요구가 충분히 반영되어 유지보수에 필요한 노력, 시간을 줄일 수 있지만, 투입 인력과 비용 산정이 어렵고, 프로토타이핑 과정을 관리, 통제하기 어렵다는 단점이 있음

나선형 모델

• 계획 및 요구분석, 프로토타입 개발 사이에 위험 분석 단계를 추가하여 반복하는 모델
• 위험 요소는 요구사항의 변경, 경험 부족, 프로젝트 관리 부재 등 소프트웨어 개발 과정이 순조롭게 진행되는데 방해되는 모든 것을 의미함
• 나선형 모델은 계획 및 요구분석 -> 위험 분석 -> 개발 -> 사용자 평가의 과정을 수정 및 추가 요구가 없을때까지 반복하게 됨
• 프로젝트가 중단되는 위험을 줄이고, 반복된 개발을 통해 사용자 요구를 충분히 반영할 수 있다는 장점이있 음
• 나선형 모델의 반복으로 인해 프로젝트 기간이 길어지고, 관리가 어려워진다는 단점이 있음

단계적 개발 모델

• 릴리즈1을 사용하는동안 릴리즈2를 개발하고, 릴리즈 2를 배포하고 사용하는 동안 릴리즈3을 개발하는 것처럼 개발과 사용을 병행하는 과정을 반복하는 개발 모델
• 단계적 개발 모델은 점증적 개발 방법과, 반복적 개발 방법으로 나뉘며, 실제 개발에서는 둘을 함께 사용하는 경우가 많음

점증적 개발 방법

• 요구분석명세서에 명시된 시스템 전체를 기능에 따라 서브 시스템으로 분할하고, 하나씩 릴리스해 완성해가는 방법
  ex) 종합정보시스템을 개발할 때 교무/학사 시스템을 우선 개발하고, 나중에 회계 업무 등의 추가 기능을 구현해나가는 것
• 한번에 많은 비용을 들이지 않고, 시스템 변화에 따른 조직의 충격을 줄일 수 있다는 장점이 있음
• 서브시스템 사이의 연관성을 고려해야 하기 때문에 두번째 이후 서브시스템을 개발할 때 어려움이 생길 수 있다는 단점이 있음

반복적 개발 방법

• 처음에 시스템 전체를 일차적으로 개발하고, 각 서브시스템의 기능과 성능을 보강해 완성도를 높이는 방법
• 초기의 요구사항이 불문명한 경우에 적합함

통합 프로세스 모델

• 선형 프로세스 모델을 반복하는 반복적 개발 방법론에 기반함
• 크게 도입, 구체화, 구축, 전이의 4단계로 나뉘고, 각 단계도 여러개의 작은 단위로 나누어 각 구간을 정복해 나감
• 반복 주기를 시작하기전에 기준선을 세우고 반복 주기가 끝나면 실행 가능한 산출물이 도출됨
• 각 단계에서 형상관리, 프로젝트 관리, 환경 점검은 지속적으로 수행함

도입 단계(inception phase)

• 준비 단계, 시작 단계 등으로 불리며 막 시작하는 단계로 구현, 테스트, 배치 작업은 거의 없음
• 대신 비즈니스 모델링, 요구사항 정의 관련 작업을 많이 하게 됨

구체화 단계(elaboration phase)

• 상세 단계로도 불리며, 보통 2-4개의 반복 단위로 구성됨
• 비즈니스 모델링, 요구사항 정의 작업이 줄어들고, 분석 및 설계 작업이 가장 활발하게 이루어지며, 구현 및 테스트 작업이 이루어지기 시작함

구축 단계(construction phase)

• 구현 작업이 가장 많이 이루어지고, 테스트 작업도 증가하게 됨
• 완성된 작업물을 배치하는 양 역시 증가하게 됨

전이 단계(transition phase)

• 이행 단계라고도 하며 사용자를 위한 제품을 완성하는 단계
• 사용자에게 완성된 제품을 넘겨주기 위한 작업을 하며 배치 작업이 주를 이루게 됨

애자일 프로세스 모델

• 고객과의 협업, 빠른 시간안에 고객이 작동해볼 수 있는 소프트웨어 제작, 환경과 고객의 변화에 능동적으로 대처하는 것을 강조하는 프로세스 모델
• 애자일 프로세스 모델을 시행하기 위해 스크럼, 익스트림 프로그래밍 등이 있음

스크럼

• 팀의 개선과 프로젝트 관리에 중점을 둔 애자일 방법론
• 제품 기능목록 작성 -> 스프린트 계획 회의 -> 스프린트 수행 -> 스프린트 회고의 순으로 진행됨
• 단순하며 프로젝트의 진행 현황이 뚜렷히 보이고 팀원간의 역할 분담과 조율에 유리하다는 장점을 가짐
• 스프린트마다 제품이 나와야 하고, 회의 시간이 길어지면 작업에 방해가 되며, 프로세스 품질을 평가하지 않는다는 단점을 가짐

제품 기능목록

• 사용자가 요구하는 제품의 기능 목록이며, 일반적인 개발론에서의 기능 목록과 유사함
• 기능 목록은 고객 측 대표인 제품 책임자가 결정함
• 제품 기능이 도출되면 각 기능을 간략하게 서술하는 사용자 스토리를 작성하게 됨
  사용자 스토리는 사용자가 필요로 하는 내용을 간략하면서도 수치 등을 포함해 구체적으로 서술해야 함
• 개발자는 사용자 스토리를 바탕으로 업무량의 상대적 크기를 이용해 스토리 포인트를 산정함, 이를 통해 요구사항의 규모를 측정할 수 있게 됨

스프린트 계획 수립

• 스토리 포인트 내에서 어떠한 것을 구현하고, 누구에게 배정할 것인지를 정하는 부분
  스프린트의 기간은 1-4주 정도로 정함
  제품 책임자를 통해 사용자의 요구사항을 파악해 우선순위가 높은 항목부터 구현하게 됨
• 결정된 스프린트의 목표와 내용은 개발 도중에 바뀌어서는 안되고, 누구든지 팀원의 동의 없이 바꿀수 없음 -> 이를 수행하도록 도움을 주는 사람을 스크럼 마스터라고 부름

스프린트 수행

• 실제로 스프린트를 진행하는 시기로, 날짜별 남은 작업량을 나타내는 소멸차트, 스프린트 현황판등을 활용해 작업물을 만들어감
• 매일 간단한 스크럼 회의를 진행해 스크럼 팀원들의 스프린트 진행 상황을 확인하고 스프린트 마스터는 스프린트가 잘 진행될 수 있도록 문제사항을 해결하게 됨
• 제품 책임자는 이단계부터는 팀 운영에 관여하지 않음

스프린트 회고

• 스프린트가 완료되면 실행 가능한 제품을 검토하고 개선할 점등에 대한 피드백을 하는 회의를 진행함
• 스프린트 검토 회의가 끝나면 스프린트 회고를 진행하며, 팀의 강점을 찾는데 집중하면서 스프린트를 피드백하게 됨

익스트림 프로그래밍(eXtreme Programming)

• 수시로 발생하는 고객의 요구사항에 유연히 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법
• 짧고 반복적인 개발주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발하는 것이 목적
• 릴리즈의 기간을 짧게 반복 => 고객의 요구사항 반영에 대한 가시성을 높임
• 의사소통, 단순성, 용기, 존중, 피드백의 5가지 핵심가치를 지님
• 아래 사진과 같은 프로젝트 과정을 거치게 됨
  
  릴리즈 계획 수립: 부분 혹은 전체 개발 완료 시점에 대한 일정을 수립하는 것
  주기(Iteration): 실제 개발 작업을 시행하는 부분으로 1-3주 소요
  승인 검사: 하나의 이터레이션 안에서 부분 완료 제품이 구현되면 수행하는 테스트
  소규모 릴리즈: 요구사항에 유연히 대응하기 위해 릴리즈 규모를 축소함

XP의 주요 실천 방법

• Pair programming(짝 프로그래밍): 다른 사람과 함께 프로그래밍을 수행 -> 개발에 대한 책임을 공동으로 나눠 갖는 환경을 조성함
• Collective Ownership(공동 코드 소유): 개발 코드에 대한 권한과 책임을 공동으로 소유함
• Test-Driven Development(테스트 주도 개발): 개발자가 실제 코드를 작성하기 전에 테스트 케이스를 먼저 작성
  테스트가 지속적으로 진행되도록 자동화된 테스팅 도구(구조, 프레임워크등)를 사용
• Whole Team(전체 팀): 고객을 포함한개발에 참여하는 모든 구성원은 각자 자신의 역할이 있고 그 역할에 대한 책임을 가져야 함.
• Continuous Integration(계속적인 통합): 모듈 단위로 나눠 개발된 코드들은 하나의 작업이 마무리될 때마다 지속적으로 통합됨
• Refactoring(리팩토링): 프로그램 기능 변경 없이 시스템을 재구성함.
  프로그램을 쉽게 이해하고 수정하여 빠르게 개발하는데 도움이 됨
• Small Releases(소규모 릴리즈): 고객의 요구 변화에 신속히 대응하기 위해 릴리즈 기간을 짧게 반복함

출처:
쉽게 배우는 소프트웨어 공학 2판, 김치수, 한빛아카데미