한빛아카데미 쉽게 배우는 소프트웨어공학 2판을 읽고 정리한 글입니다.
읽고 넘어갈만한 내용은 적지 않았습니다.
1. 소프트웨어의 이해
소프트웨어 공학
•
공학 : 과학적 지식을 활용해 문제를 해결하는 데 한정된 기간과 비용의 제약을 받는다.
•
소프트웨어 공학 : 소프트웨어 개발에 공학적 원리를 적용해보자.
•
소프트웨어 개발 : 하나의 제품인 소프트웨어를 만들기 위한 계획부터 유지보수 단계 까지의 일련의 과정 (소프트웨어 개발 생명주기 SDLC)
◦
계획 → 분석 → 설계 → 구현 → 테스트 → 유지보수
품질 좋은 소프트웨어를 경제적으로 개발하기 위해 계획을 세우고, 개발하며, 유지 및 관리하는 전 과정에서 공학, 과학 및 수학적 원리와 방법을 적용해 필요한 이론과 기술 및 도구들에 관해 연구하는 학문
2. 소프트웨어 개발 프로세스
소프트웨어 개발 프로세스 모델
•
소프트웨어 개발 프로세스 모델의 정의
◦
어떻게 소프트웨어를 개발할 것인가에 대한 전체 흐름
•
소프트웨어 개발 프로세스 모델의 목적
◦
고품질의 소프트웨어를 만들기 위함
•
소프트웨어 개발 프로세스 모델의 역할
◦
프로젝트의 골격을 세워줌
◦
자원 산정 및 분배
◦
의사소통 기준
◦
용어 표준화
3. 주먹 구구식 모델 (Build -and-Fix Model)
Build and fix를 주먹 구구식으로 번역하다니... 초월번역...
•
공식적인 가이드나 프로세스가 없는 개발 방식
•
제품을 만들고 문제가 있으면 수정하고 만들고 반복하는 방식
•
한명이 단시간에 작업을 마칠 수 있을 때 사용
4. 선형 순차적 모델 (Linear Sequential Model)
•
폭포수(Water Fall Model)로 더 잘 알려져 있음. 고전적 생명 주기 (Classic Lifecycle) 이라고도 함.
•
각 단계가 하향식으로 진행, 병행하거나 반복되지 않음
폭포수 모델의 장점과 단점
•
관리가 용이
◦
절차가 간결하고 이해가 쉬움
•
체계적 문서화 가능
•
요구사항 변화가 적을때 적합
•
각 단계는 앞 단계가 완료되어야지만 수행 가능
•
각 단계가 완벽한 수준이어야 함
•
가시적인 결과를 볼 수 없어 답답함
V 모델
•
폭포수 모델의 변형
•
각 개발 단계를 검증하는데 초점을 둠
5. 진화적 프로세스 모델 (Evolutionary Process Model)
•
새로운 요구에 민첩하게 대응할 수 있게 나온 모델
프로토타입 모델
•
개발자와 사용자 간의 의사소통 도구로 사용되어 구체적이고 원활한 대화가 가능
•
요구 사항의 반복을 통해 요구가 충분히 반영된 요구 분석 명세서 작성 가능
•
유지보수 시간과 노력 감축
•
비용 산정과 인력 산정이 어려움
•
빠른 시일 내로 완성될 것이라고 착각할 수 있음
나선형 모델
•
요구 분석 후 프로토타입 개발 이전에 위험 분석을 거침
•
위험을 고려하기 때문에 갑작스런 위험으로 인해 프로젝트가 중단되는 심각한 사태가 일어날 확률이 적음
6. 단계적 개발 모델 (Phased Development Model)
개발과 사용을 반복하는 모델
점증적 개발 방법 (Incremental Development)
중요하다고 생각하는 부분부터 차례로 개발하고 일부를 사용하면서 범위를 점차 늘려가는 방법
반복적 개발 방법 (Iterative Development)
시스템 전체를 개발하고 서브 시스템의 기능과 성능을 업그레이드해 완성도를 높이는 방법
7. 통합 프로세스 모델
•
관리 가능한 소규모 단위로 나눈다.
•
그 안에서 수행될 작은 단위의 계획을 세운다.
•
각 반복에서 작은 부분을 통합, 테스트, 실행한다.
1.
도입 단계
a.
비즈니스 모델링, 요구 사항 정의 등
2.
구체화 단계
a.
분석 및 설계 작업이 왕성하게 이루어짐 구현 시작
3.
구축 단계
a.
구현이 대부분
4.
전이 단계
a.
사용자를 위해 제품을 완성하는 단계
8. 애자일 프로세스 모델 (Agile Process Model)
•
고객의 요구에 민첩하게 대응하고 그때그때 주어지는 문제를 풀어나가는 방법론
애자일의 기본 가치
•
프로세스와 도구 중심이 아닌, 개개인의 상호 소통을 중시한다.
•
문서 중심이 아닌, 실행 가능한 소프트웨어를 중시한다.
•
계약과 협상 중심이 아닌 고객과의 협력을 중시한다.
•
계획 중심이 아닌 변화에 대한 민첩한 대응을 중시한다.
애자일 원칙
•
가치 있는 소프트웨어를 빨리, 지속적으로 제공
•
새로 추가되는 요구 사항도 기꺼이 받아들인다.
•
동작 가능한 소프트웨어를 자주 고객에게 전달한다.
등등
애자일 프로세스 개발 방법
반복으로 나누어 개발
9. 스크럼 (Scrum)
•
팀의 개선과 프로젝트 관리에 중점을 둔 애자일 방법론.
•
경험적 관리 기법
•
구체적인 프로세스를 제시하지 않음
•
조직을 운영하는 방법
스크럼 방식의 이해
•
제품 기능 목록
◦
사용자가 요구하는 제품의 기능 목록
◦
요구사항에 대한 우선순위 존재 (고객측의 PO가 결정)
•
사용자 스토리
◦
제품 기능을 간단하게 서술
◦
기능을 적지 말고 개발자와 대화를 할 수 있는 단서 정도만 적음
◦
사용자가 필요한 내용을 적음 (개발자 X)
◦
사용자 스토리의 요소
▪
카드 : 포스트잇을 통해 기능을 서술
▪
대화 : 사용자와 대화가 충분한 대화를 통해 요구사항 도출
▪
확인 : 스토리가 완료되는 조건 서술
◦
스토리가 잘 작성되었는지 확인하는 지침
1.
스토리 끼리는 의존적이지 않다
2.
스토리는 언제나 변경가능하며 자세히 서술할 필요가 없다.
3.
사용자가 이해할 수 있는 언어와 용어로 작성
4.
개발 규모와 투입 공수를 개발자들이 짐작할 수 있어야 한다
5.
개발 규모가 적정
6.
테스트가 가능한 테스트 케이스를 만들어야 한다.
•
스토리 포인트 산정
◦
요구 사항의 규모를 측정하는 단위
◦
스토리의 업무량이 가장 적을때를 1로 두고 얼마나 큰지에 따라 스토리 포인트 산정
◦
개발자가 주도
스프린트 계획 수립
•
1~4주 정도를 하나의 스프린트로 보고 스프린트 계획 회의를 통해 정한다.
•
스프린트에 배정된 작업을 멈추지 말고 끝까지 끝내야 한다.
•
스크럼 마스터는 외부의 개발 방해 요소를 차단한다.
•
스프린트 개발이 끝나면 사용자에게 시연하고 피드백을 제공한다.
•
다 못해도 스프린트는 끝난다.
스프린트 수행
•
소멸 차트
◦
계획 대비 작업이 어떻게 진행되고 있는지를 날짜별 남은 작업으로 나타내는 차트
•
일일 스크럼 회의
◦
매일 짧게 하는 회의
•
스프린트 현황판
◦
개발 현황 나타냄
•
스프린트 진척 관리
스프린트 개발 완료 후
•
스프린트 검토 회의 진행
◦
스프린트로 만들어진 제품 검토
•
스프린트 회고
◦
수행한 활동과 개발한 것을 되돌아보기
배포 목록 작성
•
사용자에게 시스템 일부 제공
스크럼 방식의 장단점
•
사용자와 충분한 의견 조율
•
일일 회의를 통해 팀원간의 신속한 협조와 조율
•
단순하고 실천 지향
•
업무에 집중할 수 있는 환경 조성
•
단순하고 실천 지향적
•
목표 달성에 집중하도록 문제 해결
•
신속한 목표과 결과 추정
•
목표에 맞는 변화 쉬움
•
스프린트마다 제품을 만들어야 하므로 시간이 더 걸림
•
일일 스크럼회의가 길어지면 방해가 됨
•
작업의 효율성 측정이 어려움
•
품질 관련 활동이 미약하고 품질의 정도를 알기 어려움