Search

Ch.03 : Unified Process

course
last review
2023/10/14 → 2023/10/15
mastery
none
progress
not started
date
4 more properties
Previous chapter

Lifecycle Phases

Inception Phase

시스템의 요구사항을 식별하고 시스템의 범위를 결정하는 단계
As-Is 모델을 통해 현재 비즈니스 프로세스의 문제점을 분석
Stakeholder가 기술한 비즈니스와 시스템의 비전을 만족하기 위한 To-Be 모델을 제작
즉, Inception Phase에서의 마일스톤비전과 범위다.

Elaboration Phase

요구사항을 만족하기 위해 시스템을 분석하고 설계하는 단계
베이스라인 아키텍쳐를 여기에서 작성한다.
즉, Elaboration Phase에서의 마일스톤은 베이스라인 아키텍쳐다.

Construction Phase

실행가능한 시스템을 만들어내는 단계
설계된 컴포넌트들을 구현하고 테스트
Construction Phase에서의 마일스톤은 Initial Capability이다.

Transition Phase

제품을 사용자에게 인도하는 단계
배포및 사후지원 등등

Major UP Disciplines

Business Modeling || 비즈니스 모델링

대상 조직과 시스템, 개선하고자하는 요구사항을 이해하고 비즈니스 모델을 만드는 과정
차후 요구사항 추출과 설계 분석단계를 진행하기 위한 기초작업으로 비즈니스 프로세스 모델비즈니스 도메인 모델을 제작한다.
비즈니스 액터와 엔티티 : 비즈니스에서 사용하는 사용자와, 그에 연관된 여러 엔티티 선정
비즈니스 유스케이스 : 어떤 시나리오 움직이는지를 기술
비즈니스 목적 : 이 짓거리를 왜 하는가?
비즈니스 과정 : 이 짓거리를 어떻게 할 것인가?(Overview)
비즈니스 데이터 : ???
비즈니스 결과 : 예상결과겠죠
등을 기술한다.

Requirement Capture || 요구사항 분석

시스템의 기능적인 요구사항이나 비기능적인 요구사항을 분석한다.
기능적인 요구사항
Dev타치가 반드시 구현해야하는 프로덕트의 Feature나 기능. 이게 구현되는가가 프로젝트의 성패를 결정한다.
특정한 조건에서의 시스템 동작장황?(예외사항같은거인듯)
비기능적인 요구사항
시스템의 퀄리티
효율, 보안성, 유지보수, 컴팩트함 등등
제약사항
시스템을 설계할 때 건드려서는 안되는 것들.

Analysis

아키텍쳐를 분석한다.
중요 유스케이스에 대해 분석 클래스를 식별하고 분석 클래스의 상호작용 모델을 작성한다.

Design

기능(비기능)적인 요구사항을 만족시키는 SW아키텍쳐와 주요 모듈을 설계한다.

Implementation

소프트웨어 아키텍쳐 상의 주요 모듈을 특정 언어나 플랫폼에 맞도록 구현한다.

Test

구현된 모듈에 대한 단위 테스팅이나 통합 테스트를 수행한다.

Characteristics of UP

Use Case Driven(4+1 View)

Architecture Centric

모든 모델은 아키텍쳐를 기반으로 만든다.
아키텍쳐 베이스라인을 기반으로 계속 실행 가능한 아키텍처를 정제한다.
개발초기에 베이직 시스템 아키텍쳐를 잘 정의해놓는 건 다른 View에도 영향을 주기 때문에 중요함.
Design Purpose : 디자인 목적
설계 목적은 시스템 또는 소프트웨어의 주요 목표를 나타냅니다. 이는 왜 시스템이 구축되거나 소프트웨어가 개발되어야 하는지를 설명하는 것으로, 비즈니스 목표 또는 문제 해결에 대한 명확한 이유를 제시합니다.
Quality Attributes :
품질 속성은 시스템이나 소프트웨어가 가져야 하는 특성을 설명합니다. 이러한 속성은 성능, 보안, 가용성, 확장성, 유지 보수성 등과 같은 품질 특성을 의미하며, 설계의 중요한 측면 중 하나입니다.
Primary Functionality : 주요 기능
주요 기능성은 시스템 또는 소프트웨어의 주요 기능을 나타냅니다. 이는 사용자 또는 비즈니스 요구사항을 충족시키기 위한 핵심적인 기능들을 설명합니다.
Architectural Concern :
아키텍처적 고려사항은 시스템 또는 소프트웨어의 설계 중에 고려해야 하는 중요한 문제나 관심사를 나타냅니다. 이는 시스템 아키텍처의 특정 측면을 강조하거나 특별히 주의를 기울여야 할 문제를 반영합니다.
Constraints : 제약사항
제약 조건은 시스템 또는 소프트웨어 설계에 부과되는 제한 사항을 나타냅니다. 이는 예산, 시간 일정, 기술 스택, 법적 규정 준수, 보안 정책 등과 같은 제약사항을 의미합니다.

Inception Phase

사업 비젼과 To-Be Model정의
Business Executive Summary(사업 스코프)
비즈니스 Object Model을 정의 : 우리가 제작하는 서비스의 규모가 어느 정도인지, 어떤 환경에서 돌아가는 지를 정의
Business Use Cases : 하나의 프로세스가 긴 경우
Activity Diagram
State Machine Diagram
Requirements Capture
System Use Cases : 어떤 액션, Function이 바로바로 atomic하게 끝나는 경우.
Functional Requirements 추출
Nonfunctional Requirements 추출
UI Prototyping
Feasibility Prototyping

SW Modeling in UML

1.
Requirement, Needs로부터 Business Use case를 뽑아낸다.
2.
Business Use Case로부터 다이어그램을 뽑아낸다.
a.
이 다이어그램으로부터 유저 인터페이스를 뽑아내고 이를 기반으로 UI 프로토타이핑을 진행한다.
b.

Functional Requirement Capture

핵심 비즈니스 로직은 Buy Item. 이를 더 딥하게 파고들어가자.

Use Case

Use Case : Buy Items
actor :
Next chapter