현행 시스템 분석
- 개념: 어떤 하위 시스템으로 구성되어 있는 지 파악하는 절차
- 목적: 개발 범위와 이향 방향성 설정
- 현행 시스템 파악 절차
- 시스템 구성 파악 → 시스템 기능 파악 → 시스템 인터페이스 현황 파악
- 아키텍처 파악 → 소프트웨어 구성 파악
- 시스템 하드웨어 현황 파악 → 네트워크 구성 파악
- 시스템 아키텍처: 시스템 내의 상위, 하위 시스템들이 어떠한 관계로 상호작용하는지 각각의 동작원리와 구성을 표현한 것
- 설계과정: 설계목표 설정 → 시스템 타입결정 → 스타일 적용 및 커스터마이즈 → 서브시스템의 기능, 인터페이스 동작 작성 → 아키텍처 설계 검토
시스템 및 인터페이스 현황 파악
시스템 구성 파악
- 기간 업무와 지원 업무로 구분하여 기술
구분 | 시스템명 | 시스템 내용 |
---|---|---|
기간 업무 | 단위 A업무 | A1, A2등의 기능을 제공 |
지원 업무 | 지원 B업무 | B1, B2등의 기능을 제공 |
시스템 기능 파악
- 현재 제공하고 있는 기능을 주요 기능과 하부 기능으로 구분해 계층형으로 표시
시스템명 | 기능 L1 | 기능 L2 | 기능 L3 |
---|---|---|---|
단위 A업무 시스템 | 기능1 | 하부기능 11 | 세부기능 111 세부기능 112 |
하부기능 12 | 세부기능 121 세부기능 122 |
||
기능2 | … | … |
인터페이스 현황 파악
- 타 업무시스템과 서로 주고받는 데이터 형식, 통신규약, 연계유형 등을 명시
- 데이터 형식: XML, 고정 Format, 가변 Format
- 통신 규약: TCP/IP, X.25
- 연계 유형(미들 웨어): EAI, FEP
- EAI: 기업 내의 컴퓨터 애플리케이션들을 현대화 통합하는 것을 목표로 세운 계획, 방법 및 도구
- FEP(전처리기): 입력데이터를 프로세서가 처리하기 전에 미리 처리
플랫폼 Platform 파악
- 플랫폼: 응영 프로그램을 실행 하기 위한 하드웨어와 시스템 소프트웨어의 결합
- 구성: 응용 소프트웨어 + (하드웨어 + 시스템 소프트웨어)
- 종류
- 운영체제 플랫폼: Windows, macOS, …
- 애플리케이션 플랫폼: Java, .NET Framework, …
- 클라우드 플랫폼: AWS
- 데이터베이스 플랫폼: Oracle, MySQL, …
- …
- 플랫폼 성능 특성 분석 항목 ⭐
- 경과시간(Turnaround Time): 작업 요청~결과가 반환 까지의 시간
- 사용률(Utilization): 시스템 또는 자원의 활용정도
- 응답시간(Response Time): 시스템 또는 서비스가 요청 ~ 응답완료 까지의 시간
- 가용성(Availability): 시스템이 가동 중지없이 지속적으로 사용 가능한 시간을 백분율로 나타낸 것
- 플랫폼 성능 특성 분석 방법: Performance Test, 사용자 인터뷰, 문서 점검
- 플랫폼 사용의 이점: 개발 비용 감소, 시간 단축,…
시스템 아키텍처 | 플랫폼 |
---|---|
소프트웨어 시스템의 전체구조 및 구성 요소 간의 관계를 설계하는 것 | 하드웨어나 소프트웨어를 실행할 수 있는 플랫폼을 제공하는 소프트웨어 |
소프트웨어 시스템의 설계단계에서 수행 | 소프트웨어 실행 단계에서 사용 |
현행 시스템 운영체제 분석
- 분석 항목: OS종류와 버전, …
- 고려사항: 가용성, 성능, 구축 비용(TCO), 메모리 누수
- 오픈 소스 라이선스 종류: GNU, Apache2.0(Hadoop: 오픈소스를 기반으로 한 분산 컴퓨팅 플랫폼 )
현행 시스템 DBMS분석
- DBMS: 데이터베이스 관리 시스템 , 종속성과 중복성의 문제를 해결하기 위해 제안된 시스템, 응용 프로그램과 데이터의 중재자
- 종류: Oracle, MySQL, …
- 고려사항: 가용성, 성능, 기술 지원, 상호 호환성, 구축비용
요구사항 개발
요구공학 Requirements Engineering
- 개념: 비전문가인 고객에게 유의미한 것을 뽑아내는 기술
- 목적: 요구사항 누락 방지, 상호이해, 오류 제거 ⇒ 경제성 제공
- 요구사항 BaseLine:
- 이해 당사자 간의 명시적 합의 내용
- 추후 발생할 수 있는 변경 사항을 체계적으로 관리하기 위한 기준
- 요구 사항 분류:
- 기술 내용에 따른 분류: 기능, 비기능 요구사항
- 기술 관점 및 대상에 따른 분류: 시스템, 사용자 요구사항
- 요구 사항 분류 기준:
- 기능, 비기능 요구사항을 구분하고 우선순위 여부 확인
- 요구사항이 하나 이상의 고수준 요구사항으로부터 유도된 것인지 확인
- 다른 원천(Source)으로부터 직접 발생한 것인지 확인
- 요구사항이 제품에 관한 것인지 프로세스에 관한 것인지 확인
- 소프트웨어에 미치는 영향의 범위 확인
- 생명주기 동안 변경이 발생하는지 확인
기능적 요구사항 | 비기능적 요구사항 |
---|---|
시스템이 어떻게 동작하는지 | 성능, 보안, 품질, 안정성 등 |
SWEBOK기반의 요구사항 개발 프로세스
- 도출(Elicitation)→ 분석(Analysis) → 명세(Specification) → 확인(검증)(Validation)
요구사항 도출 Requirment Elicitation
- 도출 기법: 고객의 발표, 문서조사, 설문, 브레인스토밍, Use Case, BPR(업무 재설계), RFP(제안요청서)
요구사항 분석 Requirement Analysis
- 소프트웨어가 환경과 어떻게 상호 작용하는지 이해하고 요구사항을 문서화하는 과정
- 개발 범위 파악, 개발 비용, 일정에 대한 제약 설정, 타당성 조사
- 소프트웨어의 범위(비용과 일정)을 파악
- 충분하고 정확하게 기술
- 기법: 사용자 의견청취, 인터뷰, 문서 분석과 중제, 관찰 및 모델 작성 기술, 설문조사를 통한 의견 수렴
- 문제인식 → 전개 → 평가와 종합 → 검토 → 문서화
요구사항 명세 Requirment Specification
- 시스템 정의, 시스템 요구사항, 소프트웨어 요구사항을 작성
- 체계적으로 검토, 평가, 승인될 수 있도록 문서로 만드는 것
- 비기능 요구사항은 필요한 것만 명확하게 기술
- 사용자가 쉽게 이해할 수 있도록 작성
- 명세 기법
정형 명세 비정형 명세 기법 수학적 기반, 모델링 기반 상태/기능/객체 중심 명세기법, 자연어 기반 종류 Z, VDM Decision Table, SADT, Use Case 장점 간결하게 표현 이해 용이, 의사전달 방법 다양성 단점 사용자의 낮은 이해도, 이해관계자의 부담 가중 불충분한 명세 기능, 모호성
요구사항 관리 Requirment Management
- 요구사항 명세서와 관련된 변경사항 추적, 관리
- 요구사항 관리도구의 필요성
- 요구사항을 관리하는 프로세스의 효율성 제고
- 빠지거나 중복되는 요구사항을 쉽게 관리
- 요구사항 변경으로 비용 편익 분석 용이
- 변경이 시작된 부분을 추적하기 용이
요구사항 할당 Requirment Allocation
- 요구사항을 만족시키기 위한 아키텍처 구성요소를 식별하는 활동
- 타 구성 요소와 상호 작용 여부 분석을 통한 추가 요구사항 발견
요구사항 확인 기법
- 종류: 프로토타이핑, 모델검증, 요구사항 검토(Requirement Reviews), 인수 테스트(Acceptance Tests)
- +(인터뷰, 설문조사, 시나리오, 스토리보드, 워키숍, 브레인스토밍, 분석 모델링)
프로토타이핑 Prototyping
- 도출된 요구사항을 토대로 프로토타입을 제작해 대상 시스템과 비교하면서 추가요구사항을 지속해서 재작성하는 도구
- 분석(요구사항 명세서 작성)→ 설계 → 개발 → 검토 및 피드백 → 프로토타입 정제(수정) → 요구사항 검증
- 장점
- 유용한 피드백 제공
- 이해하기 쉬워 의사소통에 도움이 됨
- 요구사항의 가변성이 프로토타이핑 이후 감소
- 빠르게 제작 가능
- 반복 제작으로 발전된 결과 도출 가능
- 단점
- 사용자의 관심이 핵심기능에서 멀어 질 수 있음(디자인이나 품질 문제로 집중됨)
- 프로토타입 수행 비용 발생
- 일부 범위만 프로토타입을 제작하면 사용성이 과대 평가될 수 있음
모델 검증 Model Verification
- 분석단계에서 개발된 모델의 품질을 검증
- 오류를 최소화하고 품질을 향상시키는 것을 목적으로 함
- 종류
- 정적 분석 Static Analysis :
- 의사소통 경로를 검증
- 명세의 일관성과 정확성을 확인, 분석
- 소스코드를 실행하지 않음
- 잠재적인 오류를 찾아내기 위함
- 동적 분석 Dynamic Analysis :
- 직접 실행을 통해 모델을 검증
- 작성된 소스코드를 실행
- 코드에 존재하는 메모리 누수 현황 발견
- 정적 분석 Static Analysis :
인수 테스트 Acceptance Tests ⭐
- V-모델의 인수테스트
- 소프트웨어가 사용자나 고객의 요구사항을 만족시키는지 확인하기 위한 테스트 단계
- 소프트웨어 개발의 마지막 단계에서 이루어짐, 문제를 사전에 발견해 수정할 수 있도록 함
- 종류: 계약 인수 테스트, 규정 인수 테스트, 알파 검사, 베타 검사, 사용자 인수 테스트, 운영 인수 테스트
- 알파 검사:
- 소프트웨어 개발 중 초기 단계에서 주로 사용되는 테스트 방법
- 소프트웨어의 기능과 성능을 개발자들이 직접 테스트
- 베타 검사:
- 소프트웨어가 완성되고 공개적으로 출시되기 전에 일반 사용자에게 제공하여 테스트하는 방법
- 알파 검사:
- 계획→ 설계(테스트케이스 작성) → 구현(테스트케이스 실행) → 검토(테스트결과 분석 후 수정)
→ 수행(수정된 것 다시 테스트, 인수 조건 만족 여부 확인) → 완료(문서화)
정형 기술 검토 FTR
- 요구사항 일치 여부, 표준 준수 및 결함 발생 여부를 검토하는 정적 분석 기법
- 목적: 품질 향상, 생산성 향상, 지식 공유, 표준 준수, 비용 절감
- 특징:
- 구조화된 절차
- 전문가의 참여
- 오류와 결함을 찾아내는 능력을 향상
- 개발 초기에 적용 가능
- 문서화 중요
- 정형 기술 검토 지침 사항 ⭐
- 의제와 그 범위 유지
- 참가자의 수 제한
- 개발자가 아닌 제품의 검토에 집중
- 논쟁과 반박 제한
- 검토 과정과 결과를 재검토
개념 모델링 Conceptual Modeling
- 모델: 요구사항을 이해하기 쉽도록 상황을 단순화하여 개념적으로 표현한 것
- 개념 모델링: 표현된 모델을 생성해 나가는 과정
- 대부분 UML 사용
- 종류: Use Case Diagram, Data Flow Model, State Model, …
UML (Unified Modeling Language)
- 객체지향 소프트웨어 개발과정에서 시스템 분석, 설계, 구현 등의 산출물을 명세화, 시각화, 문서화할 때 사용하는 모델링 기술과 방법론을 통합해 만든 모델링 언어
- Rumbaugh 의 OMT방법론 + Booch의 Booch방법론 + Jacobson의 OOSE방법론
- 럼바우(Rumbaough) 객체지향 분석 기법 ⭐
- 소프트웨어 구성요소를 그래픽으로 모형화
- 객체 모델링 기법
- 객체 모델링 → 동적 모델링 → 기능 모델링
- 객체 모델링(정보 모델링): 요구되는 객체를 찾아 객체 간의 관계를 다이어그램으로 표시
- 동적 모델링: 제어흐름, 상호작용, 동작 순서 등의 상태를 시간 흐름에 따라 다이어그램으로 표시
- 기능 모델링 : 여러 프로세스 간의 자료 흐름을 표시
- 작성 도구:
- 객체 모델링(OMT): 객체 다이어그램
- 동적 모델링 : 상태도
- 기능 모델링 : 자료 흐름도
- 럼바우(Rumbaough) 객체지향 분석 기법 ⭐
- 특징: 시각화, 문서화, 명세화, 구축, 확장성, 표준화된 언어
- UML 소프트웨어에 대한 관점
- 기능적 관점
- 사용자 측면에서의 소프트웨어의 기능
- 요구 분석 단계에서 사용
- Use Case Diagram 사용
- 정적 관점
- 내부의 구성 요소 사이의 구조적 관계
- Class Diagram 사용
- 동적 관점
- 시스템의 내부 동작
- 기능적 관점
UML의 구성과 접근 제어자
- 기본 구성
- 사물 Things : 객체지향 모델을 구성하는 기본요소, 객체 간의 관계 형성 대상
- 관계 Relationship: 객체 간의 연관성(연관, 집합, 포함, 일반화, 의존, 실체화)
- 다이어그램 Diagram: 객체의 관계를 도식화 한 것
- 정적 모델: 구조 다이어그램
- 동적 모델: 행위 다이어그램
- 스테레오 타입 : UML의 기본 요소 외에 추가적인 확장 요소를 표현할 때 사용
- 길러멧 Guilemet « » 사용: « 확장요소 »
- UML 접근 제어자
접근 제어자 표기 설명 public + 어떤 객체에서든 접근 가능 private - 해당 클래스 내의 객체만 접근 가능 protected # 동일 패키지나 상속 관계의 하위 클래스의 객체만 접근 가능 package ~ 동일 패키지의 클래스의 객체들만 접근 가능 - 연관관계 다중성 표현
표기 의미 1 1 객체 연결 * 또는 0..* 0 이상의 객체 연결 1..* 1 이상의 객체 연결 0..1 0 또는 1 객체 연결 1, 3, 6 1 또는 3 또는 6 객체 연결 n n개 객체 연결 n..* n개 이상의 객체 연결
UML 다이어그램의 분류
구조 다이어그램 Structural Diagram
- 시스템의 구조와 구성 요소 간의 관계를 시각적으로 표현
- 종류
종류 설명 클래스 다이어그램 클래스, 인터페이스 관계 등을 시각적으로 표현 객체 다이어그램 객체간의 관계와 상태 복합체 구조 다이어그램 복잡한 구조의 모델링 배치 다이어그램 물리적인 배치와 구성 컴포넌트 다이어그램 컴포넌트들의 구조와 관계 패키지 다이어그램 여러 객체를 그룹화하여 표현, 모듈화와 구조화를 가능하게 함
클래스 다이어그램
- 객체간의 관계를 추상화한 모델을 논리적 구조로 표현
- 클래스 이름, 속성 및 속성 타입, 오퍼레이션(연산), 오퍼레이션 리턴 타입, 오퍼레이션 매개 변수, 접근 제어
행위 다이어그램 Behavioral Diagram
- 시스템의 동작을 표현하는 다이어그램
- 종류
종류 설명 유스케이스 다이어그램 사용자 간의 상호 작용 활동 다이어그램 내부의 프로세스나 작업 흐름을 표현 상태머신 다이어그램 생명주기와 상태 변화를 시각화(상태, 이벤트, 전이) 협력 다이어그램 객체들이 서로 메시지를 주고받는 과정을 표현 상호작용 다이어그램 객체 간에 주고 받는 메시지를 통해 상호작용을 시각화함
상호작용 다이어그램 Interaction Diagram
- 순차 다이어그램 Sequence Diagram ⭐
- Use Case의 실현을 위해 구성요소들이 어떻게 상호작용하는지
- 특정 객체들이 활성화되어 동작하고, 다른 객체들을 호출하는 순서를 표현
- 시간 흐름과 순서에 따른 시스템 동작을 표현
- 구성 요소: 객체, 생명선, 실행, 메시지, 시간
- 통신 다이어그램 Communication Diagram
- 객체 간의 통신을 보여줌
- 참여 요소 간의 상호작용 관계에 초점
- 순차 다이어그램과 1:1 상호 변환이 가능
Use Case Diagram
- 사용자의 요구를 기능적 측면에서 기술할 때 사용
- 구성: 액터(Actor)와 유스케이스(Use Case)
- 결과: 개발 대상 시스템이 제공해야 하는 서비스 목록
- Use Case Diagram 요소⭐
요소 설명 System Boundary Use Case들의 범위, 큰 규모의 객체로 구현 Actor 서비스를 이용하는 외부 객체, Use Cse를 실행하도록 요구 가능한 존재 Use Case 사용자 관점에서의 기능, 개별적인 서비스 기능, 특정클래스의 멤버 함수로 모델링 Relationship-
AssociationUse Case와 Actor간의 상호작용이 있음을 표현 Relationship-
Include하나의 Use Case가 다른 Use Case의 실행을 전제로 하는 관계 Relationship-
Extend확장기능 Use Case와 확장 대상 Use Case사이에 형성되는 관계 Relationship-
Generalization유사한 Use Case 또는 Actor을 모아 추상화한 것과 연결시켜 그룹을 만든 관계,
하위가 상위 Use Case의 기능을 물려받는 경우 사용 - Use Case Diagram 작성 단계: 액터 식별→ Use Case식별→관계 정의 → Use Case 구조화
Use Case Diagram 관계 표현
- UML 연관 관계 Association Relation
- 단방향 연관 관계
- 한 쪽만 상대방을 앎
- 양방향 연관 관계
- 양쪽 객체들이 서로의 존재를 인지
- 단방향 연관 관계
- UML 의존 관계 Dependency Relation
- 연간관계와 같지만, 매우 짧은 시간만 유지됨
- UML 일반화 관계 Generalization Relatoin
- 상속관계 표현
- UML 집합 관계 Aggregation Relation
- 전체와 부분 간의 관계
- 전체 객체는 부분 객체를 포함
- 부분 객체는 전체 객체에 의해 생성, 소멸하지 않고 다른 객체와 공유 가능
- or 관계에는 점선 사용학교에는 학생과 교사가 있다
- UML 포함 관계 Composition Relation
- 부분 객체가 전체 객체에 속하는 강한 집합 관계
- 부분 객체는 다른 객체와 공유 불가책상은 다리와 상판으로 구성
- UML 실체화 관계 Realization Relation
- 인터페이스와 실제 구현된 일반 클래스 간의 관계로 존재하는 행동에 대한 구현을 표현
'자격증 > 정보처리기사' 카테고리의 다른 글
[소프트웨어설계] 6. 시스템 인터페이스 설계 (0) | 2024.01.21 |
---|---|
[소프트웨어설계] 5. 객체지향 설계와 디자인 패턴 (0) | 2024.01.19 |
[소프트웨어설계] 4. 소프트웨어설계 (0) | 2024.01.18 |
[소프트웨어설계] 3. UI설계 (1) | 2024.01.17 |
[소프트웨어설계] 1. 소프트웨어공학과 개발 방법론 (0) | 2024.01.16 |