소프트웨어란? / 소프트웨어 공학이란? / 소프트웨어 생명주기란? / 6가지 소프트웨어 개발 모델 / 스크럼이란? / XP 란?

소프트웨어(Software)란?

소프트웨어란 컴퓨터 시스템을 효율적으로 운영하기 위해 개발된 프로그램의 총칭. 컴퓨터에게 동작 방법을 지시하는 명령어 집합, 프로그램의 모임임.

 

소프트웨어 공학(Software Engineering) 이란?

소프트웨어 공학은 소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문임. 여러가지 방법론과 도구, 관리 기법들을 통해 소프트웨어의 품질과 생산성 향상을 목적으로 함.

소프트웨어 공학의 기본 원칙
① 현대적인 프로그래밍 기술을 계속적으로 적용해야 함.
② 개발된 소프트웨어의 품질이 유지되도록 지속적으로 검증해야 함.
③ 소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록을 유지해야 함.

 

소프트웨어 생명 주기란?

소프트웨어 생명 주기는 소프트웨어 개발 방법론의 바탕이 되는 것으로, 소프트웨어를 개발하기 위해 정의하고 운용, 유지보수 등의 과정을 각 단계별로 나눈 것임.

• 소프트웨어 생명 주기는 소프트웨어 개발 단계와 각 단계별 주요 활동, 그리고 활동의 결과에 대한 산출물로 표현하며 소프트웨어 수명 주기라고도 함.
• 소프트웨어 생명 주기를 표현하는 형태를 소프트웨어 생명 주기 모형이라고 하며, 소프트웨어 프로세스 모형, 소프트웨어 프로세스 모델, 소프트웨어 공학 패러다임 이라고도 함.

폭포수 모델 (Waterfall Model)

폭포수 모형은 폭포에서 한번 떨어진 물은 거슬러 올라갈 수 없듯, 소프트웨어 개발도 이전 단계로 돌아갈 수 없다는 전제하에 각 단계를 확실히 매듭짓고, 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행하는 개발 방법론.

• 폭포수 모형은 소프트웨어 공학에서 가장 오래되고 가장 폭넓게 사용된 전통적인 소프트웨어 개발 프로세스 모델임.
• 소프트웨어 개발 과정의 한 단계가 끝나야만 다음 단계로 넘어갈 수 있는 선형 순차적 모형임.
• 모형을 적용한 경험과 성공 사례가 많음.
• 각 단계가 끝난 후에는 다음 단계를 수행하기 위한 결과물이 명확하게 산출되어야 함.

최초의 폭포수 모델 / 출처: 위키백과

V 모델

V 모델은 폭포수 모델에 테스트 단계를 추가한 모델임. 각 개발 단계를 검증하는데 초점을 둔 모델임.

• 프로세스가 단순하여 초보자도 쉽게 적용 가능함.
• 중간 산출물이 명확하여 관리하기 편함.
• 코드 생성 전 충분한 연구와 분석 단계 시간이 주어짐.

V모델 / 출처: 위키백과

프로토타이핑 모델(prototyping model)

프로토타입은 대량 생산에 앞서 미리 제작해보는 시제품으로, 정식절차에 다라 완전한 소프트웨어를 만들기 전 사용자의 요구를 받아 일단 모형을 만들고 이 모형을 사용자와 의사소통하는 도구로 활용함. 

• 기능이 부족하더라도 초기에 사용 가능하고 피드백 반영이 가능하여 의사소통 도구로 활용 가능함.
• 사용자 요구가 충분히 반영된 요구 분석 명세서 작성 가능함.
• 초기 프로토타입 사용을 통한 새로운 요구사항 발견 가능함.
• 프로토 타입 사용을 통한 완성품 예측 가능함.
• 빠른 개발을 요구하는 분야에 적합함.
• 시장을 고속화하여 형성시킬 수 있음.
• 소프트웨어를 배포할 때마다 다른 전문 영역에 초점을 둘 수 있으며 예상하지 못했던 문제를 유지보수할 수 있음.

프로토타이핑 모델 / 출처: Shiksha

 

나선형 모형 / 점진적 모델 (Spiral Model)

나선형 모형은 보헴(Boehm)이 제안한 것으로 폭포수 모형과 프로토타입 모형의 장점에 위험분석 기능을 추가한 모형임.

• 나선을 따라 돌듯이 여러번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발.
• 소프트웨어를 개발하며 발생할 수 있는 위험을 관리하고 최소화하는 것을 목적으로 함.
• 점진적으로 개발 과정이 반복되므로 누락되거나 추가된 요구사항을 첨가할 수 있고 정밀하며 유지보수 과정이 필요없음.

나선형 모델 / 출처: IT위키

반응형

진화적 프로세스 모델 (Evolutionary process model)

진화적 프로세스 모델은 단계를 거스르기 힘든 구조인 폭포수 모델의 단점을 보완하여 반복적인 수정요구를 즉시 반영할 수 있는 프로세스로 프로토타이핑 모델과 비슷함.

• 개발자는 초기 사용자 요구에 따라 프로토타임을 개발함.
• 사용자는 프로토타입을 확인하고 요구사항을 추가 및 변경함.
• 요구사항을 반영하여 개발자는 2차 프로토타입을 개발함.

진화적 프로세스 모델 / 출처: GeeksforGeeks

애자일 모델 (Agile Model)

애자일은 민첩한, 기민한 이라는 의미로 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하는 개발과정임.

