정보처리기사 1과목 소프트웨어 설계
1장. 요구사항 확인
001 소프트웨어 생명 주기 Ⓐ
폭포수 모형(Waterfall Model)
- 가장 오래되고 전통적, 고전적 생명 주기 모형
- 선형 순차적 모형
- 매뉴얼 작성
- 각 단계 이후 다음 단계를 수행하기 위한 결과물이 명확하게 산출되어야 함
- 개발 완료 후 오류 발견
- 타당성 검토 -> 계획 -> 요구 분석 -> 설계 -> 구현 -> 시험 -> 유지보수
프로토타입 모형(Prototype Model)
- 사용자의 요구사항 파악
- 견본품(Prototype)을 만들어 최종 결과물 예층
- 사용자와 시스템 사이의 인터페이스에 중점
- 요구 수집 -> 설계 -> 프로토타입 구축 -> 고객 평가 -> 프로토타입 조정 -> 구현
나선형 모형(Spiral Model)
- 점진적 모형
- Bohem이 제안
- 위험 관리와 최소화
- 요구사항 중간에 추가 가능
- 계획 및 정의 -> 위험 분석 -> 개발 -> 고객 평가
애자일 모형(Agile Model)
- 요구사항 변화에 대응, 지속적으로 반영
- 스프린트/이터레이션 이라고 불리는 짧은 개발 주기 반복
- 고객이 요구사항에 우선순위 부여
- 반복되는 주기가 끝날때마다 테스트
- ex) 스크럼(Scrum), XP(eXtreme Programming), 칸반(Kanban), Lean, 크리스탈, ASD, FDD, DSDM
002 스크럼(Scrum) 기법 Ⓐ
스크럼 팀 구성
-
제품 책임자(PO; Product Owner) : 의사 결정, 요구사항 작성, 백로그 작성, 요구사항의 우선순위 지정 및 갱신
백로그(Backlog) : 요구사항을 모아 우선순위를 부여한 목록, 지속적으로 업데이트됨
- 스크럼 마스터(Scrum Master) : 객관적인 조언, 진행 사항 점검, 장애 요소 공론화
- 개발팀(DT; Development Team)
스크럼 프로세스
- 스프린트 계획 회의 -> 스프린트 -> 일일 스크럼 회의 -> 스프린트 검토 회의 -> 스트린트 회고
003 XP(eXtreme Programming) 기법 Ⓐ
XP(eXtreme Programming)
- 짧고 반복적인 개발 주기
- 릴리즈 의 기간을 반복하며 고객의 요구사항 반영
-
5가지 핵심 가치 : 용기(Courage), 단순성(Simplicity), 의사소통(Communication), 피드백(Feedback), 존중(Respect)
XP의 5가지 핵심가치 : 용 단 의 피 존
- 고객의 요구사항을 표현한 사용자 스토리에 테스트케이스 도 기재함
- 릴리즈 는 소규모로 하는게 좋음
- ex) Pair Programming, Test-Driven Development, Whole Team, Continuous Integration, Design Improvement, Small Release
004 현행 시스템 파악 Ⓒ
현행 시스템 파악 절차
- 1단계 : 시스템 구성 파악, 시스템 기능 파악, 시스템 인퍼테이스 파악
- 2단계 : 아키텍처 구성 파악, 소프트웨어 구성 파악
- 3단계 : 하드웨어 구성 파악, 네트워크 구성 파악
005 개발 기술 환경 파악 Ⓒ
요구사항 식별 시 고려사항
- 가용성 : 시스템 장기간 운영으로 인해 발생하는 장애 발생 가능, 결함으로 인한 성능 저하 및 재가동
- 성능 : 대규모 작업 처리
- 기술 지원 : 제작업체의 안정적인 기술 지원, 여러 사용자들 간의 정보 공유, 오픈 소스 여부
- 상호 호환성 : 주변기기 지원 여부
- 구축 비용 : 라이선스 정책 및 비용, 유지 관리 비용, 총 소유 비용(TCO)
006 요구사항 정의 Ⓑ
요구사항
- 개발이나 유지 보수 과정에서 필요한 기준과 근거 제공
- 이해관계자들 간의 의사소통을 도움
- ex) 기능 요구사항 - 비기능 요구사항 / 시스템 요구사항 - 사용자 요구사항
기능 요구사항
- 시스템이 무엇을 하는지, 어떤 기능을 하는지
- 시스템이 어떤 데이터를 다루는지
- 시스템이 반드시 수행해야 하는 기능
비기능 요구사항
- 시스템 장비 구성 : 하드웨어, 소프트웨어, 네트워크 …
- 성능 : 처리 속도 및 시간, 처리량 …
- 인터페이스 : 시스템 인터페이스와 사용자 인터페이스에 대한 요구사항
- 데이터 : 데이터 변환, 데이터 구축을 위해 필요한 요구사항
- 품질 : 가용성, 정합성, 상호 호환성, 대응성, 신뢰성, 유지/관리성, 이식성, 확장성, 보안성
- 테스트
- 보안
- 제약사항
- 프로젝트 관리 / 프로젝트 지원
요구사항 개발 프로세스
- 도출 -> 분석 -> 명세 -> 확인/검증
007 요구사항 분석 기법 Ⓒ
요구사항 분석 기법
- 요구사항 분류
- 개념 모델링 : 현실 세계의 상황을 단순화하여 개념적으로 표현한 모델을 만드는 과정
- 요구사항 할당 : 요구사항을 만족시키기 위한 구성 요소 식별
- 요구사항 협상 : 요구사항 충돌 시 해결
- 정형 분석(Formal Analysis) : 정형화된 언어를 이용, 요구사항 분석의 마지막 단계
008 요구사항 확인 기법 Ⓒ
요구사항 확인 기법
- 요구사항 검토
- 프로토타이핑 : 프로포타입을 만들어 요구사항을 반영하면서 지속적으로 프로토타입 재작성
- 모델 검증 : 모델이 요구사항을 충족시키는지 검증
- 인수 테스트 : 사용자 입장에서 요구사항 확인
009 UML(Unified Modeling Language) Ⓐ
UML(Unified Modeling Language)
- 객체지향 모델링 언어
- Rumbaugh(OMT), Booch, Jacobson 방법론의 장점 통합
- 구성 요소 : 사물, 관계 다이어그램
Booch 방법 : “절차지향 프로그램을 개발하려면 동사에 밑줄을 긋고, 객체지향 프로그램을 개발하려면 명사에 밑줄을 그어라”
Rumbaugh 방법 : 객체 모델링(객체 다이어그램 표시) -> 동적 모델링(상태 다이어그램 사용) -> 기능 모델링(자료 흐름도(DFD; Data Flow Diagram) 이용)
사물(Things)
- 관계가 형성될 수 있는 대상
-
구조 사물(Structural Things)
- 개념적, 물리적 요소 표현
- Class, Use Case, Component, Node
-
행동 사물(Behavioral Things)
- 요소들의 행위 표현
- Interaction, State Machine
-
그룹 사물(Grouping Things)
- Package
-
주해 사물(Annotation Things)
- 부가적인 설명, 제약조건
- Note
UML의 사물 4가지 : 구 행 그 주
관계(Relationships)
- 연관 관계(Association) : A와 B는 서로 관련됨 (A ─> B)
- 집합 관계(Aggregation) : A가 B에 포함되며 A와 B는 서로 독립적 (B ◇─ A)
- 포함 관계(Composition) : A가 B에 포함되며 A는 B에 영향을 미침 (B ◆─ A)
- 일반화 관계(Generalization) : A는 B보다 더 일반적임 (A ◁─ B)
- 의존 관계(Dependency) : A는 B에 연관이 있으나 일시적으로 영향을 줌 (A ‥> B)
- 실체화 관계(Realization) : 사물 B는 기능 A로 그룹화할 수 있음 (A ◁‥ B)
다이어그램(Diagram)
- 정적 모델링 -> 구조적 다이어그램 / 동적 모델링 -> 행위 다이어그램
- 구조적(Structural) 다이어그램 : 클래스 다이어그램, 객체 다이어그램, 컴포넌트 다이어그램, 배치 다이어그램, 복합체 구조 다이어그램, 패키지 다이어그램
- 행위(Behavioral) 다이어그램 : 유스케이스 다이어그램, 시퀀스 다이어그램, 커뮤니케이션 다이어그램, 상태 다이어그램, 활동 다이어그램, 상호작용 개요 다이어그램, 타이밍 다이어그램
REFERENCE
2020 시나공 정보처리기사 필기 : NCS 기반 전면 개편[개정판]