1. 요구사항 확인
* Spiral Model (나선형 모델)
: 나선형 모형은 보헴(Boehm)이 제안한 것으로, 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형이다.
- 나선을 따라 돌듯이 여러 번의 소프트웨어 개발 과정을 거쳐 점진적으로 완벽한 소프트웨어를 개발하는 것 -> 점진적 모형
- 소프트웨어를 개발하면서 발생할 수 있는 위험을 관리하고 최소화하는 것이 목적
- 점진적으로 개발 과정이 반복되므로 누락되거나 추가된 요구사항을 첨가할 수 있고, 정밀하며, 유지보수 과정이 필요 없다.
개발과정
[계획(수립) - (위험)분석 - 개발(및 검증) - (고객)평가] 순으로 반복
<"Spiral Model"을 설명하는 문제 지문>
- 프로토타입을 지속적으로 발전지켜 최종 소프트웨어 개발까지 이르는 개발방법으로 위험관리가 중심인 소프트웨어 생명주기 모형 : 나선형 모형
- (나선형 모형은) 초기에 위험요소를 발견하지 못할 경우 위험요소를 제거하기 위해 많은 비용이 소요될 수 있다.
* Scrum (스크럼)
: 스크럼은 팀이 중싱이 되어 개발의 효율성을 높인다는 의미가 내포된 용어
- 스크럼은 팀원 스스로가 스크럼 팀을 구성(self-organizing)해야 하며, 개발 작업에 관한 모든 것을 스스로 해결(crodd-funtional)할 수 있어야 한다. (애자일 모형 기반)
- 스크럼 팀은 "제품 책임자" , "스크럼 마스터" , "개발팀"으로 구성
* 제품 책임자(PO; Product Owner) -> 개발팀 중 주장!
: 이해관계자들 중 개발될 제품에 대한 이해도가 높고, 요구사항을 책임지고 의사를 결정할 사람으로 선정 (주로 개발 의뢰자 나 사용자 가 담당)
★ 역할
- 이해관계자들의 의견을 종합하여 제품에 대한 요구사항을 작성하는 주체
- 요구사항이 담긴 백로그(Backlog : 우선순위가 부여된 요구사항 목록)를 작성하고 백로그에 대한 우선순위를 지정
- 팀원들이 백로그에 스토리(서술회된 요구사항)를 추가할 수 있지만 우선순위를 지정할 수 없음
- 주기가 지남에 따라 요구사항 우선순위 갱신
* 스크럼 마스터(SM; Scrum Master)
: 스크럼 팀이 스크럼을 잘 수행할 수 있도록 객관적인 시각에서 조언을 해주는 가이드 역할
- 팀원 통제가 목적이 아님
★ 역할
- 일일 스크럼 회의를 주관하여 진행 사항을 점검하고, 개발 과정에서 발생된 장애 요소를 공론화하여 처리
* 개발팀(DT; Development Team)
: 제품 책임자와 스크럼 마스터를 제외한 모든 팀원으로, 개발자 외에도 디자이너, 테스터 등 제품 개발을 위해 참여하는 모든 사람이 대상이 된다.
- 보통 최대 인원은 7~8명이 적당
- 스크럼 개발 과정
1. 스프린트 계획 회의
2. 스프린트
3. 일일 스크럼 회의
4. 스프린트 검토 회의
5. 스프린트 회고
<"Scrum"을 설명하는 문제 지문>
- 스크럼의 팀 구성 요소 중 이해관계자들의 의견을 종합해 백로그를 작성하는 주체 => 제품 책임자(PO)
* eXtreme Programming : XP (익스트림 프로그래밍)
: XP는 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법
- 짧고 방복적인 개발주기, 단순한 설계, 고객의 적극적인 참여 => SW를 빠르게 개발하는 것이 목적
- 릴리즈 테스트 마다 고객을 참여시켜 요구기능의 작동여부를 고객이 직접 확인
- XP의 5가지 핵심 가치
1. 의사소통 (Communication)
2. 단순성 (Simplicity)
3. 용기 (Courage)
4. 존중 (Respect)
5. 피드백 (Feedback)
- XP의 주요 실천 방법 (Practice)
1. Pair Programming (짝 프로그래밍; 개발에 대한 책임 공유)
2. Collective Ownership (공동 코드 소유; 개발에 대한 권한 / 책임 공통 소유)
3. Test-Driven Developmeht (테스트 주도 개발; 실제 코드 작성전 테스트 코드 먼저 작성)
4. Whole Team (전체 팀; 각자 자신의 역할 / 책임 가짐)
5. Continuous Intergration (계속적인 통합; 모듈을 나눠 개발 후 통합)
6. Design Improvement / Refactoring (디자인 개선 / 리팩토링; 프로그램 기능 변경 없이, 단순화, 유연성 강화 등 시스템 재구성)
7. Small Releases (소규모 릴리즈; 릴리즈 기간을 짧게 반복 -> 고객의 요구변화에 신속히 대응)
* 소프트웨어 공학
: 여러가지 방법론과 도구, 관리 기법들을 통하여 소프트웨어 품질과 생산성을 향상시킬 목적
- IEEE 의 소프트웨어 공학 표준 용어사전 : 소프트웨어의 개발, 운용, 유지보수, 폐기 처분에 대한 체계적 접근 방안
* Agile Model (애자일 모형)
: 애자일은 고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 개발과정을 진행한다.
- 애자일 모형은 스프린트(Sprint) 또는 이터레이션(Iteration)이라고 불리는 짧은 개발 주기를 반복하며, 반복되는 주기마다 만들어지는 결과물에 대한 고객의 평가와 요구를 적극 수용한다.
- 애자일 모형을 기반으로 하는 소프트웨어 개발 모형
스크럼(Scrum), XP(eXtreme Programming), 칸반(Kanban), Lean, 크리스탈(Crystal), ASD(Adaptive Software Development), 기능 중심 개발(FDD; Feature Driven Development), DSDM(Dynamic System Development Method), DAD(Disciplined Agile Delivery) 등이 있다.
<"Agile Model"을 설명하는 문제 지문>
- 애자일은 문서화 보다 실행되는 SW에 비중을 둔다.
- 절차와 도구보다 개인과 소통을 중요하게 생각한다.
2. 화면 설계
* ISO / IEC 9126
: ISO / IEC 9126은 (개발자 관점에서 본) 소프트웨어의 품질 특성과 평가를 위한 표준 지침으로서 국제 표준으로 널리 사용된다.
(소프트웨어의 품질은 사용자의 요구사항을 충족시킴으로써 확립된다.)
- 소프트웨어의 품질에 대한 요구사항 기술 / 개발 중 (혹은 완료)인 소프트웨어의 품질 평가에 사용
<ISO / IEC 9126에서 제시한 소프트웨어의 품질 특성>
1. 기능성 (Functionality : SW가 사용자의 요구사항을 정확하게 만족하는 기능을 제공하는가)
1-1. 적절성 / 적합성 (Suitabilty ; 제공하는 기능이 적절한가)
1-2. 정확성 / 정밀성 (Accuracy ; 산출되는 결과가 정확한가)
1-3. 상호 운용성 (Interoperability ; 다른 시스템과 어울려 작업하는가)
1-4. 보안성 (Security; 권한에 따라 접근을 허용 / 차단)
1-5. 준수성 (Compliance ; 기능이 규정을 준수하는가)
2. 신뢰성 (Reliability ; 주어진 기능을 오류없이 수행하는 정도)
2-1. 성숙성 (Maturity; 고장을 피해가는 능력)
2-2. 고장 허용성 (Fault Tolerance; 고장을 허용해도 성능을 만족하는가)
2-3. 회복성(Recoverability; 성능 회복 / 데이터 복구)
3. 사용성 (Useability ; 쉽게 배우고 사용할 수 있는 정도)
이해성(Understandability), 학습성(Learnability), 운용성(Operability), 친밀성(Attractiveness; 다시 사용하고 싶음)
4. 효율성 (Efficiency; 한정된 시간/자원으로 처리 정도)
시간 효율성, 자원 효율성
5. 유지 보수성 (Maintainability)
분석성, 변경성, 안정성, 시험성
6. 이식성 (Portability)
소프트웨어가 다른 환경에서 얼마나 쉽게 적용할 수 있는가
적용성, 설치성, 대체성, 공존성
* ISO / IEC 12119 : ISO / IEC 9126을 준수한 품질 표준으로 테스트 절차를 포함하여 규정함
<"ISO / IEC 9126" 과 관련된 문제 지문>
- 주 특성과 부 특성 연결하기 (영어)
* UI 설계도구
: UI 설계 도구는 사용자의 요구사항에 맞게 UI의 화면 구조나 화면 배치 등을 설계할 때 사용하는 도구
1. Wireframe (와이어프레임)
: 기획단계 초기 제작 , 페이지에 대한 개략적인 레이아웃 / UI 요소
Wireframe Tool : 손그림, 파워포인트, 키노트, 스케치, 일러스트, 포토샵 등
2. Mockup (목업)
: Wireframe 보다 좀더 실제화면과 유사하게 만듦, 정적인 형태의 모형
Mockup Tool : 파워 목업, 발사믹 목업 등
3. Story Board (스토리 보드)
: Wireframe에 콘텐츠에 대한 설명, 페이지 간 이동 흐름 등을 추가한 문서
- 디자이너나 개발자가 최종적으로 참고하는 작업 지침서 (명확하고 세부적으로 작성)
Story Board Tool : 파워포인트, 키노트, 스케치, Axure 등
4. Prototype (프로토타입)
: Wireframe 이나 Stort Borad 등에 인터렉션을 적용, 실제 구현된 것 처럼 테스트가 가능 / 동적인 형태의 모형
(인터렉션; Interaction) : UI를 통해 시스템을 사용하는 일련의 상호작용 (EX) 버튼을 클릭 -> 해당 페이지로 이동)
Prototype Tool : HTML/CSS, Axure, Flinto, 네이버 프로토나우, 카카오 오븐 등
5. Use Case (유스케이스)
: 사용자 측면에서의 요구사항, 사용자가 원하는 목표를 달성하기 위해 수행할 내용 기술
- 사용자의 요구사항을 빠르게 파알 -> 프로젝트 초기에 시스템의 기능적인 요구 결정, 그 결과를 문서화
(자연어로 작성 / 사용자가 입장이니까)
3. 애플리케이션 설계
* 소프트웨어 아키텍쳐 설계 과정
1. 설계 목표 설정
2. 시스템 타입 결정
3. 아키텍쳐 패턴 적용
4. 서브시스템 구체화
5. 검토
* 추상화 (Abstraction) / (소프트웨어 아키텍쳐 설계의 기본 원리 : 모듈화, 추상화, 단계적 분해, 정보은폐)
: 추상화는 문제의 전체적이고 포괄적인 개념을 설계한 후 차레로 세분화 하여 구체화 시켜 나가는 것
<추상화의 유형>
과정 추상화 : 자세한 수행 과정 정의 X , 전반적인 흐름만 파악
데이터 추상화 : 데이터의 세부 정보 정의 X, 데이터 구조를 대표하는 표현
제어 추상화 : 이벤트 발생의 정확한 절차 / 방법 정의 X, 대표할 수 있는 표현
( CF) "제(어)과(정)자(료)" )
* 아키텍쳐 패턴 - (다른 사람들의 오류 처리 오답노트)
: 아키텍처를 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제
<아키텍쳐 패턴 종류>
1. Layers pattern (레이어 패턴)
: 시스템을 계층(Layer)으로 구분하여 구성
- 서브시스템들이 계층 구조를 이룸
- 서로 마주보는 두개의 계층 사이에서만 상호작용
EX) OSI 참조 모델
2. Client - Server Pattern (클라이언트 - 서버 패턴)
:하나의 서버 컴포넌트화 다수의 클라이언드 컴포넌트로 구성
사용자 -> 클라이언트 : 의사소통
클라이언트 -> 서버 : 정보 요청
서버 -> 클라이언트 : 정보 제공
클라이언트 -> 사용자 : 정보 제공
- 클라이언트 는 중계자 역할 / 서버는 클라이언트 요청에 대비 하여 항상 대기 상태
서버 / 클라이언트 서로 독립적
3. Pipe - Fiter Pattern (파이프 - 필터 패턴)
: 데이터 스트림 절차의 각 단계를 필터(Filter) 컴포넌트로 캡슐화 하여 파이프(Pipe)를 통해 데이터를 전송하는 패턴
- 필터 간 데이터 이동 시 데이터 변환으로 인한 오버헤드가 발생
EX) UNIX의 Shell
4. Model - View - Controller Pattern (MVC Pattern; 모델 - 뷰 - 컨트롤러 패턴)
- Model : 서브시스템의 핵심 기능과 데이터를 보관
- View : 사용자에게 정보를 표시
- Controller : 사용자로부터 받은 입력을 처리
EX) 대화형 어플리케이션
+) Master - Slave Pattern
- 장애 허용 시스템 / 병렬 컴퓨팅 시스템에서 주로 활용
+) Peer - To - Peer Pattern
: 피어(Peer)를 하나의 컴포넌트로 간주, 각 피어는 서비스를 호출하는 클라이언트가 될 수도, 서버가 될 수도 있는 패턴
- 클라이언트와 서버는 전형적인 멀티스레딩 방식을 사용
+) Blackboard Pattern
: 해결책이 명확하지 않은 문제에서 사용
음성인식, 차량식별, 신호해석 등에 주로 사용
이미지 출처
1. 나선형 모델 : https://terms.naver.com/entry.naver?docId=3532879&cid=58528&categoryId=58528
