1.1. 소프트웨어의 이해
-
프로그램: 프로그래밍한 원시코드
-
소프트웨어: 프로그램(코드)를 비롯해 개발 과정에서 생성되는 모든 산출물
-
특징
- 제조가 아닌 개발: 제조는 차이가 크지 않음, 소프트웨어 개발 과정은 개인 능력에 따라 차이 (생산성 즉, 시간과 효울성 등) 가 큼.
- 소모가 아닌 품질 저하: 하드웨어는 오래 사용하면 부품이 닳고 기능이 떨어짐.
소프트웨어는 닳지 않고 고장 빈도가 낮음. 사용자의 요구가 계속 발생.
-
HW 실패 곡선(욕조 곡선)의 특징 -> bathtub curve
-
이상적인 소프트웨어의 실패 곡선 (이상적인 상황)
-
실제 소프트웨어 실패 곡선
1.2. 공학, 소프트웨어 공학
- 공학: 기술적 문제를 대상으로 하는 학문, 기술적 해결책 제시
- 공학의 특성: 제약 사항 (기간, 비용) -> 문제 해결 시 한정 기간과 비용의 제약
소프트웨어의 궁극적 목적: 최단시간, 최저비용, 고품질
프로젝트 관리 삼각형: 시간, 비용, 품질
-
소프트웨어 개발 생명주기 (Software Development Life Cycle, SDLC)
: 소프트웨어를 만들기 위해 계획 단계에서 유지보수 단계에 이르기까지 일어나는 일련의 과정(계획, 분석, 설계, 구현, 테스트, 유지보수) -
프로세스: 일을 처리하는 과정 또는 순서
소프트웨어 개발에서 프로세스란? Task 순서의 집합, Constraint (제약 조건) 을 포함하는 Task의 집합인 Activity(활동).
- 소프트웨어 개발 프로세스: 필요한 절차나 과정 -> 소포트웨어 개발 목적을 이루는데 필요한 통합적 수단
- 소프트웨어 개발 프로세스 모델(SDLC 모델, 생명주기 모델)
모델 선정의 의미
1. 성공 여부에 영향을 끼침
2. 특정 목표 달성
3. 잘못 선정시 느린 업무 진행, 작업 반복 등
4. 적절히 선정 시 유연하게 진행됨
5. 선정을 안할 시 잘못한 결과와 같음
1.3. SDLC 모델의 종류
- Code-and-Fix (짜보고 고치기)
- Waterfall (폭포수)
- V (V)
- Prototype (프로토타입)
- Spiral (나선형)
- Phased Development (단계적 개발)
- Unified Process (통합 프로세스)
- Agile Process (애자일 프로세스)
모델 vs. 모델링
모델: 본보기, 모형, 견본
모델링:
1) 개발 시스템의 성능 분석 또는 동작 과정을 알아보기 위해 물리적 모형이나 도해를 만드는 과정
2) 시스템의 특징을 수학적으로 표현하는 과정
2.1. 짜보고 고치기 모델 (Code-and-Fix)
- 쓸모가 없지만 흔히 사용한다.
- 프로젝트 계획 수립 활동을 하지 않아도 됨.
- 일정이 촉박하기 때문에 미친듯이 코딩한다.
- 공식적 명세서 있을 수도, 없을 수도.
+: 부하가 없음, 비전문가가 사용 (누구든 가능)
적용하기 적절한 프로젝트: 한 번 만들어보고 버릴 목적
평가: 그 외 프로젝트에서는 위험한 모델
2.2. 폭포수 모델(Waterfall Model)
선형 순차적 모델 (Linear Sequential) = 고전적 생명주기 모델 (Classic Life Cycle Model)
- 다른 모델의 조상이자 기초, 질서 정연한 단계의 개념
- 매 단계 끝에 검토 과정 O
- 문서 기반, 연속적이지 않고 단계가 겹치지 않음
폭포수 모델의 개발 절차
1. 계획 단계 (Planning)
2. 요구분석 단계 (Requirement Analysis)
3. 설계 단계 (Design)
4. 구현 단계 (Implementation)
5. 테스트 단계 (Test)
6. 유지보수 단계 (Maintenance)
+:
- 제품 정의가 안정적, 익숙한 기술 방법론을 쓰고자 할 때 효과적
- 기존제품을 판올림할 때 적합
- 요구사항이 안정적*
-:
- 생명 주기가 끝날 때까지 실제적인 결과물을 보여주지 X
- 유연하지 않다* (현대 비즈니스 요구에 부합하지 X)
- 이전 단계로 복원 어려움
- 문서 관리가 많음
- 마지막 순간까지 진행 상황을 거의 보여주지 X
2.3. V 모델
- 폭포수 모델의 변형, 테스트 단계를 추가 확장
- 폭포수 모델은 산출물 중심
- V 모델은 각 개발 단계를 검증하는 데 초점
모듈? 특정 기능을 수행하는 명령어 집단, SW의 구성 요소 (= Copmponent)
Test의 종류들
1. Unit Test (단위 테스트) : 개별 프로그램
2. Module Test (모듈 테스트) : 기능
3. Integration Test (통합 테스트): 모듈 통합 및 오류
4. System Test (시스템 테스트) : 시스템 전체의 정상 작동
5. Acceptance Test (인수, 승인 테스트) : 사용자가 직접 요구사항 충족되는지
2.4. 프로토타입, 진화적 프로세스 모델 (Prototype)
프로토타입: 대량 생산에 앞서 미리 제작해보는 원형, 시제품, 모형
소프트웨어에서의 프로토타입: 사용자의 요구를 받아 모형을 만들고, 이 모형을 사용자와 의사소통 하는 도구로 활용
개발자 초기 요구사항을 반영해 1차 프로토타입을 만들고 보여줌 => 사용자는 추가 요구나 수정 요구를 하고 2차 프로토타입 제작
사용자의 요구 불투명, 요구사항의 변화가 계속 발생할 때 적합
+: 개발과정에 더욱 적극 참여 유도, 사용자의 새로운 요구사항 발견
-: 추가 비용 관리 통제하기가 어려움, 시점의 불명확
2.5. 나선형 모델 (Spiral Model)
- 보엠 제안
- 위험 분석 단계를 거침* (ex. 빈번히 변경되는 요구사항, 팀원들 경험이나 프로젝트 관리 부족, 결속력 떨어지는 팀워크)
- 계획 및 요구분석 단계
- 위험 분석 단계
- 개발 단계
- 사용자 평가 단계
+: 위험을 인식하기 때문에 프로젝트 중단이 일어날 확률 적음, 반복된 개발 방식으로 사용자 요구 충분히 반영
-: 반복 횟수가 많아질수록 프로젝트 관리 어려움, 기간이 길어짐, 위험 관리 전문가가 필요하다는 부담감
2.6. 단계적 개발 모델(Phased Development)
= 점증적 모델 (Incremental Model)
소프트웨어 개발 환경의 변화(빠른 시간 내놓는 것이 중요, 시간을 줄이기 위해 이용)
1. 점증적인 방법 (incremental method): 새 기능 추가
시스템을 여러 개의 서브 시스템으로 나누고 일부 기능만을 포함한 걸 릴리스, 다음에 새로운 기능 추가하는 방법
2. 반복적인 방법 (iterative method): 기존 기능의 향상
처음부터 시스템 전체 기능을 대상, 릴리스할 때마다 기능을 더 완벽하게 개발
2.7. 통합 프로세스 모델(Unified Process)
- 4단계 (도입, 구체화, 구축, 전이)
- 반복으로 나누어 반복 구간을 하나씩 정함
- 도입 단계 (비즈니스 모델링, 요구사항 정의 많이 이루어짐)
- 구체화 단계 (분석 및 설계 작업, 구현 및 단위 테스트 조금씩)
- 구축 단계 (구현)
- 전이 단계 (완성된 제품을 사용자에게 넘겨주는 과정에서 수행해야 할 일을 작업)
전이 단계에서 컴포넌트에 대한 베타 테스트 실시
누가 시행? 환경 개발자 역할 α 테스트 QA팀 내부 관련자 개발자 직접 관할 (모니터링) β 테스트 사용자 사용자 Feedback From User
- 공통 작업: 지속적으로 반복, 형상 및 변화, 프로젝트 관리 및 환경 점검은 지속적 수행
2.8. 애자일 프로세스 모델 (Agile Process Model)
- 상호 소통, 실행 가능한 소프트웨어, 고객, 민첩한 대응, 변화에 대한 대처 강조
- 고객, 소통 두 단어로 요약
- 기본이 되는 기능만 1차 요구사항 분석, 이를 반복으로 나누어 개발한다. 사용자가 릴리스 1을 사용하는 동안 개발자 2차 개발 진행 => 복잡한 편집 기능과 고급 기능을 추가해 반복으로 나누어 개발 =-> 실행 가능한 프로토타입을 만들어 사용자에게 확인받음
2.8.1. 스크럼 (Scrum) 방식
- 팀, 프로젝트 관리에 중점
- 제품 기능 목록 (기능 = 요구사항) 작성
- 스프린트 계획 수립
- 스프린트 수행
- 소멸 차트: 계획 대비 작업을 진행
- 계획 그래프: 처음 계획시 날짜별로 남은 작업량 (점선)
- 실제 그래프: 실제 남은 작업량 (실선)
+: 업무 집중할 수 있는 환경
-: 프로세스 품질 평가 X => 품질 정도를 모름
2.9. RAD 모델(Rappid Application Development)
- 짧은 개발주기 동안 소프트웨어를 개발하기 위한 순차적 프로세스 모델
- 폭포수 모델의 응용, 컴포넌트 기반 소포트웨어 개발
- 주요 기능들을 분리된 팀들에 의해 개발 후 통합
비즈니스 모델링, 데이터 모델링, 프로세스 모델링, 애플레키이션 생성 => 통합 시험 및 인수인계
2.10. 도구 맞춤 설계 (Design-to-Tools)
- 매우 응급한 경우, 극단적
- 기존 소프트웨어 도구에서 지원하는 기능만 제품에 넣음
- 제품 사슬을 끊을 수 있음 (제품이 나오기 위해 차례로 직전 제품을 의존)
=> 도구 맞춤 설계로 우수한 개발 속력을 얻을 수 있지만, 제품 기능 제어가 어려움
2.11. 상용 기성품 소프트웨어 (Commercial Off-the-Shelf Software = COTS SW)
- 새로운 시스템 개발한다는 흥분으로 흔히 간과
- 기성 소프트웨어: 필요한 기능을 모두 포함하는 경우 거의 X
+: 바로 구매해서 사용, 중요한 기능 일부 사용, 제품 한계를 이미 파악하고 우회책 발견할 수도 O
상용 SW vs. 고객 맞춤 SW
- 고객 맞춤 SW는 설계, 비용, 시간이 걸림
- 개발해도 이상적 SW에 미치지 못함 (해봤자 75프로)
