728x90
이번 글에서는 지난 글에 이어서 프로세스 활동, 소프트웨어 명세, 소프트웨어 설계 및 구현 등에 대해 알아보자.
프로세스 활동
- 기본 프로세스 활동
- Specification (명세)
- Design and implementation (설계 및 구현)
- Validation (Testing) (검증)
- Evolution (Maintenance) (진화)
- 각 개발 프로세스마다 조작 방식이 다르다.
- waterfall model (폭포수 모델) : 순차적 조직
- incremental development (점진적 개발) : 활동이 상호 교차됨
Software specification (소프트웨어 명세)
- 시스템이 제공해야 할 서비스와 시스템 운영 및 개발의 제약 조건을 정립하는 과정이다.
Requirements engineering process (요구사항 공학 프로세스)
소프트웨어 설계 및 구현
- 시스템 명세서를 실행 가능한 시스템으로 변환하는 과정이다.
- 소프트웨어 설계
- 명세를 실현할 소프트웨어 구조를 설계한다.
- 구현
- 설계 구조를 실행 가능한 프로그램으로 변환한다.
- 설계와 구현은 밀접하게 연관되어 있으며 상호 교차될 수 있다.
설계 프로세스의 일반 모델
Design activities (설계 활동)
- Architectural design (아키텍처 설계)
- 시스템의 전체 구조, 주요 컴포넌트 및 관계 식별
- Database design (데이터베이스 설계)
- 시스템 데이터 구조 및 데이터베이스 표현 설계
- Interface design (인터페이스 설계)
- 시스템 컴포넌트 간 인터페이스 정의
- Component selection and design (컴포넌트 선택 및 설계)
- 재사용 가능한 컴포넌트 탐색, 없을 경우 설계
아래는 안드로이드의 소프트웨어 아키텍처 예시이다.
시스템 구현
- 프로그래밍은 개인적인 활동이다.
- 표준화된 프로그래밍 프로세스는 없다.
- 디버깅은 프로그램의 오류를 찾아 수정하는 활동이다.
소프트웨어 검증
- 검증 및 확인 Verification and Validation (V&V)
- 시스템이 명세에 부합하고 고객 요구를 충족하는 지를 확인한다.
- 리뷰(검토)와 시스템 테스트를 포함한다.
테스트 단계
- 컴포넌트 테스트
- 개별 컴포넌트를 독립적으로 테스트한다.
- 시스템 테스트
- 전체 시스템을 테스트한다.
- 인수 테스트
- 고객 데이터로 시스템이 요구를 충족하는지 확인한다.
plan-driven 소프트웨어 프로세스에서의 테스트 단계
소프트웨어 진화 (software evolution)
- 소프트웨어는 본질적으로 유연하며 변화 가능하다.
- 비즈니스 환경 변화에 따라 소프트웨어도 진화해야한다.
프로세스 반복 - 요구사항 변화 대응
- 대규모 소프트웨어 프로젝트에서는 요구사항 변화가 불가피하다.
- 비즈니스 변화, 신기술, 플랫폼 변화 등으로 인해 요구사항이 바뀐다.
- 요구사항 변화는 프로세스 반복(이전 단계 재작업)으로 이어진다.
- 대규모 시스템에서는 항상 반복(iteration)이 존재한다.
- 관련 접근법
- Incremental delivery (점진적 납품)
Incremental delivery (점진적 납품)
- 시스템을 한 번에 납품하지 않고 여러 증분으로 개발하고 납품한다.
- 각 증분을 일부 기능을 제공한다.
- 사용자 요구사항은 우선순위에 따라 배치한다.
- 우선순위가 높은 요구사항이 먼저 구현된다.
- 증분 개발 시작 후 해방 증분의 요구사항은 고정된다.
- 이후 증분의 요구사항은 계속 evolve 가능하다.
- 장점
- 각 증분마다 고객 가치 제공
- 기능 조기 제공
- 초기 증분이 프로토타입 역할
- 우선순위 높은 서비스가 더 많이 테스트됨
- 프로젝트 실패 위험 감소
- 문제점
- 모든 증분에 필요한 공통 서비스 식별이 어려움
아래는 Incremental delivery (점진적 납품)의 도식화이다.
Rational Unified Process (RUP)
- UML 및 관련 프로세스에서 파생된 반복적 소프트웨어 개발 프로세스 프레임워크이다.
- 3가지 관점에서 설명 가능하다.
- 동적 관점 : 시간에 따른 단계
- 정적 관점 : 프로세스 활동
- 실천 관점 : 좋은 실천 방법 제안
RUP 단계 모델 - 동적 관점
- 단계는 기술적이기보다 비즈니스와 밀접하게 연관된다.
- 단계 반복 : 개념, 정교화, 구축, 전환
728x90
RUP 단계 - 동적 관점
- Inception (개념)
- 시스템의 비즈니스 사례 수립
- 시스템의 비즈니스 기여 평가
- Elaboration (정교화)
- 문제 영역 이해
- 아키텍처 프레임워크 수립
- 프로젝트 계획 개발
- 주요 위험 식별
- Construction (구축)
- 시스템 설계
- 프로그래밍
- 테스트
- Transition (전환)
- 시스템을 운영 환경에 배포
Static workflows (정적 워크플로우) - 정적 관점
- 비즈니스 모델링
- 비즈니스 프로세스를 비즈니스 유스케이스로 모델링
- 요구사항
- 시스템과 상호작용하는 액터 식별
- 유스케이스로 요구사항 모델링
- 분석 및 설계
- 아키텍처, 컴포넌트, 객체, 시퀀스 모델로 설계 모델 작성 및 문서화
- 구현
- 시스템 컴포넌트 구현 및 하위 시스템 구조화
- 설계 모델에서 자동 코드 생성 가능
- 테스트
- 구현과 함께 반복적으로 수행
- 구현 완료 후 시스템 테스트
- 배포
- 제품 릴리즈 생성
- 사용자에게 배포 및 설치
- 구성 및 변경 관리
- 시스템 변경 관리
- 프로젝트 관리
- 시스템 개발 관리
- 환경
- 개발팀에 적합한 소프트웨어 도구 제공
RUP의 좋은 실천 방법 - 실천 관점
- 반복적으로 소프트웨어를 개발한다.
- 요구사항을 관리한다.
- 컴포넌트 기반 아키텍처를 사용한다.
- 소프트웨어를 시각적으로 모델링한다.
- 소프트웨어의 품질을 검증한다.
- 변경을 관리한다.
오늘은 많은 내용을 정리했다.
소프트웨어 공학을 공부하면서 많은 것들을 알아가고 싶다.
728x90
'CS > Software Engineering' 카테고리의 다른 글
| [소프트웨어공학/Software Engineering] Polymorphism 다형성 (0) | 2026.04.10 |
|---|---|
| [소프트웨어공학/Software Engineering] 객체 지향이란? (2) | 2026.04.09 |
| [소프트웨어공학/Software Engineering] 애자일 소프트웨어 개발 (0) | 2026.04.07 |
| [소프트웨어공학/Software Engineering] 소프트웨어 프로세스 (1) (0) | 2026.04.02 |
| [소프트웨어공학/Software Engineering] 소프트웨어란? (0) | 2026.04.02 |