• 애자일 모델은 어느 특정 개발 방법론이 아니라 좋은 것을 빠르고 낭비 없게 만들기 위해 고객과의 소통에 초점을 맞춘 방법론을 통칭함.
• 애자일 모형은 기업활동 전반에 걸쳐 사용됨.
• 애자일 모형을 기반으로 하는 소프트웨어 개발 모형에는 스크럼(Scrum), XP(eXtreme Programming), 칸반(Kanban), Lean, 크리스탈(Crystal), ASD(AdaptiveSoftware Development), 기능 중심 개발(FDD; Feature Driven Development), DSDM(Dynamic System Development Method), DAD(Disciplined Agile Delivery) 등이 있음.

애자일 개발 핵심가치
① 프로세스와 도구보다는 개인과 상호작용에 더 가치를 둠.
② 방대한 문서보다는 실행되는 소프트웨어에 더 가치를 둠.
③ 계약 협상보다는 고객과 협업에 더 가치를 둠.
④ 계획을 따르기 보다는 변화에 반응하는 것에 더 가치를 둠.

애자일 모델 / 출처: 프리모아

 

스크럼(scrum)이란?

스크럼이란 럭비에서 반칙으로 경기가 중단된 경우 양 팀의 선수들이 럭비공을 가운데 두고 상대팀을 밀치기 위해 서로 대치해 있는 대형을 말함. 이처럼 스크럼은 팀이 중심이 되어 개발의 효율성을 높인다는 의미가 내포된 용어임.

• 스크럼은 팀원 스스로가 스크럼 팀을 구성(selforganizing)해야 하며, 개발 작업에 관한 모든 것을 스스로 해결(cross-functional)할 수 있어야 함
• 스크럼 팀은 제품 책임자, 스크럼 마스터, 개발팀으로 구성됨.

제품 책임자(PO; Product Owner)
• 이해관계자들 중 개발될 제품에 대한 이해도가 높고, 요구사항을 책임지고 의사 결정할 사람으로 선정하는데, 주로 개발 의뢰자나 사용자가 담당함.
• 이해관계자들의 의견을 종합하여 제품에 대한 요구사 항을 작성하는 주체.
• 제품에 대한 테스트를 수행하면서 주기적으로 요구사 항의 우선순위를 갱신.

스크럼 마스터(SM; Scrum Master)
• 스크럼 팀이 스크럼을 잘 수행할 수 있도록 객관적인 시각에서 조언을 해주는 가이드 역할을 수행함. 팀원들을 통제하는 것이 목표가 아님.
• 스크럼 회의를 주관하여 진행 사항을 점검하고, 개발 과정에서 발생된 장애 요소를 공론화하여 처리함

개발팀(DT; Development Team)
• 제품 책임자와 스크럼 마스터를 제외한 모든 팀원으로, 개발자 외에도 디자이너, 테스터 등 제품 개발을 위해 참여하는 모든 사람.
• 보통 최대 인원은 7~8명이 적당함.

스크럼 개발 프로세스

1. 제품 백로그 (Pruduct Backlog)
   제품 개발에 필요한 모든 요구사항을 우선순의에 따라 나열한 목록.
2. 스프린트 계획 회의 (Sprint Planning Meeting)
   제품 백로그 중 이번 스프린트에서 수행할 작업을 대상으로 단기 일정을 수립.
3. 스프린트 (Sprint)
   실제 개발 작업을 진행하는 과정. 스프린트 백로그에 작성된 테스크를 대상으로 속도(velocity)를 추정한 후 개발 담당자에게 할당.
4. 일일 스크럼 회의 (Daily Scrum Meeting)
   모든 팀원이 매일 짧게 진행 상황을 점검하는 회의. 남은 작업시간을 소멸 차트(Burn-down Chart) 에 표시함.
5. 스프린트 검토 회의 (Sprint Review)
   부분 또는 전체 완성 제품이 요구사항에 잘 부합되는지 사용자를 포함한 참석자 앞에서 테스팅.
6. 스프린트 회고 (Sprint Retrosepctive)
   스프린트 주기를 되돌아보며 규칙을 잘 준수했는지, 개선할점은 없는지 등을 확인하고 기록.

XP (eXtreme Programming) 이란?

XP (eXtreme Programming) 은 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법임.

• XP는 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발하는 것을 목적으로 함.
• 릴리즈의 기간을 짧게 반복하면서 고객의 요구사항 반영에 대한 가시성을 높임.

XP의 5가지 핵심
① 의사소통 (Communication)
② 단순성 (Simplicity)
③ 용기 (Courage)
④ 존중 (Respect)
⑤ 피드백 (Feedback)

eXtreme Prgramming / 출처: 위키피디아

XP의 주요 실천 방법 (Practice)

1.  Pair Programming (짝 프로그래밍)
   다른 사람과 함께 프로그래밍을 수행함으로써 개발에 대한 책임을 공동으로 나눠갖는 환경 조성.
2. Collective Ownership (공동 코드 소유)
   개발 코드에 대한 권한과 책임을 공동으로 소유함.
3. Test-Driven Development (테스트 주도 개발)
   개발자가 실제 코드를 작성하기 전에 테스트 케이스를 먼저 작성하여 자신이 무엇을 해야할지를 정확히 파악. 테스트가 지속적으로 진행될 수 있도록 자동화된 테스팅 도구를 사용.
4. Whole Team (전체 팀)
   개발에 참여하는 모든 구성원(사용자 포함)들은 각자 자신의 역할이 있고 그 역할에 대한 책임을 가져야함.
5. Continuous Integration (계속적인 통합)
   모듈 단위로 나눠 개발된 코드들은 하나의 작업이 마무리 될 때마다 지속적으로 통합.
6. Design Improvement (디자인개선) or Refactoring 
   프로그램 기능의 변경없이 단순화, 유연성 강화등을 통해 시스템을 재구성함.
7. Small Releases
   릴리즈 기간을 짧게 반복함으로써 고객의 요구 변화에 신속히 대응할 수 있음.