1. 소프트웨어 공학의 배경과 목적
가) 소프트웨어 공학 소개
SW 개발 전 과정 관리와 업무 수행에 필요한 기술 지원
3가지 핵심 요소: Process (procedures & methods), People, Technology
나) 소프트웨어 공학 배경
1950s - HW 공학과 유사
1960s - SW 수요 급증, 인력의 미성숙 -> "소프트웨어의 위기"
1970s - SW 수요 급증, 인력 수 부족 -> 비전공자 대거 투입 -> "선코딩-후수정" 기법
선코딩-후수정 기법의 많은 결함 -> 구조적, 정형적 기법 등장 (e.g., 폭포수 모델) -> 사용성, 비용 문제
1980s - 재사용성 강화에 집중
1990s - 경쟁우위 선점에 집중 -> 제품 시장출시 시간 단축의 필요성 대두 ->
동시공학 활용 (폭포수 모델에서 요구사항, 설계, 구현 동시 진행)
2000s - SW 시장 급변 -> 이에 맞춰 애자일 방법론 도입
다) 소프트웨어 공학의 4가지 중요요소
(1) 방법: 자료구조, 알고리즘, 코딩
(2) 도구: 방법들을 자동화 or 반자동화시킨 것
(3) 절차: 방법 + 도구, 순서 정의
*마일스톤: SW 관리자들의 진행 평가
(4) 사람
2. 소프트웨어 개발 생명주기
가) 정의
타당성 검토 -> 개발 계획 -> 요구사항 분석 -> 설계 -> 구현 -> 테스트 -> 운용 -> 유지보수
나) 목적
플젝 비용 산정, 개발 계획 수립, 용어의 표준화, 플젝 관리
다) 소프트웨어 생명주기 모델 종류
(1) V 모델
- 플젝에서 어떤 활동이 수행되어야 하는지 명확하게 보여줌
- 요구사항이 명확할 때 이상적인 모델
- 검증 및 확인 강조
- 개발, 테스트 병행
- 플젝에 적용 + 관리 용이
- SW 개발 잘 모르는 고객 이해시키기에 용이
(2) VP 모델 (V Model with Prototyping)
- 시스템의 리스크, 불확실성 요소 해결
- 시스템 or 시스템의 일부분 빠르게 개발
- 접근방법 1 (해결하려는 문제가 명확하지 않을 때)
: 불확실성 요소 정의 -> 해결책 정의 -> 적용 -> 불확실성 요소의 원인 찾기
(e.g., 새로운 장치의 사용자 인터페이스 구현, 시스템 성능 향상, 에러결함 관리)
- 접근방법 2 (적용하려는 해결책에 리스크나 불확실성 요소가 존재할 때)
: 불확실성 요소 정의 -> 해결책들 열거, 선택 기준 정의 -> 해결책들 평가 -> 해결책 선택
(e.g., 특정 기능에 대한 미들웨어 선택, 여러 환경 요소에 대한 설계 성능 고려)
*미들웨어: 매개 SW
(3) 점증적 모델
- 개발 시간 줄이기
- 핵심 먼저 개발하고, 나머지 기능 구현
- 시스템은 몇 번의 기능 확장을 통해 개발
- 시간이 지남에 따라 개선 여지가 있는 경우 적합
- 개발 초기 외부 인터페이스에 대한 리스크를 줄이는데 유용
(4) 진화 모델
- 개발 시간 줄이기
- 전체 시스템에 대한 개발 여러 번 반복
- 전체적인 시스템 명세가 불분명하고, 제품의 개선이 지속적으로 요구되는 경우 적합
*보통 실무에서 점증적 + 진화 조합해서 사용
3. 소프트웨어 개발 방법론
가) 소프트웨어 개발 방법론의 필요성
개발 생산성 향상, 플젝 관리, 표준 용어 통일 (효과적인 의사소통), 품질 보증
나) 소프트웨어 개발 방법론 비교
(1) 구조적 방법론
- 업무활동 중심
- 추상화
- 단계적 상세화
- 프로그램 로직 중심
- 분할과 정복의 원칙
- 데이터 흐름도, 구조도
(2) 정보공학 방법론
- 데이터 중심
- 정보전략계획
- 프로그램 로직은 데이터구조에 종속 (CRUD)
- ERD, 기능차트, 테이블 정의서/목록
(3) 객체 지향 방법론
- 데이터와 로직 통합
- 상속에 의한 재사용 분석
- 설계간 gap 없음
- 비즈프로세스/개념도, 다이어그램
(4) CBD 방법론
- 객체 지향의 진화
- 재사용 가능한 컴포넌트 개발
- 상용 컴포넌트 조합
- 요구분석
- 인터페이스 중시
- 비즈프로세스/개념도, 다이어그램, 재사용 계획서, NET, EJB
- 개발언어 무관
다) 소프트웨어 개발 단계
(1) 요구사항 분석: 개념적
(2) 설계: 물리적 실현의 첫 단계, 시스템 구조 결정
(3) 구현: 프로그래밍
(4) 테스팅
4. 애자일 개발 방법론
스크럼, 익스트림 프로그래밍, 린 (최근 급부상)
가) XP (eXtreme Programming)
- 1990년대 후반, 켄트 백
- 경량화된 개발 방식 -> 중소규모 조직에 적합
- 테스트 주도 개발 (TDD), 일일빌드, 지속적인 통합
- 반복적 개발 방법론
- 유저 스토리: 요구사항, 의사소통의 도구
- 스파이크: 간단한 프로그램
- 승인 테스트: 인수 테스트 (고객이 직접 수행)
- 작은 릴리즈: 소규모로 빈번하게 배포 -> 고객에게 조기에 이득 제공 가능
- XP 가치: 의사소통, 단순성, 피드백, 용기, 존중
- XP의 실천방법 (12가지)
(1) 단순한 설계
(2) 테스트 기반 개발
(3) 리팩토링: 코드 단순화
(4) 코딩 표준
(5) 짝 프로그래밍: 두 명의 개발자가 한 컴퓨터 앞에 앉아서 개발
(6) 코드 공유: 모든 개발자가 소스코드에 대해 공동 책임을 질 것
(7) 지속적인 통합
(8) 계획 게임
(9) 작은 릴리스
(10) 메타포: 시스템에 대한 전체 모습을 이해하기 쉬운 그림, 스토리로 표현
(11) 주당 40시간 작업: 40시간 이하로 일해라
(12) 현장 고객: 실제 시스템 사용한 고객 개발 현장에 상수하게
나) 스크럼
- 1986년, 타케우지&노나카, "The New Product Development Game" (at HBR)가 기원
- 1995년, 켄 슈와버 + 제프 서덜랜드가 소개
(1) 스크럼 프로세스
a. 스프린트: 1~4주 단위의 반복개발기간
b. 3가지 미팅: 일일 스크럼 (매일 15분 진행상황 공유), 스프린트 계획, 스프린트 리뷰
c. 3가지 산출물: 제품 백로그 ('기능=사용자 스토리'의 우선순위 정리), 스프린트 백로그 (한 스프린트 동안 개발할 목록), 소멸 차트 (개발을 완료하기까지 남은 작업량 보여주는 그래프)
(2) 스크럼 역할자 유형
a. 제품 책임자: 제품 백로그 생성, 우선순위 조정, 스프린트 시작 후에는 팀운영에 관여 x
b. 스크럼 마스터: 팀 관리
c. 스크럼 팀: 5~9명, 한 스프린트 동안 개발 할 기능 도출
(3) 스크럼 특징
투명성, 타임박싱 (시간 제한 -> 플젝에만 집중 가능), 커뮤니케이션, 경험주의 모델 (팀마다 달라지는 구조)
