1.1 소프트웨어 공학 개요
1.1.1 소프트웨어 공학의 배경과 목적
가) 소프트웨어 공학 소개
P.P.T
- 프로세스 (Process)
- 인력 (People)
- 인프라 기술 (Technology)
나) 소프트웨어 공학 배경
다) 소프트웨어 공학의 4가지 중요요소
- 방법
- 도구
- 절차
- 사람
-
방법 : 프로젝트 계획 수립과 추정, 시스템과 소프트웨어 분석, 자료구조
-
도구 : 일을 수행할 때 생산성 혹은 일관성을 목적으로 사용하는 방법
들을 자동화나 반자동화 시켜 놓은 것 -
절차 : 방법 + 도구 -> 소프트웨어 합리적 개발을 가능하도록 함
-
사람
1.1.2 소프트웨어 개발 생명주기
가) 정의
: 사용자 환경 및 문제점 이해부터 운용/유지 보수까지의 모든 과정
- 일반적인 소프트웨어 생명주기
타당성 검토 -> 개발 계획 -> 요구사항 분석 -> 설계 -> 구현 -> 테스트
-> 운용 -> 유지보수
나) 목적
- 프로젝트 관리
다) 소프트웨어 생명주기 선정
- 선택한 모델은 프로젝트에 존재하는 리스크 / 불확실성을 최소화 시킬 수 있어야 한다.
- ex) 폭포수 모델, 프로토타입 모델, 진화 모델, 점증적 모델
라) 소프트웨어 생명주기 모델 종류
1. V 모델
- 시스템의 요구사항이 모두 식별되고 명확할 때 이상적인 생명주기 모델
- 프로젝트에 적용, 관리하기가 용이
- 프로젝트의 검증 및 확인을 강조하는 모델
- 개발 활동과 이에 해당하는 테스트 활동이 병행됨
- 테스트 동안 결함이 발견되었을 경우, 개발 활동의 어느 단계를
재 수행되어야 하는 지 알 수 있다.
2. VP 모델 (V Model with Prototyping)
Prototyping : 시스템에 대한 이해 또는 리스크, 불확실성 요소와 같은 이슈를 해결하기 위해 시스템 혹은 그 일부를 빠르게 개발하는 방법
- 불확실성 요소나 리스크를 줄일 수 있음
- 개발자와 고객의 공통적인 이해를 이끌어 낼 수 있음
프로토타입 기법의 접근방법
1) 적용 가능한 해결책 조사, 이를 적용
- 불확실성 요소를 정의
- 해결책 찾기
- 적용하기 위한 방법 정의
- 해결책 적용 (반복 수행)
- 그 결과를 통해 불확실성 요소의 원인 찾기
-> 해결하려는 문제가 명확하지 않은 경우
2) 여러가지 선택 가능한 해결책을 열거, 정해진 기준에 따라 이를 평가
- 불확실성 요소를 정의
- 선택 가능한 해결책 열거
- 선택 기준 정의
- 선택 기준에 따라 해결책 평가
- 가장 적합한 해결책 선택
-> 적용하려는 해결책에 리스크나 불확실성 요소가 존재하는 경우
3. 점증적 모델
- 핵심이 되는 부분 먼저 개발 후 나머지 기능 구현
- V 모델, VP 모델 모두 적용 가능
- 시스템 개발 시간을 줄일 필요가 있는 경우 유용
- 시간이 지남에 따라 개선 여지가 있는 경우 유용
4. 진화 모델
- 전체 시스템에 대한 개발 단계 여러 번 반복
- 하나의 시스템 개발되어 사용, 변경 사항 도출 -> 다음 시스템 개발에 반영
- 시스템 개발 시간을 줄일 필요가 있는 경우 유용
- 제품의 개선이 지속적으로 요구되는 경우 유용
5. 혼합 모델
점증적 모델 + 진화 모델 -> 기존의 기능 향상, 새로운 기능 추가
- 시스템 초기 교육 가능 - 실무에 필요한 개선사항 도출
- 개발 기간 단축 - 경쟁력 강화
- 전문 분야별로 나눠서 시스템 개발 가능
1.1.3 소프트웨어 개발 방법론
가) 소프트웨어 개발 방법론의 필요성
- 개발 생산성 향상
- 효과적인 프로젝트 관리
- 의사소통 수단 제공
- 일정 수준의 품질 보증
나) 소프트웨어 개발 방법론 비교
구정객C
- CBD : Compoenet Based Development
다) 소프트웨어 개발 단계
: 소프트웨어 생명주기에 따라 정의
요구사항 분석 -> 설계 -> 구현 -> 테스팅
- 요구사항 분석
- 개념적 단계
- 무엇을 개발할 것인지 정확히 결정
- 사용자의 요구를 이해하는 단계
- 개발 비용을 감소시킬 수 있는 단계
- 전체 소프트웨어 개발 기간과 비용의 초과, 품질 저하 미연에 방지 가능
- 설계
- 물리적 실현의 첫 단계
- 시스템 구조 결정
- 품질에 직접적 영향 줌
- 설계가 제대로 되지 않으면 시스템 안정감 저하 -> 유지보수 어려움
- 구현
- 목표 : 요구사항을 만족할 수 있도록 프로그램 하는 것
- 상세 설계나 사용자 지침서에 기술된 것과 일치하도록 개발
- 코딩 표준 정하고 이를 기반으로 명확하게 코드 작성
- 테스팅
- 정해진 요구 만족하는지, 예상과 실제 결과의 차이가 어떠한지 검사하고, 평가하는 일련의 과정
- 소프트웨어의 품질을 확보하기 위해 결함을 찾아내는 일련의 작업
- 개발한 소프트웨어 품질에 대한 평가와 품질 향상을 위한 수정 작업 포함
1.1.4 애자일 개발 방법론
가) 애자일 방법론 종류
- 스크럼 (Scrum)
- 익스트림 프로그래밍 (eXtreme Programming, XP)
나) 애자일 개발 방법론 - XP
- XP 개요
- 중소규모 개발 조직에 적합한 경량화된 개발방식
- 반복적 개발방법론의 일종
- XP 개발절차 및 용어
- 유저스토리 : 요구사항 수집, 의사소통의 도구, 기능단위의 필요한 내용 기재
- 스파이크 : 어려운 요구사항 혹은 잠재 솔루션을 고려한 간단한 프로그램
목적) 사용자 스토리의 신뢰성 증대, 기술 문제의 위험 감소 - 릴리즈 계획 : 전체 프로젝트에 데한 배포 계획 수립, 반복들을 균일하게 유지
- 승인 테스트 : 릴리즈 전 인스 테스트, 고객이 직접 수행
- 작은 릴리즈 : 소규모로 빈번하게 배포 -> 고객에게 이득을 조기에 제공 가능
- XP 가치
의사소통, 단순성, 피드백, 용기, 존중
- 의사소통 : 팀 단위 개발에서 가장 중요, 고객, 개발자, 관리자들 간의 의사소통을 통해 문제를 해결하고 팀 빌딩을 강화해야 함
- 단순성 : 불필요한 복잡성 제거 - 설계를 단순,명확하도록 유지
- 피드백 : 최대한 많은 피드백을 만들어 개선에 활용
- 용기 : 요구사항 및 기술 변경에 용감하게 대처, 단순함 추구, 피드백 강화
- 존중 : 팀에 속한 사람들을 존중
- XP의 실천방법
다) 스크럼 (SCRUM)
- 스크럼 개요
- 프로젝트 관리를 위한 애자일 방법론
- 경험적 관리기법의 대표적인 형태
<스크럼 역할자 유형>
P.O / S.M / S.T => SM POST
제품 책임자 (Product Owner) - 팀장
- 제품 기능목록에 해당하는 제품 백로그 만듦
- 우선순위 조정
- 새로운 항목 추가
- 스프린트 계획 수립 시점 : 핵심 역할, 시작 후 : 팀의 운영에 관여하지 않음
스크럼 마스터 (Scrum Master) - 관리자
- 팀의 업무를 방해하는 요소 제거에 노력
- 원칙과 가치를 지키면서 팀이 개발을 진행할 수 있도록 지원
스크럼 팀 (Scrum Team) - 개발자
- 일반적으로 최소 5명 최대 9명
- 사용자 스토리를 사용하여 한 스프린트 동안 개발할 기능 도출
- 스크럼 프로세스
- 스프린트 : 1 ~ 4주 단위의 반복개발기간
- 3가지 미팅 : 일일 스크럼, 스프린트 계획, 스프린트 리뷰
- 3가지 산출물 : 제품 백로그, 스프린트 백로그, 소멸 차트
<스크럼 프로세스 산출물>
제품 백로그, 스프린트 백로그, 소멸 차트
- 제품 백로그
제품에 담고자 하는 기능의 우선순위를 정리한 목록
P.O가 주로 우선순위를 결정 - 스프린트 백로그
하나의 스프린트동안 개발할 목록
각 과업은 시간 단위로 추정 - 소멸 차트 : 개발을 완료하기까지 남은 작업량을 보여주는 그래프
<스크럼 프로세스 산출물>
스프린트 계획, 일일 스크럼, 스프린트 리뷰
- 스프린트 계획
각 스프린트에 대한 목표를 세우고 제품 백로그부터 스프린트에서 진행할
항목을 선택 - 일일 스크럼 : 매일 진행하는 프로젝트 진행상황을 공유하는 회의
- 스프린트 리뷰 : 목표를 달성했는지 작업 진행과 결과물을 확인하는 회의
스크럼 팀 - 작업한 결과를 참석자들에게 데모하고 피드백 받기
스크럼 마스터 - 잘된 점, 아쉬웠던 점, 개선할 사항 등을 찾기위한 회고 진행
- 스크럼 특징
- 투명성 : 프로젝트가 어떤 상태인지 어떤 문제점이 있는지 정확히 파악
- 타임박싱 : 스크럼을 진행하는데 들어가는 시간을 제한
- 커뮤니케이션
- 경험주의 모델 : 개개인의 경험 중요
