소프트웨어 프로세스란?
: 소프트웨어 시스템을 개발하기 위해 구조화된 활동 집합
개발 프로세스
(다양한 소프트웨어 개발 프로세스가 있지만, 공통적으로 포함됨)
- 명세(Specification) – 시스템이 무엇을 해야 할지 정의설계 및 구현(Design and Implementation) – 시스템의 구성 조직 및 구현
- 검증(Validation) – 고객 요구사항을 충족하는지 확인
- 진화(Evolution) – 고객 요구 변화에 따라 시스템을 변경
프로세스 모델: 프로세스를 특정 관점에서 추상적으로 표현한 것
프로세스 설명방식
활동(activity) 단위로 설명함
예: 데이터 모델 명세, UI 설계 등
- 산출물(Products): 해당 활동의 결과물
- 역할(Roles): 각 활동에 참여하는 사람들의 책임
- 전후 조건: 어떤 활동이 실행되기 전/후에 만족해야 할 조건들
Plan-driven Vs Agile
Plan-driven:
모든 활동이 사전에 계획되고, 진행은 그 계획에 따라 평가됨
Agile:
계획이 점진적이며 유연함 → 고객 요구 변화에 쉽게 대응 가능
실제로는 대부분의 실무 프로세스가 이 두 가지를 혼합하여 사용
절대적인 정답은 없음
소프트웨어 프로세스 모델
= 소프트웨어 개발 생명주기
- 워터폴 모델
- 계획 기반(plan-driven)
- 명세와 개발을 단계별로 분리해서 수행 => 순차적
- 점진적 개발 (Incremental Development)
- 명세, 개발, 검증을 섞어서 반복
- 애자일 또는 계획 기반으로 운영 가능 => 유연
- 통합 및 구성 (Integration and Configuration)
- 기존에 재사용 가능한 구성요소를 통합해서 시스템 구성
- 이 또한 애자일 또는 계획 기반 가능
1. 워터폴 모델
- 요구 분석 및 정의
- 시스템 및 소프트웨어 설계
- 구현 및 단위 테스트
- 통합 및 시스템 테스트
- 운영 및 유지보수
=> 각 단계별 문서화된 산출물 필요
단점:
변경에 매우 취약 => 고객 요구가 바뀌어도 중간 변경이 어려움
따라서, 요구사항이 명확하고 변화가 적을 때 적합
적용 예:
- 대규모, 다부서 협업, 국제 프로젝트 등
- 계획 중심이 유리한 상황
| 임베디드 시스템 | 하드웨어가 고정되어 변경 불가 |
| 안전 필수 시스템 | 명세 및 설계가 완벽히 정의되어야 함 |
| 대규모 시스템 | 많은 인원이 협업하기에 계획 중심이 유리 |
2. 점진적 개발
장점
- 변화 대응 비용↓
- 변경이 생겨도 다시 문서화하거나 재설계해야 할 부분이 워터폴보다 적음
- 고객 피드백↑
- 구현된 부분을 시연해보면서 고객이 의견을 줄 수 있음
- 고객이 무엇이 완료되었는지 직접 확인 가능
- 빠른 납품 가능
- 시스템을 한꺼번에 다 만들지 않아도 일부 기능 먼저 제공 가능
- 고객이 조기에 가치를 경험할 수 있음
=> 워터폴 모델보다는 빠름
단점
- 프로세스 가시성이 떨어짐
- 매 버전마다 문서를 만드는 것 = 비효율적 => 진척 상황을 파악하기 어려움
- 특히 관리자 입장에서는 매번 산출물이 없으면 불안할 수 있음
- 시스템 구조의 품질 저하
- 점진적으로 계속 추가 -> 기존 구조가 점점 복잡해지고 무너지기 쉬움
- 리팩토링에 시간과 예산을 쓰지 않으면, 유지보수 어려워짐
3. Integration and Configuration: 재사용 기반 개발 방식
- 시스템은 기존 구성 요소(component) 또는 애플리케이션 시스템에서 통합하여 구성됨
- 때로는 COTS (상용 소프트웨어)라고도 부름
- 재사용 요소는 고객 요구에 맞게 구성(configuration) 가능
- 현재 많은 비즈니스 시스템이 이 방식을 채택함
재사용하는 소프트웨어 종류
- 독립 실행 애플리케이션 시스템
- COTS 시스템, 특정 환경에 맞게 설정(configure) 가능
- 객체 컬렉션 (Object Collections)
- .NET, J2EE 같은 프레임워크용 컴포넌트 패키지
- 웹 서비스 (Web Services)
- 서비스 표준에 따라 개발되어, 원격 호출로 사용 가능 (예: REST API)
장점
- 개발 비용과 위험 감소
- 새로 만들지 않으니 시간/자원 절약
- 빠른 시스템 제공 가능
단점
- 요구사항 타협 발생
- 재사용 부품이 완벽하게 맞지 않을 수 있어, 고객 요구와 다를 수 있음
- 제어력 상실
- 이후 변경/진화에 통제력 부족
프로세스 활동
- 소프트웨어 프로세스 = 기술적 활동 + 협업 활동 + 관리 활동
- 목적: 시스템 명세 -> 설계 -> 구현 -> 테스트
- 기본 활동을 모든 개발 프로세스에 존재하지만, 조직 방식은 다름
- 워터폴: 순차적
- 점진적 개발: 뒤섞여 있음 (interleaved)
요구사항 명세
: 시스템이 어떤 기능을 제공하고, 어떠한 제약이 있는지 정의하는 과정
요구사항 공학 프로세스 단계:
- 도출 및 분석 (Elicitation & Analysis)
- 사용자/이해관계자가 원하는 바를 파악
- 명세 (Specification)
- 구체적이고 명확하게 문서화
- 검증 (Validation)
- 현실적이고 충돌이 없는지 점검
- 현실적이고 충돌이 없는지 점검
설계와 구현
: 명세된 시스템 요구사항 -> 실행 가능한 프로그램으로 변환
과정
- Software Design:
- 요구사항을 실현할 수 있도록 구조 설계
- Implementation:
- 구조 설계를 기반으로 실제 프로그램 코드로 구현
설계 활동의 종류
- Architectural Design (아키텍처 설계)
- 전체 시스템의 주요 구성 요소(모듈)와 이들 간의 관계 정의
- Database Design (데이터베이스 설계)
- 데이터를 어떻게 저장할지 구조화
- Interface Design (인터페이스 설계)
- 모듈 간, 시스템 간의 연결 방식을 정의
- Component Selection and Design
- 기존 컴포넌트를 재사용할지 결정하고, 없다면 직접 설계
구현
: 코드 작성을 통해 기능을 실제로 구현
- 디버깅(debugging):
- 버그를 찾아내고 고치는 과정
- 프로그래밍은 일반적으로 개인의 작업이며 표준화된 구현 프로세스는 없음
검증
: 시스템이 명세에 맞게 동작하는지 확인
| Verification | Are we building the product right? | 설계가 요구사항과 일치하는가 올바르게 만들었는가? |
| Validation | Are we building the right product? | 고객 요구에 부합하는가 올바른 것을 만들었는가? |
과정:
- 체크, 코드 리뷰
- 시스템 테스트
| Component Testing | 개별 컴포넌트(함수, 객체 등)를 독립적으로 테스트 |
| System Testing | 전체 시스템이 통합된 상태에서 테스트 |
| Customer Testing | 고객 데이터를 기반으로 최종 검증 (알파/베타 테스트 포함) |
소프트웨어의 발전
1. 변화
- 소프트웨어는 유연한 존재이며, 변화에 대응해 계속 수정되어야 한다.
- 비즈니스 상황이 바뀌면 시스템도 그에 맞춰 진화해야 함
- 예전엔 “개발 ↔ 유지보수”가 구분되었지만, 이제는 대부분 지속적으로 발전하는 형태
2. 대응
- 변화는 불가피함
- 비즈니스 요구사항이 바뀜
- 새로운 기술 등장
- 플랫폼 변화 (ex. PC → 모바일)
- 변화 -> 재작업
- 요구사항 재분석
- 새로운 기능 구현 → 비용 증가가 발생함
2-1. 대응 방법
1. System Prototyping
- 핵심 기능만 빠르게 구현해서 고객에게 요구사항 검증 → 변화 예측에 유리
2. Incremental Delivery
- 기능을 쪼개서 순차적으로 전달 및 피드백 → 변화 수용에도 유리
3. 재작업 비용 줄이기
방법 1: Change anticipation (변화 예측)
- 프로토타입 제작을 통해 고객 요구를 미리 탐색
- 예: 주요 기능만 먼저 시연 → 반응 파악
방법 2: Change tolerance (변화 수용성)
- 애초에 프로세스를 유연하게 설계
- 변화는 점진적으로 반영 (Incremental development 활용)
소프트웨어 프로토타이핑
: 시스템의 초기버전
for
- 개념 설명
- UI/디자인 설명
- 테스트
사용 시점
1) 요구사항 도출 & 검증 단계
2) 설계 실험 단계
3) 백투백 비교
장점
- 시스템 사용성 향상 (Usability)
- 사용자 요구와 더 일치하는 결과 도출
- 설계 품질 개선
- 유지보수 용이성 향상
- 개발 노력 감소 (불필요한 개발 방지)
프로토타입 개발시,
- 빠르게 만들 수 있는 언어/툴 사용
- 모든 기능을 구현하지 않아도 됨!
- 잘 모르는 영역에 집중 (UI, 기능 등)
- 에러 처리는 생략 가능
- 신뢰성, 보안 등 비기능 요구사항은 나중에 고려해도 됨
프로토타입은 실제 시스템으로 사용하기 어려움
이유:
- 비기능 요구사항 충족 어려움
- 문서화 부족
- 급하게 만든 구조 → 코드 품질 ↓
- 조직 기준에 부합하지 않음
점진적 배포
: 전체 시스템을 한 번에 전달하지 않고, 기능 단위로 쪼개어 단계별 납품
특징:
- 우선순위 높은 요구사항을 먼저 구현
- 한 번 개발을 시작하면, 그 인크리먼트(단위)는 고정 → 이후 변경은 다음에서 처리
점진적 개발 vs 납품
| 점진적 개발 | 점진적 배포 |
| - 기능 단위 개발 -> 다음 increment로 가기 전 평가 - 애자일 방법론에서 사용 - 사용자가 평가 수행 |
- 최종 사용자가 사용 - 소프트웨어의 실사용에 대한 현실적 평가 가능 - 교체 시스템 구현의 어려움 -> increment 대상 < 교체 대상 시스템 |
장점
- 빠르게 가치 전달 가능
- 초기 인크리먼트가 프로토타입 역할 수행
- 프로젝트 실패 위험 ↓
- 우선순위 높은 기능 → 테스트 우선시
단점
- 기존 시스템을 대체할 경우 어려움
→ 사용자들이 기존 시스템에 익숙해져 있음 - 공통 기능 파악 어려움
- 전체 명세가 없기 때문에 기초 구조 누락 가능성
- 명세와 개발이 동시에 진행되며 계속 변함
→ 기업 입장에선 “완전한 명세서”와 “완성된 산출물”을 원하지만
→ 현실은 불확실성의 연속
프로세스 개선
- 퀄리티, 개발 속도 향상, 비용 절감 방향으로 개선해감
- 현재의 과정을 이해하고 변화하는 것
방법
| 프로세스 성숙도 접근 (Process Maturity) | 조직 내 절차와 관리를 체계화하는 방식 (→ CMM 모델 등) |
| 애자일 접근 (Agile) |
문서와 형식은 최소화, 기능 전달 중심의 반복 개발 |
측정: 수치 기반으로 현재의 상황 파악
→ 분석: 병목과 문제점 파악
→ 변경: 개선 아이디어 구현
→ 다시 측정
측정
=> 가능한 정량적인 데이터를 수집해야함
but, 과정을 명확하게 하지 않으면 데이터 수집이 어려움 -> 측정이 하기 위해 프로세스 정의가 필요
=> 개선 자체가 목적이 아니라, 조직의 목표에 도달하기 위한 수단이어야함
측정 항목
- 시간
ex. 수행 시간
- 자원
ex. 작업에 투입된 인원수
- 이벤트 횟수
ex. 발견된 버그 횟수
'공부 > 소프트웨어 공학' 카테고리의 다른 글
| Software Engineering: Agile (0) | 2025.04.20 |
|---|---|
| Software Engineering: Plan-driven development & Project Plans (0) | 2025.04.20 |
| Software Engineering: Project Planning & Software Price (0) | 2025.04.20 |
| Software Engineering 소프트웨어 공학: Project Management 프로젝트 관 (0) | 2025.04.19 |
| Software Engineering: Introduction (4) | 2025.04.16 |