[정리노트] DAY1) 요구사항 분석, 소프트웨어 생명 주기

[START] 3년차 개발 비전공자의 정보처리기사 실기_최최종_2개월플랜.txt

 

▌ 강의 범위 : 1~3강

▌ 해당 강의 리스트

　1강. Part1. 요구사항 확인

　2강. 02. 소프트웨어 생명주기

　3강. 6.RAD모형

💡 강의 마치고, 최소 1~2분에서 최대 5분 꼭 복습하기

---

 

Part1. 요구사항 분석

* 컴퓨터 시스템의 구성요소 키워드 → 목적달성 / 상호 유기적

Q. 시스템에 대해 약술해라 : 목적을 달성하기 위해 구성 요소들이 상호 유기적으로 구성된 집합체이다

Q. 시스템의 구성요소를 작성해라 :   ✔입력 ✔처리 ✔출력 ✔피드백 ✔제어

　- 처리 되기 전, 의미 없는 자료들을 입력 후, 필요한 데이터로 가공처리

　  의사결정에 도움이 될 수 있는 의미있는 데이터로 출력

　  입 출력 안에서 피드백을 반복하여 필요한 데이터로 가공하며, 이 전체 프로세스를 제어

---

02. 소트프웨어 생명주기

* 소프트웨어 생명주기 -  SDLC (Software Development Life Cycle)

 - 시스템 개발주기 또는 소프트웨어 개발주기라고도 함

 - 소프트웨어의 제작 공정 과정을 형상, 문서화해서 관리하는 것을 형상 관리

 

* 기본적으로 가장 많이 출제되는 세가지 모형

1. 79년도 보헴이 만든 폭포수 모형

 - 폭포수 모형의 전체 단계

　ㄴ 개발(20%) : 계획 → 분석 → 설계 → 구현(코딩) → 시현(오류찾기) / 디버깅(오류제거)

　ㄴ 유지/보수(80%) : 인수인계 / 유지보수

- 개념상으로는 위에서 아래로, 다시 거슬러 올라갈 수 없으므로 폭포수 모형

- 개발자가 만들면서도 요구사항의 불명확성 때문에 불안하지만, 빨리 만들어서 줘야하니까 개발을 멈출순 없음

- 단계적, 순차적, 체계적인 방법

- 개발 스케일이 크지 않을 때, 비전문가 일 때 더 많이 사용

 

2. 프로토타입 모형

 - 요구사항을 정확하고 신속하게 파악할 수 있으므로 폭포수 모형의 요구사항의 불명확성을 보완할 수 있음

 - 계획 → 분석 → 프로토타입 → 고객평가 → (프로토타입 없애고 다시) 분석 → 설계 → 구현

 - 기본 단계를 급조 또는 생략하고 사용자의 요구사항에 맞춰 프로토타입을 만들어 빠르게 진행하기 때문에

　폭포수 모형과 비교했을때 비교적 품질이 떨어질 수 있음

 - 신속한 설계로 프로토타입을 작성하고 사용자에게 써보게 한 다음, 얻은 사용자의 피드백으로 고쳐서 고객평가 받고 정제

 

3. 나선형 모형

 - 보헴이 폭포수 모형에 비용이 너무 많이 발생하자 새롭게 만든 나선형 모형

 - 유지/보수 단계를 개발 단계 안으로 집어넣자고 하며, 아직 발생되지 않은 위험(risk)단계를 위험분석단계로 추가해

　주변이들의 반발심도 사고, 매너리즘 아니냐며 시기 질투도 받게됨

 - 폭포수 모형과 프로토타입 모형의 장점을 결합하고, 위험분석 단계를 추가함

 - 계획수립 → 위험분석 → 개발(코딩) → 고객적 평가 단계를 반복적으로 진행

 

4. V-모형(verification:검증)

 - 검증(테스트)을 강화시킨 모형

 - 인베디드(내장형) 시스템의 경우 유지보수 및 변형이 굉장히 힘들고,

　기존의 하드를 버리고 다시 만들어야 하는경우도 있는데 이럴때에 사용

 - 빈칸문제로 많이 출제 됨

 

5. 애자일 모형(하단에 기술)

---

6. RAD 모형

 * RAD 모형(Rapid Application Development)

 - 하나의 팀이 전체를 만드는 것이 아닌 팀별로 개발해서 작업을 합치기 때문에 매우 짧은 개발 기간

 - 빠른 개발을 위해 모듈 기반으로 개발하여 재사용이 가능한 컴포넌트로 다른 프로세스에도 적용 및 빠른 개발이 가능

 - 요구사항 파악도 잘됨

 - 순서중요 1. 비지니스모델링 / 데이터 모델링 / 프로세스 모델링 2. 애플리케이션 생성 2. 시현 및 인도

 

6. 애자일 모형

 - 전통적인 소프트웨어(폭포수 모형)와 비교해서 확인

 

	전형적(전통적)인 소프트웨어 개발모형	애자일 기법
	계획과 문서화를 중시	문서화보다는 코드의 주석(설명서) 중시
	프로세스 자체가 무거워짐	경량 프로세스
	권위주의적	2000년대 이후의 자유주의  반복적인 개발을 촉진
한계점	유지보수만 하다보면 진전이 없기때문에  모든 요구사항을 수용할 수 없음	대규모에는 적용하기 힘듬

 

** 애자일 모형의 특성 4가지(굉장히 중요함)

 - 절차와 도구보다 개인과 소통을 중요(프로젝트를 이끌어 가는 사람, 한국의 정같은게 아님)

 - 문서화보다는 소프트웨어가 잘 실행되는데 가치

 - 고객과의 피드백

 - 계획보다는 효과적인 변경 대응에 중점

 

**  애자일의 대표적인 기법

 - XP(eXtreme Programming)  : 사용자의 요구를 극한으로 들어줌

 - 스크럼(키워드 : 스프린트)

- 크리스탈 패밀리, 기능주도개발(FDD), ASD(Adaptive Software Development) ..

 

**  핵심가치 5가지

 - 용기 / 단순성 / 의사소통 / 존중 / 피드백

 

(ㄴ실천사항을 다루는 시험도 있음)

 - 소규모릴리즈

 - 테스트기반개발 시현우선개발

 - 짝프로그래밍

 - 공동코드소유