1과목 -1(필기) 내용 정리

 

 

 

 

1. 폭포수 모형 -> Waterfall Model

(1) 모형을 적용한 경험과 성공 사례가 많다

(2) 각 단계가 끝난 후에는 다음 단계를 수행하기 위한 결 과물이 명확하게 산출되어야 한다.

(3) 소프트웨어 개발 과정의 한 단계가 끝나야만 다음 단계 로 넘어갈 수 있는 선형 순차적 모형이다.

(4) 소프트웨어 공학에서 가장 오래되고 가 장 폭넓게 사용된 전통적인 소프트웨어 생명 주기 모형 으로, 고전적 생명 주기 모형이라고도 한다.

(5) 타당성 검토 -> 계획 -> 요구분석 -> 설계 -> 구현(코딩) -> 시험(검사) -> 유지보수

 

 

 

 

 

2. 나선형 모형 -> Spiral Model

(1) 폭포수 모 형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형이다.

(2) 점진적 모형

(3) 소프트웨어를 개발하면서 발생할 수 있는 위험을 관리 하고 최소화하는 것을 목적으로 한다.

(4) 점진적으로 개발 과정이 반복되므로 누락되거나 추가 된 요구사항을 첨가할 수 있고, 정밀하며, 유지보수 과 정이 필요 없다.

(5) 계획 수립 -> 위험 분석 -> 개발 및 검증 -> 고객 평가

 

 

 

 

3. 애자일 모형 -> Agile Model

(1) 고객의 요구사 항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복 하면서 개발과정을 진행한다.

(2) 고객과의 소통에 초점을 맞춘 방법론을 통칭한다.

(3) 기업 활동 전반에 걸쳐 사용된다.

(4) 스크럼(Scrum), XP(eXtreme Programming), 칸반 (Kanban), Lean, 크리스탈(Crystal), ASD(Adaptive Software Development), 기능 중심 개발(FDD; Feature Driven Development), DSDM(Dynamic System Development Method), DAD(Disciplined Agile Delivery) 등이 있다.

 

---

 

1. 애자일 개발 4가지 핵심 가치

(1)  프로세스와 도구보다는 개인과 상호작용에 더 가치를 둔다.

(2) 방대한 문서보다는 실행되는 SW에 더 가치를 둔다.

(3) 계약 협상보다는 고객과 협업에 더 가치를 둔다.

(4) 계획을 따르기 보다는 변화에 반응하는 것에 더 가치를 둔다.

 

 

 

 

 

2. 스크럼(Scrum) -> 애자일

(1) 제품 책임자(PO; Product Owner)

- 이해관계자들 중 개발될 제품에 대한 이해도가 높고, 요구사항을 책임지고 의사 결정할 사람으로 선정하는 데, 주로 개발 의뢰자나 사용자가 담당한다.

 

(2) 스크럼 마스터(SM; Scrum Master)

- 스크럼 팀이 스크럼을 잘 수행할 수 있도록 객관적인 시각에서 조언을 해주는 가이드 역할을 수행한다.

 

(3) 개발팀(DT; Development Team)

- 제품 책임자와 스크럼 마스터를 제외한 모든 팀원으로, 개발자 외에도 디자이너, 테스터 등 제품 개발을 위해 참여하는 모든 사람이 대상이 된다.

 

 

 

 

 

3. 스크럼 개발 프로세스

(1) 제품 백로그 (Product Backlog)

(2) 스프린트 계획 회의 (Sprint Planning Meeting)

(3) 스프린트(Sprint)

(4) 일일 스크럼 회의 (Daily Scrum Meeting)

(5) 스프린트 검토 회의 (Sprint Review) 

(6) 스프린트 회고 (Sprint Retrospective)

 

---

 

1. XP(eXtreme Programming

(1) 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방 법이다.

(2) 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여를 통해 소프트웨어를 빠르게 개발하는 것을 목적으로 한다.

(3) 릴리즈의 기간을 짧게 반복하면서 고객의 요구사항 반 영에 대한 가시성을 높인다. 

(4) XP의 5가지 핵심 가치

- 의사소통(Communication)

- 단순성(Simplicity)

- 용기(Courage)

- 존중(Respect)

- 피드백(Feedback)

 

 

 

 

 

2, XP의 주요 실천 방법(Practice)

(1) Pair Programming (짝 프로그래밍)

(2) Collective Ownership (공동 코드 소유) 

(3) Test-Driven Development (테스트 주도 개발)

(4) Whole Team (전체 팀)

(5) Continuous Integration (계속적인 통합) 

(6) Design Improvement (디자인 개선) 또는 Refactoring(리팩토링) : 프로그램 기능의 변경 없이, 단순화, 유연 성 강화 등을 통해 시스템을 재구성함

(7) Small Releases (소규모 릴리즈)

 

 

 

---

 

1. 데이터베이스 관리 시스템 -> DBMS

(1) 요구사항 식별 시 고려사항

- 가용성

- 성능

- 기술 지원

- 상호 호환성

- 구축 비용

 

 

 

 

 

2. 웹 애플리케이션 서버(WAS)

(1) 정적인 콘텐츠 처리를 하는 웹 서 버와 달리 사용자의 요구에 따라 변하는 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어이다.

(2) 데이터 접근, 세션 관리, 트랜잭션 관리 등을 위한 라이 브러리를 제공한다.

(3) 주로 데이터베이스 서버와 연동해서 사용한다.

(4) 웹 애플리케이션 서버의 종류에는 Tomcat, GlassFish, JBoss, Jetty, JEUS, Resin, WebLogic, WebSphere 등이 있다.

 

 

 

 

 

3. 요구사항 유형

(1) 기능 요구사항 (Functional requirements)

- 시스템이 무엇을 하는지, 어떤 기능을 하는지에 대한 사항

- 시스템의 입력이나 출력으로 무엇이 포함되어 야 하는지, 시스템이 어떤 데이터를 저장하거나 연산을 수행해야 하는지에 대한 사항

- 시스템이 반드시 수행해야 하는 기능

- 사용자가 시스템을 통해 제공받기를 원하는 기능

 

(2) 비기능 요구사항 (Non- functional requirements)

- 시스템 장비 구성 요구사항 

- 성능 요구사항

- 인터페이스 요구사항

- 데이터 요구사항

- 테스트 요구사항

- 보안 요구사항

- 품질 요구사항

- 제약사항 

- 프로젝트 관리 요구사항

- 프로젝트 지원 요구사항

 

 

---

 

1. 요구사항 개발 프로세스

(1) 도출 -> 분석 -> 명세 -> 확인

 

 

 

2. 요구사항 명세 기법

(1) 정형 명세 기법

- 기법 : 수학적 원리 기반, 모델 기반

- 작성 방법 : 수학적 기호, 정형화된 표기법

- 특징 : 요구사항에 대한 결과가 작성자에 관계없이 일관성이 있으므로 완전한 검증이 가능함

- 종류 : VDM, Z, CSP 등

 

(2) 비정형 명세 기법

- 기법 : 상태/기능/객체 중심

- 작성 방법 : 자연어를 기반으로 서술 또는 다이어그램으로 작성

- 특징 : 자연어의 사용으로 인해 요구사항에 대한 결과가 작성자에 따라 다를 수 있어 일관성이 떨어지고, 해석이 달라질 수 있음

- FSM, ER모델링, SADT 등

 

---