1. 소프트웨어 설계
1) 소프트웨어 생명주기
- 소프트웨어를 개발하기 위해 정의하고 운용, 유지보수 등 과정을 각 단계별로 나눈 것
- 쉽게 말해 요리를 하는 방법을 소프트웨어 생명주기에 비유할 수 있다.
- 생명주기 모형 - 폭포수 모형, 프로토타입 모형, 나선형 모형, 애자일 모형
2) 소프트웨어 공학
- 소프트웨어 위기를 극복하기 위한 방안으로 연구된 학문, 도구, 관리기법 등을 통하여 품질과 생산성을 향상
| 소프트웨어 공학의 기본 원칙 |
| 1) 현대적인 프로그래밍 기술을 계속적으로 적용 |
| 2) 개발된 소프트웨어 품질이 유지되도록 지속적으로 검증 |
| 3) 소프트웨어 개발 관련사항 및 결과에 대한 명확한 기록을 유지 |
※ 소프트웨어 위기 : 하드웨어 개발속도를 소프트웨어가 따라가지 못하는 것 -> 사용자의 요구사항을 감당할 수없음
3) 폭포수 모형 (Waterfall Model)
- 폭포에서 한번 떨어진 물은 거슬러 올라갈 수없듯이 소프트웨어 개발도 이전단계로 돌아갈 수 없다는 전제하에 각 단계를 확실히 매듭짓고 결과를 철저하게 검토하여 승인과정을 거친 후에 다음 단계를 진행
| 폭포수 모형의 특징 |
| 1) 가장 오래되고 가장 폭 넓게 사용된 전통적인 소프트웨어 생명주기 모형 (고전적 생명주기 모형) |
| 2) 한 단계가 끝나야만 다음 단계로 넘어갈 수 있는 선형 순차적 모형 |
| 3) 각 단계가 끝난 후에는 다음 단계로 넘어갈 수있는 선형 순차적 모형 |
| 4) 두 개 이상의 과정이 병행하여 수행되지 않음 |
4) 프로토타입 모형 (Prototype Model) , 원 형 모형
- 사용자의 요구사항을 정확하게 파악하기 위해 실제 개발될 소프트웨어의 견본(시제) 품 (Prototype)을 만들어 최종 결과물을 예측하는 모형, 모델 하우스를 짓는 과정을 프로토타입 모형에 비유할 수 있다.
| 프로토타입 모형의 특징 |
| 1) 시제품은 의뢰자나 개발자 모두에게 공동의 참조 모델이 됨 |
| 2) 새로운 요구사항이 도출될 떄 마다 이를 반영한 프로토타입을 새롭게 만들면서 소프트웨어를 구현하는 방법 |
| 3) 단 기간 제작 목적으로 인하여 비효율적인 언어나 알고리즘이 사용될 수 있음 |
5) 나선형 모형 (Spiral Model), 점진적 모형
- 보헴(Boehm)이 제안한 것으로 폭포수 모형, 프로토타입 모형의 장점에 위험분석 기능을 추가한 모형
| 나선형 모형의 특징 |
| 1) 나선을 따라 돌듯이 여러번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 최종 소프트웨어를 개발 |
| 2) 소프트웨어를 개발하면서 발생할 수있는 위험을 관리하고 최소화하는 것을 목적 |
| 3) 점진적으로 개발과정이 반복되므로 누락되거나 추가된 요구사항을 첨가 할 수있음, 유지보수 과정이 필요x |
6) 애자일 모형 (Agile Model)
- 애자일은 민첩한, 기민한 이라는 의미로 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기로 반복하면서 개발과정을 진행
- 고객과의 소통에 초점을 맞춘 방법론을 통칭
| 애자일 모형의 특징 |
| 1) 기업활동 전반에 걸쳐 사용되며 소규모 프로젝트, 고도로 숙련된 개발자, 급변하는 요구사항에 적합함 |
| 2) 스프린트 (Sprint) 또는 이터레이션 (Iteration)이라고 불리는 짧은 개발 주기를 반복 반복되는 주기마다 만들어지는 결과물에 대한 고객의 평가와 요구를 적극 수용함 |
| 3) 애자일 모형을 기반으로 하는 소프트웨어 개발 모형에는 스크럼(Scrum), XP(eXtreme Programming), 칸반(Kanban), Lean, 크리스탈(Crystal), ASD(Adaptive Software Development), 기능 중심 개발(FDD; Feature Driven Development), DSDM(Dynamic System Development Method), DAD(Disciplined Agile Delivery) 등이 있다. |
※ 스프린트 : 짧은 주기로 프로젝트를 나누어 집중적으로 작업, 지속적인 개선 및 피드백 반영을 목표로 하며 기간은 보통 2~4주 정도로 짧게 설정됨
7) 애자일 선언 (Agile Manifesto)
| 애자일 개발 4가지 핵심 가치 |
| 1) 프로세스와 도구보다는 개인과 상호작용에 더 가치를 둔다 |
| 2) 방대한 문서보다는 실행되는 SW에 더 가치를 둔다 |
| 3) 계약협상보다는 고객과 협업에 더 가치를 둔다 |
| 4) 계획을 따르기보다는 변화에 반응하는 것에 더 가치를 둔다 |
8) 폭포수 모형과 애자일의 비교
| 폭포수 | 애자일 | |
| 새로운 요구사항 반영 | 어려움 | 지속적으로 반영 |
| 고객과의 의사소통 | 적음 | 지속적임 |
| 개발 중심 | 마지막에 모든 기능 테스트 | 반복되는 일정 주기가 끝날 떄 마다 테스트 |
| 테스트 | 계획, 문서(메뉴얼) | 고객 |
9) 스크럼
- 팀이 중심이 되어 개발 효율성을 높인다는 의미가 내포된 용어
- 스크럼 팀은 제품 책임자(Product Owner), 스크럼 마스터(Scrum Master), 개발 팀(Development Team)으로 구성됨
1) 제품 책임자 (PO, Product Owner)
- 이해 관계자들 중 개발될 제품에 대한 이해도가 높고 요구사항을 책임지고 의사결정할 사람으로 선정
- 주로 개발 의뢰자나 사용자가 담당함
- 요구사항이 담긴 백로그를 작성하고 백로그에 대한 우선순위를 지정함
2) 스크럼 마스터(SM,Scrum Master)
- 스크럼 팀이 스크럼을 잘 수행 할 수 있도록 객관적인 시각에서 조언을 해주는 가이드 역할을 수행
3) 개발 팀(DT,Development Team)
- 제품 책임자와 스크럼 마스터를 제외한 모든 팀원으로 개발자 외에도 디자이너, 테스터 등 제품 개발을 위해 참여하는 모든 사람이 대상이 됨
- 최대 인원은 7~8명이 적당함
※ 백로그 : 제품 개발에 필요한 요구사항을 모두 모아 우선순위를 부여해 놓은 목록을 의미
10) 스크럼 개발 프로세스
1) 제품 백로그
- 제품 개발에 필요한 모든 요구사항을 우선순위에 따라 나열한 목록
2) 스프린트 계획회의
- 제품 백로그 중 이번 스프린트에서 수행할 작업을 대상으로 단기일정을 수립
3) 스프린트
- 실제 개발 작업을 진행하는 과정, 보통 2~4주 정도의 기간 내에서 진행함
4) 일일 스크럼 회의
- 모든 팀원이 매일 약속된 시간에 약 15분 정도의 짧은 시간동안 진행상황을 점검
- 회의는 보통 서서 진행
- 남은 작업시간은 소멸차트에 표시함
- 스크럼 마스터는 발견된 장애요소를 해결
※ 소멸차트 (Burn-down Chart) : 해당 스프린트에서 수행할 작업의 진행 상황을 확인할 수 있도록 시간의 경과에 따라 남은 작업 시간을 그래프로 표현한 것, 초기에 추정해떤 전체 작업 시간은 작업이 진행될수록 점점 줄어(Burn-down) 들게 됨
5) 스프린트 검토회의
- 부분 또는 전체 완성 제품이 요구사항에 잘 부합한 지 사용자가 포함된 참석자 앞에서 테스팅
- 스프린트의 한 주당 한 시간내에서 진행함
6) 스프린트 회고
- 스프린트 주기를 돌아보며 정해 높은 규칙을 잘 준수했는지, 개선할 점은 없는지 확인, 기록
11) XP(Extreme Programming) 익스트림 프로그래밍
- 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발과정을 반복으로 극대화하여 개발 생산성을 향상하는 방법
| 개발 생산성을 향상시키는 방법 |
| 1) 짧고 반복적인 개발주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발하는 것을 목표 |
| 2) 릴리즈 기간을 짧게 반복 - 고객의 요구사항 반영에 대한 가시성을 높임 |
| 3) 릴리즈 테스트마다 고객을 직접 참여 - 요구한 기능이 제대로 동작하는지 고객이 직접 확인 |
XP의 5가지 핵심 가치 : 의사소통(Communication), 단순성(Simplicity), 용기(Courage), 피드백(Feedback), 존중(Respect)
XP는 비교적 소규모 인원의 개발 프로젝트에 효과적임
"피존의 용기 단순"
피(피드백)존(존중)의(의사소통) 용기(용기) 단순(단순성)
12) XP 개발 프로세스
1) 사용자 스토리 (User Story)
- 고객의 요구사항을 간단한 시나리오로 표현 한 것
- 내용은 기능단위로 구성하며 필요한 경우 간단한 테스트 사항(Test Case)도 기재함
※ 테스트케이스 : 구현된 SW가 사용자 요구사항을 정확하게 준수했는지 확인하기 위해 설계된 입력 값, 실행 조건, 기대 결과 등으로 구성된 테스트 항목에 대한 명세서
2) 릴리즈 계획 수립 (Release Planning)
- 몇 개의 스토리가 적용되어 부분적으로 기능이 완료된 제품을 제공하는 것을 릴리즈라고 함
- 부분 혹은 전체 개발 완료 시점에 대한 일정을 수립
3) 스파이크 (Spike)
- 요구사항의 신뢰성을 높이고 기술 문제에 대한 위험을 감소시키기 위해 별도로 만드는 간단한 프로그램
- 처리할 문제 외의 다른 조건은 모두 무시하고 작성함
4) 이터레이션 (Iteration)
- 하나의 릴리즈를 더 세분화한 단위를 이터레이션이라고 함
- 일반적으로 1~3주 정도의 기간으로 진행됨
- 이 기간중에 새로운 스토리가 작성될 수 있으며 작성된 스토리는 진행 중인 이터레이션 혹은 다음 이터레이션에 포함될 수 있음
5) 승인검사(Acceptance Test, 인수 테스트)
- 하나의 이터레이션 안에서 계획된 릴리즈 단위의 부분완료 제품이 구현되면 수행하는 테스트
- 사용자 스토리 작성 시 함께 기재한 테스트 사항에 대해 고객이 직접 수행
6) 소규모 릴리즈(Small Release)
- 릴리즈를 소규모로 하게되면 고객의 반응을 기능별로 확인할 수 있어 고객의 요구사항에 유연하게 대응
13) XP의 주요 실천 방법
1) Pair Programming(짝 프로그래밍)
- 다른 사람과 함께 프로그래밍을 수행함으로써 개발에 대한 책임을 공동으로 나눠갖는 환경을 조성
2) Collective Development(공동 코드 소유)
- 개발 코드에 대한 권한과 책임을 공동으로 소유함
3) Test - Driven Development(테스트 주도 개발)
- 개발자가 실제코드를 작성하기 전에 테스트케이스를 먼저 작성
- 테스트가 지속적으로 진행 될 수 있도록 자동화된 테스팅 도구
4) Whole Team(전체 팀)
- 개발에 참여하는 모든 구성원들은 각자 자신의 역할이 있고 그 역할에 대한 책임을 가져야 함
5) Continuous Integration(계속적인 통합)
- 모듈 단위로 나눠서 개발된 코드들은 하나의 작업이 마무리될 때마다 지속적으로 통합
6) Refactoring(리팩토링)
- 프로그램의 단순화, 유연성 강화 등을 위해 기능의 변경 없이 시스템을 재구성
7) Small Release(소규모 릴리즈)
- 릴리즈 기간을 짧게 반복함으로써 고객의 요구변화에 신속히 대응