2장. 소프트웨어 프로세스
소프트웨어 프로세스
소프트웨어 프로세스
•
소프트웨어 시스템을 제품화하기 위한 활동들의 집합
•
다양한 유형의 시스템 개발에 적용 가능한 보편적 소프트웨어 공학 기법은 존재하지 않는다.
기본적인 소프트웨어 공학 활동
1. 소프트웨어 명세화 (Specification)
소프트웨어의 기능과 운영 제약조건을 정의해야 한다.
2. 소프트웨어 개발 (Development)
시스템의 구조를 정의하고 구현, 명세와 일치하는 소프트웨어를 개발해야 한다.
3. 소프트웨어 검증 (Validation)
시스템이 고객이 요구하는 것인지 점검해야 한다.
4. 소프트웨어 진화 (Evolution)
고객의 요구 변화에 따라 시스템을 변경해야 한다.
프로세스 설명에 포함되어야 하는 것
1. 제품과 산출물 (Product and Deliverable)
•
프로세스 활동의 결과물
•
명세화, 설계, 구현, 테스팅 등
2. 역할 (Role)
•
프로세스에 참여하는 사람들의 책임
•
프로젝트 관리자, 형상 관리자, 프로그래머 등
3. 사전/사후 조건 (Pre/Post Condition)
프로세스 활동이 이루어지거나 제품이 만들어지는 전후에 만족되어야 하는 조건들
계획 주도 프로세스와 애자일 프로세스
계획 주도 프로세스 (Plan-driven Process)
모든 프로세스 활동(Activities)을 미리 계획하고 계획 대비 실적을 측정한다.
애자일 프로세스 (Agile Process)
계획을 점증적으로 세우고 고객의 요구를 반영하여 프로세스를 간단히 변경한다.
대부분의 실제 프로세스는 계획 주도와 애자일 프로세스를 둘 다 포함한다.
소프트웨어 프로세스 모델
일반적인 프로세스 모델
1. 폭포수 모델 (Waterfall)
•
계획 주도
•
명세화, 개발, 검증, 진화를 개별적인 프로세스 단계로 구분한다.
2. 점증적 개발 (Incremental)
•
계획 주도 또는 애자일
•
명세화, 개발, 검증 활동이 중첩된다.
•
시스템은 일련의 증가분 (Increment)으로 개발된다.
•
증가분이랑 이전 버전과 비교하여 추가된 기능을 의미한다.
3. 통합 및 설정 (Integration and Configuration)
•
계획 주도 또는 애자일
•
재사용할 수 있는 컴포넌트나 시스템을 설정하고 통합하는데 초점을 맞춘다.
폭포수 모델
폭포수 모델의 단계
1. 요구사항 분석 및 정의
•
시스템 사용자와의 면담을 통해 시스템의 서비스, 제약조건과 목표를 설정한다.
•
설정한 내용은 더 구체화 시킨 후 시스템 명세서로 사용한다.
2. 시스템 및 소프트웨어 설계
•
요구사항을 하드웨어와 소프트웨어 시스템으로 나누어 할당하고, 전체 시스템 아키텍처를 작성한다.
•
소프트웨어 설계 = 소프트웨어 시스템 추상화와 이들 간의 관계를 파악하고 기술하는 활동을 포함한다.
3. 구현 및 단위 테스팅
•
소프트웨어 설계를 프로그램으로 실체화한다.
•
단위 테스팅 = 각각의 단위가 주어진 명세를 만족하는지 검증하는 활동이다.
4. 통합 및 시스템 테스팅
•
개별 프로그램 단위나 프로그램을 통합하여 소프트웨어 요구사항을 만족하는지 전체 시스템을 검사한다.
•
테스트 후에는 소프트웨어 시스템을 고객에게 전달한다.
5. 운영 및 유지보수
•
시스템이 설치되고 사용되는 단계로, 정상적인 경우 이 활동이 가장 긴 생명 주기 단계다.
•
이전 단계에서 발견하지 못했던 오류를 수정, 시스템 단위의 구현을 개선, 새로운 요구사항을 반영하여 시스템 서비스를 향상시킨다.
폭포수 모델의 특징과 단점
폭포수 모델의 특징
•
각 단계의 결과로 하나 혹은 하나 이상의 승인된 문서가 존재해야 한다.
•
원칙적으로 한 단계가 종료되어야 다음 단계를 시작한다.
폭포수 모델의 단점
•
실제 소프트웨어 개발은 각 단계가 중첩된다.
•
한 단계 (구현, 설계)에서 다른 단계 (설계, 요구사항)로의 피드백이 일어난다.
•
이전 단계의 문서를 수정하게 되면 프로세스 지연이 일어난다.
•
결국 추가 변경을 반영하지 않도록 명세서를 확정하게 된다.
변화하는 고객의 요구사항에 대응하기 어렵다.
폭포수 모델이 적합한 분야
요구사항 이해도가 높으며, (설계, 구현 중) 요구사항 변경이 제한되는 분야
1.
임베디드 시스템
•
하드웨어와 연동해야 함으로 구현 시까지 의사결정을 미룰 수 없기 때문이다.
2.
중대한 시스템
•
명세와 설계에 대한 분석 및 검토가 필요하기 때문이다.
3.
대규모 소프트웨어 시스템
•
여러 회사, 장소에서 개발하기 때문에 완성된 명세서가 필요하기 때문이다.
폭포수 모델이 적합하지 않은 분야
1.
자유로운 팀 커뮤니케이션이 가능
2.
소프트웨어 요구사항이 빨리 변경되는 상황
반복적 개발과 애자일 방법론이 적합하다.
점증적 개발
점증적 개발 (Incremental Development)
•
초기 구현을 개발하고, 사용자와 다른 사람들로부터 피드백을 받아서, 여러 버전을 거쳐 소프트웨어를 진화시킴으로써 요구한 최종 시스템을 개발하는 것이다.
•
명세, 개발, 검증은 명확히 구분되지 않으며 중첩되어 있다.
•
요구 사항이 쉽게 변하는 시스템에 적합하다. (대부분의 비즈니스 시스템)
•
개발하면서 발생하는 변경 사항에 대처하기 쉽다.
시스템의 증가분
•
시스템의 초기 증가분: 가장 중요하거나 긴급하게 요구되는 기능을 포함시킨다.
•
기타 시스템 증가분: 진척도와 고객의 우선순위에 따라 달라진다.
점증적 개발 장점
•
요구사항 변경을 구현하는 비용이 줄어든다.
•
이미 개발된 내용에 대해 고객의 피드백을 받기 쉽다.
•
모든 기능을 개발하기 전에 유용한 소프트웨어를 고객에게 전달하여 설치하고 사용하게 할 수 있다.
점증적 개발 단점
1. 프로세스가 비가시적이다.
관리자는 진척도를 측정하기 위해 산출물이 필요하지만 문서를 작성하는 것은 비용 측면에서 비효율적
2. 새로운 증가분 추가됨에 따라 시스템 구조가 저하되는 경향이 존재
구조 저하와 코드가 복잡해지는 것을 막기 위해 정기적 리팩토링 (Refactoring)이 필요하다
대규모 시스템의 개발에는 적절하지 않다.
Tip) Refactoring: 개선과 재구성
통합과 환경설정
통합과 환경설정
재사용할 수 있는 코드를 찾고 요구에 맞추어 수정한 후 이미 개발한 새로운 코드와 통합한다.
재사용 기반 프로세스
1.
요구사항 명세화
2.
소프트웨어 발견 및 평가
3.
요구사항 정제
4.
애플리케이션 시스템 설정
5.
컴포넌트 수정과 통합
프로세스 활동
실제 소프트웨어 프로세스
명세, 설계 구현, 테스팅 등의 활동이 중첩되어 있다.
기본 프로세스 활동
1.
소프트웨어 명세화 (Specification)
2.
소프트웨어 개발 (Development)
3.
소프트웨어 검증 (Validation)
4.
소프트웨어 진화 (Evolution)
개발 프로세스 별 기본 활동 구성
1.
폭포수 모델: 순차적 구성
2.
점증적 모델: 중첩 구성
소프트웨어 명세화
소프트웨어 명세화 (= 요구 공학)
•
시스템을 개발하기 위해 어떤 서비스가 필요한지를 이해하고 정의하며, 시스템의 운영과 개발에 대한 제약사항을 찾아내는 프로세스
•
명세화 (요구 공학) 이전에 타당성 조사 (Feasibility Study)나 마케팅 조사를 수행 가능하다.
소프트웨어 명세화 (요구 공학) 프로세스의 주요 활동 3가지
1. 요구사항 도출과 분석 (Requirements Elicitation and Analysis)
기존 시스템 관찰, 잠재적 사용자 및 구매자와 의사소통, 업무 분석을 통해 시스템 요구사항을 얻어내는 프로세스
2. 요구사항 명세화 (Requirements Specification)
요구사항 분석 과정에서 확보한 정보를 바탕으로 요구사항을 담은 문서를 작성하는 활동
•
사용자 요구사항: 고객 및 사용자를 위한 것으로, 시스템 요구사항에 대한 추상적 문제들에 해당한다.
•
시스템 요구사항: 제공할 기능에 대한 보다 상세한 설명을 포함한다.
3. 요구사항 검증 (Requirements Validation)
•
요구사항에 대한 현실성, 일관성, 완전성을 검사하는 활동 (Realism, Consistency, Completeness)
•
요구사항 문서상의 오류를 발견하고 해결한다.
소프트웨어 설계 및 구현
소프트웨어 설계
시스템 명세로부터 실행가능한 시스템으로 변환하는 프로세스
소프트웨어 설계 기술 목록
1.
구현해야 하는 소프트웨어 구조
2.
시스템이 사용하는 데이터 모델과 구조
3.
시스템 컴포넌트들 사이의 인터페이스
4.
사용하는 알고리즘
이 과정에서 설계에 대한 상세한 내용 추가 및 이전 설계를 수정하기 위해 끊임없이 되돌아가는 작업 반복
소프트웨어 구현
•
프로그램 개발
•
설계와 구현이 중첩되는 경우가 많다.
•
프로그래밍은 개별적 활동이기 때문에 따로 준수해야 할 일반적인 프로세스가 존재하지 않는다.
소프트웨어 구현 시 주의할 점
1.
테스팅: 제거해야 할 프로그램의 결함을 찾는다 → 결함의 존재 확인
2.
디버깅: 프로그램의 결함을 찾아서 고치는 작업 → 결함의 위치를 찾고 수정
소프트웨어 검증
Verification and Validation (V&V)
1.
Verification: 시스템이 주어진 명세를 준수하는 것
2.
Validation: 시스템이 고객의 기대를 충족하는 것
실제처럼 제작한 테스트 데이터를 사용해서 시스템을 실행하는 '프로그램 테스팅'은 주요한 검증 기법이다.
테스팅 프로세스 단계
1. 컴포넌트 테스팅
개별 컴포넌트 (함수, 객체, 또는 이들의 그룹 등)를 테스트
2. 시스템 테스팅
•
컴포넌트를 통합하여 시스템을 구성하고 이를 테스트
•
컴포넌트 간 예기치 못한 상호작용과 인터페이스 문제 때문에 발생한 오류를 찾는 활동
•
기능적 / 비기능적 요구사항 만족 여부, 창발적 (Emergent) 시스템 속성을 테스팅
3. 고객 테스팅
•
시스템이 실제 운영을 위한 인수가 결정되기 전, 테스팅 프로세스의 최종 단계
•
시스템 고객의 실제 데이터를 이용하여 테스트
소프트웨어 진화
소프트웨어 유연성 (Flexibility)
•
소프트웨어 유연성이라는 주요한 이유로 점점 더 많은 소프트웨어가 통합을 통해 더 크고 복잡한 시스템으로 변화 중
•
소프트웨어 변경은 하드웨어 변경에 비해 쉽기 때문이다.
개발과 유지보수
•
개발과 유지보수의 구분이 줄어들고 있다.
•
완전히 새로 만든 소프트웨어 시스템은 거의 없다.
•
요구사항 변화를 지속적으로 반영하면서 소프트웨어가 진화한다.
요구사항이 변화하므로 소프트웨어도 진화하고 변경되어야 한다.
변경 처리
변경을 처리하고 시스템 요구사항을 바꾸기 위한 두가지 방법
1. 시스템 프로토타이핑
•
고객의 요구사항 및 결정한 설계의 타당성을 확인하기 위해 시스템의 한 버전이나 부분을 빠르게 개발하는 것
•
인도 전에 사용자가 시스템을 사용하여 미리 요구사항을 개선할 수 있도록 한다.
2. 점증적 인도
의견을 받거나 사용할 수 있도록 시스템 증가분을 고객에게 전달하는 것
소프트웨어 프로토타이핑
프로토타입 (Prototype)
제품의 아이디어를 시연하고, 디자인 선택 사항들을 시도해보고, 문제점과 해결책을 찾아내기 위해 사용하는 소프트웨어 시스템의 초기 버전
프로토타입의 용도
1. 요구 공학 프로세스
•
요구사항 도출과 검증에 도움을 준다.
•
프로토타입을 사용해 보고 아이디어를 얻을 수 있다.
2. 설계 프로세스
•
설계 문제에 대한 해결책을 탐색하거나 설계의 타당성을 확인하기 위한 실험용으로 사용 가능
•
시스템을 위한 사용자 인터페이스 개발을 위해서도 사용 가능
